Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

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

Hi Greg,


----- Original Message -----
> From: Greg Daley <[e-mail]>
> To: 'Mark ZZZ Smith' <[e-mail]>; 'Ing-Wher Chen' <[e-mail]>; "[e-mail]" <[e-mail]>
> Cc: 
> Sent: Monday, 20 January 2014 9:50 AM
> Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt
> 
> Hi Mark, 
> 
> When we were looking at accelerating DAD for mobile nodes a while ago, I 
> investigated the state held by MLD and wrote a draft.
> (Now expired http://tools.ietf.org/html/draft-daley-ipv6-mcast-dad-02)
> 
> A much better solution was found (now RFC 4429), but the consistent state 
> keeping by the MLD querier (and other routers) is still present (particularly 
> for MLDv2).
> 
> (I am now thinking out loud, so please bear with me)
> 
> The difference is that the solicited nodes' address was not identical to an 
> address binding and that (after listener state synchronization) only the 
> non-presence of an MLD listener on the solicited nodes address could be used to 
> prove the address was absent.  For relatively sparse links and subnets this 
> would allow the router to state explicitly that the address was not in use.
> 
> For ND cache protection, the presence of any MLD listener on the solicited 
> nodes' activates the group, and no-listeners means there isn't even a 
> reason to transmit the neighbour solicitation.
> 

Exactly.

> Unless the router maintains additional ND cache state, it cannot distinguish 
> between an activated group and which of the addresses is active, and thus a 
> subset of the addresses (e.g. the globally routable equivalent of a Link-local 
> address with a particular solicited nodes [and anything with the same IID lower 
> order bits]).
> 

True. The presence of a solicited-node group on a link only indicates at least one of the addresses that would map to it is present.

> Is this sufficient protection, or does there have to be more specific state 
> gathered in the ND cache, perhaps through the discussed draft?
> 

I see this idea as another quite useful mitigation, but certainly not a prevention of the ND cache DoS attack.

As the number of present solicited-node groups is very unlikely to ever exceed 1% of the total available solicited-node groups (2^24/16M), that means that NSes don't have to be performed for destination addresses that map the the remaining 99% of solicited-node groups. This is in comparison to today where NSes would be performed for any unknown destination within the /64. I think that would be another measure that usefully reduces the effectiveness of the off-link ND cache DoS attack against a router. Less predictable solicited-node groups, as a result of draft-ietf-6man-stable-privacy-addresses, would further reduce the effectiveness of the off-link ND cache DoS.


I though of this idea while thinking about how MLD/solicited-node group membership might be able used to facilitate node registration, preventing the router ND cache DoS attack. It previously occurred to me that if nodes are using MLDv2, meaning that all nodes report their membership of all groups, then routers tracking solicited-node membership would now have knowledge of one of all of the attached nodes' link-local addresses (either as the nodes initialise their addresses, or because a router initiates a querier election when it initialises) . If the nodes then supported Inverse ND+, then the routers could query the nodes for their other addresses, giving them complete knowledge of all unicast addresses on all nodes, achieving complete node registration. NUD would then take care of expiring node registrations when the nodes disappear. 

This method wouldn't achieve the efficiency goals of draft-chakrabarti-nordmark-6man-efficient-nd. I think its value would be that it leverages existing mechanisms such as MLDv2 and Inverse ND, and would have a relatively low implementation cost.

Regards,
Mark.


+  or perhaps RFC4620 Node Information Queries, although I think Inverse ND might be better because it is likely to be simpler to implement, and isn't Experimental.




> Sincerely, 
> 
> Greg Daley
> 
> 
> 
> 
> -----Original Message-----
> From: Mark ZZZ Smith [mailto:[e-mail]] 
> Sent: Saturday, 18 January 2014 7:58 PM
> To: Greg Daley; 'Ing-Wher Chen'; [e-mail]
> Subject: Re: New Version Notification for 
> draft-halpern-6man-nd-pre-resolve-addr-00.txt
> 
> 
> 
> 
> 
> ----- Original Message -----
>>  From: Greg Daley <[e-mail]>
>>  To: 'Ing-Wher Chen' <[e-mail]>; 
> "[e-mail]" 
>>  <[e-mail]>
>>  Cc: 
>>  Sent: Friday, 17 January 2014 1:14 PM
>>  Subject: RE: New Version Notification for 
>>  draft-halpern-6man-nd-pre-resolve-addr-00.txt
>> 
>>  Hi Helen,
>> 
> <snip>
> 
>> 
>>  3/ Monitor the solicited nodes' addresses in the MLD querier router, 
>>  and do not transmit an NS from off-link for an incomplete address 
>>  unless someone is listening.
>> 
> 
> So I've been thinking for the last few months that this method could be a 
> useful further mitigation to off-link ND cache attacks for routers. I've 
> been writing something up which I've been planning to finish and post in the 
> next week or so.
> 
> I think it could be fairly effective - there are a total possible 2^24 
> solicited-node multicast groups on a link, where as there will only be as many 
> present ones as there are IIDs with unique lower 24 bits. For most subnets I 
> think that will number in the order of 10s or 100s, and perhaps on rare 
> occasions in the low 1000s. So NSes would only be necessary for e.g. 1000/2^24 
> portion of the unicast address space, otherwise the packets that would trigger 
> them can be dropped (or perhaps sent to an RFC6018 greynet collector).
> 
> A neighbor cache attack is likely to be still be possible for the 2^40 portions 
> of unicast address space covered by each of the the present solicited-multicast 
> groups, however Fernando's Stable/Opaque IID draft would make them harder to 
> find, even though it will increase the number of them, as there is an unique 
> Opaque IID per prefix.
> 
> All routers listening to MLD track group membership, not just the MLD querier, 
> so all routers on the link could implement this method.
> 
> Regards,
> Mark.
>