idnits 2.17.1 draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 21, 2012) is 4258 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-ra-guard-implementation-04 == Outdated reference: A later version (-01) exists of draft-gont-opsec-dhcpv6-shield-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for F. Gont 3 IP Network Infrastructure (opsec) UK CPNI 4 Internet-Draft August 21, 2012 5 Intended status: Informational 6 Expires: February 22, 2013 8 Security Implications of IPv6 on IPv4 Networks 9 draft-gont-opsec-ipv6-implications-on-ipv4-nets-02 11 Abstract 13 This document discusses the security implications of native IPv6 14 support and IPv6 transition/co-existence technologies on "IPv4-only" 15 networks, and describes possible mitigations for the aforementioned 16 issues. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, and it may not be 23 published except as an Internet-Draft. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 22, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Security Implications of native IPv6 support . . . . . . . . . 4 56 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4 57 3. Security Implications of tunneling Mechanisms . . . . . . . . 6 58 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 7 60 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7 61 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 7 62 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 9 63 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 9 64 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol 65 (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 72 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 17 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 1. Introduction 77 Most general-purpose operating systems implement and enable by 78 default native IPv6 [RFC2460] support and a number of transition-co- 79 existence technologies. In those cases in which such devices are 80 deployed on networks that are assumed to be IPv4-only, the 81 aforementioned technologies could be leveraged by local or remote 82 attackers for a number of (illegitimate) purposes. 84 For example, a Network Intrusion Detection System (NIDS) might be 85 prepared to detect attack patterns for IPv4 traffic, but might be 86 unable to detect the same attack patterns when a transition/ 87 co-existence technology is leveraged for that purpose. Additionally, 88 an IPv4 firewall might enforce a specific security policy in IPv4, 89 but might be unable to enforce the same policy in IPv6. Finally, 90 some transition/co-existence mechanisms (notably Teredo) are designed 91 to traverse Network Address Port Translation (NAPT) [RFC2663] 92 devices, which in many deployments provide a minimum level of 93 protection by only allowing those instances of communication that 94 have been initiated from the internal network. Thus, these 95 mechanisms might cause an internal host with otherwise limited IPv4 96 connectivity to become globally reachable over IPv6, therefore 97 resulting in increased (and possibly unexpected) host exposure. That 98 is, the aforementioned technologies might inadvertently allow 99 incoming IPv6 connections from the Internet to hosts behind the 100 organizational firewall. 102 In general, the aforementioned security implications can be mitigated 103 by enforcing security controls on native IPv6 traffic and on IPv4- 104 tunneled traffic. Among such controls is the enforcement of 105 filtering policies, such that undesirable traffic is blocked. 107 This document discusses the security implications of IPv6 and IPv6 108 transition/co-existence technologies on (allegedly) IPv4-only 109 networks, and provides guidance on how to mitigate the aforementioned 110 issues. 112 2. Security Implications of native IPv6 support 114 Most popular operating systems include IPv6 support that is enabled 115 by default. This means that even if a network is expected to be 116 IPv4-only, much of its infrastructure is nevertheless likely to be 117 IPv6 enabled. For example, hosts are likely to have at least link- 118 local IPv6 connectivity which might be exploited by attackers with 119 access to the local network. 121 [CORE2007] is a security advisory about a buffer overflow which 122 could be remotely-exploited by leveraging link-local IPv6 123 connectivity that is enabled by default. 125 Additionally, unless appropriate measures are taken, an attacker with 126 access to an 'IPv4-only' local network could impersonate a local 127 router and cause local hosts to enable their 'non-link-local' IPv6 128 connectivity (e.g. by sending Router Advertisement messages), 129 possibly circumventing security controls that were enforced only on 130 IPv4 communications. 132 [THC-IPV6] is the first publicly-available toolkit that 133 implemented this attack vector (along with many others). 135 [Waters2011] provides an example of how this could be achieved 136 using publicly available tools (besides incorrectly claiming the 137 discovery of a "0day vulnerability"). 139 In general, networks should enforce on native IPv6 traffic the same 140 security policies they currently enforce on IPv4 traffic. However, 141 in those networks in which IPv6 has not yet been deployed, and 142 enforcing the aforementioned policies is deemed as unfeasible, a 143 network administrator might mitigate IPv6-based attack vectors by 144 means of appropriate packet filtering. 146 2.1. Filtering Native IPv6 Traffic 148 Some layer-2 devices might have the ability to selectively filter 149 packets based on the type of layer-2 payload. When such 150 functionality is available, IPv6 traffic could be blocked at those 151 layer-2 devices by blocking e.g. Ethernet frames with the Protocol 152 Type field set to 0x86dd [IANA-ETHER]. 154 SLAAC-based attacks [RFC3756] can be mitigated with technologies such 155 as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a 156 similar way, DHCPv6-based attacks can be mitigated with technologies 157 such as DHCPv6-Shield [I-D.gont-opsec-dhcpv6-shield]. However, 158 neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that 159 employ IPv6 link-local addresses, since configuration of such 160 addresses does not rely on Router Advertisement messages or DCHPv6- 161 server messages. 163 In order to mitigate attacks based on native IPv6 traffic, IPv6 164 security controls should be enforced on both IPv4 and IPv6 networks. 165 The aforementioned controls might include: deploying IPv6-enabled 166 NIDS, implementing IPv6 firewalling, etc. 168 In some very specific scenarios (e.g., military operations 169 networks) in which only IPv4 service might be desired, a network 170 administrator might want to disable IPv6 support in all the 171 communicating devices. 173 3. Security Implications of tunneling Mechanisms 175 Unless properly managed, tunneling mechanisms might result in 176 negative security implications ([RFC6169] describes the security 177 implications of tunneling mechanisms in detail). Therefore, 178 tunneling mechanisms should be a concern not only to network 179 administrators that have consciously deployed them, but also to 180 network and security administrators whose security policies might be 181 bypassed by exploiting these mechanisms. 183 [CERT2009] contains some examples of how tunnels can be leveraged 184 to bypass firewall rules. 186 The aforementioned issues could be mitigated by applying the common 187 security practice of only allowing traffic deemed as "necessary" 188 (i.e., the so-called "default deny" policy). Thus, when such policy 189 is enforced IPv6 transition/co-existence traffic would be blocked by 190 default, and would only be allowed as a result of an explicit 191 decision (rather than as a result of lack of awareness about such 192 traffic). 194 It should be noted that this type of policy is usually enforced at 195 a network that is the target of such traffic (such as an 196 enterprise network). IPv6 transition traffic should generally 197 never be filtered e.g. by an ISP when it is transit traffic. 199 In those scenarios in which transition/co-existence traffic is meant 200 to be blocked, it is highly recommended that, in addition to the 201 enforcement of filtering policies at the organizational perimeter, 202 the corresponding transition/co-existence mechanisms be disabled on 203 each node connected to the organizational network. This would not 204 only prevent security breaches resulting from accidental use of these 205 mechanisms, but would also disable this functionality altogether, 206 possibly mitigating vulnerabilities that might be present in the host 207 implementation of these transition/co-existence mechanisms. 209 IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured 210 tunnels) can generally be blocked by dropping IPv4 packets that 211 contain a Protocol field set to 41. Security devices such as NIDS 212 might also include signatures that detect such transition/ 213 co-existence traffic. 215 3.1. Filtering 6in4 217 Probably the most basic type of tunnel employed for connecting IPv6 218 "islands" is the so-called "6in4", in which IPv6 packets are 219 encapsulated within IPv4 packets. These tunnels are typically result 220 from manual configuration at the two tunnel endpoints. 222 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol 223 field of 41. 225 3.2. Filtering 6over4 227 [RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4' 228 (or colloquially as 'virtual Ethernet'), which comprises a set of 229 mechanisms and policies to allow isolated IPv6 hosts located on 230 physical links with no directly-connected IPv6 router, to become 231 fully functional IPv6 hosts by using an IPv4 domain that supports 232 IPv4 multicast as their virtual local link. 234 This transition technology has never been widely deployed, because 235 of the low level of deployment of multicast in most networks. 237 6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol 238 field set to 41. As a result, simply filtering all IPv4 packets that 239 have a Protocol field equal to 41 will filter 6over4 (along with many 240 other transition technologies). 242 A more selective filtering could be enforced such that 6over4 traffic 243 is filtered while other transition traffic is still allowed. Such a 244 filtering policy would block all IPv4 packets that have their 245 Protocol field set to 41, and that have a Destination Address that 246 belongs to the prefix 239.0.0.0/8. 248 This filtering policy basically blocks 6over4 Neighbor Discovery 249 traffic directed to multicast addresses, thus preventing Stateless 250 Address Auto-configuration (SLAAC), address resolution, etc. 251 Additionally, it would prevent the 6over multicast addresses from 252 being leveraged for the purpose of network reconnaissance. 254 3.3. Filtering 6rd 256 6rd builds upon the mechanisms of 6to4 to enable the rapid deployment 257 of IPv6 on IPv4 infrastructures, while avoiding some downsides of 258 6to4. Usage of 6rd was originally documented in [RFC5569], and the 259 mechanism was generalized to other access technologies and formally 260 standardized in [RFC5969]. 262 6rd can be blocked by blocking IPv4 packets with the Protocol field 263 set to 41. 265 3.4. Filtering 6to4 267 6to4 [RFC3056] is an address assignment and router-to-router, host- 268 to-router, and router-to-host automatic tunnelling mechanism that is 269 meant to provide IPv6 connectivity between IPv6 sites and hosts 270 across the IPv4 Internet. 272 The security considerations for 6to4 are discussed in detail in 273 [RFC3964]. 275 As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, 276 could be easily blocked by filtering IPv4 that contain their Protocol 277 field set to 41. This is the most effective way of filtering such 278 traffic. 280 If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 281 traffic is allowed, then more finer-grained filtering rules could be 282 applied. For example, 6to4 traffic could be filtered by applying 283 filtering rules such as: 285 o Filter outgoing IPv4 packets that have the Destination Address set 286 to an address that belongs to the prefix 192.88.99.0/24. 288 o Filter incoming IPv4 packets that have the Source Address set to 289 an address that belongs to the prefix 192.88.99.0/24. 291 It has been suggested that 6to4 relays send their packets with 292 their IPv4 Source Address set to 192.88.99.1. 294 o Filter outgoing IPv4 packets that have the Destination Address set 295 to the IPv4 address of well-known 6to4 relays. 297 o Filter incoming IPv4 packets that have the Source Address set to 298 the IPv4 address of well-known 6to4 relays. 300 These last two filtering policies will generally be unnecessary, 301 and possibly unfeasible to enforce (given the number of potential 302 6to4 relays, and the fact that many relays might remain unknown to 303 the network administrator). If anything, they should be applied 304 with the additional requirement that such IPv4 packets have their 305 Protocol field set to 41, to avoid the case where other services 306 available at the same IPv4 address as a 6to4 relay are mistakenly 307 made inaccessible. 309 If the filtering device has capabilities to inspect the payload of 310 IPv4 packets, then the following filtering rules could be enforced: 312 o Filter outgoing IPv4 packets that have their Protocol field set to 313 41, and that have an IPv6 Source Address (embedded in the IPv4 314 payload) that belongs to the prefix 2002::/16. 316 o Filter incoming IPv4 packets that have their Protocol field set to 317 41, and that have an IPv6 Destination address (embedded in the 318 IPv4 payload) that belongs to the prefix 2002::/16. 320 3.5. Filtering ISATAP 322 ISATAP [RFC5214] is an Intra-site tunnelling protocol, and thus it is 323 generally expected that such traffic will not traverse the 324 organizational firewall of an IPv4-only. Nevertheless, ISATAP can be 325 easily blocked by blocking IPv4 packets with a Protocol field of 41. 327 The most popular operating system that includes an implementation of 328 ISATAP in the default installation is Microsoft Windows. Microsoft 329 Windows obtains the ISATAP router address by resolving the domain 330 name isatap. DNS A resource records. Additionally, they 331 try to learn the ISATAP router address by employing Link-local 332 Multicast Name Resolution (LLMNR) [RFC4795] to resolve the name 333 "isatap". As a result, blocking ISATAP by preventing hosts from 334 successfully performing name resolution for the aforementioned names 335 and/or by filtering packets with specific IPv4 destination addresses 336 is both difficult and undesirable. 338 3.6. Filtering Teredo 340 Teredo [RFC4380] is an address assignment and automatic tunnelling 341 technology that provides IPv6 connectivity to dual-stack nodes that 342 are behind one or more Network Address Port Translation (NAPT) 343 [RFC2663] devices, by encapsulating IPv6 packets in IPv4-based UDP 344 datagrams. Teredo is meant to be a 'last resort' IPv6 connectivity 345 technology, to be used only when other technologies such as 6to4 346 cannot be deployed (e.g., because the edge device has not been 347 assigned a public IPv4 address). 349 As noted in [RFC4380], in order for a Teredo client to configure its 350 Teredo IPv6 address, it must contact a Teredo server, through the 351 Teredo service port (UDP port number 3544). 353 To prevent the Teredo initialization process from succeeding, and 354 hence prevent the use of Teredo, an organizational firewall could 355 filter outgoing UDP packets with a Destination Port of 3544. 357 It is clear that such a filtering policy does not prevent an 358 attacker from running its own Teredo server in the public 359 Internet, using a non-standard UDP port for the Teredo service 360 port (i.e., a port number other than 3544). 362 If the filtering device has capabilities to inspect the payload of 363 IPv4 packets, the following (additional) filtering policy could be 364 enforced: 366 o Filter outgoing IPv4/UDP packets that have that embed an IPv6 367 packet with the "Version" field set to 6, and an IPv6 Source 368 Address that belongs to the prefix 2001::/32. 370 o Filter incoming IPv4/UDP packets that have that embed an IPv6 371 packet with the "Version" field set to 6, and an IPv6 Destination 372 Address that belongs to the prefix 2001::/32. 374 These two filtering rules could, at least in theory, result in 375 false positives. Additionally, they would generally require the 376 filtering device to reassemble fragments prior to enforcing 377 filtering rules, since the information required to enforce them 378 might be missing in the received fragments (which should be 379 expected if Teredo is being employed for malicious purposes). 381 The most popular operating system that includes an implementation of 382 Teredo in the default installation is Microsoft Windows. Microsoft 383 Windows obtains the Teredo server addresses (primary and secondary) 384 by resolving the domain name teredo.ipv6.microsoft.com into DNS A 385 records. A network administrator might want to prevent Microsoft 386 Windows hosts from obtaining Teredo service by filtering at the 387 organizational firewall outgoing UDP datagrams (i.e. IPv4 packets 388 with the Protocol field set to 17) that contain in the IPv4 389 Destination Address any of the IPv4 addresses that the domain name 390 teredo.ipv6.microsoft.com maps to. Additionally, the firewall would 391 filter incoming UDP datagrams from any of the IPv4 addresses to which 392 the domain names of well-known Teredo servers (such as 393 teredo.ipv6.microsoft.com) resolve. 395 As these IPv4 addresses might change over time, an administrator 396 should obtain these addresses when implementing the filtering 397 policy, and should also be prepared to keep this list up to date. 399 The corresponding addresses can be easily obtained from a UNIX 400 host by issuing the command 'dig teredo.ipv6.microsoft.com a' 401 (without quotes). 403 It should be noted that even with all these filtering policies in 404 place, a node in the internal network might still be able to 405 communicate with some Teredo clients. That is, it could configure an 406 IPv6 address itself (without even contacting a Teredo server), and 407 might send Teredo traffic to those peers for which intervention of 408 the host's Teredo server is not required (e.g., Teredo clients behind 409 a cone NAT). 411 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 413 The tunnel broker model enables dynamic configuration of tunnels 414 between a tunnel client and a tunnel server. The tunnel broker 415 provides a control channel for creating, deleting or updating a 416 tunnel between the tunnel client and the tunnel server. 417 Additionally, the tunnel broker may register the user IPv6 address 418 and name in the DNS. Once the tunnel is configured, data can flow 419 between the tunnel client and the tunnel server. [RFC3053] describes 420 the Tunnel Broker model, while [RFC5572] specifies the Tunnel Setup 421 Protocol (TSP), which can be used by clients to communicate with the 422 Tunnel Broker. 424 TSP can use either TCP or UDP as the transport protocol. In both 425 cases TSP uses port number 3653, which has been assigned by the IANA 426 for this purpose. As a result, TSP (the Tunnel Broker control 427 channel) can be blocked by blocking TCP and UDP packets originating 428 from the local network and destined to UDP port 3653 or TCP port 429 3653. Additionally, the data channel can be blocked by blocking UDP 430 packets originated from the local network and destined to UDP port 431 3653, and IPv4 packets with a Protocol field set to 41. 433 4. IANA Considerations 435 There are no IANA registries within this document. The RFC-Editor 436 can remove this section before publication of this document as an 437 RFC. 439 5. Security Considerations 441 This document discusses the security implications of IPv6 on IPv4 442 networks, and describes a number of techniques to mitigate the 443 aforementioned issues. In general, the possible mitigations boil 444 down to enforcing on native IPv6 and IPv6 transition/co-existence 445 traffic the same security policies currently enforced for IPv4 446 traffic, and/or blocking the aforementioned traffic when it is deemed 447 as undesirable. 449 6. Acknowledgements 451 The author would like to thank (in alphabetical order) Ran Atkinson, 452 Panos Kampanakis, David Malone, Arturo Servin, Donald Smith, Tina 453 Tsou, and Eric Vyncke, for providing valuable comments on earlier 454 versions of this document. 456 This document resulted from the project "Security Assessment of the 457 Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by 458 Fernando Gont on behalf of the UK Centre for the Protection of 459 National Infrastructure (CPNI). 461 Fernando Gont would like to thank the UK CPNI for their continued 462 support. 464 7. References 466 7.1. Normative References 468 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 469 (IPv6) Specification", RFC 2460, December 1998. 471 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 472 Domains without Explicit Tunnels", RFC 2529, March 1999. 474 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 475 Tunnel Broker", RFC 3053, January 2001. 477 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 478 via IPv4 Clouds", RFC 3056, February 2001. 480 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 481 Network Address Translations (NATs)", RFC 4380, 482 February 2006. 484 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 485 Multicast Name Resolution (LLMNR)", RFC 4795, 486 January 2007. 488 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 489 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 490 March 2008. 492 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 493 Infrastructures (6rd)", RFC 5569, January 2010. 495 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 496 Infrastructures (6rd) -- Protocol Specification", 497 RFC 5969, August 2010. 499 [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the 500 Tunnel Setup Protocol (TSP)", RFC 5572, February 2010. 502 7.2. Informative References 504 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 505 Translator (NAT) Terminology and Considerations", 506 RFC 2663, August 1999. 508 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 509 Discovery (ND) Trust Models and Threats", RFC 3756, 510 May 2004. 512 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 513 6to4", RFC 3964, December 2004. 515 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 516 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 517 February 2011. 519 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 520 Concerns with IP Tunneling", RFC 6169, April 2011. 522 [I-D.ietf-v6ops-ra-guard-implementation] 523 Gont, F., "Implementation Advice for IPv6 Router 524 Advertisement Guard (RA-Guard)", 525 draft-ietf-v6ops-ra-guard-implementation-04 (work in 526 progress), May 2012. 528 [I-D.gont-opsec-dhcpv6-shield] 529 Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6 530 Servers", draft-gont-opsec-dhcpv6-shield-00 (work in 531 progress), May 2012. 533 [IANA-ETHER] 534 IANA, "Ether Types", 2012, 535 . 537 [CERT2009] 538 CERT, "Bypassing firewalls with IPv6 tunnels", 2009, . 542 [CORE2007] 543 CORE, "OpenBSD's IPv6 mbufs remote kernel buffer 544 overflow", 2007, 545 . 547 [CPNI-IPv6] 548 Gont, F., "Security Assessment of the Internet Protocol 549 version 6 (IPv6)", UK Centre for the Protection of 550 National Infrastructure, (available on request). 552 [THC-IPV6] 553 "The Hacker's Choice IPv6 Attack Toolkit", 554 . 556 [Waters2011] 557 Waters, A., "SLAAC Attack - 0day Windows Network 558 Interception Configuration Vulnerability", 2011, 559 . 561 Appendix A. Summary of filtering rules 563 +------------+------------------------------------------------------+ 564 | Technology | Filtering rules | 565 +------------+------------------------------------------------------+ 566 | Native | EtherType 0x86DD | 567 | IPv6 | | 568 +------------+------------------------------------------------------+ 569 | 6in4 | IP proto 41 | 570 +------------+------------------------------------------------------+ 571 | 6over4 | IP proto 41 | 572 +------------+------------------------------------------------------+ 573 | 6rd | IP proto 41 | 574 +------------+------------------------------------------------------+ 575 | 6to4 | IP proto 41 | 576 +------------+------------------------------------------------------+ 577 | ISATAP | IP proto 41 | 578 +------------+------------------------------------------------------+ 579 | Teredo | UDP Dest Port 3544 | 580 +------------+------------------------------------------------------+ 581 | TB with | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest | 582 | TSP | Port 3653) | 583 +------------+------------------------------------------------------+ 585 Table 1: Summary of filtering rules 587 NOTE: the table above describes general and simple filtering rules 588 for blocking the corresponding traffic. More finer-grained rules 589 might be available in each of the corresponding sections of this 590 document. 592 Author's Address 594 Fernando Gont 595 UK Centre for the Protection of National Infrastructure 597 Email: fernando@gont.com.ar 598 URI: http://www.cpni.gov.uk