A quick thought on one of your points, before I go to bed :-) On Thu, 28 Jan 2010 04:34:11 -0800 Erik Nordmark <[email protected]> wrote:
> On 01/28/10 03:49 AM, Mark Smith wrote: > > > 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. > > Sure. But practically all hosts want to communicate off-link e.g. to > reach google.com. > > > 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. > > But presumably a router would have some resource limits that can avoid > using up too much memory for incomplete neighbor cache entries. (If they > don't, perhaps the routers need a real OS ;-) > True. It seems most of the residential CPE has or is moving to Linux these days, so they're ending up with one. Setting maximums for the incomplete neighbor cache entry was my first thought. The drawback I'd be concerned about is that if that limit is e.g. 1000, and an an attacker fills it up, then subsequent legitimate requests get dropped. I'm hoping we can come up with a simple and smart way, using existing mechansims as much as possible, to discriminate between legitimate and illegitimate NSes, based on something that the downstream hosts can provide, that doesn't involve basically setting a lower point where a NS DoS can be triggered. > > 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? > > If the router is actually aware of how much memory it is using for the > incomplete NCEs then it can have an adaptive mechanism based on a > threshold. Below the threshold nothing changes. If the number exceeds > the threshold it would look for the low order bits using 24 bit matches > against recorded MLD reports and 64 bit matches against existing NCEs. > If it is there no match, then just drop the packet. If there was a > temporary spike in the number of inactive NCEs pushing it above the > threshold, then the number will drop once those inactive NCEs time out, > at which point one can get through even to a host which didn't do the > MLD report. > > Note that this requires the routers to remember the MLD state for the > link-local groups; currently routers don't need to do that. The MLD (and > IGMP) reports for link-local groups exist for the sole purpose of making > it easy to have MLD (and IGMP) snooping L2 devices. > > > * 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. > > Yes, I misremembered it as 32 bits. > > Hmm - seems like there is still a 2^40 (or 2^39 if we discount the group > bit) of attack possibility with the MLD check. > > If the attacker knows that there is a host with a particular address on > a subnet, then it can construct 2^40 other IPv6 address that map to the > same solicited-node multicast group. A ping to those addresses would, > even with all the above mechanisms, mean that the router would send the > NSes. Thus you still need a real OS in the router that can limit the > number of (incomplete) NCEs. > > Erik > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
