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.
