Last week I published a new version of RFC5201-bis:
http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-13

This was mainly to address ID-nits and prepare the draft for the next stage of 
the review process.  However, I also received a number of comments from Anders 
Brandt (cc'ed) on the version-12 draft.  The purely editorial ones were 
included in version-13, but I decided to post a few for review on the list.

In the interest of expediency, I'd like to suggest that we aim for resolving 
all of these within the next two weeks.

1)  Section 4.1, the statement is made:

"As a result, it is believed that the HIP opportunistic mode is at least as 
secure as current IP."

Anders questioned what this statement means.  Further clarifications are needed 
here.

2) Section 5.1

"Since all HIP headers MUST contain the sender's and receiver's HIT fields, the 
minimum value for this field is 4, and conversely, the maximum length of the 
HIP parameters filed is (255*8-32 = 2008 bytes."

Anders asks "and IPv6 says 1280 bytes?" which I believe perhaps needs 
clarification or reference to the discussion on HIP fragmentation in Section 
5.1.3.

3) Section 5.3.2

"If the Responder uses the same DH keypair for multiple handshakes.  It must 
take care to avoid small subgroup attacks [RFC2785]."  These sentences are 
marked by Anders, perhaps for grammatical reasons (they should at least be 
combined).

4) Section 6.7.1, R1 Management

Anders asks whether it is allowed to make an initiator-only device, if there is 
a MUST in this section to be able to produce R1s.  I do not believe that the 
current protocol allows one to make an initiator-only device; perhaps this 
could be clarified.

- Tom
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec

Reply via email to