Slippery Floor

Filtering Tunnel Traffic with Other Mechanisms

Some tunnel variants cannot be identified by looking for Protocol 41 because they use UDP or TCP as their transport protocol and thus either have 17 (UDP) or 6 (TCP) in the Protocol field. One of these variants is Teredo.

This mechanism uses UDP port 3544 to establish the tunnel to the Teredo server. If this port is blocked, Teredo cannot establish the initial connection. Of course, you cannot rule out the possibility of attackers setting up their own Teredo server on the Internet that does not use the default port. For this reason, it can be useful to filter by other criteria.

If your packet filter is capable of inspection, you can filter for an incoming or outgoing IPv4/UDP packet transporting an IPv6 packet with a value of 16 the version field of the header and whose sender or receiver address uses the Teredo prefix 2001::/32. That said, RFC 7123 [7] points out that this approach can lead to false positives if the firewall does not implement these features correctly. In this case, an IPv4/UDP packet would still be blocked, even if it did not contain any Teredo traffic.

Another filtering option is to control DNS traffic. For example, Windows requests the IPv4 host entry (address record A) [8] teredo.ipv6.microsoft.com . This can be checked by your DNS server or filter device, as can the request issued by Windows systems that look for the name isatap.<localdomain> , to discover the ISATAP router.

Another approach for enabling IPv6 traffic through IPv4-only networks relies on tunnel brokers. Tunnel brokers are IPv6 gateways on the Internet that are addressed by a client installed on a dual-stack node. A tunnel is set up between the node and the gateway (server). The dual-stack node communicates using IPv6 through the tunnel with the IPv6 Internet. The decisive difference from other tunnel mechanisms is the explicit installation of an appropriate client.

IPv6 tunnel brokers are described in RFC 3053 [9] and often use the Tunnel Setup Protocol (TSP) defined in RFC 5572 [10]. TSP can use either TCP or UDP as its transport protocol. In both cases, TSP uses port number 3653 to communicate with the server; the port was reserved by the Internet Assigned Numbers Authority (IANA) for this purpose.

The Anything In Anything (AYIYA) tunnel technology has not yet been standardized as a RFC, although it is still fairly widespread because it is designed for communicating through NAPT devices, that is, NAT systems that perform Port Address Translation. For example, AYIYA, used by the well-known tunnel broker SixXS, can be blocked at the IPv4 gateway by filtering outgoing traffic on ports 5072/UDP or 5072/TCP.

Conclusions

Although filtering native IPv6 and tunnel traffic is not particularly difficult from a technical point of view, the first challenge is to identify the problem. With filters, the "as much as necessary and as little as possible" approach always applies. Problems filtering IPv6 traffic that result in failed connections and delays can be mitigated by returning a TCP-RST segment (with the reset flag set) to internal nodes.

Beyond explicit attack scenarios, such as hijacking an IPv6-capable router and manipulating IPv6-capable nodes that are only intended to communicate on IPv4, automatic tunneling mechanisms represent the greatest source of danger in terms of uncontrolled communication of systems with the Internet. Aggravating this situation is that IPv6 is preferred by the popular operating systems, and IPv6 communication is established, even if it is only possible by using a tunnel mechanism.

Another possibility, beyond disabling IPv6 functionality on the endpoints, is to configure the DNS server so that requests from the IPv4-only network for AAAA RR (IPv6 resource records) [11] are either ignored or get a DNS RCODE response of 0 (NOERROR) as per RFC 1035. This ensures that nodes from the IPv4-only network exclusively receive A records (i.e., IPv4 addresses) in the response from the DNS server.

In the long term, the solution is obviously widespread migration to native IPv6 connectivity. One hopes that the current upward trend in IPv6 will lead to IPv6 migration taking the highest priority in the enterprise and thus restricting these transition scenarios and the problems they can cause to the shortest possible period of time.