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:
> > 
> > How about a variation on both of these...
> > 
> > c) only the primary address remains in an established state.  Secondary
> > addresses remain in a syn-received state until required to be used in which
> > case the syn-ack and ack packets have to also be sent on the secondary
> > addresses using the same nonce.  If it doesn't arrive on the same host, the
> > flood storm will be immediately quenched.  (the decision to send a RST might be
> > a policy decision on the host).
> 
> I think that approach could be developed as well.  However,
> maybe you should pay attention to the possibility of faked
> acks.  That is, if Alice is the attacker, she knows the
> nonce.  Thus, she might be able to anticipate the forthcoming
> syn-ack containing the nonce, and be able to ack that even
> if she doesn't see the syn-ack.  Thus, we must combine
>    a) the nonce used on the primary connection, and
>    b) a fresh nonce generated for the syn-ack on the secondary
>       address.

Hmm..  good point.

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?

> 
> If you hash these together, you, again, have a solution very
> similar to that of Mobile IPv6.

I am not sure if that is totally necessary if we exchange the same addresses as
before along with a new originating nonce (so the packet looks almost identical
to a primary MH SYN address packet except for nonce and control bits)

> 
> --Pekka
> 
> 
> 

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