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 updates RFC 4861 with a stateless form of neighbor discovery; it
does not require any changes to hosts.
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.
draft-smith-6man-mitigate-nd-cache-dos-slnd-04, minor changes, 2012-
10-18
o Cleaned up heading spacing.
o Adjusted abstract to explicitly state that it updates RFC 4861
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.
Smith, Ddin Expires April 21, 2013 [Page 13]
Internet-Draft Stateless Neighbor Discovery October 18, 2012
[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.
Author's
Mark Smith
In My Own Time
Oliver Ddin
ZeroLag Communications
Additional Source: Internet Engineering Task Force
