nanog mailing list archives

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


From: Jeff Wheeler <jsw () inconcepts biz>
Date: Sun, 17 Jul 2011 16:17:34 -0400

On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong <owen () delong com> wrote:
Basically an ND entry would have the following states and timers:

I've discussed what you have described with some colleagues in the
past.  The idea has merit and I would certainly not complain if
vendors included it (as a knob) on their boxes.  The downfalls of this
approach are that they still don't ensure the discovery of new
neighbors (rather than "ever seen" neighbors) during DoS, and you make
the local DoS a bit more complex by needing to establish more rules
for purging these semi-permanent entries.

I think most of this punting could be handled at the line card level. Is there
any reason that the ND process can't be moved into line-card level silicon
as described above?

You could implement ND solicit in the data-plane (and remove punts
entirely) in even some current chips, to say nothing of future ones.
Whether or not that is a good idea, well, keep in mind that the ND
solicits would then be mcasted to the LAN at a potentially unlimited
rate.

That is not necessarily a problem unless the L2 implementation is not
too good with respect to multicast.  For example, in some "switches"
(mostly those that are routers that can switch) the L2 mcast has
surprising caveats, such as using up a lot of fabric capacity for
whatever replication scheme has been chosen.

Of course, you also hope NDP on all the connected hosts works right.
I believe some Juniper customers noticed a pretty big problem with
JUNOS NDP implementation when deploying boxes using the DE-CIX
addressing scheme, and in a situation like that, the ingress router
for the attack could be crippled by spurious responses from the other
mis-behaving hosts on the LAN, essentially like smurf except without
sending any garbage back out to the Internet.

What you definitely don't want to do is assume this fixes the local
DoS, because it doesn't.  I would like for you to keep in mind that a
host on the LAN, misconfigured to do something like "local proxy-arp,"
or otherwise responding to all ND solicits, would accidentally DoS the
LAN's gateway.  I do not think we should assume that the local DoS
won't happen, or is "fixable" with a whack-a-mole method.

Sure, that doesn't solve the problem on current hardware, but, it moves it
from design problem to implementation issue, which IMHO is a step in the
right direction.

Well, it already is a design problem that implementations can largely
work-around.  Vendors just aren't doing it.  :-/

-- 
Jeff S Wheeler <jsw () inconcepts biz>
Sr Network Operator  /  Innovative Network Concepts

_____
NANOG mailing list
NANOG () nanog org
https://mailman.nanog.org/mailman/listinfo/nanog


Current thread: