A One-way Active Measurement Protocol (OWAMP)
draft-ietf-ippm-owdp-16

[Ballot discuss]
Section 3.2 says:
>
> Authentication of each message (also referred to as a command in this
> document) in OWAMP-Control is accomplished by adding an HMAC to it.
> The HMAC that OWAMP uses is HMAC-SHA1 truncated to 128 bits.  Thus,
> all HMAC fields are 16 octets.  An HMAC needs a key.  The same key
> used for AES encryption is used for HMAC authentication.  Each HMAC
> sent covers everything sent in a given direction between the previous
> HMAC (but not including it) and up to the beginning of the new HMAC.
> This way, once encryption is set up, each bit of the OWAMP-Control
> connection is authenticated by an HMAC exactly once.
>
We did not discuss this aspect of the solution on our teleconference.
Using the same key for AES encryption and HMAC is not a good idea.
Further, the the minimal recommended length for an HMAC-SHA1 key is
160 bits.  It can be longer, as long as it does not exceed 512 bits.

Phone call tomorrow to try to resolve the last
two issues, which are in the following.  Also to ensure
that that the revision will have the resolved issues OK.
Unfortunate that there was such a lag :(

> Date:    Wed, 09 Nov 2005 11:27:19 EST
> To:      stanislav shalunov
> cc:      Matthew J Zekauskas ,
>        Henk Uijterwaal ,Allison Mankin ,
>        "Jeff W. Boote" ,Eric Boyd
> From:    Russ Housley
> Subject: Re: review of draft-ietf-ippm-owdp-14.txt
>
>
> Stanislav:
>
> > > >Following the approach of section 6.7, the initiator would start
> > > >setting the newly allocated bit to use a new algorithm (or algorithm
> > > >suite, or an entirely new way of authenticating and protecting the
> > > >confidentiality of the traffic) as soon as it supports it.  The
> > > >clients that don't support the new algorithm will ignore the bit.
> > > >Clients that supports both will use the new one.  When software
> > > >supporting the new algorithm is deployed to a sufficient extent,
> > > >support for the old algorithm is switched off.  No rollback is
> > > >possible at that point.
> > >
> > > My concern is that this assumes a linear progression.  I'm not sure
> > > that is realistic.
> >
> >Each of the bits in the Modes word can be used for an independent
> >extension.  The extensions signaled by various bits are orthogonal:
> >for example, one bit might be allocated to change from AES-128 to some
> >other cipher, another bit might be allocated to add a protocol feature
> >(such as, e.g., support for measuring over multicast), yet another
> >might be allocated to change a key derivation function, etc.  The
> >progression of versions is not a linear order, but rather partial
> >order.  An implementation can implement any subset of these features
> >(of course, features can be made mandatory to implement---e.g., new
> >more secure ciphers if they are needed).
>
> Okay.  Please add this point to section 6.7, and we can consider this
> point resolved.
>
> > > The manual key management seems to be among a large number of parties.
> > > The document says that automated key management is needed when:
> > >
> > > # A party will have to manage n^2 static keys, where n may become
> > > # large.
> > >
> > > I do not see any indication that the number of long-term keys isn't large.
> >
> >I do not see any party that would need to manage number of keys
> >quadratic in any characteristic n.  A server needs to manage n keys,
> >one for each ``user'' it supports.  (In our current deployment, users
> >are normally sites and the key belongs to a robot that uses it for
> >automated testing; users might also be humans.)  A party that acts as
> >a client needs to manage a key for each server it support; linear
> >growth again.  A party that acts as both a client and a server,
> >therefore, only needs to manage number of keys that scales linearly,
> >not quadratically.
>
> Thanks for this description.  We need to put it to the security
> considerations as the justification for manual key management of the
> long-term keys.
>
> >Where might quadratic growth come from?
> >
> >Please help me understand the problem so I can propose a solution.  As
> >I read BCP 107, it appears to me we're already in compliance---indeed,
> >the problem BCP 107 describes is the same problem, as I understand it,
> >that we were solving by introducing the session keys and an automatic
> >mechanism for their negotiation.
>
> Okay.  Please add test to the security considerations section, and we
> can consider this point resolved.
>
> > > Section 6.7 could be extended to say that a KDF is needed if a cipher
> > > with a key size other that 128-bits is needed.  I have concerns about
> > > the size of the key that would be input the KDF for generate a 256-bit
> > > key too.
> >
> >I have made the following textual change:
> >
> >Index: draft-ietf-ippm-owdp.nroff
> >===================================================================
> >===================================================================
> >RCS file: /home/cvs/engdev/owdp-id/draft-ietf-ippm-owdp.nroff,v
> >retrieving revision 1.140
> >retrieving revision 1.141
> >diff -u -r1.140 -r1.141
> >--- draft-ietf-ippm-owdp.nroff  9 Nov 2005 03:55:01 -0000      1.140
> >+++ draft-ietf-ippm-owdp.nroff  9 Nov 2005 04:00:41 -0000      1.141
> >@@ -2124,6 +2124,16 @@
> >  to message layout as well as the change in the cryptographic
> >  primitive.)
> >
> >+Should a cipher with 256-bit key become needed, a new key derivation
>
> s/256-bit key/a different key size, say a 256-bit key,/
>
> >+function for OWAMP-Test keys would also be needed.  The semantics of
> >+change in the cipher SHOULD then in the future be tied to semantics of
> >+change in the KDF.  One KDF that might be considered for the purpose
> >+might be a PRF with 256-bit output (perhaps HMAC-SHA256, if it is then
> >+still considered a secure PRF), which could then be used to derive the
> >+OWAMP-Test session keys from the OWAMP-Control session key by using
> >+the OWAMP-Control session key as the HMAC key and the SID as HMAC
> >+message.
> >+
> >
> >Is this satisfactory?
>
> Okay, we can consider this point resolved.
>
> > > I see no problem with HMAC-SHA1, which is readily available from
> > > many sources.
> > >
> > > Your salt and count recommendations seem fine to me.
> >
> >I will plan make the following change and report to you:
> >
> >- PKCS #5 PBKDF2, with HMAC-SHA1, with salt and count selected by the
>
> s/PBKDF2, with HMAC-SHA1/using PBKDF2 with HMAC-SHA1/
>
> >  server and transmitted in the clear (salt being a pseudo-random
> >  16-octet field generated using an unspecified mechanism and count
> >  being a server configuration parameter, always a power of 2, that
> >  MUST be at least 1024 and SHOULD be increased as more computing
> >  power becomes common)
>
> I look forward to the text.
>
> > > I believe that you ned to talk about the IV being in the clear, and
> > > that subsequent octets are encrypted in CBC.  You might want to look
> > > at the IPsec ESP document for an example.
> >
> >Sorry about letting this one linger.  I have made the following change:
> >
> >--- draft-ietf-ippm-owdp.nroff  9 Nov 2005 04:00:41 -0000      1.141
> >+++ draft-ietf-ippm-owdp.nroff  9 Nov 2005 04:28:21 -0000      1.142
> >@@ -671,6 +671,11 @@
> >  The client encrypts its stream using Client-IV.
> >  The server encrypts its stream using Server-IV.
> >
> >+The IVs themselves are transmitted in cleartext.  Encryption starts
> >+with the block immediately following the block containing the IV.  The
> >+two streams are encrypted indepedently, each with its own IV, but
> >+using the same key (the session key).
> >+
> >
> >Is the clarification satisfactory?
>
> I think so.  I'll need to see the whole section when the other issues
> are resolved.  This is "wrong" if you accept the AES-CCM or AES-GCM
> recommendation.  Alternatively, using HMAC-SHA1 for ICV calculation
> will preserve this structure.
>
> >The one remaining issue I am aware of is the replacement of IZP with
> >AES-CCM or AES-GCM.  I would like first to understand the BCP 107
> >concerns.
>
> I hope you are now able to attack this one.
>
> Russ
>

[Ballot discuss]
The protocol requires automated key management under the soon-to-
  be-published BCP 107 (see draft-bellovin-mandate-key-mgmt-03).  This
  BCP requires automated key management under most situations and
  requires explicit justification when manual key management is used.
  The use of TLS to protect the command channel appears to be a
  straightforward solution.  If this is adopted, please consider DTLS
  for the test traffic.  One approach that deserves consideration is
  the transfer of a random secret value on the command channel, and
  then the use of this (now shared secret) value in DTLS with PSK key
  management.  The PSK document from the TLS WG is in IESG Evaluation,
  so it will be finished soon.

RH>I understand why DTLS was not selected for the data channel.  This
RH>is clear from the new text in section 6.  However, I do not see
RH>where the comment about automated key management is handled.  Did
RH>I miss it?
RH>
RH>The manual key management seems to be among a large number of
RH>parties.  draft-bellovin-mandate-keymgmt-03 says that automated
RH>key management is needed when:
RH>
RH>  A party will have to manage n^2 static keys, where n may become
RH>  large.

  The structure is tightly coupled with a single encryption algorithm.
  While I have every confidence in AES, it is highly desirable for
  protocols to be algorithm independent.  At a minimum, the protocol
  ought to carry an algorithm identifier in the first message sent to
  the server.  If the server cannot support the requested algorithm,
  then a error is provided (which might include a list of the algorithms
  that the server does support), and then the TCP connection is closed.
  Given the structures used in this protocol, major changes would be
  needed to accomodate a cipher that has a block size other than 128
  bits.  At a minimum, I would like the security considerations to
  acknowledge this design decision.  There are several ciphers with
  128-bit blocks, so it is still straightforward to make this protocols
  less dependent on AES.  AES ought to be the mandatoy to implement
  cipher.

