Internet Engineering Task Force M. Smith Internet-Draft IMOT Updates: 4861 (if approved) O. Ddin Intended status: Standards Track ZeroLag Communications, Inc. Expires: April 21, 2013 October 18, 2012 Mitigating IPv6 Router Neighbor Cache DoS Using Stateless Neighbor Discovery draft-smith-6man-mitigate-nd-cache-dos-slnd-03 Abstract The IPv6 neighbor discovery cache is vulnerable to a Denial of Service attack that purposely exhausts the state used during the neighbor discovery address resolution process described in RFC 4861. This attack can be very disruptive when the target is a router. This memo proposes a stateless form of neighbor discovery to be used by routers to mitigate this attack. It does not require any changes to hosts. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 16, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Smith, Ddin Expires April 21, 2013 [Page 1] Internet-Draft Stateless Neighbor Discovery October 18, 2012 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Stateless Neighbor Discovery . . . . . . . . . . . . . . . . . 4 3.1. SLND Variables . . . . . . . . . . . . . . . . . . . . . . 4 3.2. SLND Process . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Unhashed SLND . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Hashed SLND . . . . . . . . . . . . . . . . . . . . . . . 7 4. Consequences of Stateless Neighbor Discovery . . . . . . . . . 8 4.1. Neighbor Advertisement Validation . . . . . . . . . . . . 9 4.2. Optimization Functions . . . . . . . . . . . . . . . . . . 9 5. Trusted/Untrusted Discriminator . . . . . . . . . . . . . . . 10 5.1. Configured Trusted and Untrusted Prefixes . . . . . . . . 10 5.2. Routing Information . . . . . . . . . . . . . . . . . . . 10 5.3. Default to Untrusted . . . . . . . . . . . . . . . . . . . 11 5.4. Neighbor Origin Flag (NOF) in relation to the TUD . . . . 11 6. Baseline Implementation . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 10. Change Log [RFC Editor please remove] . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Smith, Ddin Expires April 21, 2013 [Page 2] Internet-Draft Stateless Neighbor Discovery October 18, 2012 1. Introduction The IPv6 neighbor discovery cache [RFC4861] is vulnerable to a Denial of Service attack that purposely exhausts the state used during the neighbor discovery address resolution process [RFC3756]. 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 neighbor solicitations. Sizing a prefix proportional to the number of attached hosts, rather than using the standard /64 prefix size [RFC4291], would mitigate this attack. However, operational conveniences and benefits such as universal fixed length prefixes and interface identifiers, Stateless Address Auto configuration (SLAAC) [RFC4862] and privacy addresses [RFC4941], 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 optionally takes advantage of hosts' ability to recover from packet loss in the network, necessary due to IPv6's best effort nature. This method can be used for unknown or untrusted packet sources, when the router's neighbor cache capacity reaches a medium to high threshold of use, suggesting a neighbor cache DoS attack is occurring. Trusted packets would continue to be provided with traditional stateful neighbor discovery. 1.1. Requirements Language 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 [RFC2119]. 2. Terminology Stateful Neighbor Discovery (SFND): Traditional neighbor discovery, as specified in [RFC4861]. 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. Smith, Ddin Expires April 21, 2013 [Page 3] Internet-Draft Stateless Neighbor Discovery October 18, 2012 Stateless Neighbor Discovery (SLND): The form of neighbor discovery described in this memo. This form of neighbor discovery does not maintain state for unresolved destinations during the neighbor discovery process. SLND has two modes of operation: hashed and unhashed. Hashing refers to any computational function which digests input into a fixed-length, unique value. 3. Stateless Neighbor Discovery 3.1. SLND Variables To perform stateless neighbor discovery, the following variables are maintained: SLND Flag - This REQUIRED flag indicates whether or not the interface will perform SLND if necessary. SLND Activate Threshold - This REQUIRED variable specifies the threshold when stateless neighbor discovery is activated. The threshold specifies a neighbor cache utilization level. It is expressed as a percentage, with a RECOMMENDED default value of 80%. It may be either 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 REQUIRED flag indicates whether or not the interface is performing SLND for untrusted packet sources. It is maintained for each interface on the router. If Hashed SLND is implemented, it indicates the type of SLND in use. Trusted/Untrusted Discriminator (TUD) - This RECOMMENDED variable specifies an arbitrary discriminator that determines whether a datagram is considered trusted or untrusted for the purposes of neighbor discovery. a TUD implementation MUST provide for at least per-source and per-interface discrimination although this MAY be controlled externally such as by a packet mark/tag being the basis of the TUD and separate processes of the router providing the infrastructure to set the value; for example, a packet examination ruleset setting a particular mark/tag bit upon a match or lack thereof. SLND Neighbor Solicitation Rate Limit ("SLND NS Rate Limit") - This REQUIRED variable specifies a threshold for multicast Neighbor Solicitations when the interface is performing SLND, specified in packets per second. This limit MUST be configurable on a per- interface basis but a router MAY provide for configuring a default or global rate for convenience. OPTIONAL granular rate limiting may be achieved by maintaining a table of sources, grouped on a large Smith, Ddin Expires April 21, 2013 [Page 4] Internet-Draft Stateless Neighbor Discovery October 18, 2012 boundary (/48 or bigger) in order to achieve weighted rate limiting that has a bigger impact on an attacking subnet. If such granular rate limiting is implemented, a router MUST NOT exceed the total interface rate threshold. SLND Hash Salt (NDHS) - If implementing Hashed SLND, This is a REQUIRED value that SHOULD be at least 8 octets in length, known only to the router and MUST change periodically to mitigate replay attacks. This value SHOULD NOT change more often than the typical time taken for successful resolution and it is RECOMMENDED that this value change approximately as often as the configured ND timeout. Neighbor Origin Flag (NOF) - This RECOMMENDED value indicates whether the neighbor was learned through stateful or stateless discovery. a router MAY also indicate whether the stateless discovery was hashed or unhashed. Thus this flag may have values of STATEFUL, STATELESS and optionally HSTATELESS. 3.2. SLND Process 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 packet's destination address is not present in the neighbor cache, and the SLND Flag is on, the TUD is referred to in order to ascertain whether the packet is trusted or not. If the packet is determined to be trusted or a non-REACHABLE neighbor entry exists with an origin of STATEFUL, traditional stateful neighbor discovery is performed. If the packet is determined to be untrusted, stateless neighbor discovery is performed. A router MUST implement unhashed SLND and MAY also implement hashed SLND. Where both SLND modes are implemented, a router MUST allow mode selection on a per-interface basis. For on-link prefixes of size /64 or more, defaulting to hashed SLND is RECOMMENDED. Smith, Ddin Expires April 21, 2013 [Page 5] Internet-Draft Stateless Neighbor Discovery October 18, 2012 3.3. Unhashed SLND The unhashed stateless neighbor discovery process is as follows: 1. 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. 2. A multicast neighbor solicitation is sent by the router for the destination address in the packet. The packet MAY then be dropped. If the packet is instead requeued, any subsequent dequeue of the same packet MUST NOT result in the transmission of another solicitation whilst in SLND mode. the packet SHOULD NOT be queued indefinitely. if the packet expires, the router MAY send an ICMPv6 error to the source but given the likely scenario for the activation of SLND, this is not recommended. 3. As some later point in time, the router may receive a unicast neighbor advertisement, for a previously sent neighbor solicitation. 4. If the SLND Active Flag is off and there is no stateful entry regarding the advertisement, the router ignores the neighbor advertisement. 5. 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 with an origin of STATELESS. Stateless neighbor discovery is now complete. Smith, Ddin Expires April 21, 2013 [Page 6] Internet-Draft Stateless Neighbor Discovery October 18, 2012 3.4. Hashed SLND The hashed stateless neighbor discovery process is as follows: 1. 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. 2. The router performs hash function H(x) where x is the concatenation of the IPv6 address to solicit and the NDHS, known only to the router. the hash function SHOULD result in a value of at least 8 octets in length and subsequently be used to replace the lower 8 octets (host portion) of the IPv6 address that would have been the source of the solicitation. When applicable to the link medium, a router MUST include the ICMPv6 option detailed in Section 4.6.1 of RFC 4861 indicating the data-link layer source as part of the solicitation message. 3. As some later point in time, the router may receive a unicast neighbor advertisement, for a previously sent neighbor solicitation. 4. If the SLND Active Flag is off and there is no stateful entry regarding the advertisement, the router ignores the neighbor advertisement. 5. If the SLND Active Flag is on and a matching REACHABLE entry does not exist, the router performs hash function H(y) where y is the concatenation of the advertised IPv6 address and the NDHS. The result of H(x) is then compared to the lower 8 octets (host portion) of the IPv6 destination address in the advertisement. If the result does not match, the advertisement is discarded; otherwise the information in the advertisement is used to update the neighbor cache and assigned an origin of HSTATELESS. The utilization of the neighbor cache has to be measured to determine if it crosses the SLND Activate Threshold. If the utilization increases above the SLND Activate Threshold, the SLND Active Flag is set, and if it decreases below the SLND Activate Threshold, the SLND Active Flag is unset. Neighbor cache utilization should be measured and compared to the SLND Activate Threshold when: o entries are added to the neighbor cache, during either stateful or stateless neighbor discovery. o entries are removed from the neighbor cache when NUD discovers the neighbor has become unreachable or timed out. Smith, Ddin Expires April 21, 2013 [Page 7] Internet-Draft Stateless Neighbor Discovery October 18, 2012 4. Consequences of Stateless Neighbor Discovery During traditional stateful neighbor discovery, state is used to perform the following: o ensure a received neighbor advertisement corresponds to a previously sent neighbor solicitation o to retransmit a limited number of neighbor solicitations if previous solicitations remain unanswered o to store a small number of packets that triggered the neighbor discovery process, so that they can be transmitted if neighbor discovery completes successfully o to generate an ICMPv6 destination unreachable, address unreachable messages back to the packet source, should the neighbor discovery process fail Unhashed stateless neighbor discovery sacrifices these functions and the related state to mitigate the neighbor cache DoS attack. Hashed stateless neighbor discovery retains much of the robustness of stateful ND at a cost of computation time for hash calculation, comparison and the minor risk of replay attacks although this is largely mitigated by appropriate tuning of the frequency by which the NDHS changes. However, per the behavior clarified in Section 3. of RFC 5942, the calculated source address will trigger a solicited host to create a neighbor entry for the source address, or in the unlikely event of the address already existing in the cache; cause the link- layer address to be updated. In either case, the entry will have an immediate state of STALE - thus not posing a problem in the unlikely event that the calculated IPv6 source is a duplicate address since the affected host will solicit the stale entry to determine its reachability. Routers implementing the NOF SHOULD evict STATELESS and then HSTATELESS entries in situations where the cache is full and space is needed to add a STATEFUL entry. A router MAY evict STATELESS entries in favor of HSTATELESS. Providing an interface for the administrator to evict all entries of a particular origin, change an entry's origin and the ability to configure the eviction strategy is RECOMMENDED. Smith, Ddin Expires April 21, 2013 [Page 8] Internet-Draft Stateless Neighbor Discovery October 18, 2012 4.1. Neighbor Advertisement Validation 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. For best-case performance, Hashed SLND should be performed to provide cache protection against both on-link and off-link attacks. 4.2. Optimization Functions The nature of IPv6 is best-effort, meaning that there is a possibility that packets may be lost as they transit the network. If an application residing on an IPv6 node requires reliable packet delivery, it should utilize 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 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 provides the opportunity to perform a stateless form of neighbor discovery if there is evidence that a neighbor cache DoS attack is occurring, mitigating the off-link sourced neighbor cache DoS attack. Smith, Ddin Expires April 21, 2013 [Page 9] Internet-Draft Stateless Neighbor Discovery October 18, 2012 5. Trusted/Untrusted Discriminator As previously described, the Trusted/Untrusted Discriminator (TUD) is used to determine whether a packet is trusted or untrusted, with trusted datagrams continuing to trigger traditional stateful neighbor discovery services, and untrusted ones receiving stateless neighbor discovery services. For routers where it may not be operationally convenient or possible to implement comprehensive trusted and untrusted datagram selection, such as on low-end or embedded devices, it would be acceptable to consider all datagram sources untrusted when stateless neighbor discovery is active. For routers that can support more comprehensive trusted and untrusted datagram discrimination, the following information sources are suggested for the purposes of configuring a default set of discriminators. 5.1. Configured Trusted and Untrusted Prefixes The first suggested TUD source is an operator configured 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, using the longest-match logic that is applied to IPv6 routing decisions. This list should have a default entry of the ULA prefix (fc00::/7) [RFC4193], flagged as a trusted source. An implementation MUST allow this entry to be removed. An implementation SHOULD NOT have this default entry if reverse path filtering is not possible or where spoofing is considered trivial. 5.2. Routing Information The second suggested TUD source is the network's routing information. The network's routing information can be used to distinguish trusted and untrusted datagram 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 individual routers in the network having to be manually reconfigured with trusted prefixes when subnets 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 Smith, Ddin Expires April 21, 2013 [Page 10] Internet-Draft Stateless Neighbor Discovery October 18, 2012 distinguish between trusted and untrusted sources, with datagram sources matching internal routes being trusted, and all other datagram 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, routes may be tagged with one or more BGP communities which indicate internal and therefore trusted prefixes. A default route SHOULD NOT be used to define a trusted datagram source prefix. 5.3. Default to Untrusted Should the value of the discriminator not match the required one that has been configured according to the bitmask, the packet SHOULD be considered untrusted. 5.4. Neighbor Origin Flag (NOF) in relation to the TUD If a packet is trusted and a neighbor entry already exists with an origin of STATELESS or HSTATELESS, a router SHOULD update the NOF of the entry to STATEFUL. A neighbor entry with a STATEFUL origin MUST NOT have its origin changed except by administrative intervention. 6. Baseline Implementation A baseline implementation of this document MUST provide unhashed SLND with the means to configure the trigger threshold and disable SLND entirely. A router SHOULD NOT make exclusive use of SLND, however, the possibility of this due to hardware or other constraints is nonetheless acknowledged. Such a router MUST permit for exclusively operator configured neighbor entries. Non-router nodes MAY use SLND as a way to mitigate cache pressure caused by local applications or similar. Non-router notes using hashed SLND MUST NOT use a calculated source address known to belong to a router, in these (unlikely) instances, the NDHS SHOULD be immediately changed. Smith, Ddin Expires April 21, 2013 [Page 11] Internet-Draft Stateless Neighbor Discovery October 18, 2012 7. Acknowledgements Review and comments were provided by Ray Hunter and Matthew Moyle- Croft. This memo was prepared using the xml2rfc tool and nroff I-D editor. 8. Security Considerations This memo proposes a security mitigation for an off-link sourced neighbor cache Denial of Service attack, aimed at a router. As discussed in Section 4.1, the unhashed 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. The hashed method mitigates the above issue at the cost of creating some additional unnecessary ND traffic and potentially having a window of opportunity for a replay attack. The benefit of Hashed SLND is considered to outweigh these costs. 9. IANA Considerations This document has no actions for IANA. 10. Change Log [RFC Editor please remove] 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 o more comprehensive introduction (problem definition) text o make it more obvious that hosts don't need to be changed o low-end/embedded hosts can consider all datagram sources untrusted o misc. minor text updates draft-smith-6man-mitigate-nd-cache-dos-slnd-02, major changes, 2012- 10-16 o Add definition of Hashed SLND. Smith, Ddin Expires April 21, 2013 [Page 12] Internet-Draft Stateless Neighbor Discovery October 18, 2012 o Expand optional scope for flexibility of SLND o Address potential security risks draft-smith-6man-mitigate-nd-cache-dos-slnd-03, major changes, 2012- 10-18 o Clarify the behavior caused by calculated source addresses o Add OPTIONAL Neighbor Origin Flag (NOF) o Add section outlining baseline implementation requirements. o Various other minor clarifications and fixups. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010. Smith, Ddin Expires April 21, 2013 [Page 13] Internet-Draft Stateless Neighbor Discovery October 18, 2012 Author's Addresses Mark Smith In My Own Time PO BOX 521 HEIDELBERG, VIC 3084 AU Email: markzzzsmith@yahoo.com.au Oliver Ddin ZeroLag Communications 289 S. Robertson Blvd #441 Beverly Hills, CA 90211 USA Email: oliver@zerolag.com Smith, Ddin Expires April 21, 2013 [Page 14]