On Wed, Jan 5, 2011 at 3:31 AM, Mohacsi Janos <mohacsi@niif.hu> wrote:
Do you have some methods in your mind to resolve ARP/ND overflow problem? I think limiting mac address per port on switches both efficient on IPv4 and IPv6. Equivalent of DHCP snooping and Dynamic ARP Inspection should be implemented by the switch vendors.... But remember DHCP snooping et al. implemented in IPv4 after the first serious attacks...Make pressure on your switch vendors....
Equipment vendors, and most operators, seem to be silent on this issue, not wishing to admit it is a serious problem, which would seem to be a required step before addressing it. Without more knobs on switches or routers, I believe there are only two possible solutions for production networks today: 1) do not configure /64 LANs, and instead, configure smaller subnets which will reduce the impact of scanning attacks This is not desirable, as customers may be driven to expect a /64, or even believe it is necessary for proper functioning. I brought this up with a colleague recently, who simply pointed to the RFC and said, "that's the way you have to do it." Unfortunately, configuring the network the way the standard says, and accepting the potential DoS consequences, will likely be less acceptable to customers than not offering them /64 LAN subnets. This is a foolish position and will not last long once reality sets in, unless vendors provide more knobs. 2) use link-local addressing on LANs, and static addressing to end hosts. This prevents a subset of attacks originated from "the Internet," by making it impossible for NDP to be initiated by scanning activity; but again, is not what customers will expect. It may have operational disadvantages with broken user-space software, is not easy for customers to configure, and does not permit easy porting of addresses among host machines. It requires much greater configuration effort, is likely not possible by way of DHCP. It also does not solve NDP table overflow attacks initiated by a compromised host on the LAN, which makes it a half-way solution. The knobs/features required to somewhat-mitigate the impact of an NDP table overflow attack are, at minimum: * keep NDP/ARP entry alive based on normal traffic flow, do not expire a host that is exchanging traffic + this is not the case with some major platforms, it surprised me to learn who does not do this + may require data plane changes on some boxes to inform control plane of on-going traffic from active addresses * have configurable per-interface limits for NDP/ARP resource consumption, to prevent attack on one interface/LAN from impacting all interfaces on a router + basically no one has this capability + typically requires only control plane modifications * have configurable minimum per-interface NDP/ARP resource reservation + typically requires only control plane modifications * have per-interface policer for NDP/ARP traffic to prevent control plane from becoming overwhelmed + because huge subnets may increase the frequency of scanning attacks, and breaking one interface by reaching a policer limit is much better than breaking the whole box if it runs out of CPU, or breaking NDP/ARP function on the whole box if whole-box policer is reached * learn new ARP/NDP entry when new transit traffic comes from a host on the LAN + even if NDP function is impared on the LAN due to on-going scan attack + again, per-interface limitations must be honored to protect whole box from breaking from one misconfigured / malicious LAN host * have sane defaults for all and allow all to be modified as-needed I am sure we can all agree that, as IPv6 deployment increases, many unimagined security issues may appear and be dealt with. This is one that a lot of smart people agree is a serious design flaw in any IPv6 network where /64 LANs are used, and yet, vendors are not doing anything about it. If customers don't express this concern to them, they won't do anything about it until it becomes a popular DoS attack. In addition, if you design your network around /64 LANs, and especially if you take misguided security-by-obscurity advice and randomize your host addresses so they can't be found in a practical time by scanning, you may have a very difficult time if the ultimate solution to this must be to change the typical subnet size from /64 to something that can fit within a practical NDP/ARP table. Deploying /64 networks because customers demand it and your competitors are doing it is understandable. Doing it "because it's the standard" is very stupid. Anyone doing that on, for example, SONET interfaces or point-to-point Ethernet VLANs in their infrastructure, is making a bad mistake. Doing it toward CE routers, the sort that have an IPv4 /30, is even more foolish; and many major ISPs already know this and are using small subnets such as /126 or /124. If you are still reading, but do not have any idea what I'm talking about, ask yourself these questions: 1) do I know what happens when my router's ARP table gets 100% full? 2) do I know what happens to my ARP/NDP functionality if my router receives a 20k PPS random scan towards an attached IPv6 subnet? will it eat all my CPU and drop my BGP, or just make it impossible to learn new ARP/NDP entries? will it eventually allow old entries to expire such that they perhaps cannot be re-learnt? 3) am I deploying IPv6 in a way that is vulnerable to a trivial attack method? 4) will my network design need fundamental change if my equipment vendor does not add necessary knobs? This is a very serious problem which our industry is actively ignoring, hoping it will just go away. If you are in the group who believes it is a non-issue, I urge you to take your head out of the sand. If you are waiting for your vendor to add more knobs or come up with a magic solution, stop clapping your hands and saying "I believe in fairies," and express your concern to your vendor sales channel. If you are a black-hat script kiddie, please go ahead and start scanning attacks now, while IPv6 largely does not matter and dual-stack infrastructure is somewhat limited (although there will be some spill-over to IPv4 on dual-stack boxes) to motivate change. Finally, if you operate a major IXP with a /64 peering LAN, please explain why this is in any way better than operating the same LAN with a subnet similar in size to its existing IPv4 subnets, e.g. a /120. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts