idnits 2.17.1 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.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 : ---------------------------------------------------------------------------- == 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 (February 22, 2013) is 4081 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-06) exists of draft-ietf-opsec-vpn-leakages-00 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-dhcpv6-shield-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for F. Gont 3 IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH 4 Internet-Draft W. Liu 5 Intended status: Informational Huawei Technologies 6 Expires: August 26, 2013 February 22, 2013 8 Security Implications of IPv6 on IPv4 Networks 9 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 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. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 26, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Security Implications of Native IPv6 Support . . . . . . . . . 5 54 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5 55 3. Security Implications of Tunneling Mechanisms . . . . . . . . 7 56 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8 57 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8 58 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9 59 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9 60 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10 61 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 10 62 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol 63 (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 12 65 4. Additional Considerations when Filtering IPv6 Traffic . . . . 14 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 72 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 22 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 75 1. Introduction 77 Most general-purpose operating systems implement and enable native 78 IPv6 [RFC2460] support and a number of transition/co-existence 79 technologies by default. For cases in which the corresponding 80 devices are deployed on networks that are assumed to be IPv4-only, 81 native IPv6 support and/or IPv6 transition/co-existence technologies 82 could be leveraged by local or remote attackers for a number of 83 (illegitimate) purposes. For example, 85 o A Network Intrusion Detection System (NIDS) might be prepared to 86 detect attack patterns for IPv4 traffic, but might be unable to 87 detect the same attack patterns when a transition/co-existence 88 technology is leveraged for that purpose. 90 o An IPv4 firewall might enforce a specific security policy in IPv4, 91 but might be unable to enforce the same policy in IPv6. 93 o A NIDS or firewall might support both IPv4 and IPv6, but might be 94 not be configured to enforce on IPv6 traffic the same controls/ 95 policies it enforces on IPv4 traffic. 97 o Some transition/co-existence mechanisms could cause an internal 98 host with otherwise limited IPv4 connectivity to become globally 99 reachable over IPv6, therefore resulting in increased (and 100 possibly unexpected) host exposure. 102 Some transition/co-existence mechanisms (notably Teredo) are 103 designed to traverse Network Address Port Translation (NAPT) 104 [RFC2663] devices, allowing incoming IPv6 connections from the 105 Internet to hosts behind the organizational firewall or NAPT 106 (which in many deployments provides a minimum level of 107 protection by only allowing those instances of communication 108 that have been initiated from the internal network). 110 o IPv6 support could, either inadvertently or as a result of a 111 deliberate attack, result in VPN traffic leaks if IPv6-unaware 112 Virtual Private Network (VPN) software is employed by dual-stacked 113 hosts [I-D.ietf-opsec-vpn-leakages]. 115 In general, most of the aforementioned security implications can be 116 mitigated by enforcing security controls on native IPv6 traffic and 117 on IPv4-tunneled traffic. Among such controls is the enforcement of 118 filtering policies, to block undesirable traffic. While IPv6 119 widespread/global IPv6 deployment has been slower than expected, it 120 is nevertheless happening; and thus, filtering IPv6 traffic (whether 121 native or transition/co-existence) to mitigate IPv6 security 122 implications on IPv4 networks should (generally) only be considered 123 as a temporary measure until IPv6 is deployed. 125 2. Security Implications of Native IPv6 Support 127 Most popular operating systems include IPv6 support that is enabled 128 by default. This means that even if a network is expected to be 129 IPv4-only, much of its infrastructure is nevertheless likely to be 130 IPv6 enabled. For example, hosts are likely to have at least link- 131 local IPv6 connectivity which might be exploited by attackers with 132 access to the local network. 134 [CORE2007] is a security advisory about a buffer overflow which 135 could be remotely-exploited by leveraging link-local IPv6 136 connectivity that is enabled by default. 138 Additionally, unless appropriate measures are taken, an attacker with 139 access to an 'IPv4-only' local network could impersonate a local 140 router and cause local hosts to enable their 'non-link-local' IPv6 141 connectivity (e.g. by sending Router Advertisement messages), 142 possibly circumventing security controls that were enforced only on 143 IPv4 communications. 145 [THC-IPV6] and [IPv6-Toolkit] include tools that implement this 146 attack vector (along with many others). 148 [Waters2013] provides an example of how this could be achieved 149 using publicly available tools. 151 Native IPv6 support could also possibly lead to VPN traffic leakages 152 when hosts employ VPN software that not only does not support IPv6, 153 but that does nothing about IPv6 traffic. 154 [I-D.ietf-opsec-vpn-leakages] describes this issue, along with 155 possible mitigations. 157 In general, networks should enforce on native IPv6 traffic the same 158 security policies currently enforced on IPv4 traffic. However, in 159 those networks in which IPv6 has not yet been deployed, and enforcing 160 the aforementioned policies is deemed as unfeasible, a network 161 administrator might mitigate IPv6-based attack vectors by means of 162 appropriate packet filtering. 164 2.1. Filtering Native IPv6 Traffic 166 Some layer-2 devices might have the ability to selectively filter 167 packets based on the type of layer-2 payload. When such 168 functionality is available, IPv6 traffic could be blocked at those 169 layer-2 devices by blocking, for example, Ethernet frames with the 170 Protocol Type field set to 0x86dd [IANA-ETHER]. 172 SLAAC-based attacks [RFC3756] can be mitigated with technologies such 173 as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a 174 similar way, DHCPv6-based attacks can be mitigated with technologies 175 such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. However, 176 neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that 177 employ IPv6 link-local addresses, since configuration of such 178 addresses does not rely on Router Advertisement messages or DCHPv6- 179 server messages. 181 Administrators considering the filtering of native IPv6 traffic at 182 layer-3 devices are urged to pay attention to the general 183 considerations for IPv6 traffic filtering discussed in Section 4. 185 If native IPv6 traffic is filtered at layer-2, local IPv6 nodes 186 would only get to configure IPv6 link-local addresses. 188 In order to mitigate attacks based on native IPv6 traffic, IPv6 189 security controls should be enforced on both IPv4 and IPv6 networks. 190 The aforementioned controls might include: deploying IPv6-enabled 191 NIDS, implementing IPv6 firewalling, etc. 193 In some very specific scenarios (e.g., military operations 194 networks) in which only IPv4 service might be desired, a network 195 administrator might want to disable IPv6 support in all the 196 communicating devices. 198 3. Security Implications of Tunneling Mechanisms 200 Unless properly managed, tunneling mechanisms might result in 201 negative security implications. For example, they might increase 202 host exposure, might be leveraged to evade security controls, might 203 contain protocol-based vulnerabilities, and/or the corresponding code 204 might contain bugs with security implications. 206 [RFC6169] describes the security implications of tunneling 207 mechanisms in detail. 209 Of the plethora of tunneling mechanisms that have so far been 210 standardized and widely implemented, the so-called "automatic 211 tunneling" mechanisms (such as Teredo, ISATAP, and 6to4) are of 212 particular interest from a security standpoint, since they might 213 be employed without prior consent or action of the user or network 214 administrator. 216 Tunneling mechanisms should be a concern not only to network 217 administrators that have consciously deployed them, but also to those 218 who have not deployed them, as these mechanisms might be leveraged to 219 bypass their security policies. 221 [CERT2009] contains some examples of how tunnels can be leveraged 222 to bypass firewall rules. 224 The aforementioned issues could be mitigated by applying the common 225 security practice of only allowing traffic deemed as "necessary" 226 (i.e., the so-called "default deny" policy). Thus, when such policy 227 is enforced, IPv6 transition/co-existence traffic would be blocked by 228 default, and would only be allowed as a result of an explicit 229 decision. 231 It should be noted that this type of policy is usually enforced on 232 a network that is the target of such traffic (such as an 233 enterprise network). IPv6 transition traffic should generally 234 never be filtered e.g. by an ISP when it is transit traffic. 236 In those scenarios in which transition/co-existence traffic is meant 237 to be blocked, it is highly recommended that, in addition to the 238 enforcement of filtering policies at the organizational perimeter, 239 the corresponding transition/co-existence mechanisms be disabled on 240 each node connected to the organizational network. This would not 241 only prevent security breaches resulting from accidental use of these 242 mechanisms, but would also disable this functionality altogether, 243 possibly mitigating vulnerabilities that might be present in the host 244 implementation of these transition/co-existence mechanisms. 246 IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured 247 tunnels) can generally be blocked by dropping IPv4 packets that 248 contain a Protocol field set to 41. Security devices such as NIDS 249 might also include signatures that detect such transition/ 250 co-existence traffic. 252 Administrators considering the filtering of transition/co-existence 253 traffic are urged to pay attention to the general considerations for 254 IPv6 traffic filtering discussed in Section 4 256 3.1. Filtering 6in4 258 Probably the most basic type of tunnel employed for connecting IPv6 259 "islands" is the so-called "6in4", in which IPv6 packets are 260 encapsulated within IPv4 packets. These tunnels are typically result 261 from manual configuration at the two tunnel endpoints. 263 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol 264 field of 41. 266 3.2. Filtering 6over4 268 [RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4' 269 (or colloquially as 'virtual Ethernet'), which comprises a set of 270 mechanisms and policies to allow isolated IPv6 hosts located on 271 physical links with no directly-connected IPv6 router, to become 272 fully functional IPv6 hosts by using an IPv4 domain that supports 273 IPv4 multicast as their virtual local link. 275 This transition technology has never been widely deployed, because 276 of the low level of deployment of multicast in most networks. 278 6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol 279 field set to 41. As a result, simply filtering all IPv4 packets that 280 have a Protocol field equal to 41 will filter 6over4 (along with many 281 other transition technologies). 283 A more selective filtering could be enforced such that 6over4 traffic 284 is filtered while other transition traffic is still allowed. Such a 285 filtering policy would block all IPv4 packets that have their 286 Protocol field set to 41, and that have a Destination Address that 287 belongs to the prefix 239.0.0.0/8. 289 This filtering policy basically blocks 6over4 Neighbor Discovery 290 traffic directed to multicast addresses, thus preventing Stateless 291 Address Auto-configuration (SLAAC), address resolution, etc. 292 Additionally, it would prevent the 6over multicast addresses from 293 being leveraged for the purpose of network reconnaissance. 295 3.3. Filtering 6rd 297 6rd builds upon the mechanisms of 6to4 to enable the rapid deployment 298 of IPv6 on IPv4 infrastructures, while avoiding some downsides of 299 6to4. Usage of 6rd was originally documented in [RFC5569], and the 300 mechanism was generalized to other access technologies and formally 301 standardized in [RFC5969]. 303 6rd can be blocked by blocking IPv4 packets with the Protocol field 304 set to 41. 306 3.4. Filtering 6to4 308 6to4 [RFC3056] is an address assignment and router-to-router, host- 309 to-router, and router-to-host automatic tunnelling mechanism that is 310 meant to provide IPv6 connectivity between IPv6 sites and hosts 311 across the IPv4 Internet. 313 The security considerations for 6to4 are discussed in detail in 314 [RFC3964]. [RFC6343] provides advice to network operators about 315 6to4 (some of which relates to security mitigations). 317 As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, 318 could be easily blocked by filtering IPv4 that contain their Protocol 319 field set to 41. This is the most effective way of filtering such 320 traffic. 322 If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 323 traffic is allowed, then more finer-grained filtering rules could be 324 applied. For example, 6to4 traffic could be filtered by applying 325 filtering rules such as: 327 o Filter outgoing IPv4 packets that have the Destination Address set 328 to an address that belongs to the prefix 192.88.99.0/24. 330 o Filter incoming IPv4 packets that have the Source Address set to 331 an address that belongs to the prefix 192.88.99.0/24. 333 These rules assume that the corresponding nodes employ the 334 "Anycast Prefix for 6to4 Relay Routers" [RFC3068]. 336 It has been suggested that 6to4 relays send their packets with 337 their IPv4 Source Address set to 192.88.99.1. 339 o Filter outgoing IPv4 packets that have the Destination Address set 340 to the IPv4 address of well-known 6to4 relays. 342 o Filter incoming IPv4 packets that have the Source Address set to 343 the IPv4 address of well-known 6to4 relays. 345 These last two filtering policies will generally be unnecessary, 346 and possibly unfeasible to enforce (given the number of potential 347 6to4 relays, and the fact that many relays might remain unknown to 348 the network administrator). If anything, they should be applied 349 with the additional requirement that such IPv4 packets have their 350 Protocol field set to 41, to avoid the case where other services 351 available at the same IPv4 address as a 6to4 relay are mistakenly 352 made inaccessible. 354 If the filtering device has capabilities to inspect the payload of 355 IPv4 packets, then the following filtering rules could be enforced: 357 o Filter outgoing IPv4 packets that have their Protocol field set to 358 41, and that have an IPv6 Source Address (embedded in the IPv4 359 payload) that belongs to the prefix 2002::/16. 361 o Filter incoming IPv4 packets that have their Protocol field set to 362 41, and that have an IPv6 Destination address (embedded in the 363 IPv4 payload) that belongs to the prefix 2002::/16. 365 3.5. Filtering ISATAP 367 ISATAP [RFC5214] is an Intra-site tunnelling protocol, and thus it is 368 generally expected that such traffic will not traverse the 369 organizational firewall of an IPv4-only. Nevertheless, ISATAP can be 370 easily blocked by blocking IPv4 packets with a Protocol field of 41. 372 The most popular operating system that includes an implementation of 373 ISATAP in the default installation is Microsoft Windows. Microsoft 374 Windows obtains the ISATAP router address by resolving the domain 375 name isatap. DNS A resource records. Additionally, they 376 try to learn the ISATAP router address by employing Link-local 377 Multicast Name Resolution (LLMNR) [RFC4795] to resolve the name 378 "isatap". As a result, blocking ISATAP by preventing hosts from 379 successfully performing name resolution for the aforementioned names 380 and/or by filtering packets with specific IPv4 destination addresses 381 is both difficult and undesirable. 383 3.6. Filtering Teredo 385 Teredo [RFC4380] is an address assignment and automatic tunnelling 386 technology that provides IPv6 connectivity to dual-stack nodes that 387 are behind one or more Network Address Port Translation (NAPT) 388 [RFC2663] devices, by encapsulating IPv6 packets in IPv4-based UDP 389 datagrams. Teredo is meant to be a 'last resort' IPv6 connectivity 390 technology, to be used only when other technologies such as 6to4 391 cannot be deployed (e.g., because the edge device has not been 392 assigned a public IPv4 address). 394 As noted in [RFC4380], in order for a Teredo client to configure its 395 Teredo IPv6 address, it must contact a Teredo server, through the 396 Teredo service port (UDP port number 3544). 398 To prevent the Teredo initialization process from succeeding, and 399 hence prevent the use of Teredo, an organizational firewall could 400 filter outgoing UDP packets with a Destination Port of 3544. 402 It is clear that such a filtering policy does not prevent an 403 attacker from running its own Teredo server in the public 404 Internet, using a non-standard UDP port for the Teredo service 405 port (i.e., a port number other than 3544). 407 If the filtering device has capabilities to inspect the payload of 408 IPv4 packets, the following (additional) filtering policy could be 409 enforced: 411 o Filter outgoing IPv4/UDP packets that have that embed an IPv6 412 packet with the "Version" field set to 6, and an IPv6 Source 413 Address that belongs to the prefix 2001::/32. 415 o Filter incoming IPv4/UDP packets that have that embed an IPv6 416 packet with the "Version" field set to 6, and an IPv6 Destination 417 Address that belongs to the prefix 2001::/32. 419 These two filtering rules could, at least in theory, result in 420 false positives. Additionally, they would generally require the 421 filtering device to reassemble fragments prior to enforcing 422 filtering rules, since the information required to enforce them 423 might be missing in the received fragments (which should be 424 expected if Teredo is being employed for malicious purposes). 426 The most popular operating system that includes an implementation of 427 Teredo in the default installation is Microsoft Windows. Microsoft 428 Windows obtains the Teredo server addresses (primary and secondary) 429 by resolving the domain name teredo.ipv6.microsoft.com into DNS A 430 records. A network administrator might want to prevent Microsoft 431 Windows hosts from obtaining Teredo service by filtering at the 432 organizational firewall outgoing UDP datagrams (i.e. IPv4 packets 433 with the Protocol field set to 17) that contain in the IPv4 434 Destination Address any of the IPv4 addresses that the domain name 435 teredo.ipv6.microsoft.com maps to. Additionally, the firewall would 436 filter incoming UDP datagrams from any of the IPv4 addresses to which 437 the domain names of well-known Teredo servers (such as 438 teredo.ipv6.microsoft.com) resolve. 440 As these IPv4 addresses might change over time, an administrator 441 should obtain these addresses when implementing the filtering 442 policy, and should also be prepared to keep this list up to date. 444 The corresponding addresses can be easily obtained from a UNIX 445 host by issuing the command 'dig teredo.ipv6.microsoft.com a' 446 (without quotes). 448 dig(1) is a free-software tool (part of the "dnsutils" package) 449 produced by the Internet Software Consortium (ISC). 451 It should be noted that even with all these filtering policies in 452 place, a node in the internal network might still be able to 453 communicate with some Teredo clients. That is, it could configure an 454 IPv6 address itself (without even contacting a Teredo server), and 455 might send Teredo traffic to those peers for which intervention of 456 the host's Teredo server is not required (e.g., Teredo clients behind 457 a cone NAT). 459 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 461 The tunnel broker model enables dynamic configuration of tunnels 462 between a tunnel client and a tunnel server. The tunnel broker 463 provides a control channel for creating, deleting or updating a 464 tunnel between the tunnel client and the tunnel server. 465 Additionally, the tunnel broker may register the user IPv6 address 466 and name in the DNS. Once the tunnel is configured, data can flow 467 between the tunnel client and the tunnel server. [RFC3053] describes 468 the Tunnel Broker model, while [RFC5572] specifies the Tunnel Setup 469 Protocol (TSP), which can be used by clients to communicate with the 470 Tunnel Broker. 472 TSP can use either TCP or UDP as the transport protocol. In both 473 cases TSP uses port number 3653, which has been assigned by the IANA 474 for this purpose. As a result, TSP (the Tunnel Broker control 475 channel) can be blocked by blocking TCP and UDP packets originating 476 from the local network and destined to UDP port 3653 or TCP port 477 3653. Additionally, the data channel can be blocked by blocking UDP 478 packets originated from the local network and destined to UDP port 479 3653, and IPv4 packets with a Protocol field set to 41. 481 3.8. Filtering AYIYA 483 AYIYA ("Anything In Anything") [I-D.massar-v6ops-ayiya] allows the 484 tunnelling of packets across Network Address Port Translation (NAPT) 485 [RFC2663] devices. While the specification of this tunneling 486 mechanism was never published as an RFC, it is nevertheless widely 487 deployed [SixXS-stats]. 489 AYIYA can be blocked by blocking TCP and UDP packets originating from 490 the local network and destined to UDP port 5072 or TCP port 5072. 492 4. Additional Considerations when Filtering IPv6 Traffic 494 IPv6 deployments in the Internet are continually increasing, and some 495 hosts default to preferring IPv6 connectivity whenever it is 496 available. This is likely to cause IPv6-capable hosts to attempt to 497 reach an ever-increasing number of popular destinations via IPv6, 498 even if this IPv6 connectivity relies on a transition technology over 499 an IPv4-only network. 501 A large source of IPv6 brokenness today comes from nodes that believe 502 that they have functional IPv6 connectivity, but the path to their 503 destination fails somewhere upstream [Anderson2010] [Anderson2011] 504 [Huston2010b] [Huston2012]. Upstream filtering of transition 505 technologies or situations where a mis-configured node attempts to 506 "provide" native IPv6 service on a given network without proper 507 upstream IPv6 connectivity may result in hosts attempting to reach 508 remote nodes via IPv6, and depending on the absence or presence and 509 specific implementation details of "Happy Eyeballs" [RFC6555], there 510 might be a non-trivial timeout period before the host falls back to 511 IPv4 [Huston2010a] [Huston2012]. 513 For this reason, networks attempting to prevent IPv6 traffic from 514 traversing their devices should consider configuring their local 515 recursive DNS servers to respond to queries for AAAA DNS records with 516 a DNS RCODE of 3 (NXDOMAIN) [RFC1035] or to silently ignore such 517 queries, and should even consider filtering AAAA records at the 518 network ingress point to prevent the internal hosts from attempting 519 their own DNS resolution. This will ensure that hosts which are on 520 an IPv4-only network will only receive DNS A records, and they will 521 be unlikely to attempt to use (likely broken) IPv6 connectivity to 522 reach their desired destinations. 524 Additionally, it should be noted that when filtering IPv6 traffic, it 525 is good practice to signal the packet drop to the source node, such 526 that it is able to react to the packet drop in a more appropriate and 527 timely way. 529 For example, a firewall could signal the packet drop by means of 530 an ICMPv6 error message (or TCP [RFC0793] RST segment if 531 appropriate), such that the source node can e.g. quickly react as 532 described in [RFC5461]. 534 For obvious reasons, if the traffic being filtered is IPv6 535 transition/co-existence traffic, the signalling packet should be 536 sent by means of the corresponding IPv6 transition/co-existence 537 technology. 539 5. IANA Considerations 541 There are no IANA registries within this document. The RFC-Editor 542 can remove this section before publication of this document as an 543 RFC. 545 6. Security Considerations 547 This document discusses the security implications of IPv6 on IPv4 548 networks, and describes a number of techniques to mitigate the 549 aforementioned issues. In general, the possible mitigations boil 550 down to enforcing on native IPv6 and IPv6 transition/co-existence 551 traffic the same security policies currently enforced for IPv4 552 traffic, and/or blocking the aforementioned traffic when it is deemed 553 as undesirable. 555 7. Acknowledgements 557 The authors would like to thank Wes George, who contributed most of 558 the text that comprises Section 4 of this document. 560 The authors would like to thank (in alphabetical order) Ran Atkinson, 561 Brian Carpenter, Joel Jaeggli, Panos Kampanakis, Warren Kumari, David 562 Malone, Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke, for 563 providing valuable comments on earlier versions of this document. 565 This document is based on the results of the the project "Security 566 Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], 567 carried out by Fernando Gont on behalf of the UK Centre for the 568 Protection of National Infrastructure (CPNI). Fernando Gont would 569 like to thank the UK CPNI for their continued support. 571 8. References 573 8.1. Normative References 575 [RFC1035] Mockapetris, P., "Domain names - implementation and 576 specification", STD 13, RFC 1035, November 1987. 578 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 579 (IPv6) Specification", RFC 2460, December 1998. 581 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 582 Domains without Explicit Tunnels", RFC 2529, March 1999. 584 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 585 Tunnel Broker", RFC 3053, January 2001. 587 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 588 via IPv4 Clouds", RFC 3056, February 2001. 590 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 591 RFC 3068, June 2001. 593 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 594 Network Address Translations (NATs)", RFC 4380, 595 February 2006. 597 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 598 Multicast Name Resolution (LLMNR)", RFC 4795, 599 January 2007. 601 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 602 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 603 March 2008. 605 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 606 Infrastructures (6rd)", RFC 5569, January 2010. 608 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 609 Infrastructures (6rd) -- Protocol Specification", 610 RFC 5969, August 2010. 612 [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the 613 Tunnel Setup Protocol (TSP)", RFC 5572, February 2010. 615 8.2. Informative References 617 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 618 RFC 793, September 1981. 620 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 621 Translator (NAT) Terminology and Considerations", 622 RFC 2663, August 1999. 624 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 625 Discovery (ND) Trust Models and Threats", RFC 3756, 626 May 2004. 628 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 629 6to4", RFC 3964, December 2004. 631 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 632 February 2009. 634 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 635 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 636 February 2011. 638 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 639 Concerns with IP Tunneling", RFC 6169, April 2011. 641 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 642 RFC 6343, August 2011. 644 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 645 Dual-Stack Hosts", RFC 6555, April 2012. 647 [I-D.ietf-v6ops-ra-guard-implementation] 648 Gont, F., "Implementation Advice for IPv6 Router 649 Advertisement Guard (RA-Guard)", 650 draft-ietf-v6ops-ra-guard-implementation-07 (work in 651 progress), November 2012. 653 [I-D.ietf-opsec-vpn-leakages] 654 Gont, F., "Virtual Private Network (VPN) traffic leakages 655 in dual-stack hosts/ networks", 656 draft-ietf-opsec-vpn-leakages-00 (work in progress), 657 December 2012. 659 [I-D.ietf-opsec-dhcpv6-shield] 660 Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield: 661 Protecting Against Rogue DHCPv6 Servers", 662 draft-ietf-opsec-dhcpv6-shield-00 (work in progress), 663 December 2012. 665 [I-D.massar-v6ops-ayiya] 666 Massar, J., "AYIYA: Anything In Anything", 667 draft-massar-v6ops-ayiya-02 (work in progress), July 2004. 669 [IANA-ETHER] 670 IANA, "Ether Types", 2012, 671 . 673 [CERT2009] 674 CERT, "Bypassing firewalls with IPv6 tunnels", 2009, . 678 [CORE2007] 679 CORE, "OpenBSD's IPv6 mbufs remote kernel buffer 680 overflow", 2007, 681 . 683 [Huston2010a] 684 Huston, G., "IPv6 Measurements", 2010, 685 . 687 [Huston2010b] 688 Huston, G., "Flailing IPv6", 2010, 689 . 691 [Huston2012] 692 Huston, G., "Bemused Eyeballs: Tailoring Dual Stack 693 Applications for a CGN Environment", 2012, 694 . 696 [Anderson2010] 697 Anderson, T., "Measuring and combating IPv6 brokenness", 698 RIPE 61, Roma, November 2010, 699 . 701 [Anderson2011] 702 Anderson, T., "IPv6 dual-stack client loss in Norway", 703 2011, . 705 [CPNI-IPv6] 706 Gont, F., "Security Assessment of the Internet Protocol 707 version 6 (IPv6)", UK Centre for the Protection of 708 National Infrastructure, (available on request). 710 [IPv6-Toolkit] 711 "SI6 Networks' IPv6 Toolkit", 712 . 714 [THC-IPV6] 715 "The Hacker's Choice IPv6 Attack Toolkit", 716 . 718 [Waters2013] 719 Waters, A., "The SLAAC Attack - using IPv6 as a weapon 720 against IPv4", 2013, . 724 [SixXS-stats] 725 SixXS, "SixXS - IPv6 Deployment & Tunnel Broker :: 726 Statistics", 2013, . 728 Appendix A. Summary of filtering rules 730 +------------+------------------------------------------------------+ 731 | Technology | Filtering rules | 732 +------------+------------------------------------------------------+ 733 | Native | EtherType 0x86DD | 734 | IPv6 | | 735 +------------+------------------------------------------------------+ 736 | 6in4 | IP proto 41 | 737 +------------+------------------------------------------------------+ 738 | 6over4 | IP proto 41 | 739 +------------+------------------------------------------------------+ 740 | 6rd | IP proto 41 | 741 +------------+------------------------------------------------------+ 742 | 6to4 | IP proto 41 | 743 +------------+------------------------------------------------------+ 744 | ISATAP | IP proto 41 | 745 +------------+------------------------------------------------------+ 746 | Teredo | UDP Dest Port 3544 | 747 +------------+------------------------------------------------------+ 748 | TB with | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest | 749 | TSP | Port 3653) | 750 +------------+------------------------------------------------------+ 751 | AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 | 752 +------------+------------------------------------------------------+ 754 Table 1: Summary of filtering rules 756 NOTE: the table above describes general and simple filtering rules 757 for blocking the corresponding traffic. More finer-grained rules 758 might be available in each of the corresponding sections of this 759 document. 761 Authors' Addresses 763 Fernando Gont 764 SI6 Networks / UTN-FRH 765 Evaristo Carriego 2644 766 Haedo, Provincia de Buenos Aires 1706 767 Argentina 769 Phone: +54 11 4650 8472 770 Email: fgont@si6networks.com 771 URI: http://www.si6networks.com 773 Will (Shucheng) Liu 774 Huawei Technologies 775 Bantian, Longgang District 776 Shenzhen 518129 777 P.R. China 779 Email: liushucheng@huawei.com