IPv6 could open networks up to zero-day attacks

NIST warns that attackers are preparing to hit networks when IPv6 is turned on

The National Institute of Standards and Technology (NIST) warns that moving from IPv4 to IPv6 is a process fraught with peril, which may explain why government agencies are so far behind their own deadlines for implementation.

But private security and technology experts say those concerns are largely overstated, and that a safe transition could happen right away, if you do it correctly.

What isn't in dispute is that the 4.3 billion numbers in the IPv4 protocol are rapidly running out. The Asia Pacific Network Information Centre, which handles assigning IP addresses to that part of the world, already announced that it had run out of numbers back in 2011

+ ALSO ON NETWORK WORLD Whatever happened to the IPv4 address crisis +

Some headway has been made in reclaiming unused and abandoned IP addresses, but it's clear that IPv4 is nearing the end of its usefulness. The follow-up protocol, IPv6, will keep the Internet working for years to come. The possible numbers with IPv6 equal 3.4 times 10 to the 38th power, which equates to several thousand addresses for each of the world's 6.5 billion people. But the two protocols aren't designed to be interoperable, leading to problems with the transition from one to the next.

The U.S. government wants to lead the charge to IPv6 in the Western Hemisphere, and was under a mandate from its own Office of Management and Budget to have all public-facing Internet activities transitioned over to the new protocol by Sept. 30, 2012. It missed that deadline, and could very easily also miss the one whereby the entire government network infrastructure, both public and internal, is supposed to be exclusively IPv6 by this September.

NIST tracks the government transition in real time as it relates to Web, Domain Name Systems and e-mail services. While some agencies such as the Federal Trade Commission have met most of their goals, many others are struggling to even bring a small percentage of systems running IPv6 to bear in any of the target areas. To date, only about half the government is running systems on IPv6 more than a year past the first deadline.

But NIST is doing more than keeping tabs on other government organizations. They are actively trying to help agencies, and by extension everyone else, to make the transition to IPv6. To that end, the agency formed a working group which wrote the Special Publication 800-119, which identifies the likely pitfalls and risks associated with the transition, and how to mitigate them. Called "Guidelines for Secure Deployment of IPv6," the report exposes a laundry list of problems with deployment.

Most of the concerns listed in the NIST publication are related to security, with many stemming from trying to operate two different protocols on the same network infrastructure. It notes that most security software, appliances and hardware devices were designed to only work with IPv4. So by enabling IPv6 on a network at the same time, it may allow malware to simply skirt through those defenses, since the existing security wouldn't be able to identify it as valid traffic that needed to be scanned.

Specific concerns listed in the NIST document include:

  • The difficulty of managing rogue devices making use of the IPv6 protocol on a government network originally designed to work with just IPv4.
  • The concern that attackers have been experimenting with and even writing attack programs for IPv6 networks, giving them a tactical edge over those charged with protecting government networks from intrusion.
  • Attack programs may be staged and waiting for a network to flip on IPv6, striking almost as a zero day exploit.
  • The difficulty of running IPv4 and IPv6 networks at the same time.
  • The fact that the private security community may not have mature enough products to protect IPv6 networks as effectively as with IPv4 networks today.
  • Evidence that attackers have found ways to tunnel from IPv4 to IPv6 networks, bypassing security in some cases.

That mindset may explain why very few agencies are reporting some incremental percentage of IPv6 deployment. They are for the most part at zero or 100 percent completion. The agencies at zero are probably still working on their security infrastructure, especially since the report also notes that there is a lack of maturity in IPv6 security products. NIST says the government should wait until security can catch up.

Kevin Haley, director of Symantec Security Response, disagrees. He argues that companies like Symantec have products to protect both large enterprises and individual users running IPv6. "Back when the new standard came out, we worked to make solutions that would protect the networks that would run it. Government hasn't implemented IPv6 as quickly as they said, but our products are available. We're just waiting for the market."

Haley adds, "There are always going to be new lessons to learn, but in general it's pretty much the same from a security standpoint. Just like today, the bad guys are going to come up with new ways to exploit networks. That's what they do. But we are working just as hard to stop them, to discover the new exploits and to secure them for users. Moving to IPv6 won't change that."

