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. There are several points where the draft could be made more clear, some of which might impact security. I've listed those below, intermingled with some nits. Abstract and Section 1. "secure" is used where "authenticated" would be better, since this protocol does not provide any confidentiality services or encryption. RFC 4949 lists "message integrity code (MIC)" as a deprecated term, but this term is defined and used. In this case what is meant is "collision-resistant hash"; that phrase should be used in Sections 2 and 7. "Checksum" is an inappropriate term for a collision-resistant hash and it should be replaced in Section 4. For the security considerations section: does the hash need strong collision- resistance, or just second preimage resistance (also called weak collision-resistance)? Section 4 nits: "with help of MIC." -> "with the help of the MIC." "HIP DATA packet"-> "The HIP DATA packet" "Hash algorithm used to generate MIC is same " -> "The hash algorithm used to generate the MIC is the same " Section 4.1. I suggest emphasizing the requirement for the "Sequence Number" fields in distinct SEQ_DATA parameters to be distinct. Section 4.3. says "Payload Data 8 last bytes of the payload data over which the MIC is calculated. This field is used to uniquely bind PAYLOAD_MIC parameter to next header, in case there are multiple copies of same type." It seems to me that this uniqueness is not guaranteed, but that if the last-8-bytes is not unique, the MIC verification process would fail, but that there is no way that an attacker could exploit this fact. I suggest noting this property in the security considerations. Section 4.3: The PAYLOAD_MIC parameter has a field called "Payload MIC". It would be less confusing if the latter was called "MIC Value" or some other named that is distinct from the parameter name. Section 4.3 nit: "Identifies the data that protected by this MIC." add "is". Section 5.1 nit: "A HIP DATA packet MUST contain SEQ_DATA or ACK_DATA parameter if both parameters are missing then packet MUST be dropped as invalid." -> "A HIP DATA packet MUST contain either a SEQ_DATA or ACK_DATA parameter; if both parameters are missing, then the packet MUST be dropped as invalid." Section 5.2 says "The receiver MUST validate these MICs." It should also describe how to validate them, and S 5.3 would be a more appropriate place to detail that process. Section 5.2 says " ... no SEQ_DATA sequence number is reused before the receiver has closed the processing window for the previous packet using the same SEQ_DATA sequence number." Important question: what enables the receiver to tell the difference? I assume that there are some other fields (e.g. nonces) associated with the connection that might serve this purpose; if that is right, I suggest documenting that fact. regards, David