NIST IPv6 document

Thu Jan 6 08:24:57 UTC 2011

On Thu, Jan 6, 2011 at 2:42 AM, Joel Jaeggli <joelja at bogus.com> wrote:
> icmp6 rate limiting both reciept and origination is not rocket science.
> The attack that's being described wasn't exactly dreamed up last week,
> is as observed not unique to ipv6, and can be mitigated.

That does not solve the problem.  Your response, like most on this
thread, clearly indicates that you do not understand the underlying
issue, or how traffic is actually forwarded.  Neither IPv6 or IPv4
packets are simply forwarded onto the Ethernet, which is why the
ARP/NDP table resource is required; a mapping from layer-3 to layer-2
address is needed.  If the table resource for these entries is
exhausted, no new mappings can be learned, and bad things happen.
Either hosts on the specif interface, or the entire box, can no longer
exchange traffic through the router.  If an artificial rate-limit on
discovery traffic is reached, discovery of mappings will also be
impeded, meaning the denial-of-service condition exists and persists
until the attack ceases.  This may also affect either just that
interface, or all interfaces on the router, depending on its failure
mode.

Rate-limiting discovery traffic still breaks the attached LANs.  How
badly it breaks them is implementation-specific.  It does avoid using
up all the router's CPU, but that doesn't help the hosts which can't
exchange traffic.  Again, depending on the router implementation, the
fraction of hosts which cannot exchange traffic may reach 100%, and in
effect, the router might as well be down.

> You can still have this problem when you assign a bunch of /112s how
> many neighbor unreachable entries per interface can your fib hold?

You are correct, but the device can hold a significant number of
entries compared to the size of a /112 subnet, just like it can hold a
significant number of v4 ARP entries compared to a v4 /22 subnet.  The
difference is, ARP/NDP mappings for one /64 subnet can fill all the
TCAM resources of any router that will ever exist.  This is why more
knobs are needed, and until we have that, the /64 approach is
fundamentally broken.

Again, until this problem is better-understood, it will not be solved.
 Right now, there are many vulnerable networks; and in some platforms
running a dual-stack configuration, filling up the v6 NDP table will
also impact v4 ARP.  This means the problem is not confined to a cute
beta-test that your customers are just starting to ask about; it will
also take out your production v4 network.  If you are running a
dual-stack network with /64 LANs, you had better start planning.  It's
not just a problem on the horizon, it's a problem right now for many
early-adopters.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts