Subject: [v6ops] Fw: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 7 Apr 2014 14:21:10 -0700 (PDT)

Hi,

I've just posted the following ID, grateful for any feedback.

Regards,
Mark.

----- Forwarded Message -----
> From: "[email-masked]" <[email-masked]>
> To: Mark Smith <[email-masked]>; Mark Smith <[email-masked]>
> Cc: 
> Sent: Tuesday, 8 April 2014 7:19 AM
> Subject: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
> 
> 
> A new version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.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:    00
> Title:        Further Mitigating Router ND Cache Exhaustion DoS Attacks Using 
> Solicited-Node Group Membership
> Document date:    2014-04-07
> Group:        Individual Submission
> Pages:        6
> URL:            
> http://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/
> Htmlized:      
> http://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00
> 
> 
> 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 group membership can be used by routers to further
>    mitigate the 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: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 8 Apr 2014 16:24:29 +0000

I have several different thoughts on this. First is to wonder whether it fits this forum; it might fit better in 6man or savi. I have copied the 6man chairs on this for their comment.

As I understand it on a quick read, you talk about how a Solicited Node Multicast works, and point out that there is no point sending out a Solicited Node Multicast (the counterpart to an ARP Broadcast) at L2 if nobody has joined the indicated group at L3. That’s a very interesting observation, and worth considering.

A corollary to that might be related to draft-ietf-savi-dhcp and/or RFC 6620; a SAVI switch configures filters to deny all traffic it doesn’t permit, and permits IPv6 traffic to be originated from a given port if and only if it uses a source address that has been allocated to (DHCP) or DAD verified by (SLAAC) a device on the port. One might similarly or additionally observe that a host that doesn’t join the relevant multicast group cannot be reached by the network, and therefore should not be injecting traffic into the network, making joining the SNM Group a condition of authorization to use the network. 

What is the relationship between this and Optimistic ND? RFC 4429. 

What are the operational considerations appropriate to this?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 9 Apr 2014 13:13:19 +0900

On Wed, Apr 9, 2014 at 1:24 AM, Fred Baker (fred) <[email-masked]> wrote:

> there is no point sending out a Solicited Node Multicast (the counterpart
> to an ARP Broadcast) at L2 if nobody has joined the indicated group at L3.
>

I'd love for this to be usable, because it would also solve many of the
debates regarding excessive multicast. Unfortunately, the usual
counterarguments to this are:

   1. MLDv2 state is not reliable. MLD messages are only sent out once and
   not acknowledged, and some implementations don't send them at all. Since
   failing to resolve a L3 address to a L2 address causes unrecoverable
   failure to communicate, basing ND on an unreliable protocol is a Bad Idea.
   Yes, you can always send out NSes as a fallback in case you have no MLD
   state for that address, but then you've just gone back to the DOS
   vulnerability you were trying to avoid.
   2. If the router loses state, it won't know who is listening to what
   addresses. I suppose this could be solved by having the router send out an
   MLDv2 "general query" at boot, shortly after having sent its first periodic
   RA, but that has scaling limitations: if there are 5k hosts on-link, the
   router might well receive well over 10k packets (one for each autoconf
   address, and one for each stable-privacy or temporary address) will
   probably drop some of those packets, and then we're back to the reliability
   problem we had in #1.

I don't know if these issues can be fixed.

Cheers,
Lorenzo

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 9 Apr 2014 06:30:53 +0000

On Apr 8, 2014, at 9:13 PM, Lorenzo Colitti <[email-masked]> wrote:

> there is no point sending out a Solicited Node Multicast (the counterpart to an ARP Broadcast) at L2 if nobody has joined the indicated group at L3.
> 
> I'd love for this to be usable, because it would also solve many of the debates regarding excessive multicast. Unfortunately, the usual counterarguments to this are:
> MLDv2 state is not reliable. MLD messages are only sent out once and not acknowledged, and some implementations don't send them at all. Since failing to resolve a L3 address to a L2 address causes unrecoverable failure to communicate, basing ND on an unreliable protocol is a Bad Idea. Yes, you can always send out NSes as a fallback in case you have no MLD state for that address, but then you've just gone back to the DOS vulnerability you were trying to avoid.
> If the router loses state, it won't know who is listening to what addresses. I suppose this could be solved by having the router send out an MLDv2 "general query" at boot, shortly after having sent its first periodic RA, but that has scaling limitations: if there are 5k hosts on-link, the router might well receive well over 10k packets (one for each autoconf address, and one for each stable-privacy or temporary address) will probably drop some of those packets, and then we're back to the reliability problem we had in #1.

