Have you ever noticed how security often takes a backseat when trying something new? When I am trying out a protocol out for the first time, I barely skim the Security Considerations section of the RFC. Just the same, as more of us start experimenting with IPv6, the use of tunneling protocols is likely to rise. That is good for IPv6 adoption but not so hot for security.
I certainly don’t want to discourage anyone from trying IPv6. In fact, I would rather see folks testing the waters now, trying it out and getting comfortable with it, than thrashing and flailing when ICANN announces the exhaustion of IPv4 pools. I do want to make sure everyone is aware of the risks involved so they can take appropriate precautions.
This article will only cover 6to4 (Wikipedia/RFC 3056) not to be confused with 6in4 and Teredo (Wikipedia/RFC 4380) tunneling protocols. A direct tunnel to your providers’ IPv6 systems does not present the same problems and risks as these public protocols do.
Both protocols focus on easing the transition to IPv6 and neither one claims to offer any significant security protection. In fact, the Teredo RFC goes so far as to call itself the IPv6 Provider of Last Resort. This label comes primarily from the crazy stunts required to successfully traverse multiple NAT gateways. However, it is worth considering some other factors as well. 6to4 comes with an entire RFC devoted to security considerations (http://tools.ietf.org/html/rfc3964). Remember, IPv4 firewall rules don’t do anything to IPv6 traffic.
6to4 tunneling requires that the user endpoint exist in publicly routable IP space and be directly reachable by any 6to4 serving device. One advantage of this exposure is that you can make use of more than just one 6to4 gateway, the obvious disadvantage being that you have to trust traffic coming from any address claiming to support the protocol for full functionality.
6to4 can also support routes to networks behind the endpoint. Endpoints are assigned an IPv6 address from the 2002::/16 prefix. The 4 bytes immediately following 2002: are the IPv4 address of the endpoint converted to hex. Thus, 192.168.25.200 would map to 2002:c0a8:19c8::/48 (RFC 1918 IP used for example only, it would be invalid in actual operation). It is reasonable to say that if one was going to create a server and publish it to the IPv6 Internet, it should also be fortified against both IPv4 and IPv6 threats. The take-away here is if you publish a 2002::/16 IPv6 address, we also know the IPv4 address of your endpoint.
Teredo is designed to work just fine with the remote endpoint behind one or more NAT gateways. Unlike 6to4, however, only one host can exist behind the endpoint. Right from the start, we need to worry about tunneling from the public Internet to a host inside a NATed environment. If the host is not well-protected, we could stop right there. We also have endpoint address leakage to contend with. Teredo goes even further than 6to4 by encoding the IPv4 exit point of the NAT gateway, the UDP port used by the external NAT session, and the IPv4 address of the tunnel endpoint used by the client. Some obfuscation is used, XORing UDP port and NAT IP with all 1s. However, this fact is well-known and will only protect you from people afraid of Wikipedia.
The base prefix for a Teredo IP address is 2001:0000::/32. Teredo client addresses are assembled as follows:
- 2001:0000::/32 — base prefix
- 2001:0000:c0a8:19c8::/64 — add IP address of the tunnel server (192.168.25.200 -> c0a8:19c8)
- 2001:0000:c0a8:19c8:0000::/80 — add 16 bits of flags (0x00)
- 2001:0000:c0a8:19c8:0000:8888::/96 — add external NAT port number XORd with 0xFFFF ( 30583 -> 0x7777 ^ 0xFFFF = 0x8888)
- 2001:0000:c0a8:19c8:0000:8888:F537:76C8/128 — add external IP of NAT gateway XORd with 0xFFFFFFFF (10.200.137.55 -> 0x0AC88937 ^ 0xFFFFFFFF = 0xF53776C8)
Again, I don’t want to scare anyone off. Just know the risks and take appropriate precautions.
Happy IPv6ing!
