Hi Erik, On Thu, 28 Jan 2010 02:39:06 -0800 Erik Nordmark <[email protected]> wrote:
> On 01/26/10 11:44 PM, Mark Smith wrote: > > > 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? > > The "join delay" for MLD is unpredictable since the reliability of the > MLD reports is based on a few initial ones (which could all be lost) > plus router-triggered slow rate MLD queries. That join delay doesn't > seem to cause a problem for today's multicast applications, but I would > be quite concerned if the host couldn't communicate at all during this > delay, which would be the effect of your proposal. > Just to ensure we're on the same page, this checking of known Solicited Node addresses would only be performed for Neighbor Solicitations tiggered by traffic with off-link sources. Hosts within the subnet would still be able to communicate with each other, even if the MLD reports were lost. > I think the correct thing architecturally is to actually introduce a > reliable "registration" mechanism for hosts. There are other good > reasons for it such as avoiding low-power devices being woken up by > multicast NS messages especially when the L2 uses broadcast to deliver > multicast packets. (Work in 6lowpan has explored this space, but I don't > think draft-ietf-6lowpan-nd is quite what we need.) > > If this is construed as a security issue one can probably come up with > combinations of MLD and also the routers hearing the hosts (which they > do if the hosts send RSs as they power on) that could minimize the > probability of hosts being unreachable during the MLD join delay even if > the MLD reports are lost. But I view that as a short-term approach which > needs to be replaced by a registration mechanism. > A registration mechanism would definitely address this issue. I think it is security issue unfortunately. All that is needed to exploit it is a short script with a looping integer, standard IPv6 ping utility and low numbers of megabits of bandwidth to create unanswered NSes in the 1000s. Are there any creative ways we can make the existing MLD mechanisms a bit more robust, without having to change the protocols, and avoiding changing the hosts (only having to change router code would be much easier at this point in time I think)? Maybe something like when a router responds to a RS, or issues it's periodic RAs, it also issues an MLD general query to ensure it's Solicited Multicast address list is kept accurate? Or possibly when a Router Solicitation is received, in addition to responding with an RA, it also issues a Multicast Address Specific query for the Solicited Node Address calculated from the link-local address source of the RS? > Note that the RSs don't list all the hosts' IP addresses - the source is > a link-local address. Thus the logic in the router needs to be able to > compare just N low order bits. If a RS has been send from link local > fe80::0:1:2:3 then the router needs to be able to send NSs for anything > in Prefix::0:1:2:3. Listening to the MLD has a similar property since > the solicited-node multicast address is just a match on the bottom 32 > bits of the IPv6 address. > That's true. What we're fundamentally trying to do here is to supress Neighbor Solicitations for Solicited Node groups that don't have any members, avoiding the corresponding neighbor discovery state. With 2^24 Solicited node groups*, but practical limits of only a few 1000 hosts on a link, there potentially will be a very large number of Solicited Node groups that don't have any members. * My understanding is that the Solicited Node address is created from the bottom 24 bits of the IPv6 address, and then the lower 32 bits of that Solicited Node address is copied into the Ethernet 33:33: address. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
