NIST IPv6 document

Owen DeLong owen at
Thu Jan 6 19:47:12 CST 2011

> On Thu, Jan 6, 2011 at 1:20 PM, Owen DeLong <owen at> wrote:
>> And there are ways to mitigate ND attacks as well.
> No, Owen, there aren't.  The necessary router knobs do not exist.  The
> "Cisco approach" is currently to police NDP on a per-interface basis
> (either with per-int or global configuration knob) and break NDP on
> the interface once that policer is exceeded.  This is good (thanks,
> Cisco) because it limits damage to one subnet; but bad because it
> exemplifies the severity of the issue: the "Cisco solution" is known
> to be bad, but is less bad than letting the whole box break.  Cisco is
> not going to come up with a magic knob because there isn't any -- with
> the current design, you have to pick your failure modes and live with
> them.  That's not good and it is not a Cisco failing by any means, it
> is a design failing brought on by the standards bodies.
Saying this over and over doesn't make it so...

1.	Block packets destined for your point-to-point links at your
	borders. There's no legitimate reason someone should be
	expecting your routers to respond to packets sent to the
	router specifically.

2.	For networks that aren't intended to receive inbound requests
	from the outside, limit such requests to the live hosts that
	exist on those networks with a stateful firewall.

3.	Police the ND issue rate on the router. Yes, it means that
	an ND attack could prevent some legitimate ND requests
	from getting through, but, at least it prevents ND overflow and
	the working hosts with existing ND entries continue to function.
	In most cases, this will be virtually all of the active hosts on
	the network.

All of these things can be done today with the knobs that exist.
The combination of them pretty much takes the wind out of any
ND table overflow attack. Yes, it involves some tradeoffs and
isn't a perfect solution. However, it is an effective mitigation.


More information about the NANOG mailing list