Slippery Floor

Even though IPv6 is not establishing itself as expected, it is still making progress. More and more systems on the Internet, as well as on enterprise networks, can communicate and are accessible via IPv6. Mechanisms such as auto-configuration and automatic tunneling mean that IPv6-capable nodes will attempt to establish connections using IPv6. Filtering of IPv6 traffic or the lack of end-to-end connectivity can cause the connection to fail. In this case, the node either cancels the communication action or it tries after failing – and typically after a timeout – to use IPv4 as a fallback mechanism to reach its target, resulting in pronounced delays and unsatisfactory behavior of the IT infrastructure.

Two IPv6 security experts, Fernando Gont (SI6 Networks) and Will Liu (Huawei Technologies), summarized important principles for securing IPv4-only networks in RFC 7123 (Security Implications of IPv6 on IPv4 Networks) [1]. This request for comment still has an "Informational" status, and is thus intended as a basis for discussion and as a guideline for practical applications. In contrast to standard-track RFCs, it is not mandatory.

IPv6 in IPv4-Only Networks

Ever since Windows Vista, IPv6 has been integrated into the Windows TCP/IP stack and enabled by default. To put this another way: Windows always runs in dual-stack mode first, with IPv4 and IPv6 running in parallel (Figure 1). The Linux kernel has supported IPv6 for many years, and nearly all distributors enable it by default. Because of various IPv6 features, such as automatic configuration, transition, and translation technologies (in particular, automatic tunneling), attackers can exploit IPv6 traffic on dual-stack nodes.

This particularly becomes a danger if an admin has no plans to receive IPv6 traffic at this point in time and, thus, has no IPv6-specific security measures in place. Even if the enterprise already has plans for migrating to IPv6, these may only be implemented step-by-step over the course of several years, depending on the size of the enterprise. During the migration phase, therefore, parts of the IT infrastructure still exist that exclusively use IPv4.

Attack Scenarios

RFC 7123 describes various scenarios and examples in which a lack of IPv6 awareness, missing configurations, or missing support for the appropriate IPv6 functions can lead to vulnerabilities. They include:

• Network-based intrusion detection systems (NIDS) that are incapable of detecting the same attack patterns in IPv6 that they would easily detect in IPv4. The danger in particular is known exploits that are simply not detected via IPv6. The same principle applies to intrusion prevention systems.
• Firewalls that have an IPv4 ruleset but do not apply the same rules for IPv6 traffic. The specific problem is detecting and blocking tunneled traffic.
• NIDS and firewalls that may be incapable, from a technological point of view, of implementing the same security policies in IPv6 that they implement for IPv4. Even though vendors often promise full IPv6 support, checking the details often reveals differences in the supported features – especially in the case of extended firewall functions.
• Migration technologies such as tunnels and NAT that make internal hosts that should only have restricted IPv4 connectivity globally accessible using IPv6. This scenario becomes particularly important in the case of technologies designed to work around NAT (e.g.,, the Teredo tunneling technology), which can lead to internal hosts being accessible from the Internet without any protection, simply by using IPv6.
• VPNs that can provide an IPv6-based attack vector in dual-stack scenarios if the VPN software does not support IPv6. Firewalls play a key role in managing these scenarios. Most attack vectors can be closed down by blocking undesirable native IPv6 traffic and tunnel traffic and by disabling IPv6 functionality on the IPv4-only nodes in question.

The Problem with Native IPv6 Support

Popular operating systems support IPv6 natively and enable it by default. Therefore, IPv6 is latently active on an IPv4 network. An IPv6 interface has at least one link-local address enabled. Even if this address is initially restricted to the local link (i.e., the local subnet), communication by this kind of host can be extended in specific situations.

If attackers manage to compromise the router, they can configure it for IPv6 and, say, enable router advertisements. If the attackers configure a prefix that is routed into the local site, the IPv4 nodes, in which dual-stack is enabled, create global unicast addresses, which can then be used to access the Internet (Figure 2).

The biggest problem here is stateless auto-configuration (SLAAC), which is enabled by default on popular operating systems. When an IPv6-enabled endpoint receives a router advertisement with a prefix option (containing a 64-bit IPv6 prefix), it uses this prefix to generate a complete IPv6 address based on specific rules; under some circumstances, this address can be globally unique. To do this, the endpoint uses either the extended EUI 64 format (which is based on the MAC address of the interface) to create the interface ID or the privacy extensions as per RFC 4941 [2].

