Teredo CO-existence with 3rd party firewalls

Overview

Teredo is an IPv6 transition technology that provides NAT traversal for IPv6-capable applications as part of the Teredo protocol. As a result, applications that use Teredo as their underlying transport mechanism are able to achieve seamless peer-to-peer connectivity.  Thus, even though a machine may be behind a NAT, the use of Teredo makes it globally addressable

Glossary

Edge Traversal Flag: A policy construct which host firewalls can expose to allow an application or a user to control the receipt of edge traversal traffic.

This policy construct can be deployed to the firewall through an API, through UI elements, through script-based configurations, or through a security ISV’s website.  When this is specified through an API, it can mean application intent.

Edge Traversal Traffic:  Network technology that is used to provide inbound traversal of the NAT devices or Firewalls on the edge of a private TCP/IP network.

Network Address Translator (NAT):  A device that converts between IP addresses used within an intranet or other private network and Internet IP addresses.

Peer:  A Teredo client with which another Teredo Client needs to communicate.

Socket Option: An option provided by the Windows Operating system to applications that wish to convey their explicity intent with respect to receiving inbound edge traversal traffic.  This intent is made available to host firewalls via the Windows Filtering Platform.

Value Prop and Business Rationale

Teredo is a great platform for peer-to-peer applications as it provides an easy and reliable out-of-the-box NAT-traversal solution for applications. 

This feature would enable Teredo to have an even bigger success story as it would work equally well with both Windows Firewall as well as 3rd party firewalls and thus, make it more attractive as a NAT-traversal platform for ISVs looking to build peer-to-peer applications.

Firewall implementation requirements

