On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont <fernando@gont.com.ar> wrote:
On 07/11/2011 09:17 PM, Karl Auer wrote: Vulnerability to this specific issues has a great deal to do with the implementation. After all, whenever there's a data structure that can Yes
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. 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. So a small number of packets are lost at initial setup, due to the attack, but further packets are unaffected, So long as the attack does not overwhelm router CPU, and so long as the INCOMPLETE entry high water mark is at a low enough level, so there is still ample space in the table. Even more sophisticated strategies may be available. 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.
even those "new hosts" would be able to get into the neighbor cache and hence remain unaffected by this attack.
Thanks,
-- -JH