Hi Mark, Just a quick note. If I understand your problem correctly, I'd suggest reading the following paper as it decsribes a mechanism to mitigate the ND DoS attack launched from outside:
http://planete.inrialpes.fr/%7Eccastel/PAPERS/infocom05.pdf Regards, Wassim H. On Jan 27, 2010, at 12:44 AM, Mark Smith wrote: > Hi, > > > There have been a few discussions on a few operational mailing lists in > the last few weeks about the use of longer than /64s on point-to-point > links. > > One valid reason to do so is to mitigate a Neighbor Discovery DoS, > initiated by off-link sources sending traffic to incrementing > destinations, causing the on-link router to issue large numbers of > Neighbor Solicitations towards Solicited-Node multicast destinations > for nodes that don't exist. > > RFC3756 described this vulnerability in section 4.3.2, "Neighbor > Discovery DoS Attack". > > This issue isn't specific to point-to-point links. Any /64 is > vulnerable. People who're advocating longer than /64s for > point-to-point links as a mitigation for this issue can also advocate > using prefix lengths longer than /64 for all IPv6 subnets. > > As I'm an advocate for the simplicity of using /64s for all links, I've > been thinking how this issue could be avoided, without having to resort > to longer than /64s, or other manual methods such as traffic filtering > ACLs or static neighbor discovery entries. > > At the end of the description of the issue, RFC3756 mentions > > "This attack does not directly involve the trust models presented. > However, if access to the link is restricted to registered nodes, and > the access router keeps track of nodes that have registered for access > on the link, the attack may be trivially plugged. However, no such > mechanisms are currently standardized." > > I think Multicast Listener Discovery announcements for hosts' > memberships of the Solicited Node multicast addresses could be used as > this "membership registration" mechanism. When a router is asked > to issue a neighbor solicitation for a downstream host, after it > converts the destination address into a Solicited Node multicast > address, is could then validate that multicast address against a list > of known Solicited Node multicast addresses it has learned from the > hosts via their MLD announcements. Neighbor Solications for Solicited > Node multicast addresses that aren't known would be dropped, preventing > off-link nodes from exhausting the router's neighbor discovery > resources. > > Do people think using MLD announcements in this way would be suitable > way to mitigate this DoS while preserving the simplicity of > universal /64s? > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- Regards, Wassim H.
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
