Why Should You Care about IPv6 Security?

By Eric Vyncke

There has been discussion about IPv6 for years now and even though actual IPv6 deployments have become more common since summer 2008, the vast majority of networks only run IPv4. So, why should a network administrator or a security officer care about IPv6 security?

The reason is quite simple: even if a network runs only IPv4, IPv6-enabled hosts can communicate over IPv6 natively with layer-2 adjacent nodes or by using transition mechanisms like 6to4 or ISATAP or Teredo tunnels. As soon as two IPv6 hosts can communicate, this communication channel can be used as an attack channel.

As a result, all network administrators and security officers should learn more about IPv6 and its security threats and mitigation techniques even before deploying IPv6 in their network. This chalk talk further develops the argument by providing a short description of the threats, how the network can detect the use of those tunnels, and how they can be mitigated.

What Are the Tunnel-based Transition Techniques?

The move to IPv6 will not happen overnight or with all routers and nodes moving over IPv6 on a specific point in time. This is a long process that already started years ago. The IETF has standardized several tunnel-based transition techniques to allow a dual-stack node (this is node with IPv4 and IPv6 protocol stacks) to communicate with another IPv6 node over a IPv4-only network (like most of the Internet is in 2009). While some tunnels are statically configured very much like GRE or classic IPsec tunnels, others are dynamic (very much like Cisco Dynamic Multipoint VPN (DMVPN)). The dynamic tunnels include:

  • ISATAP (RFC 5214): To link a single host to a ISATAP tunnel server (such as an IOS router) and through this server to any IPv6 node, it uses IPv4 protocol 41. It is mainly used within an organization because it can be used with RFC 1918 addresses. The default tunnel server is the host named isatap in the default DNS domain. This means that hosts in example.com will try to use isatap.example.com by default.
  • 6to4 (RFC 3056): To connect a single host or multiple networks to IPv6, it relies on IPv4 protocol 41. It requires the use of a globally routable address; or in other words it does not work with RFC 1918 addresses. The default 6to4 relay acting as a gateway between IPv6 and IPv4 has a well-known address: 192.88.99.1, which is anycast (meaning that several organizations run a 6to4 relay and advertise its existence to their neighbor).
  • Teredo (RFC 4380): To link a single computer to IPv6, it relies on UDP to allow the tunnel to traverse NAT devices. Teredo uses UDP port 3544 to communicate with Teredo servers which are used as dispatchers between Teredo clients and Teredo relays. While Teredo was proposed by Microsoft, there exists a Linux version: Miredo.

Tip: A native dual-stack network that runs both IPv4 and IPv6 on all routers and nodes is the Cisco and IETF preferred way to transition to IPv6. It is simpler to deploy and to operate a single network topology with two protocols, IPv4 and IPv6, rather than one physical topology for IPv4 and one logical topology for IPv6 over tunnels.

What Are the Threats of IPv6 in My IPv4 Network?

The threats are relevant only if you do not know the current impact of IPv6 on your existing IPv4-only network. As usual, knowledge is the key element to security. The threats are twofold:

1) Fate-sharing: Dual-stack hosts open two attack channels for the miscreant: over IPv4 and over IPv6. As several operating systems have IPv6 enabled by default (for example, Windows Vista, Windows 2008, Mac OS/X and so on), this means that each and every host running those operating systems must be protected against IPv4 and IPv6 attacks. This is also called fate-sharing: a dual-stack host is as secure as its weakest protocol stack is secure... And quite often, the IPv6 stack has either no protection at all (i.e. no personal IPv6 firewall) or a non-configured protection (i.e. the personal firewall is for both IPv4 and IPv6 but the IPv6 side is not configured).

2) De-perimeterization: Dynamic tunnels are often enabled by default (like 6to4 tunnels) or can be enabled by the users when they install some software packages. An example is µTorrent version 1.8 (a BitTorrent client for Windows) which can configure the Teredo tunnel on behalf of the user. Depending on the security policy of the organization, those dynamic tunnels could traverse the firewall and allow remote IPv6 attackers to attack the internal network from the outside by using this dynamic tunnel, bypassing the perimeter firewall. This is also called perimeter erosion.

Figure 1

An example of fate-sharing is the Cisco IPsec VPN client in the no-split tunneling policy as shown in Figure-1. In order to increase the security of the VPN client over IPv4, the no-split tunneling policy enforces that all IPv4 traffic to and from the remote-access VPN client hosts must be to and from the IPsec tunnel. This policy prevents an IPv4 attacker to attack the VPN client host and use it as a stepping stone to penetrate via the IPsec tunnel into the organization network. The Cisco VPN client is a classic example of the fate-sharing issue because it does not prevent any IPv6 miscreant from attacking the client over IPv6 and in case of success (this is if there was a vulnerability or a Trojan in the client computer), the miscreant can extend his or her reach to the internal organization via the IPsec tunnel.

