Implement limit checks for ND6 neighbour entries,
ND6 default routers, and ND6 prefixes learnt.
This avoids easy attacks exhausting resources, e.g.,
memory.
At the moment no further (expiration) mitigation is done
which means an attacker might still succeed to render the
system unusable (for IPv6) but not to crash it anymore
at least allowing an admin to react.
Limits are only setable on the base system and not on a
per-VNET base to avoid a VNET opening itself up as a target
for DoS taking the entire system down. Should there be a
need for per-VNET limits we can either do as frag6 and have
a system global maximum sum for all VNETs and a per-VNET
one, or we could implement a SYSCTL_PROC not allowing a VNET
to go beyond the global (per-VNET) limit.
For the neighbour table entires the global limit is not
per network stack but per interface. While a per-interface
counter would help to limit the impact of the attack for
the rtr/prefix once, the data structures are global and
we'd need a way more sophisticated logic, which should go
hand-in-hand with way more sophisticated expiry logic.
Add statistics for the three aforementioned cases and
for redirects (which are another can of worms of themselves
and could be mititgated by globally disabling them for now).
Teach netstat to print the overflow counters so an attack
can be detected more easily.
For default routers and prefixes we can just keep count
ourselves. For neighbour table entries we have to overload
the llatbl logic. For that export the link and unlink functions
and change their return types to allow us to know whether the
link or unlink actually happened to avoid double-counting.
Then do our checks in the extended implementation.
There is an idea of allowing the llatbls to manage the limits
themselves (not exporting this) by adding a "max" variable.
However updating the system limit would mean walking all tables,
checking the address family and dealing with the new limit.
We'll defer this to the future, once we do understand
expiration and effects on IPv4/ARP better.
In the end the goal here is to avoid a panic and not to provide
all possible counter measures. For some cases network
infrastructure could help a lot easier than we could with 100s
of lines of code.
PR: 157410