idnits 2.17.1 draft-smith-6man-mitigate-nd-cache-dos-slnd-06.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 20, 2013) is 4081 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4862' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 611, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft IMOT 4 Updates: 4861 (if approved) February 20, 2013 5 Intended status: Standards Track 6 Expires: August 24, 2013 8 Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless Neighbor 9 Presence Discovery 10 draft-smith-6man-mitigate-nd-cache-dos-slnd-06 12 Abstract 14 One of the functions of IPv6 Neighbor Discovery is to discover 15 whether a specified neighbor is present. During the neighbor 16 presence discovery process state is created. A node's capacity for 17 this state can be intentionally exhausted to perform a denial of 18 service attack, known as the "Neighbor Discovery DoS Attack". This 19 memo proposes a stateless form of neighbor presence discovery to 20 prevent this Neighbor Discovery DoS Attack. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 24, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. The Best Effort Nature of IPv6 . . . . . . . . . . . . . . . . 4 60 4. Opportunities for Stateless Neighbor Presence Discovery . . . 5 61 4.1. Neighbor Advertisement Validation . . . . . . . . . . . . 5 62 4.2. Optimisation Functions . . . . . . . . . . . . . . . . . . 6 63 5. Stateless Neighbor Presence Discovery . . . . . . . . . . . . 6 64 5.1. SLNPD Variables . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. SLNPD Processing . . . . . . . . . . . . . . . . . . . . . 7 66 5.3. Optional Enhancements . . . . . . . . . . . . . . . . . . 9 67 5.3.1. Selective SLNPD . . . . . . . . . . . . . . . . . . . 9 68 5.3.1.1. Source Address . . . . . . . . . . . . . . . . . . 10 69 5.3.1.2. Ingress Interface . . . . . . . . . . . . . . . . 11 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 8. Change Log [RFC Editor please remove] . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 One of the functions of IPv6 Neighbor Discovery [RFC4861] is to 81 discover whether a specified neighbor is present. Neighbor presence 82 discovery occurs when a packet needs to be sent to a specified 83 neighbor for which presence hasn't previously been determined. 85 During neighbor presence discovery, state is created to support the 86 discovery process. The amount of state created is directly 87 proportional to the number of neighbors being discovered at the time. 88 The total possible state that can be created is limited to the lower 89 of the node's state capacity or the size of the IPv6 address space 90 for use by potential neighbors. 92 To provide operational convenience and simplicity, most IPv6 93 Interface Identifiers are 64 bits in length [RFC4291]. This results 94 in a common IPv6 subnet prefix length of 64 bits, covering 2^64 95 addresses. This large IPv6 subnet address space provides an 96 opportunity for an attacker to exhaust a node's capacity for state 97 created during neighbor presence discovery. The consequences of this 98 state exhaustion attack are likely to be a denial of service. New 99 neighbor presence discovery transactions may fail, despite the 100 neighbor existing, and knowledge of existing neighbors' presence may 101 be discarded. This attack is known as the "Neighbor Discovery DoS 102 Attack" [RFC3756]. 104 This memo proposes a stateless form of neighbor presence discovery to 105 prevent this Neighbor Discovery DoS Attack. It takes advantage of 106 hosts' ability to recover from packet loss in the network, necessary 107 because of IPv6's best effort nature. This method would be used when 108 a node's neighbor presence discovery state capacity reaches a medium 109 to high threshold of use, suggesting a Neighbor Discovery DoS Attack 110 is occurring. 112 This method does not require any changes to neighbors, or changes to 113 Neighbor Solicitation or Neighbor Advertisement messages. An 114 optional enhancement for router implementations is to identify a set 115 of packet sources as trusted not to conduct the DoS attack, and to 116 continue to provide these trusted packet sources with traditional and 117 stateful neighbor presence discovery service. 119 [RFC4861] calls the neighbor presence discovery function "Address 120 Resolution". This name seems somewhat inaccurate, as it suggests 121 that the discovery of the presence of neighbors is only necessary for 122 links with link-layer addresses. Neighbor presence discovery is 123 necessary on all types of links, as functions such as generating 124 ICMPv6 Destination Unreachable, Address Unreachable messages, or 125 Neighbor Unreachability Detection [RFC4861], cannot be performed if 126 the presence of a neighbor is assumed by implication of a prefix 127 length [RFC5942], rather than observed or actively tested. Address 128 resolution, for links that require it, occurs as part of the neighbor 129 presence discovery process. 131 If approved, this memo updates [RFC4861]. 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2. Terminology 141 Neighbor Presence Discovery (NPD): Discovery of the presence of a 142 specified neighbor. For link-layers with addresses, address 143 resolution is performed as part of the presence discovery process. 145 Stateful Neighbor Presence Discovery (SFNPD): Traditional neighbor 146 presence discovery specified in [RFC4861]. This form of Neighbor 147 Presence Discovery creates state for each potential neighbor for 148 which presence is being discovered. 150 Stateless Neighbor Presence Discovery (SLNPD): The form of Neighbor 151 Presence Discovery described in this memo. Per-potential neighbor 152 state is not created during Neighbor Presence Discovery. 154 IGP: Interior Gateway Protocol, such as OSPF [RFC5340]. 156 EGP: Exterior Gateway Protocol, such as BGP [RFC4271]. 158 Node: A device that implements Neighbor Presence Discovery. Both 159 hosts and routers are nodes. 161 3. The Best Effort Nature of IPv6 163 The nature of IPv6 is best effort, meaning that there is a 164 possibility that packets may be lost as they transit the network, and 165 that IPv6 will not make any attempt to recover from packet loss 166 [RFC1958]. 168 If an application requires reliable packet delivery, it will need to 169 utilise locally implemented reliable transport layer protocols such 170 as TCP and SCTP, or implement its own reliability mechanisms. These 171 reliability mechanisms will usually involve packet loss detection and 172 retransmission. Alternatively, the application needs to accept the 173 possibility and consequences of packet loss. 175 4. Opportunities for Stateless Neighbor Presence Discovery 177 During traditional and stateful NPD, state is used to perform the 178 following: 180 o ensure a received Neighbor Advertisement corresponds to a 181 previously sent Neighbor Solicitation, 183 o to retransmit a limited number of Neighbor Solicitations if 184 previous solicitations remain unanswered, 186 o to store a small number of packets that triggered the neighbor 187 presence discovery process, so that they can be sent if the 188 neighbor is present, 190 o to generate ICMP Destination Unreachable, Address Unreachable 191 messages to the NPD trigger packet(s') origin host(s) should the 192 specified neighbor not be present. 194 Stateless NPD sacrifices these functions and the related state when a 195 Neighbor Discovery DoS Attack appears to be occurring. 197 4.1. Neighbor Advertisement Validation 199 The purpose of Neighbor Advertisement validation, during NPD, is to 200 ensure that the receiver of the Neighbor Advertisement has previously 201 been interested in the presence of the neighbor, expressed by sending 202 a Neighbor Solicitation. 204 Stateless NPD abandons the state used to enforce a Neighbor 205 Solicitation/Neighbor Advertisement transaction. It accepts Neighbor 206 Advertisements without being able to ensure that they correspond to a 207 previous Neighbor Advertisement. The received Neighbor Advertisement 208 either updates existing neighbor presence information, or creates new 209 neighbor presence information. 211 Updating nodes' existing neighbor presence information via 212 unsolicited multicast Neighbor Advertisements is already permitted by 213 [RFC4861]. While operating, Stateless NPD in effect allows 214 unsolicited unicast Neighbor Advertisements, as knowledge of sending 215 the previous Neighbor Solicitation is abandoned. 217 By making the NPD process stateless, hosts and routers would be 218 protected against a Neighbor Discovery DoS Attack launched from a 219 host against itself, or launched from a host against a remote subnet 220 on a router. However, while stateless NPD is operating, hosts and 221 routers would now be vulnerable to a DoS attack from their own on- 222 link neighbors, as the neighbors could send many unsolicited unicast 223 Neighbor Advertisements for non-existent neighbors. These Neighbor 224 Advertisements would be accepted without question, and false neighbor 225 presence information would be created. 227 Considering that the set of on-link neighbors will be significantly 228 limited compared to the set of possible off-link attackers (such as 229 those on the wider Internet), may be better known due to geographic 230 proximity or link-layer authorisation, and will have a vested 231 interest in any on-link routers continuing to operate, sacrificing 232 Neighbor Advertisement validation during NPD is a worthwhile 233 compromise when a Neighbor Discovery DoS Attack appears to be 234 occurring. 236 4.2. Optimisation Functions 238 The remaining uses of stateful NPD state are not assured of success. 239 The limited number of Neighbor Solicitation retransmissions may not 240 be enough, causing neighbor discovery to fail even though the target 241 node exists. There may be more packets sent that trigger NPD than 242 are stored for transmission when NPD completes successfully, causing 243 them to be dropped. The ICMPv6 Destination Unreachable message may 244 be dropped on the way back to the traffic originating node, perhaps 245 intentionally by a network located firewall. 247 This means that these functions are useful but not essential 248 optimisations, as they are not reliable. They can be sacrificed if 249 necessary, as the original packet source will retransmit its packets, 250 reinitiating NPD, or accept that packet loss has occurred. This 251 retransmission or acceptance of packet loss provides the opportunity 252 to perform a stateless form of Neighbor Presence Discovery, if there 253 is evidence that a Neighbor Discovery DoS Attack is occurring. 255 5. Stateless Neighbor Presence Discovery 257 5.1. SLNPD Variables 259 To perform stateless NPD, five variables are maintained: 261 SLNPD Flag - This flag indicates whether or not the interface will 262 perform SLNPD if necessary. By default, this flag should be set to 263 on. 265 SLNPD Activate Threshold - This variable specifies the threshold when 266 stateless NPD is activated. The threshold specifies a neighbor cache 267 utilisation level. It is expressed as a percentage, with a default 268 value of 80%. It may either be a per-interface or node global 269 variable depending on whether the neighbor discovery implementation 270 has per-interface neighbor caches or a global neighbor cache used by 271 all interfaces. In the case of per-interface neighbor caches, for 272 convenience, an implementation may maintain a global SLNPD Activate 273 Threshold variable, used when the per-interface SLNPD Activate 274 Threshold value is set to 0. 276 SLNPD Active Flag - This flag indicates whether or not the interface 277 is currently performing SLNPD. It is maintained for each interface 278 on the node. 280 SLNPD Neighbor Advertisement Acceptance Time ("SLNPD NA Accept. 281 Time") - This variable holds the time remaining during which apparent 282 or actual unsolicited unicast Neighbor Advertisements will continue 283 to be accepted, after SLNPD has become inactive. It is measured in 284 milliseconds, and is used to implement a count-down-to-zero timer. 285 It is maintained for each interface on the node. 287 SLNPD Neighbor Solicitation Rate Limit ("SLNPD NS Rate Limit") - This 288 variable specifies a maximum threshold for multicast Neighbor 289 Solicitations when the interface is performing SLNPD, specified in 290 packets per second. It is a per-interface variable, as different 291 interfaces may have different thresholds. The rate value should be 292 an appropriate portion of the multicast packet per second 293 capabilities of the interface link technology, to ensure multicast 294 capacity remains for other uses. A packet per second rate 295 corresponding to 10% of the link's multicast capability would be 296 typical. For convenience, a node may maintain a global SLNPD NS Rate 297 Limit that is used when an interface specific SLNPD NS Rate Limit is 298 set to 0. 300 5.2. SLNPD Processing 302 The stateless NPD process may occur once a node has determined the 303 outgoing interface for a packet, and that the packet's destination is 304 on-link. 306 If the packet's destination address is present in the neighbor cache, 307 and the link-layer address has been resolved (if necessary for the 308 link-layer type), the packet is forwarded out the link-layer 309 interface to its destination. 311 If the packet's destination address is not present in the neighbor 312 cache, and the SLNPD Flag is off, traditional stateful NPD is 313 performed for the packet's destination. 315 If the SLNPD Flag is on, and the SLNPD Active flag is off, 316 traditional stateful NPD is performed. 318 If the SLNPD Flag is on, and the SLNPD Active flag is on, stateless 319 NPD is performed as follows: 321 1. The node determines if sending a multicast Neighbor Solicitation 322 would exceed the SLNPD NS Rate Limit for the outgoing interface. 323 If the SLNPD NS Rate Limit would be exceeded, discard the packet 324 and do not proceed any further. 326 2. A multicast Neighbor Solicitation is sent by the node for the 327 destination address in the packet. The packet is then discarded. 328 (An implementation memory optimisation would be to record the 329 packet destination address and then discard the packet before 330 building and sending the corresponding Neighbor Solicitation). 332 3. As some later point in time, the node is likely to receive a 333 unicast Neighbor Advertisement, for a previously sent Neighbor 334 Solicitation. 336 4. If the SLNPD Active Flag is on, or the SLNPD Active Flag is off 337 and the SLNPD NA Accept. Time is greater than zero, the node 338 either: 340 5. 342 * Updates an existing but incomplete neighbor cache entry, 343 created as part of a previous stateful NPD transaction. 345 * Creates a new entry in its neighbor cache using the 346 information received in the unicast Neighbor Advertisement. 347 Stateless NPD is now complete. 349 6. If the SLNPD Active Flag is off and the SLNPD NA Accept. Time is 350 zero, the node performs traditional stateful NPD processing of 351 the received Neighbor Advertisement. 353 The utilisation of the neighbor cache needs to be measured to 354 determine if it crosses the SLNDP Activate Threshold. If the 355 utilisation increases above the SLNDP Activate Threshold, the SLNPD 356 Active Flag is switched on, and if it decreases below the SLNDP 357 Activate Threshold, the SLNPD Active Flag is switched off. Neighbor 358 cache utilisation should be measured and compared to the SLNDP 359 Activate Threshold when: 361 o entries are added to the neighbor cache, during either stateful or 362 stateless NPD, 364 o entries are removed from the neighbor cache when Neighbor 365 Unreachability Detection discovers the neighbor has become 366 unreachable. 368 When the SLNPD Active Flag is switched from on to off, the SLNPD NA 369 Accept. Time is reset to the value of the node's RETRANS_TIMER value 370 [RFC4861] multiplied by the node's MAX_MULTICAST_SOLICIT value 371 [RFC4861]. A system timer is then started to decrement SLNPD NA 372 Accept. Time down to zero. This timer provides the opportunity for 373 outstanding SLNPD transactions to complete after SLNPD has become 374 inactive. When the SLNPD Active Flag is switched from off to on, if 375 the timer is operating it can be cancelled. 377 5.3. Optional Enhancements 379 5.3.1. Selective SLNPD 381 When a Neighbor Discovery DoS Attack appears to be occurring, it 382 could be useful to continue to provide traditional stateful NPD 383 service to hosts that are considered unlikely to initiate or 384 participate in the DoS attack. These hosts could be considered 385 trusted hosts, while the remaining set of hosts are untrusted. 387 The determination of whether a host is trusted or untrusted would 388 take place when NPD is determined to be necessary, during the 389 stateless NPD process. The determination of trust is made based on 390 attributes of the packets that trigger the NPD process. If none of 391 the packet attributes indicate either a trusted or untrusted host, or 392 the value(s) of the packet attribute(s) cannot be trusted, then the 393 source host is considered untrusted. 395 There are two basic packet attributes that an enhanced implementation 396 should provide mechanisms to use to classify a packet source as 397 trusted or untrusted: 399 o source address 401 o ingress interface 403 An implementation may be able to reuse its existing packet 404 classification mechanisms to determine trust, such as those used to 405 implement network QoS. This would mean that other packet attributes, 406 such as Traffic Class, Flow Label [RFC6437], the CALIPSO option 407 [RFC5570] or MPLS label values [RFC3031], could also be used to 408 determine packet source trustworthiness. 410 5.3.1.1. Source Address 412 The source address of the packet that has triggered the NPD process 413 can be used to determine the trust level of the origin host. The 414 information used to classify the source address can come from two 415 possible sources: 417 o an operator configured prefix list 419 o the network's routing information 421 5.3.1.1.1. Operator Configured Prefix List 423 An operator configured prefix list consists of a static list of 424 prefixes and their lengths, each with a flag indicating whether 425 traffic with source addresses that falls within the specified prefix 426 is from a trusted or untrusted source. 428 How this list is evaluated would be implementation dependent, however 429 it is likely to be either sequential from first to last entry, or 430 using a longest match algorithm. 432 In most cases, this list should have a default entry of the ULA 433 prefix (fc00::/7) [RFC4193], flagged as a trusted source. An 434 implementation must allow this entry to be removed. There may be 435 some cases where even packets with ULA source addresses cannot be 436 trusted; in these cases the prefix list should be empty by default. 437 The likely deployment role for the implementation would be a factor 438 in this decision. 440 5.3.1.1.2. Routing Information 442 The network's routing information can be used to distinguish trusted 443 and untrusted packet sources. An advantage of using routing 444 information for this purpose is that it will typically be dynamically 445 and automatically distributed to all routers within the network, when 446 dynamic routing protocols are used. This avoids changes to the 447 operator configured prefix list on individual routers when trusted 448 prefixes are added or removed from the network. 450 The contents of a stub network's route table is typically all the 451 internal routes for the network, and then a default route used to 452 reach the Internet. The list of internal routes can be used to 453 distinguish between trusted and untrusted sources, with packet 454 sources matching internal routes being trusted, and all other packet 455 sources being untrusted. 457 In more complex routing environments, such as those using one or more 458 IGPs and an EGP such as BGP [RFC4271], there may be other methods 459 available to distinguish between trusted and untrusted sources. For 460 example, routes carried in an IGP could be considered trusted, while 461 routes carried in BGP are untrusted. For a network using BGP to 462 carry all reachability information, except network transit and 463 loopback interface routes, internal routes may be tagged with one or 464 more BGP communities to indicate they are also trusted prefixes. 466 There may be cases where a subset of the internal routes need to be 467 considered untrusted, despite them being propagated internally via a 468 routing protocol. These routes will likely be for links at the edge 469 of the local network, where untrusted hosts can be attached without 470 local network control or authorisation. These routes need to be 471 labelled as untrusted, and that information propagated to all routers 472 within the local network. Route labelling mechanisms such as OSPF's 473 External Route Tag [RFC5340] or a BGP community could be used for 474 this purpose. 476 A default route sourced from a routing protocol should never be used 477 as a trusted packet source route. If a router's operator wishes to 478 trust all packet sources, they should specify the prefix that covers 479 all IPv6 addresses, ::/0, as an operator configured trusted prefix. 480 (The ::/0 prefix is only a default route when used as routing 481 information.) 483 Implementations should provide simple and convenient methods to use 484 the network's routing information to distinguish between trusted and 485 untrusted packet source prefixes. 487 5.3.1.2. Ingress Interface 489 A packet's ingress interface on the router could be used to determine 490 whether stateful or stateless NPD takes place. Interfaces on the 491 router would be labelled as trusted or untrusted. 493 The default trust level for interfaces would be up to the router's 494 implementer. Considerations could be the likely deployment scenario 495 for the router implementation (e.g., residential Internet access, or 496 within an enterprise network), and the type of interface (e.g., an 497 interface type that is usually used to attach the router to the 498 Internet, such as an ADSL interface, would be labelled untrusted). 499 These default interface trust assignments should be easy to change. 501 6. Acknowledgements 503 Oliver Ddin provided review and comments, and suggested the use of 504 ingress interface and other more general packet attributes to 505 determine packet source trust. 507 Ray Hunter provided review and comments, and initiated the discussion 508 that resulted in this memo using the term and more specifically 509 focusing on Neighbor Presence Discovery. 511 Igor Lubashev and Deb Banerjee provided review and comments, and 512 identified a hysteresis issue around the SLNPD Activate Threshold. 514 Review and comments were provided by Matthew Moyle-Croft and Karl 515 Auer. 517 This memo was prepared using the xml2rfc tool. 519 7. Security Considerations 521 This memo proposes a security mitigation method for an off-link 522 sourced Neighbor Discovery DoS Attack. 524 As discussed in Section 4.1, the method proposed creates an 525 opportunity for an on-link sourced Neighbor Discovery DoS Attack, 526 when mitigating the off-link sourced Neighbor Discovery DoS Attack. 527 This is considered to be an acceptable security trade-off. 529 Use of attributes that are carried within a packet to distinguish 530 trusted and untrusted sources in Section 5.3.1 is based on the 531 assumption that the values of these attributes can be trusted, 532 meaning that they have been set by trusted packet sources. If it is 533 possible that these packet attribute values may have been forged, 534 then their possible source should be considered untrusted during the 535 Stateless Neighbor Presence Discovery procedure, if the Selective 536 Stateless NPD enhancement has been implemented. 538 8. Change Log [RFC Editor please remove] 540 draft-smith-6man-mitigate-nd-cache-dos-slnd-00, initial version, 541 2012-09-04 543 draft-smith-6man-mitigate-nd-cache-dos-slnd-01, more clarity, 2012- 544 10-13 546 o more comprehensive introduction (problem definition) text 548 o make it more obvious that hosts don't need to be changed 549 o low-end/embedded hosts can consider all packet sources untrusted 551 o misc. minor text updates 553 draft-smith-6man-mitigate-nd-cache-dos-slnd-05, structural changes, 554 2012-11-08 556 o moved opportunities for SLNPD section to before SLNPD description 558 o spit SLNPD into basic functionality and optional enhancements 560 o use of ingress interface and other more general packet attributes 561 to determine trust 563 draft-smith-6man-mitigate-nd-cache-dos-slnd-06, better problem 564 definition, 2012-02-20 566 o rephrase problem as one of neighbor presence discovery 568 o don't ignore Neighbor Advertisements that may be part of a 569 previous stateful neighbor discovery transaction 571 o use a count down timer to allow outstanding SLNPD transactions to 572 complete 574 o mention issues regarding trusting packet attributes 576 9. References 578 9.1. Normative References 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, March 1997. 583 9.2. Informative References 585 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 586 RFC 1958, June 1996. 588 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 589 Label Switching Architecture", RFC 3031, January 2001. 591 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 592 Discovery (ND) Trust Models and Threats", RFC 3756, 593 May 2004. 595 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 596 Addresses", RFC 4193, October 2005. 598 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 599 Protocol 4 (BGP-4)", RFC 4271, January 2006. 601 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 602 Architecture", RFC 4291, February 2006. 604 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 605 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 606 September 2007. 608 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 609 Address Autoconfiguration", RFC 4862, September 2007. 611 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 612 Extensions for Stateless Address Autoconfiguration in 613 IPv6", RFC 4941, September 2007. 615 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 616 for IPv6", RFC 5340, July 2008. 618 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 619 Architecture Label IPv6 Security Option (CALIPSO)", 620 RFC 5570, July 2009. 622 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 623 Model: The Relationship between Links and Subnet 624 Prefixes", RFC 5942, July 2010. 626 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 627 "IPv6 Flow Label Specification", RFC 6437, November 2011. 629 Author's Address 631 Mark Smith 632 In My Own Time 633 PO BOX 521 634 HEIDELBERG, VIC 3084 635 AU 637 Email: markzzzsmith@yahoo.com.au