Home / Blogs

IPv6 Presents a Security Paradox for the Network

Danny McPherson

The capabilities IPv6 provides will enhance online security, but the shift to the new Internet address scheme may also present risks if not properly managed. Previously, Internet security was largely an after-thought for the early Internet, as its primary purpose was to facilitate open, end-to-end, any-to-any communications and information exchange for bridging and accelerating research efforts. Today, we have a much more complex online ecosystem that spans billions of users across the globe and serves not only as an engine for e-commerce, but as an engine for all commerce.

The Internet protocol suite has become the de facto standard for global Internet services and consumers, but it also serves as a near ubiquitous substrate for running critical network infrastructure and business critical applications. Transportation, financial systems, emergency services, utilities, and government applications are just a few examples of services that need absolute availability and robust security. But having robust security is only one part of the solution.

At the micro level, the migration of personally identifiable information and proprietary intellectual property online has influenced IPv6 protocol architects to bake additional security into the stack. For example, IPSec is mandatory to implement in IPv6 compliant protocol stacks, while secure neighbour discovery capabilities, privacy addresses, and unique local addresses (ULA) all provide additional security enhancements.

While these additional security measures are good for end users, they can present some real challenges for network administraators. For example, one of the biggest — but arguably easiest-to-remedy — pitfalls is that today most networking equipment and end systems are shipped with IPv6 enabled by default. This is ideal to foster IPv6 deployment, but puts the onus on network administrators to have a plan in place to proactively manage IPv6, as leaving IPv6 turned on by default can create security holes if not properly managed.

In an Internet environment with no bad actors it is perfectly reasonable and even requisite to enable IPv6 by default in order to rapidly deploy. However, if network managers aren't ready for IPv6 in their operating environments, meaning full functional parity from a security and operational perspective, then they really need to disable IPv6 entirely and deploy new devices and hardware in a very calculated manner.

With IPv6 usage on the rise, it is critical that networks, equipment, and systems are implemented appropriately to help securely enable its full potential and prevent the creation of inadvertent security issues. Some such issues that have been observed include IPv6 being used to compromise systems "under the radar" of IPv4-only sensors and IPv6 being expressly enabled by miscreants in order to exfiltrate data, facilitate malware propagation, and enable botnet C&C infrastructure and distributed denial of service attacks.

Other considerations for securely implementing IPv6 include the following:

Translating IPv4 to IPv6 (because it will take some time before all systems are running on v6, and some may never run IPv6) itself can be a pitfall. This is because IPv4 and IPv6 are not "bits on the wire" compatible; translating traffic from IPv4 to IPv6 will inevitably result in middle boxes mediating transactions as packets move through the network. Like a mail sorter at a post office transfer facility, transferring payloads from IPv4 to IPv6 packets creates an opportunity for a poor implementation or a bad actor to exploit a potential vulnerability.

Unlike IPv4's variable header size, IPv6 has a 40-byte fixed header, but introduces add-on "extension headers" that may be chained and require complex processing by various systems that handle the packet. These chains could overwhelm firewalls and security gateways. They could even introduce router forwarding performance degradation and be a potential vector for distributed denial of service and other attacks.

During a long period of "transitional coexistence," IPv6 adoption may require large network address translation protocol translation (NAT-PT) devices, end system or intermediate translation devices and protocols. But these devices complicate the network and could break useful functions like geo-location or tools that security administrators use to identify and mitigate malicious network behaviours, including blacklists (e.g., spam and phishing) and traffic filters.

Because of IPv6's sparse address space, active scanning of infrastructure for unauthorized or vulnerable systems is much more complex than with IPv4. These capabilities need to be augmented with network access controls and active measurement systems that trigger vulnerability scanning.

Have any other considerations to share in the comments section below?

By Danny McPherson, Senior Vice President and Chief Security Officer at Verisign

Related topics: IP Addressing, IPv6, Security

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

Untested code paths Phillip Hallam-Baker  –  Dec 28, 2012 9:16 PM PST

The biggest security implication is that pretty much every piece of networking gear is now shipping with untested code paths relating to IPv6 and many have IPv6 turned on by default which may invalidate security assumptions about devices being locked down.

I am not that much exercised about the 128bit aspect of IPv6 though. For all practical purposes the IPv6 space can be treated as a 64 bit Inter-networking address and a 64 bit local networking address. Spammers can and will play games randomizing their addresses used within the entire /56 or /64 that is available to them. But blocklists don't need to be so granular.

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

Q3 2014 DDoS Trends: Attacks Exceeding 10 Gbps on the Rise

3 Questions to Ask Your DNS Host About DDoS

Afilias Partners With Internet Society to Sponsor Deploy360 ION Conference Series Through 2016

Neustar to Build Multiple Tbps DDoS Mitigation Platform

The Latest Internet Plague: Random Subdomain Attacks

Digging Deep Into DNS Data Discloses Damaging Domains

New gTLDs and Best Practices for Domain Management Policies (Video)

Nominum Announces Future Ready DNS

New from Verisign Labs - Measuring Privacy Disclosures in URL Query Strings

DotConnectAfrica Delegates Attend the Kenya Internet Governance Forum

3 Questions to Ask Your DNS Host about Lowering DDoS Risks

Continuing to Work in the Public Interest

Verisign Named to the OTA's 2014 Online Trust Honor Roll

4 Minutes Vs. 4 Hours: A Responder Explains Emergency DDoS Mitigation

Dyn Acquires Internet Intelligence Company, Renesys

Tips to Address New FFIEC DDoS Requirements

Smokescreening: Data Theft Makes DDoS More Dangerous

dotStrategy Selects Neustar's Registry Threat Mitigation Services for .BUZZ Registry

24 Million Home Routers Expose ISPs to Massive DNS-Based DDoS Attacks

What Does a DDoS Attack Look Like? (Watch First 3 Minutes of an Actual Attack)

Sponsored Topics

Afilias

DNSSEC

Sponsored by
Afilias
Verisign

Security

Sponsored by
Verisign
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
dotMobi

Mobile

Sponsored by
dotMobi