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

[Greg Daley <[e-mail]>]

Hi Mark, 

I guess it is for others to identify if the protection is sufficient, I would just like to show that there is a feasible mitigation with MLD.

[chop]

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

I think that the value principally comes from the mandatory nature of MLD (though in MLDv1, a node can fail to transmit a report IFF there is another member of the group that has visibly reported - which activates the group anyway).

Additional information is probably extraneous and is limited by the fact that devices may not have implemented particular capabilities (i.e. they are not required by the Node Requirements RFC6434)

Greg Daley