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

[Jari Arkko <[e-mail]>]

Viday,

Thanks a lot of your review and starting an interesting
technical discussion! Some further comments inline:

>I want to separate the topics out, since these are long discussions.
>I'll start separate threads on a couple of other related topics after
>this. 
>
>Summarizing the means by which flooding attacks can be realized: 
>
>1. Directly flooding the victim by sending traffic to the victim - as
>you pointed out, this requires reasonable amount of effort on the
>attacker's part. 
>  
>
Right.

>2. Subscribing for bogus sessions using a victim's IP address (TCP has
>some behavior that can help here, for e.g., slowing down if proper acks
>aren't received, but it is possible to subscribe to UDP/RTP sessions).
>This would allow the attacker to amplify the attack without too much
>direct resource involvement. 
>  
>
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.

>3. Using MIP6 home subscription to redirect traffic to the victim. Of
>course, the risk here is that of authenticated nodes registering the
>victim's IP address as its CoA. 
>  
>
Right. TCP is not a barrier here.

>4. Using MIP6 RO to redirect traffic to the victim. If there is a HoA
>test, here too, the risk is that of authenticated nodes registering the
>victim's IP address as its CoA. The HoA test cannot pass unless there is
>a valid binding for that node at the HA. When the HoA is created with
>CGAs, this situation has full equivalence with the home subscription.
>Note that I'm still not saying the MN-HA authenticated state has any
>meaning to the CN. 
>  
>
That is the crux of the matter. Whatever arrangement exists between the MN
and its HA is invisible to the CN (under the assumption of talking to a
random
Internet host). What the CN sees with a home test is that the MN appears
to be in control of receiving traffic at the home address. This is
sufficient
for agreeing to route traffic relating to that address differently, but it
does not say anything about the existence of the node at the care of
address.

Of course, if there's a problem, the CN can go and complain to the home
network's admin. The admin may be able to find out the offending node and
turn it off. But the victim network admin needs to talk to both the CN
network
and then indirectly the home network to get this started; during the design
of the original RR mechanisms it was felt that its better to provide a
mechanism
that helps prevent these situations -- even if the network admin and
authorities
could sort out the situation later.

>If I understand correctly, you are saying that MIP6 can be used to
>amplify flooding attacks. Even though I think in practice, 2 above can
>be used to amplify flooding attacks, if that is the intention, I can buy
>the argument that if say, 2 is solved by other means, you will still be
>left with the possibility of amplification via 3 and 4.
>  
>
I believe 2 is harder to achieve with TCP from the attacker's point of view
than 3 (and 4 if we didn't have RR).

I am sure there are non-TCP attacks of class 2 that are serious. My belief
is that we should work to reduce these amplification vulnerabilities
in the entire stack.

>However, the point I struggle with is this - as I've said above, I think
>there is equivalence in the attack that is possible with 3 and 4,
>assuming that the HoA is based on CGAs and a HoA test is done. So, if we
>say RR for CoA is needed, it is equally needed for 3 and 4. I don't see
>why it is needed for 4 alone in this case. 
>  
>
Let me first state that if I could redesign RFC 3775 today, I would probably
NOT include an administrative security association relationship for the
MN - HA. This would have made deployment much easier (e.g. DHCP
assigned home agents without any of the bootstrapping complexity).
And it would have gotten us rid of problem #3.

We have occasionally talked about this change, though not very
seriously -- and I would not hold it as a precondition for doing RO
enhancements. In any case, in the current deployment model of
Mobile IPv6 there is an administrative relationship which can be
used to shut down misbehaving nodes or even send the authorities
to catch the guilty. I still like to have a stronger flooding amplification
protection for the MN - CN relationship -- particularly if it does not
have a cost in communications latency.

--Jari


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