IPv6, Relearning Old Lessons, and How Will You Know?

Those of us that have been in the business for a while know that there have been reports of the imminent exhaustion of IPv4 addresses for more than a decade.  Finally, earlier this year, IANA (the Internet Assigned Numbers Authority) handed out the last blocks of IPv4 address space to the RIRs (Regional Internet Registries, which are the folks that actually assign address space to customers).We have just about reached that point of exhaustion.

My primary interest these days is malware analysis.  I’ve spent most of the last year preparing my automated malware analysis environment for IPv6 which has caused me to spend a lot of time thinking about how malicious actors and criminals might take advantage of the coming/in-process transition to IPv6.  In February, Dennis Oniki asked if you were ready for IPv6.  I want to ask the same question, but at a slightly more technical level and from a security perspective.

One of the things that still amazes me, is that lessons I thought we had learned based on many years of experience with IPv4 apparently need to be relearned with IPv6.  In the IPv4 world, we long ago learned to disable source routing (at least at our borders).  It was an idea that may have sounded good on paper, but in practice turned out to be of more use to the malware authors than to our own network engineers.  This has primarily been (either for denial-of-service type attacks or for man-in-the-middle attacks where the criminals could intercept and/or modify our traffic, including intellectual property and personally identifiable information.

So, in the IPv6 specification comes the Routing Header Type 0 (RH0) that does pretty much the same thing.  In 2007, the Internet Engineering Task Force (IETF, the organization that produces the RFCs that define the internet protocols) relearned the source-routing lesson and recommended disabling this feature.  Despite the recommendation, the capability may still be enabled on routers in production as it was the default configuration on many routers until relatively recently.

Over the years, we’ve developed defenses to the problem of rogue DHCP servers in the enterprise (because they could be used for man-in-the-middle attacks), by introduction of DHCP Snooping in our switches to ensure that only legitimate DHCP servers can respond to DHCP requests.

Now,  along comes IPv6 and we have rogue Router Advertisements (RA) to deal with, which has similar potential for misuse due to the introduction stateless auto-configuration (SLAAC).  One of the solutions proposed for the rogue RA problem is called RA-Guard and is very similar to DHCP snooping, it only allows RAs to come from ports that are known to be legitimate routers.  Unfortunately, this hasn’t been implemented by all of the vendors and/or on older hardware.

This was yet another lesson we had to learn again.  Probably the biggest issue with this one, is to deploy RA-Guard, you need to enable IPv6 on your infrastructure switches, even if you aren’t really ready to use IPv6 within the enterprise.

There are attacks that specifically target IPv6-enabled systems (such as Windows 7, out of the box) in “IPv4-only” networks and can hijack all of the victim’s traffic and potentially steal intellectual property or identities.  That’s the thought that led to the last part of the title of this piece.

Even if we believe that we are running IPv4-only networks, the criminals are quite willing to take advantage of IPv6 and we may not see it.  As part of our transition plan, our first step must be to get our infrastructure IPv6-enabled to the point that we can recognize the existence of IPv6 traffic in our enterprise, even if we aren’t ready to take advantage of it ourselves.

In the process of updating my automated malware analysis environment, I’ve had to look through all of my tools and figure out whether they could recognize IPv6 traffic, whether they could take the appropriate actions on IPv6 traffic, and finally, whether they could store and report on data related to IPv6 traffic.  What I’ve discovered is a pretty mixed bag.  Some of the tools are ready, some aren’t, some require updates, and some need to be completely replaced.  This is an exercise all of us are going to need to go through sooner rather than later.

I’m sure that we’ll be relearning lessons we thought we had learned with IPv4 for quite a few years yet.

So what is your experience with this?  Have you seen any security threats from IPv6 technologies running on an IPv4 environment?  What are you doing to protect data from the bad guys trying to break in through IPv6-enabled systems?  We look forward to your comments.
Jim Clausing Technical Staff Principal Member AT&T About Jim