• Trend Micro
  • About TrendLabs Security Intelligence Blog
Search:
  • Home
  • Categories
    • Ransomware
    • Vulnerabilities
    • Exploits
    • Targeted Attacks
    • Deep Web
    • Mobile
    • Internet of Things
    • Malware
    • Bad Sites
    • Spam
    • Botnets
    • Social
    • Open source
Home   »   Bad Sites   »   IPv6 Tunneling Protocols: Good for Adoption, Not So Hot for Security

IPv6 Tunneling Protocols: Good for Adoption, Not So Hot for Security

  • Posted on:October 26, 2009 at 1:57 pm
  • Posted in:Bad Sites
  • Author:
    Ben April (Threat Researcher)
6

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:

  1. 2001:0000::/32 — base prefix
  2. 2001:0000:c0a8:19c8::/64 — add IP address of the tunnel server (192.168.25.200 -> c0a8:19c8)
  3. 2001:0000:c0a8:19c8:0000::/80 — add 16 bits of flags (0x00)
  4. 2001:0000:c0a8:19c8:0000:8888::/96 — add external NAT port number XORd with 0xFFFF ( 30583 -> 0x7777 ^ 0xFFFF = 0x8888)
  5. 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!

Learn how to protect Enterprises, Small Businesses, and Home Users from ransomware:
ENTERPRISE »
SMALL BUSINESS»
HOME»

Security Predictions for 2020

  • Cybersecurity in 2020 will be viewed through many lenses — from differing attacker motivations and cybercriminal arsenal to technological developments and global threat intelligence — only so defenders can keep up with the broad range of threats.
    Read our security predictions for 2020.

Business Process Compromise

  • Attackers are starting to invest in long-term operations that target specific processes enterprises rely on. They scout for vulnerable practices, susceptible systems and operational loopholes that they can leverage or abuse. To learn more, read our Security 101: Business Process Compromise.

Recent Posts

  • Our New Blog
  • How Unsecure gRPC Implementations Can Compromise APIs, Applications
  • XCSSET Mac Malware: Infects Xcode Projects, Performs UXSS Attack on Safari, Other Browsers, Leverages Zero-day Exploits
  • August Patch Tuesday Fixes Critical IE, Important Windows Vulnerabilities Exploited in the Wild
  • Water Nue Phishing Campaign Targets C-Suite’s Office 365 Accounts

Popular Posts

Sorry. No data so far.

Stay Updated

  • Home and Home Office
  • |
  • For Business
  • |
  • Security Intelligence
  • |
  • About Trend Micro
  • Asia Pacific Region (APAC): Australia / New Zealand, 中国, 日本, 대한민국, 台灣
  • Latin America Region (LAR): Brasil, México
  • North America Region (NABU): United States, Canada
  • Europe, Middle East, & Africa Region (EMEA): France, Deutschland / Österreich / Schweiz, Italia, Россия, España, United Kingdom / Ireland
  • Privacy Statement
  • Legal Policies
  • Copyright © Trend Micro Incorporated. All rights reserved.