The late Anne Richards, former Governor of Texas, once said, “After all, Ginger Rogers did everything that Fred Astaire did. She just did it backwards and in high heels.”
I think this quote summarizes IPv6 security. IPv6 security means you need to be concerned about everything you were concerned about in IPv4 and then you have to take into account some of the unique characteristics of IPv6, such as extension header chains, the extensive use of ICMP in Neighbor Discovery, a different packet fragmentation model, the importance of Path MTU Discovery, interfaces that can have multiple addresses, etc.
Too many people incorrectly think of IPv6 as just IPv4 with bigger address space. If you are going to allow IPv6 traffic on your network, you better make sure that your security architecture is capable of dealing with the unique challenges of IPv6. You need a great IPv6-capable firewall like the SRX.
I would argue that you should embrace IPv6 and implement IPv6 capable security solutions. The world is very different today than it was a few years ago. IPv6 use is exploding. According to Google, more than 6 percent of their global customers now access Google via IPv6. This figure rises to more than 14%, if you limit the analysis to just the US.
Nevertheless, many customers are avoiding the challenges of IPv6 security by simply not enabling IPv6 in their enterprise. Their routers are configured to not forward IPv6 packets and their firewall drops IPv6 packets by default. This is an important first step in halting IPv6 traffic, but it is incomplete. Unfortunately, it will do nothing to halt IPv6 traffic that is tunneled in IPv4. To your firewall, this tunneled traffic looks like IPv4. Figuratively, this is like locking the doors of your house, but leaving the windows open.
To halt unauthorized IPv6 traffic in your network, you also need to halt unauthorized IPv6 tunnels hiding in IPv4 traffic. There are many forms of tunnels you might want to control including Teredo, ISATAP, 6to4, 6in4, 6over4. Even GRE 6in4 tunnels might be a concern. In fact, every IPv4 network should also control IPv4 traffic tunneling in IPv4, since the inner packets might be using the outer packet to avoid your policy controls. This is not a simple task. Every tunnel method uses a different mechanism, which means writing comprehensive firewall policies can be complicated. You need to understand the details of each mechanism to devise a policy that will control these tunnels. In addition, many firewalls are only able to examine the first packet header (the outer tunnel). In many cases, you cannot tell what sort of tunneling protocol is being used just from examining the outer IPv4 header. For example, 6in4, 6over4, and ISATAP tunnels all use the same outer tunnel header. You must look at the inner header to really know what is going on.
Controlling tunnels is essential for IPv4 only networks, networks transitioning to IPv6, and in IPv6 only networks.
In my next blog- I will share details on a new feature in the SRX that makes it much easier to control tunnels, whether they are IPv4 tunnels, or IPv6 tunnels.