On 09/09/2013 12:50 AM, Henderson, Thomas R wrote:
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.
I can think of two reasons that R1 should be supported in all devices:
Loss of state. If a device receives a datagram protected with a HIP SPI,
but lacks that SPI, perhaps this is due to loss of state by that device
(post reboot condition). Sending an I1 to the other party is the way to
recover state. Of course we allow for a receiver of an I1 to turn around
and send an I1 itself, forcing the R1 generation back on the party that
loss state.
Rekey. Key exhaustion MAY be addressed by an UPDATE or reruning HIP
exchange. Thus either party could force the exchange.
Just some quick thoughts.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
