On 07/14/2011 10:24 PM, Jimmy Hess wrote: >> In this particular case, if the implementation enforces a limit on the >> number of entries in the "INCOMPLETE" state, then only nodes that have >> never communicated with the outside world could be affected by this >> attack. And if those entries that are in the "INCOMPLETE" state are >> pruned periodically (e.g. in a round-robin fashion), chances are that > > Not only that but it's possible to differentiate _how_ an entry is added to > the table when the table reaches a "high water mark" it's possible > to drop the packet that was attempting to cause a NDP discover, fail to add > the INCOMPLETE entry to the table, but _still_ send the outgoing NDP > neighbor solicitation, and complete the entry or "whitelist" the destination > if the neighbor advertises itself.
Agreed. I should double-check whether there's room in the current specifications to do this -- however, whether the specs allow this or not is irrelevant. At the point you're being hit with a DoS, you better do something about it (particularly when it's possible, as in this case!) > That is: if the destination is good, the neighbor will respond to the > NDP solicit, > even though the neighbor doesn't have an entry in the table. Modulo that when the high water mark has not been hit, the router should probably *not* create ND cache entries in response to this "gratuitous" ND advertisements, since otherwise it would open the door to a DoS from local attackers. > It should be possible to mitigate this, so long as the attack does not > actually > originate from a neighbor on the same subnet as a router IP interface on > an IPv6 subnet with sufficient number of IPs. Well, unless there's some layer-2 anti-spoofing mitigation in place, with /64 subnets the "local attacker" typically *will* have enough addresses. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
