Reviewer: David Waltermire Review result: Has Issues 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 Ready with issues. In general this document is clearly-written and well-organized. It was a fun read overall. I have the following concerns with the draft: ----------------------------------------------------------- Section 2.1: You should use text from RFC8174 to indicate that lowercase versions of the keywords are not normative. Something like the following would work: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Section 4.1.3.1: "it can be long-lived with no need for rekeying" Small is open to interpretation. It would be useful to include some guidance on the expected amount of data to be exchanged before rekeying would be needed, or why this is a practical impossibility. Section 5.3.2 and 5.3.3: In the paragraph on TRANSPORT_FORMAT_LIST, it would be good to document the specific ESP parameter value to be used from: https://www.iana.org/assignments/hip-parameters/hip-parameters.xml#transport-modes. This will remove any ambiguity. Section 6.6: In items #5 and #6, what is "an acceptable time span"? Some guidance here would be helpful. I believe this is discussed earlier in the draft. Perhaps a reference back may provide some clarity? Section 6.9: In #1, under what circumstances would the NOTIFY packet not be dropped silently? Why is this not a MUST? Some explanation would be useful here. In general, many of the SHOULDs in the section 6 subsections, could use further justification. Section 8: What is "a reasonable delta time"? Some guidance here would be useful. Section 9 (Security Considerations): "The puzzle mechanism using CMAC may need further study regarding the level of difficulty." Study of what? Is the concern here that the impact on constrained devices at a higher level of difficulty is not well understood? Or is this concern around identifying best practices around raising the difficulty under specific conditions? A sentence or two on this would be helpful for the reader to better understand the issue. I don't see a mention of the non-protected Host Identity issue from section 1.1 here. With regards to the 4th bullet, the text in section 3 should be referenced regarding HIT collisions. (nit)-> Referencing back to the relevant sections for the other bullets may also be useful. >From section 5.3.1, I don't see a mention of the issues around dealing with I1 storms addressed here. Section 10: It can be useful for IANA to reference the specific registry by name and URL in the IANA considerations. It can also be useful to include the actual table in the IANA considerations section. These are embedded in section 5 in the current document. Suggest moving these tables to the IANA consideration section. I found the following nits in the draft: ------------------------------------------------- Section 1.1: In the text "any signaling that indicates such anonymity should be ignored" it would be useful to provide an example of such signaling. /may carry data payload/may carry a data payload/ The packets are referred to as 1st, 2nd, 3rd, and 4th here, and as I1, R1, I2, and R2 in section 4. Consider use a consistent naming approach throughout this document to improve clarity. Section 1.2: Section 8 is not included in this summary. Suggest adding a sentence about it. (nit) Section 10 is not linked as well. Section 2: /Terms and Definitions/Terms, Notation, and Definitions/ Section 3: "other methods are used to map the data packets to the corresponding HIs" What are these other methods? What if ESP is not used and the SPI is not an option? Section 4.1.2.3: In the diagram, I think there is a missing arrow between I2-SENT and R2-SENT. Please double check. Also, this diagram is far from simple. Maybe name this section "HIP State Diagram"? Section 4.1.3.2: "Even though this input" Please clarify the "this" indefinite article. Section 4.1.4: /This will limit state/Using non-volatile storage will limit state/ This section should reference section 6.11, since some of the content is duplicated there. Section 5.2.3: /It is defined in/The HOST_ID parameter is defined in/ Section 5.2.5: /at least 64 bit/at least 64 bits/ Update the reference "#I and the puzzle solution #J (see [RFC7401])" to point to section 4.1.2 in RFC7401. Section 5.3.2: The discussion of difficulty K touches on a local policy issue that is discussed in section 7. It could be useful to reference section 7 from here. Update "(see [RFC7401])" to point to section 4.1.2 in RFC7401. /based on which it chose the ECDH/based on which the Responder chose the ECDH/ Regards, David Waltermire
