Security considerations for IPv6 launch day

In case you haven’t been glued to the Internet Society (ISOC) website, there soon will be some rather large changes to the Internet as the much anticipated World IPv6 Launch day arrives on June 6. I see this as much more hype than operationally a change.

While many large organizations have hooked their plans on change over to the ISOC launch date, legions of companies have already been leveraging IPv6 WAN connectivity. Most mobile providers who have adopted LTE 4G infrastructures have built around this networking principle already with mobile devices, by default, connecting to the Internet via IPv6 assignments.

It’s well known, however, that a 4G phone must also be 3G compatible and must also be able to regress to IPv4 published websites as not to upset the end-user community. Thus all we really have done, and much to the chagrin of the initial designers, is somehow weave IPv6 into the existing IPv4 Internet.

Bottom line: Because IPv4 is not going away and many estimate that it will take 10 years (or longer) for the natural death of IPv4 to occur, we will essentially live in perpetuity with both designs.

A new dawn? Or the beginning of the end? To be honest, it’s neither. The interoperability issues between IPv4 and IPv6, however, opens a Pandora’s Box of opportunity for those of the nefarious persuasion. Much has been written about this including from my colleague Ron Meyran who addresses specific IPv6 vulnerabilities that will remain and are likely to be with us indefinitely.

So, what are the three main takeaways from this event?

Take away #1: IPv6 will first be implemented on the WAN, IPv4 will continue to remain in the LAN for years to come
OK, so the “big boys’ – Google, Facebook, DNS and CDN providers – are all moving to IPv6 default systems via WAN connectivity. And many, if not most ISP’s are following fast or already there. However, nearly no one has made the transition to IPv6 for LAN. There are many reasons for this, but probably the most notable is that there really is no concept for IPv6 NATing, which would mean that most companies would need to go back to the drawing board for their LAN to transition to IPv6.

Realizing that IPv6 will be adopted at an ever-increasing rate on the Internet WAN operations, and it will be very slow to take hold for LAN operations, that means this will wreak havoc on perimeter security!

If we go back to Ron’s blog post we find out that there really is a huge problem associated with IPv4 and IPv6 cohabitating. The problem is twofold:

Problem #1 – There is no good security detection or mitigation for encapsulated traffic.

Problem #2 – All of yesterday’s exploits, in theory, can be tunneled through the perimeter if someone knows how to properly package the exploit in today’s new transmission transition packaging.

Take away #2: IPv6 & IPv4 don’t cohabitate well
As I mentioned earlier, IPv6 and IPv4 make insecure bedfellows. There have been no predefined standards in the way to handle the facilitation of the cohabitation of IPv4 with IPv6 so there has been shortage of “transition mechanisms’ which have popped up and have been, in most part, widely adopted.

Once again, these transition mechanisms facilitate the transitioning of the Internet from its initial IPv4 infrastructure to IPv6. As IPv4 and IPv6 networks are not directly interoperable, these technologies are designed to permit hosts on either network to participate in networking with the opposing network.

The Internet Engineering Task Force (IETF) conducts working groups and discussions through the IETF Internet Drafts and Requests for Comments processes to develop these methods. Some basic IPv6 transition mechanisms have been defined; however nothing has yet emerged as a proposed uniform standard. As such, the world is awash with the mechanisms, which are all over the map but are largely defined in the following categories:

Plethora of IPv4 to IPv6 (and vice versa) Transition Mechanisms such as the following:

• Encapsulating IPv4 in IPv6 (or 4in6)
• Encapsulating IPv6 in IPv4 (or 6in4)
• IPv6 over IPv4 (6over4)
• DS-Lite
• 6rd
• 6to4
• ISATAP
• NAT64 / DNS64
• Teredo
• SIIT.

If you are familiar with network perimeter security devices, one of the things they do well is deep packet inspection and Stateful aware analysis. However, some of the dirty little secrets is that nearly none of today’s technologies have a capability to inspect encrypted traffic such as SSL (BTW – this is an area where Radware is a true leader), or the ability to inspect tunneling protocols such as L2TP, PPTP, etc.

What IPv4 and IPv6 transition does is effectively exacerbate these “Achilles heels” in security detection capabilities by introducing a whole new category of nearly undetectable transmissions.

Don’t be fooled by a vendor’s claim that they inspect a v4 packet in v6 or vice versa, because even if true for one or two methodologies, the ways in which to accomplish this task are almost immeasurable today. This is really a true community-wide problem and one that must be addressed.

Of course, we’ve been looking at this conundrum for a while and have some strong solutions which often require some trade-offs. What controls don’t? Oh, one tangential thought: No scanners or vulnerability software is yet ready to provide you with visibility to the encapsulated transmission problem either!

So, what is the risk associated with ignoring this threat?

Take away #3: Meet your old vulnerability – Same as the new vulnerability!
Much of our defense is single threaded, and should an adversary be able to pass through your perimeter defenses, many of the “older’ vulnerabilities would find a receptive home having passed through the “corporate scrubbers.’

Moreover, just think of the new opportunities available to more nefarious organizations that don’t have your interests in mind

This “transition mechanism’ essentially becomes an effective “unscrubbed’ gateway or tunnel for all newly developed organized crime-designed, state-sponsored, and Hacktivist-motivated attacks.

Moreover, most of us will be largely blind to these realities unless you are acting now to make certain that your gateways are designed with all encapsulated traffic being detected and mitigated. Anomaly detection takes center stage here and signature tools will leave you wanting.

And one last thought: This problem requires action on behalf of security professionals to solve; you HAVE to do something differently because the inertia path will leave you vulnerable.