If Windows Firewall remains enabled, the host firewall does not need to take any further action.  Nevertheless, the third party firewall must not block the four Teredo requirements below.  If an application is exempted to receive IPv6 traffic in the host firewall, and the application sets a socket option “IPV6_PROTECTION_LEVEL” to “PROTECTION_LEVEL_UNRESTRICTED” (https://msdn.microsoft.com/en-us/library/aa832668(VS.85).aspx) the application will now be capable of receiving Teredo traffic (however, a host firewall can still restrict traffic as per the next section).

The client firewall MUST allow resolution of teredo.ipv6.microsoft.com

The client firewall MUST exempt UDP IPV4 traffic to/ from remote UDP port 3544.

Port 3544 allows the client to communicate to the Teredo Server

FWPMSystemPortsGet retrieves the dynamic UDP port number used by the Teredo client on the local computer which require UDP exemption.

Client firewalls MUST support the following ICMPv6 error messages & discovery functions (RFC 4443):

Note:  Prior compliance with IPv6 requirements will make the below ICMPv6 messages already supported.

• ICMPV6 Neighbor Solicitation / Neighbor Advertisement – Codes 135 and 136
• Router Solicitation / Router Advertisement – Codes 133 and 134
• ICMPV6 Echo Request/ Reply – Codes 128 and 129
• Destination Unreachable – Code 1
• Packet Too Big – Code 2
• Time Exceeded – Code 3
• Parameter Problem – Code4

The host firewall may notice the packets classified by a. and b. originated from or targeted to the user mode service iphlpsvc and not from the stack.  These packets MUST not be dropped by the host firewall.

If the above ICMPv6 messages cannot be specifically allowed, then the exemption of all ICMPv6 messages should be enabled on the firewall

The client firewall SHOULD allow the system to send and receive UDP/IPv4 packets to UDP port 1900 on the local subnet.

Port 1900 allows UPnP discovery traffic to flow, and while is not necessary, will improve connectivity rates.  Teredo can potentially configure, via UPnP, to enable port forwarding for a single port.

Broken scenarios include communication between certain NAT types, specifically between Symmetric NATs and Restricted NATs.  As Symmetric NATs are popular in hotspots, and Restricted NATs are popular in homes, communication from hotspots to home will potentially be broken.  The broken NAT is the Restricted NAT (home / local).

Firewall Application level changes

When Windows Firewall is disabled, allow rules need to be plumbed for the key ports described in the section above.  An additional requirement is needed to support inbound Teredo traffic, the host firewall must implement the Teredo Security Model as described in https://msdn.microsoft.com/en-us/library/bb190940(VS.85).aspx (the implementation stated in this link is under revision, the information below covers the additions). These filters described in this document are more accurate than those in the link above.

Windows allows applications to set a socket option to allow applications to indicate their explicit intent to receive Teredo traffic to the host firewall via the WFP platform.  In Windows, the socket option for protection level is used to allow an application to define what type of traffic it was willing to receive (IPV6_PROTECTION_LEVEL), as defined in https://msdn.microsoft.com/en-us/library/aa832668(VS.85).aspx.  A host firewall implementation should maintain the following filters to selectively allow Teredo traffic for an application, while blocking it by default for any application without an exemption.

Default Block Filter for Edge Traversed Traffic

A host firewall MUST always maintain a default block filter in ALE_AUTH_RECV_ACCEPT_V6 layer  (note Edge Traversal sublayer) for traffic matching to interface type tunnel and tunnel type Teredo. Presence of this filter indicates there is an edge traversal aware host firewall in the system. Likewise the absence of this filter is considered by Windows as the lack of Edge Traversal aware host firewall in the system. This should be viewed as an API contract between the host firewall and Windows. This filter by default blocks edge traversed traffic to any application.

filter.layerKey      = FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6;
filter.action.type   = FWP_ACTION_BLOCK;
filter.subLayerKey   = FWPM_SUBLAYER_EDGE_TRAVERSAL;
filter.weight.type   = FWP_UINT64;
filter.weight.uint64= 0;
filter.flags = 0;
filter.numFilterConditions        = 2; // Or 3 depending on including the loopback condition
filter.filterCondition            = filterConditions;
filter.displayData.name           = L"Teredo Edge Traversal Default Block";
filter.displayData.description    = L"Teredo Edge Traversal Default Block Filter.";
// Match Interface type tunnel
filterConditions[0].fieldKey = FWPM_CONDITION_INTERFACE_TYPE;*
filterConditions[0].matchType = FWP_MATCH_EQUAL;
filterConditions[0].conditionValue.type = FWP_UINT32;
filterConditions[0].conditionValue.uint32 = IF_TYPE_TUNNEL;
// Match tunnel type Teredo
filterConditions[1].fieldKey = FWPM_CONDITION_ TUNNEL_TYPE;*
filterConditions[1].matchType = FWP_MATCH_EQUAL;
filterConditions[1].conditionValue.type = FWP_UINT32;
filterConditions[1].conditionValue.uint32 = TUNNEL_TYPE_TEREDO;
// Having this condition is OPTIONAL, including this will automatically exempt
// loopback traffic to receive Teredo.
filterConditions[2].fieldKey = FWPM_CONDITION_FLAGS;
filterConditions[2].matchType = FWP_MATCH_FLAGS_NONE_SET;
filterConditions[2].conditionValue.type = FWP_UINT32;
filterConditions[2].conditionValue.uint32 = FWP_CONDITION_FLAG_IS_LOOPBACK;

*There are three classes of interface conditions: Delivery, Arrival, and Next hop.  They control the weak-host model and packet forwarding across interfaces.  The example above uses the delivery class of interface.

Please refer to WFP documentation as your security design must consider each of these cases.

Allow Filters for exempted applications

If an application A (represented as wszApplicationA below) is exempted to receive Teredo traffic on a listening  socket, Host Firewall MUST install a PERMIT filter for this application in ALE_AUTH_RCV_ACCEPT_V6 layer as below.  Please note that depending on how the exemption is configured by the user or the application (see the next section), host firewall MAY include a socket option condition.

   filter.layerKey   = FWPM_LAYER_ALE_AUTH_RCV_ACCEPT_V6;
   filter.action.type      = FWP_ACTION_PERMIT;
   filter.subLayerKey      = FWPM_SUBLAYER_EDGE_TRAVERSAL;
   filter.weight.type      = FWP_UINT64;
   filter.weight.uint64= 1; // Use a weight higher than the default block
   filter.flags      = 0;
   filter.numFilterConditions            = 3; // Or 4 depending on the socket option based condition
   filter.filterCondition         = filterConditions;
   filter.displayData.name        = L"Teredo Edge Traversal Allow Application A";
   filter.displayData.description = L"Teredo Edge Traversal Allow Application A Filter.";
   filterConditions[0].fieldKey = FWPM_CONDITION_INTERFACE_TYPE;
   filterConditions[0].matchType = FWP_MATCH_EQUAL;
   filterConditions[0].conditionValue.type = FWP_UINT32;
   filterConditions[0].conditionValue.uint32 = IF_TYPE_TUNNEL;
   filterConditions[1].fieldKey = FWPM_CONDITION_TUNNEL_TYPE;
   filterConditions[1].matchType = FWP_MATCH_EQUAL;
   filterConditions[1].conditionValue.type = FWP_UINT32;
   filterConditions[1].conditionValue.uint32 = TUNNEL_TYPE_TEREDO;
   FWP_BYTE_BLOB byteBlob = {0};
   filterConditions[2].fieldKey = FWPM_CONDITION_ALE_APP_ID;
   filterConditions[2].matchType = FWP_MATCH_EQUAL;
   filterConditions[2].conditionValue.type = FWP_BYTE_BLOB_TYPE;
   filterConditions[2].conditionValue.byteBlob = &byteBlob;
   filterConditions[2].conditionValue.byteBlob->data = (uint8 *) wszApplicationA;
   filterConditions[2].conditionValue.byteBlob->size =
(wcslen(wszApplicationA) + 1)*sizeof(wchar_t);
   // This filter scopes to exemption to ONLY IF the socket option is set, in other words
   // application has explicitly opted in to receive Teredo traffic
   filterConditions[3].fieldKey = FWPM_CONDITION_ALE_SIO_FIREWALL_SOCKET_PROPERTY;
   filterConditions[3].matchType = FWP_MATCH_FLAGS_ALL_SET;
   filterConditions[3].conditionValue.type = FWP_UINT32;
   filterConditions[3].conditionValue.uint32 =
FWP_CONDITION_SOCKET_PROPERTY_FLAG_ALLOW_EDGE_TRAFFIC;

Dormancy Callout Filter

Teredo service in Windows implements a dormancy model. At any given time, if there exist no application listening on a UDP or TCP socket with edge traversal enabled,  service moves back to dormant state. For the dormancy mechanism to work,  the host firewall MUST maintain one CALLOUT filter for each such exempted application under ALE_AUTH_LISTEN_V6 for TCP, and ALE_RESOURCE_ASSIGNMENT_V6 for UDP based applications. Figure below is an example dormancy callout for a TCP application A.

   filter.layerKey = FWPM_LAYER_ALE_AUTH_LISTEN_V6;
   // Use FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_V6 for UDP based exemption
   filter.action.type      = FWP_ACTION_CALLOUT_TERMINATING;
   filter.action.calloutKey = FWPM_CALLOUT_EDGE_TRAVERSAL_ALE_LISTEN_V6;
   // Use FWPM_CALLOUT_EDGE_TRAVERSAL_ALE_RESOURCE_ASSIGNMENT_V6 for UDP based exemption
   filter.subLayerKey      = FWPM_SUBLAYER_EDGE_TRAVERSAL;
   filter.weight.type      = FWP_UINT64;
   filter.weight.uint64= 1;
   filter.flags      = 0;
   filter.numFilterConditions            = 1; // 2 if including the socket option based condition
   filter.filterCondition         = filterConditions;
   filter.displayData.name        = L"Teredo Edge Traversal dormancy callout for app A";
   filter.displayData.description = L"Teredo Edge Traversal dormancy callout filter for A.";
   FWP_BYTE_BLOB byteBlob = {0};
   filterConditions[0].fieldKey = FWPM_CONDITION_ALE_APP_ID;
   filterConditions[0].matchType = FWP_MATCH_EQUAL;
   filterConditions[0].conditionValue.type = FWP_BYTE_BLOB_TYPE;
   filterConditions[0].conditionValue.byteBlob = &byteBlob;
   filterConditions[0].conditionValue.byteBlob->data = (uint8 *)wszApplicationA;
   filterConditions[0].conditionValue.byteBlob->size =
(wcslen(wszApplicationA) + 1)*sizeof(wchar_t);
   // This filter scopes to exemption to ONLY IF the socket option is set, in other words
   // application has explicitly opted in to receive Teredo traffic
   filterConditions[1].fieldKey = FWPM_CONDITION_ALE_SIO_FIREWALL_SOCKET_PROPERTY;
   filterConditions[1].matchType = FWP_MATCH_FLAGS_ALL_SET;
   filterConditions[1].conditionValue.type = FWP_UINT32;
   filterConditions[1].conditionValue.uint32 =
FWP_CONDITION_SOCKET_PROPERTY_FLAG_ALLOW_EDGE_TRAFFIC;

Exposing the Edge Traversal Flag VIA UI

In an edge traversal aware host firewall, there must be a method for the user to allow an arbitrary application to receive Teredo traffic.  Windows Firewall has chosen to utilize a UI by which users can enable edge traversal traffic on an application specific basis.

The Windows implementation of this Firewall option is available under Windows Firewall Snap-In --> <application name> --> "Advanced" tab.  This "Edge Traversal" option must be enabled individually for each application.   Firewalls should implement a variant of this that accomplishes the same thing.

The "Edge Traversal" option is enabled by the application.  Applications capable of receiving unsolicited traffic should be able to register with the firewall for “Edge Traversal” and receive unsolicited traffic over the Teredo Interface.  In Windows, an application can call the INetFwRule API with the "Edge Traversal" option set to VARIANT_TRUE.  Also they can use the INetFwRule2 API with the EdgeTraversalOptons and set it to “Allow” (equivalent to true above or “Defer to App”. User consent is required for this API call before an application is permitted to listen for the traffic.

Firewalls can utilize the INetFwRule2 API to enumerate all application edge properties as plumbed in Windows Firewall.  These edge properties are available via this API even if Windows Firewall is disabled, and third party firewalls can choose to deal with each of the application settings as they see fit.

In addition, Windows has introduced edge settings called DeferApp and DeferUser, which offer further granular control to the firewall with respect to applications receiving edge traffic.  DeferApp sets the socket option based on the applications socket option setting.  DeferUser  sets the socket option based on user choice, a prompt is thrown when an application wishes to receive unsolicited inbound traffic, and the user is asked whether he chooses to block or allow this traffic.  Below are the user prompts that Windows Firewall throws, and the change in the UI.

The below matrix outlines the behavior of Windows Firewall in conjunction with the above rules.

*For DirectAccess scenarios <link> the host firewall SHOULD allow a method for an IT administrator to unconditionally force (i.e. even if an application has not set the socket option) an application to receive edge traversal traffic.

Scenario outline

1.  Failure to implement the Edge Traversal option:

The most notable Win 7 Scenario to be broken is DirectAccess.  DirectAccess relies heavily on admin control over which applications are allowed edge traffic over the internet.  Failure to implement the Edge Traversal option would lead to network administrators not having a reliable way to allow access to applications remotely, thereby breaking DirectAccess fundamentally.

2.  Failure to implement the Socket Option:

A key Windows 7 scenario, Remote Media Experience, as well as the out-of-box help solution, Remote Assistance, will be broken.  Remote Media Experience plumbs the socket option in Windows Firewall when the user has indicated their desire to share their media over the internet.  This sharing is authenticated via Windows Live identities, however, even with this authentication, failure to subscribe to the socket option will cause the firewall to drop inbound connections from the remote user.  Remote Assistance utilizes Teredo as one of its on-demand connectivity platforms, and failure to implement the socket option will cause users who request assistance to not be reachable by the remote user helping them.

3.  Failure to implement either the Edge Traversal Option or the Socket Option:

Any Windows 7 application with peer to peer connectivity dependent on Teredo will be broken.  Note, not only Microsoft applications will fail, for example, uTorrent is dependent on Teredo.