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

From: S Moonesamy <[email-masked]>
Date: Tue, 02 Jul 2013 15:02:24 -0700

Hello,

An IPv6 Router Advertisements flooding attack can cause a node to 
consume all CPU resources available making the system unusable and 
unresponsive. draft-moonesamy-ra-flood-limit-00 ( 
http://tools.ietf.org/html/draft-moonesamy-ra-flood-limit-00 ) 
recommends some configurable variables as a mitigation against an 
IPv6 Router Advertisements flooding attack.

I would appreciate if you read the draft and comment.

Regards,
S. Moonesamy

---

From: Rui Paulo <[email-masked]>
Date: Tue, 02 Jul 2013 15:48:50 -0700

On Jul 2, 2013, at 15:02, S Moonesamy <[email-masked]> wrote:

> Hello,
> 
> An IPv6 Router Advertisements flooding attack can cause a node to consume all CPU resources available making the system unusable and unresponsive. draft-moonesamy-ra-flood-limit-00 ( http://tools.ietf.org/html/draft-moonesamy-ra-flood-limit-00 ) recommends some configurable variables as a mitigation against an IPv6 Router Advertisements flooding attack.
> 

I think it doesn't offer enough guidance to implementors. I also think that Appendix A makes an inaccurate statement about NetBSD and OpenBSD as they (along with FreeBSD) limit the number of ND options in the packets, not the number prefixes / routers.

--
Rui Paulo

---

From: S Moonesamy <[email-masked]>
Date: Tue, 02 Jul 2013 16:46:22 -0700

Hi Rui,
At 15:48 02-07-2013, Rui Paulo wrote:
>I think it doesn't offer enough guidance to implementors. I also 
>think that Appendix A

Thanks for the feedback.

As an example this is part of what one implementation does:

         if (ip6_maxifdefrouters >= 0 &&
             ext->ndefrouters >= ip6_maxifdefrouters) {
                 splx(s);
                 return (NULL);
         }

The information provided in the Router Advertisement is discarded 
once maximum is reached.

>  makes an inaccurate statement about NetBSD and OpenBSD as they 
> (along with FreeBSD) limit the number of ND options in the packets, 
> not the number prefixes / routers.

I understand the comment about ND options in the above.  I read the 
NetBSD and OpenBSD source code and I saw that there is a limit on the 
number of prefixes and routers.  I also performed several tests on 
NetBSD and OpenBSD to understand the impact of RA flooding on those 
systems.  Appendix A does not mention FreeBSD as there is still work 
to be done to address the problem report about RA flooding.

Regards,
S. Moonesamy

---

From: David Farmer <[email-masked]>
Date: Tue, 02 Jul 2013 23:43:16 -0500

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 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 implemented it still seems possible for a malicious 
attacker to disrupt access to a network or cause traffic to be 
maliciously diverted.

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?

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?

I think you need to provide more details.

On 7/2/13 17:02 , S Moonesamy wrote:
> recommends some configurable variables as a mitigation against an IPv6
> Router Advertisements flooding attack.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: S Moonesamy <[email-masked]>
Date: Wed, 03 Jul 2013 00:34:09 -0700

Hi David,

Thanks for the feedback.

At 21:43 02-07-2013, David Farmer wrote:
>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.

>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

---

From: David Farmer <[email-masked]>
Date: Wed, 03 Jul 2013 12:26:26 -0500

> At 21:43 02-07-2013, David Farmer wrote:
...
> 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.

I didn't say you had to deploy RFC6105 complaint devices, I said you 
need that, "or the other mitigation techniques discussed in section 3 of 
[RFC6104]."  In the particular case you describe, I'd recommend the 
technique described in section 3.5 of RFC6104; Setting the valid RA to a 
Router Preference of "High", this has little or no cost and is 
relatively effective, especailly with the techniques described in this 
draft.

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

I agree, I'm just saying you should be more explicit about what this 
does and doesn't do.  Maybe add the following as an additional paragraph 
to the security considerations section;

    However, without deployment of RA Guard mechanisms as described in
    [RFC6105] or the other mitigation techniques discussed in section 3
    of [RFC6104] it is still possible for a malicious attacker to
    disrupt access to a network or cause traffic to be diverted.

>> current state of the allowed prefixes, default routers, or redirects
>> per interface?  How would this protect the CPU resources?
>
> 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.

Thanks, I better understand the intended behaviour now.  I suggest the 
following text for section 2, to more clearly describe the intended 
behaviour.

    A host will silently discard any Router Advertisement that cause one
    of the following configurable limits to be exceeded.  However, Router
    Advertisements that only refresh previously learned configuration
    information are processed.  Suggested default values are specified
    making it unnecessary to configure these variables for most typical
    situations.

...

> My preference is to focus on what is being implemented instead of the

My intent is not sensationalism, its fair warning.  I don't want a naive 
users or enterprise network operator reading this and thinking that if 
their hosts implement this all their RA issues are solved.  If you added 
the paragraph I suggest above to the security consideration section I 
think it would provide the explicit and necessary fair warning I'm 
looking for.

---

From: Arturo Servin <[email-masked]>
Date: Wed, 03 Jul 2013 22:19:12 -0300

SM,

    Why IPv6 Router Advertisement Guard would be not enough?

    Or are these recommendations orthogonal to a network applying RA?

    I think that it would be important to address those questions in the
draft.

    Also, related. Is it possible for a host to perform a RS attack?

Regards,
as

---

From: S Moonesamy <[email-masked]>
Date: Wed, 03 Jul 2013 16:05:27 -0700

Hi David,
At 10:26 03-07-2013, David Farmer wrote:
>need that, "or the other mitigation techniques discussed in section 
>3 of [RFC6104]."  In the particular case you describe, I'd recommend 
>the technique described in section 3.5 of RFC6104; Setting the valid 
>RA to a Router Preference of "High", this has little or no cost and 
>is relatively effective, especailly with the techniques described in 
>this draft.

The reference to RFC 6104 is there so that people can read that 
document and decide about which mitigation technique is better suited 
to their needs.  Setting the valid RA to a Router Preference of 
"High" is an operational decision instead of an implementation decision.

>does and doesn't do.  Maybe add the following as an additional 
>paragraph to the security considerations
>  section;
>

The above sounds like an operational choice.  It may be better to 
keep the different decisions separate.

>Thanks, I better understand the intended behaviour now.  I suggest 
>the following text for section 2, to more clearly describe the 
>intended behaviour.
>

Thanks for suggesting text.  I would like to read the off-list 
comments I received and then figure out how to add the suggested changes.

>My intent is not sensationalism, its fair warning.  I don't want a 
>naive users or

I don't think that was your intent.  I meant that I am looking at 
what the code does instead of other angles that might be misleading.

>  enterprise network operator reading this and thinking that if 
> their hosts implement this all their RA issues are solved.  If you 
> added the paragraph I suggest above to the security consideration 
> section I think it would provide the explicit and necessary fair 
> warning I'm looking for.

I agree that a fair warning would be appropriate.  Someone else 
already suggested changes to the Security Considerations section.  I 
will incorporate them in the next revision.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Wed, 03 Jul 2013 23:02:38 -0700

Hi Arturo,
>     Why IPv6 Router Advertisement Guard would be not enough?

The draft does not seek to criticize Router Advertisement Guard in 
any way.  The draft looks at what can occur on the host and what has 
been done to ensure that there isn't a crash.

>     Or are these recommendations orthogonal to a network applying RA?

Yes.

>     I think that it would be important to address those questions 
> in the draft.

That would be an operational issue.

>     Also, related. Is it possible for a host to perform a RS attack?

I don't have sufficient information to provide a good answer.  I 
prefer not to give you a misleading answer.

Regards,
S. Moonesamy

---

From: Arturo Servin <[email-masked]>
Date: Thu, 04 Jul 2013 08:30:56 -0300

SM,

    Sorry, I should have said "Or are these recommendations orthogonal
to a network applying RA Guard?"

    I think the ansewer is still yes. But for that reason I think that
you should mention that this is an add-on to RA Guard (not instead of,
not criticizing it) and it is intended to provide some security
mechanisms to the host when the network administrator do not have this
capability (RA-Guard) in its network.

    In the end, having RA-Guard could solve enteraly this problem, but
when it is not provided by the network the host should have mechanisms
to defend itself. Then is when your draft applies. Does it make sense my
comment?
   
Regards,
as

On 7/4/13 3:02 AM, S Moonesamy wrote:
> The draft does not seek to criticize Router Advertisement Guard in any
> way.  The draft looks at what can occur on the host and what has been
> done to ensure that there isn't a crash.
>
>>     I think that it would be important to address those questions in
>> the draft.
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 04 Jul 2013 20:27:19 -0700

Hi Arturo,

Yes.

>capability (RA-Guard) in its network.

I think that we are looking at this from two different angles.  I can 
look at this in terms of:

  (a) how does the network protect the host

  (b) how is the host protected

If there is a protection for (a), for example, Router Advertisement 
Guard, (b) might not be much of a problem.  If the host is protected, 
the question being asked is whether (a) is needed or not.  I am not 
trying to answer that question as there is existing code for doing 
(b) and that is what the draft is talking about.  What the person 
writing the code for the host may wish to say is that their system 
provides for the limits mentioned in draft-moonesamy-ra-flood-limit-00.

>to defend itself. Then is when your draft applies. Does it make sense my

Yes, I understood what you wrote.  In my opinion it depends on your 
security posture.  Some people may prefer to put security closer to 
the end whereas others might find it better to do it centrally.  RFC 
6104 discusses about scenarios and different methods to mitigate 
against rogue Router Advertisements.  In my opinion that is where the 
above is more relevant.  What the code does is to prevent the host it 
is running on from crashing.

Regards,
S. Moonesamy

---

From: David Farmer <[email-masked]>
Date: Fri, 05 Jul 2013 10:52:59 -0500

On 7/4/13 22:27 , S Moonesamy wrote:
> trying to answer that question as there is existing code for doing (b)
> and that is what the draft is talking about.  What the person writing
> the code for the host may wish to say is that their system provides for
> the limits mentioned in draft-moonesamy-ra-flood-limit-00.

I think some kind of applicability statement would be a useful addition 
to the Draft.  I'm less worried about a network operators deciding that 
they don't need to implement RA-Guard because their hosts implement 
RA-Flood-Limit.  I'm more concerned about OS vendors or implementors 
deciding they don't need to implement RA-Flood-Limit because they view 
this as a network operator issue and if only the network operators would 
just implement RA-Guard then RA-Flood-Limit wouldn't be necessary.

I think it needs to be made clear that both RA-Guard and RA-Flood-Limit 
are independently necessary to ensure both the security and stability of 
a network and its hosts.

1. RA-Guard or the other the techniques discussed in RFC6104 can 
effectively prevent RAs sourced from hosts either by malicious activity 
or simple miss-configuration.  But, RA-Guard can do little to prevent 
RAs caused by software or hardware bugs within, or miss-configuration of 
the network itself.

2. RA-Flood-Limit prevents the consequences of many different RAs being 
seen by a host, regardless of the source of those RAs.  But, can not 
distinguish between the source of the RAs, and may allow malicious 
configuration of the host.

3. Therefore, implementation of BOTH RA-Guard and RA-Flood-Limit are 
necessary to ensure BOTH the security and stability of a network and its 
hosts.

>> to defend itself. Then is when your draft applies. Does it make sense my

I disagree, RA-Guard can effectively deal with RA-Floods caused by hosts 
either through malicious activity or miss-configuration, but can not 
necessarily deal with RA-Floods caused by miss-configuration or bugs 
within the network itself.

> security posture.  Some people may prefer to put security closer to the
> end whereas others might find it better to do it centrally.  RFC 6104
> discusses about scenarios and different methods to mitigate against
> rogue Router Advertisements.  In my opinion that is where the above is
> more relevant.  What the code does is to prevent the host it is running
> on from crashing.

Security posture is only part of the issue, this is both a security and 
stability issue, that needs both host based and network based mitigation 
strategies.  Neither, RA-Guard or RA-Flood-Limit can ensure both the 
stability and security of a network and it hosts independently, they are 
complementary strategies, and are both necessary for a complete 
solution.  I think it is important for the Draft makes this point one 
way or another.

Thanks

---

From: Arturo Servin <[email-masked]>
Date: Fri, 05 Jul 2013 13:06:27 -0300

David
On 7/5/13 12:52 PM, David Farmer wrote:
> I disagree, RA-Guard can effectively deal with RA-Floods caused by
> hosts either through malicious activity or miss-configuration, but can
> not necessarily deal with RA-Floods caused by miss-configuration or
> bugs within the network itself.

    Agreed.

    I was just considering the malicious activity but I oversight
miss-configuration or bugs.

    I also agree with you that both RA-Guard and RA-Flood-Limit are
necessary. I think those statements should be added to the draft.

Regards,
as

---

From: S Moonesamy <[email-masked]>
Date: Fri, 05 Jul 2013 13:03:17 -0700

Hi Arturo, David,
At 08:52 05-07-2013, David Farmer wrote:
>I think some kind of applicability statement would be a useful 
>addition to the Draft.

 From an IETF Stream perspective it's difficult to assess how to 
write an applicability statement in this context.

>   I'm less worried about a network operators deciding that they 
> don't need to implement RA-Guard because their hosts implement 
> RA-Flood-Limit.  I'm more concerned about OS vendors or 
> implementors deciding they don't need to implement RA-Flood-Limit 
> because they view this as a network operator issue and if only the 
> network operators would just implement RA-Guard then RA-Flood-Limit 
> wouldn't be necessary.

I see.

>I think it needs to be made clear that both RA-Guard and 
>RA-Flood-Limit are independently necessary to ensure both the 
>security and stability of a network and its hosts.

Let me see if I can write some text to discuss the network versus host angle.

>effectively prevent RAs sourced from hosts either by malicious 
>activity or simple miss-configuration.  But, RA-Guard can do little 
>to prevent RAs caused by software or hardware bugs within, or 
>miss-configuration of the network itself.

I prefer not to comment about this. :-)

>2. RA-Flood-Limit prevents the consequences of many different RAs 
>being seen by a host, regardless of the source of those RAs.  But, 
>can not distinguish between the source of the RAs, and may allow 
>malicious configuration of the host.

Yes.

>necessary to ensure BOTH the security and stability of a network and its hosts.

I think that the above looks at the proposal as a solution to the RA 
flooding problem whereas the scope of the proposal is a mitigation to 
a problem which a host may encounter.

>necessary. I think those statements should be added to the draft.

Please see the comment above about the scope.

Regards,
S. Moonesamy

---

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Jul 2013 14:42:08 +0200

> I would appreciate if you read the draft and comment.

Isn't this already covered (together with a bunch of other ND-related
stuff) in:
<http://tools.ietf.org/html/draft-gont-opsec-ipv6-nd-security>?  :-)

