Subject: [v6ops] Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership (-01)

From: Mark Smith <[email-masked]>
Date: Mon, 8 Feb 2016 06:25:18 +1100

HI,

I'm revisiting a few of my drafts that I've been intending to update,
and here is the first.

My basic realisation was that Solicited-Node joins also could serve as
a low resolution address (or address space range) registration method,
which could then be used by a router to determine whether it needs to
send a ND NS or not. If the Solicited-Node group is present, send the
ND NS, if the group isn't, then don't.

This update adds a few sections and modes based on Lorenzo's feedback:

- Strict and Relaxed discard modes. Universal discarding is Strict
mode, Relaxed mode only discards if there is an indication a DoS is
occurring, to allow for lower MLD reliability or implementations that
don't support MLD

- Some discussion on MLD reliability and how it would effect this method.

Comments and suggestions appreciated.

Regards,
Mark.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 8 February 2016 at 06:14
Subject: New Version Notification for
draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
To: "[email-masked]" <[email-masked]>

A new version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
has been successfully submitted by Mark Smith and posted to the
IETF repository.

Name:           draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
Revision:       01
Title:          Further Mitigating Router ND Cache Exhaustion DoS
Attacks Using Solicited-Node Group Membership
Document date:  2016-02-07
Group:          Individual Submission
Pages:          11
URL:
https://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01.txt
Status:
https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/
Htmlized:
https://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-01

Abstract:
   For each of their IPv6 unicast or anycast addresses, nodes join a
   Solicited-Node multicast group, formed using the lower 24 bits of the
   address.  This Solicited-Node group membership could be used by
   routers to further mitigate a Neighbor Discovery cache Denial of
   Service attack.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Tue, 09 Feb 2016 14:50:52 +0100

Mark Smith wrote:
> From:<[email-masked]>
> To: "[email-masked]"<[email-masked]>
>
>
>
I have read this draft.

At first glance it looks like a smart idea, because a defending router 
only has to track perhaps a thousand entries of state versus potentially 
having to store state for billions of "incomplete" queries.

A couple of questions.

1) How often/when is the MLD cache updated/ timed out?

My concern here is that you now have two caches interacting (mulitcast 
group membership and ND cache), and the timing of adding and deleting 
entries could cause race conditions. Some discussion of how the caches 
interact (or not) could be useful IMHO.

2) Why would a router track multicast membership when potentially it 
could also just track DAD queries directly when nodes join a link?

Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) 
and Fiber access architectures.  Based on the DAD signaling, the 
first-hop router stores in a Binding Table all known IPv6 addresses used 
on a point-to-multipoint domain (e.g., VLAN)."

Couldn't such a cache also be used as a mechanism for defending against 
off-link NS exhaustion attacks?

Obviously if the router joins the link after some nodes are already on 
link, then there's a potential for nodes to have already completed DAD 
before the router boots, so maybe a poll mechanism triggered by 
monitoring on-link ND requests might be appropriate. But then again, if 
the nodes send any off-link traffic via this router at all, they'll 
trigger ND to the router directly, so it's only a problem for normally 
silent nodes that receive inbound sessions. That could be mitigated by 
scheduling a simple 'ping' on end nodes acting as servers when they add 
a new router to their default router list (with appropriate delays/back 
off etc.).

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Mark Smith <[email-masked]>
Date: Wed, 10 Feb 2016 12:50:05 +1100

Hi Ray,

> Mark Smith wrote:

<snip>

> I have read this draft.

Thanks very much for having a read.

> At first glance it looks like a smart idea, because a defending router only
> has to track perhaps a thousand entries of state versus potentially having
> to store state for billions of "incomplete" queries.
>
> A couple of questions.
>

MLD operation is not changed, so what ever the MLD protocol timers are.

> My concern here is that you now have two caches interacting (mulitcast group
> membership and ND cache), and the timing of adding and deleting entries
> could cause race conditions. Some discussion of how the caches interact (or
> not) could be useful IMHO.
>

