Since NAT traversal problems are caused by NAT behaviors, in this chapter, we not only describe how NAT behaviors operate: Mapping and Filtering, and their definitions but also classify the NATs by measuring and analyzing the traversal ability of ICE in our experiments.
NAT behavior
NAT Mapping
A NAT assigns an external mapping for each UDP and TCP connection based on the source and destination IP and port number. The NAT variation are defined in STUN [2], Cone behavior NAT reuses the mapping which means an address assigned on NAT , as long as the source address and port number of a new connection matches those of the preceding connection while Symmetric behavior NAT assigns the different mapping if the destination of new connection change.
Endpoint Filtering
NAT may filter the inbound packets according to the rule, which is created when an internal endpoint opens an outgoing session through NAT. In this section, we detail the criteria of the filtering rule.
In RFC 4787 [3], authors describe three various filtering behaviors:
Endpoint-Independent, Address-Dependent, and Address and Port-Dependent. The classifications of filtering behaviors are the same on UDP and TCP. If a NAT allows inbound UDP/TCP connections independent of the source address and port number as
long as the necessary state exists for routing the request, we classify such filtering behavior as Endpoint-Independent. If a NAT filters inbound packets whose source matches the destination address of the connection creating this mapping, the filtering behavior of such NAT is classified into Address-Dependent. Similarly, if both address and port number are required, this filtering behavior is called Address and Port-Dependent.
TCP State Tracking
NATs implement a state machine to track the connection-state of a TCP stream.
Although NATs handle the TCP 3-way handshake to establish a connection, not every NAT handles all possible cases of packet sequences. This leads the NAT to close its mapping prematurely and breaks a TCP connection.
Accordingly, we understand that distinct NAT behavior will break peer-to-peer connections and make NAT hard to traverse, and we induce that both Mapping and Filtering behaviors restrict seriously to TCP connections, causing the TCP NAT traversal problem more complicated.
Various NAT combinations
So far endpoints are located behind the four types of NAT, when two endpoints under four NAT types has 4 x 4 = 16 various combinations, we summarize the 16 combinations into 4 combinations in Table 1 and discus which the scenario under combinations could traverse successful in Figure 1.
We estimate which kind of NAT combinations could be traversed as Table 1 shows if endpoints are behind the combinations and attempt to traverse NAT. The white fields of Table 3 mean the combinations that could be traversed successfully. If two peers are behind Cone NAT (Table 1. Combination 1), peer could traverse NAT
because the peers always send packets to the fixed and correct mapping; if one peer under Full Cone or Address Restricted NAT and another under Symmetric NAT (Table 1. Combination 2), the case SHOULD be success because the Filtering behavior of Full Cone and Address Restricted NAT is loose, so the packet 2 in Figure 1(2), which source port has changed and sent out from Symmetric NAT, could traverse them; if one peer is under Port Restricted and another is under Symmetric NAT (Table 1. Combination 3), Port Restricted NAT will filter inbound packet 2 in Figure 1(3) from Symmetric NAT since the source port of packets from Symmetric NAT will be changed, and the Symmetric NAT also filters inbound packets 1 from Port Restricted NAT since the packets reach the previous mapping created by STUN, this combination could NOT be passed; if two peers are behind Symmetric NATs (Table 1. Combination 4), both peers will send packets 1 and 2 in Figure 1(4) to the other side NAT mapping, which is get by traversal technique, but not a correct mapping created by traversal connection, so the combination fails.
Table 1. Classifications of NAT combinations
Figure 1. NAT traversal of combinations
NAT Traversal Techniques
Several NAT behavior-based solutions aim at NAT behavior and are proposed to solve NAT traversal problem. The following lists few solutions required for peer-to-peer connections on UDP and TCP in common use.
UDP NAT traversal
STUN
STUN (Figure 2(a)) is the most commonly used technique to solve UDP NAT traversal problems. It lets NAT applications search for external NAT types [2] and test the public address and port number that NAT allocates before giving the information to the host for automatic connection. STUN evolved from RFC 3489(Simple Traversal of User Datagram Protocol) to RFC 5389(Session Traversal Utilities for NAT), it was redefined a tool that is utilized as part of NAT traversal techniques, and support TCP now.
TCP NAT traversal
STUNT
The approach is proposed in [10], the endpoint sends out a low-TTL SYN packet, then sender aborts the connection attempt and creates a passive TCP socket on the same address and port number. The other then initiates a TCP connection, as illustrated in Figure 2(b). The endpoint needs to select an appropriate TTL value that is large enough to cross NAT and the NAT must not close mapping if it receives ICMP error. It also requires that the NAT accepts an inbound SYN following an outbound SYN – a sequence of packets not normally seen.
P2PNAT
In [6], the authors take advantage of the simultaneous open defined in the TCP specifications [13]. Both endpoints initiate a connection by sending SYN packets. If the SYN packets cross in the network, both the endpoint stacks respond with
SYNACK packets establishing the connection. If one end’s SYN arrives at the other end’s NAT and is dropped before that end’s SYN leaves that NAT, the first endpoint’s stack ends up following TCP simultaneous open while the other stack follows a regular open, Figure 2(c). In the latter case, the packets on the wire look like the STUNT approach without the low-TTL and associated ICMP.
The STUNT approach requires that the NAT accept an inbound SYN after an outbound SYN. In addition, the approach requires the endpoint to retry failed connection attempts in a tight loop until a timeout occurs. If instead of dropping the SYN packet, a NAT responds to it with a TCP RST then this approach devolves into a packet flood until the timeout expires.
Figure 2. NAT traversal techniques for peer-to-peer connectivity, (a)STUN, (b) STUNT, (c) P2PNAT.
ICE-UDP and ICE-TCP
Since several techniques are proposed, all advantage and disadvantage which make each one optimal in some network topologies, but a poor choice in others.
Therefore, we need a single solution which is flexible to work well in all situations.
Figure 3. ICE deployment scenario
ICE is a technique for NAT traversal for UDP-based and TCP-based streams established by the offer/answer mechanism used by protocols such as the Session Initiation Protocol (SIP), combines STUN, STUNT, and P2PNAT techniques for peer-to-peer connectivity, and works by multiplicity of IP addresses and ports derived from STUN in SDP offers and answers, then tests connectivity checks and nominates
the valid connections. Figure 3.show the ICE deployment. In the following we introduce the above ICE procedure in three main parts.
ICE-UDP vs. ICE-TCP
Gathering Candidates
For executing ICE, endpoint needs to identify all of its address candidates.
CANDIDATE is an address combines IP and port. ICE-UDP draft [5] defines few types of candidates derived via STUN [2] for peer-to-peer connection. In ICE-UDP, it defines three candidates for peer-to-peer connectivity: address obtained directly from a local interface (LOCAL CANDIDATE), translated address on the public side of a NAT (SERVER REFLEXIVE CANDIDATE) in Figure 4, besides, sometime discover a new mapping address assigned by Symmetric NAT (PEER REFLEXIVE CANDIDATE). In ICE-TCP defines address for STUNT unidirectional open (ACTIVE CANDIDATE, PASSIVE CANDIDATE), and address for TCP simultaneous open (SIMULTANEOUS CANDIDATE) in Figure 4.
Connectivity Checks
In [5], after local endpoint gathers all candidates, it sends them to remote endpoint over the signaling channel. The candidates are carried in attributes in the SDP offer. When remote peer receives the offer, it performs the same gathering process and responds with its own list of candidates. At the end of this process, each agent has a complete list of both its candidates and remote peer’s candidates. It pairs local and remote candidates up, resulting in CANDIDATE PAIRS, which are possible path for establishing connection. To test which pairs could work, ICE schedules a series of CHECKS. Each check is a STUN request/response transaction that the peer will perform on every candidate pair by sending a STUN request from the local
candidate to the remote candidate on ICE-UDP or ICE-TCP.
The obvious difference of ICE-UDP and ICE-TCP are different connectivity checks. In ICE-UDP, the peer-to-peer check list on endpoint will be “local candidate to server reflexive candidate”, ICE checks the path to remote endpoint behind NAT, and “local candidate to local candidate”, ICE checks weather both endpoints behind identical NATs; in ICE-TCP check list includes “local candidate to local candidate”,
“local candidate to simultaneous candidate” and “local candidate to passive candidate”, which are similar with “local candidate to server reflexive candidate”,
“active candidate to passive candidate” and “passive candidate to active candidate”
are paired to avoid the un-sequence packets causing TCP state filtering. Figure 4, illustrates the different connectivity checks of ICE-UDP and ICE-TCP.
Figure 4. Each candidate location and ICE connectivity check pair in check list
Concluding ICE
ICE assigns one endpoint to be the role CONTROLLING, and another be CONTROLLED. The controlling role is responsible of nominating which candidate pairs will get used for media amongst the ones that are valid. It can do this in one of
two ways – using REGULAR NOMINATION or AGGRESSIVE NOMINATION, the former selects a path after all the checks finish, the later selects one immediately when the check is succeed. Once the nomination completes, the nominated valid pair could provide a path for applications to create peer-to-peer connectivity.