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: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1