Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00

[S Moonesamy <[e-mail]>]

Hi David,

Thanks for the feedback.

At 21:43 02-07-2013, David Farmer wrote:
>First, I think it is necessary to make the point that the primary 
>technique to mitigate a malicious RA flood attack is through 
>deployment of RA Guard mechanisms as described in [RFC6105] or the 
>other mitigation techniques discussed in section 3 of [RFC6104].  This

The draft already mentions that the Router Advertisement problem is 
documented in
RFC 6104.  The following paragraph then mentions a mitigation against 
a Router Advertisements flooding attack.  The proposal documents what 
some code (see Appendix A) does in practice instead of getting into a 
discussion of the various techniques available.

As a side note, a friend and I deployed IPv6 in a school.  My friend 
donated a router to make that possible.  I doubt that the school 
would have deployed IPv6 if we told its management that the the 
school will have to purchase devices compliant with RFC 6105.

>  describes a necessary, but secondary, mechanism that only 
> mitigates exhaustion of CPU resources by a RA flood attack.  While 
> important, even with this technique properly

Yes, that's what the Introduction Section says.

>  implemented it still seems possible for a malicious attacker to 
> disrupt access to a network or cause traffic to be maliciously diverted.

I agree that it is still possible for an attacker to disrupt 
access.  The code tries to reduce the scope of the attack by 
preventing the system from being unusable or unresponsive.  That 
seems better than disabling IPv6 altogether.

>In section 2 you say the following;
>
>    A host will silently discard a Router Advertisement once the
>    configurable limit is reached.  Default values are specified to make
>    it unnecessary to configure any of these variables.
>
>Does this mean all RAs are silently discarded at that point, or only 
>those that would cause configuration of additional prefixes, default 
>routers, or redirects per interface?  If it is not all RAs, don't 
>you still have to look at all the RAs and decide which ones refresh 
>the current state of the allowed prefixes, default routers, or 
>redirects per interface?  How would this protect the CPU resources?

No, what the code does is to short-circuit processing of Router 
Advertisements (RA) to disallow the addition of additional prefixes, 
or default routers, or redirects per interface.  Looking at all the 
RAs is not a problem.  The system internally processes the 
information beyond its limits and that causes a significant amount of 
CPU resources to be consumed.

>Or, if you discard all RAs until something times out and drops you 
>below the limits, doesn't that allow a malicious attacker to achieve 
>their goal?  Isn't it likely that the valid prefixes or routers will 
>timeout first?

If the goal is to crash the system that won't happen if the system 
enforces the limits mentioned in the draft.  Yes, the system will 
lose valid information first.

>I think you need to provide more details.

My preference is to focus on what is being implemented instead of the 
sensationalist angle.

Regards,
S. Moonesamy