RH>Section 6.7 is very good, but it does not go far enough.  The
RH>means for supporting a different encryption algorithm are included;
RH>however, it does not show how the initiator and responder would
RH>each learn the algorithms supported by the other.  Rollback
RH>attacks must be prevented too.

  Further, the session-key needs to support more than 128-bit AES keys.
  Since the protocol designers prefer fixed-length messages, this might
  be accomplished by providing a very long session key that is truncated
  for use with a particular cipher.  This is the approach used in EAP.
  This approach would accomodate AES-128, AES-192, AES-256, Camellia,
  SEEK, and many other block ciphers.

RH>Section 6.7 addresses this concern, but not in my preferred manner.

  A key derivation function (KDF) will also be needed.  Currently, the
  KDF is the encryption of the 16-octet SID by the session key.  A KDF
  that is capable of generating keys of differing sizes is needed.

RH>Given the approach taken in section 6.7, this is probably not a
RH>an issue.

  Section 3.1 says:
  >
  > If the shared secret is provided as a passphrase (typical for the
  > case of interactive tools) then the MD5 sum [RFC1321] of the
  > passphrase (without possible newline character(s) at the end of the
  > passphrase) MUST be used as the key for encryption by the client and
  > decryption by the server (the passphrase also MUST NOT contain
  > newlines in the middle).  This ensures that a passphrase used to
  > generate a secret in one implementation will generate the same
  > secret in another implementation and the implementations will,
  > therefore, be interoperable.
  >
  I understand the need to specify a means of translating a pass-
  phrase into a shared secret.  However, PKCS #5 (see RFC 2898) is the
  normal way that this is done.  If PKCS #5 (with PBKDF2) is  not
  adopted, then the security considerations ought to explain why this
  algorithm is more appropriate for this protocol.  Further, given
  the environment already requires tight time sync, the time could
  be used as a salt in the key derivation.  Obviously, the use of a
  very finer grained time would be problematic, but the year, month,
  day and hour in UTC would probably be very useful.

RH>This comment seems to have been ignored.

  The document provides an incorrect description of how secret keys
  work.  It says, "secret keys, rather than having the low entropy
  typical of passwords, are suitable for use as AES keys," and then
  goes on to describe how to generate a key from a password.  Such a
  key is going to have exactly the same amount of entropy as the
  password from which it is generated.

RH>This comment seems to have been ignored.

  The IZP integrity mechanism is very flawed.  Since CBC will sync
  after two blocks, it does not provide the intended message integrity
  and authentication that is intended.  I am not sure that this can be
  exploited given the current message layouts; I did not take the time
  to look for places where adjacent blocks contain data that an attacker
  might want to tamper.  Regardles, future extensions to the protocol
  might add fields to the messages that make this attack simple.  In
  short, the use of CBC mode with a constant to provide integrity
  protection is not acceptable.  Consider using AES-CCM or AES-GCM when
  confidentiality and integrity are both needed.

RH>The explanation is improved, but the mechanism is not changed to
RH>correct the concern that was raised.

  The discussion of encryption is not clear.  For example, the
  discussion of the Request-Session message does not state which part
  of the message is encrypted.  The IV preccessing is very unclear.
  Test vectors and clear descriptions are needed.

