Hi Shane, On Wed, 27 Jan 2010 08:03:48 -0700 Shane Amante <sh...@castlepoint.net> wrote:
> Mark, > > On Jan 27, 2010, at 00:44 MST, 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? > > Why not have routers just look at the IPv6 "Hop Limit" (TTL) field, and > discard if hop limit < 255? (Of course, you'd still want to apply an > "infrastructure" ACL with GTSM so NMS systems still have visibility to your > p2p interfaces, but that shouldn't be terribly difficult). > > Have a look at RFC 5082: <http://tools.ietf.org/html/rfc5082> for GTSM. > Are you talking about protecting against neighbor solicitations that are originated off link? If that is that case, that's not the problem I talking about. I've realised the subject line might not have made that quite clear - I've changed it to hopefully make it so. Here's the steps to cause it: 1. target prefix is a globally routable /64 2. off-link located (e.g. Internet) attacker sends a high rate of packets (any type) towards incrementing or random addresses within that /64 e.g. ::1, ::2, ::3, etc. etc. 3. the router attached to the target /64 will generate neighbor solicitations for those non-existant destinations, towards it's directly attached target /64. According to RFC2461, the default total timeout for these NSes is 3 seconds. As the router keeps state for the outstanding neighbor solicitations, if the rate the attacker is sending traffic with changing host addresses is high enough, the state tables in the router may be exhausted, resulting in a denial of service. The router might appear to need to hold 2^64 outstanding Neighbor Solicitation table entries to survive this attack, however, as destinations for Neighbor Solicitations are mapped to Solicited Node multicast addresses, using the lower 24 bits, the router would have to "only" hold 2^24 outstanding Neighbor Solicitation entries, which still 16 million+. Admittedly with 64 byte packets, to go through all 2^24 Solicited Node multicast addresses the attacker would have to send around 2.8 Gpbs of traffic - receiving that much traffic might be a bigger problem. To create 65 535 neighbor solicitation table entries, which a router could still struggle with (e.g. low-end residential CPE) would only require around 11 Mbps of traffic, which is much more commonly achievable. I think the fundamental issue is that a remote attacker can use traffic to create remote network device state. That is also the case with IPv4 with ARP tables, however because the subnets in IPv4 are commonly small, IPv4 has been protected from this type of attack. Ideally, the local router should only issue neighbor solicitations onto the attached /64 for Solicited Node multicast addresses that exist, avoiding unnecessary traffic, and avoiding creating unnecessary router state for Neighbor Soliciations that will never be answered. My Linux box issues MLD announcements for these Solicited Node multicast addresses when an interface comes up, and it responds to MLD General Queries for those multicast addresses. The IPv6 Node Requirements RFC says MLD is a required feature, so I think it can be relied on that most if not all IPv6 implementations will make MLD announcements for Solicited Node addresses. I think those MLD announcements could be used by routers to build a Solicited Node validation list, allowing them to filter out Neighbor Solicitations, protecting against this type of attack. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
