Re: draft-halpern-6man-nd-pre-resolve-addr-00.txt

[Ing-Wher Chen <[e-mail]>]

> -----Original Message-----
> From: Erik Nordmark [mailto:[e-mail]]
> Sent: Friday, January 17, 2014 9:02 PM
> To: Greg Daley; Ing-Wher Chen; [e-mail]
> Subject: Re: New Version Notification for draft-halpern-6man-nd-pre- 
> resolve-addr-00.txt
>  ...
> In addition to your concern about multicast snooping environments, the 
> DAD packets are not reliably delivered. If e.g. there is a short WiFi 
> drop, the spanning tree is reconverging, etc then the single 
> transmitted DAD packet will not be received.

No ND packets are reliably delivered.  So this is not different from any other ND traffic.

> Thus as best this will collect some entries in the neighbor cache.

We agree that the approach in the draft might not capture all neighbors.
However, when a router is under an off-link attack, having this additional
source of target addresses will mean that the router can continue to service
new hosts, as it sees them.  The alternative, without the approach in the draft,
is that the router does not service any additional new hosts, starting from
the time the router is under attack.  (The DAD-NS approach can be seen as a
heuristic to distinguish legitimate target addresses from invalid target addresses.)  

In short, using the approach in the draft will yield a better result than not using it.
Since DOS attacks are impossible to prevent in the general case, all that can be
done -- by any mechanism -- is to reduce the impact of such attacks.  This approach
does reduce the impact of such attacks.

> It isn't at all clear when a node should discard entries from its 
> neighbor cache. That is potentially problematic when there are lots of 
> devices that pick new temporary IPv6 addresses each time they power on 
> since that will force routers to sooner or later discard entries from 
> the neighbor cache. The routers would have to guess which addresses 
> might still be assigned to the hosts.

We rely on Neighbor Unreachability Detection to remove stale neighbors, as specified
by the existing IETF ND standards.  We believe the standards make this clear.  We are
happy to cite the existing ND standards in this area (NUD to remove stale neighbors)
more explicitly in a future version of this draft.

> Thus all in all this is not a robust approach to the problem.

There is no perfect solution to a DOS attack.  This method yields better results than
not using this method, reducing the severity of the attack in a measurable way.

Thanks,
Helen