RH>This comment seems to have been ignored.

  Section 6 includes a discussion of why TLS was not used.  I can see
  the resons for not using TLS for the test protocol.  However, these
  resons do not extend to DTLS.  Further, TLS seems like a good choice
  for the protection of the command channel.  The use of TLS would
  address the concerns about automated key management and would provide
  sound integrity protection for the command channel.

RH>Resolved.

  Please reference RFC 4086 (a.k.a. BCP 106) instead of RFC 1750.

RH>Resolved.

[Ballot comment]
The 2nd paragdraph of section 2 says:
  >
  > The initiator of the measurement session establishes a TCP connection
  > to a well-known port on the target point and this connection remains
  > open for the duration of the OWAMP-Test sessions.  IANA will be
  > requested to allocate a well-known port number for OWAMP-Control
  > sessions.  An OWAMP server SHOULD listen to this well-known port.
  >
  I think that this paragraph should be written in an manner that makes
  it simple for implementors once IANA assignes the well-known port number.
  For, example, the text could say: "The initiator of the measurement
  session establishes a TCP connection to a well-known port XX on the
  target and this connection remains open for the duration of the
  OWAMP-Test sessions. [RFC Editor: Please replace 'XX' with the value
  assigned by IANA.]"

RH>Resolved.

  The well-known port concern surfaces several other places.  I will not
  point out each one, but I belive that the reader will be will served
  if each of them is handled as described above.

RH>Resolved.

  Some protocol messages do not have names.  This makes it difficult to
  comment on the protocol.  For example, the message sent by the
  Control-Client or a Fetch-Client as part of session set-up is
  discussed on page 8.  The protocol message has a clear description,
  but without a protocol message name, it takes a lot of words to
  reference a particular message.  Solving this is not a big deal.
  For example, the document currently says:
  >
  > Otherwise, the client MUST respond with the following message:
  >
  This could be replaced with:
  >
  > Otherwise, the client MUST respond with the Set-Up-Response message:

RH>No changes in this area.

  I wish that the 'Username' field had a different name.  It does not
  name a user.  It names a shared secret.  In other protocols, this
  would be called a key identifier (KeyID).

RH>Resolved.

[Ballot discuss]
The protocol requires automated key management under the soon-to-
  be-published BCP 107 (see draft-bellovin-mandate-key-mgmt-03).  This
  BCP requires automated key management under most situations and
  requires explicit justification when manual key management is used.
  The use of TLS to protect the command channel appears to be a
  straightforward solution.  If this is adopted, please consider DTLS
  for the test traffic.  One approach that deserves consideration is
  the transfer of a random secret value on the command channel, and
  then the use of this (now shared secret) value in DTLS with PSK key
  management.  The PSK document from the TLS WG is in IESG Evaluation,
  so it will be finished soon.

RH>I understand why DTLS was not selected for the data channel.  This
RH>is clear from the new text in section 6.  However, I do not see
RH>where the comment about automated key management is handled.  Did
RH>I miss it?

  The structure is tightly coupled with a single encryption algorithm.
  While I have every confidence in AES, it is highly desirable for
  protocols to be algorithm independent.  At a minimum, the protocol
  ought to carry an algorithm identifier in the first message sent to
  the server.  If the server cannot support the requested algorithm,
  then a error is provided (which might include a list of the algorithms
  that the server does support), and then the TCP connection is closed.
  Given the structures used in this protocol, major changes would be
  needed to accomodate a cipher that has a block size other than 128
  bits.  At a minimum, I would like the security considerations to
  acknowledge this design decision.  There are several ciphers with
  128-bit blocks, so it is still straightforward to make this protocols
  less dependent on AES.  AES ought to be the mandatoy to implement
  cipher.

RH>Section 6.7 is very good, but it does not go far enough.  The
RH>means for supporting a different encryption algorithm are included;
RH>however, it does not show how the initiator and responder would
RH>each learn the algorithms supported by the other.  Rollback
RH>attacks must be prevented too.

  Further, the session-key needs to support more than 128-bit AES keys.
  Since the protocol designers prefer fixed-length messages, this might
  be accomplished by providing a very long session key that is truncated
  for use with a particular cipher.  This is the approach used in EAP.
  This approach would accomodate AES-128, AES-192, AES-256, Camellia,
  SEEK, and many other block ciphers.

RH>Section 6.7 addresses this concern, but not in my preferred manner.

  A key derivation function (KDF) will also be needed.  Currently, the
  KDF is the encryption of the 16-octet SID by the session key.  A KDF
  that is capable of generating keys of differing sizes is needed.