Other than using the MLD membership list to determine if to ND NS for
a unknown address, there isn't any interaction between the ND and MLD
caches/memberships lists.

Was there a section which seemed to imply they were interacting more
than the ND process using the information in the MLD membership list?
I'm happy to add a statement that they aren't interacting, just
wondering if there is a specific section/paragraph where you think it
might be best placed?

> 2) Why would a router track multicast membership when potentially it could
> also just track DAD queries directly when nodes join a link?
>

The limitation of DAD is that DAD is only performed for unicast
addresses, not anycast addresses. I think anycasts are usually going
to be configured to provide a highly available service or host, not
detecting them somehow and therefore dropping ND NSes for them would
be quite a failure!

DAD is certainly something that could be used to detect normal unicast
addresses, and I think there was a ID about using them for that a few
years ago. You're right, there is also the issue of how at router
starting detects existing nodes/address that have already completed
DAD. I can't remember if I read that ID, however I thought that not
detecting anycast addresses was a fairly significant limitation of
that method.

> Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line (DSL) and
> Fiber access architectures.  Based on the DAD signaling, the first-hop
> router stores in a Binding Table all known IPv6 addresses used on a
> point-to-multipoint domain (e.g., VLAN)."
>
> Obviously if the router joins the link after some nodes are already on link,
> then there's a potential for nodes to have already completed DAD before the
> router boots, so maybe a poll mechanism triggered by monitoring on-link ND
> requests might be appropriate. But then again, if the nodes send any
> off-link traffic via this router at all, they'll trigger ND to the router
> directly, so it's only a problem for normally silent nodes that receive
> inbound sessions. That could be mitigated by scheduling a simple 'ping' on
> end nodes acting as servers when they add a new router to their default
> router list (with appropriate delays/back off etc.).
>

Thanks very much,
Mark.

---

From: [email-masked]
Date: Wed, 10 Feb 2016 06:27:49 +0100 (CET)

> detecting them somehow and therefore dropping ND NSes for them would

We use BGP-based "announce the same prefix from different sites" for
both IPv6 and IPv4 recursive DNS. But this is not the same as "real"
IPv6 anycast (which we don't use).

Is there any evidence that "real" IPv6 anycast is used at all? A sample
size of one is obviously not conclusive - I'm genuinely curious here.

Steinar Haug, AS2116

---

From: Mark Smith <[email-masked]>
Date: Wed, 10 Feb 2016 17:50:50 +1100

> size of one is obviously not conclusive - I'm genuinely curious here.

It don't have any data, however I think it probably isn't used much
because most people are probably thinking of IPv6 as the functional
equivalent of IPv4, and therefore aren't all that aware of its new
capabilities or haven't thought much about how to use them. (One of
the reasons I put quite a bit of explanation in that draft about the
use of Solicited-Node groups in ND is because I think there is a
possibility not many people are all that aware of how they're used in
ND.)

The key thing that "real" IPv6 anycast gives you is the ability to
provide anycast services to other nodes attached to the same link as
the anycast servers/services. I've thought DNS and NTP could be
examples of use - e.g., in a branch office with a single LAN, where
you want to have local redundant DNS and NTP servers available on the
same LAN segment, with them all active at the same time.

Regards,
Mark.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Wed, 10 Feb 2016 14:01:12 +0100

> Mark Smith <mailto:[email-masked]>
> 10 Feb 2016 02:50
> Hi Ray,
>
> On 10 February 2016 at 00:50, Ray Hunter (v6ops)<[email-masked]>  wrote:
>> Mark Smith wrote:
>>
>
> <snip>
>
>> I have read this draft.
>>
>
ACK.
> wondering if there is a specific section/paragraph where you think it
It's more about potential race conditions.

If you're using the contents of a cache that refreshes on one timer (and 
which is potentially unreliable) to perform filtering of actions in 
another cache that updates on another set of timers, there has to be 
some sort of interaction.

