Note: This ballot was opened for revision 04 and is now closed.
Summary: Needs a YES.
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.
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.
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.
datatracker.ietf.org