Of course, if the client is not vulnerable to any attack (for example, because it is patched for all vulnerability or because it runs Cisco Security Agent (CSA)), the IPv6 miscreant will fail to take control of the computer.

And don´t rely on the fact that your network is only IPv4 to ignore this threat... More and more computers are mobile and they could well connect over an IPv6-enabled Wi-Fi hotspot or the user can participate in a conference where the Wi-Fi service includes IPv6 connectivity. Also, if the user moves to a network where his or her computer receives a globally routable IPv4 address (this is not an RFC 1918 address), then the 6to4 tunnel mechanism actually connects the computer to the IPv6 Internet, opening a door to any IPv6 attack.

Even worse, any layer-2 adjacent miscreant can send a single IPv6 packet (called Router Advertisement) and fool the dual-stack victim into believing that IPv6 is enabled on the network; the victim will then immediately configure itself for IPv6 and will open a path for an IPv6 attack.

Figure 2

Figure-2 is an example of the de-perimeterization happening when a dual-stack client installs an IPv6-enabled application (such as µTorrent or Microsoft Meeting Space) on his/her Windows Vista machine. Those applications turn IPv6 on (even if it was disabled by the administrator) and configure the Teredo dynamic tunnel. If the IPv4 security policy at the perimeter firewall is to allow outbound UDP traffic, a dynamic Teredo tunnel is created from the intranet client to an IPv6 server via the Teredo relay.

Figure 3

Figure-3 shows that as soon as this tunnel is created, it has the side effect of allowing any IPv6 miscreant to re-use the same tunnel to attack the internal client. If this attack is successful, the client is now controlled by the miscreant who can start attacking the inside of the organization over IPv4.

How Can I Detect Hidden IPv6 Traffic?

Network operators can easily detect the presence of those threats by detecting:

  • The native IPv6 Ethernet type, 0x86DD (rather than the usual 0x0800 for IPv4) with the use of a sniffer or of a Network Analysis Module (NAM);
  • Some IPv6 tunnels with the use of NetFlow to detect protocol 41 (this is protocol and not UDP/TCP port) or UDP port 3544 (which is the default Teredo UDP port) or traffic to 192.88.99.1 (which is the default anycast address of 6to4 relays).

After reading this article, the security-conscious reader should really jump to his or her favorite NetFlow tool and check for the presence of this traffic.

What Can I Do?

The good news is that the above threats are not critical as soon as the network administrators become aware of them. Indeed, there is no real reason, with the right security products and policies, why an attack over IPv6 would succeed if the IPv4 fails provided that the personal firewall and host intrusion prevention system (such as Cisco Security Agent 6.0) are IPv6 enabled. Therefore, the fate-sharing threat is easily circumvented.

In order to block de-perimeterization caused by the automated tunnels, there are two mitigation techniques:

  • Deploy a native IPv6 in the core and at the edge of your network and enforce the same security policy for IPv4 and IPv6: network firewall, Intrusion Prevention Systems (IPS), IPsec, SSL VPN... This approach has been selected by several large enterprises.
  • Try to block all the tunnels. Block IP protocol 41 and all outbound UDP traffic at the perimeter firewall and try to block native IPv6 either by Windows registry setting (propagating by Active Directory) or by using ACL blocking Ethernet type 0x86dd.

The latter should be avoided because at some point in time, IPv6 will become mandatory even in enterprises and this block-IPv6 policy will have to be revisited.

It must also be noted that the latest Microsoft Vista and XP Service Packs block the Teredo tunnels when the IPv6 firewall is disabled or when the computer is part of an Active Directory domain. With this default policy, and assuming that the user does not tweak his or her configuration, Teredo does not present a threat. Of course, if the user (or an application being installed by the user) disables this policy, the de-perimeterization threat is back.

Conclusion

As usual on security, knowledge is key to secure an information system. Once network managers and security officers know about the fate-sharing and de-perimeterization threats, the mitigation techniques can be applied.

Please note that actually deploying IPv6 in a network also requires more knowledge about IPv6. IPv6 can be made as secure as IPv4 (and even a little bit safer with the help of Secure Neighbor Discovery) but it also requires that all members of the network and security staff (from the architect to the operator) understand IPv6 and its security application.

About the Author:

Eric Vyncke graduated from the University of Liége, Belgium, in 1983 with a Masters degree in Computer Science. Since 1997, he has worked for Cisco as a Distinguished Engineer by helping customers with security design and by assisting product design (notably security). His area of expertise includes the security aspects of LAN switching, IP telephony, and IPv6. He is a guest professor at several Belgian universities and participates regularly at the IETF (author of RFC 3585). He is also a respected speaker at several conferences. He holds a CISSP certification and is the primary author of LAN Switch Security and the co-author of IPv6 Security.

Eric Vyncke

IPv6 Security

IPv6 Security
Scott Hogg, Eric Vyncke
ISBN-10: 158705594X
Pub Date: 12/11/2008
US SRP $60.00
Publisher: Cisco Press