idnits 2.17.1 draft-gont-opsec-ipv6-nd-shield-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 5, 2012) is 4335 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'NDPMon' is defined on line 727, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-gont-opsec-dhcpv6-shield-00 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-ra-guard-implementation-04 == Outdated reference: A later version (-02) exists of draft-gont-6man-oversized-header-chain-01 == Outdated reference: A later version (-03) exists of draft-gont-6man-nd-extension-headers-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations Security Working Group F. Gont 3 (opsec) SI6 Networks / UTN-FRH 4 Internet-Draft June 5, 2012 5 Intended status: BCP 6 Expires: December 7, 2012 8 Neighbor Discovery Shield (ND-Shield): Protecting against Neighbor 9 Discovery Attacks 10 draft-gont-opsec-ipv6-nd-shield-00 12 Abstract 14 This document specifies a mechanism that can be implemented in 15 layer-2 devices to mitigate attack vectors based on Neighbor 16 Discovery messages. It is meant to complement other mechanisms 17 implemented in layer-2 devices such as Router Advertisement Guard 18 (RA-Guard) and DHCPv6-Shield, with the goal of achieving a 19 comprehensive IPv6 First Hop Security solution. This document is 20 motivated by the desire to achieve feature parity with IPv4 with 21 respect to First Hop Security mechanisms. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. This document may not be modified, 27 and derivative works of it may not be created, and it may not be 28 published except as an Internet-Draft. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 7, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Mitigating attacks based on the Neighbor Discovery Protocol . 6 62 3.1. Neighbor Discovery Cache Poisoning attacks . . . . . . . . 6 63 3.2. Routing Denial of Service (DoS) attacks . . . . . . . . . 6 64 3.3. Redirect Attacks . . . . . . . . . . . . . . . . . . . . . 6 65 4. Importance of Deploying ND-Shield along with RA-Guard and 66 DHCPv6-Shield . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Neighbor Discovery Shield (ND-Shield) Specification . . . . . 8 68 5.1. Filtering Router Solicitation Messages . . . . . . . . . . 8 69 5.2. Filtering Neighbor Solicitation Messages . . . . . . . . . 10 70 5.3. Filtering Neighbor Advertisement Messages . . . . . . . . 12 71 5.4. Filtering ICMPv6 Redirect messages . . . . . . . . . . . . 14 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 77 Appendix A. Assessment tools . . . . . . . . . . . . . . . . . . 21 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. DISCLAIMER 82 This documents is heavily based on 83 [I-D.ietf-v6ops-ra-guard-implementation] which, at the time of this 84 writing, is going through IETF LC. Future revisions of this document 85 will addresses any issues raised for 86 [I-D.ietf-v6ops-ra-guard-implementation] which apply to this 87 document. 89 Some meta-issues that require input are: 91 o The current version of this document specifies the filtering of 92 different Neighbor Discovery messages in different sections. 93 While this approach results in better-scoped rules, it might not 94 lead to a straightforward implementation. 96 * Should we coalesce all filtering rules in a single section? 97 (and if anything, clarify how each message is processed in an 98 appendix). 100 * Even if we don't proceed that way, should similar text (e.g. 101 all the discussion right after the filtering rules, in each of 102 the sections) be coalesced in a single 'general' section? -- 103 This might help reduce lots of duplicated text, make the 104 document shorter, etc. 106 2. Introduction 108 First hop security techniques are well-known and widely implemented 109 and deployed in the IPv4 world. For example, a number of 110 implementations exist that allow a layer-2 device to block forged ARP 111 reply packets that would otherwise poison the ARP cache of the victim 112 [ARP-VULN]. Additionally, a number of implementations allow a 113 layer-2 device to limit the number of link-layer Source Addresses 114 that can be concurrently "in use" at any point in time on a specific 115 layer-2 port, or the number of IP addresses that can be concurrently 116 in use on a specific layer-2 port. Therefore, it is desirable that 117 the same mitigation techniques be available in the IPv6 world, such 118 that those networks currently employing these techniques can enforce 119 the same /policies for the IPv6 protocols. 121 This document specifies "Neighbor Discovery Shield (ND-Shield)", a 122 mechanism that can be employed by layer-2 devices to mitigate attacks 123 based on the Neighbor Discovery Protocol. Specifically, this 124 mechanism allows the filtering of malicious Router Solicitation, 125 Neighbor Solicitation, Neighbor Advertisement, and ICMPv6 Redirect 126 messages at a layer-2 device. 128 Filtering of Router Advertisement messages is part of Router 129 Advertisement Guard (RA-Guard) [RFC6104] [RFC6105] 130 [I-D.ietf-v6ops-ra-guard-implementation], and hence is not 131 specified in this document. In the same way, filtering of DHCPv6 132 packets is part of DHCPv6-Shield [I-D.gont-opsec-dhcpv6-shield], 133 and hence is not specified in this document. 135 The basic concept behind ND-Shield is that a layer-2 device can 136 filter Neighbor Solicitation, Neighbor Advertisement, and Redirect 137 messages, according to a number of different criteria, such as 138 whether the Target Address or the Source Link-Layer address fields of 139 the corresponding message are considered legitimate, or whether the 140 corresponding ICMPv6 type/code message is to be allowed on a specific 141 layer-2 port. 143 Section 3 discusses the type of attacks that ND-Shield is expected to 144 mitigate. Section 4 discusses the importance of deploying ND-Shield 145 in those networks currently employing RA-Guard and/or DHCPv6-Shield. 146 Section 5 specifies the Neighbor Discovery Guard (ND-Guard) 147 mechanism; that is, the filtering rules to be enforced on the local 148 layer-2 device such that attacks based on Router Solicitation, 149 Neighbor Solicitation, Neighbor Advertisement, and Redirect messages 150 are mitigated. 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 3. Mitigating attacks based on the Neighbor Discovery Protocol 158 This section provides a brief summary of the types of attacks that 159 ND-Shield is expected to mitigate. 161 3.1. Neighbor Discovery Cache Poisoning attacks 163 An attacker could cause a victim node to include an illegitimate 164 entry in the Neighbor Cache, by sending a Neighbor Solicitation or 165 Router Solicitation with a forged Source Link-Layer Address option or 166 a Neighbor Advertisement or REdirect message with a forged Target 167 Link-Layer address option. This attack could be exploited for Denial 168 of Service (DoS) or Man In The Middle (MITM) purposes. 170 3.2. Routing Denial of Service (DoS) attacks 172 An attacker could cause a victim node to disable its first-hop router 173 by sending a forged Neighor Advertisement with the 'R' flag clear. 175 3.3. Redirect Attacks 177 An attacker could cause a victim node to send its packets to a 178 different (and possibly malicious) "first hop router" by sending 179 forged Redirect messages. This attack could be exploited for Denial 180 of Service (DoS) or Man In The Middle (MITM) purposes. 182 4. Importance of Deploying ND-Shield along with RA-Guard and DHCPv6- 183 Shield 185 RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation] can 186 mitigate attack vectors based on ICMPv6 Router Advertisement messages 187 by blocking Router Advertisement messages received on "unauthorized" 188 layer-2 ports. Thus, RA-Guard can mitigate attacks where a malicious 189 node tries to convey illegitimate network configuration information 190 to the victim nodes. In a similar way, DHCPv6-Shield 191 [I-D.gont-opsec-dhcpv6-shield] can mitigate attack vectors based on 192 forged DHCPv6 messages, where the attacker tries to convey 193 illegitimate network configuration information to the victim nodes. 195 However, even if Router Advertisement and DHCPv6 messages are 196 policed, an attacker could still e.g. divert traffic meant to the 197 legitimate router to a node he controls by sending forged Neighbor 198 Advertisement messages that illegitimately map the first-hop router's 199 IPv6 address to a the link-layer address of an attacker-controlled 200 node or by sending forged Redirect messages that cause a per-host 201 specific route to be created at the victim node. 203 Therefore, deployment of ND-Shield in scenarios where RA-Guard and/or 204 DHCPv6-Shield are already deployed is highly recommended. 206 5. Neighbor Discovery Shield (ND-Shield) Specification 208 The following subsections specify the filtering rules MUST be 209 implemented as part of an "ND-Shield" implementation. 211 5.1. Filtering Router Solicitation Messages 213 1. If the Hop Limit is not 255, pass the packet. 215 Section 6.1.1 of [RFC4861] requires nodes to discard Router 216 Solicitation messages if their Hop Limit is not 255. 218 2. Try to identify whether the packet is an ICMPv6 Router 219 Solicitation message, by parsing the IPv6 header chain. When 220 doing so, enforce a limit on the maximum number of Extension 221 Headers that is allowed for each packet, and if such limit is hit 222 before the upper-layer protocol is identified, drop the packet. 224 [RFC6564] specifies a uniform format for IPv6 Extension 225 Header, thus meaning that an IPv6 node should be able to parse 226 an IPv6 header chain even if it contains Extension Headers 227 that are not currently supported by that node. 229 3. If ND-Shield is unable to identify whether the packet is an 230 ICMPv6 Router Solicitation message or not (i.e., the packet is a 231 first-fragment, and the necessary information is missing), drop 232 the packet. 234 Note: This rule should only be applied to non-fragmented IPv6 235 datagrams and IPv6 fragments with a Fragment Offset of 0 (non- 236 first fragments can be safely passed, since they will never 237 reassemble into a complete datagram if they are part of a 238 Router Solicitation message of which the first fragment was 239 dropped). 241 4. If the packet is identified to be an ICMPv6 Router Solicitation 242 message, then proceed as follows: 244 1. If the Source Address is the loopback address (::1) or a 245 multicast address, drop the packet. 247 Such addresses are invalid for Router Solicitation 248 messages, and dropping these illegitimate packets here 249 simplifies the nest filtering rules. 251 2. If the Source Address is a unicast address which is not known 252 to be in use at any of the layer-2 ports, record the Source 253 Address as being in use on the received port, and pass the 254 packet as usual. 256 3. If the Source Address is a unicast address which is known to 257 be in use on a layer-2 port other than the one on which the 258 packet was received, drop the received packet. 260 5. In all other cases, pass the packet as usual. 262 Note: For the purpose of enforcing the ND-Shield filtering policy, 263 an ESP header [RFC4303] should be considered to be an "upper-layer 264 protocol" (that is, it should be considered the last header in the 265 IPv6 header chain). This means that packets employing ESP would 266 be passed by the ND-Shield device to the intended destination. If 267 the destination host does not have a security association with the 268 sender of the aforementioned IPv6 packet, the packet would be 269 dropped. Otherwise, if the packet is considered valid by the 270 IPsec implementation at the receiving host and encapsulates a 271 Router Solicitation message, it is up to the receiving host what 272 to do with such packet. 274 If a packet is dropped due to this filtering policy, then the packet 275 drop event SHOULD be logged. The logging mechanism SHOULD include a 276 drop counter dedicated to ND-Shield packet drops. 278 In order to protect current end-node IPv6 implementations, Rule #4 279 has been defined as a default rule to drop packets that cannot be 280 positively identified as not being Router Solicitation (RS) messages 281 (possibly because the packet contains fragments that do not contain 282 the entire IPv6 header chain). This means that, at least in theory, 283 ND-Shield could result in false-positive blocking of some legitimate 284 non-RS packets that could not be positively identified as being 285 non-RS. In order to reduce the likelihood of false positives, Rule 286 #1 requires that packets that would not pass the required validation 287 checks for RS messages (Section 6.1.1 of [RFC4861]) be passed without 288 further inspection. In any case, as noted in 289 [I-D.gont-6man-oversized-header-chain], IPv6 packets that fail to 290 include the entire IPv6 header chain are anyway unlikely to survive 291 in real networks. Whilst currently legitimate from a specifications 292 standpoint, they are virtually impossible to police with state-less 293 filters and firewalls, and are hence likely to be blocked by such 294 filters and firewalls. 296 This filtering policy assumes that host implementations require the 297 Hop Limit of Neighbor Discovery messages to be 255, and discard those 298 packets otherwise. 300 The aforementioned filtering rules implicitly handle the case of 301 fragmented packets: if the ND-Shield device fails to identify the 302 upper-layer protocol as a result of the use of fragmentation, the 303 corresponding packets would be dropped. 305 Finally, we note that IPv6 implementations that allow overlapping 306 fragments (i.e. that do not comply with [RFC5722]) might still be 307 subject of RS-based attacks. However, a recent assessment of IPv6 308 implementations [SI6-FRAG] with respect to their fragment reassembly 309 policy seems to indicate that most current implementations comply 310 with [RFC5722]. 312 5.2. Filtering Neighbor Solicitation Messages 314 1. If the Hop Limit is not 255, pass the packet. 316 Section 7.1.1 of [RFC4861] requires nodes to discard Neighbor 317 Solicitation messages if their Hop Limit is not 255. 319 2. Try to identify whether the packet is an ICMPv6 Neighbor 320 Solicitation message, by parsing the IPv6 header chain. When 321 doing so, enforce a limit on the maximum number of Extension 322 Headers that is allowed for each packet, and if such limit is hit 323 before the upper-layer protocol is identified, drop the packet. 325 [RFC6564] specifies a uniform format for IPv6 Extension 326 Header, thus meaning that an IPv6 node should be able to parse 327 an IPv6 header chain even if it contains Extension Headers 328 that are not currently supported by that node. 330 3. If ND-Shield is unable to identify whether the packet is an 331 ICMPv6 Neighbor Solicitation message or not (i.e., the packet is 332 a first-fragment, and the necessary information is missing), drop 333 the packet. 335 Note: This rule should only be applied to non-fragmented IPv6 336 datagrams and IPv6 fragments with a Fragment Offset of 0 (non- 337 first fragments can be safely passed, since they will never 338 reassemble into a complete datagram if they are part of a 339 Neighbor Solicitation message of which the first fragment was 340 dropped). 342 4. If the packet is identified to be an ICMPv6 Neighbor Solicitation 343 message, then proceed as follows: 345 1. If the Source Address is the unspecified address, and the 346 Destination Address is not a solicited-node multicast address 347 or the packet contains source link-layer address option, drop 348 the packet. 350 2. If the Source Address is a unicast address which is not known 351 to be in use at any of the layer-2 ports, record the Source 352 Address as being in use on the received port, and pass the 353 packet as usual. 355 3. If the Source Address is a unicast address which is known to 356 be in use on a layer-2 port other than the one on which the 357 packet was received, drop the received packet. 359 5. In all other cases, pass the packet as usual. 361 Note: For the purpose of enforcing the ND-Shield filtering policy, 362 an ESP header [RFC4303] should be considered to be an "upper-layer 363 protocol" (that is, it should be considered the last header in the 364 IPv6 header chain). This means that packets employing ESP would 365 be passed by the ND-Shield device to the intended destination. If 366 the destination host does not have a security association with the 367 sender of the aforementioned IPv6 packet, the packet would be 368 dropped. Otherwise, if the packet is considered valid by the 369 IPsec implementation at the receiving host and encapsulates a 370 Router Advertisement message, it is up to the receiving host what 371 to do with such packet. 373 If a packet is dropped due to this filtering policy, then the packet 374 drop event SHOULD be logged. The logging mechanism SHOULD include a 375 drop counter dedicated to ND-Shield packet drops. 377 In order to protect current end-node IPv6 implementations, Rule #4 378 has been defined as a default rule to drop packets that cannot be 379 positively identified as not being Neighbor Solicitation (NS) 380 messages (possibly because the packet contains fragments that do not 381 contain the entire IPv6 header chain). This means that, at least in 382 theory, ND-Shield could result in false-positive blocking of some 383 legitimate non-NS packets that could not be positively identified as 384 being non-NS. In order to reduce the likelihood of false positives, 385 Rule #1 requires that packets that would not pass the required 386 validation checks for NS messages (Section 7.1.1 of [RFC4861]) be 387 passed without further inspection. In any case, as noted in 388 [I-D.gont-6man-oversized-header-chain], IPv6 packets that fail to 389 include the entire IPv6 header chain are anyway unlikely to survive 390 in real networks. Whilst currently legitimate from a specifications 391 standpoint, they are virtually impossible to police with state-less 392 filters and firewalls, and are hence likely to be blocked by such 393 filters and firewalls. 395 This filtering policy assumes that host implementations require the 396 Hop Limit of Neighbor Discovery messages to be 255, and discard those 397 packets otherwise. 399 The aforementioned filtering rules implicitly handle the case of 400 fragmented packets: if the ND-Shield device fails to identify the 401 upper-layer protocol as a result of the use of fragmentation, the 402 corresponding packets would be dropped. 404 Finally, we note that IPv6 implementations that allow overlapping 405 fragments (i.e. that do not comply with [RFC5722]) might still be 406 subject of NS-based attacks. However, a recent assessment of IPv6 407 implementations [SI6-FRAG] with respect to their fragment reassembly 408 policy seems to indicate that most current implementations comply 409 with [RFC5722]. 411 5.3. Filtering Neighbor Advertisement Messages 413 1. If the Hop Limit is not 255, pass the packet. 415 Section 7.1.2 of [RFC4861] requires nodes to discard Neighbor 416 Advertisement messages if their Hop Limit is not 255. 418 2. Try to identify whether the packet is an ICMPv6 Neighbor 419 Advertisement message, by parsing the IPv6 header chain. When 420 doing so, enforce a limit on the maximum number of Extension 421 Headers that is allowed for each packet, and if such limit is hit 422 before the upper-layer protocol is identified, drop the packet. 424 [RFC6564] specifies a uniform format for IPv6 Extension 425 Header, thus meaning that an IPv6 node should be able to parse 426 an IPv6 header chain even if it contains Extension Headers 427 that are not currently supported by that node. 429 3. If ND-Shield is unable to identify whether the packet is an 430 ICMPv6 Neighbor Advertisement message or not (i.e., the packet is 431 a first-fragment, and the necessary information is missing), drop 432 the packet. 434 Note: This rule should only be applied to non-fragmented IPv6 435 datagrams and IPv6 fragments with a Fragment Offset of 0 (non- 436 first fragments can be safely passed, since they will never 437 reassemble into a complete datagram if they are part of a 438 Neighbor Advertisement which, according to the information it 439 conveys and the port where it was received, should not 440 allowed). 442 4. If the packet is identified to be an ICMPv6 Neighbor 443 Advertisement message, then proceed as follows: 445 1. If the Target Address is the unspecified address (::), the 446 loopback address (::1), or a multicast address, drop the 447 packet. 449 2. If the Target Address is a unicast address not known to be in 450 use at any of the layer-2 ports, record the Target Address as 451 being in use on the received port, and pass the packet as 452 usual. 454 3. If the Target Address is a unicast address known to be in use 455 on a layer-2 port other than the one on which the packet was 456 received, drop the received packet. 458 5. In all other cases, pass the packet as usual. 460 Note: For the purpose of enforcing the ND-Shield filtering policy, 461 an ESP header [RFC4303] should be considered to be an "upper-layer 462 protocol" (that is, it should be considered the last header in the 463 IPv6 header chain). This means that packets employing ESP would 464 be passed by the ND-Shield device to the intended destination. If 465 the destination host does not have a security association with the 466 sender of the aforementioned IPv6 packet, the packet would be 467 dropped. Otherwise, if the packet is considered valid by the 468 IPsec implementation at the receiving host and encapsulates a 469 Neighbor Advertisement message, it is up to the receiving host 470 what to do with such packet. 472 If a packet is dropped due to this filtering policy, then the packet 473 drop event SHOULD be logged. The logging mechanism SHOULD include a 474 drop counter dedicated to ND-Shield packet drops. 476 In order to protect current end-node IPv6 implementations, Rule #1 477 has been defined as a default rule to drop packets that cannot be 478 positively identified as not being Neighbor Advertisement (NA) 479 messages (possibly because the packet contains fragments that do not 480 contain the entire IPv6 header chain). This means that, at least in 481 theory, ND-Shield could result in false-positive blocking of some 482 legitimate non-NA packets that could not be positively identified as 483 being non-NA. In order to reduce the likelihood of false positives, 484 Rule #1 requires that packets that would not pass the required 485 validation checks for NA messages (Section 7.1.2 of [RFC4861]) be 486 passed without further inspection. In any case, as noted in 487 [I-D.gont-6man-oversized-header-chain], IPv6 packets that fail to 488 include the entire IPv6 header chain are anyway unlikely to survive 489 in real networks. Whilst currently legitimate from a specifications 490 standpoint, they are virtually impossible to police with state-less 491 filters and firewalls, and are hence likely to be blocked by such 492 filters and firewalls. 494 This filtering policy assumes that host implementations require the 495 Hop Limit of Neighbor Discovery messages to be 255, and discard those 496 packets otherwise. 498 The aforementioned filtering rules implicitly handle the case of 499 fragmented packets: if the ND-Shield device fails to identify the 500 upper-layer protocol as a result of the use of fragmentation, the 501 corresponding packets would be dropped. 503 Finally, we note that IPv6 implementations that allow overlapping 504 fragments (i.e. that do not comply with [RFC5722]) might still be 505 subject of NA-based attacks. However, a recent assessment of IPv6 506 implementations [SI6-FRAG] with respect to their fragment reassembly 507 policy seems to indicate that most current implementations comply 508 with [RFC5722]. 510 5.4. Filtering ICMPv6 Redirect messages 512 This section specifies the filtering rules for ICMPv6 Redirect 513 messages that must be implemented as part of an "ND-Shield" 514 implementation. The aforementioned rules should be enforced on all 515 layer-2 ports EXCEPT those that have been configured for router use. 517 NOTE: If ND-Shield is implemented along RA-Guard, the 518 aforementioned configuration information will be readily 519 available. That is, the filtering rules specified in this section 520 should be enforced on all layer-2 ports except those that have 521 been configured for router use. 523 1. If the IPv6 Source Address of the packet is not a link-local 524 address (fe80::/10), pass the packet. 526 Section 8.1 of [RFC4861] requires nodes to discard ICMPv6 527 Redirect messages if their IPv6 Source Address is not a link- 528 local address. 530 2. If the Hop Limit is not 255, pass the packet. 532 Section 8.1 of [RFC4861] requires nodes to discard ICMPv6 533 Redirect messages if their Hop Limit is not 255. 535 3. Try to identify whether the packet is an ICMPv6 Redirect message, 536 by parsing the IPv6 header chain. When doing so, enforce a limit 537 on the maximum number of Extension Headers that is allowed for 538 each packet, and if such limit is hit before the upper-layer 539 protocol is identified, drop the packet. 541 [RFC6564] specifies a uniform format for IPv6 Extension 542 Header, thus meaning that an IPv6 node should be able to parse 543 an IPv6 header chain even if it contains Extension Headers 544 that are not currently supported by that node. 546 4. If ND-Shield is unable to identify whether the packet is an 547 ICMPv6 Redirect message or not (i.e., the packet is a first- 548 fragment, and the necessary information is missing), drop the 549 packet. 551 Note: This rule should only be applied to non-fragmented IPv6 552 datagrams and IPv6 fragments with a Fragment Offset of 0 (non- 553 first fragments can be safely passed, since they will never 554 reassemble into a complete datagram if they are part of a 555 ICMPv6 Redirect message received on a port where such packets 556 are not allowed). 558 5. If the packet is identified to be an ICMPv6 Redirect message, 559 drop the packet. 561 6. In all other cases, pass the packet as usual. 563 Note: For the purpose of enforcing the ND-Shield filtering policy, 564 an ESP header [RFC4303] should be considered to be an "upper-layer 565 protocol" (that is, it should be considered the last header in the 566 IPv6 header chain). This means that packets employing ESP would 567 be passed by the ND-Shield device to the intended destination. If 568 the destination host does not have a security association with the 569 sender of the aforementioned IPv6 packet, the packet would be 570 dropped. Otherwise, if the packet is considered valid by the 571 IPsec implementation at the receiving host and encapsulates a 572 ICMPv6 Redirect message, it is up to the receiving host what to do 573 with such packet. 575 If a packet is dropped due to this filtering policy, then the packet 576 drop event SHOULD be logged. The logging mechanism SHOULD include a 577 drop counter dedicated to ND-Shield packet drops. 579 In order to protect current end-node IPv6 implementations, Rule #4 580 has been defined as a default rule to drop packets that cannot be 581 positively identified as not being ICMPv6 Redirect messages (possibly 582 because the packet contains fragments that do not contain the entire 583 IPv6 header chain). This means that, at least in theory, ND-Shield 584 could result in false-positive blocking of some legitimate non- 585 Redirect packets that could not be positively identified as being 586 non-Redirect. In order to reduce the likelihood of false positives, 587 Rule #1 and Rule #2 require that packets that would not pass the 588 required validation checks for Redirect messages (Section 8.1 of 590 [RFC4861]) be passed without further inspection. In any case, as 591 noted in [I-D.gont-6man-oversized-header-chain], IPv6 packets that 592 fail to include the entire IPv6 header chain are anyway unlikely to 593 survive in real networks. Whilst currently legitimate from a 594 specifications standpoint, they are virtually impossible to police 595 with state-less filters and firewalls, and are hence likely to be 596 blocked by such filters and firewalls. 598 This filtering policy assumes that host implementations require that 599 the IPv6 Source Address of ICMPv6 Redirect messages be a link-local 600 address, and that they discard the packet if this check fails, as 601 required by the current IETF specifications [RFC4861]. Additionally, 602 it assumes that hosts require the Hop Limit of Neighbor Discovery 603 messages to be 255, and discard those packets otherwise. 605 The aforementioned filtering rules implicitly handle the case of 606 fragmented packets: if the ND-Shield device fails to identify the 607 upper-layer protocol as a result of the use of fragmentation, the 608 corresponding packets would be dropped. 610 Finally, we note that IPv6 implementations that allow overlapping 611 fragments (i.e. that do not comply with [RFC5722]) might still be 612 subject of Redirect-based attacks. However, a recent assessment of 613 IPv6 implementations [SI6-FRAG] with respect to their fragment 614 reassembly policy seems to indicate that most current implementations 615 comply with [RFC5722]. 617 6. Security Considerations 619 This document specifies ND-Shield, an operational mitigation for 620 attack vectors based on Router Solicitation, Neighbor Solicitation, 621 Neighbor Advertisement, and Redirect messages. 623 We note that if an attacker sends a fragmented Neighbor Discovery 624 packets that are deemed as 'inappropriate' by the ND-Shield device, 625 the first-fragment would be dropped, and the rest of the fragments 626 would be passed. This means that the victim node would tie memory 627 buffers for the aforementioned fragments, which would never 628 reassemble into a complete datagram. If a large number of such 629 packets were sent by an attacker, and the victim node failed to 630 implement proper resource management for the fragment reassembly 631 buffer, this could lead to a Denial of Service (DoS). However, this 632 does not really introduce a new attack vector, since an attacker 633 could always perform the same attack by sending forged fragmented 634 datagrams in which at least one of the fragments is missing. 635 [CPNI-IPv6] discusses some resource management strategies that could 636 be implemented for the fragment reassembly buffer. 638 Finally, we note that the most effective and efficient mitigation for 639 these attacks would be to prohibit the use of IPv6 fragmentation with 640 all Neighbor Discovery messages (as proposed by 641 [I-D.gont-6man-nd-extension-headers]), such that the ND-Shield 642 functionality is easier to implement. However, since such mitigation 643 would require an update to existing implementations, it cannot be 644 relied upon in the short or near term. 646 7. Acknowledgements 648 The author would like to thank Ran Atkinson, Karl Auer, Robert 649 Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray 650 Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de 651 Velde, James Woodyatt, and Bjoern A. Zeeb, who provided valuable 652 comments on the document "Implementation Advice for IPv6 Router 653 Advertisement Guard (RA-Guard)" 654 [I-D.ietf-v6ops-ra-guard-implementation], on which this document is 655 heavily based. 657 8. References 659 8.1. Normative References 661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 662 Requirement Levels", BCP 14, RFC 2119, March 1997. 664 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 665 RFC 4303, December 2005. 667 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 668 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 669 September 2007. 671 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 672 RFC 5722, December 2009. 674 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 675 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 676 RFC 6564, April 2012. 678 8.2. Informative References 680 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 681 Problem Statement", RFC 6104, February 2011. 683 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 684 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 685 February 2011. 687 [I-D.gont-opsec-dhcpv6-shield] 688 Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6 689 Servers", draft-gont-opsec-dhcpv6-shield-00 (work in 690 progress), May 2012. 692 [I-D.ietf-v6ops-ra-guard-implementation] 693 Gont, F., "Implementation Advice for IPv6 Router 694 Advertisement Guard (RA-Guard)", 695 draft-ietf-v6ops-ra-guard-implementation-04 (work in 696 progress), May 2012. 698 [I-D.gont-6man-oversized-header-chain] 699 Gont, F. and V. Manral, "Security and Interoperability 700 Implications of Oversized IPv6 Header Chains", 701 draft-gont-6man-oversized-header-chain-01 (work in 702 progress), April 2012. 704 [I-D.gont-6man-nd-extension-headers] 705 Gont, F., "Security Implications of the Use of IPv6 706 Extension Headers with IPv6 Neighbor Discovery", 707 draft-gont-6man-nd-extension-headers-02 (work in 708 progress), January 2012. 710 [SI6-FRAG] 711 SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 712 fragmentation/reassembly", 2012, . 716 [CPNI-IPv6] 717 Gont, F., "Security Assessment of the Internet Protocol 718 version 6 (IPv6)", UK Centre for the Protection of 719 National Infrastructure, (available on request). 721 [ARP-VULN] 722 Bekeey, M., "ARP Vulnerabilities: Indefensible Local 723 Network Attacks?", Black Hat Briefings '01, 2001, . 727 [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", 728 . 730 [rafixd] "rafixd", . 733 [ramond] "ramond", . 735 [THC-IPV6] 736 "The Hacker's Choice IPv6 Attack Toolkit", 737 . 739 Appendix A. Assessment tools 741 UK CPNI (http://www.cpni.gov.uk) has produced assessment tools (which 742 have not yet been made publicly available) to assess IPv6 743 implementations with respect to the issues described in this 744 document. If you think that you would benefit from these tools, we 745 might be able to provide a copy of the tools (please contact Fernando 746 Gont at fernando@gont.com.ar). 748 [THC-IPV6] is a publicly-available set of tools that implements some 749 (if not all) of the techniques described in this document. 751 Author's Address 753 Fernando Gont 754 SI6 Networks / UTN-FRH 755 Evaristo Carriego 2644 756 Haedo, Provincia de Buenos Aires 1706 757 Argentina 759 Phone: +54 11 4650 8472 760 Email: fgont@si6networks.com 761 URI: http://www.si6networks.com