Subject: draft-ietf-ippm-owdp-01.txt comments

From: [email-masked] (Bruce A. Mah)
Date: Wed, 13 Dec 2000 21:30:23 -0800

Hi--

I had a few comments about the latest incarnation of the OWDP draft.  
Hope these will be helpful, or at least entertaining:

1.  In section 4.1, some mention is made of the "modes octet".  It looks to 
me, however, like the modes field in the connection setup message is 
really 16 bits, or two octets.  Thus, the "unused" space is really 14 
octets, not 15.

2.  As you know, TCP is a bytestream protocol, and thus doesn't
guarantee atomic delivery of messages (with message boundaries
preserved).  This means that either messages need to be fixed sized, or
there needs to be some way of determining the end of each message.
However, it's not clear, for example, how long a Request-Session (4.3)
message is...how long is the zero padding field at the end?

3.  What is an implementation supposed to do in the case of partial 
delivery of a control message (i.e. sender failure)?  I didn't see this 
specified.

4.  A number of fields are multi-byte quantities.  I didn't see any 
discussion of byte-ordering.  I can probably assume you meant 
network byte-order, but this really should be mentioned at least 
once...something to the effect of, "All multi-octet quantities are 
represented in network byte order."

5.  A philosophical statement:  I've become a real fan over the years of
control protocols that are line-oriented, and use ASCII text for their
messages.  It makes for greater ease of understanding and debugging.
Examples of protocols like this are SMTP, NNTP, FTP, and HTTP. Have you
thought about this?

	5a.  As a side note, I think that if either end of the protocol 
	becomes desynchronized (like due to a faulty implementation),
	it'll be rather difficult to get resynchronized with respect to
	where the message boundaries are.

6.  Back to the connection setup in 4.1, I note that there isn't a mode 
*bit* (you used the term "mode value") for unencrypted transfers.  Was 
this an oversight?  Also I note that according to the protocol as 
defined, it's possible for the client to respond with a contradictory 
set of mode bits...presumably the server should drop the connection or 
do some similarly drastic thing if this happens.

7.  The server's second message in connection setup (does it have a
name?) has a field called "Yes/No".  I suggest a more descriptive name. 
It also might be useful to have a way for a server to communicate to a 
client why an authentication was rejected.  (This gets a lot easier if 
you buy into #5 above.)

OK, not quite as organized as I'd like and certainly not a comprehensive
analysis.  Just a few thoughts I had while reading through this draft
over the past couple days.

Bruce.

---

From: stanislav shalunov <[email-masked]>
Date: 14 Dec 2000 04:43:21 -0500

> Hope these will be helpful, or at least entertaining:

Bruce,

Thank you very much for high-quality comments!

I'll incorporate fixes before -02 version, which will reflect IPPM
session discussion, goes out.

Ben, Matt,

I would make server drop connection after a possible timeout in (3)
and do nothing about (5a) [rationale below]; we can discuss it on the
plane if you can think of something smarter to do.

> really 16 bits, or two octets.  Thus, the "unused" space is really 14 

Thanks for noticing it.  Initially, I made Modes one octet wide, then
decided to add more space for possible future expansion.  Someone
suggested that 13 spare modes might not be enough, so I'll increase it
even further (unused space is there anyway).

> there needs to be some way of determining the end of each message.

The intent was to make it possible to discover the size of a message
after reading (and, possibly, decrypting) first 16 octets.  Each
message type has a specific size.

> message is...how long is the zero padding field at the end?

Those three lines attempt to say it's 12 octets.  I guess we should
say it explicitly everywhere.

> delivery of a control message (i.e. sender failure)?  I didn't see this 

We need to specify a timeout, I suppose.  Any suggestions of good,
currently fashionable values?

> represented in network byte order."

OK.

> Examples of protocols like this are SMTP, NNTP, FTP, and HTTP. Have you

Yes.  The trade-off was: easy way to authenticate messages and a way
to encrypt them in a mode already standartized by IETF or be
line-oriented.  A decision was made after some internal discussion to
go with the former option.  Do you feel the advantages of easy
understanding and debugging outweight CBC mode properties?

Additional advantage of simple binary protocol is that it's slightly
easier to code.  (Of course, making reading tcpdump -x output harder
at the same time.)

> 	where the message boundaries are.

Yes...  I don't see how we could easily fix it.  On the other hand,
there are only four commands, each having a fixed size.  Each of the
commands is mandatory and will be used even in simple scenarios.
I would expect an implementation that desynchronizes sometimes to
desynchronize during almost every session (and the bug would thus be
noticed and fixed).

It's not clear to me what would one do if desynchronization happens,
and one later manages to resynchronize.  State would not be known...
(Do we say "Stop-Sessions" or "Retrieve-Session"?)

> this an oversight? 

In unauthenticated mode nothing at all is encrypted.  Or did you mean
something else?

> Also I note that according to the protocol as defined, it's possible
> for the client to respond with a contradictory set of mode
> bits...presumably the server should drop the connection or do some
> similarly drastic thing if this happens.

The client actually MUST respond with no more than one bit set in Mode
field.  This needs to be clarified in the draft (oversight).

> name?) has a field called "Yes/No".  I suggest a more descriptive