RH>Given the approach taken in section 6.7, this is probably not a
RH>an issue.

  Section 3.1 says:
  >
  > If the shared secret is provided as a passphrase (typical for the
  > case of interactive tools) then the MD5 sum [RFC1321] of the
  > passphrase (without possible newline character(s) at the end of the
  > passphrase) MUST be used as the key for encryption by the client and
  > decryption by the server (the passphrase also MUST NOT contain
  > newlines in the middle).  This ensures that a passphrase used to
  > generate a secret in one implementation will generate the same
  > secret in another implementation and the implementations will,
  > therefore, be interoperable.
  >
  I understand the need to specify a means of translating a pass-
  phrase into a shared secret.  However, PKCS #5 (see RFC 2898) is the
  normal way that this is done.  If PKCS #5 (with PBKDF2) is  not
  adopted, then the security considerations ought to explain why this
  algorithm is more appropriate for this protocol.  Further, given
  the environment already requires tight time sync, the time could
  be used as a salt in the key derivation.  Obviously, the use of a
  very finer grained time would be problematic, but the year, month,
  day and hour in UTC would probably be very useful.

RH>This comment seems to have been ignored.

  The document provides an incorrect description of how secret keys
  work.  It says, "secret keys, rather than having the low entropy
  typical of passwords, are suitable for use as AES keys," and then
  goes on to describe how to generate a key from a password.  Such a
  key is going to have exactly the same amount of entropy as the
  password from which it is generated.

RH>This comment seems to have been ignored.

  The IZP integrity mechanism is very flawed.  Since CBC will sync
  after two blocks, it does not provide the intended message integrity
  and authentication that is intended.  I am not sure that this can be
  exploited given the current message layouts; I did not take the time
  to look for places where adjacent blocks contain data that an attacker
  might want to tamper.  Regardles, future extensions to the protocol
  might add fields to the messages that make this attack simple.  In
  short, the use of CBC mode with a constant to provide integrity
  protection is not acceptable.  Consider using AES-CCM or AES-GCM when
  confidentiality and integrity are both needed.

RH>The explanation is improved, but the mechanism is not changed to
RH>correct the concern that was raised.

  The discussion of encryption is not clear.  For example, the
  discussion of the Request-Session message does not state which part
  of the message is encrypted.  The IV preccessing is very unclear.
  Test vectors and clear descriptions are needed.

RH>This comment seems to have been ignored.

  Section 6 includes a discussion of why TLS was not used.  I can see
  the resons for not using TLS for the test protocol.  However, these
  resons do not extend to DTLS.  Further, TLS seems like a good choice
  for the protection of the command channel.  The use of TLS would
  address the concerns about automated key management and would provide
  sound integrity protection for the command channel.

RH>Resolved.

  Please reference RFC 4086 (a.k.a. BCP 106) instead of RFC 1750.

RH>Resolved.

[Ballot comment]
I'm in strong agreement with Russ's security comments.  We workedn
together to come up with a common understanding of the security
concerns about this document.  I do not have any concerns with this
document outside those concerns.

