Re: NIST IPv6 document

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

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