From what I have been told internally, there are hosts that don’t make MLD “Join” announcements, and those that do fire once and forget. If the message doesn’t get through, it doesn’t get through. One could send a request, but then every guy on the LAN responds, with the exception o those that don’t MLD.

> I don't know if these issues can be fixed.

Make things as simple as possible, but not simpler.
Albert Einstein

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 13 Apr 2014 01:17:11 -0700 (PDT)

Hi Fred,

Thanks for your time and comments.

----- Original Message -----
> From: Fred Baker (fred) <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>
> Cc: V6 Ops List <[email-masked]>; "<[email-masked]>" <[email-masked]>
> Sent: Wednesday, 9 April 2014 2:24 AM
> Subject: draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
> 
> I have several different thoughts on this. First is to wonder whether it fits 
> this forum; it might fit better in 6man or savi. I have copied the 6man chairs 
> on this for their comment.
> 
> As I understand it on a quick read, you talk about how a Solicited Node 
> Multicast works, and point out that there is no point sending out a Solicited 
> Node Multicast (the counterpart to an ARP Broadcast) at L2 if nobody has joined 
> the indicated group at L3. That’s a very interesting observation, and worth 
> considering.
> 

Yes, that is correct.

> A corollary to that might be related to draft-ietf-savi-dhcp and/or RFC 6620; a 
> SAVI switch configures filters to deny all traffic it doesn’t permit, and 
> permits IPv6 traffic to be originated from a given port if and only if it uses a 
> source address that has been allocated to (DHCP) or DAD verified by (SLAAC) a 
> device on the port. One might similarly or additionally observe that a host that 
> doesn’t join the relevant multicast group cannot be reached by the network, and 
> therefore should not be injecting traffic into the network, making joining the 
> SNM Group a condition of authorization to use the network. 
> 

I haven't looked thoroughly at that yet, although there doesn't seem to be any mention of "MLD", "Solicited" or "Multicast", so I presume that it doesn't change any of the Solicited-Node multicast group join/leave behaviour.

One thing to note is that this method would not be using the Solicited-Node membership for tentative addresses, as those MLD Reports are ignored by routers (identified by using the :: address as their source). 

> What are the operational considerations appropriate to this?

Broadly I don't think there really should be any, as it is taking advantage of required behaviour of hosts when they have configured their address(es).

Thanks again,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 13 Apr 2014 02:25:21 -0700 (PDT)

Hi Lorenzo,

Thanks for you time and comments.

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: Fred Baker (fred) <[email-masked]> 
>Cc: Mark ZZZ Smith <[email-masked]>; "<[email-masked]>" <[email-masked]>; V6 Ops List <[email-masked]> 
>Sent: Wednesday, 9 April 2014 2:13 PM
>Subject: Re: [v6ops] draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
> 
>
>
>    1. MLDv2 state is not reliable. MLD messages are only sent out once and not acknowledged,

My answer would be that if MLD isn't currently reliable enough for this use, then it isn't currently reliable for any multicast application use, as the MLD procedures for Solicited-Node group membership are no different to those for any other multicast groups.

I think that means work needs to go into making MLD more reliable, or, alternatively, for those links for which it isn't reliable enough (I'm guessing people would be thinking a busy wifi network), then treating the link as an RFC2491 IPv6 over NBMA link would make the MLD procedures reliable.

> and some implementations don't send them at all.

I'd think they'd be classed as broken implementations. I'm curious as to which implementations they are? I did some rough testing before I wrote the I-D, and found that Linux/Android and IIRC, Apple iOS devices do the right thing.

If those implementations don't send MLD reports claim to implement MLDv1, then RFC2710 explicitly says that MLD messages are sent for Solicited-Node multicast addresses:

"MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR- ARCH], except for the link-scope, all-nodes address (FF02::1)."

That text was removed from MLDv2 (RFC3810), however RFC4861 re-stated it:

"The set of addresses assigned to an interface may change over time. New addresses might be added and old addresses might be removed [ADDRCONF].  In such cases the node MUST join and leave the solicited-node multicast address corresponding to the new and old addresses, respectively.  Joining the solicited-node multicast address is done using a Multicast Listener Discovery such as [MLD] or [MLDv2] protocols.  Note that multiple unicast addresses may map into the same solicited-node multicast address; a node MUST NOT leave the solicited-node multicast group until all assigned addresses corresponding to that multicast address have been removed."

