idnits 2.17.1 draft-gont-opsec-ipv6-nd-security-00.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 29, 2012) is 4166 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 2414, but no explicit reference was found in the text == Unused Reference: 'SI6-Toolkit' is defined on line 2531, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5006 (Obsoleted by RFC 6106) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for F. Gont 3 IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH 4 Internet-Draft November 29, 2012 5 Intended status: Informational 6 Expires: June 2, 2013 8 Security Assessment of Neighbor Discovery (ND) for IPv6 9 draft-gont-opsec-ipv6-nd-security-00 11 Abstract 13 Neighbor Discovery is one of the core protocols of the IPv6 suite, 14 and provides in IPv6 similar functions to those provided in the IPv4 15 protocol suite by the Address Resolution Protocol (ARP) and the 16 Internet Control Message Protocol (ICMP). Its increased flexibility 17 implies a somewhat increased complexity, which has resulted in a 18 number of bugs and vulnerabilities found in popular implementations. 19 This document provides guidance in the implementation of Neighbor 20 Discovery, and documents issues that have affected popular 21 implementations, in the hopes that the same issues do not repeat in 22 other implementations. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. This document may not be modified, 28 and derivative works of it may not be created, and it may not be 29 published except as an Internet-Draft. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 2, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Neighbor Discovery messages . . . . . . . . . . . . . . . . . 6 63 3.1. Router Solicitation message . . . . . . . . . . . . . . . 6 64 3.2. Router Advertisement . . . . . . . . . . . . . . . . . . . 7 65 3.3. Neighbor Solicitation message . . . . . . . . . . . . . . 11 66 3.4. Neighbor Advertisement message . . . . . . . . . . . . . . 12 67 3.5. Redirect message . . . . . . . . . . . . . . . . . . . . . 15 68 3.6. Neighbor Discovery Options . . . . . . . . . . . . . . . . 18 69 3.6.1. General issues with Neighbor Discovery options . . . . 19 70 3.6.2. Source Link-Layer Address Option . . . . . . . . . . . 20 71 3.6.3. Target Link-Layer Address Option . . . . . . . . . . . 22 72 3.6.4. Prefix Information . . . . . . . . . . . . . . . . . . 23 73 3.6.5. Redirected Header Option . . . . . . . . . . . . . . . 26 74 3.6.6. MTU Option . . . . . . . . . . . . . . . . . . . . . . 27 75 3.6.7. Route Information Option . . . . . . . . . . . . . . . 28 76 3.6.8. Recursive DNS Server Option . . . . . . . . . . . . . 31 77 4. Router and Prefix Discovery . . . . . . . . . . . . . . . . . 33 78 4.1. Router Specification . . . . . . . . . . . . . . . . . . . 33 79 4.2. Host Specification . . . . . . . . . . . . . . . . . . . . 33 80 5. Address Resolution . . . . . . . . . . . . . . . . . . . . . . 35 81 5.1. Interface initialization . . . . . . . . . . . . . . . . . 37 82 5.2. Receipt of Neighbor Solicitation messages . . . . . . . . 38 83 6. Vulnerability analysis . . . . . . . . . . . . . . . . . . . . 39 84 6.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 39 85 6.1.1. Neighbor Cache poisoning . . . . . . . . . . . . . . . 39 86 6.1.2. Tampering with Duplicate Address Detection (DAD) . . . 40 87 6.1.3. Tampering with Neighbor Unreachability Detection 88 (NUD) . . . . . . . . . . . . . . . . . . . . . . . . 41 89 6.1.4. Rogue Router . . . . . . . . . . . . . . . . . . . . . 42 90 6.1.5. Parameter spoofing . . . . . . . . . . . . . . . . . . 42 91 6.1.6. Bogus on-link prefixes . . . . . . . . . . . . . . . . 43 92 6.1.7. Bogus address configuration prefixes . . . . . . . . . 44 93 6.1.8. Disabling routers . . . . . . . . . . . . . . . . . . 44 94 6.1.9. Tampering with 'on-link determination' . . . . . . . . 45 95 6.1.10. Introducing forwarding loops at routers . . . . . . . 46 96 6.1.11. Tampering with a Neighbor Discovery implementation . . 48 97 6.1.12. Tampering with a Neighbor Discovery router 98 implementation from a remote site . . . . . . . . . . 49 99 6.2. Performance degrading . . . . . . . . . . . . . . . . . . 50 100 6.2.1. Parameter spoofing . . . . . . . . . . . . . . . . . . 50 101 6.3. Traffic hijacking . . . . . . . . . . . . . . . . . . . . 51 102 6.3.1. Neighbor Cache poisoning . . . . . . . . . . . . . . . 51 103 6.3.2. Rogue Router . . . . . . . . . . . . . . . . . . . . . 51 104 6.3.3. Bogus on-link prefixes . . . . . . . . . . . . . . . . 52 105 6.3.4. Tampering with 'on-link determination' . . . . . . . . 52 106 6.4. Miscellaneous security issues . . . . . . . . . . . . . . 53 107 6.4.1. Detecting Sniffing Hosts . . . . . . . . . . . . . . . 53 108 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 109 8. Security Considerations . . . . . . . . . . . . . . . . . . . 55 110 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56 111 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 57 112 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 113 11.1. Normative References . . . . . . . . . . . . . . . . . . . 58 114 11.2. Informative References . . . . . . . . . . . . . . . . . . 59 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62 117 1. DISCLAIMER 119 This is WORK IN PROGRESS. Some of the recommendations might possibly 120 change. For instance, some (NOT all) of the proposed "sanity checks" 121 help reduce vulnerability to some attacks at the expense of e.g. 122 reduced responsiveness. Further discussion might find some of such 123 checks to be inadequate or inappropriate. On the other hand, some of 124 mitigations discussed in this document have been incorporated into 125 popular Neighbor Discovery (ND) implementations. 127 2. Introduction 129 Neighbor Discovery is used by nodes on the same link to discover each 130 other's presence, to determine each other's link-layer addresses, to 131 find routers, and to maintain reachability information about the 132 paths to active neighbors [RFC4861]. 134 Neighbor Discovery is specified by [RFC4861]. [RFC3122] specifies 135 extensions to Neighbor Discovery for Inverse Discovery. [RFC4389] 136 specifies Neighbor Discovery proxies. [RFC3756] describes trust 137 models and threats for Neighbor Discovery. [RFC3971] specifies a 138 secure version of Neighbor Discovery named 'SEcure Neighbor Discovery 139 (SEND)'. 141 Neighbor Discovery was originally specified by [RFC2461], which was 142 later obsoleted by [RFC4861]. [RFC4943] clarifies the rationale for 143 the removal of the 'on-link assumption' from [RFC4861]. 145 Section 3 of this document provides an analysis of each of the 146 Neighbor Discovery messages, along with a discussion of the Neighbor 147 Discovery options that have been specified at the time of this 148 writing. Section 4 discusses the security implications of Router and 149 Prefix Discovery. Section 5 describes the security implications of 150 Address Resolution. Section 6 contains a vulnerability analysis of 151 Neighbor Discovery. 153 3. Neighbor Discovery messages 155 The following subsections discuss a number of validation checks that 156 should be performed on Neighbor Discovery messages. 158 3.1. Router Solicitation message 160 The following figure illustrates the syntax of Router Solicitation 161 messages: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type | Code | Checksum | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Reserved | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Options ... 171 +-+-+-+-+-+-+-+-+-+-+-+- 173 Figure 1: ICMPv6 Router Solicitation message format 175 As can be inferred from syntax of Router Solicitation messages, any 176 legitimate Router Solicitation message must have a length (as derived 177 from the IPv6 length) that is 8 octets or more. If the packet does 178 not pass this check, it should be silently dropped. 180 The Source Address of an IPv6 packet encapsulating a Router 181 Solicitation message is set to the value of one of the addresses 182 assigned to the sending interface, or to the unspecified address (::) 183 if no address has been assigned to that interface. Nodes should 184 discard Router Solicitation messages that have a multicast address in 185 the Source Address field. 187 The Destination Address of an IPv6 packet encapsulating a Router 188 Solicitation message is set to the all-routers multicast address. 190 A unicast address could possibly be used for the Destination 191 Address for debugging purposes. 193 If a unicast address is used for the Destination Address, the 194 receiving system should ensure that it is a link-local address. If 195 the packet does not pass this check, it should be silently dropped. 197 While this is not explicitly required in [RFC4861] this provides 198 an additional counter-measure (other than the validation of the 199 Hop Limit) for non-local malicious nodes willing to make use of 200 Router Solicitation messages for reconnaissance purposes. 202 As of this writing, the following options are valid in a Router 203 Solicitation message: 205 o Source link-layer address 207 Any other options should be silently ignored. 209 If a 'source link-layer address' option is included, the following 210 sanity checks should be performed: 212 o The Source Address of the packet must not the unspecified address 213 (::) or the "loopback" addresses (::1) 215 o The advertised link-layer address must not a broadcast or 216 multicast address 218 3.2. Router Advertisement 220 The following figure illustrates the syntax of Router Advertisement 221 messages. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Type | Code | Checksum | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Reachable Time | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Retrans Timer | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Options ... 235 +-+-+-+-+-+-+-+-+-+-+-+- 237 Figure 2: ICMPv6 Router Advertisement message format 239 The Source Address of an IPv6 packet encapsulating a Router 240 Advertisement message is set to a link-local address assigned to the 241 interface from which the message is sent. Nodes should discard 242 Router Advertisements whose Source Address is not a link-local 243 address. 245 The Destination Address of an IPv6 packet encapsulating a Router 246 Advertisement message is set to the Source Address of the system that 247 elicited the Router Advertisement message (unless this was the 248 unspecified address), or in the case of unsolicited Router 249 Advertisements, to the all-nodes multicast address. Nodes receiving 250 a Router Advertisement should ensure that if the Destination Address 251 is a unicast address, it is a link-local address. Otherwise, the 252 Router Advertisement message should be silently dropped. 254 While this is not explicitly required in [RFC4861] this provides 255 another mitigation for non-local malicious nodes willing to make 256 use of Router Solicitation messages for reconnaissance purposes. 258 The Cur Hop Limit field specifies the default value that should be 259 placed in the Hop Count field of outgoing IPv6 packets. As stated in 260 [RFC4861] a value of 0 means unspecified (by this router). If the 261 Cur Hop Limit field is larger than 0, nodes should sanitize the 262 received Cur Hop Limit value as follows: 264 SanitizedCH = max(Cur Hop Limit, MIN_HOP_LIMIT) 266 where the sanitized Cur Hop Limit (SanitizedCH) is set to the maximum 267 of the Cur Hop Limit and the variable MIN_HOP_LIMIT. MIN_HOP_LIMIT 268 should default to 64, and should be configurable by the system 269 administrator. 271 If the received Cur Hop Limit were not sanitized, an attacker could 272 perform a Denial-of-Service (DoS) attack against the local network by 273 forging a Router Advertisement message that includes a very small Cur 274 Hop Limit value. As a result, nodes honouring the Router 275 Advertisement would set the Hop Limit of outgoing packets to such 276 small value, and as a result those packets would be dropped by some 277 intervening router. 279 For example, if an attacker were to forge a Router Advertisement that 280 contains a Cur Hop Limit of 1, the victim nodes could communicate 281 only with nodes on the same network link, as their packets would be 282 dropped by the first-hop router. 284 XXXX The Prf field is specified in [RFC4191] and is used to specify a 285 'preference' value for the router sending the Router Advertisement. 287 The Router Lifetime field is a 16-bit unsigned integer that specifies 288 the lifetime associated with the default router in units of seconds. 289 A Router Lifetime of 0 indicates that the router is not a default 290 router and must not appear in the default router list. The sending 291 rules in Section 6 of [RFC4861] limit the Router Lifetime to 9000 292 seconds. However, nodes are expected to handle any value. 294 An attacker could exploit the Router Lifetime field to perform DoS 295 attacks or performance-degrading attacks. For example, an 296 attacker could forge Router Advertisement messages that include a 297 very small Router Lifetime. This would have a two-fold effect on 298 the network. Firstly, once the advertised router expires as a 299 'default' router, the corresponding nodes might face a Denial of 300 Service, as a result of having no default routers. Secondly, a 301 small Router Lifetime value could lead to increased traffic in the 302 network, and increased processing time in the affected nodes (as a 303 result of the additional Router Solicitation/Advertisement 304 exchanges needed to re-configure the routing table of each node). 306 If the Router Lifetime is different from 0, it should be sanitized as 307 follows: 309 SanitizedRL = min( max(Router Lifetime, MIN_ROUTER_LIFETIME), MAX_ROUTER_LIFETIME) 311 where lower and upper limits are enforced on the advertised Router 312 Lifetime. The lower limit is specified by the variable 313 MIN_ROUTER_LIFETIME, and should default to 1800 seconds. The upper 314 limit is specified by MAX_ROUTER_LIFETIME, and should default to 9000 315 seconds. 317 The value '1800 seconds' results from the recommended default value 318 (AdvDefaultLifetime) for setting the Router Lifetime, which instead 319 results from the expression '3 * MaxRtrAdvInterval' (where 320 MaxRtrAdvInterval defaults to 600 seconds). The value '9000 seconds' 321 results from the required upper limit for setting the Router Lifetime 322 field (AdvDefaultLifetime). 324 The Router Lifetime should not be sanitized when it is equal to 0, as 325 a value of 0 indicates that the corresponding router should not be 326 used as a default router (i.e., it is only advertising prefixes). 328 When a router is in the Default routers list, and a Router 329 Advertisement is received with a Router Lifetime of 0, a node might 330 choose to keep the router in the Default routers list (as allowed by 331 the current local Router Lifetime value). This might allow nodes to 332 be resilient to Router Advertisements that incorrectly or maliciously 333 advertise a Router Lifetime of 0, at the expense of loss of 334 responsiveness in scenarios in which a router explicitly advertises 335 it wants to be removed from the Default routers list (such a scenario 336 is described in Section 6.2.5 of [RFC4861]. 338 The Reachable Time field is a 32-bit unsigned integer that specifies 339 the amount of time, in milliseconds, that a node assumes a neighbor 340 is reachable after having received a reachability confirmation. A 341 value of zero means 'unspecified by this router'. If Reachable Time 342 is different from 0, it should be sanitized as follows: 344 SanitizedRT = max( min( Reachable Time, MAX_REACHABLE_TIME), MIN_REACHABLE_TIME) 346 where MAX_REACHABLE_TIME and MIN_REACHABLE_TIME impose upper and 347 lower limits, respectively, to the received Reachable Time value. We 348 propose a MAX_REACHABLE_TIME of 3,600,000 (one hour) and a 349 MIN_REACHABLE_TIME of 20,000. 351 The upper limit of 3,600,000 is specified in Section 6.2.1 of 352 [RFC4861] (AdvReachableTime router variable). The lower limit has 353 been selected such that the minimum local ReachableTime (that would 354 result from MIN_RANDOM_FACTOR * SanitizedRT) is not smaller than 10 355 seconds. 357 The Retrans Timer is a 32-bit unsigned integer that specifies the 358 amount of time, in milliseconds between retransmitted Neighbor 359 Solicitation messages. A value of zero means 'unspecified by this 360 router'. If Retrans Timer is different from 0, it should be 361 sanitized as follows: 363 SanitizedRXT = max( min( Retrans Timer, MAX_RETRANS_TIME), MIN_RETRANS_TIME) 365 We propose a MAX_RETRANS_TIME of 60,000 and a MIN_RETRANS_TIME of 366 1,000. 368 At the time of this writing, the options that may be legitimately 369 included in Router Advertisements are: 371 o Source link-layer address 373 o MTU 375 o Prefix information 377 o Route Information 379 o Recursive DNS Server 381 Other options should be silently ignored. 383 The Source link-layer address option specifies the link-layer address 384 of the interface from which the Router Advertisement is sent. It is 385 only used on link layers that have addresses. Nodes should ignore 386 the source link-layer address option in Router Advertisements 387 received on link layers that do not have addresses. 389 Section 3.6 of this document discusses the security implications of 390 all the Neighbor Discovery options. 392 3.3. Neighbor Solicitation message 394 The following figure illustrates the format of Neighbor Solicitation 395 messages: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type | Code | Checksum | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Reserved | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | | 405 + + 406 | | 407 + Target Address + 408 | | 409 + + 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Options ... 413 +-+-+-+-+-+-+-+-+-+-+-+- 415 Figure 3: ICMPv6 Neighbor Solicitation message format 417 The Source Address of an IPv6 packet encapsulating a Neighbor 418 Solicitation message is set to an address assigned to the interface 419 from which the message is sent, or to the unspecified address (::). 421 The Destination Address of an IPv6 packet encapsulating a Neighbor 422 Solicitation message is set to the solicited-node multicast address 423 corresponding to the target address, or to the target address. 425 The ICMPv6 packet length (as derived from the IPv6 Payload Length) 426 must be greater than or equal to 24. If the packet does not pass 427 this check, it should be silently dropped. 429 The Target Address is the IPv6 address of the target of the 430 solicitation. The Target Address must pass the following checks: 432 1. It must not be a multicast address (as required in Section 4.3 of 433 [RFC4861]) 435 2. It must not be the unspecified address (::) 436 3. It must not be the loopback address::1) 438 The Target Address must also meet any of the following criteria: 440 1. It is a valid unicast or anycast address assigned to the 441 receiving interface 443 2. It is a unicast or anycast address for which the node is offering 444 proxy service 446 3. It is a 'tentative' address on which 'Duplicate Address 447 Detection' (DAD) is being performed (in which case the Neighbor 448 Solicitation message should be processed according to [RFC4862]) 450 At the time of this writing, the options that may be legitimately 451 included in Neighbor Solicitations are: 453 o Source link-layer address 455 According to Section 4.3 of [RFC4861], the source link-layer address 456 option must not be included when the Source Address is the 457 unspecified address (::). A node receiving a Neighbor Solicitation 458 that includes a source link-layer address and that has the 459 unspecified address (::) as the Source Address should silently drop 460 the corresponding packet. 462 According to Section 4.3 of [RFC4861], on link layers that have 463 addresses (and provided that the Source Address is not the 464 unspecified address), Neighbor Solicitations sent to multicast 465 addresses must include the source link-layer address option. A node 466 receiving a Neighbor Solicitation sent to a multicast address that 467 does not include a source link-layer option should be silently 468 dropped. 470 3.4. Neighbor Advertisement message 472 A node sends Neighbor Advertisements in response to Neighbor 473 Solicitations and sends unsolicited Neighbor Advertisements in order 474 to (unreliably) propagate new information quickly [RFC4861]. 476 The following figure illustrates the syntax of Neighbor Advertisement 477 messages: 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type | Code | Checksum | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |R|S|O| Reserved | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 + + 488 | | 489 + Target Address + 490 | | 491 + + 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Options ... 495 +-+-+-+-+-+-+-+-+-+-+-+- 497 Figure 4: ICMPv6 Neighbor Advertisement message format 499 The Source Address of an IPv6 packet encapsulating a Neighbor 500 Advertisement message is set to a link-local address assigned to the 501 interface from which the message is sent. Nodes should discard 502 Neighbor Advertisements that do not have a link-local address in the 503 Source Address field. 505 The Destination Address of an IPv6 packet encapsulating a Neighbor 506 Advertisement message is set to the Source Address of the Neighbor 507 Solicitation that elicited the Neighbor Advertisement message 508 (provided the Source Address of the Neighbor Solicitation was a 509 unicast address). If the Source Address of the Neighbor Solicitation 510 was the unspecified address, the Neighbor Advertisement is sent to 511 the all-nodes multicast address. Finally, unsolicited Neighbor 512 Advertisements are sent to the all-nodes multicast address 514 The Hop Limit of an IPv6 packet encapsulating a Neighbor 515 Advertisement message must be set to 255 by the sending node. A node 516 receiving a Neighbor Advertisement message should perform the 517 following check: 519 The ICMPv6 packet length (as derived from the IPv6 Payload Length) 520 must be greater than or equal to 24. If the packet does not pass 521 this check, it should be silently dropped. 523 The R flag is the Router flag, and is used by Neighbor Unreachability 524 Detection (NUD). When set, it indicates that the sender is a router. 525 An attacker could forge a Neighbor Advertisement message with the 526 Router flag cleared to cause the receiving node to remove the 527 impersonated Router from the Default router list. 529 The S bit is the Solicited flag. When set it indicates that the 530 Neighbor Advertisement is sent in response to a Neighbor Solicitation 531 sent from the Destination Address. The S flag is used as 532 reachability confirmation for Network Unreachability Detection (NUD). 533 As stated in Section 4.4 of [RFC4861], it must not be set in 534 multicast advertisements or in unsolicited unicast advertisements. 536 A node that receives a Neighbor Advertisement message that has the 537 S-bit set and was sent to a multicast address should silently discard 538 the received message. Additionally, a node that receives an 539 unsolicited Neighbor Advertisement message (i.e., there was not a 540 pending Neighbor Solicitation for the Target Address) with the S-bit 541 set that was sent to a unicast address should silently drop the 542 received message. 544 The O bit is the Override flag. When set, it indicates that this 545 Neighbor Advertisement should override an existing cache entry and 546 update the cached link-layer address. When the O bit is not set, the 547 advertisement will not update a cached link-layer address, but will 548 update a Neighbor Cache entry that does not include a link-layer 549 address. 551 The O bit should be set in all solicited advertisements, except those 552 for anycast addresses. A node that receives an unsolicited Neighbor 553 Advertisement message with the O bit set should silently drop the 554 received message. However, we note that it is virtually impossible 555 to enforce this requirement for Neighbor Advertisement messages for 556 anycast addresses that have the O bit set, as anycast addresses are 557 syntactically indistinguishable from normal unicast addresses. 559 For solicited Neighbor Advertisements, the Target Address is set to 560 the Target Address of the Neighbor Solicitation message that elicited 561 the advertisement. For unsolicited Neighbor Advertisements, the 562 Target Address is set to the address whose link-layer address has 563 changed. 565 The Target Address must pass the following checks: 567 1. It must not be a multicast address (as required in Section 4.4 of 568 [RFC4861] 570 2. It must not be the unspecified address (::) 572 3. It must not be the loopback address (::1) 574 As of this writing, the following options are allowed in Neighbor 575 Advertisement messages: 577 o Target link-layer address 579 Other options present in a Neighbor Advertisement should be ignored. 581 The target link-layer address specifies the link-layer address of the 582 target of the Neighbor Advertisement. According to Section 4.4 of 583 [RFC4861], this option must be included in Neighbor Advertisements 584 when they are sent in response to neighbor solicitations sent to 585 multicast addresses (provided the link layer has addresses). A node 586 that receives a Neighbor Advertisement message in response to a 587 solicitation sent to a multicast address, without a target link-layer 588 address should silently drop the received message (provided that the 589 corresponding link layer has addresses). 591 Section 3.6.3 contains further validation checks that should be 592 performed on target link-layer address options. 594 3.5. Redirect message 596 Routers send Redirect packets to inform a host of a better first-hop 597 node on the path to a destination, or to inform a host that the 598 destination node is in fact a neighbor (i.e., it is attached to the 599 same link). 601 The following figure illustrates the syntax of the Redirect message: 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Type | Code | Checksum | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Reserved | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 + + 612 | | 613 + Target Address + 614 | | 615 + + 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | | 619 + + 620 | | 621 + Destination Address + 622 | | 623 + + 624 | | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Options ... 627 +-+-+-+-+-+-+-+-+-+-+-+- 629 Figure 5: ICMPv6 Redirect message format 631 The Source Address of the IPv6 header is set to the link-local 632 address assigned to the interface from which the Redirect message is 633 sent. A node that receives a Redirect message should verify that the 634 Source Address of the IPv6 header is a link-local address. If the 635 packet does not pass this check, the Redirect message should be 636 silently dropped. The Source Address of a Redirect message must 637 correspond to the IPv6 address of the current first-hop router for 638 the specified ICMPv6 Destination Address (i.e., the IPv6 address 639 specified in the Destination Address field of the ICMPv6 Redirect 640 message). If the packet does not pass this check, it should be 641 silently dropped. 643 The Destination Address of the IPv6 header is set to the Source 644 Address of the packet that triggered the Redirect. 646 The Target Address specifies an IPv6 address that is a better first 647 hop to use for the IPv6 address specified in the Destination Address 648 field of the ICMPv6 header. If the Redirect message is meant to 649 indicate that a destination is in fact a neighbor (i.e., it is 650 attached to the same link), the Target Address is set to the same 651 value as the Destination Address field of the ICMPv6 header. 653 When the Redirect indicates a first-hop router, the Target Address 654 must be a link-local address (that of the aforementioned 'better 655 first-hop router'). A node that receives a Redirect message in which 656 the Target Address and the Destination Address are different should 657 verify that the Target Address is a link-local address. If the 658 Redirect message does not pass this check, it should be silently 659 dropped. 661 Additionally, the following checks should be performed on the ICMPv6 662 Target Address and the ICMPv6 Destination Address: 664 1. They must not contain a multicast address 666 2. They must not contain the unspecified address (::) 668 3. They must not contain the loopback address (::1) 670 If a Redirect message does not pass this check, it should be dropped. 672 As of this writing, the following options are legitimate for the 673 Redirect message: 675 o Target link-layer address 677 o Redirected header 679 [RFC4861] specifies that the target-link layer address should be 680 included (if known) in Redirect messages, and that it must be 681 included for NBMA links that rely on the presence of the Target link- 682 layer address option to determine the link-layer address of 683 neighbors. 685 As explained in Section 8.3 of [RFC4861], if a Redirect message 686 contains a Target link-layer address option, the node processing the 687 redirect will create or update the Neighbor Cache entry for the 688 target. As a result, an attacker could exploit ICMPv6 Redirect 689 messages not only to maliciously update the Destination Cache of the 690 victim node, but also (or alternatively) to maliciously update its 691 Neighbor Cache. 693 The Redirected header option allows the sender of the Redirect 694 message to include a portion of the packet that triggered the 695 Redirect message. The Redirected header option is discussed in 696 Section 3.6.5. 698 3.6. Neighbor Discovery Options 700 Neighbor Discovery messages can include a number of options. Such 701 options have the following general syntax: 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Type | Length | ... | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 ~ ... ~ 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 Figure 6: Neighbor Discovery option format 713 The Type field is an 8-bit identifier of the type of option. As of 714 this writing, the following options have been specified: 716 +------+---------------------------+----------------------------+ 717 | Type | Meaning | Summary | 718 +------+---------------------------+----------------------------+ 719 | 1 | Source link-layer address | Discussed in Section 3.6.2 | 720 +------+---------------------------+----------------------------+ 721 | 2 | Target link-layer address | Discussed in Section 3.6.3 | 722 +------+---------------------------+----------------------------+ 723 | 3 | Prefix information | Discussed in Section 3.6.4 | 724 +------+---------------------------+----------------------------+ 725 | 4 | Redirected header | Discussed in Section 3.6.5 | 726 +------+---------------------------+----------------------------+ 727 | 5 | MTU | Discussed in Section 3.6.6 | 728 +------+---------------------------+----------------------------+ 729 | 24 | Route Information | Discussed in Section 3.6.7 | 730 +------+---------------------------+----------------------------+ 731 | 25 | Recursive DNS Server | Discussed in Section 3.6.8 | 732 +------+---------------------------+----------------------------+ 734 Table 1: Neighbor Discovery options 736 The Length field specifies the length of the option in units of 8 737 octets. As stated in 4.6 of [RFC4861] a Length of 0 is invalid. 738 Nodes must silently discard Neighbor Discovery packets that contain 739 an option with a Length of 0. 741 3.6.1. General issues with Neighbor Discovery options 743 The following subsections discuss security issues that apply to all 744 Neighbor Discovery options. 746 The proposed checks should be performed in addition to any option- 747 specific checks proposed in the next sections. 749 Processing requirements 751 Processing of Neighbor Discovery options consumes CPU resources at 752 the processing node. While the Hop Limit check of the IPv6 header 753 encapsulating a Neighbor Discovery message limits potential attackers 754 to those attached to the same link as the target node, there's still 755 the potential of an on-link system overwhelming a node by sending it 756 packets with a surprisingly large number of Neighbor Discovery 757 options. 759 To reduce the impact of these packets on the system performance, a 760 few counter-measures could be implemented: 762 o Rate-limit the number of Neighbor Discovery packets that are 763 processed by the system. 765 o Enforce a limit on the maximum number of options to be accepted in 766 any Neighbor Discovery message. 768 The first check avoids a large number of Neighbor Discovery packets 769 to overwhelm the system in question. The second check avoids packets 770 with multiple Neighbor Discovery options to affect the performance of 771 the system. 773 Most implementations fail to rate-limit ND packets, and hence have 774 been found vulnerable to the aforementioned issue (see e.g. 775 [CVE-2011-2391]). 777 Option Length 779 The Length field specifies the length of the option in units of 8 780 octets. As stated in 4.6 of [RFC4861] a Length of 0 is invalid. 781 Nodes must silently discard Neighbor Discovery packets that contain 782 an option with a Length of 0. This check prevents, among other 783 things, loops in option processing that may arise from incorrect 784 option lengths. 786 Additionally, while the Length byte of a Neighbor Discovery option 787 allows for an option length of up to 2040 octets (255 * 8 octets), 788 there is a limit on legitimate option length imposed by the syntax of 789 the IPv6 header. 791 For all Neighbor Discovery options, the following check should be 792 enforced: 794 option-offset + Length * 8 - MIN_IPV6_HEADER <= Payload Length 796 Where 798 option-offset is the offset of the first byte of the option within 799 the IPv6 packet (with the first octet of the IPv6 header having an 800 'offset' of 0). Length is the Length field of the Neighbor Discovery 801 option being processed. MIN_IPV6_HEADER is the size of the fixed 802 IPv6 header. That is, 40 octets. Payload Length is the header field 803 from the IPv6 header encapsulating the Neighbor Discovery message. 805 If a Neighbor Discovery option does not pass this check, the 806 corresponding Neighbor Discovery message should be silently dropped. 808 The aforementioned check is meant to detect forged option-length 809 values that might make an option illegitimately exceed the actual 810 length of the IPv6 packet encapsulating the Neighbor Discovery 811 message. 813 3.6.2. Source Link-Layer Address Option 815 The Source link-layer address option contains the link-layer address 816 of the sender of the packet. It is used by Neighbor Solicitation, 817 Router Solicitation, and Router Advertisement messages. 819 The following figure illustrates the syntax of the source link-layer 820 address: 822 0 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Type | Length | Link-Layer Address ... 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Figure 7: ND Source link-layer address option 830 The Type field is set to 1. The Length field specifies the length of 831 the option (including the Type and Length octets) in units of 8 832 octets. A node that receives an ICMPv6 message with this option 833 should verify that the Length field is valid for the underlying link 834 layer. For example, for IEEE 802 addresses the Length field must be 835 1 [RFC2464]. If the packet does not pass this check, it should be 836 silently dropped. 838 The Link-Layer Address field contains the link-layer address. The 839 length, contents, and format of this field varies from one link layer 840 to another, and is specified in specific documents that describes how 841 IPv6 operates over different link layers. 843 A number of validation checks should be performed on the Link-Layer 844 Address. In the case of IEEE 802 addresses, it should not contain a 845 broadcast or multicast address. If the option does not pass this 846 check, the Neighbor Discovery message carrying the option should be 847 discarded. 849 Additionally, nodes should not allow the source link-layer address to 850 contain one of the receiving node's link-layer addresses. If the 851 option does not pass this check, the Neighbor Discovery message 852 carrying the option should be discarded. 854 The source link-layer address option could be exploited for the 855 purpose of 'Neighbor Cache poisoning', that is, to cause traffic 856 meant for a specific IPv6 address to be illegitimately directed to 857 the node whose link-layer address is specified by the Link-Layer 858 Address field. 860 This is similar to the ARP cache poisoning attacks in IPv4. 862 A possible counter-measure for Neighbor Cache poisoning attacks would 863 be to override the link-layer address stored in the Neighbor Cache 864 only after Neighbor Unreachability Detection (NUD) finds the neighbor 865 to be unreachable and the corresponding entry is removed. This is 866 clearly a trade-off between responsiveness and resiliency. 868 In some network scenarios it may be possible and desirable to 869 configure static Neighbor Cache entries, such that Neighbor Discovery 870 need not be performed for the corresponding IPv6 addresses. 872 Some implementations have been found to inadvertently override static 873 entries when they receive source link-layer address options or target 874 link-layer address options in Neighbor Discovery messages 875 [Hogg-Vyncke] [Lecigne-Neville-Neil]. 877 If source link-layer address options were allowed to contain 878 broadcast (e.g., the IEEE 802 'ff:ff:ff:ff:ff:ff' address) or 879 multicast (e.g., the IEEE 802 '33:33:00:00:00:01' address) addresses, 880 traffic directed to the corresponding IPv6 address would be sent to 881 the broadcast or multicast address specified in the source link-layer 882 option. This could have multiple implications: 884 It would have a negative impact on the performance of the nodes 885 attached to the network and on the network itself, as packets sent to 886 these addresses would need to be delivered to multiple nodes (and 887 processed by them) unnecessarily. 889 An attacker could capture network traffic sent to the corresponding 890 IPv6 address, as the corresponding packets would be delivered to all 891 (in the case of broadcast) or multiple (in the case of multicast) 892 nodes. 894 Packets could result in forwarding loops at routers, as a router 895 forwarding a packet to the corresponding address would receive itself 896 a copy of the forwarded packet, thus resulting in a forwarding loop. 897 The loop would end only when the Hop Limit is eventually decremented 898 to 0. If multiple routers are present on the same link, the problem 899 is further exacerbated. Section 6.1.10 of this document contains 900 further analysis of this vulnerability. 902 [Lecigne-Neville-Neil] reports that at least some versions of FreeBSD 903 are vulnerable to these issues. 905 3.6.3. Target Link-Layer Address Option 907 The Target link-layer address option contains the link-layer address 908 of the Target of the packet. It is used by Neighbor Advertisement 909 and Redirect messages. 911 The following figure illustrates the syntax of the Target link-layer 912 address: 914 0 1 2 3 915 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 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Type | Length | Link-Layer Address ... 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 Figure 8: ND Target link-layer address option format 922 The Type field is set to 2. The Length field specifies the length of 923 the option (including the Type and Length octets) in units of 8 924 octets. A node that receives an ICMPv6 message with this option 925 should verify that the Length field is valid for the underlying link- 926 layer. For example, for IEEE 802 addresses the Length field must be 927 1 [RFC2464]. If the packet does not pass this check, it should be 928 silently dropped. 930 The Link-Layer Address field contains the link-layer address. The 931 length, contents, and format of this field varies from one link layer 932 to another, and is specified in specific documents that describes how 933 IPv6 operates over different link layers. 935 The target link-layer address has the same security implications as 936 the source link-layer address. Therefore, the same considerations 937 apply, and the same validation checks should be performed as for the 938 source link-layer address (see Section 3.6.2). 940 3.6.4. Prefix Information 942 The Prefix Information option is used by routers to provide hosts 943 with on-link prefixes and prefixes for Address Auto-configuration. 944 It may only appear in Router Advertisement messages and should be 945 silently ignored in any other messages [RFC4861]. 947 The following figure illustrates the syntax of the Prefix Information 948 option: 950 0 1 2 3 951 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 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Type | Length | Prefix Length |L|A|R|Reserved1| 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Valid Lifetime | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Preferred Lifetime | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Reserved2 | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | | 962 + + 963 | | 964 + Prefix + 965 | | 966 + + 967 | | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 Figure 9: ND Prefix Information option format 972 The Type field is set to 3. The Length field is set to 4 by the 973 sender. A node processing a Prefix Information option should verify 974 that the Length field is 4. If the option does not pass this check, 975 the option should be ignored. 977 The Prefix Length is an 8-bit unsigned integer that specifies the 978 prefix length, that is, the number of leading bits in the Prefix 979 field that are valid. 981 The following sanity check should be applied on the Prefix Length 982 field: 984 Prefix Length >= 32 986 If the Prefix Length field does not pass this checks, the Prefix 987 Information option should be discarded. 989 The L bit is a 1-bit flag that, when set, states that the prefix can 990 be used for on-link determination. The A bit is a 1-bit autonomous 991 address-configuration flag that indicates whether this prefix can be 992 used for autonomous address configuration. The R flag is specified 993 by [RFC3775], and indicates that the Prefix field contains a complete 994 IPv6 address assigned to the sending router. The Reserved1 field is 995 a 6-bit unused field that is set to zero by the sender and must be 996 ignored by the receiver. 998 The Valid Lifetime field is a 32-bit unsigned integer that specifies 999 the amount of time (in seconds) this prefix can be used for on-link 1000 determination (with a value of 0xffffffff representing 'infinity'). 1001 We recommend hosts to sanitize the Valid Lifetime as follows: 1003 SanitizedVL = max(Valid Lifetime, MIN_VALID_LIFETIME) 1005 Where SanitizedVL is the sanitized 'Valid Lifetime', and 1006 MIN_VALID_LIFETIME is set to 1800 (seconds). 1008 The value of 1800 seconds for MIN_VALID_LIFETIME has been selected to 1009 coincide with the lower limit enforced on the Router Lifetime 1010 (MIN_ROUTER_LIFETIME). 1012 The Preferred Lifetime is a 32-bit unsigned integer that specifies 1013 the length of time (in seconds) that addresses generated from this 1014 prefix via stateless address auto-configuration (SLAAC) should remain 1015 'preferred' (with a value of 0xffffffff representing 'infinity'). 1017 As noted in [RFC4861] the Preferred Lifetime must be smaller than or 1018 equal to the Valid Lifetime to avoid preferring addresses that are no 1019 longer valid. Therefore, a node processing a Prefix Information 1020 option should perform the following check: 1022 Preferred Lifetime <= Valid Lifetime 1024 If the option does not pass this check, it should be silently 1025 ignored. 1027 The Reserved2 is a 32-bit unused field that is set to zero by the 1028 sender and must be ignored by the receiver. 1030 The Prefix field contains an IPv6 address or a prefix of an IPv6 1031 address. 1033 The Prefix Length contains the number of leading bits in the prefix 1034 that are to be considered valid. The remaining bits in the Prefix 1035 field are set to zero by the sender and must be ignored by the 1036 receiver. 1038 As stated in Section 4.6.2 of [RFC4861], routers should not send a 1039 Prefix Information option for the link-local prefix. Therefore, a 1040 node should verify that the Prefix does not contain the link-local 1041 prefix. If the option does not pass this check, it should be 1042 silently dropped. 1044 Additionally, a node should verify that the Prefix does not contain a 1045 multicast IPv6 prefix. If the option does not pass this check, it 1046 should be silently dropped. 1048 An attacker could exploit the Prefix information option to perform a 1049 Denial-of-Service attack, by sending a large number of Router 1050 Advertisements with the Prefix Information options that have the A 1051 bit set, therefore advising the receiving systems to configure an 1052 IPv6 address with each of these prefixes. If an implementation does 1053 not enforce a limit on the number of addresses they configure in 1054 response to Router Advertisements, the aforementioned attack might 1055 result in buffer overflows or kernel memory exhaustion. 1057 [CVE-2010-4669] is one vulnerability report about the 1058 aforementioned issue. 1060 We recommend hosts to default to a maximum number of configured 1061 addresses (for each interface) of 16. 1063 This limits is already being enforced by a number of implementations, 1064 such as OpenBSD 4.2. 1066 On the other hand, Windows XP SP2 and FreeBSD 9.0 fail to enforce 1067 limits on the maximum number of configured addresses, and therefore 1068 are vulnerable to a Denial of Service attack. 1070 Even if hosts do enforce a limit on the number of IPv6 addresses 1071 configured, an attacker might try to cause victim hosts to ignore 1072 legitimate prefixes previously advertised for address configuration 1073 by legitimate routers. Hereby we recommend hosts to not discard 1074 previously configured addresses if new prefixes for address auto- 1075 configuration are advertised and the limit for the maximum number of 1076 configured addresses (per interface) has been reached. When such 1077 limit is hit, the newly advertised prefixes for address auto- 1078 configuration should be ignored. 1080 Section 3.6.4 describes how an attacker could exploit the Prefix 1081 Information option for the purpose of traffic hijacking. 1083 3.6.5. Redirected Header Option 1085 The Redirected Header option is used in Redirect messages to convey 1086 all or part of the packet that is being redirected. It must be 1087 silently ignored for all other messages. 1089 The following figure illustrates the syntax of the Redirected Header 1090 option: 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Type | Length | Reserved | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Reserved | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | | 1100 ~ IP header + data ~ 1101 | | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Figure 10: ND Redirected Header option format 1106 The Type field is 4. The Length field specifies the option size 1107 (including the Type and Length fields) in units of 8 octets. 1108 Assuming the Redirected Header option will contain at least the 1109 mandatory fields of the option (8 bytes), the fixed IPv6 header (40 1110 bytes), and the first 8 bytes of the transport protocol header, the 1111 following validation check should be performed: 1113 Length >= 7 1115 If the option does not pass this check, the corresponding Redirect 1116 Message should be silently ignored. 1118 As the option is meant to contain as much of the Redirected packet 1119 without exceeding the minimum IPv6 MTU, and the minimum IPv6 MTU is 1120 1280 octets, this is a sensible requirement to enforce. 1122 3.6.6. MTU Option 1124 The MTU option is used in Router Advertisement messages to ensure 1125 that all nodes on a link use the same MTU value in those scenarios in 1126 which heterogeneous technologies are bridged together. This option 1127 must be silently ignored for other Neighbor Discovery messages. 1129 The following figure illustrates the syntax of the MTU option: 1131 0 1 2 3 1132 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 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Type | Length | Reserved | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | MTU | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 Figure 11: ND MTU option format 1141 The Type field identifies the kind of option and is set to 5. This 1142 option has a fixed Length that is 1. Therefore, the following sanity 1143 check should be performed: 1145 Length == 1 1147 If the option does not pass this check it, should be ignored. 1149 The Reserved field is a 16-bit unused field that is set to 0 by the 1150 sender and should be ignored by the receiver. 1152 The MTU field is a 32-bit unsigned integer that specifies the MTU 1153 value that should be used for this link. [RFC2460] specifies that 1154 the minimum IPv6 MTU is 1280 octets. Therefore, a node processing a 1155 MTU option should perform the following check: 1157 MTU >= MINIMUM_IPV6_MTU 1159 where MINIMUM_IPV6_MTU is a variable that should be set to 1280. 1161 If the option does not pass this check, it should be silently 1162 ignored. 1164 It has been reported that some link layers do not support a minimum 1165 MTU of 1280 bytes. Therefore, implementations should provide the 1166 means to change the default value of the MINIMUM_IPV6_MTU variable. 1168 Additionally, the advertised MTU should not exceed the maximum MTU 1169 specified in the link-type-specific document (e.g., [RFC2464] for 1170 Ethernet networks). Therefore, a node processing a MTU option should 1171 perform the following check: 1173 MTU <= MAX_LINK_MTU 1175 where MAX_LINK_MTU is a variable that should be set according to the 1176 maximum link MTU specified in the link-type-specific document (e.g., 1177 [RFC2464] for Ethernet). 1179 If the option does not pass this check, it should be silently 1180 ignored. 1182 The MTU option could be potentially exploited by an attacker to 1183 perform a Denial-of-Service (DoS) or a performance-degrading attack 1184 against the systems in a local network. In order to perform this 1185 attack, an attacker would forge a Router Advertisement that includes 1186 an MTU option with a very small (possibly zero) value. The impact of 1187 this attack would be the same as the 'Blind performance-degrading 1188 attack' described in Section 15.7 of [CPNI-TCP]. 1190 3.6.7. Route Information Option 1192 The Route Information option is used to convey more-specific routes 1193 in Router Advertisement messages. The following figure illustrates 1194 the syntax of the Router Information option: 1196 0 1 2 3 1197 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 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Route Lifetime | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Prefix (Variable Length) | 1204 . . 1205 . . 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 Figure 12: ND Route Information option format 1210 The Type field identifies the type of option and is set to 24. The 1211 Length field contains the length of the option (including the Type 1212 and Length fields) in units of 8 octets. The following sanity checks 1213 should be performed on these Length field: 1215 (Length >=1) && (Length <=3) 1217 If the option does not pass this check, it should be ignored. 1219 An option Length of 1 octet allows the specification of prefixes with 1220 a length of 0 (i.e., /0), while an option Length of 3 allows the 1221 specification of prefixes of up to 128 bits (i.e., /128). 1223 The Prefix Length field indicates the number of leading bits in the 1224 Prefix field that are valid. The Length field and the Prefix Length 1225 field are closely related, as the Length field constrains the 1226 possible values of the Prefix Length field. 1228 The following sanity check should be enforced on the Prefix Length 1229 field: 1231 Prefix Length <= (Length - 1) * 64 1233 If the option does not pass this check, it should be ignored. 1235 Both of the Rsvd fields are set to zero by the sender of the message, 1236 and should be ignored by the receiver. The Prf field specifies the 1237 'Preference' of this route. As specified by RFC 4191, if the Prf 1238 field contains the value of '10' ('Reserved'), the option should be 1239 ignored. 1241 The Route Lifetime field specifies the length of time, in seconds, 1242 that the prefix is valid for route determination. While not required 1243 by RFC 4191, we recommend hosts to perform the following sanity check 1244 on the Route Lifetime field: 1246 SanitizedRL = min( max(Route Lifetime, MIN_ROUTE_LIFETIME), MAX_ROUTE_LIFETIME) 1248 Where MIN_ROUTE_LIFETIME is set to 1800 seconds and 1249 MAX_ROUTE_LIFETIME is set to 9000 seconds. 1251 These values have been selected according to the upper and lower 1252 limits described in Section 3.2 ('Router Advertisement') of this 1253 document for the Router Lifetime field of Router Advertisements. 1255 The Prefix field contains the actual IPv6 prefix that, together with 1256 the Prefix Length field, identifies the route. A number of sanity 1257 checks should be enforced on the Prefix field. For example, the 1258 Prefix should neither contain a link-local unicast prefix (e.g., 1259 fe80::/10, fe80::/64, etc.) nor a link-local multicast prefix (e.g., 1260 ff02::0/64). 1262 The Route information option has a number of security implications. 1263 Firstly, an attacker could forge Router Advertisements with a higher 1264 'preference' value (Prf), thus overriding the existing default 1265 routers at the attacked system. Secondly, an attacker could exploit 1266 this option to implant more specific routes to a victim prefix at the 1267 attacked system, thus overriding the existing routes for that victim 1268 prefix. Thirdly, an attacker could cause an existing route to a 1269 victim prefix to be removed from the routing table of the attacked 1270 host, by forging a Route Information option that contains a Route 1271 Lifetime of 0 (or some other small value). Fourthly, if an 1272 implementation does not enforce limits on the size of the Destination 1273 Cache, an attacker could possibly exhaust the kernel memory or CPU 1274 cycles of that system by forging a large number of Route Information 1275 options (possibly in many different Router Advertisements), such that 1276 the attacked system consumes its kernel memory and/or its CPU time to 1277 install those routes (see e.g. [CVE-2012-notyet]). 1279 A general mitigation for the security implications of Router 1280 Advertisements that can be applied when the protocols are deployed is 1281 to restrict which ports of a managed switch can send Router 1282 Advertisement messages. That is, Router Advertisements received on 1283 all other ports of the switch would be discarded. This mechanism is 1284 commonly-known as Router Advertisement Guard (RA-Guard) [RFC6104] 1285 [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. 1287 We recommend hosts to not simply discard a default router entry when 1288 a Router Preference with a higher Prf value is received. In 1289 particular, default routers that are known to be working should not 1290 be discarded when such Router Advertisements are received. 1292 This means that the higher-priority router would override the 1293 existing default router, but the latter would still be kept in the 1294 "default routers list", such that if the newly-learned router is 1295 found to be non-working, the existing (lower-priority) router 1296 could still be employed). 1298 We recommend hosts to enforce a lower limit Prefix Length in the 1299 Route Information options. This would prevent an attacker from 1300 overriding the default routers by including, e.g., one Route 1301 Information option for the prefix ::/1 and one Route Information 1302 option for the prefix 8000::/1. We recommend hosts to enforce a 1303 minimum Prefix Length of 32. Hosts may also enforce an upper limit 1304 on the Prefix Length, such that an attacker cannot easily redirect 1305 traffic to specific site. A possible upper limit for the Prefix 1306 Length would be 64. As discussed earlier in this Section, the Route 1307 Lifetime value should be sanitized, and a route entry should not 1308 simply be discarded when a Route Information option with a Route 1309 Lifetime of 0 is received. 1311 Finally, hosts should enforce a limit on the maximum number of 1312 entries in the Destination Cache. 1314 3.6.8. Recursive DNS Server Option 1316 The Recursive DNS Server (RDNSS) option provides a mechanism for 1317 routers to advertise the IPv6 addresses of one or more Recursive DNS 1318 Servers. This option is specified in [RFC5006]. The following 1319 figure illustrates the syntax of the RDNSS options: 1321 0 1 2 3 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Type | Length | Reserved | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Lifetime | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | | 1329 : Addresses of IPv6 Recursive DNS Servers : 1330 | | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 Figure 13: ND Recursive DNS Server option format 1335 The Type field identifies must be 25. The Length field specifies the 1336 length of the option (including the Type and Length fields) in units 1337 of 8 octets. The following sanity checks should be performed on the 1338 Length field: 1340 Length >= 3 1342 If the option does not pass this check, it should be ignored. 1344 This sanity check requires a RDNSS option to contain the IPv6 address 1345 of at least one Recursive DNS Server. 1347 Additionally, the following sanity check should be performed: 1349 (Length -1) % 2 == 0 1351 If the option does not pass this check, it should be silently 1352 ignored. 1354 As an IPv6 address consists of 16 bytes, each IPv6 address that is 1355 included in the option should increment the minimum option length by 1356 2. 1358 The Reserved field is set to zero by the sender, and must be ignored 1359 by the receiver. The Lifetime field specifies the maximum time in 1360 seconds that a node may use the IPv6 addresses included in the option 1361 for name resolution, with a value of 0 indicating that they can no 1362 longer be used. As specified in [RFC5006], the following sanity 1363 checks should be performed on the Lifetime field: 1365 Lifetime >= 1800 1367 Lifetime <= 3600 1369 [RFC5006] specifies these sanity checks as MaxRtrAdvInterval <= 1370 Lifetime <= 2*MaxRtrAdvInterval. 1372 If the Lifetime field does not pass this check, the option should be 1373 ignored. 1375 Failure to enforce a lower limit on the Lifetime value could allow an 1376 attacker to 'disable' a Recursive DNS Server at a target system, by 1377 forging a Router Advertisement with a RDNSS option that includes the 1378 IPv6 address of such DNS Server, and a Lifetime of 0 (or some other 1379 small value). This would cause the receiving system to remove such 1380 RDNSS address from the list of Recursive DNS Servers. However, it 1381 should be noted that this represents a trade-off of responsiveness 1382 vs. resiliency. 1384 Sanity checks should be performed on the IPv6 addresses that are 1385 included in the RDNSS option. For example, nodes should check that 1386 the IPv6 addresses included in the RDNSS option are not multicast 1387 addresses. If any of the addresses in the RDNSS option does not pass 1388 this check, it should be silently dropped. 1390 Nodes should enforce a limit on the number of IPv6 addresses they 1391 include in the local list of Recursive DNS Servers. An arbitrary 1392 limit could be to allow a maximum of 16 IPv6 addresses in the list of 1393 Recursive DNS Servers. 1395 The value 16 is somewhat arbitrary. It has been chosen to be the 1396 same as the limit on the maximum number of default routes that many 1397 systems (such as OpenBSD 4.2) already enforce. 1399 Failure to enforce limits on the maximum number of Recursive DNS 1400 Servers could probably allow an attacker to exhaust the system memory 1401 by crafting multiple Router Advertisements that advertise a large 1402 number of IPv6 addresses in RDNSS options. 1404 It should also be clear that if an attacker is able to advertise a 1405 malicious Recursive DNS Server to victim nodes, he could perform a 1406 variety of attacks against the victim nodes (DoS, Man-in-the-Middle. 1407 Etc.). 1409 4. Router and Prefix Discovery 1411 4.1. Router Specification 1413 Section 6.2 of [RFC4861] contains the Router specification for Router 1414 and Prefix Discovery. 1416 Section 6.2.6 ('Processing Router Solicitations') of [RFC4861] states 1417 that if a router receives a Router Solicitation message, and 'the 1418 router already has a Neighbor Cache entry for the solicitation's 1419 sender, the solicitation contains a Source Link-Layer Address option, 1420 and the received link-layer address differs from that already in the 1421 cache, then the link-layer address SHOULD be updated in the 1422 appropriate Neighbor Cache entry'. As a result, an attacker might 1423 forge a Router solicitation message with a forged source link-layer 1424 address, thus causing all traffic meant from the attacked router to 1425 the (forged) Source Address of the Router Advertisement to be sent to 1426 the link-layer address advertised in the forged source link-layer 1427 address option. 1429 Section 6.2.6 of [RFC4861] further states that 'Whether or not a 1430 Source Link-Layer Address option is provided, if a Neighbor Cache 1431 entry for the solicitation's sender exists (or is created) the 1432 entry's IsRouter flag MUST be set to FALSE'. As a result, in a 1433 network scenario in which there are two routers ('A' and 'B') on the 1434 same link, and an attacker is directly attached to that link, an 1435 attacker could send a Router Solicitation to one of the routers 1436 (Router A) forging the Source Address to be that of the other router 1437 (Router B). As a result, the target router (Router A) would set the 1438 IsRouter flag of the Neighbor Cache entry corresponding to the IPv6 1439 address of Router B (the forged Source Address of the Router 1440 Solicitation message) to FALSE, and as a result, Router B would be 1441 eliminated from the Default router list of Router A. 1443 One interesting aspect about this attack is that while some devices 1444 might be filtering e.g. Router Advertisements, they might not be 1445 filtering Router Solicitation messages, and thus this attack might 1446 still be effective. 1448 4.2. Host Specification 1450 Section 6.3.4 of [RFC4861] states that when a Router Advertisement is 1451 received that communicates information for a specific parameter 1452 (e.g., link MTU) that differs from information received in previous 1453 Router Advertisements, the most recently received information is 1454 considered authoritative. 1456 While this requirement guarantees that the relevant information can 1457 be updated in a timely fashion, it also guarantees that an attacker 1458 connected to the local link always has the chance to maliciously 1459 override the values of parameters previously learned from Router 1460 Advertisements. 1462 Section 6.3.4 of [RFC4861] states that 'to limit the storage needed 1463 for the Default Router List, a host MAY choose not to store all of 1464 the router addresses discovered via advertisements'. Here we 1465 strongly advise hosts to enforce a limit on the maximum number of 1466 entries in the Default Router List. A possible (somewhat arbitrary) 1467 limit for the maximum number of entries in the Default Router list 1468 would be 16. 1470 Section 6.3.4 of [RFC4861] states that 'If the received Cur Hop Limit 1471 value is non-zero, the host SHOULD set its CurHopLimit variable to 1472 the received value'. Here we strongly advise that the received Cur 1473 Hop Limit is sanitized as described in Section 3.2 of this document. 1475 Section 6.3.4 of [RFC4861] states that 'The RetransTimer variable 1476 SHOULD be copied from the Retrans Timer field, if the received value 1477 is non-zero'. Here we strongly advise that the received Retrans 1478 Timer is sanitized as described in Section 3.2 of this document. 1480 Honouring very small Retrans Timer values could lead the system to 1481 flood the network with Neighbor Advertisements. 1483 With respect to the processing of received MTU options, Section 6.3.4 1484 of [RFC4861] correctly states that the received option should be 1485 honoured as long as the received value is within the expected limits. 1486 Section 3.6.6 of this document discusses a number of checks that 1487 should be performed on received MTU options. 1489 Section 6.3.4 of [RFC4861] states that 'The only way to cancel a 1490 previous on-link indication is to advertise that prefix with the 1491 L-bit set and the Lifetime set to zero'. This means that if an 1492 attacker forges a Router Advertisement that advertises a 'victim' 1493 prefix as being on-link, such prefix will usually be considered 'on- 1494 link' for the advertised Lifetime period of time ('forever' if 1495 Lifetime was set to 0xffffffff). 1497 5. Address Resolution 1499 In the case of broadcast link-layer technologies, in order for a 1500 system to transfer an IPv6 datagram, it must first map an IPv6 1501 address to the corresponding link-layer address via Neighbor 1502 Solicitation/Advertisement messages. 1504 While this operation is being performed, the packets that require 1505 such a mapping would need to be kept in memory. This may happen both 1506 in the case of hosts and in the case of routers. 1508 The possible implementation approach of keeping those datagrams in 1509 memory while the mapping operation is being performed is mentioned in 1510 Section 5.2 of [RFC4861]. 1512 This situation might be exploited by an attacker to perform a Denial- 1513 of-Service (DoS) attack against an IPv6 router, by sending a large 1514 number of packets to a non-existent node that would supposedly be a 1515 neighbor to the attacked router. While trying to map the 1516 corresponding IPv6 address into a link-layer address, the attacked 1517 router would keep in memory all the packets that would depend on that 1518 address resolution operation in order to be forwarded to the intended 1519 destination. At the point in which the mapping function times out, 1520 the node would typically drop all the packets that were queued 1521 waiting for that address resolution operation to complete. 1523 Depending on the timeout value for the mapping function this 1524 situation might result in the attacked router running out of memory, 1525 with the consequence that incoming legitimate packets would have to 1526 be dropped, or that legitimate packets already stored in the router's 1527 memory buffers might need to be dropped. Both of these situations 1528 would lead either to a complete Denial of Service or to a degradation 1529 of the network service. 1531 A number of countermeasures are warranted for this vulnerability: 1533 Firstly, nodes should enforce a limit on the maximum number of 1534 packets that are queued for the same destination address while the 1535 corresponding address resolution operation is being performed. 1536 Additionally, nodes should enforce a limit on the aggregate number of 1537 packets that are queued waiting for address resolution operations to 1538 complete. 1540 At the point the mapping function times out, all the packets destined 1541 to the address that timed out should be discarded. In addition, a 1542 'negative cache entry' might be kept in the module performing the 1543 matching function, so that for some amount of time the mapping 1544 function would return an error when the IPv6 module requests 1545 resolution of some IPv6 address for which the mapping has recently 1546 failed (i.e., timed out). 1548 A proactive mitigation for this vulnerability would be that when a 1549 packet is received that requires an address resolution operation 1550 before the packet can be forwarded, the packet is dropped and the 1551 router is then engaged in the address resolution operation. 1553 This is a common implementation strategy for IPv4 routers. In IPv4, 1554 it is common that when a packet is received that requires an ARP 1555 request to be performed (before the packet can be forwarded), the 1556 packet is dropped and the router is then engaged in the ARP 1557 procedure. 1559 While similar issues exist in IPv4 networks, this problem is 1560 exacerbated in IPv6, as IPv6 subnets are typically much larger than 1561 their IPv4 counterparts. Therefore, an attacker could send a large 1562 number of packets, each destined to different IPv6 addresses 1563 corresponding to non-existent 'neighbor nodes' of the attacked 1564 router. In the event that the router implementation drops packets 1565 only when the address resolution operation times out, the DoS 1566 condition might persist, whereas it would have probably disappeared 1567 if all the malicious packets had been destined to the same IPv6 1568 address. 1570 That is, if all the attack packets had been destined to the same IPv6 1571 address, the timeout of the address resolution operation for that 1572 IPv6 address could have resulted in all the attack packets to be 1573 dropped. 1575 An attacker could also potentially perform a Denial-of-Service attack 1576 against a router by exhausting the number of entries in the Neighbor 1577 cache and/or the Destination cache. In order to perform this attack, 1578 an attacker would send a large number of packets, each destined to 1579 different IPv6 addresses corresponding to non-existent 'neighbor 1580 nodes' of the attacked router. Each of these attack packets would 1581 trigger an address-resolution operation at the attacked router. If 1582 the target router does not enforce any limits on the maximum number 1583 of entries in the Neighbor cache, this attack could result in a 1584 buffer overflow at the attacked router. On the other hand, if the 1585 router does enforce limits on the maximum number of entries in the 1586 neighbor cache, the packets sent by the attacker could result in the 1587 attacked router hitting the aforementioned limit, probably preventing 1588 legitimate entries to be added to the Neighbor cache, resulting in a 1589 Denial of Service to the corresponding nodes. 1591 This situation has been experienced in production networks probably 1592 as a result of reconnaissance activity by attackers. That is, this 1593 situation could not only indicate a deliberate Denial-of-Service 1594 attack against a router, but could also be side-effect of network 1595 reconnaissance (i.e., 'scanning') activities. 1597 A number of mitigations are warranted for this vulnerability: 1599 o Nodes should enforce a limit on the number of entries in the 1600 Neighbor cache. 1602 o Nodes should implement an algorithm to reclaim Neighbor Cache 1603 entries when the limit on the number of entries is reached. 1605 o Nodes should enforce a limit on the number of entries in the 1606 Neighbor Cache that have a reachability state of 'INCOMPLETE'. 1607 This limit should be much stricter than the general limit on the 1608 number of entries in the Neighbor Cache. 1610 o Nodes should enforce a limit on the number of entries in the 1611 Destination cache. 1613 o Nodes should implement an algorithm to reclaim Destination Cache 1614 entries when the limit on the maximum number of entries is 1615 reached. 1617 Section 5.3 of [RFC4861] states that for the purpose of eliminating 1618 unused entries (i.e., garbage-collection) in the Neighbor cache, any 1619 Least Recently Used (LRU)-based policy that only reclaims entries 1620 that have not been used in some time should be adequate. Such LRU- 1621 based policy should also be enforced to reclaim entries in the 1622 Neighbor cache or the Destination Cache when the limit on the maximum 1623 number of entries is hit for the Neighbor cache or the Destination 1624 cache, respectively. 1626 5.1. Interface initialization 1628 As explained in Section 7.2.1 of [RFC4861], when a multicast-capable 1629 interface is enabled, the node must join the all-nodes multicast 1630 group on that interface, and the solicited-node multicast address 1631 corresponding to each of the addresses assigned to an interface. As 1632 discussed in the same section, nodes join and leave the solicited- 1633 node groups as the assigned addresses change over time. 1635 As the solicited-node multicast address for a number of assigned 1636 addresses might be the same, nodes should ensure that a solicited- 1637 node multicast group is not left until all the addresses 1638 corresponding to that solicited-node group have been removed. 1640 An implementation that incorrectly leaves a solicited-node multicast 1641 group while there are addresses corresponding to that multicast group 1642 still in use might be subject of a Denial-of-Service attack (from a 1643 malicious node attached to the same link as the victim). 1645 In order to perform such an attack, an attacker would first send an 1646 unsolicited Router Advertisement, announcing a prefix such that the 1647 victim node configures an address whose solicited-node multicast 1648 group is the same as some legitimately-configured address. The 1649 advertised prefix would have a Lifetime value that would cause the 1650 address to be removed in the short term. If the Neighbor Discovery 1651 implementation of the victim system does not ensure that a solicited- 1652 node multicast group is left only when the last address corresponding 1653 to that solicited-node multicast group is removed, the victim might 1654 incorrectly leave the aforementioned solicited-node multicast group. 1655 As a result, the victim system would be unable to respond to Neighbor 1656 Solicitation messages for the target address, and therefore the 1657 aforementioned address would become unreachable. 1659 5.2. Receipt of Neighbor Solicitation messages 1661 As stated in Section 7.2.3, if a Neighbor Solicitation is received 1662 and an entry already exists in the Neighbor Cache for the IPv6 Source 1663 Address of the solicitation with a cached link-layer address that is 1664 different from the one in the received Source Link-Layer option, the 1665 cached address should be replaced by the received address (and the 1666 entry's reachability state must be set to STALE). 1668 If an entry does not exist for the corresponding Target Address, a 1669 new entry is added to the Neighbor Cache, and its reachability state 1670 is set to STALE. 1672 While this allows for improved responsiveness in the event the link- 1673 layer address corresponding to an IPv6 address changes, it also means 1674 that an attacker could easily override the mapping from IPv6 address 1675 to link-layer address. 1677 An attacker attached to the same link as the victim system could 1678 craft a Neighbor Solicitation message with a forged IPv6 Source 1679 Address, and send it to the victim system, thus illegitimately 1680 causing the victim to update its Neighbor Cache. The attacker could 1681 then send a Neighbor Advertisement with the Solicited flag set, thus 1682 causing the reachability state of the neighbor cache entry to be set 1683 to REACHABLE. 1685 As a result, the attacker could cause traffic meant from the victim 1686 to the forged IPv6 address to be directed to any local system (i.e., 1687 attached to the same network link). 1689 6. Vulnerability analysis 1691 This section summarizes the security implications that arise from the 1692 Neighbor Discovery mechanisms in IPv6. The following vulnerabilities 1693 have been identified: 1695 o Denial of Service: communication is prevented between legitimate 1696 nodes 1698 o Performance-degrading: the performance of communication between 1699 legitimate nodes is reduced 1701 o Traffic hijacking: traffic is illegitimately redirected to a node 1702 operated by an attacker 1704 [RFC3756] provides a good security assessment of the Neighbor 1705 Discovery mechanisms. The following subs-sections summarize the 1706 results in [RFC3756], and also identify new vulnerabilities and 1707 specific attack vectors not present in that document. 1709 Some of the vulnerabilities discussed in the following sub-sections 1710 involve an attacker sending Router Advertisement messages. [RFC6104] 1711 analyzes the problem of Rogue IPv6 Router Advertisements, and discuss 1712 a number of possible solutions. [RFC6105] discusses a specific 1713 solution to this problem based on layer-2 filtering, known as 'RA- 1714 Guard'. However, as discussed in 1715 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 1716 implementations can be easily circumvented by leveraging IPv6 1717 extension headers. 1719 [THC-IPv6] includes 'proof of concept' tools of some of the 1720 vulnerabilities discussed in the following subsections. 1721 [vanHauser2006] is a presentation about this tool set. 1723 [Beck2007b] analyzes the use of Neighbor Discovery for Operating 1724 System detection. However, the results seem to indicate that 1725 Neighbor Discovery is not an attractive means for Operating System 1726 detection when compared to other techniques such as those described 1727 in [CPNI-TCP]. Therefore, the 'information leakage' resulting from 1728 Neighbor Discovery, while possible, is not included in the threat 1729 analysis present in the following subsections. 1731 6.1. Denial of Service 1733 6.1.1. Neighbor Cache poisoning 1735 Router Solicitation, Router Advertisement, Neighbor Solicitation and 1736 Neighbor Advertisement messages can be exploited to maliciously 1737 poison the Neighbor Cache of a victim node such that an IPv6 address 1738 maps into a non-existent link-layer address. As a result, traffic 1739 meant to the victim address would be 'black-holed' as a result of 1740 sending it to a non-existent link-layer address. 1742 In the case of Router Solicitation, Router Advertisement, and 1743 Neighbor Solicitation messages, a source link-layer address would be 1744 employed. In the case of Neighbor Advertisement messages, a target 1745 link-layer address would be used instead. 1747 In order for an attacker to successfully perform this attack, he 1748 would need to be attached to the same network link to which the 1749 target node is attached, or control a node attached to that network 1750 link (e.g., compromise such a node). However, it could be possible 1751 that as a result of tunnelling mechanisms, an attacker could perform 1752 these attacks remotely. 1754 This attack could be mitigated by not overwriting the link-layer 1755 address of an existing Neighbor Cache entry when a source link-layer 1756 address option or a target link-layer address option is received. 1757 The mapping of IPv6 address to link-layer address would be updated 1758 only if Neighbor Unreachability Detection (NUD) first removes the 1759 corresponding Neighbor Cache entry, and then a Neighbor Discovery 1760 message updates the mapping. 1762 Furthermore, some monitoring tools exist that detect some possible 1763 exploitation of Neighbor Discovery and Neighbor Advertisement 1764 messages. NDPMon [NDPMon] is an example of such a monitoring tool 1765 (which is similar to the IPv4 arpwatch tool [arpwatch]). [Beck2007] 1766 is a paper about the aforementioned tool. 1768 6.1.2. Tampering with Duplicate Address Detection (DAD) 1770 The Duplicate Address Detection (DAD) mechanism is used to ensure 1771 that a node does configure for itself an address that is already in 1772 use. 1774 An attacker could simply listen to Neighbor Solicitations sent as 1775 part of the DAD mechanism, and respond with crafted Neighbor 1776 Advertisements, thus causing the victim node to consider the address 1777 to be already in use, and thus preventing it from configuring the 1778 address for future use. 1780 Additionally, an attacker could respond to Neighbor Solicitations 1781 sent as part of the DAD mechanism with a Neighbor Solicitation for 1782 the same IPv6 address. The legitimate node performing DAD would 1783 consider this a collision and would cease to solicit that address 1784 (and possibly select and perform DAD for some alternative address). 1786 In order for an attacker to successfully perform this attack, he 1787 would need to be attached to the same network link on which the 1788 attack is to be launched, or control a node attached to that network 1789 link (e.g., compromise such a node). 1791 Layer-2 switches could filter Neighbor Advertisement messages based 1792 on previous knowledge of the link-layer addresses recently in use at 1793 each port. 1795 6.1.3. Tampering with Neighbor Unreachability Detection (NUD) 1797 The Neighbor Unreachability Detection (NUD) mechanism is used to 1798 detect unreachable neighbors and cause the corresponding entries in 1799 the Neighbor Cache to be eliminated. When an unreachable neighbor is 1800 detected and the corresponding Neighbor Cache entry is removed, a 1801 node has the chance to e.g., perform next-hop determination. 1803 In order for a neighbor to be considered reachable, NUD uses 1804 reachability indications from upper-layer protocols. In the absence 1805 of reachability indications from an upper layer (e.g., from TCP's 1806 Acknowledgements), NUD employs solicited unicast Neighbor 1807 Solicitations to confirm the reachability of a Neighbor. 1809 An attacker could snoop traffic and respond to the solicited Neighbor 1810 Solicitation messages being used for the purpose of NUD, thus 1811 preventing victim nodes from detecting that the impersonated node is 1812 unreachable. As a result, those 'victim' nodes would continue 1813 sending packets to the unreachable node, instead of e.g., performing 1814 first-hop determination to find an alternative working router. 1816 In order for an attacker to successfully perform this attack, he 1817 would need to be attached to the same network link on which the 1818 attack is to be launched, or control a node attached to that network 1819 link (e.g., compromise such a node). 1821 Nodes could require the link-layer source address of solicited 1822 Neighbor Advertisements being employed for NUD to be the same as that 1823 stored in the Neighbor Cache entry for which NUD is being performed. 1824 With this requirement in place, layer-2 switches could filter 1825 Neighbor Advertisement messages according to their source link-layer 1826 address, based on previous knowledge of the link-layer addresses 1827 recently in use at each port. 1829 It should be noted that this recommendation should not be enforced in 1830 more complex networks in which VRRP [RFC5798] or custom redundancy 1831 protocols are employed. 1833 This would mitigate the tampering with NUD that employs Neighbor 1834 Advertisement messages. However, it should be noted that an attacker 1835 might still tamper with NUD by forging upper-layer packets such as 1836 TCP Acknowledgements. 1838 6.1.4. Rogue Router 1840 An attacker could either send unsolicited Router Advertisements 1841 and/or illegitimately respond to Router Solicitations, advertising a 1842 non-existent system as a default router. 1844 As a result, hosts honouring the aforementioned Router Advertisements 1845 would use the advertised rogue router as a default router, and as a 1846 result their packets would be black-holed. 1848 In order for an attacker to successfully perform this attack, he 1849 would need to be attached to the same network link on which the 1850 attack is to be launched, or control a node attached to that network 1851 link (e.g., compromise such a node). As described in [RFC3756], this 1852 vulnerability could be mitigated by preferring existing routers over 1853 new ones. 1855 Additionally, layer-2 switches could possibly allow Router 1856 Advertisements messages to be sent only from specific ports. 1858 [RFC6104] analyzes the problem of Rogue IPv6 Router Advertisements, 1859 and discusses a number of possible solutions. [RFC6105] discusses a 1860 specific solution to this problem based on layer-2 filtering, known 1861 as 'RA-Guard'. However, as discussed in 1862 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 1863 implementations can be easily circumvented by leveraging IPv6 1864 extension headers. 1866 6.1.5. Parameter spoofing 1868 An attacker could either send unsolicited Router Advertisements 1869 and/or illegitimately respond to Router Solicitations, advertising a 1870 legitimate default router, but malicious network parameters. 1872 For example, an attacker could advertise a very small Cur Hop Limit 1873 value, thus causing packets to be discarded before reaching their 1874 intended destination. 1876 An attacker could also advertise an incorrect link MTU (either very 1877 small or very large) possibly preventing packets from being sent on 1878 the corresponding link and/or causing pathological behaviour at the 1879 victim nodes. 1881 Finally, an attacker could either send unsolicited Router 1882 Advertisements and/or illegitimately respond to Router Solicitations, 1883 sending Router Advertisements with the M and/or the O bits set, thus 1884 possibly causing the victim nodes to engage in managed address 1885 configuration when such service is not present (e.g., there is no 1886 DHCP server) or when the attacker operates a malicious DHCP server. 1888 In the former scenario, address configuration would fail, as a result 1889 of the non-existing DHCP server. In the latter scenario, an attacker 1890 could operate a malicious DHCP server to override IPv6's stateless 1891 configuration. 1893 In order for an attacker to successfully perform this attack, he 1894 would need to be attached to the same network link on which the 1895 attack is to be launched, or control a node attached to that network 1896 link (e.g., compromise such a node). 1898 As with other attacks based on Router Advertisement messages, they 1899 could be mitigated if Layer-2 switches allow Router Advertisements 1900 messages to be sent only from specific ports. 1902 6.1.6. Bogus on-link prefixes 1904 An attacker could either send unsolicited Router Advertisements 1905 and/or illegitimately respond to Router Solicitations, advertising 1906 bogus prefixes for on-link determination. 1908 As a result, nodes belonging to the aforementioned prefixes would be 1909 considered on-link, and packets destined to them would not be relayed 1910 to a first-hop router. As a result, the victim nodes (i.e., those 1911 receiving the crafted Router Advertisements) would perform Neighbor 1912 Discovery for the intended destination, and when ND failed, the 1913 packets would be discarded. 1915 In order for an attacker to successfully perform this attack, he 1916 would need to be attached to the same network-link on which the 1917 attack is to be launched, or control a node attached to that network 1918 link (e.g., compromise such a node). 1920 As mentioned in [RFC3756] host implementations could mitigate the 1921 impact of this attack by requiring the advertised prefixes to be at 1922 least /64s. 1924 This would prevent an attacker from affecting a much larger portion 1925 of the IPv6 address space by e.g. sending a Router Advertisement that 1926 advertises the prefix ::/0 to be 'on-link'. 1928 As with other attacks based on Router Advertisement messages, they 1929 could be mitigated if Layer-2 switches allow Router Advertisements 1930 messages to be sent only from specific ports. 1932 6.1.7. Bogus address configuration prefixes 1934 An attacker could either send unsolicited Router Advertisements 1935 and/or illegitimately respond to Router Solicitations, illegitimately 1936 advertising IPv6 prefixes for stateless address auto-configuration 1937 (SLAAC). This prefixes could either be bogon prefixes or prefixes 1938 owned by a remote site. An attacker could cause victim systems to 1939 configure IPv6 addresses using prefixes that would cause the 1940 resulting traffic to be black-holed. 1942 This would cause the receiving nodes to configure their addresses 1943 with those bogus prefixes, and as a result, the resulting traffic 1944 would possibly be filtered by the network (e.g., if network egress- 1945 filtering is in place). Even if the outgoing packets were not 1946 filtered, these victim systems would not receive the return traffic, 1947 as the return traffic would either be filtered (in the case of bogon 1948 prefixes) or delivered to the legitimate destination (in the case of 1949 prefixes owned by some other party). 1951 In order for an attacker to successfully perform this attack, he 1952 would need to be attached to the same network-link on which the 1953 attack is to be launched, or control a node attached to that network 1954 link (e.g., compromise such a node). 1956 As with other attacks based on Router Advertisement messages, they 1957 could be mitigated if Layer-2 switches allow Router Advertisements 1958 messages to be sent only from specific ports. 1960 6.1.8. Disabling routers 1962 An attacker could send crafted Router Advertisements, Neighbor 1963 Advertisements, or Router Solicitations to cause the receiving nodes 1964 to remove the impersonated router from the router list. 1966 In current implementations, if there are no default routers, a packet 1967 destined to an off-link node will elicit an ICMPv6 Destination 1968 Unreachable error message. In the case of legacy implementations 1969 compliant with [RFC2461], if there are no default routers, the 1970 Destination Address would be assumed to be 'on-link', and the victim 1971 would perform Neighbor Discovery for the destination address in the 1972 hope of delivering the packet on the local link. 1974 In the case of the Router Advertisements vector, an attacker would 1975 send unsolicited Router Advertisements with a Preferred Lifetime 1976 equal to 0 or to some other small value, thus causing the receiving 1977 nodes to remove the impersonated router from the default router list. 1979 Alternatively, an attacker could send forged Neighbor Advertisements 1980 (either solicited or unsolicited) with the Router flag set to 0, thus 1981 causing the impersonated router to be removed from the default router 1982 list. 1984 Receiving nodes would assume the impersonated router has ceased to be 1985 a router and has changed to functioning only as a host. 1987 As a third option, an attacker could send a forged Router 1988 Solicitation message to a router on the local network link, to cause 1989 the victim to remove the impersonated router from the router list. 1990 This attack vector is discussed in more detail in Section 4.1. 1992 In order for an attacker to successfully perform this attack, he 1993 would need to be attached to the same network link on which the 1994 attack is to be launched, or control a node attached to that network 1995 link (e.g., compromise such a node). 1997 Some IPv6 networks employ the 'RA-Guard' mechanism specified in 1998 [RFC6105] as the first line of defence against RA-based attack 1999 vectors. However, However, as discussed in 2000 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 2001 implementations can be easily circumvented by leveraging IPv6 2002 extension headers. 2004 The rest of the attack vectors discussed in this section could 2005 possibly be mitigated with a more advanced Layer-2 filtering. 2007 6.1.9. Tampering with 'on-link determination' 2009 Section 2.1 of [RFC4861] states that a node considers an address to 2010 be on-link if: 2012 o it is covered by one of the link's prefixes (e.g., as indicated by 2013 the on-link flag in the Prefix Information option), or 2015 o a neighbouring router specifies the address as the target of a 2016 Redirect message, or 2018 o a Neighbor Advertisement message is received for the (target) 2019 address, or 2021 o any Neighbor Discovery message is received from the address. 2023 As a result, some implementations create a Destination Cache entry 2024 for the Source Address of a Neighbor Discovery message (or for the 2025 Target Address of a Neighbor Advertisement message) when such a 2026 message is received, and mark the aforementioned address as 'on- 2027 link'. 2029 This means in all traffic meant to the forged address will be 2030 delivered to the node identified in the corresponding Neighbor Cache 2031 entry (as the node will be considered to be on-link). If the 2032 corresponding Neighbor Cache entry maps the forged address into a 2033 non-existent or malicious node, all traffic can be black-holed, thus 2034 leading to a DoS scenario. 2036 [RFC5942] updates [RFC4861], removing the third and fourth bullets in 2037 the above list. This means that receipt of ND messages must not 2038 result in the Source Address of the ND message or the Target Address 2039 of a Neighbor Advertisement message to be considered on-link (e.g., 2040 by modifying the Prefix List or by marking the corresponding 2041 Destination Cache entry as 'on-link'). 2043 [CVE-2008-2476] and [US-CERT2008] are vulnerability advisories 2044 about this issue. 2046 Some IPv6 networks employ the 'RA-Guard' mechanism specified in 2047 [RFC6105] as the first line of defence against RA-based attack 2048 vectors. However, as discussed in 2049 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 2050 implementations can be easily circumvented by leveraging IPv6 2051 extension headers as shown in [CVE-2011-2395]. 2053 The rest of the attack vectors discussed in this section could 2054 possibly be mitigated with a more advanced Layer-2 filtering. 2056 6.1.10. Introducing forwarding loops at routers 2058 As discussed in Section 3.6.2 of this document, if broadcast or 2059 multicast addresses were allowed in source link-layer address options 2060 or in target link-layer address options, traffic directed to a victim 2061 IPv6 address would be sent to such broadcast or multicast IPv6 2062 address. 2064 Consider the following network scenario: 2066 +----------+ +--------+ +----------+ 2067 | Router A | | Host C | | Router B | 2068 +----------+ +--------+ +----------+ 2069 || || || 2070 ================================================= 2071 || 2072 || 2073 +----------+ 2074 | Attacker | 2075 +----------+ 2077 Figure 14: Example network scenario for forwarding loop 2079 An attacker could poison the neighbor cache of Router A and the 2080 neighbor cache of Router B, such that the IPv6 address of Host C maps 2081 to the Ethernet broadcast address (ff:ff:ff:ff:ff:ff). Afterwards, 2082 he could send a packet to the Ethernet broadcast address (ff:ff:ff: 2083 ff:ff:ff), with an IPv6 Destination Address equal to the IPv6 address 2084 of Host C. Upon receiving the packet, both Router A and Router C 2085 would decrement the Hop Limit of the packet, and would resend it to 2086 the Ethernet broadcast address. As a result, both Router A and 2087 Router B would now receive two copies of the same packet (one sent by 2088 Router A, and another sent by Router B). This would result in a 2089 'chain reaction' that would only disappear when the Hop Limit of each 2090 of the packets is decremented to 0. The total number of packets, for 2091 a general scenario in which multiple routers are present on the link 2092 and are subject of the aforementioned neighbor cache poisoning 2093 attack, and the attacker sends the initial attack packet with an 2094 arbitrary Hop Limit (possibly 255 to get the maximum amplification 2095 factor) is: 2097 HopLimit-1 2098 --- 2099 \ x 2100 Packets = / Routers 2101 --- 2102 x=0 2104 Figure 15: Maximum amplification factor 2106 This equation does not take into account neither the possible ICMPv6 2107 Redirect messages that each of the Routers could send, nor the 2108 possible ICMPv6 'time exceeded in transit' error messages that each 2109 of the routers could possibly send to the Source Address of the 2110 packet when each of the 'copies' of the original packet is discarded 2111 as a result of their Hop Limit being decremented to 0. 2113 As discussed in Section 3.6.2 of this document, neither broadcast nor 2114 multicast addresses should be allowed in source link-layer address 2115 and target link-layer address options. An additional mitigation 2116 would be for routers to not forward IPv6 packets on the same 2117 interface if the link-layer destination address of the packet was a 2118 broadcast or multicast address. 2120 It is also possible to introduce a forwarding loop at a router by 2121 poisoning its neighbor cache such that a victim IPv6 address 2122 (considered to be on-link) maps to one of the attacked router's link- 2123 layer addresses. An attacker could poison the neighbor cache of the 2124 target router as described, and then send a packet to the attacked 2125 router with the IPv6 Destination Address set to the victim address. 2126 Upon receipt of the packet, the router would decrement the Hop Limit, 2127 and 'forward' the packet to its own link-layer address. This would 2128 result in a loop, with the target router processing the packet 'Hop 2129 Limit' times (where 'Hop Limit' is the value used for the Hop Limit 2130 field of the original packet). 2132 6.1.11. Tampering with a Neighbor Discovery implementation 2134 The Neighbor Discovery specification describes conceptual data 2135 structures such as the Neighbor Cache and the Destination Cache, 2136 which grow as a result of each entry that is created. Additionally, 2137 there are other structures such as the list of configured IPv6 2138 addresses, the list of Recursive DNS Servers, etc., that also grow 2139 for each entry that is created in them. 2141 As discussed throughout Section 5 of this document, an implementation 2142 should enforce limits on the maximum number of entries in these 2143 structures. Failure in enforcing such limits could result in buffer 2144 overflows or memory exhaustion. 2146 FreeBSD 9.0 and NetBSD 5.1 fail to enforce limits on the number of 2147 entries in the IPv6 routing table, on the number of entries in the 2148 Neighbor Cache, on the number of entries in the Default Router 2149 List, and on the number of configured IPv6 addresses. Therefore 2150 they are vulnerable to multiple Denial of Service attacks. 2152 All Windows versions that support IPv6 (XP to current Server 2012) 2153 fail to enforce limits on the number of entries in the IPv6 2154 routing table, on the maximum number of configured addresses, and 2155 on the number of entries in the Neighbor Cache. Therefore, these 2156 structures could be exploited for performing a Denial of Service 2157 attack. 2159 Linux 2.6.38-10 does enforce a limit on the number of entries in 2160 the Default router list. However, this limit itself could be 2161 leveraged for performing a Denial of Service attack, by causing 2162 the Default router list to become full of malicious/spurious 2163 entries before a legitimate entry can be added. As a result, the 2164 system would be unable to configure a legitimate default router, 2165 even if a legitimate Router Advertisement is received at some 2166 point later. 2168 An attacker attached to the same network link as the target node can 2169 stress most of these data structures by sending a large number of the 2170 appropriate Neighbor Discovery options (e.g., RDNSS or Prefix 2171 Information options in Router Advertisement messages, etc.) as has 2172 been shown by e.g. [CVE-2010-4669]. 2174 Other structures (such as the Neighbor Cache or the Destination 2175 Cache) can be stressed by sending packets with forged addresses to 2176 the target node. For example, an attacker could send any packets 2177 that would elicit a response from the destination system with forged 2178 IPv6 Source Address that is assumed to be 'on-link' by the target 2179 system. In order for the target node to respond to those packets, it 2180 would have to create the necessary entries in the Destination Cache 2181 and in the Neighbor Cache. If the target implementation does not 2182 enforce limits on the maximum number of entries in each of those data 2183 structures, the attack may result in buffer overflows or kernel 2184 system memory exhaustion. 2186 It is interesting to note that this attack vector could also be 2187 exploited by an attacker located in a remote site, unless ingress 2188 and/or egress filtering are in place. 2190 [NISCC2006b] discusses ingress and egress filtering. 2192 6.1.12. Tampering with a Neighbor Discovery router implementation from 2193 a remote site 2195 A remote attacker could potentially perform a Denial-of-Service (DoS) 2196 attack against a router by sending packets to different IPv6 2197 addresses considered on-link at one of the network links to which the 2198 target router is attached. Each of these packets would engage the 2199 target router in neighbor discovery for each of those addresses, 2200 probably preventing the router from performing neighbor discovery for 2201 legitimate packets aimed at existing nodes. 2203 This problem would be exacerbated if an implementation queues in 2204 memory those packets that are destined to an IPv6 address for which 2205 address resolution is being performed. See Section 5 of this 2206 document for a thorough description of this issue. 2208 One important difference between this attack vector and the ones 2209 described in the previous subsections is that in order for an 2210 attacker to successfully perform this attack, he does not need to be 2211 attached to the same network link to which the target router is 2212 attached. 2214 A possible mitigation for this attack would be to enforce a limit on 2215 the maximum number of entries in the Neighbor Cache that are in the 2216 'INCOMPLETE' state. This limit should be stricter than the overall 2217 limit on the maximum number of entries in the Neighbor Cache. 2219 A Neighbor Cache entry is in the 'INCOMPLETE' state if a Neighbor 2220 Advertisement message has never been received for the corresponding 2221 IPv6 address since the entry was created. 2223 It should be noted that this is an implementation issue rather than a 2224 protocol-based vulnerability. However, a number of implementations 2225 have been found to be vulnerable to this attack. 2227 It is also worth noting that this attack does not require an attacker 2228 to forge the IPv6 Source Address of the 'malicious' packets. 2229 Therefore, mechanisms such as 'ingress filtering' do not provide any 2230 mitigation for this attack. 2232 Section 6.1.11 describes another attack vector for stressing the 2233 Neighbor Cache (and the Destination cache) of both host and router 2234 implementations. 2236 6.2. Performance degrading 2238 6.2.1. Parameter spoofing 2240 An attacker could either send unsolicited Router Advertisements 2241 and/or illegitimately respond to Router Solicitations, advertising a 2242 legitimate default router, but malicious network parameters. 2244 An attacker could also advertise a small link MTU causing the victim 2245 nodes to enforce such a small MTU for the corresponding network link. 2246 This would increase the overhead (headers/data ratio), and possibly 2247 result in a packet-rate increase (if the same throughput is to be 2248 maintained). Additionally, this might also require the use of IPv6 2249 fragmentation when data are to be transferred across this network 2250 link. This is a moderate version of the Denial-of-Service (DoS) 2251 attack discussed in Section 6.1.5 of this document. 2253 In order for an attacker to successfully perform this attack, he 2254 would need to be attached to the same network link on which the 2255 attack is to be launched, or control a node attached to that network 2256 link (e.g., compromise such a node). 2258 Some IPv6 networks employ the 'RA-Guard' mechanism specified in 2259 [RFC6105] as the first line of defence against RA-based attack 2260 vectors. However, However, as discussed in 2261 [I-D.ietf-v6ops-ra-guard-implementation], some popular RA-Guard 2262 implementations can be easily circumvented by leveraging IPv6 2263 extension headers. 2265 6.3. Traffic hijacking 2267 6.3.1. Neighbor Cache poisoning 2269 Neighbor Solicitation and Neighbor Advertisement messages can be 2270 exploited to maliciously poison the Neighbor Cache of a target node 2271 such that an IPv6 address maps into the link-layer address of a 2272 malicious node operated by an attacker. As a result, once the 2273 victim's Neighbor Cache is poisoned, the attacker would receive all 2274 traffic aimed at the victim node. 2276 This is similar to the Denial-of-Service (DoS) attack described in 2277 Section 6.1.1 of this document, with the only difference being that 2278 in this case traffic would be directed to a node operated by the 2279 attacker, rather than to a non-existent node. 2281 In order for an attacker to successfully perform this attack, he 2282 would need to be attached to the same network link on which the 2283 attack is to be launched, or control a node attached to that network 2284 link (e.g., compromise such a node). 2286 An attacker could also poison the Neighbor Cache of a target node 2287 mapping a victim IPv6 address to a multicast or broadcast link-layer 2288 address, such that he can receive a copy of those packets sent by the 2289 attacked node to the victim node. This specific attack vector is 2290 thoroughly discussed in Section 3.6.2 of this document. 2292 The same mitigation techniques as described in Section 6.1.1 of this 2293 document apply to this attack-vector. 2295 6.3.2. Rogue Router 2297 An attacker could either send unsolicited Router Advertisements 2298 and/or illegitimately respond to Router Solicitations, advertising 2299 his own node as a default router. 2301 This is similar to the Denial-of-Service (DoS) attack described in 2302 Section 6.1.4, with the only difference that in this case traffic 2303 would be directed to a node operated by the attacker, rather than to 2304 a non-existing node. 2306 In order for an attacker to successfully perform this attack, he 2307 would need to be attached to the same network link on which the 2308 attack is to be launched, or control a node attached to that network 2309 link (e.g., compromise such a node). 2311 The same mitigation techniques as described in Section 6.1.4 apply to 2312 this attack vector. 2314 6.3.3. Bogus on-link prefixes 2316 An attacker could either send unsolicited Router Advertisements 2317 and/or illegitimately respond to Router Solicitations, advertising 2318 bogus prefixes for on-link determination. 2320 As a result, nodes belonging to the aforementioned prefixes would be 2321 considered on-link, and packets destined to them would not be relayed 2322 to a first-hop router, but would instead be delivered on the local 2323 link. The victim nodes (i.e., those receiving the crafted Router 2324 Advertisements) would perform Neighbor Discovery for the intended 2325 destination, and the attacker could then respond with Neighbor 2326 Advertisements that advertise the link-layer address of his node, so 2327 that packets are finally delivered to his malicious node. 2329 In order for an attacker to successfully perform this attack, he 2330 would need to be attached to the same network link on which the 2331 attack is to be launched, or control a node attached to that network 2332 link (e.g., compromise such a node). 2334 The same mitigation techniques as described in Section 6.1.6 apply to 2335 this attack vector. 2337 6.3.4. Tampering with 'on-link determination' 2339 This attack is similar to the Denial-of-Service (DoS) attack 2340 described in Section 6.1.10, with the only difference that for the 2341 purpose of traffic-hijacking, an attacker would make sure that the 2342 cached link-layer address of the Neighbor Cache entry corresponding 2343 to the victim address (the Source Address of the forged Neighbor 2344 Discovery message or the forged Target Address of the forged Neighbor 2345 Advertisement message) corresponds to the link-layer address of a 2346 node operated by the attacker. 2348 As discussed in Section 6.1.9, [RFC5942] updates [RFC4861], such that 2349 this attack vector is eliminated. The same mitigations discussed in 2350 Section 6.1.9 of this document apply to mitigate this vulnerabilty. 2352 [CVE-2008-2476] and [US-CERT2008] are vulnerability advisories 2353 about this issue. 2355 6.4. Miscellaneous security issues 2357 6.4.1. Detecting Sniffing Hosts 2359 If a system reacts differently depending on whether the network 2360 interface is in promiscuous mode, this can be leveraged by an 2361 attacker that is on-link to infer whether the target node is in 2362 promiscuous mode. Such a security issue has been found on many 2363 operating systems, where a packet with a multicast MAC address that 2364 is not being listened on by that target will be processed only if the 2365 receiving node is in promiscuous mode (i.e., "sniffing" the network). 2366 This test can be performed with any packet type, e.g. Neighbor 2367 Solicitation or Echo Request. 2369 [CVE-2010-4562] is one vulnerability advisory about such an issue. 2371 7. IANA Considerations 2373 This document has no actions for IANA. 2375 8. Security Considerations 2377 This entire document is about security vulnerabilities that have been 2378 found popular Neighbor Discovery implementations, and other potential 2379 security issues that might be affecting existing implementations. 2380 This document not only discusses the aforementioned issues, but also 2381 provides implementation guidance such that these issues can be 2382 eliminated from the affected implementations and completely avoided 2383 or mitigated in any new Neighbor Discovery implementations. 2385 The ultimate goal of this document is to help improve the overall 2386 maturity of Neighbor Discovery implementations, and to raise 2387 awareness about current security issues that might affect IPv6 2388 networks. 2390 9. Acknowledgements 2392 This document is based on the technical report "Security Assessment 2393 of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by 2394 Fernando Gont on behalf of the UK Centre for the Protection of 2395 National Infrastructure (CPNI). The author would like to thank to 2396 thank (in alphabetical order) Ran Atkinson, Fred Baker, Brian 2397 Carpenter, Roque Gagliano, Guillermo Gont, Alfred Hoenes, Qing Li, 2398 Neil Long, and Pekka Savola, for providing valuable feedback on 2399 earlier versions of such document. Additionally, the author would 2400 like to thank (in alphabetical order) Ran Atkinson, Brian Carpenter, 2401 Joel M. Halpern, Robert Hinden, Pekka Savola, Fred Templin, and Ole 2402 Troan, who generously answered a number of questions when authoring 2403 the aforementioned document. 2405 10. Contributors 2407 Marc Heuse contributed text, edits, comments, and new vulnerabilities 2408 that were incorporated into this document. 2410 11. References 2412 11.1. Normative References 2414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2415 Requirement Levels", BCP 14, RFC 2119, March 1997. 2417 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2418 (IPv6) Specification", RFC 2460, December 1998. 2420 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2421 Networks", RFC 2464, December 1998. 2423 [RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for 2424 Inverse Discovery Specification", RFC 3122, June 2001. 2426 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 2427 Discovery (ND) Trust Models and Threats", RFC 3756, 2428 May 2004. 2430 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 2431 in IPv6", RFC 3775, June 2004. 2433 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2434 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2436 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2437 More-Specific Routes", RFC 4191, November 2005. 2439 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2440 Proxies (ND Proxy)", RFC 4389, April 2006. 2442 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2443 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2444 September 2007. 2446 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2447 Address Autoconfiguration", RFC 4862, September 2007. 2449 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 2450 Discovery On-Link Assumption Considered Harmful", 2451 RFC 4943, September 2007. 2453 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 2454 "IPv6 Router Advertisement Option for DNS Configuration", 2455 RFC 5006, September 2007. 2457 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 2458 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 2460 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 2461 Model: The Relationship between Links and Subnet 2462 Prefixes", RFC 5942, July 2010. 2464 11.2. Informative References 2466 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 2467 Discovery for IP Version 6 (IPv6)", RFC 2461, 2468 December 1998. 2470 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 2471 Problem Statement", RFC 6104, February 2011. 2473 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 2474 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 2475 February 2011. 2477 [I-D.ietf-v6ops-ra-guard-implementation] 2478 Gont, F., "Implementation Advice for IPv6 Router 2479 Advertisement Guard (RA-Guard)", 2480 draft-ietf-v6ops-ra-guard-implementation-07 (work in 2481 progress), November 2012. 2483 [CPNI-IPv6] 2484 Gont, F., "Security Assessment of the Internet Protocol 2485 version 6 (IPv6)", UK Centre for the Protection of 2486 National Infrastructure, (available on request). 2488 [CPNI-TCP] 2489 CPNI, "Security Assessment of the Transmission Control 2490 Protocol (TCP)", 2009, . 2493 [Hogg-Vyncke] 2494 Hogg, S. and E. Vyncke, "IPv6 Security", Cisco Press; 1 2495 edition, 2008. 2497 [Lecigne-Neville-Neil] 2498 Lecigne, C. and G. Neville-Neil, "Walking through FreeBSD 2499 IPv6 stack", 2006, . 2501 [Beck2007] 2502 Beck, F., Cholez, T., Festor, O., and I. Chrisment, 2503 "Monitoring the Neighbor Discovery Protocol", The Second 2504 International Workshop on IPv6 Today - Technology and 2505 Deployment - IPv6TD 2007, . 2508 [Beck2007b] 2509 Beck, F., Festor, O., and I. Chrisment, "IPv6 Neighbor 2510 Discovery Protocol based OS fingerprinting", INRIA 2511 Rapport Technique No 0345, 2007, . 2515 [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", 2516 . 2518 [arpwatch] 2519 LBNL/NRG, "arpwatch tool", 2006, . 2521 [NISCC2006b] 2522 NISCC, "NISCC Technical Note 01/2006: Egress and Ingress 2523 Filtering", 2006, . 2526 [vanHauser2006] 2527 vanHauser, "Attacking the IPv6 Protocol Suite", EuSecWest 2528 2006 Conference, 2529 . 2531 [SI6-Toolkit] 2532 "SI6 Networks' IPv6 toolkit", 2533 . 2535 [THC-IPv6] 2536 "The Hacker's Choice IPv6 Attack Toolkit", 2537 . 2539 [CVE-2012-notyet] 2540 CVE, "CVE-2012-notyet - entry is upcoming ... to be 2541 filled", 2012. 2543 [CVE-2011-2391] 2544 CVE, "CVE-2011-2391 - IPv6 Neighbor Discovery Protocol 2545 (NDP) implementations do not limit the rate of Neighbor 2546 Discovery messages processed", 2011. 2548 [CVE-2008-2476] 2549 CVE, "CVE-2008-2476 - IPv6 Neighbor Discovery Protocol 2550 (NDP) implementations do not validate the origin of 2551 Neighbor Discovery messages", 2008. 2553 [CVE-2010-4669] 2554 CVE, "CVE-2010-4669 - Neighbor Discovery (ND) protocol 2555 implementation in the IPv6 stack in Microsoft Windows 2556 allows attackers to cause a denial of service (CPU 2557 consumption and system hang) by sending many Router 2558 Advertisement (RA) messages with different source 2559 addresses", 2010. 2561 [CVE-2011-2395] 2562 CVE, "CVE-2011-2395 - Neighbor Discovery (ND) protocol 2563 implementation in Cisco IOS on unspecified switches allows 2564 attackers to bypass the Router Advertisement Guarding 2565 functionality via a fragmented IPv6 packets", 2011. 2567 [CVE-2010-4562] 2568 CVE, "CVE-2010-4562 - Microsoft Windows, when using IPv6, 2569 allows remote attackers to determine whether a host is 2570 sniffing the network by sending an ICMPv6 Echo Request to 2571 a multicast address and determining whether an Echo Reply 2572 is sent", 2010. 2574 [US-CERT2008] 2575 US-CERT, "US-CERT Vulnerability Note VU#472363: IPv6 2576 implementations insecurely update Forwarding Information 2577 Base", 2008. 2579 Author's Address 2581 Fernando Gont 2582 SI6 Networks / UTN-FRH 2583 Evaristo Carriego 2644 2584 Haedo, Provincia de Buenos Aires 1706 2585 Argentina 2587 Phone: +54 11 4650 8472 2588 Email: fgont@si6networks.com 2589 URI: http://www.si6networks.com