Skip to main content

Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)


(Mark Townsley)

No Objection

(Chris Newman)
(Lisa Dusseault)
(Ron Bonica)
(Ross Callon)
(Tim Polk)


(David Ward)
(Jari Arkko)
(Lars Eggert)

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

Mark Townsley Former IESG member
Yes () Unknown

Sam Hartman Former IESG member
(was Discuss) Yes
Yes (2007-04-18) Unknown
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.
Chris Newman Former IESG member
No Objection
No Objection () Unknown

Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

Magnus Westerlund Former IESG member
No Objection
No Objection (2007-04-19) Unknown
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.
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

Ross Callon Former IESG member
No Objection
No Objection () Unknown

Russ Housley Former IESG member
No Objection
No Objection (2007-04-19) Unknown
  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.
Tim Polk Former IESG member
(was No Record, No Objection) No Objection
No Objection () Unknown

David Ward Former IESG member
(was No Objection) Recuse
Recuse () Unknown

Jari Arkko Former IESG member
Recuse () Unknown

Lars Eggert Former IESG member
Recuse () Unknown