[Ballot discuss]
The protocol requires automated key management under the soon-to-
  be-published BCP 107 (see draft-bellovin-mandate-key-mgmt-03).  This
  BCP requires automated key management under most situations and
  requires explicit justification when manual key management is used.
  The use of TLS to protect the command channel appears to be a
  straightforward solution.  If this is adopted, please consider DTLS
  for the test traffic.  One approach that deserves consideration is
  the transfer of a random secret value on the command channel, and
  then the use of this (now shared secret) value in DTLS with PSK key
  management.  The PSK document from the TLS WG is in IESG Evaluation,
  so it will be finished soon.

  The structure is tightly coupled with a single encryption algorithm.
  While I have every confidence in AES, it is highly desirable for
  protocols to be algorithm independent.  At a minimum, the protocol
  ought to carry an algorithm identifier in the first message sent to
  the server.  If the server cannot support the requested algorithm,
  then a error is provided (which might include a list of the algorithms
  that the server does support), and then the TCP connection is closed.
  Given the structures used in this protocol, major changes would be
  needed to accomodate a cipher that has a block size other than 128
  bits.  At a minimum, I would like the security considerations to
  acknowledge this design decision.  There are several ciphers with
  128-bit blocks, so it is still straightforward to make this protocols
  less dependent on AES.  AES ought to be the mandatoy to implement
  cipher.

  Further, the session-key needs to support more than 128-bit AES keys.
  Since the protocol designers prefer fixed-length messages, this might
  be accomplished by providing a very long session key that is truncated
  for use with a particular cipher.  This is the approach used in EAP.
  This approach would accomodate AES-128, AES-192, AES-256, Camellia,
  SEEK, and many other block ciphers.

  A key derivation function (KDF) will also be needed.  Currently, the
  KDF is the encryption of the 16-octet SID by the session key.  A KDF
  that is capable of generating keys of differing sizes is needed.

  Section 3.1 says:
  >
  > If the shared secret is provided as a passphrase (typical for the
  > case of interactive tools) then the MD5 sum [RFC1321] of the
  > passphrase (without possible newline character(s) at the end of the
  > passphrase) MUST be used as the key for encryption by the client and
  > decryption by the server (the passphrase also MUST NOT contain
  > newlines in the middle).  This ensures that a passphrase used to
  > generate a secret in one implementation will generate the same
  > secret in another implementation and the implementations will,
  > therefore, be interoperable.
  >
  I understand the need to specify a means of translating a pass-
  phrase into a shared secret.  However, PKCS #5 (see RFC 2898) is the
  normal way that this is done.  If PKCS #5 (with PBKDF2) is  not
  adopted, then the security considerations ought to explain why this
  algorithm is more appropriate for this protocol.  Further, given
  the environment already requires tight time sync, the time could
  be used as a salt in the key derivation.  Obviously, the use of a
  very finer grained time would be problematic, but the year, month,
  day and hour in UTC would probably be very useful.

  The document provides an incorrect description of how secret keys
  work.  It says, "secret keys, rather than having the low entropy
  typical of passwords, are suitable for use as AES keys," and then
  goes on to describe how to generate a key from a password.  Such a
  key is going to have exactly the same amount of entropy as the
  password from which it is generated.

  The IZP integrity mechanism is very flawed.  Since CBC will sync
  after two blocks, it does not provide the intended message integrity
  and authentication that is intended.  I am not sure that this can be
  exploited given the current message layouts; I did not take the time
  to look for places where adjacent blocks contain data that an attacker
  might want to tamper.  Regardles, future extensions to the protocol
  might add fields to the messages that make this attack simple.  In
  short, the use of CBC mode with a constant to provide integrity
  protection is not acceptable.  Consider using AES-CCM or AES-GCM when
  confidentiality and integrity are both needed.

  The discussion of encryption is not clear.  For example, the
  discussion of the Request-Session message does not state which part
  of the message is encrypted.  The IV preccessing is very unclear.
  Test vectors and clear descriptions are needed.

  Section 6 includes a discussion of why TLS was not used.  I can see
  the resons for not using TLS for the test protocol.  However, these
  resons do not extend to DTLS.  Further, TLS seems like a good choice
  for the protection of the command channel.  The use of TLS would
  address the concerns about automated key management and would provide
  sound integrity protection for the command channel.

  Please reference RFC 4086 (a.k.a. BCP 106) instead of RFC 1750.

[Ballot comment]
The 2nd paragdraph of section 2 says:
  >
  > The initiator of the measurement session establishes a TCP connection
  > to a well-known port on the target point and this connection remains
  > open for the duration of the OWAMP-Test sessions.  IANA will be
  > requested to allocate a well-known port number for OWAMP-Control
  > sessions.  An OWAMP server SHOULD listen to this well-known port.
  >
  I think that this paragraph should be written in an manner that makes
  it simple for implementors once IANA assignes the well-known port number.
  For, example, the text could say: "The initiator of the measurement
  session establishes a TCP connection to a well-known port XX on the
  target and this connection remains open for the duration of the
  OWAMP-Test sessions. [RFC Editor: Please replace 'XX' with the value
  assigned by IANA.]"

  The well-known port concern surfaces several other places.  I will not
  point out each one, but I belive that the reader will be will served
  if each of them is handled as described above.

  Some protocol messages do not have names.  This makes it difficult to
  comment on the protocol.  For example, the message sent by the
  Control-Client or a Fetch-Client as part of session set-up is
  discussed on page 8.  The protocol message has a clear description,
  but without a protocol message name, it takes a lot of words to
  reference a particular message.  Solving this is not a big deal.
  For example, the document currently says:
  >
  > Otherwise, the client MUST respond with the following message:
  >
  This could be replaced with:
  >
  > Otherwise, the client MUST respond with the Set-Up-Response message:

  I wish that the 'Username' field had a different name.  It does not
  name a user.  It names a shared secret.  In other protocols, this
  would be called a key identifier (KeyID).