I also looked at what RFC4890, "Recommendations for Filtering ICMPv6 Messages in Firewalls" said about filtering of MLD messages, and it does not advise to filter them.

With the age of these requirements e.g. RFC2710 (1999), there has been plenty of time for implementations to do the correct thing. I wonder how tolerant it is necessary to be of implementations that don't follow requirements in specifications?

In this case, I'd think the majority of implementations would do the right thing, and for the implementations they don't, it would be better to prevent them working at all than disable the protection this method would provide to the correct implementations. IOW, reward and protect the majority doing the right thing, penalise the minority that don't.

(I think it would be best that this measure is on by default, I could put some text in the next revision to say that it must be possible to switch this mitigation method off if necessary to accommodate hosts that don't correctly issue MLD join the Solicited-Node multicast group, if it isn't possible to fix them.)

> Since failing to resolve a L3 address to a L2 address causes unrecoverable failure to communicate, basing ND on an unreliable protocol is a Bad Idea. Yes, you can always send out NSes as a fallback in case you have no MLD state for that address, but then you've just gone back to the DOS vulnerability you were trying to avoid.
>

Agree.

>    2. If the router loses state, it won't know who is listening to what addresses. I suppose this could be solved by having the router send out an MLDv2 "general query" at boot,

Multicast routers should do exactly this when they bring up their interface, as part of the election of a Querier, sending out multiple queries.

> shortly after having sent its first periodic RA, but that has scaling limitations: if there are 5k hosts on-link, the router might well receive well over 10k packets (one for each autoconf address, and one for each stable-privacy or temporary address) will probably drop some of those packets, and then we're back to the reliability problem we had in #1.
>

MLD has measures in it to spread responses to Queries out over a time period specified in the query (Maximum Responde Delay).

More generally, I've noticed that these sorts of more extreme and corner cases are starting to be used to dismiss solutions that would work for the common cases. That's not to say that some people aren't building them, but I wonder if that means that if people want to build them, they need to stop expecting protocols and methods that work for common cases (such as 100s of hosts, or perhaps low 1000) to scale up well beyond what was likely to be the original design requirement.

I wonder if the large IPv6 address space in a /64 subnet is inadvertently setting an incorrect expectation that IPv6 subnets can have many orders of magnitude more hosts attached than the equivalent IPv4 subnets, and that the protocols to support link operation, such as RAs, ND and MLD have also been designed to scale that large.

Actually, I understand the use of Solicited-Node multicast groups and MLD messages for use by snooping switches, instead of link-layer broadcasts i.e., IPv4 ARPs, is to allow the number of hosts on a link to be increased. So if MLD is failing to be reliable, and therefore IPv6 NSes are being flooded to all hosts, perhaps that is a or another sign that the link-layer has too many hosts attached to it, and it needs to be partitioned.

Thanks very much,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 14 Apr 2014 12:37:20 +0900

On Sun, Apr 13, 2014 at 6:25 PM, Mark ZZZ Smith
<[email-masked]>wrote:

> My answer would be that if MLD isn't currently reliable enough for this
> use, then it isn't currently reliable for any multicast application use, as
> the MLD procedures for Solicited-Node group membership are no different to
> those for any other multicast groups.
>
> I think that means work needs to go into making MLD more reliable, or,
> alternatively, for those links for which it isn't reliable enough (I'm
> guessing people would be thinking a busy wifi network), then treating the
> link as an RFC2491 IPv6 over NBMA link would make the MLD procedures
> reliable.
>

All I'm saying is that the document should determine and very clearly
document the reliability of what it is proposing. Perhaps there's something
I'm missing, but it seems to me that if for whatever reason the router
misses the MLD join for an IP address, then no packets can be sent to that
IP address, ever - or at least until the host leaves and joins again.

It seems to me that regardless of whether the link-layer is a busy wifi
network or a gold-plated fiber network, making usability of an IP address
completely contingent on one unacknowledged packet sent at the beginning of
its lifecycle won't work in many networks. Packets get lost. CPUs get
overwhelmed. Cables blip when people touch them.

"Make MLD more reliable" is a non-trivial exercise, and it won't help
current implementations. "Treat the link as NBMA" might work (I don't know
anything about it), but if so, then it needs to be clearly stated that this
requires fundamentally changing the subnet model.

