draft-ietf-v6ops-v6nd-problems-02.txt   draft-ietf-v6ops-v6nd-problems-03.txt 
v6ops I. Gashinsky v6ops I. Gashinsky
Internet-Draft Yahoo! Internet-Draft Yahoo!
Intended status: Informational J. Jaeggli Intended status: Informational J. Jaeggli
Expires: July 11, 2012 Zynga Expires: July 28, 2012 Zynga
W. Kumari W. Kumari
Google Inc Google Inc
January 8, 2012 January 25, 2012
Operational Neighbor Discovery Problems Operational Neighbor Discovery Problems
draft-ietf-v6ops-v6nd-problems-02 draft-ietf-v6ops-v6nd-problems-03
Abstract Abstract
In IPv4, subnets are generally small, made just large enough to cover In IPv4, subnets are generally small, made just large enough to cover
the actual number of machines on the subnet. In contrast, the the actual number of machines on the subnet. In contrast, the
default IPv6 subnet size is a /64, a number so large it covers default IPv6 subnet size is a /64, a number so large it covers
trillions of addresses, the overwhelming number of which will be trillions of addresses, the overwhelming number of which will be
unassigned. Consequently, simplistic implementations of Neighbor unassigned. Consequently, simplistic implementations of Neighbor
Discovery can be vulnerable to deliberate or accidental denial of Discovery (ND) can be vulnerable to deliberate or accidental denial
service, whereby they attempt to perform address resolution for large of service, whereby they attempt to perform address resolution for
numbers of unassigned addresses. Such denial of attacks can be large numbers of unassigned addresses. Such denial of attacks can be
launched intentionally (by an attacker), or result from legitimate launched intentionally (by an attacker), or result from legitimate
operational tools or accident conditions. As a result of these operational tools or accident conditions. As a result of these
vulnerabilities, new devices may not be able to "join" a network, it vulnerabilities, new devices may not be able to "join" a network, it
may be impossible to establish new IPv6 flows, and existing IPv6 may be impossible to establish new IPv6 flows, and existing IPv6
transported flows may be interrupted. transported flows may be interrupted.
This document describes the potential for DOS in detail and suggests This document describes the potential for DOS in detail and suggests
possible implementation improvements as well as operational possible implementation improvements as well as operational
mitigation techniques that can in some cases be used to protect mitigation techniques that can in some cases be used to protect
against or at least alleviate the impact of such attacks. against or at least alleviate the impact of such attacks.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 11, 2012. This Internet-Draft will expire on July 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Neighbor Discovery Overview . . . . . . . . . . . . . . . . . 7 5. Neighbor Discovery Overview . . . . . . . . . . . . . . . . . 7
6. Operational Mitigation Options . . . . . . . . . . . . . . . . 8 6. Operational Mitigation Options . . . . . . . . . . . . . . . . 8
6.1. Filtering of unused address space. . . . . . . . . . . . . 8 6.1. Filtering of unused address space. . . . . . . . . . . . . 8
6.2. Minimal Subnet Sizing. . . . . . . . . . . . . . . . . . . 8 6.2. Minimal Subnet Sizing. . . . . . . . . . . . . . . . . . . 8
6.3. Routing Mitigation. . . . . . . . . . . . . . . . . . . . 8 6.3. Routing Mitigation. . . . . . . . . . . . . . . . . . . . 9
6.4. Tuning of the NDP Queue Rate Limit. . . . . . . . . . . . 9 6.4. Tuning of the NDP Queue Rate Limit. . . . . . . . . . . . 9
7. Recommendations for Implementors. . . . . . . . . . . . . . . 9 7. Recommendations for Implementors. . . . . . . . . . . . . . . 9
7.1. Prioritize NDP Activities . . . . . . . . . . . . . . . . 10 7.1. Prioritize NDP Activities . . . . . . . . . . . . . . . . 10
7.2. Queue Tuning. . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Queue Tuning. . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document describes implementation issues with IPv6's Neighbor This document describes implementation issues with IPv6's Neighbor
Discovery protocol that can result in vulnerabilities when a network Discovery protocol that can result in vulnerabilities when a network
is scanned, either by an intruder or through the use of scanning is scanned, either by an intruder or through the use of scanning
tools that perform network inventory, security audits, etc. (e.g., tools that perform network inventory, security audits, etc. (e.g.
"nmap"). "nmap").
This document describes the problem in detail and suggests possible This document describes the problem in detail, suggests possible
implementation improvements as well as operational mitigation implementation improvements, as well as operational mitigation
techniques that can in some cases to protect against such attacks. techniques, that can in some cases protect against such attacks.
The RFC series documents generally describe the behavior of The RFC series documents generally describe the behavior of
protocols, that is, "what" is to be done by a protocol, but not protocols, that is, "what" is to be done by a protocol, but not
exactly "how" it is to be implemented. The exact details of how best exactly "how" it is to be implemented. The exact details of how best
to implement a protocol will depend on the overall hardware and to implement a protocol will depend on the overall hardware and
software architecture of a particular device. The actual "how" software architecture of a particular device. The actual "how"
decisions are (correctly) left in the hands of implementers, so long decisions are (correctly) left in the hands of implementers, so long
as implementations differences will generally produce proper on-the- as implementations differences will generally produce proper on-the-
wire behavior. wire behavior.
While reading this document, it is important to keep in mind that While reading this document, it is important to keep in mind that
discussions of how things have been implemented beyond basic discussions of how things have been implemented beyond basic
compliance with the specification is not within the scope of the compliance with the specification is not within the scope of the
neighbor discovery RFCs. neighbor discovery RFCs.
1.1. Applicability 1.1. Applicability
This document is primarily intended for operators of IPV6 networks This document is primarily intended for operators of IPV6 networks
and implementors of [RFC4861]. The Document provides some and implementors of [RFC4861]. The Document provides some
operational consideration as well as recommendations to increase the operational considerations as well as recommendations to increase the
resilience of the Neighbor Discovery protocol. resilience of the Neighbor Discovery protocol.
2. The Problem 2. The Problem
In IPv4, subnets are generally small, made just large enough to cover In IPv4, subnets are generally small, made just large enough to cover
the actual number of machines on the subnet. For example, an IPv4 the actual number of machines on the subnet. For example, an IPv4
/20 contains only 4096 address. In contrast, the default IPv6 subnet /20 contains only 4096 address. In contrast, the default IPv6 subnet
size is a /64, a number so large it covers literally billions of size is a /64, a number so large it covers literally billions of
billions of addresses, the overwhelming number of which will be billions of addresses, the overwhelming majority of which will be
unassigned. Consequently, simplistic implementations of Neighbor unassigned. Consequently, simplistic implementations of Neighbor
Discovery can be vulnerable to denial of service attacks whereby they Discovery may fail to perform as desired when they perform address
perform address resolution for large numbers of unassigned addresses. resolution of large numbers of unassigned addresses. Such failures
Such denial of attacks can be launched intentionally (by an can be triggered either intentionally by an attacker launching a
attacker), or result from legitimate operational tools that scan Denial of Service attack (DoS) to exploit this vulnerability, or
networks for inventory and other purposes. As a result of these unintentionally due to the use of legitimate operational tools that
vulnerabilities, new devices may not be able to "join" a network, it scan networks for inventory and other purposes. As a result of these
may be impossible to establish new IPv6 flows, and existing ipv6 failures, new devices may not be able to "join" a network, it may be
transport flows may be interrupted. impossible to establish new IPv6 flows, and existing IPv6 transport
flows may be interrupted.
Network scans attempt to find and probe devices on a network. Network scans attempt to find and probe devices on a network.
Typically, scans are performed on a range of target addresses, or all Typically, scans are performed on a range of target addresses, or all
the addresses on a particular subnet. When such probes are directed the addresses on a particular subnet. When such probes are directed
via a router, and the target addresses are on a directly attached via a router, and the target addresses are on a directly attached
network, the router will attempt to perform address resolution on a network, the router will attempt to perform address resolution on a
large number of destinations (i.e., some fraction of the 2^64 large number of destinations (i.e., some fraction of the 2^64
addresses on the subnet). The router's process of testing for the addresses on the subnet). The router's process of testing for the
(non)existence of neighbors can induce a denial of service condition, (non)existence of neighbors can induce a denial of service condition,
where the number of necessary Neighbor Discovery requests overwhelms where the number of necessary Neighbor Discovery requests overwhelms
the implementation's capacity to process them, exhausts available the implementation's capacity to process them, exhausts available
memory, replaces existing in-use mappings with incomplete entries memoryand replaces existing in-use mappings with incomplete entries
that will never be completed, and so on. The resulting network that will never be completed. A directed DoS attack may seek to
disruption, may impact existing traffic, and devices that join the intentionally create similar conditions to that created
network may find that address resolution attempts fail. The DOS as a unintentionally by a network scan. The resulting network disruption
consequence of network scanning was previously described in [RFC5157] may impact existing traffic, and devices that join the network may
find that address resolution attempts fail. The DOS as a consequence
of network scanning was previously described in [RFC5157]
In order to alleviate risk associated with this DOS threat, some In order to mitigate risk associated with this DoS threat, some
router implementations have taken steps to rate-limit the processing router implementations have taken steps to rate-limit the processing
rate of Neighbor Solicitations (NS). While these mitigations do rate of Neighbor Solicitations (NS). While these mitigations do
help, they do not fully address the issue and may introduce their own help, they do not fully address the issue and may introduce their own
set of potential liabilities to the neighbor discovery process. set of issues to the neighbor discovery process.
3. Terminology 3. Terminology
Address Resolution Address resolution is the process through which a Address Resolution Address resolution is the process through which a
node determines the link-layer address of a neighbor given only node determines the link-layer address of a neighbor given only
its IP address. In IPv6, address resolution is performed as part its IP address. In IPv6, address resolution is performed as part
of Neighbor Discovery [RFC4861], p60 of Neighbor Discovery [RFC4861], p60
Forwarding Plane That part of a router responsible for forwarding Forwarding Plane That part of a router responsible for forwarding
packets. In higher-end routers, the forwarding plane is typically packets. In higher-end routers, the forwarding plane is typically
implemented in specialized hardware optimized for performance. implemented in specialized hardware optimized for performance.
Forwarding steps include determining the correct outgoing Steps in the forwarding process include determining the correct
interface for a packet, decrementing its Time To Live (TTL), outgoing interface for a packet, decrementing its Time To Live
verifying and updating the checksum, placing the correct link- (TTL), verifying and updating the checksum, placing the correct
layer header on the packet, and forwarding it. link-layer header on the packet, and forwarding it.
Control Plane That part of the router implementation that maintains Control Plane That part of the router implementation that maintains
the data structures that determine where packets should be the data structures that determine where packets should be
forwarded. The control plane is typically implemented as a forwarded. The control plane is typically implemented as a
"slower" software process running on a general purpose processor "slower" software process running on a general purpose processor
and is responsible for such functions as the routing protocols, and is responsible for such functions as communicating network
performing management and resolving the correct link-layer address status changes via routing protocols, maintaining the forwarding
for adjacent neighbors. The control plane "controls" the table, performing management, and resolving the correct link-layer
address for adjacent neighbors. The control plane "controls" the
forwarding plane by programming it with the information needed for forwarding plane by programming it with the information needed for
packet forwarding. packet forwarding.
Neighbor Cache As described in [RFC4861], the data structure that Neighbor Cache As described in [RFC4861], the data structure that
holds the cache of (amongst other things) IP address to link-layer holds the cache of (amongst other things) IP address to link-layer
address mappings for connected nodes. The forwarding plane address mappings for connected nodes. As the information in the
accesses the Neighbor Cache on every forwarded packet. Thus it is Neighbor Cache is needed by the forwarding plane every time it
usually implemented in an ASIC . forwards a packet, it is usually implemented in an ASIC.
Neighbor Discovery Process The Neighbor Discovery Process (NDP) is Neighbor Discovery Process The Neighbor Discovery Process (NDP) is
that part of the control plane that implements the Neighbor that part of the control plane that implements the Neighbor
Discovery protocol. NDP is responsible for performing address Discovery protocol. NDP is responsible for performing address
resolution and maintaining the Neighbor Cache. When forwarding resolution and maintaining the Neighbor Cache. When forwarding
packets, the forwarding plane accesses entries within the Neighbor packets, the forwarding plane accesses entries within the Neighbor
Cache. When the forwarding plane processes a packet for which the Cache. When the forwarding plane processes a packet for which the
corresponding Neighbor Cache Entry is missing or incomplete, it corresponding Neighbor Cache Entry is missing or incomplete, it
notifies NDP to take appropriate action (typically via a shared notifies NDP to take appropriate action (typically via a shared
queue). NDP picks up requests from the shared queue and performs queue). NDP picks up requests from the shared queue and performs
skipping to change at page 7, line 15 skipping to change at page 7, line 19
In order to protect NDP specifically and the control plane generally In order to protect NDP specifically and the control plane generally
from being overwhelmed with these requests, appropriate steps must be from being overwhelmed with these requests, appropriate steps must be
taken. For example, the size and fill rate of the queue might be taken. For example, the size and fill rate of the queue might be
limited. NDP running in the control plane of the router dequeues limited. NDP running in the control plane of the router dequeues
requests and performs the address resolution function (by performing requests and performs the address resolution function (by performing
a neighbor solicitation and listening for a neighbor advertisement). a neighbor solicitation and listening for a neighbor advertisement).
This process is usually also responsible for other activities needed This process is usually also responsible for other activities needed
to maintain link-layer information, such as Neighbor Unreachability to maintain link-layer information, such as Neighbor Unreachability
Detection (NUD). Detection (NUD).
An attacker sending the appropriate packets to addresses on a given By sending appropriate packets to addresses on a given subnet, an
subnet can cause the router to queue attempts to resolve so many attacker can cause the router to queue attempts to resolve so many
addresses that it crowds out attempts to resolve "legitimate" addresses that it crowds out attempts to resolve "legitimate"
addresses (and in many cases becomes unable to perform maintenance of addresses (and in many cases becomes unable to perform maintenance of
existing entries in the neighbor cache, and unable to answer Neighbor existing entries in the neighbor cache, and unable to answer Neighbor
Solicitation). This condition can result in the inability to resolve Solicitation). This condition can result in the inability to resolve
new neighbors and loss of reachability to neighbors with existing ND- new neighbors and loss of reachability to neighbors with existing ND-
Cache entries. During testing it was concluded that 4 simultaneous Cache entries. During testing it was concluded that 4 simultaneous
nmap sessions from a low-end computer was sufficient to make a nmap sessions from a low-end computer was sufficient to make a
router's neighbor discovery process unusable and therefore forwarding router's neighbor discovery process unusable and therefore forwarding
became unavailable to the destination subnets. became unavailable to the destination subnets.
The NDP behavior under attack has been observed across multiple The failure to maintain proper NDP behavior whilst under attack has
platforms and implementations. been observed across multiple platforms and implementations,
including the largest routers available (when this document was
started) from two of the largest vendors.
5. Neighbor Discovery Overview 5. Neighbor Discovery Overview
When a packet arrives at (or is generated by) a router for a When a packet arrives at (or is generated by) a router for a
destination on an attached link, the router needs to determine the destination on an attached link, the router needs to determine the
correct link-layer address to send the packet to. The router checks correct link-layer address to use in the destination field of the
the Neighbor Cache for an existing Neighbor Cache Entry for the layer 2 encapsulation. The router checks the Neighbor Cache for an
neighbor, and if none exists, invokes the address resolution portions existing Neighbor Cache Entry for the neighbor, and if none exists,
of the IPv6 Neighbor Discovery [RFC4861] protocol to determine the invokes the address resolution portions of the IPv6 Neighbor
link-layer address. Discovery [RFC4861] protocol to determine the link-layer address of
the neighbor.
[RFC4861] Section 5.2 (Conceptual Sending Algorithm) outlines how [RFC4861] Section 5.2 (Conceptual Sending Algorithm) outlines how
this process works. A very high level summary is that the device this process works. A very high level summary is that the device
creates a new Neighbor Cache Entry for the neighbor, sets the state creates a new Neighbor Cache Entry for the neighbor, sets the state
to INCOMPLETE, queues the packet and initiates the actual address to INCOMPLETE, queues the packet and initiates the actual address
resolution process. The device then sends out one or more Neighbor resolution process. The device then sends out one or more Neighbor
Solicitations, and when it receives a corresponding Neighbor Solicitations, and when it receives a corresponding Neighbor
Advertisement, completes the Neighbor Cache Entry and sends the Advertisement, completes the Neighbor Cache Entry and sends the
queued packet. queued packet.
skipping to change at page 8, line 18 skipping to change at page 8, line 22
employed today by network operators in order to protect network employed today by network operators in order to protect network
availability while vendors implement more effective protection availability while vendors implement more effective protection
measures. It can be stipulated that some of these options are measures. It can be stipulated that some of these options are
"kludges", and are operationally difficult to manage. They are "kludges", and are operationally difficult to manage. They are
presented, as they represent options we currently have. It is each presented, as they represent options we currently have. It is each
operator's responsibility to evaluate and understand the impact of operator's responsibility to evaluate and understand the impact of
changes to their network due to these measures. changes to their network due to these measures.
6.1. Filtering of unused address space. 6.1. Filtering of unused address space.
The DOS condition is induced by making a router try to resolve The DoS condition is induced by making a router try to resolve
addresses on the subnet at a high rate. By carefully addressing addresses on the subnet at a high rate. By carefully addressing
machines into a small portion of a subnet (such as the lowest machines into a small portion of a subnet (such as the lowest
numbered addresses), it is possible to filter access to addresses not numbered addresses), it is possible to filter access to addresses not
in that portion. This will prevent the attacker from making the in that assigned portion of address space using Access Control Lists
(ACLs), or by null routing, features which are available on most
existing platforms. This will prevent the attacker from making the
router attempt to resolve unused addresses. For example if there are router attempt to resolve unused addresses. For example if there are
only 50 hosts connected to an interface, you may be able to filter only 50 hosts connected to an interface, you may be able to filter
any address above the first 64 addresses of that subnet by null- any address above the first 64 addresses of that subnet by null-
routing the subnet carrying a more specific /122 route. routing the subnet carrying a more specific /122 route or by applying
ACLs on the WAN link to prevent the attack traffic reaching the
vulnerable device.
As mentioned at the beginning of this section, it is fully understood As mentioned at the beginning of this section, it is fully understood
that this is ugly (and difficult to manage); but failing other that this is ugly (and difficult to manage); but failing other
options, it may be a useful technique especially when responding to options, it may be a useful technique especially when responding to
an attack. an attack.
This solution requires that the hosts be statically or statefully This solution requires that the hosts be statically or statefully
addressed (as is often done in a datacenter) and may not interact addressed (as is often done in a datacenter) and may not interact
well with networks using [RFC4862] well with networks using [RFC4862]
skipping to change at page 9, line 15 skipping to change at page 9, line 25
announce routes for their IP addresses into the network (or use some announce routes for their IP addresses into the network (or use some
method to inject much more specific addresses into the local routing method to inject much more specific addresses into the local routing
domain). For example the network 2001:db8:1:2:3::/64 could be routed domain). For example the network 2001:db8:1:2:3::/64 could be routed
to a discard interface on "border" routers, and then individual hosts to a discard interface on "border" routers, and then individual hosts
could announce 2001:db8:1:2:3::10/128, 2001:db8:1:2:3::66/128 into could announce 2001:db8:1:2:3::10/128, 2001:db8:1:2:3::66/128 into
the IGP. This is typically done by having the IP address bound to a the IGP. This is typically done by having the IP address bound to a
virtual interface on the host (for example the loopback interface), virtual interface on the host (for example the loopback interface),
enabling IP forwarding on the host and having it run a routing enabling IP forwarding on the host and having it run a routing
daemon. For obvious reasons, host participation in the IGP makes daemon. For obvious reasons, host participation in the IGP makes
many operators uncomfortable, but can be a very powerful technique if many operators uncomfortable, but can be a very powerful technique if
used in a disciplined and controlled manner. used in a disciplined and controlled manner. One method to help
address these concerns is to have the hosts participate in a
different IGP (or difference instance of the same IGP) and carefully
redistribute into the main IGP.
6.4. Tuning of the NDP Queue Rate Limit. 6.4. Tuning of the NDP Queue Rate Limit.
Many implementations provide a means to control the rate of Many implementations provide a means to control the rate of
resolution of unknown addresses. By tuning this rate, it may be resolution of unknown addresses. By tuning this rate, it may be
possible to ameliorate the issue, as with most tuning knobs possible to ameliorate the issue, as with most tuning knobs
(especially those that deal with rate limiting), the attack may be (especially those that deal with rate limiting), the attack may be
completed more quickly due to the lower threshold. By excessively completed more quickly due to the lower threshold. By excessively
lowering this rate you may negatively impact how long the device lowering this rate you may negatively impact how long the device
takes to learn new addresses under normal conditions (for example, takes to learn new addresses under normal conditions (for example,
after clearing the neighbor cache or when the router first boots). after clearing the neighbor cache or when the router first boots).
Under attack conditions you may be unable to resolve "legitimate" Under attack conditions you may be unable to resolve "legitimate"
addresses sooner than if you had just left the parameter untouched. addresses sooner than if you had just left the parameter untouched.
It is worth noting that this technique is worth investigating only if It is worth noting that this technique is worth investigating only if
the device has separate queues for resolution of unknown addresses the device has separate queues for resolution of unknown addresses
and the maintenance of existing entries. and the maintenance of existing entries.
7. Recommendations for Implementors. 7. Recommendations for Implementors.
The section provides some recommendations to implementors of IPv4 The section provides some recommendations to implementors of IPv6
Neighbor Discovery. Neighbor Discovery.
At a high-level, implementors should program defensively. That is, At a high-level, implementors should program defensively. That is,
they should assume that intruders will attempt to exploit they should assume that attackers will attempt to exploit
implementation weaknesses, and should ensure that implementations are implementation weaknesses, and should ensure that implementations are
robust to various attacks. In the case of Neighbor Discovery, the robust to various attacks. In the case of Neighbor Discovery, the
following general considerations apply: following general considerations apply:
Manage Resources Explicitly - Resources such as processor cycles, Manage Resources Explicitly Resources such as processor cycles,
memory, etc. are never infinite, yet with IPv6's large subnets it memory, etc. are never infinite, yet with IPv6's large subnets it
is easy to cause NDP to generate large numbers of address is easy to cause NDP to generate large numbers of address
resolution requests for non-existent destinations. resolution requests for non-existent destinations.
Implementations need to limit resources devoted to processing Implementations need to limit resources devoted to processing
Neighbor Discovery requests in a thoughtful manner. Neighbor Discovery requests in a thoughtful manner.
Prioritize - Some NDP requests are more important than others. For Prioritize Some NDP requests are more important than others. For
example, when resources are limited, responding to Neighbor example, when resources are limited, responding to Neighbor
Solicitations for one's own address is more important than Solicitations for one's own address is more important than
initiating address resolution requests that create new entries. initiating address resolution requests that create new entries.
Likewise, performing Neighbor Unreachability Detection, which by Likewise, performing Neighbor Unreachability Detection, which by
definition is only invoked on destinations that are actively being definition is only invoked on destinations that are actively being
used, is more important than creating new entries for possibly used, is more important than creating new entries for possibly
non-existent neighbors. non-existent neighbors.
7.1. Prioritize NDP Activities 7.1. Prioritize NDP Activities
Not all Neighbor Discovery activities are equally important. Not all Neighbor Discovery activities are equally important.
Specifically, requests to perform large numbers of address Specifically, requests to perform large numbers of address
resolutions on non-existent Neighbor Cache Entries should not come at resolutions on non-existent Neighbor Cache Entries should not come at
the expense of servicing requests related to keeping existing, in-use the expense of servicing requests related to keeping existing, in-use
entries properly up-to-date. Thus, implementations should divide entries properly up-to-date. Thus, implementations should divide
work activities into categories having different priorities. The work activities into categories having different priorities. The
following gives examples of different activities and their importance following gives examples of different activities and their importance
in rough priority order. in rough priority order. If implmented, the operation and priority
of these SHOULD be configurable by the operator.
1. It is critical to respond to Neighbor Solicitations for one's own 1. It is critical to respond to Neighbor Solicitations for one's own
address, especially when a router. Whether for address resolution or address, especially for a router. Whether for address resolution or
Neighbor Unreachability Detection, failure to respond to Neighbor Neighbor Unreachability Detection, failure to respond to Neighbor
Solicitations results in immediate problems. Failure to respond to Solicitations results in immediate problems. Failure to respond to
NS requests that are part of NUD can cause neighbors to delete the NS requests that are part of NUD can cause neighbors to delete the
NCE for that address, and will result in followup NS messages using NCE for that address, and will result in followup NS messages using
multicast. Once an entry has been flushed, existing traffic for multicast. Once an entry has been flushed, existing traffic for
destinations using that entry can no longer be forwarded until destinations using that entry can no longer be forwarded until
address resolution completes successfully. In other words, not address resolution completes successfully. In other words, not
responding to NS messages further increases the NDP load, and causes responding to NS messages further increases the NDP load, and causes
on-going communication to fail. on-going communication to fail.
skipping to change at page 11, line 5 skipping to change at page 11, line 19
using that entry can no longer be forwarded until address resolution using that entry can no longer be forwarded until address resolution
completes successfully. completes successfully.
3. To maintain the stability of the control plane, Neighbor 3. To maintain the stability of the control plane, Neighbor
Discovery activity related to traffic sourced by the router (as Discovery activity related to traffic sourced by the router (as
opposed to traffic being forwarded by the router) should be given opposed to traffic being forwarded by the router) should be given
high priority. Whenever network problems occur, debugging and making high priority. Whenever network problems occur, debugging and making
other operational changes requires being able to query and access the other operational changes requires being able to query and access the
router. In addition, routing protocols dependent on Neighbor router. In addition, routing protocols dependent on Neighbor
Discovery for connectivity may begin to react (negatively) to Discovery for connectivity may begin to react (negatively) to
perceived connectivity problems, causing addition undesirable ripple perceived connectivity problems, causing additional undesirable
effects. ripple effects.
4. Traffic to unknown addresses should be given lowest priority. 4. Traffic to unknown addresses should be given lowest priority.
Indeed, it may be useful to distinguish between "never seen" Indeed, it may be useful to distinguish between "never seen"
addresses and those that have been seen before, but that do not have addresses and those that have been seen before, but that do not have
a corresponding NCE. Specifically, the conceptual processing a corresponding NCE. Specifically, the conceptual processing
algorithm in IPv6 Neighbor Discovery [RFC4861] calls for deleting algorithm in IPv6 Neighbor Discovery [RFC4861] calls for deleting
NCEs under certain conditions. Rather than delete them completely, NCEs under certain conditions. Rather than delete them completely,
however, it might be useful to at least keep track of the fact that however, it might be useful to at least keep track of the fact that
an entry at one time existed, in order to prioritize address an entry at one time existed, in order to prioritize address
resolution requests for such neighbors compared with neighbors that resolution requests for such neighbors compared with neighbors that
have never been seen before. have never been seen before.
7.2. Queue Tuning. 7.2. Queue Tuning.
On implementations in which requests to NDP are submitted via a On implementations in which requests to NDP are submitted via a
single queue, router vendors SHOULD provide operators with means to single queue, router vendors SHOULD provide operators with means to
control both the rate of link-layer address resolution requests control both the rate of link-layer address resolution requests
placed into the queue and the size of the queue. This will allow placed into the queue and the size of the queue. This will allow
operators to tune Neighbour Discovery for their specific environment. operators to tune Neighbour Discovery for their specific environment.
The ability to set, or have per interface or subnet queue limits at a The ability to set, or have per interface or per prefix queue limits
rate below that of the global queue limit might limit the damage to at a rate below that of the global queue limit might limit the damage
the neighbor discovery processing to the network targeted by the to the neighbor discovery processing to the network targeted by the
attack. attack.
Setting those values must be a very careful balancing act - the lower Setting those values must be a very careful balancing act - the lower
the rate of entry into the queue, the less load there will be on the the rate of entry into the queue, the less load there will be on the
ND process, however, it will take the router longer to learn ND process, however, it will take the router longer to learn
legitimate destinations as a result. In a datacenter with 6,000 legitimate destinations as a result. In a datacenter with 6,000
hosts attached to a single router, setting that value to be under hosts attached to a single router, setting that value to be under
1000 would mean that resolving all of the addresses from an initial 1000 would mean that resolving all of the addresses from an initial
state (or something that invalidates the address cache, such as a STP state (or something that invalidates the address cache, such as a STP
TCN) may take over 6 seconds. Similarly, the lower the size of the TCN) may take over 6 seconds. Similarly, the lower the size of the
skipping to change at page 12, line 8 skipping to change at page 12, line 20
No IANA resources or consideration are requested in this draft. No IANA resources or consideration are requested in this draft.
9. Security Considerations 9. Security Considerations
This document outlines mitigation options that operators can use to This document outlines mitigation options that operators can use to
protect themselves from Denial of Service attacks. Implementation protect themselves from Denial of Service attacks. Implementation
advice to router vendors aimed at ameliorating known problems carries advice to router vendors aimed at ameliorating known problems carries
the risk of previously unforeseen consequences. It is not believed the risk of previously unforeseen consequences. It is not believed
that these mitigation techniques or the implementation of finer- that these mitigation techniques or the implementation of finer-
grained queuing of NDP activity create additional security risks or grained queuing of NDP activity create additional security risks or
DOS exposure. DoS exposure.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Ron Bonica, Troy Bonin, John Jason The authors would like to thank Ron Bonica, Troy Bonin, John Jason
Brzozowski, Randy Bush, Vint Cerf, Tassos Chatzithomaoglou, Jason Brzozowski, Randy Bush, Vint Cerf, Tassos Chatzithomaoglou, Jason
Fesler, Wes George, Erik Kline, Jared Mauch, Chris Morrow and Suran Fesler, Wes George, Erik Kline, Jared Mauch, Chris Morrow and Suran
De Silva. Special thanks to Thomas Narten for detailed review and De Silva. Special thanks to Thomas Narten and Ray Hunter for
(even more so) for providing text! detailed review and (even more so) for providing text!
Apologies for anyone we may have missed; it was not intentional. Apologies for anyone we may have missed; it was not intentional.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 36 change blocks. 
70 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/