With so much attention focused on the recent deadline for U.S. government agencies to deploy IPv6 on their public-facing websites, it’s important to raise the flag on a much less discussed, but critically important aspect of IPv6. Namely, that the rapid expansion of unplanned and unmonitored IPv6-enabled systems in ‘IPv4-only’ networks is greatly increasing the attack surface presented by those networks.

Limited awareness of IPv6 security issues and incomplete support for IPv6 vulnerability detection in commercial firewall and intrusion detection products are exposing both commercial and government enterprises to cyber attack.

The IPv4 protocol is the primary communications protocol of the Internet. As early as 1992, the IPv4 limit of 4 billion addresses for network-connected devices was recognized as insufficient to support the rapidly increasing growth of the Internet. The Internet Engineering Task Force embarked on a project to define a replacement protocol for IPv4, eventually labeled as IPv6, to resolve the IPv4 address exhaustion problem and support additional capabilities.

The lack of awareness and insufficient IPv6 security defenses are exposing ‘IPv4-only’ networks to attack and exploitation.”

The quantity of addresses supported by the IPv6 protocol is so vast that an IPv6 address could be assigned to every atom on the surface of the earth and still have enough addresses left to cover another 100 earth-sized planets.

This vastly increased address space enables continued growth of the Internet and support for new services and applications. IPv6 also introduces a redesigned protocol that is streamlined and extensible, improving router efficiency and making it adaptable to future protocol requirements. Additional features include network auto-configuration, improved support for end-to-end security, quality of service capabilities and mobile support.

The IPv6 protocol specification was published in 1996 and the last decade and a half has seen much experimentation, testing and refinement. Greatly spurred on by government initiatives to advance support for IPv6 in commercial products, most network equipment, computer operating systems and mobile devices now ship with operational IPv6 communications stacks in addition to the traditional IPv4 communication stack. Just as in the early days of IPv4 adoption, it will take time for these IPv6 software implementations to mature.

While we gain more experience with these IPv6 implementations, vulnerabilities, implementation errors and misconfigurations will continue to expose these systems to penetration and denial-of-service attacks.

The MITRE Common Vulnerabilities and Exposures (CVE) database details over 100 known IPv6 vulnerabilities, and that list continues to grow. Increasingly sophisticated attack tools are available to exploit these known vulnerabilities, and through fuzzing techniques, identify new ones.

When plugged into a network, these dual-stack systems will automatically configure themselves into a local IPv6 network and start querying their neighbors for the configuration information necessary to communicate beyond the local network and to the IPv6 Internet. This built-in IPv6 auto-configuration capability, known as Stateless Address Auto-Configuration, or SLAAC, lacks any form of authentication or integrity checking, making it susceptible to spoofing through the impersonation of a valid configuration information source. Essentially, an attacker who can reach these nodes can configure this unmonitored IPv6 network on-demand to support exfiltration of data and deeper penetration into the enterprise environment.

IPv6 tunnels, which encapsulate IPv6 packets inside of IPv4 packets, present another important security issue. IPv6 tunnels enable IPv6-capable systems to reach other IPv6 systems and the IPv6 Internet over an IPv4 network. IPv6 tunnels were intended to aid in the transition of IPv4 to IPv6, but they also can be used to bypass firewalls and intrusion detection systems, supporting covert communications and aiding in exfiltration of data.

Many operating systems ship with support for automatically configured tunnels that can result in unintended and unmonitored connections from inside the enterprise to the IPv6 Internet. For example, all Windows operating system versions since Windows Vista ship with support for ISATAP, 6to4 and Teredo automatic tunnels. Under the right conditions, the Windows operating system will automatically attempt to configure each of these types of tunnels and create a persistent, routable IPv6 tunnel through the enterprise and to the IPv6 Internet.

The unintended presence of native IPv6 traffic and IPv6 tunnels in ‘IPv4-only’ networks introduces a whole new class of network vulnerabilities. Unfortunately, most network security products, including firewalls and intrusion detection systems, still lack the comprehensive security capabilities necessary to fully inspect and filter native IPv6 and tunneled IPv6 traffic. The complexity of the IPv6 extensible protocol design and the difficulty in identifying and inspecting the contents of IPv6 tunnels are some of the reasons why these implementations have lagged behind.

It is imperative that CIOs and CSOs recognize that IPv6 is here, whether they like it or not. The threats resulting from the unplanned and unmonitored deployment of IPv6-enabled systems into enterprise networks can no longer be ignored and appropriate security controls must be put in place to address them.

Knowing that security incidents come down to just plain human error the lack of training professionals greatly increases the risk of more errors. IT and network security staffs need to be trained on the operational and security issues of IPv6 and network security product vendors must made to step up to the challenge of implementing effective counter-measures to IPv6-based attacks.

David Helms is vice president, Cyber Security Center of Excellence at Salient Federal Solutions.
which is developing comprehensive security controls and countermeasures, including those necessary to address the expanding IPv6 attack surface in enterprise networks.

Keep reading →

Despite a longstanding deadline and months of work, most federal agencies are about to miss the Sept. 30 deadline to enable IPv6 but will face no penalties for not reaching that goal.

Officials say Sept. 30 was a goal set by the Office of Management and Budget and that consequences for not meeting it are unnecessary. Nonetheless, compliance remains important as private industry v6 compliance is strong and therefore limits government interaction. Google, for example, launched IPv6 in June (see video with Vint Cerf above). Keep reading →

Officials guiding federal agencies to meet a Sept. 30 deadline to comply with Internet Protocol version 6 standards say they are confident the deadline can be met, though that clearly means a lot of work must be done in the next four months.

The latest National Institute of Standards and Technology (NIST) tracking graphic keeping tabs on progress show as of this week, about 100 of the 1,553 domain sites were v6 compliant. Keep reading →

Steven Pirzchalski is a very popular guy these days.

As director of enterprise telecommunications for the Department of Veterans Affairs, he’s the VA’s IPv6 lead person on transitioning the agency to the new version of Internet protocol. He’s also the point person to answer every question other agencies have about the transition, a role the Office of Management and Budget gave him three months ago. Keep reading →