> More generally, I've noticed that these sorts of more extreme and corner
> cases are starting to be used to dismiss solutions that would work for the
> common cases. That's not to say that some people aren't building them, but
> I wonder if that means that if people want to build them, they need to stop
> expecting protocols and methods that work for common cases (such as 100s of
> hosts, or perhaps low 1000) to scale up well beyond what was likely to be
> the original design requirement.
>
> I wonder if the large IPv6 address space in a /64 subnet is inadvertently
> setting an incorrect expectation that IPv6 subnets can have many orders of
> magnitude more hosts attached than the equivalent IPv4 subnets, and that
> the protocols to support link operation, such as RAs, ND and MLD have also
> been designed to scale that large.
>

Well, but to be fair, it would be nice to allow that sort of scalability.

> Actually, I understand the use of Solicited-Node multicast groups and MLD
> messages for use by snooping switches, instead of link-layer broadcasts
> i.e., IPv4 ARPs, is to allow the number of hosts on a link to be increased.
> So if MLD is failing to be reliable, and therefore IPv6 NSes are being
> flooded to all hosts, perhaps that is a or another sign that the link-layer
> has too many hosts attached to it, and it needs to be partitioned.
>

To some extent what you say is true - ND is much more efficient than
broadcast ARP.

The problem with comparing ND to ARP based on the protocols themselves is
that today, at least in many networks, ARP is not a ARP any more. The
packet format is the same, but it's not a broadcast. The host might send
out a broadcast, but that's dropped and, depending on how many layering
violations are being performed, the first-hop router or the AP reply
unicast from their ARP cache, or, again depending on how many layering
violations are being performed, from the DHCP lease database.

So today people are building IPv4 wireless networks with 10k clients and
/16 subnets of RFC1918 space. If plain ARP were in use such a network would
melt down instantly, but since ARP requests are proxied by the AP, things
"work" - sort of.

---

From: "Eric Levy- Abegnoli (elevyabe)" <[email-masked]>
Date: Wed, 16 Apr 2014 16:24:45 +0000

Hi, 
I took a look at the draft, and found it "protocolly" interesting but
"operationally" flawed.
- some host stacks (last time I checked was a few years ago, so hopefully
that has changed) don't bother sending the MLD join for solicited-node
groups, mainly because it's not very relevant. Currently, stacks don't
bother storing mld state received in join, for any link-local scope mc,
and simply forward multicast regardless (I understand that the draft is
suggesting to make them relevant, but the amount of router-to-network
interactions is not worth the value in my opinion).  And the fact that so
far, these states were useless make me think there are not generally
available.

- When the MLD join is sent, it is sent once, when link goes up. It's easy
to miss it for the router, for many reasons (split network, no retry,
reboot, etc.). The router could send a periodic MLD query, but that would
generate quite a bit of overhead, and I suspect that while some host
stacks still bother sending the mld report on link-up, they might not
bother sending then on mld-query (I don't know that for a fact).
Bottom line, the router is not likely to have an accurate table at any
given time of all listeners (even if it polls, can't do it too often for
obvious scalability reasons).
So we can't really base a resolution decision on this table (unless the
router is under attack and has no other choice).

- In addition, to come back to the purpose (mitigate resolution DoS), it
would "only: divide by 2**24 the address space. So a DoS attack would
still have plenty of addresses to use for his attack (2**40 per known
address, which is way enough to fill a cache).

If this is "just" to mitigate a DoS resolution attack, it would be more
efficient to store the (savi) binding table on the router, so that it
knows the address, not the the slctd (I think someone proposed a solution
like that at last ietf).
Eric

On 07/04/14 23:21, "Mark ZZZ Smith" <[email-masked]> wrote:

>> Subject: New Version Notification for
>>draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
>> 
>> 
>> A new version of I-D,
>>draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 19 Apr 2014 21:35:03 -0700 (PDT)

Hi Eric,

So I've been doing some further investigation in to host stack MLD behaviour. I haven't finished that, however I can address some points below, which have also been raised by Lorenzo.

----- Original Message -----
> From: Eric Levy- Abegnoli (elevyabe) <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>; V6 Ops List <[email-masked]>
> Cc: 
> Sent: Thursday, 17 April 2014 2:24 AM
> Subject: Re: [v6ops] Fw: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
> 
> Hi, 
> groups, mainly because it's not very relevant.

Linux (Fedora 20) does and probably that means Android does. I'm running up some Windows VMs to see what that does (http://www.modern.ie/ for a legal variety of them).

Apart from being required by RFC2710 and RFC4862, hosts have an interest in sending these so that MLD snooping layer 2 devices can suppress unwanted multicasts to them.

If it was quite a while ago, then perhaps these hosts were IPv6 implementations that existed before MLDv1/RFC2710, as RFC2710 introduced the requirement to join the Solicited-Node multicast groups.

One broader question I have is how much tolerance for lack of features in implementations is necessary? RFC2710 was published in 1999, and the IPv6 Node Requirements RFC from 2006 made MLD a requirement. Implementations before RFC2710 aren't going to support off-link sourced multicast applications, because they can't tell a router they want to join multicast groups.

> Currently, stacks don't

> - When the MLD join is sent, it is sent once, when link goes up.

Firstly, note that from the perspective of MLDv1/MLDv2, there is nothing special about Solicited-Node multicast groups. So the standard MLDv1/MLDv2 join etc. procedures apply.

In the case of RFC2710/MLDv1 it is recommended to send more than one:

"  When a node starts listening to a multicast address on an interface,
   it should immediately transmit an unsolicited Report for that address
   on that interface, in case it is the first listener on the link.  To
   cover the possibility of the initial Report being lost or damaged, it
   is recommended that it be repeated once or twice after short delays
   [Unsolicited Report Interval].  (A simple way to accomplish this is
   to send the initial Report and then act as if a Multicast-Address-
   Specific Query was received for that address, and set a timer
   appropriately)."

In the case of MLDv2, they explicitly made sending at least two MLD state change reports a requirement:

"  As opposed to Current State Reports, State Change Reports are
   retransmitted several times, in order to avoid them being missed by
   one or more multicast routers.  The number of retransmissions depends
   on the so-called Robustness Variable.  This variable allows tuning
   the protocol according to the expected packet loss on a link.  If a
   link is expected to be lossy (e.g., a wireless connection), the value
   of the Robustness Variable may be increased.  MLD is robust to
   [Robustness Variable]-1 packet losses.  This document recommends a
   default value of 2 for the Robustness Variable (see section 9.1)."

> It's easy
> reboot, etc.). The router could send a periodic MLD query,

That is what the designated querier multicast router does to track the continued existence of multicast group presence on a link. Solicited-Node multicast group membership is reported in response to these queries.

These queries are sent approximately once every 2 minutes respectively by MLD or MLDv2. That would too long to wait to discover Solicited-Node membership for a new device if the initial reports had been lost. It's tempting to suggest setting this interval to something much lower e.g. 3 to 5 seconds, however that is really trying to make up for the lack of reliability of implementations that haven't either followed the recommendations in MLDv1 or the requirements in MLDv2 for group joins. While I think tolerating faulty or unreliable implementations is generally a good thing, I always wonder how far to go before saying, "the implementation is too broken, can't be supported."

> but that would

If it doesn't, the MLD/MLDv2 has failed to successfully discover multicast listeners. That means the all of the following won't work reliably:

- the method proposed in this memo

- MLD snooping by layer 2 devices

- all multicast applications where the multicast sources are off-link

While I accept that the consequences of this DoS mitigation method failing are the most severe (all off-link unicast fails), end-users will probably consider the failure of off-link multicast applications to be nearly as severe - they just expect things to work, and don't really care why they don't.

So if MLD is failing, something needs to be done to make it more reliable, either tuning, or fixing of the MLD/MLDv2 protocol.

I accept that this method could uncover the lack of MLD reliability on a link, that hasn't previously been discovered because off-link source multicast applications haven't been used. I'll have a think about that case further.

> address, which is way enough to fill a cache).

True, as I've described in the Security Considerations section. This is not a stand alone method, I think it is a further compliment to other methods to protect the ND cache.

Ultimately the only way to absolutely solve this problem is to have a node registration protocol, so that routers have absolute knowledge of all hosts. However, in the interim, I think methods such as this one can be useful mitigations.

> knows the address, not the the slctd (I think someone proposed a solution

I think one of the advantages of this method is that it is likely to require very minimal changes to routers' implementations of features they probably already have - enabling MLDv1/MLDv2 capability all of the time rather than just when it is a multicast (forwarding) router, and a slight change to their neighbor discovery procedure.

Thanks,
Mark.