Re: The cost of crypto in end-host multi-homing (was Re: The state of IPv6 multihoming development)

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

On Mon, 28 Oct 2002, Pekka Nikander wrote:

> Peter Tattam wrote:
> > What about if we turn the process around backward.  The site which decides the
> > other end is unreachable starts a fresh exchange on the new address pair
> > (although it is still a secondary address and no new addresses may be
> > introduced) with a separate nonce for each unused destination address (as seen
> > by the host originating packets).  The new nonce has to be cryptographically
> > strong enough to be unguessable.
> > 
> > i.e.
> > 
> > 5. Bob sees Alice is not responding to the primary address and sends a new MH
> >    SYN-Secondary to the secondary address, but with new originating nonce.
> > 
> > 6. Alice responds with a MH SYN-Secondary ACK-Secondary (with same addresses
> >    as before). (original nonce or new nonce???)
> > 
> > 7. Bob sends MH ACK-Secondary as with MH ACK-primary.
> > 
> > We add some extra signals...
> > 
> > for Primary MH address establishment we use as before..
> > 
> > SYN-primary and ACK-primary control signals (like SYN and ACK bits in TCP).
> > 
> > for each Secondary MH address establishment we use two new signals..
> > 
> > SYN-secondary and ACK-secondary control signals
> > 
> > 
> > A SYN secondary must be ignored if there is no MH state with the primary
> > address in the ESTABLISHED state.  Also, I think the address list should match
> > exactly the same as the primary address.
> > 
> > Would that solve the problems?
> 
> Maybe.  I'd have to see a much more specific description before
> I could analyze it for possible holes.  But as a quick evaluation,
> maybe the address list + the existense of a higher layer context
> would work well enough.

Doesn't bother me - I'm just thinking on my feet.

> 
> But, IMHO, we are now going too far into a transport specific
> solution space.  There are other problems with transport-only
> solutions, like consistency between different parallal transport
> connections, the amount of signalling when changing from primary
> to secondary etc.

I don't want to rule out crypto altogether (e.g. I would insist on crypto
for the nonce selection.  My latest TCP stack [Trumpet Winsock and PetrOS
TCP] uses crypto [MD5 hashed sequence] to select ISS for all tcp sessions now.
It seems to be fast enough for the purpose of building lots of TCP connection.)
You must however be very carefully aware of the types of crypto being selected
from a CPU time perspective.  PK encryption is very CPU intensive and could
easily result in DoS attacks at the kernel layer.

> 
> I fully support Iljitsch in the call for an architectural discussion.
> That was the reason why I chimed in:  instead of trying to hack
> end-host multi-homing support into TCP or IP, maybe it would be
> the right time to consider a new name space.  And if not, taking
> a good look at SCTP, as Brian suggested, might be the right road.

I looked at SCTP a while back.  While it has some similarities, I agree with
others that it will not solve the legacy problem of apps that are built for
TCP.

> 
> --Pekka Nikander
> 
> 

I have gotten to the point where I am agnostic about whether this particular
solution should be deployed or not.  It would be nice if it solved a large part
of the MH problem, but if it never gets accepted, I'm not going to lose any
sleep over it.  I don't have a great deal of time at my disposal, and IETF
meetings are out of the question because of my limited financial resources.

Maybe mobility is the way to go.  Why not apply it to realistic scenarios and
see how well it fits.

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