As an example: router boots up. MLD cache is totally empty. The node on 
the LAN may have already discovered this router as its default router, 
and routing protocols may have already converged. The filter on inbound 
connections based on MLD cache should probably not be applied until the 
MLD cache is populated, and possibly a couple of update cycles completed.

Another potential example: Node boots up. MLD is between refreshes and 
the router does not see a join request. Inbound connection attempt 
arrives. Router filters the connection attempt. Probably nothing to do 
here except wait for another connection attempt.

Another potential example: Nodes are stressed due to an attack. Or the 
MLD polling router is stressed. MLD queries or MLD responses either are 
not sent, or go astray. MLD cache entry Source Timer times out. Node is 
cut off from external traffic by router filter. Traffic potentially 
subsides. Cycle repeats.

Probably a one-liner could cover the concern.

"Care should be taken to check the validity of the MLD cache before 
applying filtering, to avoid using unreliable MLD cache data, or race 
conditions."

> Ray Hunter (v6ops) <mailto:[email-masked]>
> 9 Feb 2016 14:50
>
>
> Mark Smith wrote:
> I have read this draft.
>
> only has to track perhaps a thousand entries of state versus 
> potentially having to store state for billions of "incomplete" queries.
>
> A couple of questions.
>
> Quoting RFC 6957, the "DAD Proxy works in Digital Subscriber Line 
> (DSL) and Fiber access architectures.  Based on the DAD signaling, the 
> first-hop router stores in a Binding Table all known IPv6 addresses 
> used on a point-to-multipoint domain (e.g., VLAN)."
>
> Couldn't such a cache also be used as a mechanism for defending 
> against off-link NS exhaustion attacks?

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Feb 2016 21:47:38 +1100

Hi Ray,

Sorry not to get back to you sooner.

On 11 February 2016 at 00:01, Ray Hunter (v6ops) <[email-masked]> wrote:
> Mark Smith
> which is potentially unreliable) to perform filtering of actions in another
> cache that updates on another set of timers, there has to be some sort of
> interaction.
>
> As an example: router boots up. MLD cache is totally empty. The node on the
> LAN may have already discovered this router as its default router, and
> routing protocols may have already converged. The filter on inbound
> connections based on MLD cache should probably not be applied until the MLD
> cache is populated, and possibly a couple of update cycles completed.
>
> Another potential example: Node boots up. MLD is between refreshes and the
> router does not see a join request. Inbound connection attempt arrives.
> Router filters the connection attempt. Probably nothing to do here except
> wait for another connection attempt.
>
> Another potential example: Nodes are stressed due to an attack. Or the MLD
> polling router is stressed. MLD queries or MLD responses either are not
> sent, or go astray. MLD cache entry Source Timer times out. Node is cut off
> from external traffic by router filter. Traffic potentially subsides. Cycle
> repeats.
>

All of these are the sorts of reasons why I created the Strict and
Relaxed Mitigation Modes, after Lorenzo expressed the concern about
tying the decision to perform ND for unicast address to the success of
MLD to discover the corresponding Solicited-Node multicast groups.

> "Care should be taken to check the validity of the MLD cache before applying
> filtering, to avoid using unreliable MLD cache data, or race conditions."
>

While I understand the intent, I think it isn't actually possible to
check the validity of the MLD cache, in the sense that it isn't
possible to be absolutely sure that all Solicited-Node groups have
been discovered - there is no way to know absolutely how many groups
should be discovered to know when all of them have been.

I think what might be missing from the text is an explicit statement
that when in Strict Mitigation Mode, this method causes ND to depend
on the success of MLD in discovering the corresponding Solicited-Node
multicast groups, and that when a router is performing that discovery
for the first time, e.g., after boot, ND will fail during the MLD
discovery period. I'll add some text to that effect in the next couple
of days.

> off-link NS exhaustion attacks?

