The Importance of IPv6 and the Internet of Things

How much do you really know about IPv6? Maybe you know it extends the existing IPv4 notation from 32 bits to 128 bits per IP address. Maybe you know that IPv6 addresses can be created automatically from the local system’s MAC address. It’s possible that you understand that IPv6 fields include a routing prefix, subnet ID and the interface identifier (well, for unicast formats). You may even be aware of the multicast and anycast formats — good for you!

The thing is, despite IPv6 having been around for almost 20 years now, few security professionals truly understand it. However, we’d better become Zen with it quickly, because the Internet of Things (IoT) will depend on IPv6 and the new threats they both bring to the party.

Analysts predict that there will be 30 billion connected “things” by 2020, yet the IPv4 address space only accommodates 4 billion and change. Even with network address translation (NAT) and private address space, the IoT’s appetite for addresses will overcome IPv4’s ability to sate it.

Enter IPv6, which expands the address space to 340 undecillion, or 3.4×1038. Well, it’s technically a bit less than that, since some combinations are reserved; nonetheless, that’s still enough usable addresses to allocate about 4,000 to every person on the planet.

We have plenty of time to get up to speed before the IoT is in full bloom, right? Not so fast! Practically all modern operating systems, including mobile, are equipped with IPv6, and most enable it by default. In fact, some modern applications, such as Microsoft Exchange 2013, won’t work without IPv6. The best case that procrastinators can hope for is that IPv6 is to the Internet what the metric system is to U.S. measurement standards: a great and novel idea, but only adopted by academics and enterprises that must use it to speak a common language with like-minded partners.

The reality is that most organizations will eventually need to run IPv6 in conjunction with existing IPv4 infrastructures, further complicating an already complex ecosystem and compromising legacy systems, mobile devices, many forms of the cloud and, now, “things.” As we all know, complexity is the enemy of security, and as security professionals, we have been staring down that barrel for a decade now.

So what are the specific security concerns with IPv6?

IPv6 Is the Pod People of IP Addressing

Whether you planned for it or not, IPv6 has almost certainly already inhabited your systems. Even when you don’t explicitly set an IPv6 address, hosts will autoconfigure one, typically by using its MAC address. This is known as a link-local address and is restricted to IPv6 communication between systems on your local network.

In the spirit of reducing your threat surface, it’s best to disable IPv6 if your enterprise doesn’t use it. However, IPv6 keeps infiltrating your network as you introduce new devices and may even re-enable it through updates and patches after you’ve already disabled IPv6. With the IoT, you may not be able to disable IPv6 and retain functionality, and the ability to configure more than just the basic connectivity options in IoT devices is often hidden from administrators or simply unavailable. Many network printers, while arguably not IoT devices, still hide advanced networking configuration features that security professionals need to be able to tune.

To complicate matters, a link-local address must be configured for each interface on an IPv6-connected device. This includes systems with multiple cabled interfaces and end user systems, which typically have both an Ethernet and a wireless interface. If you configure a global IPv6 address that can be routed on the Internet, each interface must still be assigned a link-local address. In many cases, each interface will have three addresses: an IPv4 address, a link-local IPv6 address and a global IPv6 address. Imagine the complexity of firewall rules for systems that act like Sybil — and we haven’t even introduced IPv6 mobility yet.

Neighbor Discovery Protocol: I Want to Believe

Self-assignment of the link-local address is only the beginning of autoconfiguration. IPv6 introduces the Neighbor Discovery Protocol (NDP), which acts a lot like a combination of IPv4’s Address Resolution Protocol (ARP) and Dynamic Host Control Protocol (DHCP). In fact, although there is a DHCPv6, link-local and global IPv6 address assignments can be performed without it.

IPv6 stateless autoconfiguration works by generating a link-local address, then uses NDP to ensure the address is unique before it commits the address to the interface. The process is somewhat like IPv4 address conflict detection, except IPv6 checks for conflicts before using the address. Next, IPv6 autoconfiguration locates IPv6-capable routers through NDP with the Router Solicitation message or by passively listening for a router advertisement message. Routers direct further activity, which may include a route prefix so the host can generate a global address or indicate that the host should contact the specified DHCPv6 server.

There is good news and bad news here. ARP spoofing is effectively eliminated because link-local addresses use the host’s apparent MAC address as part of the IPv6 address; however, routing protocol attacks are still possible and NDP has its own vulnerabilities and is subject to man-in-the-middle attacks. For example, a nefarious system can hijack routes with rogue router advertisements. Additionally, IPv6 introduces name resolution on local networks that don’t have an IPv6-capable DNS server using the Link-Local Multicast Name Resolution protocol, which is somewhat like NetBIOS broadcast name resolution and suffers from the same types of name manipulation attacks.

Through the IPv6 Wormhole

To help the transition to IPv6 while knowing that it would have to coexist with existing networks for a time, there are a number of encapsulation and tunneling protocols that transport IPv6 traffic across IPv4 networks. They include 6to4, the Intra-Site Automatic Tunnel Addressing Protocol and Teredo. Of the three, Teredo, designed by Microsoft, is the most comprehensive, and the only one that works across NAT routers and firewalls.

