Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery

The IPv6 neighbor discovery cache is vulnerable to a Denial of Service attack that purposely exhausts the state used during the neighbor discovery process . When a router is the target of this attack, an off-link attacker sends traffic towards many non-existent addresses within a prefix attached to the router. This causes the router to create neighbor cache state for neighbor solicitations for these non-existent addresses. The denial of service occurs when the router's neighbor cache state capacity is exhausted due to too many outstanding neighor solicitations. Sizing a prefix proportional to the number of attached hosts, rather than using the standard /64 prefix size , would mitigate this attack. However, operational conveniences and benefits such as universal fixed length prefixes and interface identifiers, Stateless Address Autoconfiguration (SLAAC) and privacy addresses , and never having to resize the prefix or add secondary prefixes to attach more hosts to the link would be lost. This memo proposes a stateless form of neighbor discovery to prevent this type of DoS attack on a router. It does not require any changes to the operation of neighbor discovery on hosts. It takes advantage of hosts' ability to recover from packet loss in the network, necessary due to IPv6's best effort nature. This method would be used when the router's neighbor cache's state capacity reaches a medium to high threshold of use, suggesting a neighbor cache DoS attack is occuring. An optional enhancement is to distinguish packet sources as trusted or untrusted, and to continue to provide trusted packet sources with traditional stateful neighbor discovery.

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.

Stateful Neighbor Discovery (SFND): Traditional neighbor discovery, as specified in . This form of neighbor discovery maintains per packet destination state for all unresolved destinations during the neighbor discovery process. The neighbor cache's state capacity is intentionally exhausted to cause the neighbor cache Denial of Service attack. Stateless Neighbor Discovery (SLND): The form of neighbor discovery described in this memo. This form of neighbor discovery does not maintain per packet destination state for unresolved destinations during the neighbor discovery process. IGP: Interior Gateway Protocol, such as OSPF . EGP: Exterior Gateway Protocol, such as BGP .

During traditional stateful neighbor discovery, state is used to perform the following: ensure a received neighbor advertisement corresponds to a previously sent neighbor solicitation to retransmit a limited number of neighbor solicitations if previous solicitations remain unanswered to store a small number of packets that triggered the neighbor discovery process, so that they can be transmitted if neighbor discovery completes successfully to generate ICMPv6 destination unreachable, address unreachble messages should neighbor discovery fail Stateless neighbor discovery sacrifices these functions and the related state to mitigate the neighbor cache DoS attack.

Ensuring received neighbor advertisements correspond to previously sent neighbor solicitations prevents on-link nodes from sending unsolicited neighbor advertisements to the router, and then having them added to the router's neighbor cache without validation. This would allow on-link hosts to perform a neighbor cache DoS attack, as they could send many neighbor advertisements for non-existent addresses within the link assigned prefixes, exhausting the neighbor cache capacity. If neighbor advertisement validation occurs, then the router is vulnerable to an off-link sourced neighbor cache DoS attack, but is not vulnerable to an on-link sourced neighbor cache DoS attack. If neighbor advertisement validation does not occur, then the router is vulnerable to an on-link sourced neighbor cache DoS attack, but is now not vulnerable to an off-link sourced neighbor cache DoS attack. Considering that on-link nodes will usually have a vested interest in the router continuing to operate, that there will be a much smaller set of on-link sources, and that they'll be far better known and possibly access controlled, the likelihood of an on-link sourced neighbor cache DoS is much lower than an off-link sourced neighbor cache DoS. It is therefore beneficial to sacrifice on-link neighbor cache DoS protection to gain off-link neighbor cache DoS protection. Also note that during the stateless neighbor discovery process proposed in this memo, neighbor advertisement validation is only sacrificed when an off-link sourced neighbor cache DoS appears to be taking place. Under normal circumstances on-link sourced neighbor advertisement validation continues to occur.

