Re: NIST IPv6 document

[Joel Jaeggli <joelja () bogus com>]

On 1/6/11 12:24 AM, Jeff Wheeler wrote:
> On Thu, Jan 6, 2011 at 2:42 AM, Joel Jaeggli <joelja () 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.

You seem hell bent on telling me what I do and don't know. I know how
they're created.

> If the table resource for these entries is
> exhausted, no new mappings can be learned,

Which at a minimum is why you want to police the number of nd messages
that the device sends and unreachable entries do not simply fill up the
nd cache, such that new mappings in fact can be learned because there
are free entries. you need to do this on a per subnet basis rather than
globally. as in ipv4 policing, global limits will kill the boxes ability
to learn new entries everywhere.

> 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,

a /112 is 16 bits.

 just like it can hold a
> significant number of v4 ARP entries compared to a v4 /22 subnet. 

I've got this lovely ex8208 here, a quick glance as the specs says 100k
arp entries per linecard. that requires some sensible configuration from
the outset otherwise shooting yourself in the foot with ipv4 is
possible. I've done it both deliberately and on accident and I have
better rules now.

> The
> difference is, ARP/NDP mappings for one /64 subnet can fill all the
> TCAM resources of any router that will ever exist.

the arp mappings for an ipv4 /15 will fill up the device today.

>  This is why more
> knobs are needed, and until we have that, the /64 approach is
> fundamentally broken.

as with anything sent to into the control plane it needs to be policed
there are sensible ways to do that today, they can improve.

> 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.