Operational Security Capabilities for F. Gont IP Network Infrastructure (opsec) UK CPNI Internet-Draft April 24, 2012 Intended status: BCP Expires: October 26, 2012 Security Implications of IPv6 on IPv4 networks draft-gont-opsec-ipv6-implications-on-ipv4-nets-00 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 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 October 26, 2012. Copyright Notice Copyright (c) 2012 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 Gont Expires October 26, 2012 [Page 1]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Implications of native IPv6 support . . . . . . . . . 4 3. Security Implications of tunneling Mechanisms . . . . . . . . 5 3.1. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 6 3.3. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 7 3.4. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Gont Expires October 26, 2012 [Page 2]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 1 . Introduction RFC2119]. Gont Expires October 26, 2012 [Page 3]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 2 . Security Implications of native IPv6 support 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 IPv6 connectivity (e.g. by sending Router Advertisement messages), possibly circumventing security controls that were are enforced only on IPv4 communications. [Waters2011] provides an example of how this could be achieved using publicly available tools. SLAAC-based attacks [RFC3756] can be mitigated with technologies such as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. However, RA-Guard cannot mitigate attack vectors that employ IPv6 link-local addresses, since configuration of such addresses does not rely on Router Advertisement messages. 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. In some very specific scenarios (e.g., military operations networks) in which only IPv4 service might be desired, a network administrator might disable IPv6 support in all the communicating devices. Gont Expires October 26, 2012 [Page 4]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 3 . Security Implications of tunneling Mechanisms RFC6169] describes the security implications of tunneling mechanisms in detail. Therefore, tunneling mechanisms should be a concern not only to network administrators that have consciously deployed them, but also to network and security administrators whose security policies might be bypassed by exploiting these mechanisms. [CERT2009] contains some examples of how tunnels can be leveraged to bypass firewall rules. To help mitigate these issues, a good security practice is to only allow traffic deemed as "necessary" (i.e., the so-called "default deny" policy). Therefore, security administrators should only allow IPv6 transition co-existence traffic as a result of an explicit decision, rather than as a result of lack of awareness about such traffic. It should be noted that this recommendation is aimed at a network that is the target of such traffic (such as an enterprise network). IPv6-transition traffic should not be filtered e.g. by an ISP when it is transit traffic. Additionally, it is highly recommended that in those networks where specific transition mechanisms are not explicitly deployed, not only the corresponding traffic should be filtered at the organizational perimeter, but also the corresponding mechanisms disabled on each node connected to the organizational network. This not only prevents security breaches resulting from accidental use of these mechanisms, but also disables this functionality altogether, possibly mitigating vulnerabilities that might be present in the host implementation of this 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. 3.1 . Filtering 6to4 RFC3056] is an address assignment and router-to-router, host- to-router, and router-to-host automatic tunnelling mechanism that is meant to provide IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet. Gont Expires October 26, 2012 [Page 5]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, could be easily blocked by filtering IPv4 that contain their Protocol field set to 41. This is the most effective way of filtering such traffic. Additional filtering rules that might be incorporated include: o Filter outgoing IPv4 packets that have their Destination Address set to an address that belongs to the prefix 192.88.99.0/24. o Filter incoming IPv4 packets that have their Source Address set to an address that belongs to the prefix 192.88.99.0/24. 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 their Destination Address set to the IPv4 address of well-known 6to4 relays. o Filter incoming IPv4 packets that have their Destination Address set to the IPv4 address of well-known 6to4 relays. These last two filtering policies will generally be unnecessary, and possibly unfeasible to enforce (given the number of potential 6to4 relays, and the fact that many relays may 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. If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 traffic is allowed, then the following filtering rules could be applied: 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.2 . Filtering ISATAP RFC5214] is an Intra-site tunnelling protocol, and thus it is generally expected that such traffic will not traverse the organizational firewall of an IPv4-only. Nevertheless, ISATAP Gont Expires October 26, 2012 [Page 6]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 traffic is easily filtered as described in Section 3 of this document. 3.3 . Filtering Teredo RFC4380] is an address assignment and automatic tunnelling technology that provides IPv6 connectivity to dual-stack nodes that are behind one or more Network Address Translators (NATs), 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. 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). 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 may 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. 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. As these IPv4 addresses might change over time, an administrator should obtain these addresses himself when implementing the filtering policy, and should also be prepared to maintain this list updated over time. Gont Expires October 26, 2012 [Page 7]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 The corresponding addresses can be easily obtained from a UNIX host by issuing the command 'dig teredo.ipv6.microsoft.com a' (without quotes). 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 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.4 . 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. 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 Stateless Address Auto-configuration (SLAAC), address resolution, etc. Additionally, it would prevent the 6over multicast addresses from being leveraged for the purpose of network reconnaissance. Gont Expires October 26, 2012 [Page 8]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 4 . Security Considerations Gont Expires October 26, 2012 [Page 9]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 5 . Acknowledgements 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. Gont Expires October 26, 2012 [Page 10]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 [CORE2007] CORE, "OpenBSD's IPv6 mbufs remote kernel buffer overflow", 2007, <http://www.coresecurity.com/content/open-bsd-advisorie>. [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). [Waters2011] Waters, A., "SLAAC Attack - 0day Windows Network Interception Configuration Vulnerability", 2011, <http://resources.infosecinstitute.com/slaac-attack/>. Gont Expires October 26, 2012 [Page 12]

Internet-Draft Sec. Impl. of IPv6 on IPv4 networks April 2012 Author's Address Fernando Gont UK Centre for the Protection of National Infrastructure Email: fernando@gont.com.ar URI: http://www.cpni.gov.uk Gont Expires October 26, 2012 [Page 13]