diff options
Diffstat (limited to 'doc/rfc/rfc7123.txt')
| -rw-r--r-- | doc/rfc/rfc7123.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc7123.txt b/doc/rfc/rfc7123.txt new file mode 100644 index 0000000..530d83f --- /dev/null +++ b/doc/rfc/rfc7123.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Gont +Request for Comments: 7123 SI6 Networks/UTN-FRH +Category: Informational W. Liu +ISSN: 2070-1721 Huawei Technologies + February 2014 + + + Security Implications of IPv6 on IPv4 Networks + +Abstract + + This document discusses the security implications of native IPv6 + support and IPv6 transition/coexistence technologies on "IPv4-only" + networks and describes possible mitigations for the aforementioned + issues. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7123. + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Gont & Liu Informational [Page 1] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Security Implications of Native IPv6 Support . . . . . . . . 4 + 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4 + 3. Security Implications of Tunneling Mechanisms . . . . . . . . 5 + 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . 7 + 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7 + 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . 8 + 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . 9 + 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . 9 + 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 11 + 3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 11 + 4. Additional Considerations when Filtering IPv6 Traffic . . . . 12 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 7.2. Informative References . . . . . . . . . . . . . . . . . 14 + Appendix A. Summary of Filtering Rules . . . . . . . . . . . . . 18 + +1. Introduction + + Most general-purpose operating systems implement and enable native + IPv6 [RFC2460] support and a number of transition/coexistence + technologies by default. Support of IPv6 by all nodes is intended to + become best current practice [RFC6540]. Some enterprise networks + might, however, choose to delay active use of IPv6. + + This document describes operational practices to prevent security + exposure in enterprise networks resulting from unplanned use of IPv6 + on such networks. This document is only applicable to enterprise + networks: networks where the network operator is not providing a + general-purpose internet, but rather a business-specific network. + The solutions proposed here are not practical for home networks, nor + are they appropriate for provider networks such as ISPs, mobile + providers, WiFi hotspot providers, or any other public internet + service. + + In scenarios in which IPv6-enabled devices are deployed on enterprise + networks that are intended to be IPv4-only, native IPv6 support and/ + or IPv6 transition/coexistence technologies could be leveraged by + local or remote attackers for a number of (illegitimate) purposes. + For example, + + + + + + +Gont & Liu Informational [Page 2] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + o A Network Intrusion Detection System (NIDS) might be prepared to + detect attack patterns for IPv4 traffic, but might be unable to + detect the same attack patterns when a transition/coexistence + technology is leveraged for that purpose. + + o An IPv4 firewall might enforce a specific security policy in IPv4, + but might be unable to enforce the same policy in IPv6. + + o A NIDS or firewall might support both IPv4 and IPv6, but might not + be configured to enforce on IPv6 traffic the same controls/ + policies it enforces on IPv4 traffic. + + o Some transition/coexistence mechanisms could cause an internal + host with otherwise limited IPv4 connectivity to become globally + reachable over IPv6, therefore resulting in increased (and + possibly unexpected) host exposure. + + NOTE: Some transition/coexistence mechanisms (notably Teredo) + are designed to traverse Network Address Port Translation + (NAPT) [RFC2663] devices, allowing incoming IPv6 connections + from the Internet to hosts behind the organizational firewall + or NAPT (which in many deployments provides a minimum level of + protection by only allowing those instances of communication + that have been initiated from the internal network). + + o IPv6 support could, either inadvertently or as a result of a + deliberate attack, result in Virtual Private Network (VPN) traffic + leaks if IPv6-unaware VPN software is employed by dual-stacked + hosts [VPN-LEAKS]. + + In general, most of the aforementioned security implications can be + mitigated by enforcing security controls on native IPv6 traffic and + on IPv4-tunneled IPv6 traffic. Among such controls, is the + enforcement of filtering policies to block undesirable traffic. + While IPv6 widespread/global IPv6 deployment has been slower than + expected, it is nevertheless happening; and thus, filtering IPv6 + traffic (whether native or transition/coexistence) to mitigate IPv6 + security implications on IPv4 networks should (generally) only be + considered as a temporary measure until IPv6 is deployed. + + NOTE: The aforementioned security controls should contemplate not + only network-based solutions, but also host-based solutions (such + as, e.g., personal firewalls). + + + + + + + + +Gont & Liu Informational [Page 3] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + +2. Security Implications of Native IPv6 Support + + Most popular operating systems include IPv6 support that is enabled + by default. This means that even if a network is expected to be + IPv4-only, much of its infrastructure is nevertheless likely to be + IPv6-enabled. For example, hosts are likely to have at least link- + local IPv6 connectivity, which might be exploited by attackers with + access to the local network. + + Additionally, unless appropriate measures are taken, an attacker with + access to an "IPv4-only" local network could impersonate a local + router and cause local hosts to enable their 'non-link-local' IPv6 + connectivity (e.g., by sending Router Advertisement messages), + possibly circumventing security controls that were enforced only on + IPv4 communications. + + NOTE: [THC-IPV6] and [IPv6-Toolkit] include tools that implement + this attack vector (along with many others). [Waters2011] + provides an example of how this could be achieved using publicly + available tools. + + Native IPv6 support could also possibly lead to VPN-traffic leakages + when hosts employ VPN software that, not only does not support IPv6, + but does nothing about IPv6 traffic. [VPN-LEAKS] describes this + issue, along with possible mitigations. + + In general, networks should enforce on native IPv6 traffic the same + security policies currently enforced on IPv4 traffic. However, in + those networks in which IPv6 has not yet been deployed and enforcing + the aforementioned policies is deemed as infeasible, a network + administrator might mitigate IPv6-based attack vectors by means of + appropriate packet filtering. + +2.1. Filtering Native IPv6 Traffic + + Some layer-2 devices might have the ability to selectively filter + packets based on the type of layer-2 payload. When such + functionality is available, IPv6 traffic could be blocked at those + layer-2 devices by blocking, for example, Ethernet frames with the + Protocol Type field set to 0x86dd [IANA-ETHER]. We note, however, + that blocking IPv6 at layer-2 might create problems that are + difficult to diagnose, inclusive of intentional or incidental use of + link-local addressing (as in Multicast DNS/DNS-based Service + Discovery [RFC6762] [RFC6763]); sites that enforce such a filtering + policy should keep that possibility in mind when debugging the + network. + + + + + +Gont & Liu Informational [Page 4] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + Attacks based on Stateless Address Autoconfiguration (SLAAC) + [RFC3756] can be mitigated with technologies such as Router + Advertisement Guard (RA-Guard) [RFC6105] [RA-GRD-IMP]. In a similar + way, DHCPv6-based attacks can be mitigated with technologies such as + DHCPv6-Shield [SHIELD]. However, both RA-Guard and DHCPv6-Shield are + incapable of mitigating attack vectors that employ IPv6 link-local + addresses, since configuration of such addresses does not rely on + Router Advertisement messages or DHCPv6-server messages. + + Administrators considering the filtering of native IPv6 traffic at + layer-3 devices are urged to pay attention to the general + considerations for IPv6 traffic filtering discussed in Section 4. + + NOTE: If native IPv6 traffic is filtered at layer-2, local IPv6 + nodes would only get to configure IPv6 link-local addresses. + + In order to mitigate attacks based on native IPv6 traffic, IPv6 + security controls should be enforced on both IPv4 and IPv6 networks. + The aforementioned controls might include: deploying IPv6-enabled + NIDS, implementing IPv6 firewalling, etc. + + NOTE: In some very specific scenarios (e.g., military operations + networks) in which only IPv4 service might be desired, a network + administrator might want to disable IPv6 support in all the + communicating devices. + +3. Security Implications of Tunneling Mechanisms + + Unless properly managed, tunneling mechanisms might result in + negative security implications. For example, they might increase + host exposure, might be leveraged to evade security controls, might + contain protocol-based vulnerabilities, and/or the corresponding code + might contain bugs with security implications. + + NOTE: [RFC6169] describes the security implications of tunneling + mechanisms in detail. Of the plethora of tunneling mechanisms + that have so far been standardized and widely implemented, the so- + called "automatic tunneling" mechanisms (such as Teredo, Intra- + Site Automatic Tunnel Addressing Protocol (ISATAP), and 6to4) are + of particular interest from a security standpoint, since they + might be employed without prior consent or action of the user or + network administrator. + + Tunneling mechanisms should be a concern not only to network + administrators that have consciously deployed them, but also to those + who have not deployed them, as these mechanisms might be leveraged to + bypass their security policies. + + + + +Gont & Liu Informational [Page 5] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + NOTE: [CERT2009] contains some examples of how tunnels can be + leveraged to bypass firewall rules. + + The aforementioned issues could be mitigated by applying the common + security practice of only allowing traffic deemed as "necessary" + (i.e., the so-called "default deny" policy). Thus, when such policy + is enforced, IPv6 transition/coexistence traffic would be blocked by + default and would only be allowed as a result of an explicit + decision. + + NOTE: It should be noted that this type of policy is usually + enforced on a network that is the target of such traffic (such as + an enterprise network). IPv6 transition traffic should generally + never be filtered, e.g., by an ISP when it is transit traffic. + + In those scenarios in which transition/coexistence traffic is meant + to be blocked, it is highly recommended that, in addition to the + enforcement of filtering policies at the organizational perimeter, + the corresponding transition/coexistence mechanisms be disabled on + each node connected to the organizational network. This would not + only prevent security breaches resulting from accidental use of these + mechanisms, but would also disable this functionality altogether, + possibly mitigating vulnerabilities that might be present in the host + implementation of these transition/coexistence mechanisms. + + IPv6-in-IPv4 tunneling mechanisms (such as 6to4 or configured + tunnels) can generally be blocked by dropping IPv4 packets that + contain a Protocol field set to 41. Security devices such as NIDS + might also include signatures that detect such transition/coexistence + traffic. + + Administrators considering the filtering of transition/coexistence + traffic are urged to pay attention to the general considerations for + IPv6 traffic filtering discussed in Section 4. + + We note that this document only covers standardized IPv6 tunneling + mechanisms; it does not aim to cover non-standard tunneling + mechanisms or tunneling based on IPsec [RFC4301] or on SSL/TLS + [RFC5246] [RFC6101]. + +3.1. Filtering 6in4 + + Probably the most basic type of tunnel employed for connecting IPv6 + "islands" is the so-called "6in4", in which IPv6 packets are + encapsulated within IPv4 packets. These tunnels typically result + from manual configuration at the two tunnel endpoints. + + + + + +Gont & Liu Informational [Page 6] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol + field of 41. + +3.2. Filtering 6over4 + + [RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4' + (or colloquially as 'virtual Ethernet'), which comprises a set of + mechanisms and policies to allow isolated IPv6 hosts located on + physical links with no directly connected IPv6 router to become fully + functional IPv6 hosts by using an IPv4 domain that supports IPv4 + multicast as their virtual local link. + + NOTE: This transition technology has never been widely deployed + because of the low level of deployment of multicast in most + networks. + + 6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol + field set to 41. As a result, simply filtering all IPv4 packets that + have a Protocol field equal to 41 will filter 6over4 (along with many + other transition technologies). + + A more selective filtering could be enforced such that 6over4 traffic + is filtered while other transition traffic is still allowed. Such a + filtering policy would block all IPv4 packets that have their + Protocol field set to 41, and that have a Destination Address that + belongs to the prefix 239.0.0.0/8. + + This filtering policy basically blocks 6over4 Neighbor Discovery + traffic directed to multicast addresses, thus preventing SLAAC, + address resolution, etc. Additionally, it would prevent the 6over4 + multicast addresses from being leveraged for the purpose of network + reconnaissance. + +3.3. Filtering 6rd + + 6rd builds upon the mechanisms of 6to4 to enable the rapid deployment + of IPv6 on IPv4 infrastructures, while avoiding some downsides of + 6to4. Usage of 6rd was originally documented in [RFC5569], and the + mechanism was generalized to other access technologies and formally + standardized in [RFC5969]. + + 6rd can be blocked by blocking IPv4 packets with the Protocol field + set to 41. + + + + + + + + +Gont & Liu Informational [Page 7] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + +3.4. Filtering 6to4 + + 6to4 [RFC3056] is an address assignment and router-to-router, host- + to-router, and router-to-host automatic tunneling mechanism that is + meant to provide IPv6 connectivity between IPv6 sites and hosts + across the IPv4 Internet. + + NOTE: The security considerations for 6to4 are discussed in detail + in [RFC3964]. [RFC6343] provides advice to network operators + about 6to4 (some of which relates to security mitigations). + + As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, + could be easily blocked by filtering IPv4 packets that contain their + Protocol field set to 41. This is the most effective way of + filtering such traffic. + + If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 + traffic is allowed, then more finer-grained filtering rules could be + applied. For example, 6to4 traffic could be filtered by applying + filtering rules such as: + + o Filter outgoing IPv4 packets that have the Destination Address set + to an address that belongs to the prefix 192.88.99.0/24. + + o Filter incoming IPv4 packets that have the Source Address set to + an address that belongs to the prefix 192.88.99.0/24. + + NOTE: These rules assume that the corresponding nodes employ + the "Anycast Prefix for 6to4 Relay Routers" [RFC3068]. It has + been suggested that 6to4 relays send their packets with their + IPv4 Source Address set to 192.88.99.1. + + o Filter outgoing IPv4 packets that have the Destination Address set + to the IPv4 address of well-known 6to4 relays. + + o Filter incoming IPv4 packets that have the Source Address set to + the IPv4 address of well-known 6to4 relays. + + These last two filtering policies will generally be unnecessary, + and possibly infeasible to enforce (given the number of potential + 6to4 relays, and the fact that many relays might remain unknown to + the network administrator). If anything, they should be applied + with the additional requirement that such IPv4 packets have their + Protocol field set to 41 to avoid the case where other services + available at the same IPv4 address as a 6to4 relay are mistakenly + made inaccessible. + + + + + +Gont & Liu Informational [Page 8] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + If the filtering device has capabilities to inspect the payload of + IPv4 packets, then the following filtering rules could be enforced: + + o Filter outgoing IPv4 packets that have their Protocol field set to + 41, and that have an IPv6 Source Address (embedded in the IPv4 + payload) that belongs to the prefix 2002::/16. + + o Filter incoming IPv4 packets that have their Protocol field set to + 41, and that have an IPv6 Destination address (embedded in the + IPv4 payload) that belongs to the prefix 2002::/16. + +3.5. Filtering ISATAP + + ISATAP [RFC5214] is an Intra-site tunneling protocol, and thus it is + generally expected that such traffic will not traverse the + organizational firewall of an IPv4-only network. Nevertheless, + ISATAP can be easily blocked by blocking IPv4 packets with a Protocol + field of 41. + + The most popular operating system that includes an implementation of + ISATAP in the default installation is Microsoft Windows. Microsoft + Windows obtains the ISATAP router address by resolving the domain + name isatap.<localdomain> to DNS A resource records. Additionally, + it tries to learn the ISATAP router address by employing Link-Local + Multicast Name Resolution (LLMNR) [RFC4795] to resolve the name + "isatap". As a result, blocking ISATAP by preventing hosts from + successfully performing name resolution for the aforementioned names + and/or by filtering packets with specific IPv4 destination addresses + is both difficult and undesirable. + +3.6. Filtering Teredo + + Teredo [RFC4380] is an address assignment and automatic tunneling + technology that provides IPv6 connectivity to dual-stack nodes that + are behind one or more Network Address Port Translation (NAPT) + [RFC2663] devices, by encapsulating IPv6 packets in IPv4-based UDP + datagrams. Teredo is meant to be a 'last-resort' IPv6 connectivity + technology, to be used only when other technologies such as 6to4 + cannot be deployed (e.g., because the edge device has not been + assigned a public IPv4 address). + + As noted in [RFC4380], in order for a Teredo client to configure its + Teredo IPv6 address, it must contact a Teredo server through the + Teredo service port (UDP port number 3544). + + To prevent the Teredo initialization process from succeeding, and + hence prevent the use of Teredo, an organizational firewall could + filter outgoing UDP packets with a Destination Port of 3544. + + + +Gont & Liu Informational [Page 9] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + NOTE: It is clear that such a filtering policy does not prevent an + attacker from running its own Teredo server in the public + Internet, using a non-standard UDP port for the Teredo service + port (i.e., a port number other than 3544). + + If the filtering device has capabilities to inspect the payload of + IPv4 packets, the following (additional) filtering policy could be + enforced: + + o Filter outgoing IPv4/UDP packets that embed an IPv6 packet with + the "Version" field set to 6, and an IPv6 Source Address that + belongs to the prefix 2001::/32. + + o Filter incoming IPv4/UDP packets that embed an IPv6 packet with + the "Version" field set to 6, and an IPv6 Destination Address that + belongs to the prefix 2001::/32. + + NOTE: These two filtering rules could, at least in theory, result + in false positives. Additionally, they would generally require + the filtering device to reassemble fragments prior to enforcing + filtering rules, since the information required to enforce them + might be missing in the received fragments (which should be + expected if Teredo is being employed for malicious purposes). + + The most popular operating system that includes an implementation of + Teredo in the default installation is Microsoft Windows. Microsoft + Windows obtains the Teredo server addresses (primary and secondary) + by resolving the domain name teredo.ipv6.microsoft.com into DNS A + records. A network administrator might want to prevent Microsoft + Windows hosts from obtaining Teredo service by filtering, at the + organizational firewall, outgoing UDP datagrams (i.e., IPv4 packets + with the Protocol field set to 17) that contain in the IPv4 + Destination Address any of the IPv4 addresses that the domain name + teredo.ipv6.microsoft.com maps to (or the IPv4 address of any well- + known Teredo server). Additionally, the firewall would filter + incoming UDP datagrams from any of the IPv4 addresses to which the + domain names of well-known Teredo servers (such as + teredo.ipv6.microsoft.com) resolve. + + NOTE: As these IPv4 addresses might change over time, an + administrator should obtain these addresses when implementing the + filtering policy, and should also be prepared to keep this list up + to date. The corresponding addresses can be easily obtained from + a UNIX host by issuing the command 'dig teredo.ipv6.microsoft.com + a' (without quotes), where dig(1) is a free-software tool (part of + the "dnsutils" package) produced by the Internet Software + Consortium (ISC). + + + + +Gont & Liu Informational [Page 10] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + It should be noted that even with all these filtering policies in + place, a node in the internal network might still be able to + communicate with some Teredo clients. That is, it could configure an + IPv6 address itself (without even contacting a Teredo server), and it + might send Teredo traffic to those peers for which intervention of + the host's Teredo server is not required (e.g., Teredo clients behind + a cone NAT). + +3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) + + The tunnel broker model enables dynamic configuration of tunnels + between a tunnel client and a tunnel server. The tunnel broker + provides a control channel for creating, deleting, or updating a + tunnel between the tunnel client and the tunnel server. + Additionally, the tunnel broker may register the user's IPv6 address + and name in the DNS. Once the tunnel is configured, data can flow + between the tunnel client and the tunnel server. [RFC3053] describes + the tunnel broker model, while [RFC5572] specifies the Tunnel Setup + Protocol (TSP), which can be used by clients to communicate with the + Tunnel Broker. + + TSP can use either TCP or UDP as the transport protocol. In both + cases, TSP uses port number 3653, which has been assigned by the IANA + for this purpose. As a result, TSP (the Tunnel Broker control + channel) can be blocked by blocking TCP and UDP packets originating + from the local network and destined to UDP port 3653 or TCP port + 3653. Additionally, the data channel can be blocked by blocking UDP + packets originated from the local network and destined to UDP port + 3653, and IPv4 packets with a Protocol field set to 41. + +3.8. Filtering AYIYA + + AYIYA ("Anything In Anything") [AYIYA] allows the tunneling of + packets across Network Address Port Translation (NAPT) [RFC2663] + devices. While the specification of this tunneling mechanism was + never published as an RFC, it is nevertheless widely deployed + [SixXS-stats]. + + AYIYA can be blocked by blocking TCP and UDP packets originating from + the local network and destined to UDP port 5072 or TCP port 5072. + + + + + + + + + + + +Gont & Liu Informational [Page 11] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + +4. Additional Considerations when Filtering IPv6 Traffic + + IPv6 deployments in the Internet are continually increasing, and some + hosts default to preferring IPv6 connectivity whenever it is + available. This is likely to cause IPv6-capable hosts to attempt to + reach an ever-increasing number of popular destinations via IPv6, + even if this IPv6 connectivity relies on a transition technology over + an "IPv4-only" network. + + A large source of IPv6 brokenness today comes from nodes that believe + that they have functional IPv6 connectivity, but the path to their + destination fails somewhere upstream [Anderson2010] [Anderson2011] + [Huston2010b] [Huston2012]. Upstream filtering of transition + technologies or situations where a misconfigured node attempts to + "provide" native IPv6 service on a given network without proper + upstream IPv6 connectivity may result in hosts attempting to reach + remote nodes via IPv6, and depending on the absence or presence and + specific implementation details of "Happy Eyeballs" [RFC6555], there + might be a non-trivial timeout period before the host falls back to + IPv4 [Huston2010a] [Huston2012]. + + For this reason, networks attempting to prevent IPv6 traffic from + traversing their devices should consider configuring their local + recursive DNS servers to respond to queries for AAAA DNS records with + a DNS RCODE of 0 (NOERROR) [RFC1035] or to silently ignore such + queries, and should even consider filtering AAAA records at the + network ingress point to prevent the internal hosts from attempting + their own DNS resolution. This will ensure that hosts that are on an + "IPv4-only" network will only receive DNS A records, and they will be + unlikely to attempt to use (likely broken) IPv6 connectivity to reach + their desired destinations. + + We note that in scenarios where DNSSEC [RFC4033] is deployed, + stripping AAAA records from DNS responses would lead to DNS responses + elicited by queries with the DO and CD bits set [RFC4035] to be + considered invalid, and hence discarded. This situation is similar + to that of DNS64 [RFC6147] in the presence of DNSSEC and should be + considered a drawback associated with this approach. + + Additionally, it should be noted that when filtering IPv6 traffic, it + is good practice to signal the packet drop to the source node, such + that it is able to react to the packet drop in a more appropriate and + timely way. For example, a firewall could signal the packet drop by + means of an ICMPv6 error message (or TCP [RFC0793] RST segment if + appropriate), such that the source node can, e.g., quickly react as + described in [RFC5461]. For obvious reasons, if the traffic being + + + + + +Gont & Liu Informational [Page 12] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + filtered is IPv6 transition/coexistence traffic, the signaling packet + should be sent by means of the corresponding IPv6 transition/ + coexistence technology. + +5. Security Considerations + + This document discusses the security implications of IPv6 on IPv4 + networks and describes a number of techniques to mitigate the + aforementioned issues. In general, the possible mitigations boil + down to enforcing on native IPv6 and IPv6 transition/coexistence + traffic the same security policies currently enforced for IPv4 + traffic and/or blocking the aforementioned traffic when it is deemed + as undesirable. + +6. Acknowledgements + + The authors would like to thank Wes George, who contributed most of + the text that comprises Section 4 of this document. + + The authors would like to thank (in alphabetical order) Ran Atkinson, + Brian Carpenter, Stephen Farrell, Guillermo Gont, Joel Jaeggli, Panos + Kampanakis, Warren Kumari, Ted Lemon, David Malone, Joseph Salowey, + Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke for providing + valuable comments on earlier versions of this document. + + This document is based on the results of the project "Security + Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], + carried out by Fernando Gont on behalf of the UK Centre for the + Protection of National Infrastructure (CPNI). Fernando Gont would + like to thank the UK CPNI for their continued support. + +7. References + +7.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 + Domains without Explicit Tunnels", RFC 2529, March 1999. + + [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 + Tunnel Broker", RFC 3053, January 2001. + + + + + +Gont & Liu Informational [Page 13] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", + RFC 3068, June 2001. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, February + 2006. + + [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local + Multicast Name Resolution (LLMNR)", RFC 4795, January + 2007. + + [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site + Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, + March 2008. + + [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 + Infrastructures (6rd)", RFC 5569, January 2010. + + [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 + Infrastructures (6rd) -- Protocol Specification", RFC + 5969, August 2010. + + [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the + Tunnel Setup Protocol (TSP)", RFC 5572, February 2010. + + [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van + Beijnum, "DNS64: DNS Extensions for Network Address + Translation from IPv6 Clients to IPv4 Servers", RFC 6147, + April 2011. + +7.2. Informative References + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + + + + + +Gont & Liu Informational [Page 14] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", RFC + 2663, August 1999. + + [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor + Discovery (ND) Trust Models and Threats", RFC 3756, May + 2004. + + [RFC3964] Savola, P. and C. Patel, "Security Considerations for + 6to4", RFC 3964, December 2004. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, + February 2009. + + [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure + Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, + August 2011. + + [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. + Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, + February 2011. + + [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security + Concerns with IP Tunneling", RFC 6169, April 2011. + + [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", + RFC 6343, August 2011. + + [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, + "IPv6 Support Required for All IP-Capable Nodes", BCP 177, + RFC 6540, April 2012. + + [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with + Dual-Stack Hosts", RFC 6555, April 2012. + + [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, + February 2013. + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, February 2013. + + + + + +Gont & Liu Informational [Page 15] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + [RA-GRD-IMP] + Gont, F., "Implementation Advice for IPv6 Router + Advertisement Guard (RA-Guard)", Work in Progress, + November 2012. + + [VPN-LEAKS] + Gont, F., "Virtual Private Network (VPN) traffic leakages + in dual-stack hosts/ networks", Work in Progress, August + 2013. + + [SHIELD] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: + Protecting Against Rogue DHCPv6 Servers", Work in + Progress, October 2013. + + [AYIYA] Massar, J., "AYIYA: Anything In Anything", Work in + Progress, July 2004. + + [IANA-ETHER] + IANA, "Ethernet Numbers", + <http://www.iana.org/assignments/ethernet-numbers>. + + [CERT2009] Giobbi, R., "Bypassing Firewalls with IPv6 Tunnels", CERT/ + CC Blog, April 2009, <http://www.cert.org/blogs/vuls/2009/ + 04/bypassing_firewalls_with_ipv6.html>. + + [Huston2010a] + Huston, G., "IPv6 Measurements", 2010, + <http://www.potaroo.net/stats/1x1/>. + + [Huston2010b] + Huston, G., "Flailing IPv6", The ISP Column: A monthly + column on things Internet, December 2010, + <http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>. + + [Huston2012] + Huston, G., "Bemused Eyeballs: Tailoring Dual Stack + Applications in a CGN Environment", The ISP Column: A + monthly column on things Internet, May 2012, + <http://www.potaroo.net/ispcol/2012-05/notquite.pdf>. + + [Anderson2010] + Anderson, T., "Measuring and combating IPv6 brokenness", + RIPE 61, Roma, November 2010, + <http://ripe61.ripe.net/presentations/162-ripe61.pdf>. + + [Anderson2011] + Anderson, T., "IPv6 dual-stack client loss in Norway", + 2011, <http://www.fud.no/ipv6/>. + + + +Gont & Liu Informational [Page 16] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + + [CPNI-IPv6] + Gont, F., "Security Assessment of the Internet Protocol + version 6 (IPv6)", UK Centre for the Protection of + National Infrastructure, (available on request), . + + [IPv6-Toolkit] + SI6 Networks, "SI6 Networks' IPv6 Toolkit", + <http://www.si6networks.com/tools/ipv6toolkit>. + + [THC-IPV6] The Hacker's Choice, "THC-IPV6 - attacking the IPV6 + protocol suite", December 2013, + <http://www.thc.org/thc-ipv6/>. + + [Waters2011] + Waters, A., "The SLAAC Attack - using IPv6 as a weapon + against IPv4", April 2011, + <http://wirewatcher.wordpress.com/2011/04/04/ + the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/>. + + [SixXS-stats] + SixXS, , "SixXS - IPv6 Deployment & Tunnel Broker :: + Statistics", 2013, <http://www.sixxs.net/misc/usage/>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gont & Liu Informational [Page 17] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + +Appendix A. Summary of Filtering Rules + + +-------------+-----------------------------------------------------+ + | Technology | Filtering rules | + +-------------+-----------------------------------------------------+ + | Native IPv6 | EtherType 0x86DD | + +-------------+-----------------------------------------------------+ + | 6in4 | IP proto 41 | + +-------------+-----------------------------------------------------+ + | 6over4 | IP proto 41 | + +-------------+-----------------------------------------------------+ + | 6rd | IP proto 41 | + +-------------+-----------------------------------------------------+ + | 6to4 | IP proto 41 | + +-------------+-----------------------------------------------------+ + | ISATAP | IP proto 41 | + +-------------+-----------------------------------------------------+ + | Teredo | UDP Dest Port 3544 | + +-------------+-----------------------------------------------------+ + | TB with TSP | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest | + | | Port 3653) | + +-------------+-----------------------------------------------------+ + | AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 | + +-------------+-----------------------------------------------------+ + + Table 1: Summary of filtering rules + + NOTE: the table above describes general and simple filtering rules + for blocking the corresponding traffic. More finer-grained rules + might be available in each of the corresponding sections of this + document. + + + + + + + + + + + + + + + + + + + + +Gont & Liu Informational [Page 18] + +RFC 7123 Sec. Impl. of IPv6 on IPv4 Networks February 2014 + + +Authors' Addresses + + Fernando Gont + SI6 Networks / UTN-FRH + Evaristo Carriego 2644 + Haedo, Provincia de Buenos Aires 1706 + Argentina + + Phone: +54 11 4650 8472 + EMail: fgont@si6networks.com + URI: http://www.si6networks.com + + + Will (Shucheng) Liu + Huawei Technologies + Bantian, Longgang District + Shenzhen 518129 + P.R. China + + EMail: liushucheng@huawei.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gont & Liu Informational [Page 19] + |