Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership

When an IPv6 unicast or anycast address is added to or removed from an interface, the node also joins or leaves the Solicited-Node multicast group that corresponds to the address . The Solicited-Node multicast group the node joins or leaves is determined by appending the lower 24 bits of the address to the IPv6 multicast prefix FF02:0:0:0:0:1:FF00::/104 . The presence of a Solicited-Node multicast group on a link indicates that at least one unicast or anycast address that maps to the Solicited-Node multicast group is present. Conversely, the absence of a Solicited-Node multicast group indicates that no unicast or anycast addresses that would map to it are present on the link. This presence or absence of Solicited-Node multicast groups can be used by a router to determine if it needs to send Neighbor Solicitations for unresolved addresses on to the link. If the to-be-resolved address maps to a non-existent Solicited-Node multicast group, the router can drop the packet, rather than sending a Neighbor Solicitation for its destination. For links with prefixes with lengths shorter than or equal to /104, such as a /64, the total number of Solicited-Node multicast groups possible on a link is 2^24, or 16 777 216 groups. The number of Solicited-Node multicast groups present on a link is equal to the number of IPv6 unicast or anycast addresses present on the link which have unique lower 24 bits, used to form the Solicited-Node multicast group address. For most links the number of present Solicited-Node multicast groups present is going to be in the order of 10s, 100s or perhaps on rarer occasions in the low 1000s. This means that Neighbor Solicitations do not have to be sent for very large numbers of unresolved unicast or anycast addresses for which the corresonding Solicited-Node multicast group is not present. This can significantly reduce the attack surface for the ND cache exhaustion denial of service attack . For example, if a link has 1000 present Solicited-Node multicast groups, then Neighbor Solicitations do not have to be sent for addresses that would map to the absent 16 776 216 Solicited-Node multicast groups, which is more than 99.99% of the possible Solicited-Node multicast groups. This memo describes how a router collects Solicited-Node multicast group membership and how it uses this information as part of its neighbor presence discovery procedure, for the purposes of further mitigating the ND cache exhaustion attack. Note that this method has been independently suggested by Greg Daley and perhaps others.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

To track Solicited-Node multicast group presence on a link, a router uses the multicast listener discovery procedures specified in or , without modification. Note that the procedures specified in and do not require that a router performing them to be forwarding multicast packets, or to be participating in a multicast routing protocol with other multicast routers. The ND cache DoS mitigation method described in this memo can be used regardless of whether the other routers in the network, including other on-link routers, are performing multicast forwarding. If a router using this ND cache DoS mitigation method is not performing multicast forwarding, it may choose to only track Solicited-Node multicast group presence, ignoring the presence information it receives for other multicast groups. This may usefully reduce the router's resources consumption. If a router using this optimisation becomes a multicast forwarding router, it will need to collect presence information for all multicast groups, using the Querier Election procedure , as though it had no knowledge of the presence any of the multicast groups.

When a router receives a packet for a destination for which it does not have a neighbor cache entry, it uses the specified method to form a Solicited-Node multicast group address from the destination address. The router then compares the resulting Solicited-Node multicast group address with its list of present Solicited-Node multicast groups on the link. If the Solicited-Node multicast group is present, the router then performs the address resolution procedure for the packet's destination IPv6 address as specified in , starting with sending a Neighbor Solicitation towards the Solicited-Node multicast group that corresponds to the address. If the resulting Solicited-Node multicast group is not present then the router would normally drop the packet. It may alternatively perform some other action with the packet which may be useful to the router's operator, perhaps for security purposes.

The method described in this memo further mitigates the ND cache exhaustion DoS attack. It does not prevent it. Using this method, neighbor presence discovery will occur for any of the unicast or anycast addresses that map to the present Solicited-Node multicast groups. As a Solicited-Node multicast group can map to up to 2^40 unicast or anycast addresses (for a /64 prefix, 2^(64 - 24)), the ND implementation is likely to continue to be vulnerable to a ND cache exhaustion denial of service for addresses covered by the present Solicited-Node multicast groups. While the number of non-existent addresses that can be targetted remains very large, it is very significantly smaller than the targettable non-existent addresses possible in the on-link prefixes without this measure. The severity of this threat depends on two factors: the number of Solicited-Node multicast groups present on the link, and the ability of the attacker to stumble upon or discover non-existent addresses that map to present Solicited-Node multicast groups. The severity of the threat is lower with lesser numbers of Solicited-Node multicast groups, and less predictable and sparsely distributed Solicited-Node multicast group addresses. proposes the use of stable yet random and less predictable IIDs, on a per-prefix basis. This will increase the number of present Solicited-Node multicast groups, by up to the number of prefixes multiplied by the number of hosts implementing . This will reduce the effectiveness of the measure proposed in this memo. However, it will also conversely increase the effectiveness of this measure, as the IIDs and therefore the Solicited-Node multicast groups become less predictable and sparsely distributed. To protect against ND cache DoS attacks for non-existent addresses that map to present Solicited-Node multicast groups, other ND cache protection measures, such as those described in should be implemented. When a packet is sent to a destination that is unresolved and is not covered by a present Solicited-Node multicast group, instead of being dropped, it could alternatively be forwarded to an greynet collector for further analysis.

Review and comments were provided by YOUR NAME HERE! This memo was prepared using the xml2rfc tool.

draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00, initial version, 2014-04-08