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

Hi Vidya, hi Jari.

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

Yes, this is one point:  Proactivity is better than reactivity.

Another thing is that there may actually be no home agent and home
domain admin which a victim could contact.  (I mentioned this in the
previous email, but I guess it was lost in the noise.)  E.g., an
attacker may attach to a public WLAN, acquire a (possibly temporary) IP
address, and use this IP address as a HoA in combination with a false
CoA.  The attacker itself would then play the HA part during the HoA test.

Of course, the HoA test would in this case guarantee the attacker's
reachability of the alleged "HoA", and hence a victim could
theoretically track the attacker down by contacting the public WLAN
provider.  But there is no clear and, more importantly, fast procedure
that the victim could follow.

Also note that the business relationship between the attacker and the
public WLAN provider may only be of temporary nature (e.g., an hourly
subscription).

Ciao,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

Jari Arkko wrote:
> 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
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop