I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

The summary of the review is Not ready. (However, as this is an early
review, this should not be unexpected.)

Here are some concerns, comments, and questions.

(1) With the current network flows, there’s some doubt that flows will
actually pass one or more firewalls between the client and server.  Section
3 begins by saying

  “One end-point takes the role of server, awaiting connection requests
   on a well-known port from the other end-point, the client.”

As I understand the above text, the client sends from a well-known port
rather than the conventional method of a server opening a well-known port
and listening on it. So a firewall in front of the client may open an
inbound pinhole of “ephemeral port -> well-known port” (since the client
sent a message from "well-known port -> ephemeral port").  This ought to
be sufficient, from the client’s perspective.  But Security Consideration
also says this:

     “Firewalls protecting each host can both continue to do
      their job normally.  This aspect is similar to many other test
      utilities available.”

I don’t understand how any reasonable firewall policy would be defined on
the server side, when a client is initiating a protocol to a server’s
ephemeral port. That is, ephemeral ports are usually blocked unless the
server sends an outgoing message from it.  So how the firewall policy is
intended to work needs to be described much more clearly. For example, if
there is a co-dependancy that a firewall administrator be required to open
all of the ephemeral ports that the server might use in advaance, that
needs to be stated.  (Having said that, such a policy might very well be
unacceptable to the firewall administrator.) Or if the server is never
expected to have a firewall in front of it this last quoted sentence needs
to be changed to say that.

(2) Can you describe the server’s behavior more clearly, as to how as a
server it listens on an ephemeral port, a range of ephemeral ports, or
whatever strategy you have in mind? This seems backwards from the usual
flows of client using an ephemeral port to contact a server on a well-known
port. The last quote above includes the sentence:

    "This aspect is similar to many other test utilities available.”

and seems to indicate that there are existing examples of how this works.
Do these “other test utilities” really have these same data flows? If so,
then please describe how an existing firewall placed in front of the server
works when the server is receiving packets on ephemeral ports.

(3) The draft seems to define message authentication only for the Setup
Request and Response messages. In this situation I assume the goal is to
authenticate a peer with the goal of verifying peer authorization only.
That is, when only these messages are authenticated then there is no 
real goal of knowing whether the measurements later sent are accurate
since an attacker can theoretically modify messages in transit. The
other messages seem to lack a authDigest field.  

But Security Considerations does state

     “Client-server authentication and integrity protection for
       feedback messages conveying measurements is RECOMMENDED. “

So is message authentication intended as an option for all messages  but
the PDUs in -01 just doesn’t show the authDigest field yet? If so, it would
be good to explicitly add them.

In any case, Security Considerations needs to state just what the security
goals are when only some messages are authenticated, and defend why that
is acceptable. For example, I understand that adding message authentication
processing to feedback messages generated by a data plane can affect the
quality of the measurements, and some people might accept that measurements
are not necessarily correct if they have been tampered by an attacker.

(4) Section 3 says

  “If the Setup Request must be rejected (due to any of the reasons in
   the Command response codes listed below), a Setup Response SHALL be
   sent back to the client with a corresponding command response value
   indicating the reason for the rejection.”

I note that some reasons have to do with the server not being able to
authenticate the client. Assuming the server has an open port or set of
ports that any network device can target, this seems like an opportunity
for an arbitrary network device spoofing a victim IP address to use the
server as a DDoS “bounce” address targeting that victim. That is, the
attacker would create a message with the victim's IP address as source
address, and use a destination address of the measurement server, causing
the measurement server to reply to the intended victim.

A more secure policy would be to silently drop messages that cannot be
authenticated, even though this makes diagnosing the failure harder. The
idea of silently dropping message is mentioned on Page 9, including when
“a directed attack has been detected”, but as these attacks can do a lot
of damage before being detected it’s not really sufficient to just say
that “Attack detection is beyond the scope of this specification”. Yes,
that’s true, but causing a vulnerability in protocol design and assuming
some other system will detect and block it is not sufficient. This is 
why it's important to silently drop messages that fail authentication.
Otherwise, the remaining threat needs to be defended in Security 
Considerations.

(5) Section 5.1 begins by saying

  “When the client receives the Setup response from the server it first
   checks the cmdResponse value.”

Actually, checking the validity of the  authDigest field in the Setup
Response should be the first step. Otherwise, the cmdResponse value is not
known to be trustable.

(6) Section 6.1 does mention using the “Authentication mode, and Authentication
time stamp” in the context of the Test Activation Request. Can you clarify
how these data fields are used? Would it be reasonable to add these fields
to the  Test Activation Request and Response messages, since they seem to
be control plane messages rather than data plane messages?

(7) Section 7.2. There is a note that protection from bit errors could
be desirable. I note that message authentication of these messsage would
ensure that bit errors are detected.

(8) Section 8 says

  “When the client receives a load or status PDU with the STOP1
   indication, it SHALL finalize testing, ….”

Stopping a test seems like an important message to verify that it actually
came from the server rather than an attacker that doesn’t want the measurement
to happen. (Maybe the measurement would result in discovery that the attcker
is using some resources, or some such.) An authDigest field would resolve
that threat.

(9) Section 10 says

     “Cooperating source and destination hosts and agreements to test
       the path between the hosts are REQUIRED.”

I assume this cooperation is determined by authorization through the use
of the authDigest field and the known identity associated with the key used to
create the authDigest field. If so this sentence should say this more
explicitly.

(10) The authDigest usage needs to be defined, i.e. what bytes are included
in the digest, etc.  Also the choices that can be configured for authMode
should be stated. Also, there should be a registry of authentication methods
for interoperabilty.

(11) The use of authUnixTime is not stated anywhere. Why is time important,
how does a receiver determine if the time is accuracy given latency in the
network, and what threats does it resolve?

Thanks, 
Brian