Teredo Security Updates
updates
- rfc-4380 — Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
Extracted elements (15)
Only 12 of the 13 unused flag bits are randomized; one bit (z) is kept reserved and set to zero for potential future use, maintaining a defined reserved bit per RFC 4380's original structure.
The cone bit is deprecated because it reveals the security posture of the network: a set cone bit signals that the NAT is open to incoming connections, potentially inviting port scans. Deprecating it prevents a priori revelation of NAT security posture to attackers.
Twelve of the 13 unused bits in the Flags field are randomized to guard against address-scanning risks. Even if an attacker knows the external IPv4 address and port assigned by a NAT, they must still attack a range of 4,096 IPv6 addresses (2^12) to find the actual Teredo address.
Cone bit deprecation (as specified in this document) is implemented in Windows Vista and Windows Server 2008; random flags are implemented in Windows Vista SP1 and Windows Server 2008. All Windows implementations automatically disable Teredo on managed networks with a domain controller.
Deprecating the cone bit forces peers to always send indirect bubbles as if communicating with a restricted NAT, which is less efficient but backward compatible because skipping case 4 of RFC 4380 Section 5.2.4 is already allowed for reliability reasons; peers behind cone NATs will reply to the indirect bubbles normally.
Teredo clients and relays SHOULD ignore the cone bit in the address of a Teredo peer and treat it as if it were always clear, as specified in RFC 4380 Section 5.2.4 (last paragraph).
Teredo clients SHOULD completely skip the first phase of the qualification procedure and implement only the second phase using the Teredo link-local address with the cone bit set to zero, effectively deprecating cone NAT detection.
Teredo servers MUST NOT ignore the cone bit because the cone bit in the IPv6 source address of a Router Solicitation from a client controls what IPv4 source address the server uses when sending a Router Advertisement; ignoring it would cause legacy clients to incorrectly conclude they are behind a cone NAT.
The Random1 and Random2 bits in the Teredo Flags field MUST be set to a random value when constructing a Teredo IPv6 address.
The Random1 and Random2 bits MUST be constructed following the recommendations for random number generation as specified in NIST SP 800-90 and RFC 4086, to prevent adversaries from easily guessing the values.
The reserved z bit in the Flags field MUST be set to zero when the address is constructed, as specified in RFC 4380.
A Teredo IPv6 address embeds the Teredo prefix (32 bits, IANA-assigned value 2001:0000::/32), the server IPv4 address (32 bits), the Flags field (16 bits), and the obfuscated external port and IPv4 address (each 16 and 32 bits). Predictability of each field varies, with the Flags field historically having only 1 variable bit (the cone bit).
Teredo is NOT RECOMMENDED as a solution for networks that wish to implement strict controls for Internet traffic; administrators of such networks may wish to filter all Teredo traffic at network boundaries, as Teredo can open holes in enterprise firewalls.
The random address bits guard against IPv6 address scanning (RFC 5157) by off-path attackers: the 12 random bits provide 4,096 possible addresses per external IPv4/port combination, providing search space comparable to or better than IPv6 SLAAC-configured addresses.
The updated 16-bit Teredo Flags field is structured as: C (cone, bit 0), z (reserved, bit 1), Random1 (bits 2-5, 4 bits), U (bit 6), G (bit 7), Random2 (bits 8-15, 8 bits). Random1 and Random2 together provide 12 bits of randomness.