Teredo is a platform-independent protocol developed by Microsoft, which is enabled by default in Windows Vista. Teredo provides a way for nodes located behind an IPv4 NAT to connect to IPv6 nodes on the Internet. However, by tunneling IPv6 traffic over IPv4 UDP through the NAT and directly to the end node, Teredo raises some security concerns. Primary concerns include bypassing security controls, reducing defense in depth, and allowing unsolicited traffic. Additional security concerns associated with the use of Teredo include the capability of remote nodes to open the NAT for themselves, benefits to worms, ways to deny Teredo service, and the difficulty in finding all Teredo traffic to inspect.
We have completed an analysis of the Teredo protocol based on a reading of the RFC (and apart from any implementation). In this section, we highlight some of the more significant security implications of the protocol; that is, ways in which Teredo positively or negatively impacts the IPv4 and IPv6 portions of the Internet.
Teredo provides a way for dual-stack nodes, that do not have direct IPv6 connectivity due to being located behind an IPv4 NAT, to communicate with remote IPv6 nodes. This may be an admirable goal in that it promotes the use of IPv6 earlier for the large number of hosts stuck behind NATs. To accomplish this goal it is necessary for the protocol to essentially bypass the NAT. Teredo accomplishes this by establishing a fixed UDP port for each client, over which IPv6 is tunneled to the end client; though in so doing, more than just the NAT is bypassed. Existing network-based security controls (e.g. firewalls, IPSs), even those that support IPv6, are bypassed as well. Although the controls can continue to do IPv4 inspection, the real traffic is occurring over the UDP tunnel. Until and unless those controls are upgraded to be Teredo-aware, they will not be properly applying IPv6 or higher-level controls to this traffic. (However, we also found that it may be difficult to inspect all Teredo traffic due to the lack of fixed port numbers.)
Certainly, an opportunity exists to apply security controls on the Teredo client past the end of the tunnel. That is definitely advisable since Teredo essentially puts the client directly on the Internet (any IPv6 node can send packets that will reach the client). However, Teredo does not require that such controls be put in place, and any controls that are unique to the network are bypassed. Even network-based controls that have an analog (comparable control) on the client have had their defense in depth reduced. Teredo even allows unsolicited incoming packets to be passed through the tunnel. End-to-end connectivity like this is expected to be the norm under native IPv6, but there is a better chance of proper security controls being in place there.
An example of where end-host security controls are important for Teredo clients, especially when network security controls have been bypassed, is with IPv6 source routing. Source routing is quite often disabled via network controls. If it is not disabled on the client as well, an IPv6 source routed packet sent over Teredo will be forwarded by the Teredo client to its next destination, which may be inside the client's network.
Teredo provides a bubble-to-open function, which allows arbitrary IPv4 nodes to set up a Teredo client's NAT such they can that send unsolicited traffic to the client (i.e. they can poke a hole in the NAT for themselves). This essentially turns a restricted NAT into an unrestricted (pure cone) one, for each port maintained by a Teredo client. Even the accessibility through a pure cone NAT is improved, since Teredo is both including the port number and address in the client's Teredo address and is actively keeping the port open. The appropriate security posture may need to be rethought due to this. Something else revealed in the Teredo address is the client'ss NAT type; this can help facilitate or target attacks, and an attacker may interpret the cone bit being on as a sign of weakness for the network and attackers may preferentially target such nodes. Servers see a client's intended IPv6 peers, so one should use only trusted servers; this mainly a concern if the server setting is secretly switched to a malicious server.
Worms that target using layer 3 or 4, such as blind IP address-scanning worms, of course benefit from increased reachability since they can reach hosts even if they are behind a NAT. Even if a firewall was in place on the host, if a vulnerability exists in the Teredo client or some other prefirewall component that permits remote code execution, a worm that spreads with a single UDP packet (like Slammer did) may be possible.
To an extent, Teredo components on the Internet provide an easier means of denying service when one of the peers is a Teredo client than when native IPv4 or IPv6 connectivity is in use. The exact reasons for why it is worse varies with the attack. If enough IPv6 packets with different Teredo destination addresses are sent through a Teredo relay, the number of peer address records that the relay can store at one time will be exceeded; this would cause at minimum a significant degradation of service. We anticipate this to be a worse problem than the case with IPv4 or IPv6 routers, because it is expected to be easy to exceed this number, especially since the relay may be queuing packets for up to a 6 seconds while waiting for NATs to be set up. A similar problem exists on the client, since it is probably easy to cause a client to connect to many different destinations and thus exceed the maximum number of peers it can maintain at one time. If a Teredo server can be subjected to a brute-force denial of service or if it is compromised, the impact may be more widespread than in the native IPv4 or IPv6 case, because a very large number of clients may depend on it for IPv6 access. On the positive side, Teredo has peer anti-spoofing measures that are automatically applied. Though not foolproof nor as strong as IPsec, these measures provide more peer validation than is currently typically applied, especially in the case of IPv4. In addition, IPsec is compatible with Teredo, but it might not be compatible with other transition mechanisms. Sanity checks required of Teredo components by the Teredo RFC prevent many potential attacks.