"Accept" was used in similar situations elsewhere.  Sounds better?

> client why an authentication was rejected.  (This gets a lot easier if 

A negative response is any non-zero value, here and elsewhere.  We
intended to define a set of error codes once the draft is more mature.
Would that be sufficient?

-- 
Stanislav Shalunov <[email-masked]>	Internet Engineer, Internet2

A large number of installed systems work by fiat.  That is, they work
by being declared to work.                             -- Anatol Holt

---

From: [email-masked] (Bruce A. Mah)
Date: Thu, 14 Dec 2000 09:02:44 -0800

> session discussion, goes out.

I forgot, for some reason, to CC the ippm list.  If you think it's 
useful, feel free to forward my comments there.

[snip]

> message type has a specific size.

OK, sounds good.  Upon reading the draft a little more closely, I now 
realize that the encryption parameters are meant to apply to subsequent 
OWDP-Control messages, where I originally thought they applied to the 
OWDP-Test packets.  This raises another question in my mind...what 
about just using (for example) SSL or some other more established 
encryption layer to encrypt the entire contents of the TCP connection?  
That should simplify both the protocol and its implementation at least 
a little bit (code reuse and all that).

> say it explicitly everywhere.

I generally assume when I'm reading these things that every diagram is
"not to scale".  :-)

> currently fashionable values?

Hmmm.  The only values that come to mind are those that sendmail 
uses for SMTP conversations.  They're highly configurable but I think 
they're on the order of minutes.  I can't remember if SMTP specifies 
exact values or not.

> understanding and debugging outweight CBC mode properties?

No, not necessarily.  (IETF standardized AES in CBC mode?  I missed 
that part, I guess.  I have to go look up exactly what cipher block 
chaining means now.)

> easier to code.  (Of course, making reading tcpdump -x output harder

Hmmm.  I'll reiterate my preference for ASCII text, line-oriented
protocols, and stop there.  :-)  (Wait, in the cases where you're
encrypting, isn't tcpdump -x going to be real hard to read anyways?)

> desynchronize during almost every session (and the bug would thus be

OK, true.  It's not like this is the FTP control protocol, which has 
$DIETY knows how many commands, all with variable sizes.

> (Do we say "Stop-Sessions" or "Retrieve-Session"?)

I'm not sure what the right answer for this is, either.  This is not a 
huge problem, it just affects the ability of the protocol to be robust 
in the face of failures (note that the TCP checksum mechanism isn't 
100% reliable).  On the other hand, for scenarios where encryption is 
used, it's likely that any integrity checks in that layer would catch 
problems like this and deal with them in some way.

> In unauthenticated mode nothing at all is encrypted.  Or did you mean

What I meant was that there's a bit that means "will accept 
unauthenticated", a bit that means "will accept authenticated", and a 
bit that means "will accept encrypted".  My thinking is colored by 
using PGP for many years; in that system, encryption and authentication 
are orthogonal as you probably know.  So I was thinking that there 
should be a bit that means "will accept unencrypted", for completeness. 
It sounds from your comment that this is not necessary.

[snip]

> "Accept" was used in similar situations elsewhere.  Sounds better?

Much better.  :-)

> Would that be sufficient?

Yeah, that sounds good.  You also have those 14 unused bytes to play 
with; the server can just blat some ASCII text into those bytes.

Cheers,

Bruce.

---

From: Ben Teitelbaum <[email-masked]>
Date: Thu, 14 Dec 2000 14:40:58 -0500

Bruce,

Let me add my thanks to you for your careful reading and thoughtful
suggestions. 

Stas,

I agreed with all your responses to Bruce, with the possible exception of your
response to issue 2 (finding message boundaries in the TCP byte stream). Let
me make sure I'm understanding. I think what you are saying is that we don't
need a length field or some sort of message delimiter, because:

  1) Each message type is of fixed size;

  2) Each command begins with a "Command-Type" octet;

  3) Command response messages, though lacking a "Command-Type" octet happen