Alternatively, Windows uses a one-off randomized identifier. In any of these cases, the address is unique, and if the router also has a connection to the enterprise's IPv6 infrastructure, or directly to the Internet, the dual-stack node, which you actually only want to communicate using IPv4, can go online with its IPv6 address.

Even if an IPv6-enabled node does not receive any router advertisements, most operating systems attempt to set up an IPv6 configuration on IPv6-capable interfaces using DHCPv6. If an attacker manages to set up a rogue DHCPv6 server, the nodes can use it to set up a full IPv6 address. The challenge for the attacker is that DHCPv6 currently has no option for setting the node's default gateway, so it either has to be configured via router advertisements or manually.

Security for Native IPv6 Traffic

During the migration phase to IPv6, you need to control IPv6 traffic. The most effective protection against undesirable, native IPv6 traffic is provided by a multi-tiered approach:

• To begin, disable any IPv6 features you do not use; that is, either disable IPv6 completely or at least disable automatic configuration to ensure that the node does not create any IPv6 addresses and that it reliably ignores any router advertisements.
• Network-based protection should be implemented by configuring appropriate filter rules on the packet filters. Even if the enterprise already supports IPv6 communication in some parts of the infrastructure, the components that currently rely exclusively on IPv4 for communication can be blocked for IPv6 traffic with appropriately restrictive filter rules. Again, the typical approach for firewalls applies: as much as necessary, as little as possible. The decisive thing here is that you take a holistic approach to integrating IPv6 into your security planning.
• To provide protection against undesirable IPv6 routers and DHCPv6 servers, you can use features such as RA-Guard (RFC 6105) [3] and DHCPv6-Shield [4]. These functions are implemented on switches and referred to as First Hop Security. SEND (Secure Neighbor Discovery) [5] is an approach that relies on cryptographically generated addresses (CGAs) to provide protection against unauthorized routers and other systems. That said, SEND does require complex configuration on all communication partners and is thus not the approach of choice for protecting IPv4-only networks. However, if you do take the trouble of implementing SEND, you will probably already have enabled IPv6 communication up front.

Other protections relate to security devices such as VPN gateways or network IDs/network IPs (NIDS/NIPS). You will want to configure them for IPv6 awareness, too.

Undesirable Tunnel Traffic

In the scope of IPv6 migration, tunnel technologies provide an option for connecting IPv6 islands across an IPv4-only infrastructure. They provide transmission mechanisms that will be replaced at some time in the future by native IPv6 communication. The problem with some tunnel technologies is that they are automatically enabled in some circumstances: They specifically include:

• 6to4: A tunnel technology designed for communication between IPv6 nodes across the IPv4 Internet.
• ISATAP: The Intra-Site Automatic Tunnel Addressing Protocol is used in particular by Microsoft; it is primarily designed for communication between IPv6 nodes using Intranet structures within an enterprise.
• Teredo: Named after a mollusk, Teredo's specialty is that it can communicate across NAT structures that cause difficulties for other tunnel technologies [6].

What all of these tunnel technologies have in common is that IPv6 packets are encapsulated in IPv4 headers and then forwarded as IPv4 packets (Figure 3), making it very easy for undesirable traffic to pass through firewalls and other security systems that do not correctly validate the content of the IPv4 packets.

Some tunnel mechanisms, such as 6to4 and Teredo, use predefined prefixes, and the algorithm for generating the complete IPv6 tunnel address is designed so that globally unique addresses are created automatically. Therefore, the system that uses the tunnel addresses may be easily accessible from the outside.

Filtering Tunnel Traffic with the Protocol Field

You can quite easily check IPv6 in IPv4 tunneling mechanisms using your (IPv4) firewalls by investigating the Protocol field in the IPv4 header: It regularly has a value of 41 when transporting an IPv6 packet. If your firewall filters this type of packet, tunnel mechanisms are ruled out as an attack vector. You can use this approach to block the following internal mechanisms:

