Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)
Note: This ballot was opened for revision 06 and is now closed.
(Sam Hartman) (was Discuss) Yes
A lot of effort is spent supporting middleboxes that want to verify HIP packets: signatures are required after key material is available and especially on update packets. As an option this seems like a reasonable design choice. However as a requirement this seems poorly considered as it significantly increases the computational complexity of HIP. NATs get along today without verifying state. I think there are many cases where state verification will not be required for HIP. I'd like to thank the HIP community for an excellent set of documents for spending a lot of time working with the security directorate to get their comments resolved. I'd also like to thank the many security directorate members who provided reviews.
(Mark Townsley) Yes
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Russ Housley) No Objection
Comment (2007-04-19 for -)
It is possible to run vanilla IPsec and HIP on the same node and get the intended security services applied to the intended traffic if one is careful about configuration. The security services are present, and it appears to be possible to use a HIP-unaware IPsec to do the HIP ESP processing. One should worry about whether there is a possibility of a HIT conflicting with an actual IPv6 address as the technique advocated for a HIP-unaware IPsec implementation apparently has HITs masquerade as IPv6 addresses for IPsec processing. Since HIP and IPsec share a common SPI space, and traffic on any HIP SPI completely bypasses IPsec policy. (Think about Steve Kent's usual rant about IPsec being more than just a means to apply cryptographic security mechanisms to traffic.) The assurances that IPsec provides are easily broken with HIP, since inbound HIP traffic bypasses the IPsec SPD and gets handed directly to HIP, which logically has its own SPD. It is not clear to me exactly how to avoid this situation, or what to add to the document to warn about this security consideration. A long discussion may be needed. Since the document is intended for Experimental RFC, this may be an acceptable situation, but this must be resolved for this document to transition to the standards track.
(Chris Newman) No Objection
(Tim Polk) (was No Record, No Objection) No Objection
Magnus Westerlund No Objection
Comment (2007-04-19 for -)
draft-ietf-hip-mm-05, Section 1: Finally, making underlying IP mobility transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and QoS. Transport-layer mobility triggers, and the proper transport response to a HIP mobility or multihoming address change, are outside the scope of this document. This is a important issue with mobility. I expect that there are some real considerations and hopefully solutions on this if and when HIP goes from experimental to standards track. But I do understand that it is likely to requrie also work on the transport side.