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

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

[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 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.

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.

--Pekka Nikander