idnits 2.17.1 draft-ietf-v6ops-ra-guard-implementation-05.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 (October 26, 2012) is 4198 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) == Outdated reference: A later version (-09) exists of draft-ietf-6man-oversized-header-chain-01 == Outdated reference: A later version (-05) exists of draft-ietf-6man-nd-extension-headers-00 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) October 26, 2012 5 Intended status: BCP 6 Expires: April 29, 2013 8 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) 9 draft-ietf-v6ops-ra-guard-implementation-05 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 April 29, 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 Appendix B. Advice and guidance to vendors . . . . . . . . . . . 18 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 1. Introduction 76 IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique 77 for attack vectors based on ICMPv6 Router Advertisement messages. 78 [RFC6104] describes the problem statement of "Rogue IPv6 Router 79 Advertisements", and [RFC6105] specifies the "IPv6 Router 80 Advertisement Guard" functionality. 82 The concept behind RA-Guard is that a layer-2 device filters ICMPv6 83 Router Advertisement messages, according to a number of different 84 criteria. The most basic filtering criterion is that Router 85 Advertisement messages are discarded by the layer-2 device unless 86 they are received on a specified port of the layer-2 device. 87 Clearly, the effectiveness of the RA Guard mitigation relies on the 88 ability of the layer-2 device to identify ICMPv6 Router Advertisement 89 messages. 91 Some popular RA-Guard implementations have been found to be easy to 92 circumvent by employing IPv6 extension headers [CPNI-IPv6]. This 93 document describes such evasion techniques, and provides advice to 94 RA-Guard implementers such that the aforementioned evasion vectors 95 can be eliminated. 97 It should be noted that the aforementioned techniques could also be 98 exploited to evade network monitoring tools such as NDPMon [NDPMon], 99 ramond [ramond], and rafixd [rafixd], and could probably be exploited 100 to perform stealth DHCPv6 attacks. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 2. Evasion techniques for some Router Advertisement Guard (RA Guard) 107 implementations 109 The following subsections describe two different vectors that have 110 been found to be effective for the evasion of popular implementations 111 of the RA-Guard protection. Section 2.1 describes an attack vector 112 based on the use of IPv6 Extension Headers with the ICMPv6 Router 113 Advertisement messages, which may be used to circumvent the RA-Guard 114 protection of those implementations that fail to process an entire 115 IPv6 header chain when trying to identify the ICMPv6 Router 116 Advertisement messages. Section 2.2 describes an attack method based 117 on the use of IPv6 fragmentation, possibly in conjunction with the 118 use of IPv6 Extension Headers. This later vector has been found to 119 be effective with all existing implementations of the RA-Guard 120 mechanism. 122 2.1. Attack Vector based on IPv6 Extension Headers 124 While there is currently no legitimate use for IPv6 Extension Headers 125 in ICMPv6 Router Advertisement messages, Neighbor Discovery 126 implementations allow the use of Extension Headers with these 127 messages, by simply ignoring the received options. Some RA-Guard 128 implementations try to identify ICMPv6 Router Advertisement messages 129 by simply looking at the "Next Header" field of the fixed IPv6 130 header, rather than following the entire header chain. As a result, 131 such implementations fail to identify any ICMPv6 Router Advertisement 132 messages that include any Extension Headers (for example, a Hop by 133 Hop Options header, a Destination Options Header, etc.), and can be 134 easily circumvented. 136 The following figure illustrates the structure of ICMPv6 Router 137 Advertisement messages that implement this evasion technique: 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 |NH=60| |NH=58| | | 141 +-+-+-+ +-+-+-+ + + 142 | IPv6 header | Dst Opt Hdr | ICMPv6 Router Advertisement | 143 + + + + 144 | | | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 2.2. Attack vector based on IPv6 fragmentation 149 This section presents a different attack vector, which has been found 150 to be effective against all implementations of RA-Guard. The basic 151 idea behind this attack vector is that if the forged ICMPv6 Router 152 Advertisement is fragmented into at least two fragments, the layer-2 153 device implementing "RA-Guard" would be unable to identify the attack 154 packet, and would thus fail to block it. 156 A first variant of this attack vector would be an original ICMPv6 157 Router Advertisement message preceded with a Destination Options 158 Header, that results in two fragments. The following figure 159 illustrates the "original" attack packet, prior to fragmentation, and 160 the two resulting fragments which are actually sent as part of the 161 attack. 163 Original packet: 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |NH=60| |NH=58| | | 167 +-+-+-+ +-+-+-+ + + 168 | IPv6 header | Dst Opt Hdr | ICMPv6 RA | 169 + + + + 170 | | | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 First fragment: 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |NH=44| |NH=60| |NH=58| | 177 +-+-+-+ +-+-+-+ +-+-+-+ + 178 | IPv6 Header | Frag Hdr | Dst Opt Hdr | 179 + + + + 180 | | | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Second fragment: 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |NH=44| |NH=60| | | | 187 +-+-+-+ +-+-+-+ + + + 188 | IPv6 header | Frag Hdr | Dst Opt Hdr | ICMPv6 RA | 189 + + + + + 190 | | | | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 It should be noted that the "Hdr Ext Len" field of the Destination 194 Options Header is present in the first fragment (rather than the 195 second). Therefore, it is impossible for a device processing only 196 the second fragment to locate the ICMPv6 header contained in that 197 fragment, since it is unknown how many bytes should be "skipped" to 198 get to the next header following the Destination Options Header. 200 Thus, by leveraging the use of the Fragment Header together with the 201 use of the Destination Options header, the attacker is able to 202 conceal the type and contents of the ICMPv6 message he is sending (an 203 ICMPv6 Router Advertisement in this example). Unless the layer-2 204 device were to implement IPv6 fragment reassembly, it would be 205 impossible for the device to identify the ICMPv6 type of the message. 207 A layer-2 device could, however, at least detect that that an 208 ICMPv6 message (or some type) is being sent, since the "Next 209 Header" field of the Destination Options header contained in the 210 first fragment is set to "58" (ICMPv6). 212 This idea can be taken further, such that it is also impossible for 213 the layer-2 device to detect that the attacker is sending an ICMPv6 214 message in the first place. This can be achieved with an original 215 ICMPv6 Router Advertisement message preceded with two Destination 216 Options Headers, that results in two fragments. The following figure 217 illustrates the "original" attack packet, prior to fragmentation, and 218 the two resulting packets which are actually sent as part of the 219 attack. 221 Original packet: 223 +-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |NH=60| |NH=60| |NH=58| | | 225 +-+-+-+ +-+-+-+ +-+-+-+ + + 226 | IPv6 header | Dst Opt Hdr | Dst Opt Hdr | ICMPv6 RA | 227 + + + + + 228 | | | | | 229 +-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 First fragment: 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |NH=44| |NH=60| |NH=60| | 235 +-+-+-+ +-+-+-+ +-+-+-+ + 236 | IPv6 header | Frag Hdr | Dst Opt Hdr | 237 + + + + 238 | | | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Second fragment: 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |NH=44| |NH=60| | |NH=58| | | 245 +-+-+-+ +-+-+-+ + +-+-+-+ + + 246 | IPv6 header | Frag Hdr | Dst O Hdr | Dst Opt Hdr | ICMPv6 RA | 247 + + + + + + 248 | | | | | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 In this variant, the "Next Header" field of the Destination Options 252 header contained in the first fragment is set "60" (Destination 253 Options header), and thus it is impossible for a device processing 254 only the first fragment to detect that an ICMPv6 message is being 255 sent in the first place. 257 The second fragment presents the same challenges as the second 258 fragment of the previous variant. That is, it would be impossible 259 for a device processing only the second fragment to locate the second 260 Destination Options header (and hence the ICMPv6 header), since the 261 "Hdr Ext Len" field of the first Destination Options header is 262 present in the first fragment (rather than the second). 264 3. RA-Guard implementation advice 266 The following filtering rules MUST be implemented as part of an "RA- 267 Guard" implementation on those ports that are not allowed to send 268 ICMPv6 Router Advertisement messages, such that the vulnerabilities 269 discussed in this document are eliminated: 271 1. If the IPv6 Source Address of the packet is not a link-local 272 address (fe80::/10), RA-Guard MUST pass the packet. 274 RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to 275 discard Router Advertisement messages if their IPv6 Source 276 Address is not a link-local address. 278 2. If the Hop Limit is not 255, RA-Guard MUST pass the packet. 280 RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to 281 discard Router Advertisement messages if their Hop Limit is 282 not 255. 284 3. RA-Guard MUST parse the IPv6 entire header chain present in the 285 packet, to identify whether the packet is a Router Advertisement 286 message. 288 RATIONALE: [RFC6564] specifies a uniform format for IPv6 289 Extension Header, thus meaning that an IPv6 node can parse an 290 IPv6 header chain even if it contains Extension Headers that 291 are not currently supported by that node. Additionally, 292 [I-D.ietf-6man-oversized-header-chain] requires that if a 293 packet is fragmented, the first fragment contains the entire 294 IPv6 header chain. 296 RA-Guard implementations MUST NOT enforce a limit on the 297 number of bytes they can inspect (starting from the beginning 298 of the IPv6 packet), since this could introduce false- 299 positives: legitimate packets could be dropped simply because 300 the RA-Guard device does not parse the entire IPv6 header 301 chain present in the packet. An implementation that has such 302 an implementation-specific limit MUST NOT claim compliance 303 with this specification, and MUST pass the packet when such 304 implementation-specific limit is reached. 306 4. When parsing the IPv6 header chain, if the packet is a first- 307 fragment (i.e., a packet containing a Fragment Header with the 308 Fragment Offset set to 0) and it fails to contain the entire IPv6 309 header chain (i.e., all the headers starting from the IPv6 header 310 up to, and including, the upper-layer header), RA-Guard MUST drop 311 the packet, and SHOULD log the packet drop event in an 312 implementation-specific manner as a security fault. 314 RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies 315 that the first-fragment (i.e., the fragment with the Fragment 316 Offset set to 0) MUST contain the entire IPv6 header chain, 317 and allows intermmediate systems such as routers to drop those 318 packets that fail to comply with this requirement. 320 NOTE: This rule should only be applied to IPv6 fragments with 321 a Fragment Offset of 0 (non-first fragments can be safely 322 passed, since they will never reassemble into a complete 323 datagram if they are part of a Router Advertisement received 324 on a port where such packets are not allowed). 326 5. When parsing the IPv6 header chain, if the packet is identified 327 to be an ICMPv6 Router Advertisement message, RA-Guard MUST drop 328 the packet, and SHOULD log the packet drop event in an 329 implementation-specific manner as a security fault. 331 RATIONALE: By definition, Router Advertisement messages MUST 332 originate on-link, MUST have a link-local IPv6 Source Address, 333 and MUST have a Hop Limit value of 255. [RFC4861]. 335 6. In all other cases, RA-Guard MUST pass the packet as usual. 337 NOTE: For the purpose of enforcing the RA-Guard filtering policy, 338 an ESP header [RFC4303] should be considered to be an "upper-layer 339 protocol" (that is, it should be considered the last header in the 340 IPv6 header chain). This means that packets employing ESP would 341 be passed by the RA-Guard device to the intended destination. If 342 the destination host does not have a security association with the 343 sender of the aforementioned IPv6 packet, the packet would be 344 dropped. Otherwise, if the packet is considered valid by the 345 IPsec implementation at the receiving host and encapsulates a 346 Router Advertisement message, it is up to the receiving host what 347 to do with such packet. 349 If a packet is dropped due to this filtering policy, then the packet 350 drop event SHOULD be logged in an implementation-specific manner as a 351 security fault. The logging mechanism SHOULD include a drop counter 352 dedicated to RA-Guard packet drops. 354 In order to protect current end-node IPv6 implementations, Rule #4 355 has been defined as a default rule to drop packets that cannot be 356 positively identified as not being Router Advertisement (RA) messages 357 (because the packet is a fragment that fails to include the entire 358 IPv6 header chain). This means that, at least in theory, RA-Guard 359 could result in false-positive blocking of some legitimate non-RA 360 packets that could not be positively identified as being non-RA. In 361 order to reduce the likelihood of false positives, Rule #1 and Rule 362 #2 require that packets that would not pass the required validation 363 checks for RA messages (Section 6.1.2 of [RFC4861]) be passed without 364 further inspection. In any case, as noted in 365 [I-D.ietf-6man-oversized-header-chain], IPv6 packets that fail to 366 include the entire IPv6 header chain are virtually impossible to 367 police with state-less filters and firewalls, and hence are unlikely 368 to survive in real networks. [I-D.ietf-6man-oversized-header-chain] 369 requires that hosts employing fragmentation include the entire IPv6 370 header chain in the first fragment (the fragment with the Fragment 371 Offset set to 0), thus eliminating the aforementioned false 372 positives. 374 This filtering policy assumes that host implementations require that 375 the IPv6 Source Address of ICMPv6 Router Advertisement messages be a 376 link-local address, and that they discard the packet if this check 377 fails, as required by the current IETF specifications [RFC4861]. 378 Additionally, it assumes that hosts require the Hop Limit of Neighbor 379 Discovery messages to be 255, and discard those packets otherwise. 381 The aforementioned filtering rules implicitly handle the case of 382 fragmented packets: if the RA-Guard device fails to identify the 383 upper-layer protocol as a result of the use of fragmentation, the 384 corresponding packets would be dropped. 386 Finally, we note that IPv6 implementations that allow overlapping 387 fragments (i.e. that do not comply with [RFC5722]) might still be 388 subject of RA-based attacks. However, a recent assessment of IPv6 389 implementations [SI6-FRAG] with respect to their fragment reassembly 390 policy seems to indicate that most current implementations comply 391 with [RFC5722]. 393 4. Other Implications 395 A similar concept to that of "RA-Guard" has been implemented for 396 protecting against forged DHCPv6 messages. Such protection can be 397 circumvented with the same techniques discussed in this document, and 398 the counter-measures for such evasion attack are analogous to those 399 described in Section 3 of this document. 401 [DHCPv6-Shield] specifies a mechanism to protect against rogue 402 DHCPv6 servers, while taking into consideration the evasion 403 techniques discussed in this document. 405 5. IANA Considerations 407 This document has no actions for IANA. 409 6. Security Considerations 411 This document describes a number of techniques that have been found 412 to be effective to circumvent popular RA-Guard implementations, and 413 provides advice to RA-Guard implementations such that those evasion 414 vulnerabilities are eliminated. 416 As noted in Section 3, IPv6 implementations that allow overlapping 417 fragments (i.e. that do not comply with [RFC5722]) might still be 418 subject of RA-based attacks. However, most current 419 implementations seem to comply with [RFC5722]. 421 We note that if an attacker sends a fragmented Router Advertisement 422 message on a port not allowed to send such packets, the first- 423 fragment would be dropped, and the rest of the fragments would be 424 passed. This means that the victim node would tie memory buffers for 425 the aforementioned fragments, which would never reassemble into a 426 complete datagram. If a large number of such packets were sent by an 427 attacker, and the victim node failed to implement proper resource 428 management for the fragment reassembly buffer, this could lead to a 429 Denial of Service (DoS). However, this does not really introduce a 430 new attack vector, since an attacker could always perform the same 431 attack by sending forged fragmented datagram in which at least one of 432 the fragments is missing. [CPNI-IPv6] discusses some resource 433 management strategies that could be implemented for the fragment 434 reassembly buffer. 436 We note that most effective and efficient mitigation for these 437 attacks would be to prohibit the use of IPv6 fragmentation with 438 Router Advertisement messages (as proposed by 439 [I-D.ietf-6man-nd-extension-headers]), such that the RA-Guard 440 functionality is easier to implement. However, since such mitigation 441 would require an update to existing implementations, it cannot be 442 relied upon in the short or near term. 444 Finally, we note that RA-Guard only mitigates attack vectors based on 445 ICMPv6 Router advertisement messages. Protection against similar 446 attacks based on other messages (such as DCHPv6) is considered out of 447 the scope of this document, and left for other documents(e.g. 448 [DHCPv6-Shield]). 450 7. Acknowledgements 452 The author would like to thank Ran Atkinson, who provided very 453 detailed comments and suggested text that was incorporated into this 454 document. 456 The author would like to thank Ran Atkinson, Karl Auer, Robert 457 Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray 458 Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de 459 Velde, James Woodyatt, and Bjoern A. Zeeb, for providing valuable 460 comments on earlier versions of this document. 462 The author would like to thank Arturo Servin, who presented this 463 document at IETF 81. 465 This document resulted from the project "Security Assessment of the 466 Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by 467 Fernando Gont on behalf of the UK Centre for the Protection of 468 National Infrastructure (CPNI). The author would like to thank the 469 UK CPNI, for their continued support. 471 8. References 473 8.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 479 RFC 4303, December 2005. 481 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 482 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 483 September 2007. 485 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 486 RFC 5722, December 2009. 488 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 489 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 490 RFC 6564, April 2012. 492 [I-D.ietf-6man-oversized-header-chain] 493 Gont, F. and V. Manral, "Security and Interoperability 494 Implications of Oversized IPv6 Header Chains", 495 draft-ietf-6man-oversized-header-chain-01 (work in 496 progress), July 2012. 498 [I-D.ietf-6man-nd-extension-headers] 499 Gont, F., "Security Implications of the Use of IPv6 500 Extension Headers with IPv6 Neighbor Discovery", 501 draft-ietf-6man-nd-extension-headers-00 (work in 502 progress), June 2012. 504 8.2. Informative References 506 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 507 Problem Statement", RFC 6104, February 2011. 509 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 510 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 511 February 2011. 513 [DHCPv6-Shield] 514 Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6 515 Servers", IETF Internet Draft, 516 draft-gont-opsec-dhcpv6-shield, work in progress, 517 May 2012. 519 [CPNI-IPv6] 520 Gont, F., "Security Assessment of the Internet Protocol 521 version 6 (IPv6)", UK Centre for the Protection of 522 National Infrastructure, (available on request). 524 [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", 525 . 527 [rafixd] "rafixd", . 530 [ramond] "ramond", . 532 [SI6-FRAG] 533 SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 534 fragmentation/reassembly", 2012, . 538 [SI6-IPv6] 539 "SI6 Networks' IPv6 toolkit", 540 . 542 [THC-IPV6] 543 "The Hacker's Choice IPv6 Attack Toolkit", 544 . 546 Appendix A. Assessment tools 548 [SI6-IPv6] is a publicly-available set of tools (for Linux, *BSD, and 549 Mac OS) that implements the techniques described in this document. 551 [THC-IPV6] is a publicly-available set of tools (for Linux) that 552 implements some of the techniques described in this document. 554 Appendix B. Advice and guidance to vendors 556 Vendors are urged to contact CSIRTUK (csirt@cpni.gsi.gov.uk) if they 557 think they may be affected by the issues described in this document. 558 As the lead coordination centre for these issues, CPNI is well placed 559 to give advice and guidance as required. 561 CPNI works extensively with government departments and agencies, 562 commercial organisations and the academic community to research 563 vulnerabilities and potential threats to IT systems especially where 564 they may have an impact on Critical National Infrastructure's (CNI). 566 Other ways to contact CPNI, plus CPNI's PGP public key, are available 567 at http://www.cpni.gov.uk. 569 Author's Address 571 Fernando Gont 572 Centre for the Protection of National Infrastructure 574 Email: fgont@si6networks.com 575 URI: http://www.cpni.gov.uk