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

From: Ing-Wher Chen <[email-masked]>
Date: Tue, 21 Jan 2014 00:09:56 +0000

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Friday, January 17, 2014 9:02 PM
> To: Greg Daley; Ing-Wher Chen; [email-masked]
> 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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Jan 2014 17:57:48 -0800

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

The DAD probe is different that NS messages used for address resolution. 
For address resolution the NS is retransmitted (3 times) until there is 
a response.

But the DAD probe is single (multicast) NS message, and if there is no 
response in one second then the node will conclude that there is no 
duplicate.

Thus if there is packet loss (e.g., on WiFi where multicast packets 
don't get ARQ), or on wired Ethernet with a spanning tree reconvergence 
when the DAD probe is sent, then the prober will incorrectly assume it 
is not a duplicate.

RFC 4862 talks about this lack of guarantees in section 5.4.

> heuristic to distinguish legitimate target addresses from invalid target addresses.)

I don't think you need to do anything special with DAD to accomplish 
that. When a new host appears it will send other packets to the router 
(the first might be either a RS or a NS depending on the host 
implementation) which includes a source IPv6 address and a source 
link-layer address. The router would (according to RFC 4861) populate 
the neighbor cache based on the source information that RS or NS.

What does overloading the DAD probe do in addition?

> In short, using the approach in the draft will yield a better result than not using it.

Please provide more information.

Do you have studies of existing implementations that show that they do 
not populate the neighbor cache based on the source of the RS or NS?

Is that an implementation issue or a standards issue?

> does reduce the impact of such attacks.

In don't see how it reduces the impact assuming the host and router 
follows RFC 4861.

> more explicitly in a future version of this draft.

But NUD only comes into play if there is traffic towards those IP 
addresses. An implementation needs a strategy to garbage collect NCEs in 
the absence of traffic that would trigger NUD.

    Erik

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>