On Jul 17, 2011, at 12:09 PM, Christian Huitema wrote: >> So perhaps the changes required would be mostly limited to - >> >> - DADs to all-nodes rather than solicited node addresses >> - nodes receiving the DAD use that to create a neighbor cache entry >> - NUD takes care of maintaining the validity of those entries >> - ND NS to all nodes with an unspecified target address solicits NAs >> from all nodes to cover the router (or any device) reboot situation > > I am not sure this addresses the problem too well. The DOS issue manifests > itself at the gateway, and the main issue is the remote DOS: attacker sends > packets to a very large number of putative IPv6 addresses in the subnet > managed by the local gateway, causing the size of the neighbor cache to > explode. If we want to protect the cache in the gateway, let's do that. The > solution has to be a tweak in the implementation of ND in the gateway, along > the lines of: > > - Upon arrival of a packet from the local network: > - If the source address is already in ND cache, keep it there > - if the source address is not already in the ND cache: > Perform some quota check on the source MAC address, > If the quota is exceeded, drop the packet to protect against local DOS > If the quota is not exceeded, perform ND for the source address > > - Upon arrival of a packet bound to the local subnet > - If the destination address is already in ND cache, route the packet; > - If the destination address is not in ND cache: > If the table is "too full," drop the packet > Else, perform ND > > The basic idea is that remote parties should only be sending to addresses > that have already been discovered in the local subnet. This is, in a way, a > weak form of stateful filtering. It needs to be implemented softly, because > routers/gateways sometime lose their memory, so we want to allow for some > dynamic learning if the tables are not already populated. > > The proposed tweaks amount to making ND learn faster. They are fine in > general, but they have the side effect of making local DOS easier. A local > attacker could generate a large number of addresses, etc.
As a defense against remote attack, I'm thinking that routers should limit the percentage of their ND caches that are associated with nonexistent hosts. I suspect there are circumstances when it makes sense to have "passive" hosts, perhaps even large numbers of them, which the local router isn't aware of until traffic from outside arrives for them. It might also make sense to rate-limit ND messages sent as a result of inbound traffic - if this rate of such ND messages exceeds a certain threshold, drop incoming packets for hosts not in the ND cache at random. Regarding local attack, I doubt that the right thing to do is for routers to give preference to addresses already in the ND cache. It seems like that would just invite DoS attack, by having the attacking host flood the router's ND cache at regular intervals (especially if the ND cache entry timeout were a constant). A better idea might be for routers to give preference to addresses that are actually being used to exchange traffic. That might mean associating a count or timestamp with each ND cache entry. (which admittedly can introduce its own set of issues under certain conditions). And I wonder whether ND cache entries should have a "half-life" rather than a strict timeout. That still leaves the possibility of an attack where a local host generates large numbers of addresses, and actually uses each of them to exchange traffic with a remote host. As long as hosts can easily and quickly change their interfaces' MAC addresses, I don't see an easy way to deal with that.... though perhaps platforms could rate-limit the ability of applications to do that. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
