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

[Erik Nordmark <[e-mail]>]

Greg,

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.

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

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.

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

    Erik


On 1/16/14 6:14 PM, Greg Daley wrote:
> Hi Helen,
>
> I've got a couple of issues with the draft apart from IPR.
>
> It seems that principal assumption is that off-link flooding can occur due to sending packets to unknown host destinations on a subnet, and reuses the mandatory DAD-NS transmission as a proof-of-life for an address to avoid packets being transmitted on the link.
>
> Firstly, I think there could be simpler mitigation techniques for this:
> 1/ Mandate DHCP for global prefixes - which ensures that the devices send packets to routers on the link to keep their address (and limit unregistered address lookups)
> 2/ Treat on-link generated ND Cache entries (or entries which have previously been REACHABLE) as different to off-link generated (rate limit).
>
> In that case, the ND resolution behaviour for incomplete off-link is reduced and live communications cannot be impacted. There is still a potential DoS issue for initiating communications to quiet servers, but if the on-link server has ever talked to the router it could still have a STALE NCE.
>
> Secondly, the proposal assumes that DAD-NS packets are visible to all devices on the link, whereas they aren't in a Multicast-snooped environment.
>
> This implicitly requires that the router is assigned to an all-multi interface on the switch infrastructure, which it may be (but this isn't stated).  It also negates the general applicability of this to hosts (rather than routers).
>
> Neighbour Solicitation messages for incomplete entries (per RFC 4861 S7.2.2) will be dropped by the snooping switches if there is no Multicast subscriber for the solicited nodes' multicast address.  Not only is this a mitigation of the potential attack, but also indicates an alternative for non-snooping networks:
>
> 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 guess my comment is that we have two other potential solutions for mitigating transmission of off-link initiated NS's ( 1- Use DHCP bindings and 3 - MLD Solicited Nodes'), and some fair ideas for mitigating resource challenges in the ND engine (2), and decreased applicability in multicast snoop environments.
>
> Can you tell us why we should use this encumbered solution?
>
> Sincerely,
>
> Greg Daley
> [e-mail]
>
>
>
>
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Ing-Wher Chen
> Sent: Tuesday, 14 January 2014 9:53 AM
> To: [e-mail]
> Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt
>
> Please note that we're actively working with Ericsson's legal department on an IPR disclosure regarding the draft.
>
> Thanks,
> Helen
>
> -----Original Message-----
> From: Ing-Wher Chen
> Sent: Monday, January 13, 2014 2:37 PM
> To: '[e-mail]'
> Subject: FW: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt
>
> Hello,
>
> The informational draft below documents Ericsson's solution, deployed since early 2013, regarding Mikael's concern in the recent discussion about ND denial-of-service attacks.  The draft also elaborates on Lorenzo's point regarding discovering neighbors based on DAD-NS packets.
>
> Thanks,
> Helen
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Friday, January 10, 2014 4:44 PM
> To: Joel Halpern; Ing-Wher Chen; Joel Halpern; Ing-Wher Chen
> Subject: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt
>
>
> A new version of I-D, draft-halpern-6man-nd-pre-resolve-addr-00.txt
> has been successfully submitted by I. Chen and posted to the IETF repository.
>
> Name:		draft-halpern-6man-nd-pre-resolve-addr
> Revision:	00
> Title:		Triggering ND Address Resolution on Receiving DAD-NS
> Document date:	2014-01-10
> Group:		Individual Submission
> Pages:		7
> URL:            http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-halpern-6man-nd-pre-resolve-addr/
> Htmlized:       http://tools.ietf.org/html/draft-halpern-6man-nd-pre-resolve-addr-00
>
>
> Abstract:
>     This draft proposes a new optional event to trigger address
>     resolution using IPv6 Neighbor Discovery.  This helps optimize router
>     performance, and can help mitigate certain potential ND-related
>     denial-of-service attacks.  Upon receiving a DAD-NS message, the
>     neighbor solicitation message used to detect duplicate addresses, if
>     the target address encoded in the DAD-NS is not a duplicate address,
>     the receiving device responds by triggering address resolution for
>     the target address in the DAD-NS, in preparation for expectant future
>     communication with the sending device.
>
>
>
>
> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>