Yes, although I think there are a couple of drawbacks with it. From
what I remember when I looked at it a while back, it firstly relies on
a hub-and-spoke forwarding topology, so couldn't be supported on a
standard peer-to-peer link-layer, and secondly, it seems not to
support having more than one DAD proxy on the link.

Of course, it won't work with anycast addresses because there is no
DAD for them.

Regards,
Mark.

> Ray Hunter (v6ops)

---

From: [email-masked]
Date: Tue, 23 Feb 2016 11:59:11 +0100

Mark,

MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups.

Best regards,
Ole

> On 07 Feb 2016, at 20:25, Mark Smith <[email-masked]> wrote:
> 
> HI,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Feb 2016 07:46:58 +1300

> MLD joins for the solicited node multicast address has turned out to have little practical purpose. I am thinking of going the other way and stop sending joins for link-local multicast groups.

Yes. What is the possible use of a link-local "join"?  The packets are just there
on the link anyway, so "joining" is entirely an internal matter for each node.

However, it is the case that some switches are not transparent to LL multicasts
to arbitrary addresses. For example in some tests I did recently, the lab switch
was transparent to ff02::1 but opaque to ff02::114.

    Brian

---

From: [email-masked]
Date: Tue, 23 Feb 2016 19:53:18 +0100

> was transparent to ff02::1 but opaque to ff02::114.

it was presumably snooping on MLD and did forward when it had received a join for ff02::114?
the switch designers I've spoken to state that they cannot scale for the number of multicast groups, in particular solicited node multicast. I think they often do an exception for ff02::1 and treat that as broadcast.

cheers,
Ole

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 23 Feb 2016 13:01:06 -0600

> the switch designers I've spoken to state that they cannot scale for the number of multicast groups, in particular solicited node multicast. I think they often do an exception for ff02::1 and treat…

Newer implementations might, but many commonly deployed platforms by
default do snooping that results in loss of multicast traffic.  I think
only very modern platforms can excempt this.

Particular cases we have seen also include loss of RA's (made worse by
a router that can't do solicited unicast RA when possible).  At our site
we now have to flood all ipv6 multicast.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Feb 2016 08:07:48 +1300

> it was presumably snooping on MLD and did forward when it had received a join for ff02::114?

Possibly. I fixed the problem by inserting a dumb bridge that does what bridges
are supposed to do.

> the switch designers I've spoken to state that they cannot scale for the number of multicast groups, in particular solicited node multicast. I think they often do an exception for ff02::1 and treat…

But why not pass all LL multicasts?

Anyway, if this is common behaviour by switches it has to be allowed for.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2016 17:10:20 -0300

On 02/23/2016 07:59 AM, [email-masked] wrote:
> Mark,
> 
> MLD joins for the solicited node multicast address has turned out to
> have little practical purpose. 

Operation on swtiches that do mld-snooping?

Or am I missing something?

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

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Feb 2016 07:13:48 +1100

On 23 Feb 2016 9:59 PM, <[email-masked]> wrote:
>
> Mark,
>
> MLD joins for the solicited node multicast address has turned out to have
little practical purpose. I am thinking of going the other way and stop
sending joins for link-local multicast groups.

Well, they're mandated by the specs, and here is (what I think) is quite a
useful use for them.

I also think these SN group joins could help scale the size of virtualised
networks, because the underlay network could use them to track to which
NVE/tunnel end-points to send ND NSes to, rather than flooding them to all
NVEs/tunnel end points (the underlay network would be running a multicast
routing protocol to do this.)

Best regards,

Mark.

> > A new version of I-D,

---

From: [email-masked]
Date: Tue, 23 Feb 2016 21:27:12 +0100

> Or am I missing something?

MLD snooping apparently doesn't scale to the number of link-local multicast groups.
switches fall back to flooding. (add typically and it depends as fits).

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2016 17:58:13 -0300

> switches fall back to flooding. (add typically and it depends as fits).

Hopefully they do. I seem to recall a couple of folks complaining abut
issues associated with faulty/buggy/sloppy MLD-snooping or lack of thereof.

Cheers,