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

["Joel M. Halpern" <[e-mail]>]

Let me see if I can help a bit.

Firstly, we are trying for something that works with the existing 
specified Ipv6 deployments.  So mandating DHCP, and DHCP-guard, was not 
a choice we felt we could take.   Using DHCP, dhcp-guard, and dhcp 
derived mechanisms to fill the router table is indeed a viable 
alternative for operators who wish to run their networks that way.

Secondly, we are specifically concerned with the off-link based denial 
of service attack.  Where the attack attempts to fill either the link 
(hard) or the router cache in such a way as to interfere with legitimate 
address resolution and communication.  The use of multicast by IPv6 ND 
is understood and assumed.  It does not help when the router is the 
target of the external attack.

Yours,
Joel

On 1/16/14 9: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
> --------------------------------------------------------------------
>