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

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
gdaley@au.logicalis.com 

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ing-Wher Chen
Sent: Tuesday, 14 January 2014 9:53 AM
To: ipv6@ietf.org
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: 'ipv6@ietf.org'
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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------