idnits 2.17.1 draft-ietf-v6ops-ra-guard-implementation-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6105, updated by this document, for RFC5378 checks: 2008-07-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 14, 2012) is 4173 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: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-6man-oversized-header-chain-02 == Outdated reference: A later version (-05) exists of draft-ietf-6man-nd-extension-headers-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group (v6ops) F. Gont 3 Internet-Draft UK CPNI 4 Updates: 6105 (if approved) November 14, 2012 5 Intended status: Informational 6 Expires: May 18, 2013 8 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) 9 draft-ietf-v6ops-ra-guard-implementation-07 11 Abstract 13 The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly 14 employed to mitigate attack vectors based on forged ICMPv6 Router 15 Advertisement messages. Many existing IPv6 deployments rely on RA- 16 Guard as the first line of defense against the aforementioned attack 17 vectors. However, some implementations of RA-Guard have been found 18 to be prone to circumvention by employing IPv6 Extension Headers. 19 This document describes the evasion techniques that affect the 20 aforementioned implementations, and formally updates RFC 6105, such 21 that the aforementioned RA-Guard evasion vectors are eliminated. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 18, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Evasion techniques for some Router Advertisement Guard (RA 59 Guard) implementations . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Attack Vector based on IPv6 Extension Headers . . . . . . 4 61 2.2. Attack vector based on IPv6 fragmentation . . . . . . . . 4 62 3. RA-Guard implementation advice . . . . . . . . . . . . . . . . 8 63 4. Other Implications . . . . . . . . . . . . . . . . . . . . . . 11 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 70 Appendix A. Assessment tools . . . . . . . . . . . . . . . . . . 17 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 1. Introduction 75 IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique 76 for attack vectors based on ICMPv6 Router Advertisement messages. 77 [RFC6104] describes the problem statement of "Rogue IPv6 Router 78 Advertisements", and [RFC6105] specifies the "IPv6 Router 79 Advertisement Guard" functionality. 81 The concept behind RA-Guard is that a layer-2 device filters ICMPv6 82 Router Advertisement messages, according to a number of different 83 criteria. The most basic filtering criterion is that Router 84 Advertisement messages are discarded by the layer-2 device unless 85 they are received on a specified port of the layer-2 device. 86 Clearly, the effectiveness of the RA Guard mitigation relies on the 87 ability of the layer-2 device to identify ICMPv6 Router Advertisement 88 messages. 90 Some popular RA-Guard implementations have been found to be easy to 91 circumvent by employing IPv6 extension headers [CPNI-IPv6]. This 92 document describes such evasion techniques, and provides advice to 93 RA-Guard implementers such that the aforementioned evasion vectors 94 can be eliminated. 96 It should be noted that the aforementioned techniques could also be 97 exploited to evade network monitoring tools such as NDPMon [NDPMon], 98 ramond [ramond], and rafixd [rafixd], and could probably be exploited 99 to perform stealth DHCPv6 attacks. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2. Evasion techniques for some Router Advertisement Guard (RA Guard) 106 implementations 108 The following subsections describe two different vectors that have 109 been found to be effective for the evasion of popular implementations 110 of the RA-Guard protection. Section 2.1 describes an attack vector 111 based on the use of IPv6 Extension Headers with the ICMPv6 Router 112 Advertisement messages, which may be used to circumvent the RA-Guard 113 protection of those implementations that fail to process an entire 114 IPv6 header chain when trying to identify the ICMPv6 Router 115 Advertisement messages. Section 2.2 describes an attack method based 116 on the use of IPv6 fragmentation, possibly in conjunction with the 117 use of IPv6 Extension Headers. This later vector has been found to 118 be effective with all existing implementations of the RA-Guard 119 mechanism. 121 2.1. Attack Vector based on IPv6 Extension Headers 123 While there is currently no legitimate use for IPv6 Extension Headers 124 in ICMPv6 Router Advertisement messages, Neighbor Discovery 125 implementations allow the use of Extension Headers with these 126 messages, by simply ignoring the received options. Some RA-Guard 127 implementations try to identify ICMPv6 Router Advertisement messages 128 by simply looking at the "Next Header" field of the fixed IPv6 129 header, rather than following the entire header chain. As a result, 130 such implementations fail to identify any ICMPv6 Router Advertisement 131 messages that include any Extension Headers (for example, a Hop by 132 Hop Options header, a Destination Options Header, etc.), and can be 133 easily circumvented. 135 The following figure illustrates the structure of ICMPv6 Router 136 Advertisement messages that implement this evasion technique: 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |NH=60| |NH=58| | | 140 +-+-+-+ +-+-+-+ + + 141 | IPv6 header | Dst Opt Hdr | ICMPv6 Router Advertisement | 142 + + + + 143 | | | | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 2.2. Attack vector based on IPv6 fragmentation 148 This section presents a different attack vector, which has been found 149 to be effective against all implementations of RA-Guard. The basic 150 idea behind this attack vector is that if the forged ICMPv6 Router 151 Advertisement is fragmented into at least two fragments, the layer-2 152 device implementing "RA-Guard" would be unable to identify the attack 153 packet, and would thus fail to block it. 155 A first variant of this attack vector would be an original ICMPv6 156 Router Advertisement message preceded with a Destination Options 157 Header, that results in two fragments. The following figure 158 illustrates the "original" attack packet, prior to fragmentation, and 159 the two resulting fragments which are actually sent as part of the 160 attack. 162 Original packet: 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 |NH=60| |NH=58| | | 166 +-+-+-+ +-+-+-+ + + 167 | IPv6 header | Dst Opt Hdr | ICMPv6 RA | 168 + + + + 169 | | | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 First fragment: 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |NH=44| |NH=60| |NH=58| | 176 +-+-+-+ +-+-+-+ +-+-+-+ + 177 | IPv6 Header | Frag Hdr | Dst Opt Hdr | 178 + + + + 179 | | | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Second fragment: 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 |NH=44| |NH=60| | | | 186 +-+-+-+ +-+-+-+ + + + 187 | IPv6 header | Frag Hdr | Dst Opt Hdr | ICMPv6 RA | 188 + + + + + 189 | | | | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 It should be noted that the "Hdr Ext Len" field of the Destination 193 Options Header is present in the first fragment (rather than the 194 second). Therefore, it is impossible for a device processing only 195 the second fragment to locate the ICMPv6 header contained in that 196 fragment, since it is unknown how many bytes should be "skipped" to 197 get to the next header following the Destination Options Header. 199 Thus, by leveraging the use of the Fragment Header together with the 200 use of the Destination Options header, the attacker is able to 201 conceal the type and contents of the ICMPv6 message he is sending (an 202 ICMPv6 Router Advertisement in this example). Unless the layer-2 203 device were to implement IPv6 fragment reassembly, it would be 204 impossible for the device to identify the ICMPv6 type of the message. 206 A layer-2 device could, however, at least detect that that an 207 ICMPv6 message (or some type) is being sent, since the "Next 208 Header" field of the Destination Options header contained in the 209 first fragment is set to "58" (ICMPv6). 211 This idea can be taken further, such that it is also impossible for 212 the layer-2 device to detect that the attacker is sending an ICMPv6 213 message in the first place. This can be achieved with an original 214 ICMPv6 Router Advertisement message preceded with two Destination 215 Options Headers, that results in two fragments. The following figure 216 illustrates the "original" attack packet, prior to fragmentation, and 217 the two resulting packets which are actually sent as part of the 218 attack. 220 Original packet: 222 +-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |NH=60| |NH=60| |NH=58| | | 224 +-+-+-+ +-+-+-+ +-+-+-+ + + 225 | IPv6 header | Dst Opt Hdr | Dst Opt Hdr | ICMPv6 RA | 226 + + + + + 227 | | | | | 228 +-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 First fragment: 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |NH=44| |NH=60| |NH=60| | 234 +-+-+-+ +-+-+-+ +-+-+-+ + 235 | IPv6 header | Frag Hdr | Dst Opt Hdr | 236 + + + + 237 | | | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Second fragment: 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |NH=44| |NH=60| | |NH=58| | | 244 +-+-+-+ +-+-+-+ + +-+-+-+ + + 245 | IPv6 header | Frag Hdr | Dst O Hdr | Dst Opt Hdr | ICMPv6 RA | 246 + + + + + + 247 | | | | | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 In this variant, the "Next Header" field of the Destination Options 251 header contained in the first fragment is set "60" (Destination 252 Options header), and thus it is impossible for a device processing 253 only the first fragment to detect that an ICMPv6 message is being 254 sent in the first place. 256 The second fragment presents the same challenges as the second 257 fragment of the previous variant. That is, it would be impossible 258 for a device processing only the second fragment to locate the second 259 Destination Options header (and hence the ICMPv6 header), since the 260 "Hdr Ext Len" field of the first Destination Options header is 261 present in the first fragment (rather than the second). 263 3. RA-Guard implementation advice 265 The following filtering rules must be implemented as part of an "RA- 266 Guard" implementation on ports that face interfaces that are not 267 allowed to send ICMPv6 Router Advertisement messages, such that the 268 vulnerabilities discussed in this document are eliminated: 270 1. If the IPv6 Source Address of the packet is not a link-local 271 address (fe80::/10), RA-Guard must pass the packet. 273 RATIONALE: This prevents "RA-Guard" from dedicating compute 274 cycles to filtering packets that originate off-net and, if 275 they are RA's, would not be accepted by the host. Section 276 6.1.2 of [RFC4861] requires nodes to discard Router 277 Advertisement messages if their IPv6 Source Address is not a 278 link-local address. 280 2. If the Hop Limit is not 255, RA-Guard must pass the packet. 282 RATIONALE: This prevents "RA-Guard" from dedicating compute 283 cycles to filtering packets that originate off-net and, if 284 they are RA's, would not be accepted by the host. Section 285 6.1.2 of [RFC4861] requires nodes to discard Router 286 Advertisement messages if their Hop Limit is not 255. 288 3. RA-Guard must parse the IPv6 entire header chain present in the 289 packet, to identify whether the packet is a Router Advertisement 290 message. 292 RATIONALE: [RFC6564] specifies a uniform format for IPv6 293 Extension Header, thus meaning that an IPv6 node can parse an 294 IPv6 header chain even if it contains Extension Headers that 295 are not currently supported by that node. Additionally, 296 [I-D.ietf-6man-oversized-header-chain] requires that if a 297 packet is fragmented, the first fragment contains the entire 298 IPv6 header chain. 300 RA-Guard implementations must not enforce a limit on the 301 number of bytes they can inspect (starting from the beginning 302 of the IPv6 packet), since this could introduce false- 303 positives: legitimate packets could be dropped simply because 304 the RA-Guard device does not parse the entire IPv6 header 305 chain present in the packet. An implementation that has such 306 an implementation-specific limit must not claim compliance 307 with this specification, and must pass the packet when such 308 implementation-specific limit is reached. 310 4. When parsing the IPv6 header chain, if the packet is a first- 311 fragment (i.e., a packet containing a Fragment Header with the 312 Fragment Offset set to 0) and it fails to contain the entire IPv6 313 header chain (i.e., all the headers starting from the IPv6 header 314 up to, and including, the upper-layer header), RA-Guard must drop 315 the packet, and should log the packet drop event in an 316 implementation-specific manner as a security fault. 318 RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies 319 that the first-fragment (i.e., the fragment with the Fragment 320 Offset set to 0) MUST contain the entire IPv6 header chain, 321 and allows intermmediate systems such as routers to drop those 322 packets that fail to comply with this requirement. 324 NOTE: This rule should only be applied to IPv6 fragments with 325 a Fragment Offset of 0 (non-first fragments can be safely 326 passed, since they will never reassemble into a complete 327 datagram if they are part of a Router Advertisement received 328 on a port where such packets are not allowed). 330 5. When parsing the IPv6 header chain, if the packet is identified 331 to be an ICMPv6 Router Advertisement message, RA-Guard must drop 332 the packet, and should log the packet drop event in an 333 implementation-specific manner as a security fault. 335 RATIONALE: By definition, Router Advertisement messages MUST 336 originate on-link, MUST have a link-local IPv6 Source Address, 337 and MUST have a Hop Limit value of 255. [RFC4861]. 339 6. In all other cases, RA-Guard must pass the packet as usual. 341 NOTE: For the purpose of enforcing the RA-Guard filtering policy, 342 an ESP header [RFC4303] should be considered to be an "upper-layer 343 protocol" (that is, it should be considered the last header in the 344 IPv6 header chain). This means that packets employing ESP would 345 be passed by the RA-Guard device to the intended destination. If 346 the destination host does not have a security association with the 347 sender of the aforementioned IPv6 packet, the packet would be 348 dropped. Otherwise, if the packet is considered valid by the 349 IPsec implementation at the receiving host and encapsulates a 350 Router Advertisement message, it is up to the receiving host what 351 to do with such packet. 353 If a packet is dropped due to this filtering policy, then the packet 354 drop event should be logged in an implementation-specific manner as a 355 security fault. The logging mechanism should include a drop counter 356 dedicated to RA-Guard packet drops. 358 In order to protect current end-node IPv6 implementations, Rule #4 359 has been defined as a default rule to drop packets that cannot be 360 positively identified as not being Router Advertisement (RA) messages 361 (because the packet is a fragment that fails to include the entire 362 IPv6 header chain). This means that, at least in theory, RA-Guard 363 could result in false-positive blocking of some legitimate non-RA 364 packets that could not be positively identified as being non-RA. In 365 order to reduce the likelihood of false positives, Rule #1 and Rule 366 #2 require that packets that would not pass the required validation 367 checks for RA messages (Section 6.1.2 of [RFC4861]) be passed without 368 further inspection. In any case, as noted in 369 [I-D.ietf-6man-oversized-header-chain], IPv6 packets that fail to 370 include the entire IPv6 header chain are virtually impossible to 371 police with state-less filters and firewalls, and hence are unlikely 372 to survive in real networks. [I-D.ietf-6man-oversized-header-chain] 373 requires that hosts employing fragmentation include the entire IPv6 374 header chain in the first fragment (the fragment with the Fragment 375 Offset set to 0), thus eliminating the aforementioned false 376 positives. 378 This filtering policy assumes that host implementations require that 379 the IPv6 Source Address of ICMPv6 Router Advertisement messages be a 380 link-local address, and that they discard the packet if this check 381 fails, as required by the current IETF specifications [RFC4861]. 382 Additionally, it assumes that hosts require the Hop Limit of Neighbor 383 Discovery messages to be 255, and discard those packets otherwise. 385 The aforementioned filtering rules implicitly handle the case of 386 fragmented packets: if the RA-Guard device fails to identify the 387 upper-layer protocol as a result of the use of fragmentation, the 388 corresponding packets would be dropped. 390 Finally, we note that IPv6 implementations that allow overlapping 391 fragments (i.e. that do not comply with [RFC5722]) might still be 392 subject of RA-based attacks. However, a recent assessment of IPv6 393 implementations [SI6-FRAG] with respect to their fragment reassembly 394 policy seems to indicate that most current implementations comply 395 with [RFC5722]. 397 4. Other Implications 399 A similar concept to that of "RA-Guard" has been implemented for 400 protecting against forged DHCPv6 messages. Such protection can be 401 circumvented with the same techniques discussed in this document, and 402 the counter-measures for such evasion attack are analogous to those 403 described in Section 3 of this document. 405 [DHCPv6-Shield] specifies a mechanism to protect against rogue 406 DHCPv6 servers, while taking into consideration the evasion 407 techniques discussed in this document. 409 5. IANA Considerations 411 This document has no actions for IANA. 413 6. Security Considerations 415 This document describes a number of techniques that have been found 416 to be effective to circumvent popular RA-Guard implementations, and 417 provides advice to RA-Guard implementations such that those evasion 418 vulnerabilities are eliminated. 420 As noted in Section 3, IPv6 implementations that allow overlapping 421 fragments (i.e. that do not comply with [RFC5722]) might still be 422 subject of RA-based attacks. However, most current 423 implementations seem to comply with [RFC5722]. 425 We note that if an attacker sends a fragmented Router Advertisement 426 message on a port not allowed to send such packets, the first- 427 fragment would be dropped, and the rest of the fragments would be 428 passed. This means that the victim node would tie memory buffers for 429 the aforementioned fragments, which would never reassemble into a 430 complete datagram. If a large number of such packets were sent by an 431 attacker, and the victim node failed to implement proper resource 432 management for the fragment reassembly buffer, this could lead to a 433 Denial of Service (DoS). However, this does not really introduce a 434 new attack vector, since an attacker could always perform the same 435 attack by sending forged fragmented datagram in which at least one of 436 the fragments is missing. [CPNI-IPv6] discusses some resource 437 management strategies that could be implemented for the fragment 438 reassembly buffer. 440 We note that most effective and efficient mitigation for these 441 attacks would be to prohibit the use of IPv6 fragmentation with 442 Router Advertisement messages (as proposed by 443 [I-D.ietf-6man-nd-extension-headers]), such that the RA-Guard 444 functionality is easier to implement. However, since such mitigation 445 would require an update to existing implementations, it cannot be 446 relied upon in the short or near term. 448 Finally, we note that RA-Guard only mitigates attack vectors based on 449 ICMPv6 Router advertisement messages. Protection against similar 450 attacks based on other messages (such as DCHPv6) is considered out of 451 the scope of this document, and left for other documents(e.g. 452 [DHCPv6-Shield]). 454 7. Acknowledgements 456 The author would like to thank Ran Atkinson, who provided very 457 detailed comments and suggested text that was incorporated into this 458 document. 460 The author would like to thank Ran Atkinson, Karl Auer, Robert 461 Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray 462 Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de 463 Velde, James Woodyatt, and Bjoern A. Zeeb, for providing valuable 464 comments on earlier versions of this document. 466 The author would like to thank Arturo Servin, who presented this 467 document at IETF 81. 469 This document resulted from the project "Security Assessment of the 470 Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by 471 Fernando Gont on behalf of the UK Centre for the Protection of 472 National Infrastructure (CPNI). The author would like to thank the 473 UK CPNI, for their continued support. 475 8. References 477 8.1. Normative References 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 483 RFC 4303, December 2005. 485 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 486 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 487 September 2007. 489 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 490 RFC 5722, December 2009. 492 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 493 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 494 February 2011. 496 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 497 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 498 RFC 6564, April 2012. 500 [I-D.ietf-6man-oversized-header-chain] 501 Gont, F. and V. Manral, "Security and Interoperability 502 Implications of Oversized IPv6 Header Chains", 503 draft-ietf-6man-oversized-header-chain-02 (work in 504 progress), November 2012. 506 [I-D.ietf-6man-nd-extension-headers] 507 Gont, F., "Security Implications of IPv6 Fragmentation 508 with IPv6 Neighbor Discovery", 509 draft-ietf-6man-nd-extension-headers-01 (work in 510 progress), November 2012. 512 8.2. Informative References 514 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 515 Problem Statement", RFC 6104, February 2011. 517 [DHCPv6-Shield] 518 Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6 519 Servers", IETF Internet Draft, 520 draft-gont-opsec-dhcpv6-shield, work in progress, 521 May 2012. 523 [CPNI-IPv6] 524 Gont, F., "Security Assessment of the Internet Protocol 525 version 6 (IPv6)", UK Centre for the Protection of 526 National Infrastructure, (available on request). 528 [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", 529 . 531 [rafixd] "rafixd", . 534 [ramond] "ramond", . 536 [SI6-FRAG] 537 SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 538 fragmentation/reassembly", 2012, . 542 [SI6-IPv6] 543 "SI6 Networks' IPv6 toolkit", 544 . 546 [THC-IPV6] 547 "The Hacker's Choice IPv6 Attack Toolkit", 548 . 550 Appendix A. Assessment tools 552 [SI6-IPv6] is a publicly-available set of tools (for Linux, *BSD, and 553 Mac OS) that implements the techniques described in this document. 555 [THC-IPV6] is a publicly-available set of tools (for Linux) that 556 implements some of the techniques described in this document. 558 Author's Address 560 Fernando Gont 561 Centre for the Protection of National Infrastructure 563 Email: fgont@si6networks.com 564 URI: http://www.cpni.gov.uk