Re: The state of IPv6 multihoming development

[Pekka Nikander <Pekka.Nikander@nomadiclab.com>]

Iljitsch van Beijnum wrote:
> > > The basic idea is simple: the IP addresses the transport layer uses
> > > become the identifiers of a session. In transit, these identifiers
> > > may/must be replaced by locators, but they identifiers are restored
> > > before the packet reaches the transport layer at the other end.
> > I am probably biased here, but IMHO once you start to really
> > ponder the security consequences, you pretty much come to the
> > idea that maybe, after all, it might be better to introduce
> > a new cryptographic name space instead of once more overloading
> > the IP name space with some IP addresses that are end-point
> > identifiers (and locators) and some that are (just) locators.
> > The resulting aliasing problems are nasty, security wise.
> What would this cryptographic name space look like?
The basic idea is simple:  Introduce a new name space for
end-points.  Architecturally, the name space would be located
between the IP addresses and the TCP/UDP/SCTP ports.  The
scope of the transport layer ports would be changed from
IP addresses to end-point names.

The end-points names would then be bound to IP addresses.
For mobility, this binding would be dynamic.  For end-host
multi-homing, this binding would be one-to-many.  For
virtual hosts, the binding would be many-to-one.

If the new name space was cryptographic, the primary end-point
identifiers would be public keys (or equivalents).  However,
since public keys are so large, it would be more convenient to
use digests of the keys in most data structures.

Thus, instead of trying to make a TCP connection to e.g.
your-ip:25 I would create a TCP connection to hash(your-key):25.

Security would be trivial, since you would know the public
key of your peer.  The details are in the HIP drafts.

> Remember that we have to maintain backward compatibility
> with a lot of stuff.
There are lots of details to be worked out, but the basic
idea in HIP is to represent the end-point ID as a 127 bit
hash of the public key.  This hash would then be encoded
so that it looks like an IPv6 address with the first two
bits being either 01 or 10.  Both of these code points
are currently unassigned.

The host stack would then, underneath TCP or UDP, look
at these two bits.  If the bits indicate a normal IPv6
address, nothing would happen and the host would work
just like today.  On the other hand, if the bits indicate
HIP, the host would select an IP address from the addresses
currently available for the given host, and replace the
key hash with the address.  The recipient would then make
the reverse, thereby preserving transport layer checksums.

This is somewhat hackish, I agree, but it would preserve
backward compatibility.  A new API would be a better
alternative, but would break backward compatibility.

In the wire, IP addresses are always used as today.
Thus, no changes are required to routing.

> > The NSRG report still makes a good reading.
> Do you have a pointer?
http://www.ietf.org/internet-drafts/draft-irtf-nsrg-report-06.txt

> > If you are going to require changes to the end-host and the
> > introduction of a mudem box anyway, the HIP design might
> > be a good place to start with.  The more recent variants of
> > HIP already support end-host multi-homing, and they contain
> > a "mudem" which is able to perform prefix translation, function
> > as a mobility home agent, and as a mobility anchor point.
> That sounds good. Another pointer, please?
The basic design is perhaps best explained in our forthcoming
NDSS paper.  I'm happy to send preprints upon request; I'm afraid
I can't put it on my web site yet.  (NDSS will be held in
February in San Diego, see http://www.isoc.org)

Other sources of information are the following:

http://homebase.htt-consult.com/HIP.html
http://hip4inter.net

> However, mobility as I understand it assumes things,
> especially the home agent, are reachable. In multihoming,
>  this definately isn't an assumption we can make.
According to my understanding, mobility requires reachability
for the following two reasons:
 a) Initial reachability.  You need some initial IP address
    to reach the host in the first place.  If multi-homing
    is supported in addition to mobility, the set of initial
    addresses can contain more than one address.
 b) Resolving simultaneous movements (double jump).  If both
    ends of a connection are mobile and move at the same time,
    they must somehow be able to reach each other after the
    movements.
Both of these, in fact, are easier to solve with end-host
multi-homing.

(It is a completely different thing that Mobile IPv6 is
designed as it is designed, with home agents and lots of
complexity.  It carries much history from Mobile IPv4 design...)

--Pekka Nikander