On Thu, Jan 6, 2011 at 7:34 AM, Robert E. Seastrom <rs@seastrom.com> wrote:
I continue to believe that the "allocate the /64, configure the /127 as a workaround for the router vendors' unevolved designs" approach,
As a point of information, I notice that Level3 has deployed without doing this, e.g. they have densely packed /126 subnets which are conceptually identical to /30s for infrastructure and point-to-point. I am still taking your conservative approach, as I see no operational disadvantage to it; but opinions must differ. On Thu, Jan 6, 2011 at 11:28 AM, <Valdis.Kletnieks@vt.edu> wrote:
And the "ZOMG they can overflow the ARP/ND/whatever table" is a total red herring - you know damned well that if a script kiddie with a 10K node botnet wants to hose down your network, you're going to be looking at a DDoS, and it really doesn't matter whether it's SYN packets, or ND traffic, or forged ICMP echo-reply mobygrams.
I agree, botnets are large enough to DDoS most things. However, with the current state of ARP/ND table implementations in some major equipment vendors' routers, combined with standards-compliant configuration, it doesn't take a botnet. I could DoS your subnet (or whole router) without a botnet, say, using an IPv6 McDonald's Wi-Fi hotspot. That is very much a legitimate concern. A few hundred packets per second will be enough to cripple some platforms. On Thu, Jan 6, 2011 at 1:20 PM, Owen DeLong <owen@delong.com> wrote:
And there are ways to mitigate ND attacks as well.
No, Owen, there aren't. The necessary router knobs do not exist. The "Cisco approach" is currently to police NDP on a per-interface basis (either with per-int or global configuration knob) and break NDP on the interface once that policer is exceeded. This is good (thanks, Cisco) because it limits damage to one subnet; but bad because it exemplifies the severity of the issue: the "Cisco solution" is known to be bad, but is less bad than letting the whole box break. Cisco is not going to come up with a magic knob because there isn't any -- with the current design, you have to pick your failure modes and live with them. That's not good and it is not a Cisco failing by any means, it is a design failing brought on by the standards bodies. I would also like to reply in public to a couple of off-list questions, because the questions are common ones, the answers are not necessarily cut-and-dry (my opinion is only one approach; there are others) and this is the kind of useful discussion needed to address this matter. I will leave out the names of the people asking since they emailed me in private, but I'm sure they won't mind me pasting their questions. Anonymous Questioner:
What do you think about using only link-local ip addresses on the infrastructure links please? I can't think of any potential drawbacks do you?
This can be done, but then you don't have a numbered next-hop for routing protocols. That's okay if you re-write it to something else. Note that link-local subnets still have an NDP table, and if that resource is exhausted due to attacks on the router, neighbors with link-local addressing are not immune. link-local scope offers numerous advantages which are mostly out-weighed by more practical concerns, like, how hard it is going to be to convince the average Windows sysadmin to configure his machine to suit such a design, instead of just taking his business elsewhere. Not a problem for enterprise/gov/academia so much, but a problem for service providers. On Thu, Jan 6, 2011 at 3:43 PM, Jack Bates <jbates@brightok.net> wrote:
Given that the incomplete age is to protect the L2 network from excessive broadcast/multicast, I agree that aging them out fast would be a wiser
I agree that it would be nice to have such a knob. I bet you and I would make different choices about how to use it, which is the whole point of having a knob instead of a fixed value.
I'm still a proponent for removing as needed requests like this, though. It would have been better to send a global "everyone update me" request periodically, even if triggered by an unknown entry, yet limited to only broadcasting once every 10-30 seconds.
Given that all requests for an unknown arp/ND entry results in all hosts on the network checking, it only makes sense for all hosts to respond. There
This isn't a new idea and it has its own set of problems, which are well-understood. IPv6 NS messages are more clever than ARP, though, and are sent to a computed multicast address. This means that the number of hosts which receive the message is minimized. See RFC2461 section 2.3 for the quick introduction. NDP is better than ARP. However, your statement that NDP has all (I'd like to say some) of the same problems as ARP but the increased subnet size has magnified them, is basically correct. NDP does some things a lot better than ARP, but not this. It's important to realize that when this stuff was designed, there were few hardware-based layer-3 routers for IPv4. The biggest networks (Sprint/UUnet/etc) were exchanging a few hundred megabits per second on PNIs and the tier-2 guys had DS3s to IXPs. The network has come a long way in terms of user-base, bandwidth, and sophistication since then. Second Anonymous Questioner:
That is, I don't see why a smart rate-limiting implementation doesn't solve most of it.
This is a good question, which I have tried to cover in much earlier posts, perhaps without explaining it effectively. There currently are major vendors shipping IPv6 routers which age out ARP/NDP entries even if they have continuous traffic -- these routers do an occasional ARP/NDP "refresh" even though the neighbor is constantly sending and receiving traffic. For this reason, an attack can trigger your rate-limit and prevent the "refresh" from working. So over a period of time, all hosts attached to the router will stop working. Smarter platforms are still unable to learn about new neighbors when your rate-limit is being triggered. How bad this is depends on the implementation. Finally, any compromised host on the LAN can fill up the NDP table for the interface (which on most platforms, really means fill up the combined NDP/ARP table for the whole box) and either prevent any new neighbor associations, or far worse, cause churn that will disable the entire router and all traffic that needs to transit through it. This is extremely bad, and yet, it is trivial to execute if you have access to a machine on the LAN.
Yes, during this period, lots of unreachables will not be sent,
Unreachables are really of no concern. The router staying up, and its interfaces continuing to function correctly, are in question. Actually, they're not so much in question ... because all existing IPv6 routers can be broken with the trivial method we are discussing if /64 subnets are in use. What's implementation-specific is "how broken," but as you can read above, Cisco has given customers a knob to control the damage, but it's very, very far from a complete solution. Unlike Cisco, some other vendors haven't given this the first thought, let alone added a knob; but even Cisco must do more. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts