idnits 2.17.00 (12 Aug 2021) /tmp/idnits36920/draft-gashinsky-6man-v6nd-enhance-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4861]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 19, 2012) is 3531 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 317, but no explicit reference was found in the text == Unused Reference: 'RFC4398' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC6164' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-impatient-nud' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC4255' is defined on line 342, but no explicit reference was found in the text == Outdated reference: draft-ietf-6man-impatient-nud has been published as RFC 7048 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational I. Gashinsky 5 Expires: March 23, 2013 Yahoo! 6 J. Jaeggli 7 Zynga 8 K. Chittimaneni 9 Google 10 September 19, 2012 12 Neighbor Discovery Enhancement for DOS mititgation 13 draft-gashinsky-6man-v6nd-enhance-01 15 Abstract 17 In IPv4, subnets are generally small, made just large enough to cover 18 the actual number of machines on the subnet. In contrast, the 19 default IPv6 subnet size is a /64, a number so large it covers 20 trillions of addresses, the overwhelming number of which will be 21 unassigned. Consequently, simplistic implementations of Neighbor 22 Discovery can be vulnerable to denial of service attacks whereby they 23 attempt to perform address resolution for large numbers of unassigned 24 addresses. Such denial of attacks can be launched intentionally (by 25 an attacker), or result from legitimate operational tools that scan 26 networks for inventory and other purposes. As a result of these 27 vulnerabilities, new devices may not be able to "join" a network, it 28 may be impossible to establish new IPv6 flows, and existing IPv6 29 transported flows may be interrupted. 31 This document describes a modification to the [RFC4861] neighbor 32 discovery protocol aimed at improving the resilience of the neighbor 33 discovery process. We call this process Gratuitous neighbor 34 discovery and it derives inspiration in part from analogous IPv4 35 gratuitous ARP implementation. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 23, 2013. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5. Neighbor Discovery Overview . . . . . . . . . . . . . . . . . . 7 77 6. NDP Protocol Gratuitous NA . . . . . . . . . . . . . . . . . . 7 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 This document describes modifications to the IPv6 Neighbor Discovery 89 protocol [RFC4861] in order to reduce exposure to vulnerabilities 90 when a network is scanned, either by an intruder, as part of a 91 deliberate DOS attempt, or through the use of scanning tools that 92 perform network inventory, security audits, etc. (e.g., "nmap"). In 93 some cases, DOS-like conditions can also be induced by legitimate 94 traffic in heavy traffic networks such as campuses or datacenters. 96 1.1. Applicability 98 This document is primarily intended for implementors of [RFC4861]. 100 2. The Problem 102 In IPv4, subnets are generally small, made just large enough to cover 103 the actual number of machines on the subnet. For example, an IPv4 104 /20 contains only 4096 address. In contrast, the default IPv6 subnet 105 size is a /64, a number so large it covers literally billions of 106 billions of addresses, the overwhelming number of which will be 107 unassigned. Consequently, simplistic implementations of Neighbor 108 Discovery can be vulnerable to denial of service attacks whereby they 109 perform address resolution for large numbers of unassigned addresses. 110 Such denial of attacks can be launched intentionally (by an 111 attacker), or result from legitimate operational tools that scan 112 networks for inventory and other purposes. As a result of these 113 vulnerabilities, new devices may not be able to "join" a network, it 114 may be impossible to establish new IPv6 flows, and existing IPv6 115 transport flows may be interrupted. 117 Network scans attempt to find and probe devices on a network. 118 Typically, scans are performed on a range of target addresses, or all 119 the addresses on a particular subnet. When such probes are directed 120 via a router, and the target addresses are on a directly attached 121 network, the router will to attempt to perform address resolution on 122 a large number of destinations (i.e., some fraction of the 2^64 123 addresses on the subnet). The process of testing for the 124 (non)existence of neighbors can induce a denial of service condition, 125 where the number of Neighbor Discovery requests overwhelms the 126 implementation's capacity to process them, exhausts available memory, 127 replaces existing in-use mappings with incomplete entries that will 128 never be completed, etc. The result can be network disruption, where 129 existing traffic may be impacted, and devices that join the net find 130 that address resolutions fails. 132 In some network environments, legitimate Neighbor Discovery traffic 133 from a large number of connected hosts could induce a DoS condition 134 even without the use of any scanning tools. For e.g., Consider a 135 campus network with a pair of core routers that aggregate traffic 136 from a few thousand wifi clients. In this scenario, high volume of 137 regular ND traffic from clients can easily overwhelm the routers such 138 that they are no longer able to process regular traffic anymore. 140 In order to alleviate risk associated with this DOS threat, some 141 router implementations have taken steps to rate-limit the processing 142 rate of Neighbor Solicitations (NS). While these mitigations do 143 help, they do not fully address the issue and may introduce their own 144 set of potential liabilities to the neighbor discovery process. 146 This document is a companion to two additional documents. The first 147 document was Operational Neighbor Discovery Problems [RFC6583] which 148 addressed the problem in detail and described operational and 149 implementation mitigation within the framework of the Existing 150 protocol. The second related document Neighbor Unreachability 151 Detection is too impatient [1] proposes to alter the Neighbor 152 unreachability Detection by relaxing rules in an attempt to keep 153 devices in the cache. 155 In this document we propose alterations that allow the update or 156 installation of neighbor entries without the instigation of a full 157 [RFC4861] neighbor solicitation. 159 3. Terminology 161 Address Resolution Address resolution is the process through which a 162 node determines the link-layer address of a neighbor given only 163 its IP address. In IPv6, address resolution is performed as part 164 of Neighbor Discovery [RFC4861], p60 166 Forwarding Plane That part of a router responsible for forwarding 167 packets. In higher-end routers, the forwarding plane is typically 168 implemented in specialized hardware optimized for performance. 169 Forwarding steps include determining the correct outgoing 170 interface for a packet, decrementing its Time To Live (TTL), 171 verifying and updating the checksum, placing the correct link- 172 layer header on the packet, and forwarding it. 174 Control Plane That part of the router implementation that maintains 175 the data structures that determine where packets should be 176 forwarded. The control plane is typically implemented as a 177 "slower" software process running on a general purpose processor 178 and is responsible for such functions as the routing protocols, 179 performing management and resolving the correct link-layer address 180 for adjacent neighbors. The control plane "controls" the 181 forwarding plane by programming it with the information needed for 182 packet forwarding. 184 Neighbor Cache As described in [RFC4861], the data structure that 185 holds the cache of (amongst other things) IP address to link-layer 186 address mappings for connected nodes. The forwarding plane 187 accesses the Neighbor Cache on every forwarded packet. Thus it is 188 usually implemented in an ASIC . 190 Neighbor Discovery Process The Neighbor Discovery Process (NDP) is 191 that part of the control plane that implements the Neighbor 192 Discovery protocol. NDP is responsible for performing address 193 resolution and maintaining the Neighbor Cache. When forwarding 194 packets, the forwarding plane accesses entries within the Neighbor 195 Cache. Whenever the forwarding plane processes a packet for which 196 the corresponding Neighbor Cache Entry is missing or incomplete, 197 it notifies NDP to take appropriate action (typically via a shared 198 queue). NDP picks up requests from the shared queue and performs 199 any necessary actions. In many implementations it is also 200 responsible for responding to router solicitation messages, 201 Neighbor Unreachability Detection (NUD), etc. 203 4. Background 205 Modern router architectures separate the forwarding of packets 206 (forwarding plane) from the decisions needed to decide where the 207 packets should go (control plane). In order to deal with the high 208 number of packets per second the forwarding plane is generally 209 implemented in hardware and is highly optimized for the task of 210 forwarding packets. In contrast, the NDP control plane is mostly 211 implemented in software processes running on a general purpose 212 processor. 214 When a router needs to forward an IP packet, the forwarding plane 215 logic performs the longest match lookup to determine where to send 216 the packet and what outgoing interface to use. To deliver the packet 217 to an adjacent node, It encapsulates the packet in a link-layer frame 218 (which contains a header with the link-layer destination address). 219 The forwarding plane logic checks the Neighbor Cache to see if it 220 already has a suitable link-layer destination, and if not, places the 221 request for the required information into a queue, and signals the 222 control plane (i.e., NDP) that it needs the link-layer address 223 resolved. 225 In order to protect NDP specifically and the control plane generally 226 from being overwhelmed with these requests, appropriate steps must be 227 taken. For example, the size and rate of the queue might be limited. 228 NDP running in the control plane of the router dequeues requests and 229 performs the address resolution function (by performing a neighbor 230 solicitation and listening for a neighbor advertisement). This 231 process is usually also responsible for other activities needed to 232 maintain link-layer information, such as Neighbor Unreachability 233 Detection (NUD). 235 An attacker sending the appropriate packets to addresses on a given 236 subnet can cause the router to queue attempts to resolve so many 237 addresses that it crowds out attempts to resolve "legitimate" 238 addresses (and in many cases becomes unable to perform maintenance of 239 existing entries in the neighbor cache, and unable to answer Neighbor 240 Solicitiation). This condition can result the inability to resolve 241 new neighbors and loss of reachability to neighbors with existing ND- 242 Cache entries. During testing it was concluded that 4 simultaneous 243 nmap sessions from a low-end computer was sufficient to make a 244 router's neighbor discovery process unhappy and therefore forwarding 245 unusable. 247 This behavior has been observed across multiple platforms and 248 implementations. 250 5. Neighbor Discovery Overview 252 When a packet arrives at (or is generated by) a router for a 253 destination on an attached link, the router needs to determine the 254 correct link-layer address to send the packet to. The router checks 255 the Neighbor Cache for an existing Neighbor Cache Entry for the 256 neighbor, and if none exists, invokes the address resolution portions 257 of the IPv6 Neighbor Discovery [RFC4861] protocol to determine the 258 link-layer address. 260 RFC4861 Section 5.2 (Conceptual Sending Algorithm) outlines how this 261 process works. A very high level summary is that the device creates 262 a new Neighbor Cache Entry for the neighbor, sets the state to 263 INCOMPLETE, queues the packet and initiates the actual address 264 resolution process. The device then sends out one or more Neighbor 265 Solicitations, and when it receives a corresponding Neighbor 266 Advertisement, completes the Neighbor Cache Entry and sends the 267 queued packet. 269 6. NDP Protocol Gratuitous NA 271 RFC 4861, section 7.2.5 and 7.2.6 [RFC4861] requires that unsolicited 272 neighbor advertisements result in the receiver setting it's neighbor 273 cache entry to STALE, kicking off the resolution of the neighbor 274 using neighbor solicitation. If the link layer address in an 275 unsolicited neighbor advertisement matches that of the existing ND 276 cache entry, routers SHOULD retain the existing entry updating it's 277 status with regards to LRU retention policy. 279 Hosts MAY be configured to send unsolicited Neighbor advertisement at 280 a rate set at the discretion of the operators. The rate SHOULD be 281 appropriate to the sizing of ND cache parameters and the host count 282 on the subnet. An unsolicited NA rate parameter MUST NOT be enabled 283 by default. The unsolicited rate interval as interpreted by hosts 284 must jitter the value for the interval between transmissions. Hosts 285 receiving a neighbor solicitation requests from a router following 286 each of three subsequent gratuitous NA intervals MUST revert to RFC 287 4861 behavior. 289 Implementation of new behavior for unsolicited neighbor advertisement 290 would make it possible under appropriate circumstances to greatly 291 reduce the dependence on the neighbor solicitation process for 292 retaining existing ND cache entries. 294 This may impact the detection of one-way reachability. 296 7. IANA Considerations 298 No IANA resources or consideration are requested in this draft. 300 8. Security Considerations 302 This technique has potential impact on neighbor detection and in 303 particular the discovery of unidirectional forwarding problems. 305 9. Acknowledgements 307 The authors would like to thank Ron Bonica, Troy Bonin, John Jason 308 Brzozowski, Randy Bush, Vint Cerf, Jason Fesler Erik Kline, Jared 309 Mauch, Chris Morrow and Suran De Silva. Special thanks to Thomas 310 Narten for detailed review and (even more so) for providing text! 312 Apologies for anyone we may have missed; it was not intentional. 314 10. References 315 10.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 321 System (DNS)", RFC 4398, March 2006. 323 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 324 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 325 September 2007. 327 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 328 Address Autoconfiguration", RFC 4862, September 2007. 330 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 331 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 332 Router Links", RFC 6164, April 2011. 334 10.2. Informative References 336 [I-D.ietf-6man-impatient-nud] 337 Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 338 Detection is too impatient", 339 draft-ietf-6man-impatient-nud-02 (work in progress), 340 July 2012. 342 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 343 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 344 January 2006. 346 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 347 Neighbor Discovery Problems", RFC 6583, March 2012. 349 URIs 351 [1] 353 Authors' Addresses 355 Warren Kumari 356 Google 358 Email: warren@kumari.net 359 Igor 360 Yahoo! 361 45 W 18th St 362 New York, NY 363 USA 365 Email: igor@yahoo-inc.com 367 Joel 368 Zynga 369 111 Evelyn 370 Sunnyvale, CA 371 USA 373 Email: jjaeggli@zynga.com 375 Kiran 376 Google 377 1600 Amphitheater Pkwy 378 Mountain View, CA 379 USA 381 Email: kk@google.com