• 6in4 and 6over4: These mechanisms require manual tunnel configuration.
• 6rd: Based on 6to4, 6rd does not use a fixed prefix and can thus principally only be detected by packet filters via the Protocol field of the IPv4 header.
• 6to4: In addition to a value of 41 in the Protocol field, 6to4 uses a prefix of 2002::/16. This prefix can be filtered by appropriate IPv6 firewalls in the IPv6 infrastructure area. However, it often proves more effective to filter for 6to4 relays on the Internet that use the IPv4 Anycast address 192.88.99.1. On your IPv4 Internet gateways, you can thus filter for this target address outgoing, and for this sender address incoming.
• ISATAP: This mechanism does not use any well-known prefix and is actually designed for communication within an enterprise network (intranet). Nevertheless, filtering on Protocol 41 (IPv6 over IPv4) still provides effective protection.

Filtering Tunnel Traffic with Other Mechanisms

Some tunnel variants cannot be identified by looking for Protocol 41 because they use UDP or TCP as their transport protocol and thus either have 17 (UDP) or 6 (TCP) in the Protocol field. One of these variants is Teredo.

This mechanism uses UDP port 3544 to establish the tunnel to the Teredo server. If this port is blocked, Teredo cannot establish the initial connection. Of course, you cannot rule out the possibility of attackers setting up their own Teredo server on the Internet that does not use the default port. For this reason, it can be useful to filter by other criteria.

If your packet filter is capable of inspection, you can filter for an incoming or outgoing IPv4/UDP packet transporting an IPv6 packet with a value of 16 the version field of the header and whose sender or receiver address uses the Teredo prefix 2001::/32. That said, RFC 7123 [7] points out that this approach can lead to false positives if the firewall does not implement these features correctly. In this case, an IPv4/UDP packet would still be blocked, even if it did not contain any Teredo traffic.

Another filtering option is to control DNS traffic. For example, Windows requests the IPv4 host entry (address record A) [8] teredo.ipv6.microsoft.com. This can be checked by your DNS server or filter device, as can the request issued by Windows systems that look for the name isatap.<localdomain>, to discover the ISATAP router.

Another approach for enabling IPv6 traffic through IPv4-only networks relies on tunnel brokers. Tunnel brokers are IPv6 gateways on the Internet that are addressed by a client installed on a dual-stack node. A tunnel is set up between the node and the gateway (server). The dual-stack node communicates using IPv6 through the tunnel with the IPv6 Internet. The decisive difference from other tunnel mechanisms is the explicit installation of an appropriate client.

IPv6 tunnel brokers are described in RFC 3053 [9] and often use the Tunnel Setup Protocol (TSP) defined in RFC 5572 [10]. TSP can use either TCP or UDP as its transport protocol. In both cases, TSP uses port number 3653 to communicate with the server; the port was reserved by the Internet Assigned Numbers Authority (IANA) for this purpose.

The Anything In Anything (AYIYA) tunnel technology has not yet been standardized as a RFC, although it is still fairly widespread because it is designed for communicating through NAPT devices, that is, NAT systems that perform Port Address Translation. For example, AYIYA, used by the well-known tunnel broker SixXS, can be blocked at the IPv4 gateway by filtering outgoing traffic on ports 5072/UDP or 5072/TCP.

Conclusions

Although filtering native IPv6 and tunnel traffic is not particularly difficult from a technical point of view, the first challenge is to identify the problem. With filters, the "as much as necessary and as little as possible" approach always applies. Problems filtering IPv6 traffic that result in failed connections and delays can be mitigated by returning a TCP-RST segment (with the reset flag set) to internal nodes.

Beyond explicit attack scenarios, such as hijacking an IPv6-capable router and manipulating IPv6-capable nodes that are only intended to communicate on IPv4, automatic tunneling mechanisms represent the greatest source of danger in terms of uncontrolled communication of systems with the Internet. Aggravating this situation is that IPv6 is preferred by the popular operating systems, and IPv6 communication is established, even if it is only possible by using a tunnel mechanism.

Another possibility, beyond disabling IPv6 functionality on the endpoints, is to configure the DNS server so that requests from the IPv4-only network for AAAA RR (IPv6 resource records) [11] are either ignored or get a DNS RCODE response of 0 (NOERROR) as per RFC 1035. This ensures that nodes from the IPv4-only network exclusively receive A records (i.e., IPv4 addresses) in the response from the DNS server.

In the long term, the solution is obviously widespread migration to native IPv6 connectivity. One hopes that the current upward trend in IPv6 will lead to IPv6 migration taking the highest priority in the enterprise and thus restricting these transition scenarios and the problems they can cause to the shortest possible period of time.