--- 1/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03.txt 2013-05-08 11:44:09.213888964 +0100 +++ 2/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04.txt 2013-05-08 11:44:09.293890770 +0100 @@ -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: August 26, 2013 February 22, 2013 +Expires: November 3, 2013 May 2, 2013 Security Implications of IPv6 on IPv4 Networks - draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 + draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04 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 August 26, 2013. + This Internet-Draft will expire on November 3, 2013. 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 @@ -51,43 +51,45 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Implications of Native IPv6 Support . . . . . . . . . 5 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5 3. Security Implications of Tunneling Mechanisms . . . . . . . . 7 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10 - 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 10 + 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 11 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 12 + 3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 13 4. Additional Considerations when Filtering IPv6 Traffic . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 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. For cases in which the corresponding - 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, + 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, 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 @@ -107,27 +109,31 @@ 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 VPN traffic leaks if IPv6-unaware Virtual Private Network (VPN) software is employed by dual-stacked hosts [I-D.ietf-opsec-vpn-leakages]. In general, most of the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and - on IPv4-tunneled 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/co-existence) to mitigate IPv6 security - implications on IPv4 networks should (generally) only be considered - as a temporary measure until IPv6 is deployed. + 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/co-existence) to mitigate IPv6 + security implications on IPv4 networks should (generally) only be + considered as a temporary measure until IPv6 is deployed. + + The aforementioned security controls should contemplate not only + network-based solutions, but also host-based solutions (such as + e.g. personal firewalls). 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. @@ -244,21 +250,26 @@ implementation of these transition/co-existence mechanisms. IPv6-in-IPv4 tunnelling 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/ co-existence traffic. Administrators considering the filtering of transition/co-existence traffic are urged to pay attention to the general considerations for - IPv6 traffic filtering discussed in Section 4 + IPv6 traffic filtering discussed in Section 4. + + We note that this document only covers standardized IPv6 tunneling + mechanisms, but does not aim to cover non-standard tunneling + mechanisms or IPsec-based [RFC4301] or SSL/TLS-based [RFC5246] + [RFC6101] tunneling of IPv6 packets. 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 are typically result from manual configuration at the two tunnel endpoints. 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol field of 41. @@ -552,22 +563,23 @@ 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, Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke, for - providing valuable comments on earlier versions of this document. + 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 @@ -621,33 +633,47 @@ 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. [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]