Re: The state of IPv6 multihoming development

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On Sun, 27 Oct 2002, 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.
> 
> >Why does this so much sound like Mobile IPv6 to me?
> 
> There are many similarities. That's why it would be good to talk with the mobility people.
> 
> >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? Remember that we have to maintain backward compatibility with a lot of stuff.

I strongly believe that any solution which depends on crypto won't fly, mainly
on the grounds that it is my understanding that good crypto relies on PKI and
also requires significant cpu resources that may not be applicable to monster
servers or miniscule devices. Generally the nature of mobility is that crypto
is mandatory because of the dangerous environment that it operates within.  The
only security requirement that a MH solution needs to conform to would be
equivalent to what we have in IPv4.  I believe this requirement is fully met by
a syn/ack exchange of addresses on the primary addresses between the hosts.
While this does not preclude a man in the middle attack steal the connection,
neither does the BGP model preclude a man in the middle attack also in such a
scenario.  I believe it could withstand a man on the side attack though.

> 
> >The NSRG report still makes a good reading.
> 
> Do you have a pointer?
> 
> >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?
> 
> 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.
> 
> 

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210