NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

Fri Jul 15 01:47:26 UTC 2011

On Jul 14, 2011, at 6:24 PM, Jimmy Hess wrote:

> On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont <fernando at 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

Very true. This is where Mr. Wheeler's arguments depart from reality. He's right
in that the problem can't be truly fixed without some very complicated code added
to lots of devices, but, it can be mitigated relatively easily and mitigation really
is good enough for most real world purposes.

Owen