This tip is a part of the SearchSecurity.com mini learning guide, IPv6 tutorial: Understanding IPv6 security issues, threats, defenses.
In this tip, we’ll briefly introduce these transition/co-existence mechanisms, and explain why they present a variety of compelling security concerns for enterprises.
IPv6 transition/co-existence mechanisms generally follow one of these paradigms:
Dual-stack refers to nodes supporting both the IPv6 and IPv4 protocols. IPv6 is used to communicate with IPv6 nodes, and IPv4 is used when communicating with IPv4 nodes. When it comes to the network itself, this means network devices need to support both versions of the Internet protocol, such that the same (or similar) service is provided with IPv6 as with IPv4. Consequently, this implies some network devices may need to be replaced or upgraded to support IPv6.
The translation paradigm aims at performing translation from IPv6 to IPv4 (and vice-versa), so at least some level of communication is allowed between the two protocols. An example of a translation technology is the so-called “NAT64” mechanism. In the enterprise, this typically involves the deployment of a NAT64 box, which serves to translate packets so IPv6-only devices can communicate with IPv4 servers.
Finally, the tunneling paradigm aims to enable sparse deployment of a protocol in a network dominated by a different network protocol. Thus, tunnels can be used to “connect” islands of a given network protocol (e.g. IPv6) over a network that only supports a different network protocol (e.g., IPv4). Tunnels can be “configured” or “automatic” -- configured tunnels require some form of manual setup, whereas the so-called automatic tunnels usually require no human intervention. Examples of automatic tunnels are Teredo and ISATAP, which are supported and enabled by default in operating systems such as Windows Vista.
IPv6 security issues, concerns for enterprises
While these transition/co-existence mechanisms serve to ease the transition from IPv4 to IPv6, from a security standpoint, however, these mechanisms have proved to be challenging.
First, some operating systems (notably Windows Vista and Windows 7) enable some of these mechanisms by default, which means they might be in use without consent of the user or the network administrator. For example, transition mechanisms could be leveraged to bypass firewalls and/or to circumvent network intrusion detection systems (NIDS).
Secondly, some of these mechanisms (notably Teredo) are designed to traverse Network Address Translators (NATs), which in many deployments provide a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network. As a result, these mechanisms might cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6. As a result, sensitive network assets could become available to savvy attackers via these transition mechanisms.
Thirdly, support for IPv6 transition/co-existence mechanisms in security devices (such as firewalls or NIDSs) lags behind support for IPv4 (or even native IPv6 traffic). Therefore, it may prove to be difficult to enforce on transition/co-existence traffic the same security policies currently enforced on IPv4. For example, an enterprise firewall might allow incoming connections only to specific TCP port numbers, by examining the contents of the corresponding header fields. However, the same firewall might be unable to filter connections with the same granularity if transition/co-existence mechanisms are employed, and thus the header fields of interest (TCP port numbers, etc.) result embedded in several layers of protocols (e.g., TCP/IPv6 packets are tunneled to the server over IPv4/UDP datagrams).
Of the plethora of transition/co-existence mechanisms, the so-called “automatic tunneling” mechanisms are of particular interest from a security standpoint, since they might be used without prior consent of the user or network administrator, and may prove to be difficult to police or monitor, unless specific measures are taken.
For example, 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 pattern when a transition/co-existence technology is leveraged for that purpose. Additionally, an IPv4 firewall might be configured to block incoming connections from the Internet to hosts in the internal network, but may inadvertedly allow incoming IPv6 connections from the Internet to hosts behind the organizational firewall.
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.
In the case of native IPv6 traffic, it can be implicitly blocked at the organizational firewall by only allowing IPv4 traffic. However, an attacker with access to a local network might still be able to leverage the native IPv6 support of local hosts to perform attacks against them. For example, an attacker might cause local hosts to make use of their IPv6 connectivity (since it is supported and enabled by default in most desktop operating systems), and then launch other attacks over IPv6 (rather than over IPv4), possibly remaining undetected by security devices with no IPv6 support. As a result, an enterprise security administrator needs to take necessary measures so these issues are mitigated, namely by implementing IPv6 traffic-monitoring mechanisms and filtering on the local network, or disabling IPv6 support in systems that are not expected to use it.
Translation traffic will be subject to IPv4 or IPv6 security policies, depending on whether the policy is enforced before or after translation. For example, use of NAT64 resulting from IPv6 traffic originating in an organizational network can be implicitly blocked by blocking IPv6 native traffic, as indicated above.
However, enforcing filtering policies on transition/co-existence traffic may be trickier. While most of the tunneling mechanisms can be prevented by blocking IPv4 with a “Protocol” field of 41 (i.e., by blocking IPv4 packets that encapsulate IPv6 packets, other tunneling mechanisms require a finer-grained filtering policy). For example, Teredo clients use the UDP port 3544 to communicate with public Teredo servers. Thus, simply blocking outgoing packets with a UDP destination port of 3544 would prevent communication with public Teredo servers. However, in order to prevent false positives, a security administrator may want to improve this filtering rule by taking into account the IPv4 addresses of public Teredo servers, such that outgoing packets destined to UDP port 3544 are only blocked if they are meant to well-known public Teredo servers.
Other tunneling mechanisms may require similar filtering policies. For example, in the “Tunnel Broker with Tunnel Setup Protocol (TSP),” TSP clients may employ TCP destination port 3653 or UDP destination port 3653 for communicating with a TSP server. While blocking outgoing packets that employ such UDP or TCP port numbers would prevent use of TSP service (assuming the server uses the standardized port), a security administrator might want to improve this filtering rule by taking into account the IPv4 addresses of public TSP servers.
As noted above, enterprises must understand there are a variety of IPv6 security concerns playing out on IPv4 networks, any of which might negatively affect the security of an IPv4 network. Enterprise security administrators must be aware of these IPv6 security issues and take necessary measures to prevent them from affecting the security of their networks.
About the author:
Fernando Gont is a networking and security consultant who has worked on a number of projects on behalf of the UK National Infrastructure Security Coordination Centre (NISCC) and the UK Centre for the Protection of National Infrastructure (CPNI). As part of his work for these organizations, he has authored a series of documents with recommendations for network engineers and implementers of the Internet protocol suite. Gont is an active participant at the IETF (Internet Engineering Task Force), where he contributes to several working groups, and has authored a number of RFCs (Request for Comments). He is a regular speaker at a number of conferences, trade shows, and technical meetings, about information security, operating systems, and Internet engineering. More information is available at his website: http://www.gont.com.ar
This was first published in May 2011