Re: Flooding Attacks and MIP6 (was RE: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04)

[Jari Arkko <[e-mail]>]

>
>
>Yes -- but I believe for TCP this is hard, because it would 
>> imply being able to guess the sequence numbers. Otherwise the 
>> session won't even start. There are ways to guess the 
>> sequence numbers, but at least some of those ways involve 
>> additional cost for the attacker.
>> 
>  
>
>
>I'd somewhat buy that  :)  I think spoofing the acks can be done, but it
>does involve some cost.
>  
>

Lets talk about this in more detail. To get a flooding attack
with TCP, you need to open a TCP session on behalf of
someone else i.e. using a spoofed source address. Just
sending a SYN is insufficient, because the TCP session
will not start by itself unless you respond to the reply.
For most applications you would also have to be able to
send some initial data, e.g., HTTP GET. Finally, to get
an efficient attack you would need to keep sending at least
some ACKs so that TCP gets to a higher speed.

For some TCP implementations, it was possible for the
attacker to first detect what operating system and
version the reflector node uses, open one TCP session
from the attacker's true IP address, and then guess
what initial sequence number the *next*, spoofed
session gets.

However, modern implementations should use a
randomized initial sequence number which defeats
this attack. I do not have a good estimate of how
widely this has been implemented and turned on,
but I believe it is quite widespread. With
randomization, the attacker would have to
send a large number of packets to succeed
in hitting the right number. For some spoofing
attacks it makes sense for an attacker to spend
such an effort -- but not when it wants to flood
the victim.

It is also necessary to avoid the victim node's
RST responses from disabling the attack. (See
RFC 1948.)

Based on the above, I think we have reasonable
protection against using TCP in flooding attacks.
But I don't dispute the fact that there's probably
a fair number of other situations where such
attacks are possible. And we have older TCP
implementations (but that situation should
improve over time).

----

One more follow-up: what the MIPSHOP document does
is an improvement over the existing Mobile IPv6 mechanism.
But it does not change the fundamental principles of the
base protocol, such as whether there should be
amplification/flooding attack protection in the RO
part. I would suggest that if you believe that a
change is needed in this respect we open another
discussion about that. That discussion is bigger
than the fate of a single optimization.

--Jari


_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop