Re: The state of IPv6 multihoming development

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

[CC:in to hipsec from multi6]

Iljitsch van Beijnum wrote:
> > 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.
> Hm, what problem exactly does this solve that isn't solved by (for
> instance) SSL?
That is a subtle question, thanks for asking that.  That is also
exactly the question which has prevented HIP from becoming a WG
a long time ago.  I think that the multi6 list is perhaps not the
right place to discuss that question, the answer is too long.
If you are interested, let's move this point off-line, to
the HIP mailing list, or some other better suited mailing list.
And please read the NSRG report before we start to dive into this.

> Also, how does the hash to IP address mapping work in the absence of a
> hierarchy?
How does a name to IP address mapping work today?  Using DNS,
for example.  Or some other name resolution service.

There are pure hash based name resolution services, dubbed
"distributed hash tables" (DHT).  I'm not an expert there,
but I can dig up a couple of references if you are interested.

> I'm not sure if I've said so clearly on this list, but over the last
> month or so I've come to realize that it's probably too soon to create a
> definitive multihoming solution. So it would be good to come up with
> meta-solutions that enable different solutions to work together, or
> provide a growth path from one solution to the other.
I agree.  Basically I wanted to point of the following:

 1. Once we start to discuss solutions that require changes to the
    end host (and perhaps these "mudem"s), there is also the option
    of introducing a new name space, cryptographic or not.

 2. End-host based multi-homing solutions *seem* to have the
    same security problems as (some) end-host mobility solutions.

> ...  More specifically: if we can make some sort of
> identifier/locator seperation solution where the identifiers are simply
> routable addresses, most of the ground work to move to crypto hash
> identifiers is in place, and the only thing necessary is a good locator
> discovery mechanism.
If you create a solution where identifiers are simply
routable addresses, you are, from my point of view, basically
re-inventing Mobile IPv6.  And since there are so many
problems with Mobile IPv6, I am quite sceptical about such
a design.  Well, Mobile IPv6 works (probably) and the security
problems have been solved, but the result is, well, large
and complex.  But perhaps I'm short sighted here, and you
have something else in your mind.

> >  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.
> But what if the home agent becomes unreachable?
If the end-host is multi-homed, either in reality or conceptually,
there is no problem.  You can consider the home agent as one
multi-homed interface.  You can have multiple home agents if you
need to.  Or none, temporarily.  See the paper.

> I read about a homeless mobility proposal somewhere a while ago, but I
> haven't been able to find it again afterwards...
That was our draft.  Since then we moved our work to HIP,
mainly due to security constraints.  Maybe it would be the
time to have a look at cheaper-than-PK crypto solutions for
HIP.

--Pekka Nikander