[Ballot comment]
Review comments from a AAA-Doctor (Jari) and author/editor has
agreed (to at least part of it) and I think has revised text.

--- comments from Jari follows:

I read this draft based on Bert's request.
Here are my comments:

Overall:

I like this draft, its very exciting technology. I'm eager to
start testing it, when it becomes available on the types
of machines that I use.

The draft is mostly OK. I noted some nits. The main
technical concern I have is tighting up the denial-of-service
protection text.

Note that I'm not a IPPM expert and this is the first time I
read this draft. I may have missed something obvious. If
so, let me know.

Technical:

> 6.2. Preventing Third-Party Denial of Service
>
>    OWAMP-Test sessions directed at an unsuspecting party could be used
>    for denial of service (DoS) attacks.  In unauthenticated mode,
>    servers SHOULD limit receivers to hosts they control or to the OWAMP-
>    Control client.

The above text is good, but I would like to tighten the rule
a little bit. Maybe by adding this:

  "Specifically, unless otherwise configured, the default behavior
    of servers MUST be to decline requests where the Receiver Address
    field is not equal to the address that the control connection
    was initiated from. Given the TCP handshake procedure and sequence
    numbers in the control connection, this ensures that the hosts that
    make such requests are actually those hosts themselves, or at
    least on the path towards them. If either this test or the handshake
    procedure were omitted, it would become possible for attackers
    anywhere in the Internet to request large amounts of test packets
    be directed against victim nodes somewhere else.

    In any case, servers MUST decline all requests where the Sender
    Address is not either the server's own address or the address of
    a node that it controls; OWDP-Test packets with a given source
    address can only be sent from the node that has been assigned
    that address."

>    payload of a single ATM cell (this is only achieved in
>    unauthenticated and encrypted modes).

I have to wonder whether this should read "unauthenticated
and unencrypted", but I'm reading on... Section 4.1.2 shows
the authenticated and encrypted modes to have the same
format, and neither EBC or CBC modes should add any
overhead. What am I missing? Why does an encrypted mode
packet fit an ATM cell but an authenticated does not? And
I don't see a MAC field anywhere.

>    The protocol does not carry any information in a natural language.

I would actually prefer the Username field to be in UTF-8, rather
than Octet. (It would be even better if it were possible to have
longer than 16 byte usernames, in case someone later wants to
use AAA or something for the shared secret management of
OWDP. But I can see that changing that would be a too big change
for the protocol formats.)

> 7. IANA Considerations
>
>    IANA is requested to allocate a well-known TCP port number for the
>    OWAMP-Control part of the OWAMP protocol.

How about Accept values? Might make sense to have a rule about adding
those. Say, Standards Action.

Editorial:

>  hosts
>    increasingly have available to them very accurate time
>    sources

Maybe "very accurate time sources are increasingly available
to hosts", which sounds better to me (but I'm not a native speaker).

--Jari

[Ballot comment]
Frome review by Mark Allman.The first and last points certainly need attention.

  + On page 8 it would seem like the mode value should be chosen from
    the mode values advertised in the message given on page 7.  Right?
    I think it'd be good to say this.

  + The MBZ fields are often mentioned in the context of filling them in
    with a "string" of zeros.  I think a better word could be chosen
    here.  I understand that we're not really placing a string in the
    packet.  But, more explicitly stating that each bit must be of value
    zero would be nice.  (This is a nit and maybe something that could
    be clarified by the RFC editor.)

  + Another nit... "uptime" seems like the wrong term.  I think
    "StartTime" would be better since this is an absolute time and not a
    relative time.  I.e., it's when the process started, not how long it
    has been running.  (Right?)  (Again, could be fixed with an RFC
    editor note, I am sure.)

  + I am baffled as to the purpose of the IZP field.  I think there
    needs to be a better paragraph as to what the purpose of this field
    really is.

[Ballot comment]
Intro:
"The IETF IP Performance Metrics (IPPM) working group has proposed
draft standard metrics for one-way packet delay [RFC2679] and loss
[RFC2680] across Internet paths."

2679 and 2680 are PROPOSED (not draft) standards.