On Thu, Jan 6, 2011 at 1:20 PM, Owen DeLong <owen@delong.com> 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. Owen