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

[Mark ZZZ Smith <[e-mail]>]

Hi Eric,

Thanks for your time and comments.

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) <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>; V6 Ops List <[e-mail]>
> 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, 
> 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.

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

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


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
> to miss it for the router, for many reasons (split network, no retry,
> 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
> 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).

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.

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

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.

> 

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

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.


> Eric
> 
> 
> 
> On 07/04/14 23:21, "Mark ZZZ Smith" <[e-mail]> 
> wrote:
> 
>> Hi,
>> 
>> I've just posted the following ID, grateful for any feedback.
>> 
>> Regards,
>> Mark.
>> 
>> 
>> ----- Forwarded Message -----
>>>  From: "[e-mail]" 
> <[e-mail]>
>>>  To: Mark Smith <[e-mail]>; Mark Smith
>>> <[e-mail]>
>>>  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-ml
>>> d-slctd-node-00.txt
>>>  Status:        
>>> 
>>> https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-s
>>> lctd-node/
>>>  Htmlized:      
>>> 
>>> http://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-n
>>> ode-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
>>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>