--- 1/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04.txt 2013-07-05 09:14:23.582136716 -0700 +++ 2/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.txt 2013-07-05 09:14:23.622137745 -0700 @@ -1,19 +1,19 @@ Operational Security Capabilities for F. Gont IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH Internet-Draft W. Liu Intended status: Informational Huawei Technologies -Expires: November 3, 2013 May 2, 2013 +Expires: January 6, 2014 July 5, 2013 Security Implications of IPv6 on IPv4 Networks - draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04 + draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05 Abstract This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. Status of this Memo @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 3, 2013. + This Internet-Draft will expire on January 6, 2014. Copyright Notice Copyright (c) 2013 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 @@ -71,25 +71,37 @@ 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/co-existence 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. In scenarios in - which the aforementioned devices are deployed on networks that are - assumed to be IPv4-only, native IPv6 support and/or IPv6 transition/ - co-existence technologies could be leveraged by local or remote - attackers for a number of (illegitimate) purposes. For example, + might, however, choose to delay active use of IPv6. + + This document describes operational practices for enterprise networks + to prevent security exposure 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/co-existence technologies could be leveraged + by local or remote attackers for a number of (illegitimate) purposes. + For example, 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/co-existence 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 be @@ -130,24 +142,20 @@ 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. - [CORE2007] is a security advisory about a buffer overflow which - could be remotely-exploited by leveraging link-local IPv6 - connectivity that is enabled by default. - 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. [THC-IPV6] and [IPv6-Toolkit] include tools that implement this attack vector (along with many others). @@ -166,21 +174,24 @@ the aforementioned policies is deemed as unfeasible, 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]. + Protocol Type field set to 0x86dd [IANA-ETHER]. We note, however, + that enforcement of such filtering policy would break applications + that expect IPv6 link-local connectivity to work properly (e.g. + Bonjour). SLAAC-based attacks [RFC3756] can be mitigated with technologies such as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a similar way, DHCPv6-based attacks can be mitigated with technologies such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. However, neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages or DCHPv6- server messages. @@ -517,21 +528,21 @@ "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 3 (NXDOMAIN) [RFC1035] or to silently ignore such + 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 which 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. 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 @@ -562,24 +573,24 @@ traffic the same security policies currently enforced for IPv4 traffic, and/or blocking the aforementioned traffic when it is deemed as undesirable. 7. 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, Joel Jaeggli, Panos Kampanakis, Warren Kumari, David - Malone, Joseph Salowey, Arturo Servin, Donald Smith, Tina Tsou, and - Eric Vyncke, for providing valuable comments on earlier versions of - this document. + Brian Carpenter, Stephen Farrell, 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 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. 8. References 8.1. Normative References @@ -672,22 +683,22 @@ [I-D.ietf-v6ops-ra-guard-implementation] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-guard-implementation-07 (work in progress), November 2012. [I-D.ietf-opsec-vpn-leakages] Gont, F., "Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks", - draft-ietf-opsec-vpn-leakages-00 (work in progress), - December 2012. + draft-ietf-opsec-vpn-leakages-01 (work in progress), + June 2013. [I-D.ietf-opsec-dhcpv6-shield] Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", draft-ietf-opsec-dhcpv6-shield-00 (work in progress), December 2012. [I-D.massar-v6ops-ayiya] Massar, J., "AYIYA: Anything In Anything", draft-massar-v6ops-ayiya-02 (work in progress), July 2004.