Securing IPv6 Transition Technologies
In the previous installment of our series of IPv6 security posts, we covered some of the basic things you need to consider when performing security testing on your IPv6 network. In this post, we will examine some of the things that you need to consider to secure the transition from IPv4 to IPv6. IPv6 is being deployed on more and more networks, but IPv4 is not going away any time soon. During this transition period, security is crucial since you will be running both IPv4 and IPv6, along with various tunneling protocols (even if you did not configure them explicitly) that enable communication between IPv4 and IPv6 networks (such as Teredo, ISATAP, and 6to4).
To begin with, the designers of IPv6 realized that the transition from IPv4 to IPv6 would not happen overnight. There was a hope that there would be a large push and the transition would go rather quickly, but as time moved on, that did not happen. The time for a quick transition has passed and we are in for a long and protracted transition. During this transition, nodes on your network will fit into one of the following buckets:
- IPv4-only node (only runs an IPv4 stack)
- IPv6-only node (only runs an IPv6 stack)
- IPv6/IPv4 node (runs both an IPv4 & IPv6 stack)
Given these types of nodes, the transition mechanisms basically fall into the following categories:
- Dual Stack (running IPv4 & IPv6 simultaneously)
- Tunneling (IPv6 over IPv4 & IPv4 over IPv6)
- Translation (IPv4 to IPv6 & IPv6 to IPv4)
Running a dual stack environment is the simplest way to support IPv4 and IPv6. In this configuration, your devices run two different stacks (IPv4 and IPv6) simultaneously. Therefore, your devices can communicate through either IPv6 or IPv4. Although this appears to give you the best of both worlds, it also presents some interesting security concerns. First, since your devices are running two different stacks, existing ACLs for IPv4 do nothing to stop IPv6 traffic. You may think that this is not a problem since you have not configured IPv6 on your network yet. Think again. Many hosts have IPv6 enabled by default. Combine that with the ability of IPv6 to automatically configure network addresses, and you have a situation in which an attacker can bypass your existing protections and potentially compromise devices on your network, even though you have not yet deployed IPv6.
To enable interoperability between IPv4 hosts and IPv6 hosts, you need a way to encode the 32 bit, IPv4 address inside of the 128 bit, IPv6 address. This enables both the automatic tunneling of IPv6 traffic across an IPv4 network, as well as translation between IPv4 and IPv6 networks. Because of the size of the IPv6 address, numerous methods have been developed for encoding an IPv4 address inside of an IPv6 address. For instance, to maintain backward compatibility with IPv4, RFC 4291 defines both IPv4-compatible and IPv4-mapped addresses (both types begin with 80 0’s) to provide a direct mapping for IPv4 addresses in IPv6. Various tunneling protocols such as ISATAP, 6to4, and Teredo also encode the IPv4 address in the IPv6 address.
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is an automatic tunneling protocol that enables dual-stack devices to transmit IPv6 traffic (encapsulated in IP protocol 41 packets) between each other across an IPv4 backbone. Since ISATAP assumes that multicast is not available on the underlying IPv4 network, it has to have a mechanism for ISATAP hosts to identify potential ISATAP routers to communicate with. You can manually configure this list, but most implementations prefer to use DNS to query the IPv4 network for isatap.company.com (where your local domain is company.com) to identify the location of the ISATAP router. Given an IPv4 address of 22.214.171.124, an ISATAP encodes the IPv4 address into the IPv6 address using the following format:
<64-bit network prefix>:0:5EFE:126.96.36.199 (private address)
- <64-bit network prefix>:200:5EFE:188.8.131.52 (globally unique address)
ISATAP is implemented on most platforms and enabled by default on Microsoft devices.
6to4 also enables dual-stack devices to transmit IPv6 traffic across an IPv4 backbone via 6to4 relay servers without the need to manually configure tunnels. Similar to ISATAP, the tunneled IPv6 traffic is encapsulated in IP protocol 41 packets on the IPv4 network. 6to4 may be used by an individual host, or by a local IPv6 network, but does require the use of a public IPv4 address. Given an IPv4 address of 184.108.40.206, 6to4 encodes the IPv4 address into the IPv6 address by appending the IPv4 address to 2002::/16 in the following format:
- 2002 (16 Bits) + AABB:CCDD (32 Bits) + Subnet ID (16 Bits) + Interface ID (64 bits)
In the 6to4 address, AABB:CCDD represents the IPv6 colon representation of the a.b.c.d IPv4 address. Given our IPv4 address of 220.127.116.11, the 6to4 address would be 2002:ACC0:A005, followed by the Subnet ID and the Interface ID.
A 6to4 relay router connects to both an IPv4 network and an IPv6 network. When it receives encapsulated IPv6 traffic from the IPv4 network, it decapsulates the IPv6 traffic and sends it across the IPv6 network. For IPv6 traffic going to the IPv4 network, it encapsulates the IPv6 packet into an IP protocol 41 packet and uses the IPv4 address encoded in the IPv6 address as the destination address for that IPv4 packet. The 6to4 host must know how to reach the 6to4 relay. This is normally handled by defining a default gateway. To facilitate configuring this default gateway, the anycast address of 18.104.22.168 has been allocated specifically for 6to4 relay routers. This enables you to easily define multiple 6to4 relays on your network without having to alter the configuration on your 6to4 hosts.
Teredo gives full IPv6 connectivity for dual-stack hosts that are connected to the Internet, but which have no direct native connection to an IPv6 network. Teredo encapsulates IPv6 data into IPv4 UDP packets and successfully operates through most NAT boundaries. A Teredo IPv6 address is constructed as follows:
- Teredo Prefix (2001::/32) + Teredo Server IPv4 address + Flags + Obscured External Port + Obscured External Address
Unlike other tunneling protocols, Teredo actually obscures the IPv4 address and port to prevent “smart” NAT devices from translating the information. A Teredo environment is comprised of Teredo clients, Teredo Servers, and Teredo Relays. To communicate with another IPv6 device, a Teredo client encapsulates an ICMPv6 Echo Request to the other device in a UDP packet and sends this to the Teredo server. The server decapsulates the ICMPv6 Echo Request and sends it to the actual IPv6 node. The node will reply with an Echo Reply, but this reply is sent to the appropriate Teredo relay who then contacts the Teredo client. Both the Teredo client and the native IPv6 node utilize the same Teredo relay, which is usually the relay closest to the IPv6 node. This design means that neither the Teredo server nor client needs to know the IPv4 address of any Teredo relays; a suitable one is automatically found by means of the global IPv6 routing table, since all Teredo relays advertise the network 2001:0::/32.
Besides using the Teredo Server to determine the NAT configuration between the Teredo server and the Teredo client, the client also regularly sends IPv4 UDP traffic to the server so that firewall pinholes remain open for the Teredo server and Teredo relay to communicate directly with the client. One of the large security concerns with Teredo tunnels is that it increases your attack surface by assigning globally routable IPv6 addresses to hosts behind NAT devices which are usually not directly accessible from the IPv4 network. This can expose IPv6 services on those hosts to direct attack.
Most of the tunneling protocols used to transition between IPv4 and IPv6 do not provide any security mechanisms. Therefore, you need to secure these tunnels using ACLs and other network controls to prevent them from impacting the security of your overall network (such as preventing IP protocol 41 traffic from entering your network at the edge). This can be a challenging task for the automatic tunneling protocols (such as ISATAP and 6to4) because they can be created without any user interaction. Two main concerns with tunnels are the following:
- IPv4 source address of the encapsulating “outer” packet can be spoofed
- IPv6 address of the encapsulated “inner” packet can be spoofed
Attackers injecting traffic into tunnels is as simple as sending the correctly formatted packets to the specific relay device. Therefore, defining the correct ACLs to limit which traffic can enter and leave tunnels, as well as preventing packets with “spoofed” source addresses from entering your network are crucial to maintaining the security of your network during this transition period.
Besides filtering traffic entering and leaving known tunnel endpoints, it is also vital to filter potential tunnel traffic at various locations within your network to make sure that attackers do not take advantage of these tunnels to transmit information out of your network without detection. These tunnels use UDP and IP Protocol 41 to encapsulate IPv6 traffic on the network. Therefore you need to make sure that these two transports are adequately filtered with your regular network ACLs. Furthermore, if you are using these transition mechanisms to migrate your IPv4 network to an IPv6 network, you need to make sure that hosts are using an official relay device. An attacker impersonating a relay device can gain control of all of the traffic being relayed through it. With ISATAP this should not be that difficult since the location of the relay is being learned from DNS. 6to4, however, utilizes an anycast address so it is easier to impersonate a 6to4 relay unless controls have been implemented that restrict which hosts can generate the normal Router Advertisement messages.
Besides tunneling, some Microsoft systems provide a proxy functionality that can be used to translate traffic between IPv4 and IPv6 network segments. Windows Server 2008 and Windows Vista provide a PortProxy interface that enables the following functionality:
- Proxy IPv4 TCP traffic to another IPv4 address
- Proxy IPv4 TCP traffic to an IPv6 address
- Proxy IPv6 TCP traffic to another IPv6 address
- Proxy IPv6 TCP traffic to an IPv4 address
These translation capabilities are handled by defining corresponding DNS entries that direct the initiating system to send traffic to the specific device that is configured with PortProxy. For instance, to proxy IPv4 TCP traffic to an IPv6 address, the DNS resolver is configured to return an IPv4 address for the IPv6-only host. So when the IPv4 host initiates the TCP conversation, it sends the packets to the IPv4 address provided by DNS. This causes the traffic to be sent to the host with the PortProxy interface, which converts the traffic to IPv6 and sends it to the specific IPv6-only host.
The main security concern with PortProxy is that an attacker may utilize it to bypass existing security controls that are in place on your network. For instance, you may have specific controls in place to limit who can connect between different segments of your network. The PortProxy interface may be used to bypass these restrictions. Note that this is not new to IPv6 since this applies to traffic between two IPv4 addresses as well and is more the result of an attacker taking advantage of a misconfiguration.
This has been a quick look at some of the things to consider when trying to secure your network during the transition period when you have to deal with IPv4 and IPv6 simultaneously. It is crucial to deploy strong security measures to protect your network at all times, but since this transition is going to be long, it is important to be especially vigilant. This also wraps up the series of posts on IPv6. Hopefully, these articles have provided you with some useful information to use as you begin and continue to deploy IPv6 on your network.