Tunneling in general poses a security dilemma. In order to impose appropriate restrictions in the form of access control lists, rules and content analytics, security solutions have to recognize the tunnel, expose the base encapsulated traffic and understand IPv6. Teredo in particular has features that cause concern for security, such as “bubble-to-open.” In order for an external attacker to create a tunnel with a target across a stateful firewall, the internal target must first create an outbound connection to the attacker, thereby causing the firewall to add an entry to the state table by allowing the return communication. Bubble-to-open provides a means for the external attacker to solicit this interaction.

There are other tunneling attacks that could take advantage of IPv6-specific features or general IP features that may have not been hardened in the IPv6 stack. For example, attackers can gain access first to an internal system running IPv6, then “bounce through” that target system using source routing to move laterally and access other internal systems. Alternatively, an attack source can be obfuscated by bouncing through a series of IPv6 nodes. Source routing is also available in IPv4, but network and security administrators have disabled it as a standard practice for years. By adding IPv6, operations procedures will need to take into account yet another factor, with all its special security needs.

Quantum Computing or Schrödinger’s Mobility

As previously alluded to, IPv6 introduces the concept of mobility. That is, a device can retain a virtual point of presence on one network while it is connected to another. It’s always reachable by its “home” address regardless of its location in the IPv6 network. Imagine you want to participate on your corporate network while you’re visiting a customer or traveling around the world. The solution in IPv4 is to implement some sort of virtual private network, which often requires third-party solutions with a network gateway device and heavyweight client software on the mobile node. In contrast, this functionality is designed into IPv6.

While there are no specific security concerns around mobility, it effectively tunnels connections from the remote network back to the home network, which introduces the same potential attacks as other IPv6 tunneling methods. Additionally, mobility adds configuration complexity.

DDoS Attacks

There has been a recent shift away from moderately connected endpoints to well-connected servers to launch distributed denial-of-service attacks. Rather than 100,000 old Gateway 2000 PCs connected to cable modems, attackers have been able to achieve up to 400 Gbps with amplification attacks through DNS and NDP servers on fast pipes. Expand the address space by 1 trillion times multiplied by 1 trillion times multiplied by another 1 trillion times 79 (79,228,162,514,264,300,000,000,000,000, to be exact), or to be more realistic, 10 times the IP addresses by 2020 that are in use today, and you’ve got a galactic arsenal of potential bots. That’s a massive surge in not only bandwidth clogging, but also in terms of tracking and blocking.

Security Technology Isn’t Ready for the Invasion

Of greatest concern, however, is that most current security technology is built around IPv4. For example, firewalls and intrusion detection and prevention systems may be blind to IPv6 attacks, most, if not all, logging management systems have been designed to index on IPv4 addresses and threat intelligence databases may not include IPv6 addresses with their IPv4 counterparts. To be fair, some systems include IPv6 fields, but they’re often not primary indices and some may simply be textual fields without the ability to search with IPv6 syntax. For example, the system needs to know that the following represent the same IPv6 address — or that ::1/128 is the loopback address (localhost):

  • 2001:0000:3238:DFE1:63:0000:0000:FEFB
  • 2001:0000:3238:DFE1:63::FEFB
  • 2001:0:3238:DFE1:63::FEFB

More than just a matter of interpretation, software algorithms have been developed and fine-tuned to search for IPv4 addresses at wire speed. Those algorithms will now have to be adapted and optimized for IPv6 addresses, as well.

Take Control, Dispel Superstition

It is important to understand that many vulnerabilities in IPv6 and associated attacks are largely theoretical. Because IPv6 has only yet been implemented in small pockets — and unwittingly, but nominally, in almost all networks — there have been no published real-world breaches. It’s possible that some of the attacks mentioned above or by other security researchers are not functional in practice. If nothing else, they serve as a thought exercise and warning to us all before IPv6 becomes the new norm. Now is the time to prepare by doing the following:

  • Get up to speed on IPv6 concepts and operations, including address types, syntax, configuration, supporting protocols such as the NDP, tunneling and IPSec extensibility.
  • Evaluate your security technology for IPv6 preparedness. Don’t just look for “IPv6” in their documentation; dig in and hold the vendor’s feet to the fire to prove its product can deal with IPv6 addresses and associated features as well as IPv4. Get the vendor to commit to its plan to support IPv6 or plan to change vendors.
  • Update your own security program and procedures to address IPv6 and the IoT. How do you plan to migrate to IPv6? Which protections will you implement? Will you embrace the IoT? For what business purpose? Within which business units? How will you monitor and protect IoT devices?

One Layer Does Not a Catastrophe Make

Despite the inherent dangers in IPv6, it is still an advancement over IPv4 both in functionality and in secure operation — and it’s just one layer of the ISO network model. Beyond the addressing and routing changes, pretty much everything else remains the same. That means our strategy to protect applications is still valid, as is our knowledge of IP protocols and ports.

And it will be required to support the IoT.

Share this Article:
Chris Poulin

Research Strategist, X-Force R&D, IBM

Chris Poulin brings a balance of management experience and technical skills encompassing 30 years in information security, software development, and IT management, to his role as Research Strategist for IBM’s X-Force Research & Development team. Chris is responsible for researching and analyzing security trends, creating programs to help customers keep pace with emerging threats, and forging the vision for a secure planet. Chris joins IBM through the Q1 Labs acquisition, where he served as CSO. He started his security career in the U.S. Air Force managing global intelligence networks and developing software. Chris left the Department of Defense to leverage his leadership and technical skills to found and build FireTower, Inc., a successful information security consulting firm serving many Fortune 100 clients.