The nature of IPv6 is best effort, meaning that there is a possibility that packets may be lost as they transit the network, and that IPv6 will not make any attempt to recover lost packets. If an application residing on an IPv6 node requires reliable packet delivery, it will need to utilise locally implemented reliable upper layer protocols such as TCP and SCTP, or implement it's own reliability mechanisms. These reliability mechanisms involve retransmitting packets. Alternatively, the application needs to accept the possibility and consequences of packet loss. The remaining uses of stateful neighbor discovery state are not assured of success. The limited number of neighbor solicitation retransmissions may not be enough, causing neighbor discovery to fail even though the target node exists. There may be more packets sent that trigger neighbor discovery than are stored for transmission when neighbor discovery completes successfully, causing them to be dropped. The ICMPv6 destination unreachable message may be dropped on the way back to the traffic originating node, perhaps intentionally by a network located firewall. This means that these functions are useful but not essential optimisations. If necessary, they do not need to be performed, as the packet source will retransmit it's packets, reinitiating the neighbor discovery process, or accept that packet loss has occured. This provides the opportunity to perform a stateless form of neighbor discovery if there is evidence that a neighbor cache DoS attack is occuring, mitigating the off-link sourced neighbor cache DoS attack.

To perform stateless neighbor discovery, four variables are maintained: SLND Flag - This flag indicates whether or not the interface will perform SLND if necessary. By default, this flag should be set to on. SLDN Activate Threshold - This variable specifies the threshold when stateless neighbor discovery is activated. The threshold specifies a neighbor cache utilisation level. It is expressed as a percentage, with a default value of 80%. It may either be a per-interface or router global variable depending on whether the router implementation has per-interface neighbor caches or a global neighbor cache used by all interfaces. SLND Active Flag - This flag indicates whether or not the interface is currently performing SLND. It is maintained for each interface on the router. SLND Neighbor Solicitation Rate Limit ("SLND NS Rate Limit") - This variable specifies a threshold for multicast Neighbor Solictiations when the interface is performing SLND, specified in packets per second. It is a per-interface variable, as different interfaces may have different thresholds. The rate value should be an appropriate portion of the multicast packet per second capabilities of the interface link technology, such as 10%. A router may maintain a global threshold that is applied to interfaces that do not have an interface specific rate limit.

The stateless neighbor discovery process may occur once a router has determined the outgoing interface for a packet, and that the packet's destination is on-link. If the packet's destination address is present in the neighbor cache, and the link-layer address has been resolved, the packet is forwarded to it's destination. If the packet's destination address is not present in the neighbor cache, and the SLND Flag is off, traditional stateful neighbor discovery is performed for the packet's destination. If the SLND Flag is on, and the SLND Active flag is off, traditional stateful neighbor discovery is performed. If the SLND Flag is on, and the SLND Active flag is on, stateless neighbor discovery is performed as follows: The router determines if sending a multicast neighbor solicitation would exceed the SLND NS Rate Limit for the outgoing interface. If the SLND NS Rate Limit would be exceeded, drop the packet and do not proceed any further. A multicast neighbor solicitation is sent by the router for the destination address in the packet. The packet is then dropped. As some later point in time, the router is likely to receive a unicast neighbor advertisement, for a previously sent neighbor solicitation. If the SLND Active Flag is off, the router ignores the neighbor advertisement. If the SLND Active Flag is on, the router creates an entry in it's neighbor cache using the information received in the unicast neighbor advertisement. Stateless neighbor discovery is now complete. The utilisation of the neighbor cache needs to be measured to determine if it crosses the SLDN Activate Threshold. If the utilisation increases above the SLDN Activate Threshold, the SLND Active Flag is switched on, and if it decreases below the SLDN Activate Threshold, the SLND Active Flag is switched off. Neighbor cache utlisation should be measured and compared to the SLDN Activate Threshold when: entries are added to the neighbor cache, during either stateful or stateless neighbor discovery entries are removed from the neighbor cache when Neighbor Unreachability Detection discovers the neighbor has disappeared

When a neighbor cache DoS attack appears to be occurring, it could be useful to continue to provide traditional stateful neighbor discovery service to hosts that are considered unlikely to initiate or participate in the DoS attack. These hosts could be considered trusted hosts, while the remaining set of hosts are untrusted. The determination of whether a host is trusted or untrusted would take place when neighbor discovery is determined to be necessary, during the stateless neighbor discovery process. The determination of trust is made based on attributes of the packets that trigger the neighbor discovery process. If none of the packet attributes indicate either a trusted or untrusted host, then the host is considered to be untrusted. There are two basic packet attributes that an enhanced implementation should provide mechanisms to use to classify a packet source as trusted or untrusted: source address ingress interface An implementation may be able to reuse its existing packet classification mechanisms to determine trust, such as those used to implement network QoS. This would mean that other packet attributes, such as Traffic Class, Flow Label , the CALIPSO option or MPLS label values , could also be used to determine packet source trustworthiness.

The source address of the packet that has triggered the neighbor discovery process can be used to determine the trust level of the origin host. The information used to classify the source address can come from two possible sources: an operator configured prefix list the network's routing information

An operator configured prefix list consists of a static list of prefixes and their lengths, each with a flag indicating whether traffic with source addresses that falls within the specified prefix is from a trusted or untrusted source. How this list is evaluated would be implementation dependent, however it is likely to be either sequential from first to last entry, or using a longest match algorithm. This list should have a default entry of the ULA prefix (fc00::/7) , flagged as a trusted source. An implementation must allow this entry to be removed.

The network's routing information can be used to distinguish trusted and untrusted packet sources. An advantage of using routing information for this purpose is that it will typically be dynamically and automatically distributed to all routers within the network, when dynamic routing protocols are used. This avoids changes to the operator configured prefix list on individual routers when trusted prefixes are added or removed from the network. The contents of a stub network's route table is typically all the internal routes for the network, and then a default route used to reach the Internet. The list of internal routes can be used to distinguish between trusted and untrusted sources, with packet sources matching internal routes being trusted, and all other packet sources being untrusted. In more complex routing environments, such as those using one or more IGPs and an EGP such as BGP , there may be other methods available to distinguish between trusted and untrusted sources. For example, routes carried in an IGP could be considered trusted, while routes carried in BGP are untrusted. For a network using BGP to carry all reachability information, except network transit and loopback interface routes, internal routes may be tagged with one or more BGP communities to indicate they are also trusted prefixes. There may be cases where a subset of the internal routes need to be considered untrusted, despite them being propagated internally via a routing protocol. These routes will likely be for links at the edge of the local network, where untrusted hosts can be attached without local network control or authorisation. These routes need to be labelled as untrusted, and that information propagated to all routers within the local network. Route labelling mechanisms such as OSPF's External Route Tag or a BGP community could be used for this purpose. A default route should never be used as a trusted packet source route. If a router's operator wishes to trust all packet sources, they should specify the prefix that covers all IPv6 addresses, ::/0, as an operator configured trusted prefix. (The ::/0 prefix is only a default route when used as routing information.) Implementations should provide simple and convenient methods to use the network's routing information to distinguish between trusted and untrusted packet source prefixes.

A packet's ingress interface on the router could be used to determine whether statelful or stateless neighbor discovery takes place. Interfaces on the router would be labelled as trusted or untrusted. The default trust level for interfaces would be up to the router's implenter. Considerations could be the likely deployment scenario for the router implementation (e.g., residential Internet access, or within an enterprise network), and the type of interface (e.g., an interface type that is usually used to attach the router to the Internet, such as an ADSL interface, would be labelled untrusted). These default interface trust assignments should be easy to change.

Oliver Ddin provided review and comments, and suggested the use of ingress interface and other more general packet attributes to determine packet source trust. Review and comments were provided by Ray Hunter, Matthew Moyle-Croft and Karl Auer. This memo was prepared using the xml2rfc tool.

This memo proposes a security mitigation for an off-link sourced neighbor cache Denial of Service attack, aimed at a router. As discussed in , the method proposed creates an opportunity for an on-link sourced neighbor cache DoS attack, when mitigating the off-link sourced neighbor cache DoS. This is considered to be an acceptable security trade-off.

draft-smith-6man-mitigate-nd-cache-dos-slnd-00, initial version, 2012-09-04 draft-smith-6man-mitigate-nd-cache-dos-slnd-01, more clarity, 2012-10-13 more comprehensive introduction (problem definition) text make it more obvious that hosts don't need to be changed low-end/embedded hosts can consider all packet sources untrusted misc. minor text updates draft-smith-6man-mitigate-nd-cache-dos-slnd-05, structual changes, 2012-11-08 moved opportunities for SLND section to before SLND description spit SLND into basic functionality and optional enhancements use of ingress interface and other more general packet attributes to determine trust