In a previous blog, I discussed the importance of controlling tunneled traffic in your network.
If you don’t, it is like locking the front door on your house, but leaving your windows open. The National Institute of Standards and Technology (NIST) puts it this way in their Special Publication SP 800-119, Guidelines for the Secure Deployment of IPv6, “Tunnel endpoints are always a focal point for security; attackers frequently target them in attacks. . . The tunneled traffic should not be trusted without inspection.”
One problem, particularly if you are trying to control IPv6 tunnels, is the policy to identify these tunnels, can be complex. To be successful, you need to understand how to identify the various types of tunnels. Additionally, some tunnel types cannot be differentiated solely by examining the outer packet, so if you want to block 6in4 and 6over4, but allow ISATAP, it isn’t possible, without deeper inspection of the packet.
Fortunately, in Junos 12.3X48, there is a new SRX feature that makes it much easier to control tunnels in your network. You might miss this new feature, since it is called IPv6 tunneling control for SRX Series devices. It is useful in IPv6 enabled networks, but it is also essential for IPv4 only networks.
This feature adds the following new screens that allow you to control, allow, or block the transit of tunneled traffic:
- GRE 4in4 Tunnel
- GRE 4in6 Tunnel
- GRE 6in4 Tunnel
- GRE 6in6 Tunnel
- IPinIP 6to4relay Tunnel
- IPinIP 6in4 Tunnel
- IPinIP 6over4 Tunnel
- IPinIP 4in6 Tunnel
- IPinIP ISATAP Tunnel
- IPinIP DS-Lite Tunnel
- IPinIP 6in6 Tunnel
- IPinIP 4in4 Tunnel
- IPinUDP Teredo Tunnel
More detail on these screens is available here.
Even if you already have a dual stack network, these screens will still be useful. If you are one of the rare few to have an IPv6 only network, we still have screens for you. The SRX engineering team had the foresight to address IPv6 tunnels in IPv4, IPv4 tunnels in IPv4, IPv6 tunnels in IPv6 and IPv4 tunnels in IPv6.
These screens are effectively an “easy button” to control tunneling.
There is more to this feature than just making tunnel control easier. In SP 800-119, NIST states, “checking the IPv4 outer header doesn’t necessarily mean the inner IPv6 packet is legitimate. Depending on the security device being used, it can be difficult to check/match the outer and the inner header.” If an attacker sends traffic that masquerades as something else, policy that simply looks at the outer packet header won’t help.
Fortunately, the new, IPv6 Tunneling Control feature has a one more screen for this situations. It’s called the Bad Inner Header Tunnel Screen. This screen specifically checks to make sure that a packet is what it claims to be. It actually checks the tunnel traffic inner header information for consistency and will drop (and/or log) a packet if it fails checks for the inner header not matching outer header, and a whole series of inner packet sanity checks. So if the outer packet has been crafted to hide the presence of a tunneled packet, this screen will detect and stop the packet.
If you aren’t effectively controlling tunnels (whether IPv6 or IPv4), you have a gap in your security policy. The good news is the SRX is making it easier to deal with tunneled traffic and is specifically designed with the complexities of IPv6 in mind.
We at Juniper don’t just look at IPv6 as IPv4 with larger address space. We shipped the first IPv6 capable firewall more than a decade ago and have continued to work on IPv6 security since then. We have made countless enhancements to the SRX to deal with the challenges of IPv6. As a result, the SRX is arguably the world’s best IPv6 firewall.