draft-ietf-v6ops-v6nd-problems-00.txt   draft-ietf-v6ops-v6nd-problems-01.txt 
v6ops I. Gashinsky v6ops I. Gashinsky
Internet-Draft Yahoo! Internet-Draft Yahoo!
Intended status: Informational J. Jaeggli Intended status: Informational J. Jaeggli
Expires: April 26, 2012 Zynga Expires: June 6, 2012 Zynga
W. Kumari W. Kumari
Google Google
October 24, 2011 December 4, 2011
Operational Neighbor Discovery Problems Operational Neighbor Discovery Problems
draft-ietf-v6ops-v6nd-problems-00 draft-ietf-v6ops-v6nd-problems-01
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 can be vulnerable to deliberate or accidental denial of
service, whereby they attempt to perform address resolution for large service, whereby they attempt to perform address resolution for large
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 April 26, 2012. This Internet-Draft will expire on June 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . 7 6. Operational Mitigation Options . . . . . . . . . . . . . . . . 7
6.1. Filtering of unused address space. . . . . . . . . . . . . 8 6.1. Filtering of unused address space. . . . . . . . . . . . . 8
6.2. Appropriate Subnet Sizing. . . . . . . . . . . . . . . . . 8 6.2. Minimal Subnet Sizing. . . . . . . . . . . . . . . . . . . 8
6.3. Routing Mitigation. . . . . . . . . . . . . . . . . . . . 8 6.3. Routing Mitigation. . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . 12
Appendix A. Text goes here. . . . . . . . . . . . . . . . . . . . 12 Appendix A. Text goes here. . . . . . . . . . . . . . . . . . . . 12
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 and suggests possible
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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)existance of neighbors can induce a denial of service condition, (non)existance 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 memory, replaces existing in-use mappings with incomplete entries
that will never be completed, and so on. The resulting network that will never be completed, and so on. The resulting network
disruption, may impact existing traffic, and devices that join the disruption, may impact existing traffic, and devices that join the
network may find that address resolution attempts fail. 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 alleviate 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 potential liabilities 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
skipping to change at page 7, line 35 skipping to change at page 7, line 36
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 send the packet to. The router checks
the Neighbor Cache for an existing Neighbor Cache Entry for the the Neighbor Cache for an existing Neighbor Cache Entry for the
neighbor, and if none exists, invokes the address resolution portions neighbor, and if none exists, invokes the address resolution portions
of the IPv6 Neighbor Discovery [RFC4861] protocol to determine the of the IPv6 Neighbor Discovery [RFC4861] protocol to determine the
link-layer address. link-layer address.
RFC4861 Section 5.2 (Conceptual Sending Algorithm) outlines how this [RFC4861] Section 5.2 (Conceptual Sending Algorithm) outlines how
process works. A very high level summary is that the device creates this process works. A very high level summary is that the device
a new Neighbor Cache Entry for the neighbor, sets the state to creates a new Neighbor Cache Entry for the neighbor, sets the state
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 correpsonding Neighbor Solicitations, and when it receives a correpsonding Neighbor
Advertisement, completes the Neighbor Cache Entry and sends the Advertisement, completes the Neighbor Cache Entry and sends the
queued packet. queued packet.
6. Operational Mitigation Options 6. Operational Mitigation Options
This section provides some feasible mitigation options that can be This section provides some feasible mitigation options that can be
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
skipping to change at page 8, line 30 skipping to change at page 8, line 31
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]
6.2. Appropriate Subnet Sizing. 6.2. Minimal Subnet Sizing.
By sizing subnets to reflect the number of addresses actually in use, By sizing subnets to reflect the number of addresses actually in use,
the problem can be avoided. For example, [RFC6164] recommends sizing the problem can be avoided. For example, [RFC6164] recommends sizing
the subnets for inter-router links to only have 2 addresses (a /127). the subnets for inter-router links to only have 2 addresses (a /127).
It is worth noting that this practice is common in IPv4 networks, in It is worth noting that this practice is common in IPv4 networks, in
part to protect against the harmful effects of ARP request flooding. part to protect against the harmful effects of ARP request flooding.
Subnet prefixes longer than a /64 are not able to use stateless auto-
configuration [RFC4862] so this approach is not suitable for use with
hosts that are not statically configured.
6.3. Routing Mitigation. 6.3. Routing Mitigation.
One very effective technique is to route the subnet to a discard One very effective technique is to route the subnet to a discard
interface (most modern router platforms can discard traffic in interface (most modern router platforms can discard traffic in
hardware / the forwarding plane) and then have individual hosts hardware / the forwarding plane) and then have individual hosts
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
skipping to change at page 12, line 22 skipping to change at page 12, line 23
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.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
System (DNS)", RFC 4398, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, April 2011. Router Links", RFC 6164, April 2011.
11.2. Informative References 11.2. Informative References
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
January 2006. January 2006.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, March 2008.
Appendix A. Text goes here. Appendix A. Text goes here.
TBD TBD
Authors' Addresses Authors' Addresses
Igor Igor
Yahoo! Yahoo!
45 W 18th St 45 W 18th St
New York, NY New York, NY
 End of changes. 12 change blocks. 
15 lines changed or deleted 20 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/