(this I-D was presented at the OPSEC meeting in Orlando)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: S Moonesamy <[email-masked]>
Date: Mon, 15 Jul 2013 20:57:16 -0700

Hi Fernando,
>(this I-D was presented at the OPSEC meeting in Orlando)

I was not aware of that draft or that it was presented In Orlando.  I 
took a quick look at  your draft and I see that it mentions 
CVE-2010-4669 and the limit being enforced in OpenBSD 4.2.

Here's the background that led to the draft.  There was an advisory 
published in 2011 about the IPv6 Router Advertisements flooding 
attack.  One of the workarounds suggested was to disable IPv6 if the 
workaround (see Section 2 of draft-moonesamy-ra-flood-limit-00) was 
not available.  There are multiple reasons for why the workaround was 
not implemented on different platforms (see advisory for some of the 
details) even though the problem is documented in RFC 
6104.  draft-moonesamy-ra-flood-limit-00 is about documenting the 
workaround that has been implemented in NetBSD and OpenBSD.

Someone mentioned to me that it is a short draft.  The draft is a 
small effort so that I do not have to hear the "turn off IPv6" 
argument. :-)  It is also about trying to address a known problem 
affecting a node in a timely manner.  I'll invite you to join the 
small effort as co-author of draft-moonesamy-ra-flood-limit.

