[Hipsec] multi6 summary

[[e-mail] (Henderson, Thomas R)]

At the IETF60 meeting of HIP WG, the chairs asked=20
me to summarize my multi6 presentation for the list, so
as to obtain consensus as to what, if anything,
to do.

Summary:
The multi6 working group has named a design team to
study a consolidated approach for the class of solutions
that it calls a "layer 3.5 wedge".  A draft:
http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-01.txt
about HIP is one of the drafts being considered.  More
information about the multi6 effort can be found at:
http://ops.ietf.org/lists/multi6/multi6.2004/msg01205.html

Previously, the consensus of those working on HIP has
been that HIP should evolve without strict dependencies
on other working groups, and vice versa.  However, in the
context of the multi6 discussions, there were a number of
possible objections raised to HIP as a multi6 solution.
In light of this, since multihoming is an important
possible use of HIP, I thought that it would be prudent
to at least consider whether the objections being raised
might be addressed now by the working group, if by addressing
them now it would make HIP more useful in the long run.

The objections were:
i) reliance on an experimental protocol
ii) absence of supporting infrastructure (e.g., to look up
identities and HITs)
iii) HIP handshake (PK signatures) considered too heavyweight
for some applications
iv) mandatory IPsec considered too heavyweight for some
applications
v) use of HITs as application-level identifiers may break
referrals
vi) privacy concerns with the use of non-ephemeral identifiers

Now, regarding whether any of the current specifications should
be changed to possibly remedy these objections, i) and ii)
are not related to the base spec, and we can't do anything
about them now.  It has been proposed by some people on the multi6
list that iii) could be addressed by using a lightweight
handshake by default and "upgrading" the session to HIP
protection if it was deemed necessary (e.g., mobility).  But
the security properties of the HIP handshake are considered
an essential part of the security.  iv) is addressed by a
possible "Lightweight HIP" idea in the HIP multi6 draft-- such
a protocol could be specified as an extension to HIP and doesn't
really require base spec changes at this time.  vi) is a=20
valid concern, but HIP does have mechanism (anonymous identity
support) to allow for privacy-- it is the management of HIP
identities that is the real concern here, but that is an issue
possibly outside of the base spec.

This leaves problem v)-- the referrals problem for legacy applications
and stacks.  The two main alternatives are to use IP addresses
(locators) as upper-layer identifiers, or to use HITs as transport
layer identifiers, and translate them to IP addresses for legacy
applications and APIs.  Architecturally, the latter alternative
is cleaner, but the former one may have advantage if the HIP
exchange is delayed past the initial exchange.  See, for example,=20
the thread at:
http://honor.trusecure.com/pipermail/hipsec/2004-July/000879.html
The reason that this is relevant is because it affects what is
chosen to put into the pseudoheader.

It is not critical to solve this problem once and for all at this
time.  It may be possible to define a mode of HIP operation in the=20
future that allows IP addresses in the transport level pseudoheader,
if there is a big need for deferring all HIP context exchange until
after initial packets flow on a session, but that probably can
be dealt with in a protocol extension.  For now, if we prefer
to continue using HITs as the transport-level identifier, we
seem to be implicitly saying that we must have some handshake
to exchange the HITs before any packets flow between hosts, even
if it is not a full HIP handshake to start the session.

So in summary, it is my opinion (also expressed at the WG meeting)=20
that nothing needs to be done to the base spec now to accommodate=20
the multi6 problem.  One possible enhancement would be to suggest
that implementations use IP addresses as application layer identifiers=20
for legacy applications and sockets API.  There is some discussion
of this problem in Appendix A of the base spec.  Maybe new base spec
text is needed for that topic.

multi6 will eventually come to a solution or solutions that may (or
may not) include HIP concepts, but after some experience is gained
with what the real requirements are, changes to HIP could probably
be handled in an extension to HIP rather than changing the base spec
at this time.

Tom=20