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 Has Nits.

This document describes a new method and set of PDUs for measuring
the performance of UDP traffic. It defines methods of message
authentication, and one method of encrypting control and status
messages. Encryption of data messages is not included, as it is
expected to reduce the accuracy of the performance measurements.

I have reviewed this document twice before, and have just a few
minor comments and suggestions.

Section 3, list item 1. I’m wondering why the name of the exchange
described in this list item (i.e., Setup Request and Response
Exchange) was removed? The name seems to still be used elsewhere
in the document, so would be helpful to state it here.

Section 4.2, list item 1. This unauthenticated mode is stated as
“shall only be allowed when all other modes requiring authentication
(or Partial Encryption) are blocked or unavailable for use.” The
words “are blocked” were added here, which I believe is unwise. A
typical method by a on-path attacker is to “downgrade” the security
of a session by blocking packets. I would recommend removing these
words. Note also that the next sentence says “This mode is  intended
for a lab or limited domain”, where I would expect blocked packets
to be a network error that can be (and should be) fixed, and can
be fixed by the same administrators as are running the test. So the
necessity of including “are blocked” seems wholly unnecessary.
Alternatively, text needs to be added in Security Considerations
describing this threat and under what conditions the threat is
acceptable.

Section 4.2.4. This mode is titled “Optional Partial Encryption of
Control and Status”. The “Partial” can be misleading a reader into
believing that only part of the control or status portions of the
message is encrypted. But if I understand the payloads properly,
the entire payload prior to the authentication state is encrypted,
leaving only the authentication state in the clear. Leaving the
authentication state in the clear is necessary since the receiver
will check authentication before decryption. I would suggest removing
the world “Partial”.

Section 4.2.4. This section defines one encryption method. This
definition is fine. But over time the strength of encryption methods
tends to degrade, and new definitions need to be adopted. Protocols
thus need to be designed with algorithm agility. In fact the document
does provide for algorithm agility due to the ability to define new
Modes in the “Test Setup PDU Authentication Mode Registry”.  However,
this is not obvious to a reader. I would suggest adding a note,
either in this section or in Security Considerations, that says
something like “Alternate encryption and/or authentication modes
provide for algorithm agility by defining a new Mode following the
rules of the “Test Setup PDU Authentication Mode Registry”.”