Last Call Review of draft-ietf-hip-hiccups-
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
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
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