Hi, Here's a new version of my "Mitigating IPv6 Router Neighbor Cache DoS
Using Stateless Neighbor Discovery" draft. Changes since my last submitted version (-01): o moved opportunities for SLND section to before SLND description o spit SLND into basic functionality and optional enhancements o use of ingress interface and other more general packet attributes to determine trust I've thought a fair bit about whether it is worth having a two level response to a ND cache DoS i.e. at a lower threshold, perform stateless neighbor discovery for only some of the untrusted sources, and if the neighbor cache fills further, move to performing stateless neighbor discovery for all untrusted sources. Considering the additional complexity required and that this mechanism is only ever going to be used in response to a rare event, I don't really think it is justified. Thanks to Karl Auer and Oliver Ddin for their reviews and comments. Thanks very much, Mark. ----- Forwarded Message ----- >From: "[email protected]" <[email protected]> >To: [email protected] >Sent: Saturday, 10 November 2012 9:45 PM >Subject: New Version Notification for >draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt > > >A new version of I-D, draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt >has been successfully submitted by Mark Smith and posted to the >IETF repository. > >Filename: draft-smith-6man-mitigate-nd-cache-dos-slnd >Revision: 05 >Title: Mitigating IPv6 Router Neighbor Cache DoS Using Stateless >Neighbor Discovery >Creation date: 2012-11-10 >WG ID: Individual Submission >Number of pages: 12 >URL: >http://www.ietf.org/internet-drafts/draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt >Status: >http://datatracker.ietf.org/doc/draft-smith-6man-mitigate-nd-cache-dos-slnd >Htmlized: >http://tools.ietf.org/html/draft-smith-6man-mitigate-nd-cache-dos-slnd-05 >Diff: >http://www.ietf.org/rfcdiff?url2=draft-smith-6man-mitigate-nd-cache-dos-slnd-05 > >Abstract: > The IPv6 neighbor discovery cache is vulnerable to a Denial of > Service attack that purposely exhausts the state used during the > neighbor discovery process. This attack can be very disruptive when > the target is a router. This memo proposes a stateless form of > neighbor discovery to be used by routers to mitigate this attack. It > does not require any changes to hosts. > > > > > >The IETF Secretariat > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
