Document: draft-ietf-ippm-capacity-protocol Title: Test Protocol for One-way IP Capacity Measurement Reviewer: Brian Weis Review result: Has Nits 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”.” -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
