Sign in
Version 5.3.0, 2014-04-12
Report a bug

End-Host Mobility and Multihoming with the Host Identity Protocol

(was Discuss)
No Objection
(was No Record, No Objection)
(was No Objection)

Note: This ballot was opened for revision 04 and is now closed.

Summary: Needs a YES.

[Magnus Westerlund]

Comment (2007-04-19)

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.

[Russ Housley]

Comment (2007-04-19)

  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.

[Sam Hartman]

Comment (2007-04-18)

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.