Last Call Review of draft-ietf-hip-hiccups-

Request Review of draft-ietf-hip-hiccups
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-06-15
Requested 2010-06-03
Authors Gonzalo Camarillo, Jan Melen
Draft last updated 2010-06-20
Completed reviews Secdir Last Call review of -?? by David McGrew
Assignment Reviewer David McGrew 
State Completed
Review review-ietf-hip-hiccups-secdir-lc-mcgrew-2010-06-20
Review completed: 2010-06-20


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