Regards,
S. Moonesamy

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Jul 2013 14:14:57 +0200

On 07/16/2013 05:57 AM, S Moonesamy wrote:
> published in 2011 about the IPv6 Router Advertisements flooding attack. 
> One of the workarounds suggested was to disable IPv6 if the workaround
> (see Section 2 of draft-moonesamy-ra-flood-limit-00) was not available. 

Suggested in that advisory, or where?

> There are multiple reasons for why the workaround was not implemented on
> different platforms (see advisory for some of the details)

Sloppy coding?

> even though
> the problem is documented in RFC 6104. 

RFC6104 describes rogue RA, rather than RA floods. They are two
unrelated issues: RA flooding is about enforcing basic checks such that
your data structures cannot grow without bounds. Rogue RA is about how
to deal with malicious RAs in the absence of authentication.

> draft-moonesamy-ra-flood-limit-00 is about documenting the workaround
> that has been implemented in NetBSD and OpenBSD.
> 
> Someone mentioned to me that it is a short draft.  The draft is a small
> effort so that I do not have to hear the "turn off IPv6" argument. :-) 

It is not unlikely for people to give that option in security advisories
when no workaround is available.

> It is also about trying to address a known problem affecting a node in a
> timely manner.  I'll invite you to join the small effort as co-author of
> draft-moonesamy-ra-flood-limit.

I don't object to co-authoring (always happy to contribute).

But I'd note that implementations also fail to enforce limits on:

* the number of default routers
* size of the NC
* number of routes

etc., etc.

That's why I personally believe it is better to provide comprehensive
implementation advice, such as that in draft-gont-opsec-nd-security

Thanks!

Best regards,