[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The cost of crypto in end-host multi-homing (was Re: The stateof IPv6 multihoming development)
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.
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