[secdir] Review of draft-ietf-hip-hiccups-02

[David McGrew <[e-mail]>]

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