idnits 2.17.1 draft-gashinsky-v6nd-enhance-00.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 (June 29, 2011) is 4678 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC4398' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC4255' is defined on line 594, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-nordmark-6man-impatient-nud-00 Summary: 1 error (**), 0 flaws (~~), 6 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: December 31, 2011 Yahoo! 6 J. Jaeggli 7 Zynga 8 June 29, 2011 10 Operational Neighbor Discovery Problems and Enhancements. 11 draft-gashinsky-v6nd-enhance-00 13 Abstract 15 In IPv4, subnets are generally small, made just large enough to cover 16 the actual number of machines on the subnet. In contrast, the 17 default IPv6 subnet size is a /64, a number so large it covers 18 trillions of addresses, the overwhelming number of which will be 19 unassigned. Consequently, simplistic implementations of Neighbor 20 Discovery can be vulnerable to denial of service attacks whereby they 21 attempt to perform address resolution for large numbers of unassigned 22 addresses. Such denial of attacks can be launched intentionally (by 23 an attacker), or result from legitimate operational tools that scan 24 networks for inventory and other purposes. As a result of these 25 vulnerabilities, new devices may not be able to "join" a network, it 26 may be impossible to establish new IPv6 flows, and existing ipv6 27 transported flows may be interrupted. 29 This document describes the problem in detail and suggests possible 30 implementation improvements as well as operational mitigation 31 techniques that can in some cases to protect against such attacks. 32 It also discusses possible modifications to the traditional [RFC4861] 33 neighbor discovery protocol itself. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on December 31, 2011. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 70 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Neighbor Discovery Overview . . . . . . . . . . . . . . . . . 7 74 6. Operational Mitigation Options . . . . . . . . . . . . . . . . 7 75 6.1. Filtering of unused address space. . . . . . . . . . . . . 8 76 6.2. Appropriate Subnet Sizing. . . . . . . . . . . . . . . . . 8 77 6.3. Routing Mitigation. . . . . . . . . . . . . . . . . . . . 8 78 6.4. Tuning of the NDP Queue Rate Limit. . . . . . . . . . . . 9 79 7. Recommendations for Implementors. . . . . . . . . . . . . . . 9 80 7.1. Priortize NDP Activities . . . . . . . . . . . . . . . . . 10 81 7.2. Queue Tuning. . . . . . . . . . . . . . . . . . . . . . . 11 82 7.3. NDP Protocol Gratuitous NA . . . . . . . . . . . . . . . . 11 83 7.4. ND cache priming and refresh . . . . . . . . . . . . . . . 12 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Appendix A. Text goes here. . . . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 This document describes implementation issues with IPv6's Neighbor 96 Discovery protocol that can result in vulnerabilities when a network 97 is scanned, either by an intruder or through the use of scanning 98 tools that peform network inventory, security audits, etc. (e.g., 99 "nmap"). 101 This document describes the problem in detail and suggests possible 102 implementation improvements as well as operational mitigation 103 techniques that can in some cases to protect against such attacks. 104 It also discusses possible modifications to the traditional [RFC4861] 105 neighbor discovery protocol itself. 107 The RFC series documents generally describe on-the-wire behavior of 108 protocols, that is, "what" is to be done by a protocol, but not 109 exactly "how" it is to be implemented. The exact details of how best 110 to implement a protocol will depend on the overall hardware and 111 software architecture of a particular device. The actual "how" 112 decisions are (correctly) left in the hands of implementers, so long 113 as implementations produce proper on-the-wire behavior. 115 While reading this document, it is important to keep in mind that 116 discussions of how things have been implemented beyond basic 117 compliance with the specification is not in the scope of the neighbor 118 discovery RFCs. 120 1.1. Applicability 122 This document is primarily intended for operators of IPV6 networks 123 and implementors of [RFC4861]. The Document provides some 124 operational consideration as well as recommendations to increase the 125 resilience of the Neighbor Discovery protocol. 127 2. The Problem 129 In IPv4, subnets are generally small, made just large enough to cover 130 the actual number of machines on the subnet. For example, an IPv4 131 /20 contains only 4096 address. In contrast, the default IPv6 subnet 132 size is a /64, a number so large it covers literally billions of 133 billions of addresses, the overwhelming number of which will be 134 unassigned. Consequently, simplistic implementations of Neighbor 135 Discovery can be vulnerable to denial of service attacks whereby they 136 perform address resolution for large numbers of unassigned addresses. 137 Such denial of attacks can be launched intentionally (by an 138 attacker), or result from legitimate operational tools that scan 139 networks for inventory and other purposes. As a result of these 140 vulnerabilities, new devices may not be able to "join" a network, it 141 may be impossible to establish new IPv6 flows, and existing ipv6 142 transport flows may be interrupted. 144 Network scans attempt to find and probe devices on a network. 145 Typically, scans are performed on a range of target addresses, or all 146 the addresses on a particular subnet. When such probes are directed 147 via a router, and the target addresses are on a directly attached 148 network, the router will to attempt to perform address resolution on 149 a large number of destinations (i.e., some fraction of the 2^64 150 addresses on the subnet). The process of testing for the 151 (non)existance of neighbors can induce a denial of service condition, 152 where the number of Neighbor Discovery requests overwhelms the 153 implementation's capacity to process them, exhausts available memory, 154 replaces existing in-use mappings with incomplete entries that will 155 never be completed, etc. The result can be network disruption, where 156 existing traffic may be impacted, and devices that join the net find 157 that address resolutions fails. 159 In order to alleviate risk associated with this DOS threat, some 160 router implementations have taken steps to rate-limit the processing 161 rate of Neighbor Solicitations (NS). While these mitigations do 162 help, they do not fully address the issue and may introduce their own 163 set of potential liabilities to the neighbor discovery process. 165 3. Terminology 167 Address Resolution Address resolution is the process through which a 168 node determines the link-layer address of a neighbor given only 169 its IP address. In IPv6, address resolution is performed as part 170 of Neighbor Discovery [RFC4861], p60 172 Forwarding Plane That part of a router responsible for forwarding 173 packets. In higher-end routers, the forwarding plane is typically 174 implemented in specialized hardware optimized for performance. 175 Forwarding steps include determining the correct outgoing 176 interface for a packet, decrementing its Time To Live (TTL), 177 verifying and updating the checksum, placing the correct link- 178 layer header on the packet, and forwarding it. 180 Control Plane That part of the router implementation that maintains 181 the data structures that determine where packets should be 182 forwarded. The control plane is typically implemented as a 183 "slower" software process running on a general purpose processor 184 and is responsible for such functions as the routing protocols, 185 performing management and resolving the correct link-layer address 186 for adjacent neighbors. The control plane "controls" the 187 forwarding plane by programming it with the information needed for 188 packet forwarding. 190 Neighbor Cache As described in [RFC4861], the data structure that 191 holds the cache of (amongst other things) IP address to link-layer 192 address mappings for connected nodes. The forwarding plane 193 accesses the Neighbor Cache on every forwarded packet. Thus it is 194 usually implemented in an ASIC . 196 Neighbor Discovery Process The Neighbor Discovery Process (NDP) is 197 that part of the control plane that implements the Neighbor 198 Discovery protocol. NDP is responsible for performing address 199 resolution and maintaining the Neighbor Cache. When forwarding 200 packets, the forwarding plane accesses entries within the Neighbor 201 Cache. Whenever the forwarding plane processes a packet for which 202 the corresponding Neighbor Cache Entry is missing or incomplete, 203 it notifies NDP to take appropriate action (typically via a shared 204 queue). NDP picks up requests from the shared queue and performs 205 any necessary actions. In many implementations it is also 206 responsible for responding to router solicitation messages, 207 Neighbor Unreachability Detection (NUD), etc. 209 4. Background 211 Modern router architectures separate the forwarding of packets 212 (forwarding plane) from the decisions needed to decide where the 213 packets should go (control plane). In order to deal with the high 214 number of packets per second the forwarding plane is generally 215 implemented in hardware and is highly optimized for the task of 216 forwarding packets. In contrast, the NDP control plane is mostly 217 implemented in software processes running on a general purpose 218 processor. 220 When a router needs to forward an IP packet, the forwarding plane 221 logic performs the longest match lookup to determine where to send 222 the packet and what outgoing interface to use. To deliver the packet 223 to an adjacent node, It encapsulates the packet in a link-layer frame 224 (which contains a header with the link-layer destination address). 225 The forwarding plane logic checks the Neighbor Cache to see if it 226 already has a suitable link-layer destination, and if not, places the 227 request for the required information into a queue, and signals the 228 control plane (i.e., NDP) that it needs the link-layer address 229 resolved. 231 In order to protect NDP specifically and the control plane generally 232 from being overwhelmed with these requests, appropriate steps must be 233 taken. For example, the size and rate of the queue might be limited. 235 NDP running in the control plane of the router dequeues requests and 236 performs the address resolution function (by performing a neighbor 237 solicitation and listening for a neighbor advertisement). This 238 process is usually also responsible for other activities needed to 239 maintain link-layer information, such as Neighbor Unreachability 240 Detection (NUD). 242 An attacker sending the appropriate packets to addresses on a given 243 subnet can cause the router to queue attempts to resolve so many 244 addresses that it crowds out attempts to resolve "legitimate" 245 addresses (and in many cases becomes unable to perform maintenance of 246 existing entries in the neighbor cache, and unable to answer Neighbor 247 Solicitiation). This condition can result the inability to resolve 248 new neighbors and loss of reachability to neighbors with existing ND- 249 Cache entries. During testing it was concluded that 4 simultaneous 250 nmap sessions from a low-end computer was sufficient to make a 251 router's neighbor discovery process unhappy and therefore forwarding 252 unusable. 254 This behavior has been observed across multiple platforms and 255 implementations. 257 5. Neighbor Discovery Overview 259 When a packet arrives at (or is generated by) a router for a 260 destination on an attached link, the router needs to determine the 261 correct link-layer address to send the packet to. The router checks 262 the Neighbor Cache for an existing Neighbor Cache Entry for the 263 neighbor, and if none exists, invokes the address resolution portions 264 of the IPv6 Neighbor Discovery [RFC4861] protocol to determine the 265 link-layer address. 267 RFC4861 Section 5.2 (Conceptual Sending Algorithm) outlines how this 268 process works. A very high level summary is that the device creates 269 a new Neighbor Cache Entry for the neighbor, sets the state to 270 INCOMPLETE, queues the packet and initiates the actual address 271 resolution process. The device then sends out one or more Neighbor 272 Solicitiations, and when it receives a correpsonding Neighbor 273 Advertisement, completes the Neighbor Cache Entry and sends the 274 queued packet. 276 6. Operational Mitigation Options 278 This section provides some feasible mitigation options that can be 279 employed today by network operators in order to protect network 280 availability while vendors implement more effective protection 281 measures. It can be stipulated that some of these options are 282 "kludges", and are operationally difficult to manage. They are 283 presented, as they represent options we currently have. It is each 284 operator's responsibility to evaluate and understand the impact of 285 changes to their network due to these measures. 287 6.1. Filtering of unused address space. 289 The DOS condition is induced by making a router try to resolve 290 addresses on the subnet at a high rate. By carefully addressing 291 machines into a small portion of a subnet (such as the lowest 292 numbered addresses), it is possible to filter access to addresses not 293 in that portion. This will prevent the attacker from making the 294 router attempt to resolve unused addresses. For example if there are 295 only 50 hosts connected to an interface, you may be able to filter 296 any address above the first 64 addresses of that subnet by 297 nullrouting the subnet carrying a more specific /122 route. 299 As mentioned at the beginning of this section, it is fully understood 300 that this is ugly (and difficult to manage); but failing other 301 options, it may be a useful technique especially when responding to 302 an attack. 304 This solution requires that the hosts be statically or statefully 305 addressed (as is often done in a datacenter) and may not interact 306 well with networks using [RFC4862] 308 6.2. Appropriate Subnet Sizing. 310 By sizing subnets to reflect the number of addresses actually in use, 311 the problem can be avoided. For example [RFC6164] recommends sizing 312 the subnet for inter-router links to only have 2 addresses. It is 313 worth noting that this practice is common in IPv4 networks, partly to 314 protect against the harmful effects of ARP flooding attacks. 316 6.3. Routing Mitigation. 318 One very effective technique is to route the subnet to a discard 319 interface (most modern router platforms can discard traffic in 320 hardware / the forwarding plane) and then have individual hosts 321 announce routes for their IP addresses into the network (or use some 322 method to inject much more specific addresses into the local routing 323 domain). For example the network 2001:db8:1:2:3::/64 could be routed 324 to a discard interface on "border" routers, and then individual hosts 325 could announce 2001:db8:1:2:3::10/128, 2001:db8:1:2:3::66/128 into 326 the IGP. This is typically done by having the IP address bound to a 327 virtual interface on the host (for example the loopback interface), 328 enabling IP forwarding on the host and having it run a routing 329 daemon. For obvious reasons, host participation in the IGP makes 330 many operators uncomfortable, but can be a very powerful technique if 331 used in a disciplined and controlled manner. 333 6.4. Tuning of the NDP Queue Rate Limit. 335 Many implementations provide a means to control the rate of 336 resolution of unknown addresses. By tuning this rate, it may be 337 possibly to amerlorate the isse, although, as with most tuning knobs 338 (especially those that deal with rate limiting), you may be 339 "completing the attack". By excissivly lowing this rate you may 340 negatively impact how long the device takes to learn new addresses 341 under normal conditions (for example, after clearing the neighbor 342 cache or when the router first boots) and, under attack conditions 343 you may be unable to resolve "legitimate" addresses sooner than if 344 you had just the the knob alone. 346 It is worth noting that this technique is only worth investigationg 347 if the device has separate queue for resolution of unknown addresses 348 versus maintaice of existing entries. 350 7. Recommendations for Implementors. 352 The section provides some recommendations to implementors of IPv4 353 Neighbor Discovery. 355 At a high-level, implementors should program defensively. That is, 356 they should assume that intruders will attempt to exploit 357 implementation weaknesses, and should ensure that implementations are 358 robust to various attacks. In the case of Neighbor Discovery, the 359 following general considerations apply: 361 Manage Resources Explicitely - Resources such as processor cycles, 362 memory, etc. are never infinite, yet with IPv6's large subnets it 363 is easy to cause NDP to generate large numbers of address 364 resolution requests for non-existant destinations. 365 Implementations need to limit resources devoted to processing 366 Neighbor Discovery requests in a thoughtful manner. 368 Prioritize - Some NDP requests are more important than others. For 369 example, when resources are limited, responding to Neighbor 370 Solicitations for one's own address is more important than 371 initiating address resolution requests that create new entries. 372 Likewise, performing Neighbor Unreachability Detection, which by 373 definition is only invoked on destinations that are actively being 374 used, is more important than creating new entries for possibly 375 non-existant neighbors. 377 7.1. Priortize NDP Activities 379 Not all Neighbor Discovery activies are equally important. 380 Specifically, requests to perform large numbers of address 381 resolutions on non-existant Neighbor Cache Entries should not come at 382 the expense of servicing requests related to keeping existing, in-use 383 entries properly up-to-date. Thus, implementations should divide 384 work activities into categories having different priorities. The 385 following gives examples of different activities and their importance 386 in rough priority order. 388 1. It is critical to respond to Neighbor Solicitations for one's own 389 address, especially when a router. Whether for address resolution or 390 Neighbor Unreachability Detection, failure to respond to Neighbor 391 Solicitations results in immediate problems. Failure to respond to 392 NS requests that are part of NUD can cause neighbors to delete the 393 NCE for that address, and will result in followup NS messages using 394 multicast. Once an entry has been flushed, existing traffic for 395 destinations using that entry can no longer be forwarded until 396 address resolution completes succesfully. In other words, not 397 responding to NS messages further increases the NDP load, and causes 398 on-going communication to fail. 400 2. It is critical to revalidate one's own existing NCEs in need of 401 refresh. As part of NUD, ND is required to frequently revalidate 402 existing, in-use entries. Failure to do so can result in the entry 403 being discarded. For in-use entries, discarding the entry will 404 almost certainly result in a subsquent request to perform address 405 resolution on the entry, but this time using multicast. As above, 406 once the entry has been flushed, existing traffic for destinations 407 using that entry can no longer be forwarded until address resolution 408 completes succesfully. 410 3. To maintin the stability of the control plane, Neighbor Discovery 411 activity related to traffic sourced by the router (as opposed to 412 traffic being forwarded by the router) should be given high priority. 413 Whenever network problems occur, debugging and making other 414 operational changes requires being able to query and access the 415 router. In addition, routing protocols may begin to react 416 (negatively) to perceived connectivity problems, causing addition 417 undesirable ripple effects. 419 4. Activities related to the sending and recieving of Router 420 Advertisements also impact address resolutions. [XXX say more?] 422 5. Traffic to unknown addresses should be given lowest priority. 423 Indeed, it may be useful to distinguish between "never seen" 424 addresses and those that have been seen before, but that do not have 425 a corresponding NCE. Specifically, the conceptual processing 426 algorithm in IPv6 Neighbor Discovery [RFC4861] calls for deleting 427 NCEs under certain conditions. Rather than delete them completely, 428 however, it might be useful to at least keep track of the fact that 429 an entry at one time existed, in order to prioritize address 430 resolution requests for such neighbors compared with neighbors that 431 have never been seen before. 433 7.2. Queue Tuning. 435 On implementations in which requests to NDP are submitted via a 436 single queue, router vendors SHOULD provide operators with means to 437 control both the rate of link-layer address resolution requests 438 placed into the queue and the size of the queue. This will allow 439 operators to tune Neighbour Discovery for their specific environment. 440 The ability to set or have per interface or subnet queue limits at a 441 rate below that of the global queue limit might limit the damage to 442 the neighbor discovery process to the taret network. 444 Setting those values must be a very careful balancing act - the lower 445 the rate of entry into the queue, the less load there will be on the 446 ND process, however, it also means that it will take the router 447 longer to learn legitimate destinations. In a datacenter with 6,000 448 hosts attached to a single router, setting that value to be under 449 1000 would mean that resolving all of the addresses from an initial 450 state (or something that invalidates the address cache, such as a STP 451 TCN) may take over 6 seconds. Similarly, the lower the size of the 452 queue, the higher the likelihood of an attack being able to knock out 453 legitimate traffic (but less memory utilization on the router). 455 7.3. NDP Protocol Gratuitous NA 457 Per RFC 4861, section 7.2.5 and 7.2.6 [RFC4861] requires that 458 unsolicited neighbor advertisements result in the receiver setting 459 it's neighbor cache entry to STALE, kicking off the resolution of the 460 neighbor using neighbor solicitation. If the link layer address in 461 an unsolicited neighbor advertisement matches that of the existing ND 462 cache entry, routers SHOULD retain the existing entry updating it's 463 status with regards to LRU retention policy. 465 Hosts MAY be configured to send unsolicited Neighbor advertisement at 466 a rate set at the discretion of the operators. The rate SHOULD be 467 appropriate to the sizing of ND cache parameters and the host count 468 on the subnet. An unsolicited NA rate parameter MUST NOT be enabled 469 by default. The unsolicted rate interval as interpreted by hosts 470 must jitter the value for the interval between transmissions. Hosts 471 receiving a neighbor solicitation requests from a router following 472 each of three subsequent gratuitous NA intervals MUST revert to RFC 473 4861 behavior. 475 Implementation of new behavior for unsolicited neighbor advertisement 476 would make it possible under appropriate circumstances to greatly 477 reduce the dependence on the neighbor solicitation process for 478 retaining existing ND cache entries. 480 This may impact the detection of one-way reachability. 482 It is understood that this section may need to be moved into a 483 separate document -- it is (currently) provided here for discussion 484 purposes. 486 7.4. ND cache priming and refresh 488 With all of the above recommendations implemented, it should be 489 possible to survive a "scan attack" with very little impact to the 490 network, however, adding new hosts to the network (and the sending of 491 traffic to them) may still be negatively impacted. Traffic to those 492 new hosts would have to go through the unknown Neighbor Resolution 493 queue, which is where the attack traffic would end up as well. A 494 solution to this would be that any new host that joins the network 495 would "announce" itself, and be added to the cache, therefore not 496 requiring packets destined to it to go through the unknown NDP queue. 497 This could be done by sending a ping packet to the all-routers 498 multicast address, which would then trigger the router's own neighbor 499 resolution process, which should be in a different queue then other 500 packets. 502 All attempts should be made to keep these addresses in cache, since 503 any eviction of legitimate hosts from the cache could potentially 504 place resolutions for them into the same queue as the attack traffic. 505 At present, [RFC4861] states that there should be MAX_UNICAST_SOLICIT 506 (3) attempts, RETRANS_TIMER 1 second apart, so if there is an 507 interruption in the network or control plane processing for longer 508 then 3 seconds during the refresh, the entry would be evicted from 509 the ND Cache. Any network event which takes longer then 3 seconds to 510 converge (UDLD, STP, etc may take 30+ seconds) while under an attack, 511 would result in ND cache eviction. If an entry is evicted during a 512 scan, connectivity could be lost for an extended period of time. 514 NDP refresh timers could be revised as suggested in 515 draft-nordmark-6man-impatient-nud-00 [1] and SHOULD have a 516 configurable value for MAX_UNICAST_SOLICIT and RETRANS_TIMER, and 517 include capabilities for binary/exponential backoff. 519 A suggested algorithm, which retains backward compatiblity with 520 [RFC4861] is: operator configurable values for MAX_UNICAST_SOLICIT, 521 RETRANS_TIMER, and a way to set adaptive back-of multiple, simmilar 522 to ipv4 -- call it BACKOFF_MULTIPLE), so that we could implement: 524 next_retrans = 525 ($BACKOFF_MULTIPLE^$solicit_attempt_num)*$RETRANS_TIMER + jittered 526 value. 528 The recommended behavior is to have 5 attempts, with timing spacing 529 of 0 (initial request), 1 second later, 3 seconds later, then 9, and 530 then 27, which represents: 532 MAX_UNICAST_SOLICIT=5 534 RETRANS_TIMER=1 (default) 536 BACKOFF_MULTIPLE=3 538 If BACKOFF_MULTIPLE=1 (which should be the default value), and 539 MAX_UNICAST_SOLICIT=3, you would get the backwards-compatible RFC 540 behavior, but operators should be able to adjust the values as 541 necessary to insure that they are sufficiently aggressive about 542 retaining ND entries in cache. 544 An Implementation following this algorithm would if the request was 545 not answered at first due for example to a transitory condition, 546 retry immediately, and then back off for progressively longer 547 periods. This would allow for a reasonably fast resolution time when 548 the transitory condition clears. 550 8. IANA Considerations 552 No IANA resources or consideration are requested in this draft. 554 9. Security Considerations 556 This document outlines mitigation options that operators can use to 557 protect themselves from Denial of Service attacks. Implementation 558 advice to router vendors aimed at ameliorating known problems carries 559 the risk of previously unforeseen consequences. It is not believed 560 that these techniques create additional security or DOS exposure 562 10. Acknowledgements 564 The authors would like to thank Ron Bonica, Troy Bonin, John Jason 565 Brzozowski, Randy Bush, Vint Cerf, Jason Fesler Erik Kline, Jared 566 Mauch, Chris Morrow and Suran De Silva. Special thanks to Thomas 567 Narten for detailed review and (even more so) for providing text! 569 Apologies for anyone we may have missed; it was not intentional. 571 11. References 573 11.1. Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 579 System (DNS)", RFC 4398, March 2006. 581 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 582 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 583 September 2007. 585 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 586 Address Autoconfiguration", RFC 4862, September 2007. 588 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 589 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 590 Router Links", RFC 6164, April 2011. 592 11.2. Informative References 594 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 595 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 596 January 2006. 598 URIs 600 [1] 603 Appendix A. Text goes here. 605 TBD 607 Authors' Addresses 609 Warren Kumari 610 Google 612 Email: warren@kumari.net 614 Igor 615 Yahoo! 616 45 W 18th St 617 New York, NY 618 USA 620 Email: igor@yahoo-inc.com 622 Joel 623 Zynga 624 111 Evelyn 625 Sunnyvale, CA 626 USA 628 Email: jjaeggli@zynga.com