>So perhaps the changes required would be mostly limited to -
>
>- DADs to all-nodes rather than solicited node addresses
>- nodes receiving the DAD use that to create a neighbor cache entry
>- NUD takes care of maintaining the validity of those entries
>- ND NS to all nodes with an unspecified target address solicits NAs
> from all nodes to cover the router (or any device) reboot situation
I am not sure this addresses the problem too well. The DOS issue manifests
itself at the gateway, and the main issue is the remote DOS: attacker sends
packets to a very large number of putative IPv6 addresses in the subnet managed
by the local gateway, causing the size of the neighbor cache to explode. If we
want to protect the cache in the gateway, let's do that. The solution has to be
a tweak in the implementation of ND in the gateway, along the lines of:
- Upon arrival of a packet from the local network:
- If the source address is already in ND cache, keep it there
- if the source address is not already in the ND cache:
Perform some quota check on the source MAC address,
If the quota is exceeded, drop the packet to protect against local DOS
If the quota is not exceeded, perform ND for the source address
- Upon arrival of a packet bound to the local subnet
- If the destination address is already in ND cache, route the packet;
- If the destination address is not in ND cache:
If the table is "too full," drop the packet
Else, perform ND
The basic idea is that remote parties should only be sending to addresses that
have already been discovered in the local subnet. This is, in a way, a weak
form of stateful filtering. It needs to be implemented softly, because
routers/gateways sometime lose their memory, so we want to allow for some
dynamic learning if the tables are not already populated.
The proposed tweaks amount to making ND learn faster. They are fine in general,
but they have the side effect of making local DOS easier. A local attacker
could generate a large number of addresses, etc.
-- Christian Huitema
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
