idnits 2.17.1 draft-gont-opsec-ipv6-nd-security-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Intended status: Informational R. Bonica 5 Expires: April 25, 2014 Juniper Networks 6 W. Liu 7 Huawei Technologies 8 October 22, 2013 10 Security Assessment of Neighbor Discovery (ND) for IPv6 11 draft-gont-opsec-ipv6-nd-security-02 13 Abstract 15 Neighbor Discovery is one of the core protocols of the IPv6 suite, 16 and provides in IPv6 similar functions to those provided in the IPv4 17 protocol suite by the Address Resolution Protocol (ARP) and the 18 Internet Control Message Protocol (ICMP). Its increased flexibility 19 implies a somewhat increased complexity, which has resulted in a 20 number of bugs and vulnerabilities found in popular implementations. 21 This document provides guidance in the implementation of Neighbor 22 Discovery, and documents issues that have affected popular 23 implementations, in the hopes that the same issues do not repeat in 24 other implementations. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. This document may not be modified, 30 and derivative works of it may not be created, and it may not be 31 published except as an Internet-Draft. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 25, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Neighbor Discovery messages . . . . . . . . . . . . . . . . . 6 65 3.1. Router Solicitation message . . . . . . . . . . . . . . . 6 66 3.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 7 67 3.3. Neighbor Solicitation message . . . . . . . . . . . . . . 11 68 3.4. Neighbor Advertisement message . . . . . . . . . . . . . . 12 69 3.5. Redirect message . . . . . . . . . . . . . . . . . . . . . 15 70 3.6. Neighbor Discovery Options . . . . . . . . . . . . . . . . 18 71 3.6.1. General issues with Neighbor Discovery options . . . . 19 72 3.6.2. Source Link-Layer Address Option . . . . . . . . . . . 20 73 3.6.3. Target Link-Layer Address Option . . . . . . . . . . . 22 74 3.6.4. Prefix Information . . . . . . . . . . . . . . . . . . 23 75 3.6.5. Redirected Header Option . . . . . . . . . . . . . . . 26 76 3.6.6. MTU Option . . . . . . . . . . . . . . . . . . . . . . 27 77 3.6.7. Route Information Option . . . . . . . . . . . . . . . 28 78 3.6.8. Recursive DNS Server Option . . . . . . . . . . . . . 31 79 3.6.9. DNS Search List . . . . . . . . . . . . . . . . . . . 33 80 4. Router and Prefix Discovery . . . . . . . . . . . . . . . . . 34 81 4.1. Router Specification . . . . . . . . . . . . . . . . . . . 34 82 4.2. Host Specification . . . . . . . . . . . . . . . . . . . . 34 83 5. Address Resolution . . . . . . . . . . . . . . . . . . . . . . 36 84 5.1. Interface initialization . . . . . . . . . . . . . . . . . 38 85 5.2. Receipt of Neighbor Solicitation messages . . . . . . . . 39 86 6. Vulnerability analysis . . . . . . . . . . . . . . . . . . . . 40 87 6.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 40 88 6.1.1. Neighbor Cache poisoning . . . . . . . . . . . . . . . 41 89 6.1.2. Tampering with Duplicate Address Detection (DAD) . . . 41 90 6.1.3. Tampering with Neighbor Unreachability Detection 91 (NUD) . . . . . . . . . . . . . . . . . . . . . . . . 42 92 6.1.4. Rogue Router . . . . . . . . . . . . . . . . . . . . . 43 93 6.1.5. Parameter spoofing . . . . . . . . . . . . . . . . . . 43 94 6.1.6. Bogus on-link prefixes . . . . . . . . . . . . . . . . 44 95 6.1.7. Bogus address configuration prefixes . . . . . . . . . 45 96 6.1.8. Disabling routers . . . . . . . . . . . . . . . . . . 45 97 6.1.9. Tampering with 'on-link determination' . . . . . . . . 46 98 6.1.10. Introducing forwarding loops at routers . . . . . . . 48 99 6.1.11. Tampering with a Neighbor Discovery implementation . . 49 100 6.1.12. Tampering with a Neighbor Discovery router 101 implementation from a remote site . . . . . . . . . . 51 102 6.2. Performance degrading . . . . . . . . . . . . . . . . . . 52 103 6.2.1. Parameter spoofing . . . . . . . . . . . . . . . . . . 52 104 6.3. Traffic hijacking . . . . . . . . . . . . . . . . . . . . 52 105 6.3.1. Neighbor Cache poisoning . . . . . . . . . . . . . . . 52 106 6.3.2. Rogue Router . . . . . . . . . . . . . . . . . . . . . 53 107 6.3.3. Bogus on-link prefixes . . . . . . . . . . . . . . . . 53 108 6.3.4. Tampering with 'on-link determination' . . . . . . . . 54 109 6.4. Miscellaneous security issues . . . . . . . . . . . . . . 54 110 6.4.1. Detecting Sniffing Hosts . . . . . . . . . . . . . . . 54 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56 113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 57 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 115 10.1. Normative References . . . . . . . . . . . . . . . . . . . 58 116 10.2. Informative References . . . . . . . . . . . . . . . . . . 59 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 119 1. DISCLAIMER 121 This is WORK IN PROGRESS. Some of the recommendations might possibly 122 change. For instance, some (NOT all) of the proposed "sanity checks" 123 help reduce vulnerability to some attacks at the expense of e.g. 124 reduced responsiveness. Further discussion might find some of such 125 checks to be inadequate or inappropriate. On the other hand, some of 126 mitigations discussed in this document have been incorporated into 127 popular Neighbor Discovery (ND) implementations. 129 2. Introduction 131 Neighbor Discovery is used by nodes on the same link to discover each 132 other's presence, to determine each other's link-layer addresses, to 133 find routers, and to maintain reachability information about the 134 paths to active neighbors [RFC4861]. 136 Neighbor Discovery is specified by [RFC4861]. [RFC3122] specifies 137 extensions to Neighbor Discovery for Inverse Discovery. [RFC4389] 138 specifies Neighbor Discovery proxies. [RFC3756] describes trust 139 models and threats for Neighbor Discovery. [RFC3971] specifies a 140 secure version of Neighbor Discovery named 'SEcure Neighbor Discovery 141 (SEND)'. 143 Neighbor Discovery was originally specified by [RFC2461], which was 144 later obsoleted by [RFC4861]. [RFC4943] clarifies the rationale for 145 the removal of the 'on-link assumption' from [RFC4861]. 147 Section 3 of this document provides an analysis of each of the 148 Neighbor Discovery messages, along with a discussion of the Neighbor 149 Discovery options that have been specified at the time of this 150 writing. Section 4 discusses the security implications of Router and 151 Prefix Discovery. Section 5 describes the security implications of 152 Address Resolution. Section 6 contains a vulnerability analysis of 153 Neighbor Discovery. 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 3. Neighbor Discovery messages 161 The following subsections discuss a number of validation checks that 162 should be performed on Neighbor Discovery messages. 164 3.1. Router Solicitation message 166 The following figure illustrates the syntax of Router Solicitation 167 messages: 169 0 1 2 3 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Code | Checksum | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Reserved | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Options ... 177 +-+-+-+-+-+-+-+-+-+-+-+- 179 Figure 1: ICMPv6 Router Solicitation message format 181 As can be inferred from syntax of Router Solicitation messages, any 182 legitimate Router Solicitation message must have a length (as derived 183 from the IPv6 length) that is 8 octets or more. If the packet does 184 not pass this check, it should be silently dropped. 186 The Source Address of an IPv6 packet encapsulating a Router 187 Solicitation message is set to the value of one of the addresses 188 assigned to the sending interface, or to the unspecified address (::) 189 if no address has been assigned to that interface. Nodes should 190 discard Router Solicitation messages that have a multicast address in 191 the Source Address field. 193 The Destination Address of an IPv6 packet encapsulating a Router 194 Solicitation message is set to the all-routers multicast address. 196 A unicast address could possibly be used for the Destination 197 Address for debugging purposes. 199 If a unicast address is used for the Destination Address, the 200 receiving system should ensure that it is a link-local address. If 201 the packet does not pass this check, it should be silently dropped. 203 While this is not explicitly required in [RFC4861] this provides 204 an additional counter-measure (other than the validation of the 205 Hop Limit) for non-local malicious nodes willing to make use of 206 Router Solicitation messages for reconnaissance purposes. 208 As of this writing, the following options are valid in a Router 209 Solicitation message: 211 o Source link-layer address 213 Any other options should be silently ignored. 215 If a 'source link-layer address' option is included, the following 216 sanity checks should be performed: 218 o The Source Address of the packet must not the unspecified address 219 (::) or the "loopback" addresses (::1) 221 o The advertised link-layer address must not a broadcast or 222 multicast address 224 3.2. Router Advertisement 226 The following figure illustrates the syntax of Router Advertisement 227 messages. 229 0 1 2 3 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Code | Checksum | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Reachable Time | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Retrans Timer | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Options ... 241 +-+-+-+-+-+-+-+-+-+-+-+- 243 Figure 2: ICMPv6 Router Advertisement message format 245 The Source Address of an IPv6 packet encapsulating a Router 246 Advertisement message is set to a link-local address assigned to the 247 interface from which the message is sent. Nodes should discard 248 Router Advertisements whose Source Address is not a link-local 249 address. 251 The Destination Address of an IPv6 packet encapsulating a Router 252 Advertisement message is set to the Source Address of the system that 253 elicited the Router Advertisement message (unless this was the 254 unspecified address), or in the case of unsolicited Router 255 Advertisements, to the all-nodes multicast address. Nodes receiving 256 a Router Advertisement should ensure that if the Destination Address 257 is a unicast address, it is a link-local address. Otherwise, the 258 Router Advertisement message should be silently dropped. 260 While this is not explicitly required in [RFC4861] this provides 261 another mitigation for non-local malicious nodes willing to make 262 use of Router Solicitation messages for reconnaissance purposes. 264 The Cur Hop Limit field specifies the default value that should be 265 placed in the Hop Count field of outgoing IPv6 packets. As stated in 266 [RFC4861] a value of 0 means unspecified (by this router). If the 267 Cur Hop Limit field is larger than 0, nodes should sanitize the 268 received Cur Hop Limit value as follows: 270 SanitizedCH = max(Cur Hop Limit, MIN_HOP_LIMIT) 272 where the sanitized Cur Hop Limit (SanitizedCH) is set to the maximum 273 of the Cur Hop Limit and the variable MIN_HOP_LIMIT. MIN_HOP_LIMIT 274 should default to 64, and should be configurable by the system 275 administrator. 277 If the received Cur Hop Limit were not sanitized, an attacker could 278 perform a Denial-of-Service (DoS) attack against the local network by 279 forging a Router Advertisement message that includes a very small Cur 280 Hop Limit value. As a result, nodes honouring the Router 281 Advertisement would set the Hop Limit of outgoing packets to such 282 small value, and as a result those packets would be dropped by some 283 intervening router. 285 For example, if an attacker were to forge a Router Advertisement that 286 contains a Cur Hop Limit of 1, the victim nodes could communicate 287 only with nodes on the same network link, as their packets would be 288 dropped by the first-hop router. 290 XXXX The Prf field is specified in [RFC4191] and is used to specify a 291 'preference' value for the router sending the Router Advertisement. 293 The Router Lifetime field is a 16-bit unsigned integer that specifies 294 the lifetime associated with the default router in units of seconds. 295 A Router Lifetime of 0 indicates that the router is not a default 296 router and must not appear in the default router list. The sending 297 rules in Section 6 of [RFC4861] limit the Router Lifetime to 9000 298 seconds. However, nodes are expected to handle any value. 300 An attacker could exploit the Router Lifetime field to perform DoS 301 attacks or performance-degrading attacks. For example, an 302 attacker could forge Router Advertisement messages that include a 303 very small Router Lifetime. This would have a two-fold effect on 304 the network. Firstly, once the advertised router expires as a 305 'default' router, the corresponding nodes might face a Denial of 306 Service, as a result of having no default routers. Secondly, a 307 small Router Lifetime value could lead to increased traffic in the 308 network, and increased processing time in the affected nodes (as a 309 result of the additional Router Solicitation/Advertisement 310 exchanges needed to re-configure the routing table of each node). 312 If the Router Lifetime is different from 0, it should be sanitized as 313 follows: 315 SanitizedRL = min( max(Router Lifetime, MIN_ROUTER_LIFETIME), 316 MAX_ROUTER_LIFETIME) 318 where lower and upper limits are enforced on the advertised Router 319 Lifetime. The lower limit is specified by the variable 320 MIN_ROUTER_LIFETIME, and should default to 1800 seconds. The upper 321 limit is specified by MAX_ROUTER_LIFETIME, and should default to 9000 322 seconds. 324 The value '1800 seconds' results from the recommended default value 325 (AdvDefaultLifetime) for setting the Router Lifetime, which instead 326 results from the expression '3 * MaxRtrAdvInterval' (where 327 MaxRtrAdvInterval defaults to 600 seconds). The value '9000 seconds' 328 results from the required upper limit for setting the Router Lifetime 329 field (AdvDefaultLifetime). 331 The Router Lifetime should not be sanitized when it is equal to 0, as 332 a value of 0 indicates that the corresponding router should not be 333 used as a default router (i.e., it is only advertising prefixes). 335 When a router is in the Default routers list, and a Router 336 Advertisement is received with a Router Lifetime of 0, a node might 337 choose to keep the router in the Default routers list (as allowed by 338 the current local Router Lifetime value). This might allow nodes to 339 be resilient to Router Advertisements that incorrectly or maliciously 340 advertise a Router Lifetime of 0, at the expense of loss of 341 responsiveness in scenarios in which a router explicitly advertises 342 it wants to be removed from the Default routers list (such a scenario 343 is described in Section 6.2.5 of [RFC4861]. 345 The Reachable Time field is a 32-bit unsigned integer that specifies 346 the amount of time, in milliseconds, that a node assumes a neighbor 347 is reachable after having received a reachability confirmation. A 348 value of zero means 'unspecified by this router'. If Reachable Time 349 is different from 0, it should be sanitized as follows: 351 SanitizedRT = max( min( Reachable Time, MAX_REACHABLE_TIME), 352 MIN_REACHABLE_TIME) 354 where MAX_REACHABLE_TIME and MIN_REACHABLE_TIME impose upper and 355 lower limits, respectively, to the received Reachable Time value. We 356 propose a MAX_REACHABLE_TIME of 3,600,000 (one hour) and a 357 MIN_REACHABLE_TIME of 20,000. 359 The upper limit of 3,600,000 is specified in Section 6.2.1 of 360 [RFC4861] (AdvReachableTime router variable). The lower limit has 361 been selected such that the minimum local ReachableTime (that would 362 result from MIN_RANDOM_FACTOR * SanitizedRT) is not smaller than 10 363 seconds. 365 The Retrans Timer is a 32-bit unsigned integer that specifies the 366 amount of time, in milliseconds between retransmitted Neighbor 367 Solicitation messages. A value of zero means 'unspecified by this 368 router'. If Retrans Timer is different from 0, it should be 369 sanitized as follows: 371 SanitizedRXT = max( min( Retrans Timer, MAX_RETRANS_TIME), 372 MIN_RETRANS_TIME) 374 We propose a MAX_RETRANS_TIME of 60,000 and a MIN_RETRANS_TIME of 375 1,000. 377 At the time of this writing, the options that may be legitimately 378 included in Router Advertisements are: 380 o Source link-layer address 382 o MTU 384 o Prefix information 386 o Route Information 388 o Recursive DNS Server 390 o DNS Search List 392 Other options should be silently ignored. 394 The Source link-layer address option specifies the link-layer address 395 of the interface from which the Router Advertisement is sent. It is 396 only used on link layers that have addresses. Nodes should ignore 397 the source link-layer address option in Router Advertisements 398 received on link layers that do not have addresses. 400 Section 3.6 of this document discusses the security implications of 401 all the Neighbor Discovery options. 403 3.3. Neighbor Solicitation message 405 The following figure illustrates the format of Neighbor Solicitation 406 messages: 408 0 1 2 3 409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Code | Checksum | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Reserved | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 + + 417 | | 418 + Target Address + 419 | | 420 + + 421 | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Options ... 424 +-+-+-+-+-+-+-+-+-+-+-+- 426 Figure 3: ICMPv6 Neighbor Solicitation message format 428 The Source Address of an IPv6 packet encapsulating a Neighbor 429 Solicitation message is set to an address assigned to the interface 430 from which the message is sent, or to the unspecified address (::). 432 The Destination Address of an IPv6 packet encapsulating a Neighbor 433 Solicitation message is set to the solicited-node multicast address 434 corresponding to the target address, or to the target address. 436 The ICMPv6 packet length (as derived from the IPv6 Payload Length) 437 must be greater than or equal to 24. If the packet does not pass 438 this check, it should be silently dropped. 440 The Target Address is the IPv6 address of the target of the 441 solicitation. The Target Address must pass the following checks: 443 1. It must not be a multicast address (as required in Section 4.3 of 444 [RFC4861]) 446 2. It must not be the unspecified address (::) 448 3. It must not be the loopback address (::1) 450 The Target Address must also meet any of the following criteria: 452 1. It is a valid unicast or anycast address assigned to the 453 receiving interface 455 2. It is a unicast or anycast address for which the node is offering 456 proxy service 458 3. It is a 'tentative' address on which 'Duplicate Address 459 Detection' (DAD) is being performed (in which case the Neighbor 460 Solicitation message should be processed according to [RFC4862]) 462 At the time of this writing, the options that may be legitimately 463 included in Neighbor Solicitations are: 465 o Source link-layer address 467 According to Section 4.3 of [RFC4861], the source link-layer address 468 option must not be included when the Source Address is the 469 unspecified address (::). A node receiving a Neighbor Solicitation 470 that includes a source link-layer address and that has the 471 unspecified address (::) as the Source Address should silently drop 472 the corresponding packet. 474 According to Section 4.3 of [RFC4861], on link layers that have 475 addresses (and provided that the Source Address is not the 476 unspecified address), Neighbor Solicitations sent to multicast 477 addresses must include the source link-layer address option. A node 478 receiving a Neighbor Solicitation sent to a multicast address that 479 does not include a source link-layer option should be silently 480 dropped. 482 3.4. Neighbor Advertisement message 484 A node sends Neighbor Advertisements in response to Neighbor 485 Solicitations and sends unsolicited Neighbor Advertisements in order 486 to (unreliably) propagate new information quickly [RFC4861]. 488 The following figure illustrates the syntax of Neighbor Advertisement 489 messages: 491 0 1 2 3 492 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Code | Checksum | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 |R|S|O| Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | | 499 + + 500 | | 501 + Target Address + 502 | | 503 + + 504 | | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Options ... 507 +-+-+-+-+-+-+-+-+-+-+-+- 509 Figure 4: ICMPv6 Neighbor Advertisement message format 511 The Source Address of an IPv6 packet encapsulating a Neighbor 512 Advertisement message is set to a link-local address assigned to the 513 interface from which the message is sent. Nodes should discard 514 Neighbor Advertisements that do not have a link-local address in the 515 Source Address field. 517 The Destination Address of an IPv6 packet encapsulating a Neighbor 518 Advertisement message is set to the Source Address of the Neighbor 519 Solicitation that elicited the Neighbor Advertisement message 520 (provided the Source Address of the Neighbor Solicitation was a 521 unicast address). If the Source Address of the Neighbor Solicitation 522 was the unspecified address, the Neighbor Advertisement is sent to 523 the all-nodes multicast address. Finally, unsolicited Neighbor 524 Advertisements are sent to the all-nodes multicast address 526 The Hop Limit of an IPv6 packet encapsulating a Neighbor 527 Advertisement message must be set to 255 by the sending node. A node 528 receiving a Neighbor Advertisement message should perform the 529 following check: 531 The ICMPv6 packet length (as derived from the IPv6 Payload Length) 532 must be greater than or equal to 24. If the packet does not pass 533 this check, it should be silently dropped. 535 The R flag is the Router flag, and is used by Neighbor Unreachability 536 Detection (NUD). When set, it indicates that the sender is a router. 537 An attacker could forge a Neighbor Advertisement message with the 538 Router flag cleared to cause the receiving node to remove the 539 impersonated Router from the Default router list. 541 The S bit is the Solicited flag. When set it indicates that the 542 Neighbor Advertisement is sent in response to a Neighbor Solicitation 543 sent from the Destination Address. The S flag is used as 544 reachability confirmation for Network Unreachability Detection (NUD). 545 As stated in Section 4.4 of [RFC4861], it must not be set in 546 multicast advertisements or in unsolicited unicast advertisements. 548 A node that receives a Neighbor Advertisement message that has the 549 S-bit set and was sent to a multicast address should silently discard 550 the received message. Additionally, a node that receives an 551 unsolicited Neighbor Advertisement message (i.e., there was not a 552 pending Neighbor Solicitation for the Target Address) with the S-bit 553 set that was sent to a unicast address should silently drop the 554 received message. 556 The O bit is the Override flag. When set, it indicates that this 557 Neighbor Advertisement should override an existing cache entry and 558 update the cached link-layer address. When the O bit is not set, the 559 advertisement will not update a cached link-layer address, but will 560 update a Neighbor Cache entry that does not include a link-layer 561 address. 563 The O bit should be set in all solicited advertisements, except those 564 for anycast addresses. A node that receives an unsolicited Neighbor 565 Advertisement message with the O bit set should silently drop the 566 received message. However, we note that it is virtually impossible 567 to enforce this requirement for Neighbor Advertisement messages for 568 anycast addresses that have the O bit set, as anycast addresses are 569 syntactically indistinguishable from normal unicast addresses. 571 For solicited Neighbor Advertisements, the Target Address is set to 572 the Target Address of the Neighbor Solicitation message that elicited 573 the advertisement. For unsolicited Neighbor Advertisements, the 574 Target Address is set to the address whose link-layer address has 575 changed. 577 The Target Address must pass the following checks: 579 1. It must not be a multicast address (as required in Section 4.4 of 580 [RFC4861] 582 2. It must not be the unspecified address (::) 584 3. It must not be the loopback address (::1) 586 As of this writing, the following options are allowed in Neighbor 587 Advertisement messages: 589 o Target link-layer address 591 Other options present in a Neighbor Advertisement should be ignored. 593 The target link-layer address specifies the link-layer address of the 594 target of the Neighbor Advertisement. According to Section 4.4 of 595 [RFC4861], this option must be included in Neighbor Advertisements 596 when they are sent in response to neighbor solicitations sent to 597 multicast addresses (provided the link layer has addresses). A node 598 that receives a Neighbor Advertisement message in response to a 599 solicitation sent to a multicast address, without a target link-layer 600 address should silently drop the received message (provided that the 601 corresponding link layer has addresses). 603 Section 3.6.3 contains further validation checks that should be 604 performed on target link-layer address options. 606 3.5. Redirect message 608 Routers send Redirect packets to inform a host of a better first-hop 609 node on the path to a destination, or to inform a host that the 610 destination node is in fact a neighbor (i.e., it is attached to the 611 same link). 613 The following figure illustrates the syntax of the Redirect message: 615 0 1 2 3 616 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type | Code | Checksum | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Reserved | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | | 623 + + 624 | | 625 + Target Address + 626 | | 627 + + 628 | | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | | 631 + + 632 | | 633 + Destination Address + 634 | | 635 + + 636 | | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Options ... 639 +-+-+-+-+-+-+-+-+-+-+-+- 641 Figure 5: ICMPv6 Redirect message format 643 The Source Address of the IPv6 header is set to the link-local 644 address assigned to the interface from which the Redirect message is 645 sent. A node that receives a Redirect message should verify that the 646 Source Address of the IPv6 header is a link-local address. If the 647 packet does not pass this check, the Redirect message should be 648 silently dropped. The Source Address of a Redirect message must 649 correspond to the IPv6 address of the current first-hop router for 650 the specified ICMPv6 Destination Address (i.e., the IPv6 address 651 specified in the Destination Address field of the ICMPv6 Redirect 652 message). If the packet does not pass this check, it should be 653 silently dropped. 655 The Destination Address of the IPv6 header is set to the Source 656 Address of the packet that triggered the Redirect. 658 The Target Address specifies an IPv6 address that is a better first 659 hop to use for the IPv6 address specified in the Destination Address 660 field of the ICMPv6 header. If the Redirect message is meant to 661 indicate that a destination is in fact a neighbor (i.e., it is 662 attached to the same link), the Target Address is set to the same 663 value as the Destination Address field of the ICMPv6 header. 665 When the Redirect indicates a first-hop router, the Target Address 666 must be a link-local address (that of the aforementioned 'better 667 first-hop router'). A node that receives a Redirect message in which 668 the Target Address and the Destination Address are different should 669 verify that the Target Address is a link-local address. If the 670 Redirect message does not pass this check, it should be silently 671 dropped. 673 Additionally, the following checks should be performed on the ICMPv6 674 Target Address and the ICMPv6 Destination Address: 676 1. They must not contain a multicast address 678 2. They must not contain the unspecified address (::) 680 3. They must not contain the loopback address (::1) 682 If a Redirect message does not pass this check, it should be dropped. 684 As of this writing, the following options are legitimate for the 685 Redirect message: 687 o Target link-layer address 689 o Redirected header 691 [RFC4861] specifies that the target-link layer address should be 692 included (if known) in Redirect messages, and that it must be 693 included for NBMA links that rely on the presence of the Target link- 694 layer address option to determine the link-layer address of 695 neighbors. 697 As explained in Section 8.3 of [RFC4861], if a Redirect message 698 contains a Target link-layer address option, the node processing the 699 redirect will create or update the Neighbor Cache entry for the 700 target. As a result, an attacker could exploit ICMPv6 Redirect 701 messages not only to maliciously update the Destination Cache of the 702 victim node, but also (or alternatively) to maliciously update its 703 Neighbor Cache. 705 The Redirected header option allows the sender of the Redirect 706 message to include a portion of the packet that triggered the 707 Redirect message. The Redirected header option is discussed in 708 Section 3.6.5. 710 3.6. Neighbor Discovery Options 712 Neighbor Discovery messages can include a number of options. Such 713 options have the following general syntax: 715 0 1 2 3 716 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Type | Length | ... | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 ~ ... ~ 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Figure 6: Neighbor Discovery option format 725 The Type field is an 8-bit identifier of the type of option. As of 726 this writing, the following options have been specified: 728 +------+---------------------------+----------------------------+ 729 | Type | Meaning | Summary | 730 +------+---------------------------+----------------------------+ 731 | 1 | Source link-layer address | Discussed in Section 3.6.2 | 732 +------+---------------------------+----------------------------+ 733 | 2 | Target link-layer address | Discussed in Section 3.6.3 | 734 +------+---------------------------+----------------------------+ 735 | 3 | Prefix information | Discussed in Section 3.6.4 | 736 +------+---------------------------+----------------------------+ 737 | 4 | Redirected header | Discussed in Section 3.6.5 | 738 +------+---------------------------+----------------------------+ 739 | 5 | MTU | Discussed in Section 3.6.6 | 740 +------+---------------------------+----------------------------+ 741 | 24 | Route Information | Discussed in Section 3.6.7 | 742 +------+---------------------------+----------------------------+ 743 | 25 | Recursive DNS Server | Discussed in Section 3.6.8 | 744 +------+---------------------------+----------------------------+ 745 | 31 | DNS Search List | Discussed in Section 3.6.9 | 746 +------+---------------------------+----------------------------+ 748 Table 1: Neighbor Discovery options 750 The Length field specifies the length of the option in units of 8 751 octets. As stated in 4.6 of [RFC4861] a Length of 0 is invalid. 752 Nodes must silently discard Neighbor Discovery packets that contain 753 an option with a Length of 0. 755 3.6.1. General issues with Neighbor Discovery options 757 The following subsections discuss security issues that apply to all 758 Neighbor Discovery options. 760 The proposed checks should be performed in addition to any option- 761 specific checks proposed in the next sections. 763 Processing requirements 765 Processing of Neighbor Discovery options consumes CPU resources at 766 the processing node. While the Hop Limit check of the IPv6 header 767 encapsulating a Neighbor Discovery message limits potential attackers 768 to those attached to the same link as the target node, there's still 769 the potential of an on-link system overwhelming a node by sending it 770 packets with a surprisingly large number of Neighbor Discovery 771 options. 773 To reduce the impact of these packets on the system performance, a 774 few counter-measures could be implemented: 776 o Rate-limit the number of Neighbor Discovery packets that are 777 processed by the system. 779 o Enforce a limit on the maximum number of options to be accepted in 780 any Neighbor Discovery message. 782 The first check avoids a large number of Neighbor Discovery packets 783 to overwhelm the system in question. The second check avoids packets 784 with multiple Neighbor Discovery options to affect the performance of 785 the system. 787 Most implementations fail to rate-limit ND packets, and hence have 788 been found vulnerable to the aforementioned issue (see e.g. 789 [CVE-2011-2391]). 791 Option Length 793 The Length field specifies the length of the option in units of 8 794 octets. As stated in 4.6 of [RFC4861] a Length of 0 is invalid. 795 Nodes must silently discard Neighbor Discovery packets that contain 796 an option with a Length of 0. This check prevents, among other 797 things, loops in option processing that may arise from incorrect 798 option lengths. 800 Additionally, while the Length byte of a Neighbor Discovery option 801 allows for an option length of up to 2040 octets (255 * 8 octets), 802 there is a limit on legitimate option length imposed by the syntax of 803 the IPv6 header. 805 For all Neighbor Discovery options, the following check should be 806 enforced: 808 option-offset + Length * 8 - MIN_IPV6_HEADER <= Payload Length 810 Where 812 option-offset is the offset of the first byte of the option within 813 the IPv6 packet (with the first octet of the IPv6 header having an 814 'offset' of 0). Length is the Length field of the Neighbor Discovery 815 option being processed. MIN_IPV6_HEADER is the size of the fixed 816 IPv6 header. That is, 40 octets. Payload Length is the header field 817 from the IPv6 header encapsulating the Neighbor Discovery message. 819 If a Neighbor Discovery option does not pass this check, the 820 corresponding Neighbor Discovery message should be silently dropped. 822 The aforementioned check is meant to detect forged option-length 823 values that might make an option illegitimately exceed the actual 824 length of the IPv6 packet encapsulating the Neighbor Discovery 825 message. 827 3.6.2. Source Link-Layer Address Option 829 The Source link-layer address option contains the link-layer address 830 of the sender of the packet. It is used by Neighbor Solicitation, 831 Router Solicitation, and Router Advertisement messages. 833 The following figure illustrates the syntax of the source link-layer 834 address: 836 0 1 2 3 837 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type | Length | Link-Layer Address ... 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Figure 7: ND Source link-layer address option 844 The Type field is set to 1. The Length field specifies the length of 845 the option (including the Type and Length octets) in units of 8 846 octets. A node that receives an ICMPv6 message with this option 847 should verify that the Length field is valid for the underlying link 848 layer. For example, for IEEE 802 addresses the Length field must be 849 1 [RFC2464]. If the packet does not pass this check, it should be 850 silently dropped. 852 The Link-Layer Address field contains the link-layer address. The 853 length, contents, and format of this field varies from one link layer 854 to another, and is specified in specific documents that describes how 855 IPv6 operates over different link layers. 857 A number of validation checks should be performed on the Link-Layer 858 Address. In the case of IEEE 802 addresses, it should not contain a 859 broadcast or multicast address. If the option does not pass this 860 check, the Neighbor Discovery message carrying the option should be 861 discarded. 863 Additionally, nodes should not allow the source link-layer address to 864 contain one of the receiving node's link-layer addresses. If the 865 option does not pass this check, the Neighbor Discovery message 866 carrying the option should be discarded. 868 The source link-layer address option could be exploited for the 869 purpose of 'Neighbor Cache poisoning', that is, to cause traffic 870 meant for a specific IPv6 address to be illegitimately directed to 871 the node whose link-layer address is specified by the Link-Layer 872 Address field. 874 This is similar to the ARP cache poisoning attacks in IPv4. 876 A possible counter-measure for Neighbor Cache poisoning attacks would 877 be to override the link-layer address stored in the Neighbor Cache 878 only after Neighbor Unreachability Detection (NUD) finds the neighbor 879 to be unreachable and the corresponding entry is removed. This is 880 clearly a trade-off between responsiveness and resiliency. 882 In some network scenarios it may be possible and desirable to 883 configure static Neighbor Cache entries, such that Neighbor Discovery 884 need not be performed for the corresponding IPv6 addresses. 886 Some implementations have been found to inadvertently override static 887 entries when they receive source link-layer address options or target 888 link-layer address options in Neighbor Discovery messages 889 [Hogg-Vyncke] [Lecigne-Neville-Neil]. 891 If source link-layer address options were allowed to contain 892 broadcast (e.g., the IEEE 802 'ff:ff:ff:ff:ff:ff' address) or 893 multicast (e.g., the IEEE 802 '33:33:00:00:00:01' address) addresses, 894 traffic directed to the corresponding IPv6 address would be sent to 895 the broadcast or multicast address specified in the source link-layer 896 option. This could have multiple implications: 898 It would have a negative impact on the performance of the nodes 899 attached to the network and on the network itself, as packets sent to 900 these addresses would need to be delivered to multiple nodes (and 901 processed by them) unnecessarily. 903 An attacker could capture network traffic sent to the corresponding 904 IPv6 address, as the corresponding packets would be delivered to all 905 (in the case of broadcast) or multiple (in the case of multicast) 906 nodes. 908 Packets could result in forwarding loops at routers, as a router 909 forwarding a packet to the corresponding address would receive itself 910 a copy of the forwarded packet, thus resulting in a forwarding loop. 911 The loop would end only when the Hop Limit is eventually decremented 912 to 0. If multiple routers are present on the same link, the problem 913 is further exacerbated. Section 6.1.10 of this document contains 914 further analysis of this vulnerability. 916 [Lecigne-Neville-Neil] reports that at least some versions of FreeBSD 917 are vulnerable to these issues. 919 3.6.3. Target Link-Layer Address Option 921 The Target link-layer address option contains the link-layer address 922 of the Target of the packet. It is used by Neighbor Advertisement 923 and Redirect messages. 925 The following figure illustrates the syntax of the Target link-layer 926 address: 928 0 1 2 3 929 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Type | Length | Link-Layer Address ... 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Figure 8: ND Target link-layer address option format 936 The Type field is set to 2. The Length field specifies the length of 937 the option (including the Type and Length octets) in units of 8 938 octets. A node that receives an ICMPv6 message with this option 939 should verify that the Length field is valid for the underlying link- 940 layer. For example, for IEEE 802 addresses the Length field must be 941 1 [RFC2464]. If the packet does not pass this check, it should be 942 silently dropped. 944 The Link-Layer Address field contains the link-layer address. The 945 length, contents, and format of this field varies from one link layer 946 to another, and is specified in specific documents that describes how 947 IPv6 operates over different link layers. 949 The target link-layer address has the same security implications as 950 the source link-layer address. Therefore, the same considerations 951 apply, and the same validation checks should be performed as for the 952 source link-layer address (see Section 3.6.2). 954 3.6.4. Prefix Information 956 The Prefix Information option is used by routers to provide hosts 957 with on-link prefixes and prefixes for Address Auto-configuration. 958 It may only appear in Router Advertisement messages and should be 959 silently ignored in any other messages [RFC4861]. 961 The following figure illustrates the syntax of the Prefix Information 962 option: 964 0 1 2 3 965 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Type | Length | Prefix Length |L|A|R|Reserved1| 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Valid Lifetime | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Preferred Lifetime | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Reserved2 | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | | 976 + + 977 | | 978 + Prefix + 979 | | 980 + + 981 | | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Figure 9: ND Prefix Information option format 986 The Type field is set to 3. The Length field is set to 4 by the 987 sender. A node processing a Prefix Information option should verify 988 that the Length field is 4. If the option does not pass this check, 989 the option should be ignored. 991 The Prefix Length is an 8-bit unsigned integer that specifies the 992 prefix length, that is, the number of leading bits in the Prefix 993 field that are valid. 995 The following sanity check should be applied on the Prefix Length 996 field: 998 Prefix Length >= 32 1000 If the Prefix Length field does not pass this checks, the Prefix 1001 Information option should be discarded. 1003 The L bit is a 1-bit flag that, when set, states that the prefix can 1004 be used for on-link determination. The A bit is a 1-bit autonomous 1005 address-configuration flag that indicates whether this prefix can be 1006 used for autonomous address configuration. The R flag is specified 1007 by [RFC6275], and indicates that the Prefix field contains a complete 1008 IPv6 address assigned to the sending router. The Reserved1 field is 1009 a 6-bit unused field that is set to zero by the sender and must be 1010 ignored by the receiver. 1012 The Valid Lifetime field is a 32-bit unsigned integer that specifies 1013 the amount of time (in seconds) this prefix can be used for on-link 1014 determination (with a value of 0xffffffff representing 'infinity'). 1015 We recommend hosts to sanitize the Valid Lifetime as follows: 1017 SanitizedVL = max(Valid Lifetime, MIN_VALID_LIFETIME) 1019 Where SanitizedVL is the sanitized 'Valid Lifetime', and 1020 MIN_VALID_LIFETIME is set to 1800 (seconds). 1022 The value of 1800 seconds for MIN_VALID_LIFETIME has been selected to 1023 coincide with the lower limit enforced on the Router Lifetime 1024 (MIN_ROUTER_LIFETIME). 1026 The Preferred Lifetime is a 32-bit unsigned integer that specifies 1027 the length of time (in seconds) that addresses generated from this 1028 prefix via stateless address auto-configuration (SLAAC) should remain 1029 'preferred' (with a value of 0xffffffff representing 'infinity'). 1031 As noted in [RFC4861] the Preferred Lifetime must be smaller than or 1032 equal to the Valid Lifetime to avoid preferring addresses that are no 1033 longer valid. Therefore, a node processing a Prefix Information 1034 option should perform the following check: 1036 Preferred Lifetime <= Valid Lifetime 1038 If the option does not pass this check, it should be silently 1039 ignored. 1041 The Reserved2 is a 32-bit unused field that is set to zero by the 1042 sender and must be ignored by the receiver. 1044 The Prefix field contains an IPv6 address or a prefix of an IPv6 1045 address. 1047 The Prefix Length contains the number of leading bits in the prefix 1048 that are to be considered valid. The remaining bits in the Prefix 1049 field are set to zero by the sender and must be ignored by the 1050 receiver. 1052 As stated in Section 4.6.2 of [RFC4861], routers should not send a 1053 Prefix Information option for the link-local prefix. Therefore, a 1054 node should verify that the Prefix does not contain the link-local 1055 prefix. If the option does not pass this check, it should be 1056 silently dropped. 1058 Additionally, a node should verify that the Prefix does not contain a 1059 multicast IPv6 prefix. If the option does not pass this check, it 1060 should be silently dropped. 1062 An attacker could exploit the Prefix information option to perform a 1063 Denial-of-Service attack, by sending a large number of Router 1064 Advertisements with the Prefix Information options that have the A 1065 bit set, therefore advising the receiving systems to configure an 1066 IPv6 address with each of these prefixes. If an implementation does 1067 not enforce a limit on the number of addresses they configure in 1068 response to Router Advertisements, the aforementioned attack might 1069 result in buffer overflows or kernel memory exhaustion. 1071 [CVE-2010-4669] is one vulnerability report about the 1072 aforementioned issue. 1074 We recommend hosts to default to a maximum number of configured 1075 addresses (for each interface) of 16. 1077 This limits is already being enforced by a number of implementations, 1078 such as OpenBSD 4.2. 1080 On the other hand, Windows XP SP2 and FreeBSD 9.0 fail to enforce 1081 limits on the maximum number of configured addresses, and therefore 1082 are vulnerable to a Denial of Service attack. 1084 Even if hosts do enforce a limit on the number of IPv6 addresses 1085 configured, an attacker might try to cause victim hosts to ignore 1086 legitimate prefixes previously advertised for address configuration 1087 by legitimate routers. Hereby we recommend hosts to not discard 1088 previously configured addresses if new prefixes for address auto- 1089 configuration are advertised and the limit for the maximum number of 1090 configured addresses (per interface) has been reached. When such 1091 limit is hit, the newly advertised prefixes for address auto- 1092 configuration should be ignored. 1094 Section 3.6.4 describes how an attacker could exploit the Prefix 1095 Information option for the purpose of traffic hijacking. 1097 3.6.5. Redirected Header Option 1099 The Redirected Header option is used in Redirect messages to convey 1100 all or part of the packet that is being redirected. It must be 1101 silently ignored for all other messages. 1103 The following figure illustrates the syntax of the Redirected Header 1104 option: 1106 0 1 2 3 1107 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Type | Length | Reserved | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Reserved | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | | 1114 ~ IP header + data ~ 1115 | | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 Figure 10: ND Redirected Header option format 1120 The Type field is 4. The Length field specifies the option size 1121 (including the Type and Length fields) in units of 8 octets. 1122 Assuming the Redirected Header option will contain at least the 1123 mandatory fields of the option (8 bytes), the fixed IPv6 header (40 1124 bytes), and the first 8 bytes of the transport protocol header, the 1125 following validation check should be performed: 1127 Length >= 7 1129 If the option does not pass this check, the corresponding Redirect 1130 Message should be silently ignored. 1132 As the option is meant to contain as much of the Redirected packet 1133 without exceeding the minimum IPv6 MTU, and the minimum IPv6 MTU is 1134 1280 octets, this is a sensible requirement to enforce. 1136 3.6.6. MTU Option 1138 The MTU option is used in Router Advertisement messages to ensure 1139 that all nodes on a link use the same MTU value in those scenarios in 1140 which heterogeneous technologies are bridged together. This option 1141 must be silently ignored for other Neighbor Discovery messages. 1143 The following figure illustrates the syntax of the MTU option: 1145 0 1 2 3 1146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Type | Length | Reserved | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | MTU | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 Figure 11: ND MTU option format 1155 The Type field identifies the kind of option and is set to 5. This 1156 option has a fixed Length that is 1. Therefore, the following sanity 1157 check should be performed: 1159 Length == 1 1161 If the option does not pass this check it, should be ignored. 1163 The Reserved field is a 16-bit unused field that is set to 0 by the 1164 sender and should be ignored by the receiver. 1166 The MTU field is a 32-bit unsigned integer that specifies the MTU 1167 value that should be used for this link. [RFC2460] specifies that 1168 the minimum IPv6 MTU is 1280 octets. Therefore, a node processing a 1169 MTU option should perform the following check: 1171 MTU >= MINIMUM_IPV6_MTU 1173 where MINIMUM_IPV6_MTU is a variable that should be set to 1280. 1175 If the option does not pass this check, it should be silently 1176 ignored. 1178 It has been reported that some link layers do not support a minimum 1179 MTU of 1280 bytes. Therefore, implementations should provide the 1180 means to change the default value of the MINIMUM_IPV6_MTU variable. 1182 Additionally, the advertised MTU should not exceed the maximum MTU 1183 specified in the link-type-specific document (e.g., [RFC2464] for 1184 Ethernet networks). Therefore, a node processing a MTU option should 1185 perform the following check: 1187 MTU <= MAX_LINK_MTU 1189 where MAX_LINK_MTU is a variable that should be set according to the 1190 maximum link MTU specified in the link-type-specific document (e.g., 1191 [RFC2464] for Ethernet). 1193 If the option does not pass this check, it should be silently 1194 ignored. 1196 The MTU option could be potentially exploited by an attacker to 1197 perform a Denial-of-Service (DoS) or a performance-degrading attack 1198 against the systems in a local network. In order to perform this 1199 attack, an attacker would forge a Router Advertisement that includes 1200 an MTU option with a very small (possibly zero) value. The impact of 1201 this attack would be the same as the 'Blind performance-degrading 1202 attack' described in Section 15.7 of [CPNI-TCP]. 1204 3.6.7. Route Information Option 1206 The Route Information option is used to convey more-specific routes 1207 in Router Advertisement messages. The following figure illustrates 1208 the syntax of the Router Information option: 1210 0 1 2 3 1211 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Route Lifetime | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Prefix (Variable Length) | 1218 . . 1219 . . 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 Figure 12: ND Route Information option format 1224 The Type field identifies the type of option and is set to 24. The 1225 Length field contains the length of the option (including the Type 1226 and Length fields) in units of 8 octets. The following sanity checks 1227 should be performed on these Length field: 1229 (Length >=1) && (Length <=3) 1231 If the option does not pass this check, it should be ignored. 1233 An option Length of 1 octet allows the specification of prefixes with 1234 a length of 0 (i.e., /0), while an option Length of 3 allows the 1235 specification of prefixes of up to 128 bits (i.e., /128). 1237 The Prefix Length field indicates the number of leading bits in the 1238 Prefix field that are valid. The Length field and the Prefix Length 1239 field are closely related, as the Length field constrains the 1240 possible values of the Prefix Length field. 1242 The following sanity check should be enforced on the Prefix Length 1243 field: 1245 Prefix Length <= (Length - 1) * 64 1247 If the option does not pass this check, it should be ignored. 1249 Both of the Rsvd fields are set to zero by the sender of the message, 1250 and should be ignored by the receiver. The Prf field specifies the 1251 'Preference' of this route. As specified by RFC 4191, if the Prf 1252 field contains the value of '10' ('Reserved'), the option should be 1253 ignored. 1255 The Route Lifetime field specifies the length of time, in seconds, 1256 that the prefix is valid for route determination. While not required 1257 by RFC 4191, we recommend hosts to perform the following sanity check 1258 on the Route Lifetime field: 1260 SanitizedRL = min( max(Route Lifetime, MIN_ROUTE_LIFETIME), 1261 MAX_ROUTE_LIFETIME) 1263 Where MIN_ROUTE_LIFETIME is set to 1800 seconds and 1264 MAX_ROUTE_LIFETIME is set to 9000 seconds. 1266 These values have been selected according to the upper and lower 1267 limits described in Section 3.2 ('Router Advertisement') of this 1268 document for the Router Lifetime field of Router Advertisements. 1270 The Prefix field contains the actual IPv6 prefix that, together with 1271 the Prefix Length field, identifies the route. A number of sanity 1272 checks should be enforced on the Prefix field. For example, the 1273 Prefix should neither contain a link-local unicast prefix (e.g., 1274 fe80::/10, fe80::/64, etc.) nor a link-local multicast prefix (e.g., 1275 ff02::0/64). 1277 The Route information option has a number of security implications. 1278 Firstly, an attacker could forge Router Advertisements with a higher 1279 'preference' value (Prf), thus overriding the existing default 1280 routers at the attacked system. Secondly, an attacker could exploit 1281 this option to implant more specific routes to a victim prefix at the 1282 attacked system, thus overriding the existing routes for that victim 1283 prefix. Thirdly, an attacker could cause an existing route to a 1284 victim prefix to be removed from the routing table of the attacked 1285 host, by forging a Route Information option that contains a Route 1286 Lifetime of 0 (or some other small value). Fourthly, if an 1287 implementation does not enforce limits on the size of the Destination 1288 Cache, an attacker could possibly exhaust the kernel memory or CPU 1289 cycles of that system by forging a large number of Route Information 1290 options (possibly in many different Router Advertisements), such that 1291 the attacked system consumes its kernel memory and/or its CPU time to 1292 install those routes (see e.g. [CVE-2012-notyet]). 1294 A general mitigation for the security implications of Router 1295 Advertisements that can be applied when the protocols are deployed is 1296 to restrict which ports of a managed switch can send Router 1297 Advertisement messages. That is, Router Advertisements received on 1298 all other ports of the switch would be discarded. This mechanism is 1299 commonly-known as Router Advertisement Guard (RA-Guard) [RFC6104] 1300 [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. 1302 We recommend hosts to not simply discard a default router entry when 1303 a Router Preference with a higher Prf value is received. In 1304 particular, default routers that are known to be working should not 1305 be discarded when such Router Advertisements are received. 1307 This means that the higher-priority router would override the 1308 existing default router, but the latter would still be kept in the 1309 "default routers list", such that if the newly-learned router is 1310 found to be non-working, the existing (lower-priority) router 1311 could still be employed). 1313 We recommend hosts to enforce a lower limit Prefix Length in the 1314 Route Information options. This would prevent an attacker from 1315 overriding the default routers by including, e.g., one Route 1316 Information option for the prefix ::/1 and one Route Information 1317 option for the prefix 8000::/1. We recommend hosts to enforce a 1318 minimum Prefix Length of 32. Hosts may also enforce an upper limit 1319 on the Prefix Length, such that an attacker cannot easily redirect 1320 traffic to specific site. A possible upper limit for the Prefix 1321 Length would be 64. As discussed earlier in this Section, the Route 1322 Lifetime value should be sanitized, and a route entry should not 1323 simply be discarded when a Route Information option with a Route 1324 Lifetime of 0 is received. 1326 Finally, hosts should enforce a limit on the maximum number of 1327 entries in the Destination Cache. 1329 3.6.8. Recursive DNS Server Option 1331 The Recursive DNS Server (RDNSS) option provides a mechanism for 1332 routers to advertise the IPv6 addresses of one or more Recursive DNS 1333 Servers. This option is specified in [RFC6106]. The following 1334 figure illustrates the syntax of the RDNSS options: 1336 0 1 2 3 1337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Type | Length | Reserved | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Lifetime | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | | 1344 : Addresses of IPv6 Recursive DNS Servers : 1345 | | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 Figure 13: ND Recursive DNS Server option format 1350 The Type field identifies must be 25. The Length field specifies the 1351 length of the option (including the Type and Length fields) in units 1352 of 8 octets. The following sanity checks should be performed on the 1353 Length field: 1355 Length >= 3 1357 If the option does not pass this check, it should be ignored. 1359 This sanity check requires a RDNSS option to contain the IPv6 address 1360 of at least one Recursive DNS Server. 1362 Additionally, the following sanity check should be performed: 1364 (Length -1) % 2 == 0 1366 If the option does not pass this check, it should be silently 1367 ignored. 1369 As an IPv6 address consists of 16 bytes, each IPv6 address that is 1370 included in the option should increment the minimum option length by 1371 2. 1373 The Reserved field is set to zero by the sender, and must be ignored 1374 by the receiver. The Lifetime field specifies the maximum time in 1375 seconds that a node may use the IPv6 addresses included in the option 1376 for name resolution, with a value of 0 indicating that they can no 1377 longer be used. As specified in [RFC6106], the following sanity 1378 checks should be performed on the Lifetime field: 1380 Lifetime >= 1800 1382 Lifetime <= 3600 1384 [RFC6106] specifies these sanity checks as MaxRtrAdvInterval <= 1385 Lifetime <= 2*MaxRtrAdvInterval. 1387 If the Lifetime field does not pass this check, the option should be 1388 ignored. 1390 Failure to enforce a lower limit on the Lifetime value could allow an 1391 attacker to 'disable' a Recursive DNS Server at a target system, by 1392 forging a Router Advertisement with a RDNSS option that includes the 1393 IPv6 address of such DNS Server, and a Lifetime of 0 (or some other 1394 small value). This would cause the receiving system to remove such 1395 RDNSS address from the list of Recursive DNS Servers. However, it 1396 should be noted that this represents a trade-off of responsiveness 1397 vs. resiliency. 1399 Sanity checks should be performed on the IPv6 addresses that are 1400 included in the RDNSS option. For example, nodes should check that 1401 the IPv6 addresses included in the RDNSS option are not multicast 1402 addresses. If any of the addresses in the RDNSS option does not pass 1403 this check, it should be silently dropped. 1405 Nodes should enforce a limit on the number of IPv6 addresses they 1406 include in the local list of Recursive DNS Servers. An arbitrary 1407 limit could be to allow a maximum of 16 IPv6 addresses in the list of 1408 Recursive DNS Servers. 1410 The value 16 is somewhat arbitrary. It has been chosen to be the 1411 same as the limit on the maximum number of default routes that many 1412 systems (such as OpenBSD 4.2) already enforce. 1414 Failure to enforce limits on the maximum number of Recursive DNS 1415 Servers could probably allow an attacker to exhaust the system memory 1416 by crafting multiple Router Advertisements that advertise a large 1417 number of IPv6 addresses in RDNSS options. 1419 It should also be clear that if an attacker is able to advertise a 1420 malicious Recursive DNS Server to victim nodes, he could perform a 1421 variety of attacks against the victim nodes (DoS, Man-in-the-Middle. 1422 Etc.). 1424 3.6.9. DNS Search List 1426 The Recursive DNS Server (RDNSS) option provides a mechanism for 1427 routers to advertise the IPv6 addresses of one or more Recursive DNS 1428 Servers. This option is specified in [RFC6106]. The following 1429 figure illustrates the syntax of the RDNSS options: 1431 0 1 2 3 1432 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | Type | Length | Reserved | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Lifetime | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | | 1439 : Domain Names of DNS Search List : 1440 | | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 Figure 14: V 1445 XXX (PLACEHOLDER): Need to complete the security assessment of this 1446 option. 1448 4. Router and Prefix Discovery 1450 4.1. Router Specification 1452 Section 6.2 of [RFC4861] contains the Router specification for Router 1453 and Prefix Discovery. 1455 Section 6.2.6 ('Processing Router Solicitations') of [RFC4861] states 1456 that if a router receives a Router Solicitation message, and 'the 1457 router already has a Neighbor Cache entry for the solicitation's 1458 sender, the solicitation contains a Source Link-Layer Address option, 1459 and the received link-layer address differs from that already in the 1460 cache, then the link-layer address SHOULD be updated in the 1461 appropriate Neighbor Cache entry'. As a result, an attacker might 1462 forge a Router solicitation message with a forged source link-layer 1463 address, thus causing all traffic meant from the attacked router to 1464 the (forged) Source Address of the Router Advertisement to be sent to 1465 the link-layer address advertised in the forged source link-layer 1466 address option. 1468 Section 6.2.6 of [RFC4861] further states that 'Whether or not a 1469 Source Link-Layer Address option is provided, if a Neighbor Cache 1470 entry for the solicitation's sender exists (or is created) the 1471 entry's IsRouter flag MUST be set to FALSE'. As a result, in a 1472 network scenario in which there are two routers ('A' and 'B') on the 1473 same link, and an attacker is directly attached to that link, an 1474 attacker could send a Router Solicitation to one of the routers 1475 (Router A) forging the Source Address to be that of the other router 1476 (Router B). As a result, the target router (Router A) would set the 1477 IsRouter flag of the Neighbor Cache entry corresponding to the IPv6 1478 address of Router B (the forged Source Address of the Router 1479 Solicitation message) to FALSE, and as a result, Router B would be 1480 eliminated from the Default router list of Router A. 1482 One interesting aspect about this attack is that while some devices 1483 might be filtering e.g. Router Advertisements, they might not be 1484 filtering Router Solicitation messages, and thus this attack might 1485 still be effective. 1487 4.2. Host Specification 1489 Section 6.3.4 of [RFC4861] states that when a Router Advertisement is 1490 received that communicates information for a specific parameter 1491 (e.g., link MTU) that differs from information received in previous 1492 Router Advertisements, the most recently received information is 1493 considered authoritative. 1495 While this requirement guarantees that the relevant information can 1496 be updated in a timely fashion, it also guarantees that an attacker 1497 connected to the local link always has the chance to maliciously 1498 override the values of parameters previously learned from Router 1499 Advertisements. 1501 Section 6.3.4 of [RFC4861] states that 'to limit the storage needed 1502 for the Default Router List, a host MAY choose not to store all of 1503 the router addresses discovered via advertisements'. Here we 1504 strongly advise hosts to enforce a limit on the maximum number of 1505 entries in the Default Router List. A possible (somewhat arbitrary) 1506 limit for the maximum number of entries in the Default Router list 1507 would be 16. 1509 Section 6.3.4 of [RFC4861] states that 'If the received Cur Hop Limit 1510 value is non-zero, the host SHOULD set its CurHopLimit variable to 1511 the received value'. Here we strongly advise that the received Cur 1512 Hop Limit is sanitized as described in Section 3.2 of this document. 1514 Section 6.3.4 of [RFC4861] states that 'The RetransTimer variable 1515 SHOULD be copied from the Retrans Timer field, if the received value 1516 is non-zero'. Here we strongly advise that the received Retrans 1517 Timer is sanitized as described in Section 3.2 of this document. 1519 Honouring very small Retrans Timer values could lead the system to 1520 flood the network with Neighbor Advertisements. 1522 With respect to the processing of received MTU options, Section 6.3.4 1523 of [RFC4861] correctly states that the received option should be 1524 honoured as long as the received value is within the expected limits. 1525 Section 3.6.6 of this document discusses a number of checks that 1526 should be performed on received MTU options. 1528 Section 6.3.4 of [RFC4861] states that 'The only way to cancel a 1529 previous on-link indication is to advertise that prefix with the 1530 L-bit set and the Lifetime set to zero'. This means that if an 1531 attacker forges a Router Advertisement that advertises a 'victim' 1532 prefix as being on-link, such prefix will usually be considered 'on- 1533 link' for the advertised Lifetime period of time ('forever' if 1534 Lifetime was set to 0xffffffff). 1536 5. Address Resolution 1538 In the case of broadcast link-layer technologies, in order for a 1539 system to transfer an IPv6 datagram, it must first map an IPv6 1540 address to the corresponding link-layer address via Neighbor 1541 Solicitation/Advertisement messages. 1543 While this operation is being performed, the packets that require 1544 such a mapping would need to be kept in memory. This may happen both 1545 in the case of hosts and in the case of routers. 1547 The possible implementation approach of keeping those datagrams in 1548 memory while the mapping operation is being performed is mentioned in 1549 Section 5.2 of [RFC4861]. 1551 This situation might be exploited by an attacker to perform a Denial- 1552 of-Service (DoS) attack against an IPv6 router, by sending a large 1553 number of packets to a non-existent node that would supposedly be a 1554 neighbor to the attacked router. While trying to map the 1555 corresponding IPv6 address into a link-layer address, the attacked 1556 router would keep in memory all the packets that would depend on that 1557 address resolution operation in order to be forwarded to the intended 1558 destination. At the point in which the mapping function times out, 1559 the node would typically drop all the packets that were queued 1560 waiting for that address resolution operation to complete. 1562 Depending on the timeout value for the mapping function this 1563 situation might result in the attacked router running out of memory, 1564 with the consequence that incoming legitimate packets would have to 1565 be dropped, or that legitimate packets already stored in the router's 1566 memory buffers might need to be dropped. Both of these situations 1567 would lead either to a complete Denial of Service or to a degradation 1568 of the network service. 1570 A number of countermeasures are warranted for this vulnerability: 1572 Firstly, nodes should enforce a limit on the maximum number of 1573 packets that are queued for the same destination address while the 1574 corresponding address resolution operation is being performed. 1575 Additionally, nodes should enforce a limit on the aggregate number of 1576 packets that are queued waiting for address resolution operations to 1577 complete. 1579 At the point the mapping function times out, all the packets destined 1580 to the address that timed out should be discarded. In addition, a 1581 'negative cache entry' might be kept in the module performing the 1582 matching function, so that for some amount of time the mapping 1583 function would return an error when the IPv6 module requests 1584 resolution of some IPv6 address for which the mapping has recently 1585 failed (i.e., timed out). 1587 A proactive mitigation for this vulnerability would be that when a 1588 packet is received that requires an address resolution operation 1589 before the packet can be forwarded, the packet is dropped and the 1590 router is then engaged in the address resolution operation. 1592 This is a common implementation strategy for IPv4 routers. In IPv4, 1593 it is common that when a packet is received that requires an ARP 1594 request to be performed (before the packet can be forwarded), the 1595 packet is dropped and the router is then engaged in the ARP 1596 procedure. 1598 While similar issues exist in IPv4 networks, this problem is 1599 exacerbated in IPv6, as IPv6 subnets are typically much larger than 1600 their IPv4 counterparts. Therefore, an attacker could send a large 1601 number of packets, each destined to different IPv6 addresses 1602 corresponding to non-existent 'neighbor nodes' of the attacked 1603 router. In the event that the router implementation drops packets 1604 only when the address resolution operation times out, the DoS 1605 condition might persist, whereas it would have probably disappeared 1606 if all the malicious packets had been destined to the same IPv6 1607 address. 1609 That is, if all the attack packets had been destined to the same IPv6 1610 address, the timeout of the address resolution operation for that 1611 IPv6 address could have resulted in all the attack packets to be 1612 dropped. 1614 An attacker could also potentially perform a Denial-of-Service attack 1615 against a router by exhausting the number of entries in the Neighbor 1616 cache and/or the Destination cache. In order to perform this attack, 1617 an attacker would send a large number of packets, each destined to 1618 different IPv6 addresses corresponding to non-existent 'neighbor 1619 nodes' of the attacked router. Each of these attack packets would 1620 trigger an address-resolution operation at the attacked router. If 1621 the target router does not enforce any limits on the maximum number 1622 of entries in the Neighbor cache, this attack could result in a 1623 buffer overflow at the attacked router. On the other hand, if the 1624 router does enforce limits on the maximum number of entries in the 1625 neighbor cache, the packets sent by the attacker could result in the 1626 attacked router hitting the aforementioned limit, probably preventing 1627 legitimate entries to be added to the Neighbor cache, resulting in a 1628 Denial of Service to the corresponding nodes. 1630 This situation has been experienced in production networks probably 1631 as a result of reconnaissance activity by attackers. That is, this 1632 situation could not only indicate a deliberate Denial-of-Service 1633 attack against a router, but could also be side-effect of network 1634 reconnaissance (i.e., 'scanning') activities. 1636 A number of mitigations are warranted for this vulnerability: 1638 o Nodes should enforce a limit on the number of entries in the 1639 Neighbor cache. 1641 o Nodes should implement an algorithm to reclaim Neighbor Cache 1642 entries when the limit on the number of entries is reached. 1644 o Nodes should enforce a limit on the number of entries in the 1645 Neighbor Cache that have a reachability state of 'INCOMPLETE'. 1646 This limit should be much stricter than the general limit on the 1647 number of entries in the Neighbor Cache. 1649 o Nodes should enforce a limit on the number of entries in the 1650 Destination cache. 1652 o Nodes should implement an algorithm to reclaim Destination Cache 1653 entries when the limit on the maximum number of entries is 1654 reached. 1656 Section 5.3 of [RFC4861] states that for the purpose of eliminating 1657 unused entries (i.e., garbage-collection) in the Neighbor cache, any 1658 Least Recently Used (LRU)-based policy that only reclaims entries 1659 that have not been used in some time should be adequate. Such LRU- 1660 based policy should also be enforced to reclaim entries in the 1661 Neighbor cache or the Destination Cache when the limit on the maximum 1662 number of entries is hit for the Neighbor cache or the Destination 1663 cache, respectively. 1665 5.1. Interface initialization 1667 As explained in Section 7.2.1 of [RFC4861], when a multicast-capable 1668 interface is enabled, the node must join the all-nodes multicast 1669 group on that interface, and the solicited-node multicast address 1670 corresponding to each of the addresses assigned to an interface. As 1671 discussed in the same section, nodes join and leave the solicited- 1672 node groups as the assigned addresses change over time. 1674 As the solicited-node multicast address for a number of assigned 1675 addresses might be the same, nodes should ensure that a solicited- 1676 node multicast group is not left until all the addresses 1677 corresponding to that solicited-node group have been removed. 1679 An implementation that incorrectly leaves a solicited-node multicast 1680 group while there are addresses corresponding to that multicast group 1681 still in use might be subject of a Denial-of-Service attack (from a 1682 malicious node attached to the same link as the victim). 1684 In order to perform such an attack, an attacker would first send an 1685 unsolicited Router Advertisement, announcing a prefix such that the 1686 victim node configures an address whose solicited-node multicast 1687 group is the same as some legitimately-configured address. The 1688 advertised prefix would have a Lifetime value that would cause the 1689 address to be removed in the short term. If the Neighbor Discovery 1690 implementation of the victim system does not ensure that a solicited- 1691 node multicast group is left only when the last address corresponding 1692 to that solicited-node multicast group is removed, the victim might 1693 incorrectly leave the aforementioned solicited-node multicast group. 1694 As a result, the victim system would be unable to respond to Neighbor 1695 Solicitation messages for the target address, and therefore the 1696 aforementioned address would become unreachable. 1698 5.2. Receipt of Neighbor Solicitation messages 1700 As stated in Section 7.2.3, if a Neighbor Solicitation is received 1701 and an entry already exists in the Neighbor Cache for the IPv6 Source 1702 Address of the solicitation with a cached link-layer address that is 1703 different from the one in the received Source Link-Layer option, the 1704 cached address should be replaced by the received address (and the 1705 entry's reachability state must be set to STALE). 1707 If an entry does not exist for the corresponding Target Address, a 1708 new entry is added to the Neighbor Cache, and its reachability state 1709 is set to STALE. 1711 While this allows for improved responsiveness in the event the link- 1712 layer address corresponding to an IPv6 address changes, it also means 1713 that an attacker could easily override the mapping from IPv6 address 1714 to link-layer address. 1716 An attacker attached to the same link as the victim system could 1717 craft a Neighbor Solicitation message with a forged IPv6 Source 1718 Address, and send it to the victim system, thus illegitimately 1719 causing the victim to update its Neighbor Cache. The attacker could 1720 then send a Neighbor Advertisement with the Solicited flag set, thus 1721 causing the reachability state of the neighbor cache entry to be set 1722 to REACHABLE. 1724 As a result, the attacker could cause traffic meant from the victim 1725 to the forged IPv6 address to be directed to any local system (i.e., 1726 attached to the same network link). 1728 6. Vulnerability analysis 1730 This section summarizes the security implications that arise from the 1731 Neighbor Discovery mechanisms in IPv6. The following vulnerabilities 1732 have been identified: 1734 o Denial of Service: communication is prevented between legitimate 1735 nodes 1737 o Performance-degrading: the performance of communication between 1738 legitimate nodes is reduced 1740 o Traffic hijacking: traffic is illegitimately redirected to a node 1741 operated by an attacker 1743 [RFC3756] provides a good security assessment of the Neighbor 1744 Discovery mechanisms. The following subs-sections summarize the 1745 results in [RFC3756], and also identify new vulnerabilities and 1746 specific attack vectors not present in that document. 1748 Some of the vulnerabilities discussed in the following sub-sections 1749 involve an attacker sending Router Advertisement messages. [RFC6104] 1750 analyzes the problem of Rogue IPv6 Router Advertisements, and discuss 1751 a number of possible solutions. [RFC6105] discusses a specific 1752 solution to this problem based on layer-2 filtering, known as 'RA- 1753 Guard'. However, as discussed in 1754 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 1755 implementations can be easily circumvented by leveraging IPv6 1756 extension headers. 1758 [SI6-Toolkit] is a complete complete IPv6 toolkit that can be 1759 employed to exploit all the vulnerabilities discussed in the 1760 following subsections. [THC-IPv6] includes 'proof of concept' tools 1761 of some of the vulnerabilities discussed in the following 1762 subsections. [vanHauser2006] is a presentation about this tool set. 1764 [Beck2007b] analyzes the use of Neighbor Discovery for Operating 1765 System detection. However, the results seem to indicate that 1766 Neighbor Discovery is not an attractive means for Operating System 1767 detection when compared to other techniques such as those described 1768 in [CPNI-TCP]. Therefore, the 'information leakage' resulting from 1769 Neighbor Discovery, while possible, is not included in the threat 1770 analysis present in the following subsections. 1772 6.1. Denial of Service 1773 6.1.1. Neighbor Cache poisoning 1775 Router Solicitation, Router Advertisement, Neighbor Solicitation and 1776 Neighbor Advertisement messages can be exploited to maliciously 1777 poison the Neighbor Cache of a victim node such that an IPv6 address 1778 maps into a non-existent link-layer address. As a result, traffic 1779 meant to the victim address would be 'black-holed' as a result of 1780 sending it to a non-existent link-layer address. 1782 In the case of Router Solicitation, Router Advertisement, and 1783 Neighbor Solicitation messages, a source link-layer address would be 1784 employed. In the case of Neighbor Advertisement messages, a target 1785 link-layer address would be used instead. 1787 In order for an attacker to successfully perform this attack, he 1788 would need to be attached to the same network link to which the 1789 target node is attached, or control a node attached to that network 1790 link (e.g., compromise such a node). However, it could be possible 1791 that as a result of tunnelling mechanisms, an attacker could perform 1792 these attacks remotely. 1794 This attack could be mitigated by not overwriting the link-layer 1795 address of an existing Neighbor Cache entry when a source link-layer 1796 address option or a target link-layer address option is received. 1797 The mapping of IPv6 address to link-layer address would be updated 1798 only if Neighbor Unreachability Detection (NUD) first removes the 1799 corresponding Neighbor Cache entry, and then a Neighbor Discovery 1800 message updates the mapping. 1802 Furthermore, some monitoring tools exist that detect some possible 1803 exploitation of Neighbor Discovery and Neighbor Advertisement 1804 messages. NDPMon [NDPMon] is an example of such a monitoring tool 1805 (which is similar to the IPv4 arpwatch tool [arpwatch]). [Beck2007] 1806 is a paper about the aforementioned tool. 1808 6.1.2. Tampering with Duplicate Address Detection (DAD) 1810 The Duplicate Address Detection (DAD) mechanism is used to ensure 1811 that a node does configure for itself an address that is already in 1812 use. 1814 An attacker could simply listen to Neighbor Solicitations sent as 1815 part of the DAD mechanism, and respond with crafted Neighbor 1816 Advertisements, thus causing the victim node to consider the address 1817 to be already in use, and thus preventing it from configuring the 1818 address for future use. 1820 Additionally, an attacker could respond to Neighbor Solicitations 1821 sent as part of the DAD mechanism with a Neighbor Solicitation for 1822 the same IPv6 address. The legitimate node performing DAD would 1823 consider this a collision and would cease to solicit that address 1824 (and possibly select and perform DAD for some alternative address). 1826 In order for an attacker to successfully perform this attack, he 1827 would need to be attached to the same network link on which the 1828 attack is to be launched, or control a node attached to that network 1829 link (e.g., compromise such a node). 1831 Layer-2 switches could filter Neighbor Advertisement messages based 1832 on previous knowledge of the link-layer addresses recently in use at 1833 each port. 1835 6.1.3. Tampering with Neighbor Unreachability Detection (NUD) 1837 The Neighbor Unreachability Detection (NUD) mechanism is used to 1838 detect unreachable neighbors and cause the corresponding entries in 1839 the Neighbor Cache to be eliminated. When an unreachable neighbor is 1840 detected and the corresponding Neighbor Cache entry is removed, a 1841 node has the chance to e.g., perform next-hop determination. 1843 In order for a neighbor to be considered reachable, NUD uses 1844 reachability indications from upper-layer protocols. In the absence 1845 of reachability indications from an upper layer (e.g., from TCP's 1846 Acknowledgements), NUD employs solicited unicast Neighbor 1847 Solicitations to confirm the reachability of a Neighbor. 1849 An attacker could snoop traffic and respond to the solicited Neighbor 1850 Solicitation messages being used for the purpose of NUD, thus 1851 preventing victim nodes from detecting that the impersonated node is 1852 unreachable. As a result, those 'victim' nodes would continue 1853 sending packets to the unreachable node, instead of e.g., performing 1854 first-hop determination to find an alternative working router. 1856 In order for an attacker to successfully perform this attack, he 1857 would need to be attached to the same network link on which the 1858 attack is to be launched, or control a node attached to that network 1859 link (e.g., compromise such a node). 1861 Nodes could require the link-layer source address of solicited 1862 Neighbor Advertisements being employed for NUD to be the same as that 1863 stored in the Neighbor Cache entry for which NUD is being performed. 1864 With this requirement in place, layer-2 switches could filter 1865 Neighbor Advertisement messages according to their source link-layer 1866 address, based on previous knowledge of the link-layer addresses 1867 recently in use at each port. 1869 It should be noted that this recommendation should not be enforced in 1870 more complex networks in which VRRP [RFC5798] or custom redundancy 1871 protocols are employed. 1873 This would mitigate the tampering with NUD that employs Neighbor 1874 Advertisement messages. However, it should be noted that an attacker 1875 might still tamper with NUD by forging upper-layer packets such as 1876 TCP Acknowledgements. 1878 6.1.4. Rogue Router 1880 An attacker could either send unsolicited Router Advertisements 1881 and/or illegitimately respond to Router Solicitations, advertising a 1882 non-existent system as a default router. 1884 As a result, hosts honouring the aforementioned Router Advertisements 1885 would use the advertised rogue router as a default router, and as a 1886 result their packets would be black-holed. 1888 In order for an attacker to successfully perform this attack, he 1889 would need to be attached to the same network link on which the 1890 attack is to be launched, or control a node attached to that network 1891 link (e.g., compromise such a node). As described in [RFC3756], this 1892 vulnerability could be mitigated by preferring existing routers over 1893 new ones. 1895 Additionally, layer-2 switches could possibly allow Router 1896 Advertisements messages to be sent only from specific ports. 1898 [RFC6104] analyzes the problem of Rogue IPv6 Router Advertisements, 1899 and discusses a number of possible solutions. [RFC6105] discusses a 1900 specific solution to this problem based on layer-2 filtering, known 1901 as 'RA-Guard'. However, as discussed in 1902 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 1903 implementations can be easily circumvented by leveraging IPv6 1904 extension headers. [CVE-2011-2395] is a vulnerability advisory about 1905 this issue. 1907 [SI6-Toolkit] is a complete complete IPv6 toolkit that can be 1908 employed to circumvent the aforementioned RA-Guard 1909 implementations. 1911 6.1.5. Parameter spoofing 1913 An attacker could either send unsolicited Router Advertisements 1914 and/or illegitimately respond to Router Solicitations, advertising a 1915 legitimate default router, but malicious network parameters. 1917 For example, an attacker could advertise a very small Cur Hop Limit 1918 value, thus causing packets to be discarded before reaching their 1919 intended destination. 1921 An attacker could also advertise an incorrect link MTU (either very 1922 small or very large) possibly preventing packets from being sent on 1923 the corresponding link and/or causing pathological behaviour at the 1924 victim nodes. 1926 Finally, an attacker could either send unsolicited Router 1927 Advertisements and/or illegitimately respond to Router Solicitations, 1928 sending Router Advertisements with the M and/or the O bits set, thus 1929 possibly causing the victim nodes to engage in managed address 1930 configuration when such service is not present (e.g., there is no 1931 DHCP server) or when the attacker operates a malicious DHCP server. 1933 In the former scenario, address configuration would fail, as a result 1934 of the non-existing DHCP server. In the latter scenario, an attacker 1935 could operate a malicious DHCP server to override IPv6's stateless 1936 configuration. 1938 In order for an attacker to successfully perform this attack, he 1939 would need to be attached to the same network link on which the 1940 attack is to be launched, or control a node attached to that network 1941 link (e.g., compromise such a node). 1943 As with other attacks based on Router Advertisement messages, they 1944 could be mitigated if Layer-2 switches allow Router Advertisements 1945 messages to be sent only from specific ports. 1947 6.1.6. Bogus on-link prefixes 1949 An attacker could either send unsolicited Router Advertisements 1950 and/or illegitimately respond to Router Solicitations, advertising 1951 bogus prefixes for on-link determination. 1953 As a result, nodes belonging to the aforementioned prefixes would be 1954 considered on-link, and packets destined to them would not be relayed 1955 to a first-hop router. As a result, the victim nodes (i.e., those 1956 receiving the crafted Router Advertisements) would perform Neighbor 1957 Discovery for the intended destination, and when ND failed, the 1958 packets would be discarded. 1960 In order for an attacker to successfully perform this attack, he 1961 would need to be attached to the same network-link on which the 1962 attack is to be launched, or control a node attached to that network 1963 link (e.g., compromise such a node). 1965 As mentioned in [RFC3756] host implementations could mitigate the 1966 impact of this attack by requiring the advertised prefixes to be at 1967 least /64s. 1969 This would prevent an attacker from affecting a much larger portion 1970 of the IPv6 address space by e.g. sending a Router Advertisement that 1971 advertises the prefix ::/0 to be 'on-link'. 1973 As with other attacks based on Router Advertisement messages, they 1974 could be mitigated if Layer-2 switches allow Router Advertisements 1975 messages to be sent only from specific ports. 1977 6.1.7. Bogus address configuration prefixes 1979 An attacker could either send unsolicited Router Advertisements 1980 and/or illegitimately respond to Router Solicitations, illegitimately 1981 advertising IPv6 prefixes for stateless address auto-configuration 1982 (SLAAC). This prefixes could either be bogon prefixes or prefixes 1983 owned by a remote site. An attacker could cause victim systems to 1984 configure IPv6 addresses using prefixes that would cause the 1985 resulting traffic to be black-holed. 1987 This would cause the receiving nodes to configure their addresses 1988 with those bogus prefixes, and as a result, the resulting traffic 1989 would possibly be filtered by the network (e.g., if network egress- 1990 filtering is in place). Even if the outgoing packets were not 1991 filtered, these victim systems would not receive the return traffic, 1992 as the return traffic would either be filtered (in the case of bogon 1993 prefixes) or delivered to the legitimate destination (in the case of 1994 prefixes owned by some other party). 1996 In order for an attacker to successfully perform this attack, he 1997 would need to be attached to the same network-link on which the 1998 attack is to be launched, or control a node attached to that network 1999 link (e.g., compromise such a node). 2001 As with other attacks based on Router Advertisement messages, they 2002 could be mitigated if Layer-2 switches allow Router Advertisements 2003 messages to be sent only from specific ports. 2005 6.1.8. Disabling routers 2007 An attacker could send crafted Router Advertisements, Neighbor 2008 Advertisements, or Router Solicitations to cause the receiving nodes 2009 to remove the impersonated router from the router list. 2011 In current implementations, if there are no default routers, a packet 2012 destined to an off-link node will elicit an ICMPv6 Destination 2013 Unreachable error message. In the case of legacy implementations 2014 compliant with [RFC2461], if there are no default routers, the 2015 Destination Address would be assumed to be 'on-link', and the victim 2016 would perform Neighbor Discovery for the destination address in the 2017 hope of delivering the packet on the local link. 2019 In the case of the Router Advertisements vector, an attacker would 2020 send unsolicited Router Advertisements with a Preferred Lifetime 2021 equal to 0 or to some other small value, thus causing the receiving 2022 nodes to remove the impersonated router from the default router list. 2024 Alternatively, an attacker could send forged Neighbor Advertisements 2025 (either solicited or unsolicited) with the Router flag set to 0, thus 2026 causing the impersonated router to be removed from the default router 2027 list. 2029 Receiving nodes would assume the impersonated router has ceased to be 2030 a router and has changed to functioning only as a host. 2032 As a third option, an attacker could send a forged Router 2033 Solicitation message to a router on the local network link, to cause 2034 the victim to remove the impersonated router from the router list. 2035 This attack vector is discussed in more detail in Section 4.1. 2037 In order for an attacker to successfully perform this attack, he 2038 would need to be attached to the same network link on which the 2039 attack is to be launched, or control a node attached to that network 2040 link (e.g., compromise such a node). 2042 Some IPv6 networks employ the 'RA-Guard' mechanism specified in 2043 [RFC6105] as the first line of defence against RA-based attack 2044 vectors. However, However, as discussed in 2045 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 2046 implementations can be easily circumvented by leveraging IPv6 2047 extension headers. [CVE-2011-2395] is a vulnerability advisory about 2048 this issue. 2050 [SI6-Toolkit] is a complete complete IPv6 toolkit that can be 2051 employed to circumvent the aforementioned RA-Guard 2052 implementations. 2054 The rest of the attack vectors discussed in this section could 2055 possibly be mitigated with a more advanced Layer-2 filtering. 2057 6.1.9. Tampering with 'on-link determination' 2059 Section 2.1 of [RFC4861] states that a node considers an address to 2060 be on-link if: 2062 o it is covered by one of the link's prefixes (e.g., as indicated by 2063 the on-link flag in the Prefix Information option), or 2065 o a neighbouring router specifies the address as the target of a 2066 Redirect message, or 2068 o a Neighbor Advertisement message is received for the (target) 2069 address, or 2071 o any Neighbor Discovery message is received from the address. 2073 As a result, some implementations create a Destination Cache entry 2074 for the Source Address of a Neighbor Discovery message (or for the 2075 Target Address of a Neighbor Advertisement message) when such a 2076 message is received, and mark the aforementioned address as 'on- 2077 link'. 2079 This means in all traffic meant to the forged address will be 2080 delivered to the node identified in the corresponding Neighbor Cache 2081 entry (as the node will be considered to be on-link). If the 2082 corresponding Neighbor Cache entry maps the forged address into a 2083 non-existent or malicious node, all traffic can be black-holed, thus 2084 leading to a DoS scenario. 2086 [RFC5942] updates [RFC4861], removing the third and fourth bullets in 2087 the above list. This means that receipt of ND messages must not 2088 result in the Source Address of the ND message or the Target Address 2089 of a Neighbor Advertisement message to be considered on-link (e.g., 2090 by modifying the Prefix List or by marking the corresponding 2091 Destination Cache entry as 'on-link'). 2093 [CVE-2008-2476] and [US-CERT2008] are vulnerability advisories 2094 about this issue. 2096 Some IPv6 networks employ the 'RA-Guard' mechanism specified in 2097 [RFC6105] as the first line of defence against RA-based attack 2098 vectors. However, as discussed in 2099 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 2100 implementations can be easily circumvented by leveraging IPv6 2101 extension headers. [CVE-2011-2395] is a vulnerability advisory about 2102 this issue. 2104 [SI6-Toolkit] is a complete complete IPv6 toolkit that can be 2105 employed to circumvent the aforementioned RA-Guard 2106 implementations. 2108 [I-D.ietf-6man-nd-extension-headers] updates [RFC3971] and [RFC4861], 2109 deprecating the use of fragmentation with Neighbor Discovery, such 2110 that layer-2 filtering and Neighbor Discovery monitoring become 2111 feasible. 2113 6.1.10. Introducing forwarding loops at routers 2115 As discussed in Section 3.6.2 of this document, if broadcast or 2116 multicast addresses were allowed in source link-layer address options 2117 or in target link-layer address options, traffic directed to a victim 2118 IPv6 address would be sent to such broadcast or multicast IPv6 2119 address. 2121 Consider the following network scenario: 2123 +----------+ +--------+ +----------+ 2124 | Router A | | Host C | | Router B | 2125 +----------+ +--------+ +----------+ 2126 || || || 2127 ================================================= 2128 || 2129 || 2130 +----------+ 2131 | Attacker | 2132 +----------+ 2134 Figure 15: Example network scenario for forwarding loop 2136 An attacker could poison the neighbor cache of Router A and the 2137 neighbor cache of Router B, such that the IPv6 address of Host C maps 2138 to the Ethernet broadcast address (ff:ff:ff:ff:ff:ff). Afterwards, 2139 he could send a packet to the Ethernet broadcast address (ff:ff:ff: 2140 ff:ff:ff), with an IPv6 Destination Address equal to the IPv6 address 2141 of Host C. Upon receiving the packet, both Router A and Router C 2142 would decrement the Hop Limit of the packet, and would resend it to 2143 the Ethernet broadcast address. As a result, both Router A and 2144 Router B would now receive two copies of the same packet (one sent by 2145 Router A, and another sent by Router B). This would result in a 2146 'chain reaction' that would only disappear when the Hop Limit of each 2147 of the packets is decremented to 0. The total number of packets, for 2148 a general scenario in which multiple routers are present on the link 2149 and are subject of the aforementioned neighbor cache poisoning 2150 attack, and the attacker sends the initial attack packet with an 2151 arbitrary Hop Limit (possibly 255 to get the maximum amplification 2152 factor) is: 2154 HopLimit-1 2155 --- 2156 \ x 2157 Packets = / Routers 2158 --- 2159 x=0 2161 Figure 16: Maximum amplification factor 2163 This equation does not take into account neither the possible ICMPv6 2164 Redirect messages that each of the Routers could send, nor the 2165 possible ICMPv6 'time exceeded in transit' error messages that each 2166 of the routers could possibly send to the Source Address of the 2167 packet when each of the 'copies' of the original packet is discarded 2168 as a result of their Hop Limit being decremented to 0. 2170 As discussed in Section 3.6.2 of this document, neither broadcast nor 2171 multicast addresses should be allowed in source link-layer address 2172 and target link-layer address options. An additional mitigation 2173 would be for routers to not forward IPv6 packets on the same 2174 interface if the link-layer destination address of the packet was a 2175 broadcast or multicast address. 2177 It is also possible to introduce a forwarding loop at a router by 2178 poisoning its neighbor cache such that a victim IPv6 address 2179 (considered to be on-link) maps to one of the attacked router's link- 2180 layer addresses. An attacker could poison the neighbor cache of the 2181 target router as described, and then send a packet to the attacked 2182 router with the IPv6 Destination Address set to the victim address. 2183 Upon receipt of the packet, the router would decrement the Hop Limit, 2184 and 'forward' the packet to its own link-layer address. This would 2185 result in a loop, with the target router processing the packet 'Hop 2186 Limit' times (where 'Hop Limit' is the value used for the Hop Limit 2187 field of the original packet). 2189 6.1.11. Tampering with a Neighbor Discovery implementation 2191 The Neighbor Discovery specification describes conceptual data 2192 structures such as the Neighbor Cache and the Destination Cache, 2193 which grow as a result of each entry that is created. Additionally, 2194 there are other structures such as the list of configured IPv6 2195 addresses, the list of Recursive DNS Servers, etc., that also grow 2196 for each entry that is created in them. 2198 As discussed throughout Section 5 of this document, an implementation 2199 should enforce limits on the maximum number of entries in these 2200 structures. Failure in enforcing such limits could result in buffer 2201 overflows or memory exhaustion. 2203 FreeBSD 9.0 and NetBSD 5.1 fail to enforce limits on the number of 2204 entries in the IPv6 routing table, on the number of entries in the 2205 Neighbor Cache, on the number of entries in the Default Router 2206 List, and on the number of configured IPv6 addresses. Therefore 2207 they are vulnerable to multiple Denial of Service attacks. 2209 Many versions of Windows that support IPv6 fail to enforce limits 2210 on the number of entries in the IPv6 routing table, on the maximum 2211 number of configured addresses, and on the number of entries in 2212 the Neighbor Cache. Therefore, these structures could be 2213 exploited for performing a Denial of Service attack. [Win-Update] 2214 describes an update has been made available for Windows 7 and 2215 Windows Server 2008 R2 to limit the number of configured addresses 2216 and the number of routing table entries on a per-interface basis. 2218 Linux 2.6.38-10 does enforce a limit on the number of entries in 2219 the Default router list. However, this limit itself could be 2220 leveraged for performing a Denial of Service attack, by causing 2221 the Default router list to become full of malicious/spurious 2222 entries before a legitimate entry can be added. As a result, the 2223 system would be unable to configure a legitimate default router, 2224 even if a legitimate Router Advertisement is received at some 2225 point later. 2227 An attacker attached to the same network link as the target node can 2228 stress most of these data structures by sending a large number of the 2229 appropriate Neighbor Discovery options (e.g., RDNSS or Prefix 2230 Information options in Router Advertisement messages, etc.) as has 2231 been shown by e.g. [CVE-2010-4669]. 2233 Other structures (such as the Neighbor Cache or the Destination 2234 Cache) can be stressed by sending packets with forged addresses to 2235 the target node. For example, an attacker could send any packets 2236 that would elicit a response from the destination system with forged 2237 IPv6 Source Address that is assumed to be 'on-link' by the target 2238 system. In order for the target node to respond to those packets, it 2239 would have to create the necessary entries in the Destination Cache 2240 and in the Neighbor Cache. If the target implementation does not 2241 enforce limits on the maximum number of entries in each of those data 2242 structures, the attack may result in buffer overflows or kernel 2243 system memory exhaustion. 2245 It is interesting to note that this attack vector could also be 2246 exploited by an attacker located in a remote site, unless ingress 2247 and/or egress filtering are in place. 2249 [NISCC2006b] discusses ingress and egress filtering. 2251 6.1.12. Tampering with a Neighbor Discovery router implementation from 2252 a remote site 2254 A remote attacker could potentially perform a Denial-of-Service (DoS) 2255 attack against a router by sending packets to different IPv6 2256 addresses considered on-link at one of the network links to which the 2257 target router is attached. Each of these packets would engage the 2258 target router in neighbor discovery for each of those addresses, 2259 probably preventing the router from performing neighbor discovery for 2260 legitimate packets aimed at existing nodes. 2262 This problem would be exacerbated if an implementation queues in 2263 memory those packets that are destined to an IPv6 address for which 2264 address resolution is being performed. See Section 5 of this 2265 document for a thorough description of this issue. 2267 One important difference between this attack vector and the ones 2268 described in the previous subsections is that in order for an 2269 attacker to successfully perform this attack, he does not need to be 2270 attached to the same network link to which the target router is 2271 attached. 2273 A possible mitigation for this attack would be to enforce a limit on 2274 the maximum number of entries in the Neighbor Cache that are in the 2275 'INCOMPLETE' state. This limit should be stricter than the overall 2276 limit on the maximum number of entries in the Neighbor Cache. 2278 A Neighbor Cache entry is in the 'INCOMPLETE' state if a Neighbor 2279 Advertisement message has never been received for the corresponding 2280 IPv6 address since the entry was created. 2282 It should be noted that this is an implementation issue rather than a 2283 protocol-based vulnerability. However, a number of implementations 2284 have been found to be vulnerable to this attack. 2286 It is also worth noting that this attack does not require an attacker 2287 to forge the IPv6 Source Address of the 'malicious' packets. 2288 Therefore, mechanisms such as 'ingress filtering' do not provide any 2289 mitigation for this attack. 2291 Section 6.1.11 describes another attack vector for stressing the 2292 Neighbor Cache (and the Destination cache) of both host and router 2293 implementations. 2295 6.2. Performance degrading 2297 6.2.1. Parameter spoofing 2299 An attacker could either send unsolicited Router Advertisements 2300 and/or illegitimately respond to Router Solicitations, advertising a 2301 legitimate default router, but malicious network parameters. 2303 An attacker could also advertise a small link MTU causing the victim 2304 nodes to enforce such a small MTU for the corresponding network link. 2305 This would increase the overhead (headers/data ratio), and possibly 2306 result in a packet-rate increase (if the same throughput is to be 2307 maintained). Additionally, this might also require the use of IPv6 2308 fragmentation when data are to be transferred across this network 2309 link. This is a moderate version of the Denial-of-Service (DoS) 2310 attack discussed in Section 6.1.5 of this document. 2312 In order for an attacker to successfully perform this attack, he 2313 would need to be attached to the same network link on which the 2314 attack is to be launched, or control a node attached to that network 2315 link (e.g., compromise such a node). 2317 Some IPv6 networks employ the 'RA-Guard' mechanism specified in 2318 [RFC6105] as the first line of defence against RA-based attack 2319 vectors. However, as discussed in 2320 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 2321 implementations can be easily circumvented by leveraging IPv6 2322 extension headers. [CVE-2011-2395] is a vulnerability advisory about 2323 this issue. 2325 [SI6-Toolkit] is a complete complete IPv6 toolkit that can be 2326 employed to circumvent the aforementioned RA-Guard 2327 implementations. 2329 6.3. Traffic hijacking 2331 6.3.1. Neighbor Cache poisoning 2333 Neighbor Solicitation and Neighbor Advertisement messages can be 2334 exploited to maliciously poison the Neighbor Cache of a target node 2335 such that an IPv6 address maps into the link-layer address of a 2336 malicious node operated by an attacker. As a result, once the 2337 victim's Neighbor Cache is poisoned, the attacker would receive all 2338 traffic aimed at the victim node. 2340 This is similar to the Denial-of-Service (DoS) attack described in 2341 Section 6.1.1 of this document, with the only difference being that 2342 in this case traffic would be directed to a node operated by the 2343 attacker, rather than to a non-existent node. 2345 In order for an attacker to successfully perform this attack, he 2346 would need to be attached to the same network link on which the 2347 attack is to be launched, or control a node attached to that network 2348 link (e.g., compromise such a node). 2350 An attacker could also poison the Neighbor Cache of a target node 2351 mapping a victim IPv6 address to a multicast or broadcast link-layer 2352 address, such that he can receive a copy of those packets sent by the 2353 attacked node to the victim node. This specific attack vector is 2354 thoroughly discussed in Section 3.6.2 of this document. 2356 The same mitigation techniques as described in Section 6.1.1 of this 2357 document apply to this attack-vector. 2359 6.3.2. Rogue Router 2361 An attacker could either send unsolicited Router Advertisements 2362 and/or illegitimately respond to Router Solicitations, advertising 2363 his own node as a default router. 2365 This is similar to the Denial-of-Service (DoS) attack described in 2366 Section 6.1.4, with the only difference that in this case traffic 2367 would be directed to a node operated by the attacker, rather than to 2368 a non-existing node. 2370 In order for an attacker to successfully perform this attack, he 2371 would need to be attached to the same network link on which the 2372 attack is to be launched, or control a node attached to that network 2373 link (e.g., compromise such a node). 2375 The same mitigation techniques as described in Section 6.1.4 apply to 2376 this attack vector. 2378 6.3.3. Bogus on-link prefixes 2380 An attacker could either send unsolicited Router Advertisements 2381 and/or illegitimately respond to Router Solicitations, advertising 2382 bogus prefixes for on-link determination. 2384 As a result, nodes belonging to the aforementioned prefixes would be 2385 considered on-link, and packets destined to them would not be relayed 2386 to a first-hop router, but would instead be delivered on the local 2387 link. The victim nodes (i.e., those receiving the crafted Router 2388 Advertisements) would perform Neighbor Discovery for the intended 2389 destination, and the attacker could then respond with Neighbor 2390 Advertisements that advertise the link-layer address of his node, so 2391 that packets are finally delivered to his malicious node. 2393 In order for an attacker to successfully perform this attack, he 2394 would need to be attached to the same network link on which the 2395 attack is to be launched, or control a node attached to that network 2396 link (e.g., compromise such a node). 2398 The same mitigation techniques as described in Section 6.1.6 apply to 2399 this attack vector. 2401 6.3.4. Tampering with 'on-link determination' 2403 This attack is similar to the Denial-of-Service (DoS) attack 2404 described in Section 6.1.10, with the only difference that for the 2405 purpose of traffic-hijacking, an attacker would make sure that the 2406 cached link-layer address of the Neighbor Cache entry corresponding 2407 to the victim address (the Source Address of the forged Neighbor 2408 Discovery message or the forged Target Address of the forged Neighbor 2409 Advertisement message) corresponds to the link-layer address of a 2410 node operated by the attacker. 2412 As discussed in Section 6.1.9, [RFC5942] updates [RFC4861], such that 2413 this attack vector is eliminated. The same mitigations discussed in 2414 Section 6.1.9 of this document apply to mitigate this vulnerability. 2416 [CVE-2008-2476] and [US-CERT2008] are vulnerability advisories 2417 about this issue. 2419 6.4. Miscellaneous security issues 2421 6.4.1. Detecting Sniffing Hosts 2423 If a system reacts differently depending on whether the network 2424 interface is in promiscuous mode, this can be leveraged by an 2425 attacker that is on-link to infer whether the target node is in 2426 promiscuous mode. Such a security issue has been found on many 2427 operating systems, where a packet with a multicast MAC address that 2428 is not being listened on by that target will be processed only if the 2429 receiving node is in promiscuous mode (i.e., "sniffing" the network). 2430 This test can be performed with any packet type, e.g. Neighbor 2431 Solicitation or Echo Request. 2433 [CVE-2010-4562] is one vulnerability advisory about such an issue. 2435 7. IANA Considerations 2437 This document has no actions for IANA. 2439 8. Security Considerations 2441 This entire document is about security vulnerabilities that have been 2442 found popular Neighbor Discovery implementations, and other potential 2443 security issues that might be affecting existing implementations. 2444 This document not only discusses the aforementioned issues, but also 2445 provides implementation guidance such that these issues can be 2446 eliminated from the affected implementations and completely avoided 2447 or mitigated in any new Neighbor Discovery implementations. 2449 The ultimate goal of this document is to help improve the overall 2450 maturity of Neighbor Discovery implementations, and to raise 2451 awareness about current security issues that might affect IPv6 2452 networks. 2454 9. Acknowledgements 2456 Marc Heuse contributed text, edits, comments, and new vulnerabilities 2457 that were incorporated into this document. 2459 The author would like to thank George Kargiotakis, who provided 2460 valuable comments on earlier versions of this document. 2462 This document is based on the technical report "Security Assessment 2463 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 2464 Fernando Gont on behalf of the UK Centre for the Protection of 2465 National Infrastructure (CPNI). The author would like to thank (in 2466 alphabetical order) Ran Atkinson, Fred Baker, Brian Carpenter, Roque 2467 Gagliano, Guillermo Gont, Alfred Hoenes, Qing Li, Neil Long, and 2468 Pekka Savola, for providing valuable feedback on earlier versions of 2469 such document. Additionally, the author would like to thank (in 2470 alphabetical order) Ran Atkinson, Brian Carpenter, Joel M. Halpern, 2471 Robert Hinden, Pekka Savola, Fred Templin, and Ole Troan, who 2472 generously answered a number of questions when authoring the 2473 aforementioned document. 2475 10. References 2477 10.1. Normative References 2479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2480 Requirement Levels", BCP 14, RFC 2119, March 1997. 2482 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2483 (IPv6) Specification", RFC 2460, December 1998. 2485 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2486 Networks", RFC 2464, December 1998. 2488 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 2489 Inverse Discovery Specification", RFC 3122, June 2001. 2491 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 2492 Discovery (ND) Trust Models and Threats", RFC 3756, 2493 May 2004. 2495 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 2496 in IPv6", RFC 6275, July 2011. 2498 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2499 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2501 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2502 More-Specific Routes", RFC 4191, November 2005. 2504 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2505 Proxies (ND Proxy)", RFC 4389, April 2006. 2507 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2508 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2509 September 2007. 2511 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2512 Address Autoconfiguration", RFC 4862, September 2007. 2514 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 2515 Discovery On-Link Assumption Considered Harmful", 2516 RFC 4943, September 2007. 2518 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 2519 "IPv6 Router Advertisement Options for DNS Configuration", 2520 RFC 6106, November 2010. 2522 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 2523 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 2525 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 2526 Model: The Relationship between Links and Subnet 2527 Prefixes", RFC 5942, July 2010. 2529 [I-D.ietf-6man-nd-extension-headers] 2530 Gont, F., "Security Implications of IPv6 Fragmentation 2531 with IPv6 Neighbor Discovery", 2532 draft-ietf-6man-nd-extension-headers-05 (work in 2533 progress), June 2013. 2535 10.2. Informative References 2537 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2538 Discovery for IP Version 6 (IPv6)", RFC 2461, 2539 December 1998. 2541 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 2542 Problem Statement", RFC 6104, February 2011. 2544 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 2545 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 2546 February 2011. 2548 [I-D.ietf-v6ops-ra-guard-implementation] 2549 Gont, F., "Implementation Advice for IPv6 Router 2550 Advertisement Guard (RA-Guard)", 2551 draft-ietf-v6ops-ra-guard-implementation-07 (work in 2552 progress), November 2012. 2554 [CPNI-IPv6] 2555 Gont, F., "Security Assessment of the Internet Protocol 2556 version 6 (IPv6)", UK Centre for the Protection of 2557 National Infrastructure, (available on request). 2559 [CPNI-TCP] 2560 CPNI, "Security Assessment of the Transmission Control 2561 Protocol (TCP)", 2009, . 2564 [Hogg-Vyncke] 2565 Hogg, S. and E. Vyncke, "IPv6 Security", Cisco Press; 1 2566 edition, 2008. 2568 [Lecigne-Neville-Neil] 2569 Lecigne, C. and G. Neville-Neil, "Walking through FreeBSD 2570 IPv6 stack", 2006, . 2572 [Beck2007] 2573 Beck, F., Cholez, T., Festor, O., and I. Chrisment, 2574 "Monitoring the Neighbor Discovery Protocol", The Second 2575 International Workshop on IPv6 Today - Technology and 2576 Deployment - IPv6TD 2007, . 2579 [Beck2007b] 2580 Beck, F., Festor, O., and I. Chrisment, "IPv6 Neighbor 2581 Discovery Protocol based OS fingerprinting", INRIA 2582 Rapport Technique No 0345, 2007, . 2586 [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", 2587 . 2589 [arpwatch] 2590 LBNL/NRG, "arpwatch tool", 2006, . 2592 [NISCC2006b] 2593 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 2594 Filtering", 2006, . 2597 [vanHauser2006] 2598 vanHauser, "Attacking the IPv6 Protocol Suite", EuSecWest 2599 2006 Conference, 2600 . 2602 [SI6-Toolkit] 2603 "SI6 Networks' IPv6 toolkit", 2604 . 2606 [THC-IPv6] 2607 "The Hacker's Choice IPv6 Attack Toolkit", 2608 . 2610 [CVE-2012-notyet] 2611 CVE, "CVE-2012-notyet - entry is upcoming ... to be 2612 filled", 2012. 2614 [CVE-2011-2391] 2615 CVE, "CVE-2011-2391 - IPv6 Neighbor Discovery Protocol 2616 (NDP) implementations do not limit the rate of Neighbor 2617 Discovery messages processed", 2011. 2619 [CVE-2008-2476] 2620 CVE, "CVE-2008-2476 - IPv6 Neighbor Discovery Protocol 2621 (NDP) implementations do not validate the origin of 2622 Neighbor Discovery messages", 2008. 2624 [CVE-2010-4669] 2625 CVE, "CVE-2010-4669 - Neighbor Discovery (ND) protocol 2626 implementation in the IPv6 stack in Microsoft Windows 2627 allows attackers to cause a denial of service (CPU 2628 consumption and system hang) by sending many Router 2629 Advertisement (RA) messages with different source 2630 addresses", 2010. 2632 [CVE-2011-2395] 2633 CVE, "CVE-2011-2395 - Neighbor Discovery (ND) protocol 2634 implementation in Cisco IOS on unspecified switches allows 2635 attackers to bypass the Router Advertisement Guarding 2636 functionality via a fragmented IPv6 packets", 2011. 2638 [CVE-2010-4562] 2639 CVE, "CVE-2010-4562 - Microsoft Windows, when using IPv6, 2640 allows remote attackers to determine whether a host is 2641 sniffing the network by sending an ICMPv6 Echo Request to 2642 a multicast address and determining whether an Echo Reply 2643 is sent", 2010. 2645 [US-CERT2008] 2646 US-CERT, "US-CERT Vulnerability Note VU#472363: IPv6 2647 implementations insecurely update Forwarding Information 2648 Base", 2008. 2650 [Win-Update] 2651 Microsoft, "An IPv6 readiness update is available for 2652 Windows 7 and for Windows Server 2008 R2", 2012. 2654 Authors' Addresses 2656 Fernando Gont 2657 SI6 Networks / UTN-FRH 2658 Evaristo Carriego 2644 2659 Haedo, Provincia de Buenos Aires 1706 2660 Argentina 2662 Phone: +54 11 4650 8472 2663 Email: fgont@si6networks.com 2664 URI: http://www.si6networks.com 2666 Ronald P. Bonica 2667 Juniper Networks 2668 2251 Corporate Park Drive 2669 Herndon, VA 20171 2670 US 2672 Phone: 571 250 5819 2673 Email: rbonica@juniper.net 2675 Will Liu 2676 Huawei Technologies 2677 Bantian, Longgang District 2678 Shenzhen 518129 2679 P.R. China 2681 Email: liushucheng@huawei.com