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.