On Thu, 6 Jan 2011 21:13:52 -0500 Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong <owen@delong.com> wrote:
1. Block packets destined for your point-to-point links at your borders. There's no legitimate reason someone should be
Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those networks want NDP to be the reason they choose to make this change.
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.
Again, this doesn't fix the problem of misconfigured hosts on the LAN. I can and shall say it over and over, as long as folks continue to miss the potential for one compromised machine to disable the entire LAN, and in many cases, the entire router. It is bad that NDP table overflow can be triggered externally, but even if you solve that problem (which again does not require a stateful firewall, why do you keep saying this?) you still haven't made sure one host machine can't disable the LAN/router.
Doesn't this risk already exist in IPv4? Any device attached to a LAN can send any traffic it likes to any other device attached to a LAN, whether that be spoofed ARP updates, intentionally created duplicate IP addresses, or simple flat out traffic based denial of service attacks using valid IPv4 addresses. Just relying on ARP means you're trusting other LAN attached devices not be lying. If you really think a LAN attached device being malicious to another LAN attached device is an unacceptable risk, then you're going to need to abandon your peer-to-peer traffic forwarding topology provided by a multi-access LAN, and adopt a hub-and-spoke one, with the hub (router/firewall) acting as an inspection and quarantining device for all traffic originated by spokes. PPPoE or per-device VLANs would be the way to do that, while still gaining the price benefits of commodity Ethernet. I definitely think there is an issue with IPv6 ND cache state being exploitable from off-link sources e.g. the Internet. I think, however, targetting on-link devices on a LAN is far less of an issue - you've already accepted the risk that LAN other devices can send malicious traffic, and those LAN devices also have a vested interest in their default router being available, so they have far less of an incentive to maliciously disable it.
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.
You must understand that policing will not stop the NDCache from becoming full almost instantly under an attack. Since the largest existing routers have about 100k entries at most, an attack can fill that up in *one second.*
On some platforms, existing entries must be periodically refreshed by actual ARP/NDP exchange. If they are not refreshed, the entries go away, and traffic stops flowing. This is extremely bad because it can break even hosts with constant traffic flows, such as a server or infrastructure link to a neighboring router. Depending on the attack PPS and policer configuration, such hosts may remain broken for the duration of the attack.
Implementations differ greatly in this regard. All of them break under an attack. Every single current implementation breaks in some fashion. It's just a question of how bad.
-- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts