[ippm] Re: draft-ietf-ippm-capacity-protocol-14 ietf last call Secdir review

[[e-mail]]

Hi Brian,

thanks for your review and suggestions. The comments of Len and me are marked [Authors] in line below.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Brian Weis via Datatracker <[e-mail]> 
Gesendet: Dienstag, 29. April 2025 03:33
An: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Betreff: draft-ietf-ippm-capacity-protocol-14 ietf last call Secdir review

<snip>

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.

[Authors]: Thanks, sound....bullet point 1) ADD: Test Setup Request and Response:

-----------------

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.

[Authors]: NEW: ....(or Encryption) are unavailable for use.

----------------

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”.

[Authors]: Agreed.

-------------------

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”.”

[Authors]: Thanks, Security Section, ADD: Authentication and encryption methods and requirements steadily evolve. Alternate encryption and/or authentication modes provide for algorithm agility by defining a new Mode, whose support is indicated by an assigning a suitable "Test Setup PDU Authentication Mode Registry" value (see section  11.2.4).