in lock-step with the commands;

Is this correct? I think a state machine diagram might help make the
lock-step-ness easier to see. I'll try to draw one.

PS: Matt and I don't see you on the plane and have concluded that you missed
the flight; hope you are OK and find your way to Ann Arbor OK.

-- 

                         ,,,

                        `o-o-  
                          <    Benjamin Teitelbaum
                           -   Advanced Network & Services, Inc.
                           .   Internet2

---

From: stanislav shalunov <[email-masked]>
Date: 14 Dec 2000 14:58:50 -0500

[email-masked] (Bruce A. Mah) writes:

> Upon reading the draft a little more closely, I now realize that the
> encryption parameters are meant to apply to subsequent OWDP-Control
> messages, where I originally thought they applied to the OWDP-Test
> packets.

Encryption parameters are applied to both OWDP-Control and OWDP-Test.

> This raises another question in my mind...what about just using (for
> example) SSL or some other more established encryption layer to
> encrypt the entire contents of the TCP connection?  That should
> simplify both the protocol and its implementation at least a little
> bit (code reuse and all that).

Several reasons:

* OWDP-Test needs a way to encrypt/authenticate messages anyway.  Once
  you have your own encryption in OWDP-Test, why not use it in
  OWDP-Control and depend on just one external library (rather than
  two: AES + SSL).

* SSL doesn't authenticate individual messages.  If one highjacks its
  TCP connection and modifies some bits, all subsequent bits will
  decypher to garbage, but there's no clear way to check for this.
  With knowledge of message boundaries of underlying protocol one can
  authenticate each message.

* SSL is complex and solves slightly different problem.
  OWDP-Control's mechanisms are light-weight.  You'd have about the
  same amount of security-related code in both cases (possibly decrypt
  after read, possibly encrypt before write), but AES library would be
  two orders of magnitude smaller than available SSL libraries.

> I generally assume when I'm reading these things that every diagram is

Explicitly specified size of all long fields everywhere.

> they're on the order of minutes.  I can't remember if SMTP specifies 

Specified 30 minutes for now.  It's more than what most TCPs would
take to timeout on the other end (if the problem is with network
connection).

> IETF standardized AES in CBC mode?

Not AES, but CBC itself is explained in an IPSec RFC.  (I'm
disconnected right now, can't provide reference.)

> (Wait, in the cases where you're encrypting, isn't tcpdump -x going
> to be real hard to read anyways?)

That's right.  Additional reason why it doesn't matter much if it's
block- or line-oriented.  And, since block-oriented protocol has these
other advantages...

> It sounds from your comment that this is not necessary.

Authenticating in some way and then having a cleartext connection
doesn't help against active man-in-the-middle attacks.  Since AES
encrypting is very cheap, I don't see a reason to have such a mode.

> with; the server can just blat some ASCII text into those bytes.

I thought about it.  Until now, there wasn't anything in the protocol
that was intended for humans (everything is for computers).  I feel
that having descriptive error codes would be more convenient for
appliances and automated tests.  If there's a place to put a human
explanation, the implementer could be pushed towards using a more
generic error code plus a verbal description of the error condition.

"Computer Science is no more about computers than astronomy is about
telescopes."					-- E. W. Dijkstra