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:

> [I changed the subject line to reflect the contents of discussion.]
> 
> Peter Tattam wrote:
> 
> > 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.
> 
> Well, I fully agree that there are problems with crypto.  However,
> part of your worry is ungrounded, IMHO.  The kind of crypto we are
> now taking about does *not* depend on PKI.  It may even be possible
> to base it on symmetric crypto instead of public key crypto, thus
> alleviating some of the performance worries.  OTOH, using public
> key crypto is so much easier that AFAIK nobody has yet seriously
> considered the symmetric alternatives.
> 
> Why do I believe that crypto is probably needed?  Well, *if* the
> goal of end-host multi-homing is to keep transport sessions
> flowing, it becomes equivalent with mobility, at least from
> security point of view.
> 
> Let's consider the following scenario:
> 
>    1. Alice contacts Bob from 10.0.0.1
>    2. Alice tells Bob that she is also reachable at 10.1.1.2
>    3. Alice stops answering to 10.0.0.1
>    4. Bob assumes that the path to 10.0.0.1 has failed and
>       starts using 10.1.1.2 instead

This should be...

1. Alice at primary address 10.0.0.1 contacts Bob at primary
address 10.10.0.1 and at the same time says
that she is reachable also at 10.1.1.2

2. Bob responds by saying, ok you tell me that you are at 10.0.0.1 and
10.1.1.2, and I'm at 10.10.0.1 and also at 10.12.0.1

3. Alice says ok, that agrees with what I sent you and I'm responding back
to you to say you're telling me you're at 10.10.0.1 and at 10.12.0.1.  I'm
still awaiting final confirmation.

4. Bob sends his final response saying yes, your response agrees with what
I sent you.  We both trust each other to send data on these addresses, but we
agree now that no other addresses can be used from this point on.

    time passes...

5. Alice stops answering to 10.0.0.1
6. Bob knows already that alice might be listening at 10.1.1.2 and tries
that address also.

(Steps 1 to 4 *MUST* be done on the primary addresses.  If that fails a new
primary address should be chosen and the whole process starts again.)

Been through this issue many times before.  Both sides exchange the set of
reachable addresses with a three way syn/ack handshake before any addresses are
allowed to be switched. The strength of this is governed by the size of the
ISS/IRS in TCP, which in recent times has been encouraged to have much more
cryptographically strong properties. It is plausible to have a much larger
nonce for this purpose included in the IPv6 option that is cryptographically
strong enough to prevent any kind of guessing that is common in syn/ack
hijacking.  If the session doesn't reach an established state, nothing goes
ahead.  For the really paranoid, the only solution is signing the packets, but
that implies there are either shared secrets or some kind of public key crypto. 

The difference between a MH solution and a mobility solution is that in the MH
solution, both ends negotiate in advance all possible addresses because each
end knows in advance all the possible addresses which can be used, and only the
primary address pair is used for negotation. In mobility, the alternative
addresses are generally not known in advance and hence crypto is required to
establish trust that the change of address is authorized.

Don't also forget that DNS provides MH information which can also be used
to add some extra checking at least for destination addresses.  It is
unrealistic for the listening host to consult DNS for every incoming
connection, although many sites do this as a matter of good practice anyway.

> 
> This is equivalent, from the security point of view, to
> 
>    1. Alice contacts Bob from 10.0.0.1
>    2. Alice tells Bob that she has moved to 10.1.1.2
>    3. Bob starts using 10.1.1.2 instead of 10.0.0.1
> 
> Ergo, if someone can launch an attack against a mobility
> mechanism, she is also able to launch a similar attack against
> an equivalent end-host multi-homing mechanism.  The level of
> protection needed is basically similar, and the same basic
> security solutions are applicable.

They are not the same for reasons mentioned above. The attack can be launched
only during the exchange, but no other time.  With mobility, the attack could
be launched any time.

I challenge the security people to work out an attack strategy which is not a
man in the middle one, and then I will be perfectly happy to concede defeat.

> 
> Well, the multi-homing case (as well as the so called smooth
> handover case) is slightly easier to solve, since we can assume
> that the multi-homed host is (at least briefly) reachable
> through both addresses.  However, the difference is quite small
> in practise.  The resulting security protocols are fairly similar
> in both end-host mobility and end-host multihoming.  The details
> differ more based on the exact nature of the mobility resp.
> multi-homing solution, not whether it is a question of end-host
> mobility or end-host multi-homing.
> 
> If we forget about keeping the transport sessions flowing, or
> rely completely on mechanisms on the routing infrastructure,
> the story is different, of course.  I am only referring to the
> case where multi-homing is visible to the end-hosts.
> 
> Anyway, that's my current humble understanding, after having
> played with the ideas for some 2-3 years now.  Maybe I am
> completely flawed in my analysis, and most probably I haven't
> layed out the underlying assumptions well enough in this message.

No problem.  I would really like a definitive answer from the security
heavyweights to finally put the matter to rest if possible.

> 
> --Pekka Nikander
> 
> 
> 
> 

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