Hackers are gearing up

The fact that hackers are actively studying IPv6, perhaps more so than any other group, is another pitfall that NIST cites. Specifically, NIST says that potential attackers may have more expertise with IPv6 implementation than the personnel at agencies and organizations trying to deploy it. The report recommends training more personnel on how to safely use IPv6 in different environments before moving forward with it too quickly.

But Sean Siler, director of device sales, Department of Defense at Microsoft, thinks that IPv6 is mature enough for deployment right now without too much additional hassle or worry. Siler probably knows more about IPv6 than most people. From 2007 to 2010, he was the IPv6 Program Manager for Core Windows. In that role he led the team that made Windows work with IPv6, and says it's been ready for longer than most people realize.

"The first time that Microsoft Windows worked with IPv6 was as far back as Windows XP, service pack two," he says. "Back then it was kind of an add-on that the team put into the software, but it worked fine and we tested it in a variety of environments."

Since then, Siler says that Windows products have been brought into perfect lockstep with the new protocol, to the point now where any Windows operating system can function on an IPv6 network without missing a beat, and without introducing any extra security vulnerabilities.

Specifically, Siler says that all modern versions of Windows have their TCP/IP stack written so that the operating system fundamentally understands IPv6 at its core. "Back in 2007 we were doing a lot of experiments with IPv6," he says. "But today, it’s a totally mature feature, fully ready for deployment with Windows. Nobody should be afraid to use it."

NIST worries about tunneling

But NIST isn't so sure. The report notes that malware may exist right now that could take advantage of the IPv6 protocol, but simply isn't doing it because most networks only allow IPv4 traffic. If those same networks suddenly begin to allow IPv6 traffic, they could immediately come under attack. To compensate for that, NIST recommends that all IPv6 traffic on networks be blocked, both incoming and outgoing, until a formal deployment schedule and the requisite security protocols can be put in place.

Haley admits that allowing both IPv4 and IPv6 traffic on the same network can introduce a specific new risk, but says that it's easily overcome. "What we have seen is that there is a risk of attackers on a hybrid network tunneling from the IPv4 area to IPv6, and using that as a way to disguise the fact that they are sending commands to a server," he says. "But all you have to do is block that tunneling. Then you can run both and there's no risk of that type of attack occurring."

With the tunnel-blocking solution, it doesn't actually hinder either network, since there are few valid reasons why one would need to tunnel to another. IPv4 traffic would stay in its area and IPv6 traffic would remain in its pond. The only possible disadvantage to disabling tunneling would be a very specific case where an administrator working remotely in an IPv4 environment might need to make a fix on the IPv6 area, but it's more likely that this would only be used as an exploit, so most networks can simply run with tunneling disabled.  

As for shutting down all IPv6 traffic until a network is ready to move 100 percent to it, Haley says that is unnecessary from a security standpoint. "Obviously, running both at the same time is going to be more complicated," he said. "But if you have protection in place for both and eliminate tunneling, there won't be any problems. The one thing you don’t want to do is have IPv6 accidentally turned on so that it's not managed and only the bad guys can use it."

NIST notes that even after the full deployment of IPv6, problems aren't likely to go away. It states that even years from now that organizations will still require mechanisms for IPv6 and IPv4 co-existence. So even if the pitfalls of IPv6 installation are finally surmounted, there could still be a bumpy road ahead, if not outright threats that will require constant vigilance long after the deployment phase is a distant memory.

John Breeden II has been covering and speaking about technology for more than 20 years. He was the lab director of product testing for Government Computer News magazine for the past decade. Today he's the president of the Tech Writer's Bureau, a group of influential journalists that pen interesting technology stories and analysis pieces for a variety of publications and companies.

Read more about LANs & WANs in Network World's LANs & WANs section.

This story, "IPv6 could open networks up to zero-day attacks " was originally published by Network World.

Copyright © 2014 IDG Communications, Inc.

How to choose a low-code development platform