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:
> >> 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.
> > 
> 
> > 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.
> 
> I'm quite happy with your extended description instead of my
> more compact one, no problem with that.
> 
> However, there is a potential flooding DoS problem with the scenario:
> 
>    1. Alice the attacker contacts 20000 hosts, tells them that her
>       primary address is 10.0.0.1 and she is also reachable at 10.1.1.2
>       She may make the contacts one at time if she has herself only
>       limited network capability, leaving the connections dormant.
>       She also performs the three way handshake as outlined above.
> 
>    2. Alice orders a large data stream from each of the 20000 hosts,
>       perhaps once at a time, and *immediately* stops answering
>       at 10.0.0.1 for that particular host.  Preferably she uses
>       a service where the data stream will start with a delay, e.g.
>       streaming video which will start only somewhat later.
> 
>    3. The 20000 hosts notice, one by one, that Alice is not answering
>       any more at 10.0.0.1, and divert the large data stream to 10.1.1.2.
>       To make the situation worse, Alice may try to send faked canned
>       acknowledgements that look like they were coming from 10.1.1.2.
>       Notice that there does not have to be any hosts at 10.1.1.2, and
>       therefore the 20000 hosts are not receiving ICMP replies or
>       TCP RSTs.   The real target might be the network 10.1.1.0/24.
> 
>    4. As a result, the 10.1.1.0/24 network is flooded with unwanted traffic.
> 
> The fix is simple, but needed:  Either
> 
>    a) during the initial negotiation the hosts check the reachability
>       of the secondary addresses, and make sure, through some simple
>       and cheap crypto, that it is the same host answering at all of
>       the given addresses, or
> 
>    b) once the primary address becomes unreachable, the hosts check,
>       using some simple and cheap crypto, that it is the same host
>       answering at the secondary address, *before* sending any larger
>       amounts of data to that secondary address.

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

> 
> If you look at the current MIPv6 security solution, it is essentially
> a variation combined a) and b); a) since a MIPv6 host is multihomed
> at its home address and care-of-address and b) since the care-of-address
> changes in an unpredictable way during a handoff.
> 
> The essense: You *have* to check that it is the *same* host that
> is answering in the secondary address *before* you send any larger
> amounts of data to that address.
> 
> For what I've been following SCTP etc, it looks like the possibility
> of such a flooding attack has been neglected.
> 
> Using that "simple and cheap" crypto is not very secure, of course.
> PK makes it more secure.  But people seemed to agree that it is
> good enough for MIPv6; maybe it would be good enough for end-host
> multi-homing as well.  Hence also my call for non-PK crypto for HIP,
> since HIP is more than just security.
> 
> [In principle I agree with your "strengthening TCP ISS/IRS" view.]
> 
> > 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.
> 
> IMHO, that is quite a black&white view.  I think that the majority
> of end-host multihoming cases will be shades of gray there in between,
> e.g. mobile devices with multiple alternative network interfaces.
> 
> 
> >> 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 slightly disagree for two reasons:  Firstly, I don't believe
> in the black&white multi-homing vs. mobility distinction, but I
> see the shades of gray.  Secondly, IMHO the flooding attacks
> look very much the same, even though the details differ.
> 
> The expired draft-aura-mipv6-bu-attacks-01.txt had pretty good
> text about the flooding attacks.  It is still available at
> Google cache.
> 
> > 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.
> 
> Maybe the flooding above qualifies as one? :-)
> 
> > No problem.  I would really like a definitive answer from the security
> > heavyweights to finally put the matter to rest if possible.
> 
> Well, the security people think that I'm a mobility person, knowing
> nuthin about security, and the mobility people think that I'm a
> security Steve, knowing nuthing about mobility.  So take your
> grain of salt.
> 
> --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