Outline of the Thesis

This paper is organized as follows. In chapter 2, characteristics and behaviors of NATs are described. Many UDP and TCP NAT traversal methods are surveyed in chap-ter 3. In chapchap-ter 4 we review three practical TCP NAT traversal methods to understand their characters comprehensively. In chapter 5, NAT behavior aware approach is de-clared in detail. We include system implementations of NBA in chapter 6. In chapter 7, NAT behavior aware approach and previous TCP NAT traversal are compared according to the experiment results. Finally, we draw conclusions and suggest future works.

Chapter 2 Background

In the chapter, NAT will be described carefully including problems of TCP NAT traversal and the basic principle of NAT operation, mapping rules, filtering rules and TCP state tracking. Although the concept of NAT was proposed more than 15 years [1, 10, 11, 12], neither NAT-related standard nor protocol is specified. As a result, current NAT implementations vary among not only vendors but also NAT models.

2.1 Problems of NAT Traversal

Three characteristics of NAT behaviors affect NAT traversal deeply that are NAT mapping rules, filtering rules and TCP state tracking. NAT uses mapping rules to decide which ports for assigning to each connection and filtering rule for determining whether inbound packets can be sent to hosts behind an NAT via existing mappings. The two rules make it difficult to establish direct connection between two peers behind NATs.

Besides, NAT implements TCP state tracking to trace TCP stage and the mechanism may block unexpected TCP packet sequences. Different NATs may have different NAT TCP state tracking implementations, so peers are more difficult to establish a TCP con-nection between two hosts behind NATs. In the following sections, we describe the three characteristics of NAT behaviors in detail.

2.2 NAT Operation

Figure 2-1 illustrates the case that one host located on a private network wants to communicate with the other host located on a public network. Internal host must first send out an outbound packet though the NAT device to the external host, and NAT will

then generate a mapping entry on its mapping table to keep track of the session. For example in Figure 2-1, the internal host sends out an outbound packet to the external host, and NAT must translate the source address of the outbound packet from private IP address (ex: 192.168.1.10) to public IP address (ex: 140.113.215.183) and source port from local port (ex: 5100) to global port (ex: 12500) so that the packet can be routed on the public network. On the other hand, NAT generates a mapping entry to record the mapping between local IP/Port transport address and global IP/Port transport address (ex: 192.168.1.10:5100 140.113.215.183:12500). When the NAT device receives the inbound packet form the external host to the internal host, it translates the destination IP/Port transport address (ex: 140.113.215.183:12500) of the inbound packet to the cor-responding transport address (ex: 192.168.1.10:5100) according to the mapping table in NAT. The principle of address translation in NAT is based on mapping table. Therefore, any inbound packet from the external host cannot be routed to the internal host by NAT until the internal host has sent out an outbound packet to the external host and a map-ping entry was generated on mapmap-ping table in NAT.

Figure 2-1 NAT Operation

2.3 NAT Mapping Rule

NAT mapping rule defines how NAT assigns public ports to outgoing connections, and it is required for a NAT to maintain a connection between private network and pub-lic network. When an internal host initiates an outgoing connection through an NAT, the NAT assigns a global IP address and a global port number to the connection and then create a mapping entry so that subsequent response packets from an external host can be received by the NAT, translated, and forwarded to the internal host according this entry [8]. NAT mapping rule can be classified into three categories:

 Independent: NAT reuses the port-mapping for subsequent packets sent from the same internal IP/Port transport address to any external IP/Port transport ad-dress. For example, in Figure 2-2, no matter Node A sends packets to different ports P1, P2 on Node B or P3 on Node C, NAT will all reuse the same

port-mapping Pa of its external interface.

 Address dependent: NAT reuses the port-mapping for subsequent packets sent from the same internal IP/Port transport address only to the same external IP address, regardless of the external port. For instance, Figure 2-3 shows that NAT will use the port-mapping Pa when Node A sends packets to P1 and P2 on Node B. But NAT uses port-mapping Pb when the destination is Node C.

 Address and port dependent: NAT reuses the port-mapping for subsequent packets sent from the same internal IP/Port transport address only to the same external IP/Port transport address. As shown in Figure 2-4, if the destination IP address or port is different (Node B with P1 and P2, and Node C with P3), NAT uses different port-mapping (Pa, Pb and Pc).

Figure 2-2 Independent mapping

Figure 2-3 Address dependent mapping

Figure 2-4 Address and port dependent mapping

2.4 NAT Filtering Rule

NAT filtering rule defines which external hosts are allowed to send inbound packets to the corresponding internal hosts via existing mappings [8]. NAT filtering rule can al-so be classified to three categories:

 Independent: Internal hosts send packets to any external IP address is suffi-cient to allow any packets from external host with any IP address and port back to the internal host. As shown in Figure 2-5, once the session between Node A and Node B has been established by Node A, any inbound packets from exter-nal hosts such as Node B and Node C can pass the NAT via this port-mapping.

 Address dependent: Internal hosts receiving packets from a specific external host are necessary for internal hosts to send packets first to that specific exter-nal host's IP address. For instance, Figure 2-6 shows that once the session has been established by Node A between Node A and Node B, only inbound pack-ets from external host Node B with P1 and P2 can pass the NAT via this port-mapping.

 Address and port dependent: This behavior is similar to the previous catego-ry. Internal hosts receiving packets from a specific external host are necessary for them to send packets first to that specific external host's IP address and port. For example, in Figure 2-7, once the connection has been established by Node A between Node A and Node B, only inbound packets from external host Node B‟s port P1 can pass the NAT via this port-mapping.

Figure 2-5 Independent filtering

Figure 2-6 Address dependent filtering

Figure 2-7 Address and port dependent filtering

2.5 NAT Variations

For UDP, NAT‟s treatment of packets varies among implementations. Typically, NAT devices can be classified into two categories such as Cone NAT and Symmetric NAT based on mapping rule [4]. Cone NAT assigns the same public port for all connec-tions from the same local port; Symmetric NAT assigns a unique public port for differ-ent connections.

Cone NAT can be further classified into Full Cone, Restricted Cone and Port Re-stricted Cone based on filtering rule [4]. In the following, we describe the four catego-ries of NAT carefully.

 Full Cone: All outgoing packets from the internal host with the same internal IP/Port transport address are mapped to the same external IP/Port transport address. Moreover, all external hosts can send packets to the internal host by using the mapped external IP/Port transport address.

 Restricted Cone: All outgoing packets from the internal host with the same internal IP/Port transport address are mapped to the same external IP/Port transport address. But only internal hosts who ever send packets to the specific external host‟s IP address can receive packets from the specific external host.

 Port Restricted Cone: All outgoing packets from the internal host with the same internal IP/Port transport address are mapped to the same external IP/Port transport address. But only internal hosts who ever send packets to the specific external host‟s IP/Port transport address can receive packets from the specific external host.

 Symmetric: If the same internal host sends a packet with the same source ad-dress and port to a different destination IP adad-dress or port, and NAT would use a different mapping. Furthermore, only internal hosts who ever send packets to

the specific external host‟s IP/Port transport address can receive packets from the specific external host.

However, RFC 5389 which evolves from the STUN protocol, RFC 3489, had re-moved the algorithm for NAT variations detection because NATs nowadays cannot be classified into those four types of behaviors. But this is a familiar classification when we study NAT technology. So, we still describe it in this section.

2.6 NAT TCP State Tracking

The TCP three-way handshake known technically as the SYN, SYN-ACK and ACK is the process for establishing a TCP connection as shown in Figure 2-8. However, two hosts behind different NATs cannot establish a TCP connection through normal TCP three-way handshake process so that special TCP packet sequence flows will ap-pear. The special packet sequence flows are caused not only by current TCP NAT tra-versal methods but also by NAT response. For example, scenario 1 and scenario 2 in Figure 2-9, there are many vendors use a lightweight state machine within the NAT Session to track the current state of a TCP connection [13] and determine when connection-state can be garbage-collected. NAT may block unexpected packets se-quences according to its implementation of TCP state tracking mechanism.

Figure 2-8 TCP three-way handshake

Figure 2-9 TCP state tracking

Chapter 3

Related Work

In this chapter, a number of current researches and techniques related to UDP and TCP NAT traversal problem will be described. Then, a major issue which affects TCP NAT traversal problem will also be depicted.

3.1 UDP NAT Traversal 3.1.1 STUN

Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows hosts to discover not only the presence and types of NATs and firewalls between them but also the public IP/Port transport addresses [4]. STUN Server is a third-party network server with two IP addresses and two ports as shown in Figure 3-1. STUN is a commonly used technique to solve UDP NAT traversal problems. Internal host uses STUN server to realize the public IP and port-mapping on its NAT and then other host may use this port-mapping to send inbound packets to the internal host in some types of NATs.

RFC 5389 [9] is a new specification of STUN named “Session Traversal Utilities for NAT”, and it is an evolution from RFC 3489. The original STUN protocol defined a NAT type discovery process flow for applications to discover the type of an NAT. But new STUN protocol had removed this algorithm for NAT type detection and binding lifetime discovery. Because NATs nowadays may not fit into those type classifications which we have described in session 2.5, and the algorithm was found to have some er-rors [9]. RFC 5389 also defines STUN protocol to have additional capability such as checking connectivity between two peers behind different NATs and a keep-alive

pro-tocol to maintain NAT mappings.

However, since symmetric NAT assigns a unique public port for each connection to a specific IP/Port transport address, we cannot use STUN to traverse this category of NATs.

Figure 3-1 STUN Architecture

3.1.2 TURN

Traversal Using Relays around NAT (TURN) is a protocol that allows the host behind a NAT to control the operation of the relay server and to exchange packets with its peers using the relay [5]. Once hosts behind different NATs want to communicate with each other, they can establish their own connection with the third-party network server named TURN server, and TURN server would help them to redirect data to the other hosts. Figure 3-2 shows the typical operation of TURN. In Figure 3-2, Node A

relay resource X to host B. Once two hosts want to communicate with each other, they can just send data to the relay resource X, and TURN server will redirect data to the other host. This relay approach is a useful NAT traversal method.

However, when two hosts use TURN server as a relay server to communicate with each other, they must occupy additional network bandwidth. Therefore, although TRUN can traverse all types of NATs, it has the lowest priority in NAT traversal me-thods.

Figure 3-2 TURN Architecture

3.1.3 ICE

Interactive Connectivity Establishment (ICE) makes use of integrating some NAT traversal techniques such as STUN and TURN, and it is a protocol for UDP (ICE-UDP) and TCP (ICE-TCP) NAT traversal. Once two hosts behind NATs want to check con-nectivity, they would collect their own possible candidates which are a multiplicity of IP addresses and ports from STUN and TURN. Then two hosts use ICE to exchange those candidates, ICE would make pairs of two hosts‟ candidates and try systematically all

possible pairs until it finds one or more direct connectivity path.

Figure 3-3 is an example for ICE-UDP. Both two hosts must collect its own can-didates which are local address, server reflexive address from STUN server and relay address from TURN server. ICE makes pairs of two hosts‟ candidates to nine possible pairs and checks connectivity of each pair.

Figure 3-3 ICE Architecture

However, ICE brings about a large delay during connection setup since these col-lection steps and check procedure have to be performed for any new connectivity re-quest. Moreover ICE only establishes connections between applications on two hosts which have the knowledge of ICE protocol. As a result ICE cannot be seen as a solution for arbitrary applications.

3.2 TCP NAT Traversal

TCP NAT traversal is more complex than UDP because most NATs implement TCP state tracking mechanism to track the current state of a TCP connection. In this section, three implement TCP NAT traversal methods which are proposed in recent lite-ratures will be described.

3.2.1 STUNT

Simple Traversal of UDP Through NATs and TCP too (STUNT), which extends STUN to include TCP functionality, is a lightweight protocol that assists hosts behind NATs to determine external IP address and port number. It also helps hosts traverse NAT to establish TCP connections. STUNT was proposed in [14] including two TCP NAT traversal methods named STUNT #1 and STUNT #2, illustrated in Figure 3-4 and Figure 3-5 respectively.

Figure 3-4 STUNT #1

Figure 3-5 STUNT #2

In STUNT #1, when hosts behind different NATs want to establish a TCP con-nection, both hosts must first send an initial SYN packet to each other. However, un-solicited packets may cause side effects of NAT while establishing two hosts‟ connec-tions. Therefore, the initial SYN packets are set with low time to live (TTL) values to cross their NATs, but the SYN packets must not reach other host‟s NAT and will be dropped in the network (once the TTL expires). Second, both hosts learn the TCP se-quence number of the initial SYN packets over PCAP or a RAW socket and send their respective TCP sequence number to a globally reachable third-party named STUNT server. The STUNT server resides in public network and spoofs a relative SYNACK to each host with the appropriately sequence numbers as the packet comes from the other host. Finally, host will respond an ACK packet to the other host for completing TCP 3-way handshake.

STUNT #2 is similar to the STUNT #1, but only one host sends out a low -TTL SYN packet. Then sender aborts this connection attempt and creates a passive TCP socket on the same IP address and port number. The other host then initiates a 3-way handshake procedure to establish a TCP connection. However, there are some issues existing on STUNT such as NAT characteristics, host requirements and the spoofing requirement for the STUNT Server.

3.2.2 NATBlaster

In [15], the authors propose a novel mechanism named NATBlaster to create direct TCP connections between two hosts behind middle-boxes with minimal help from a third-party. NATBlaster as shown in Figure 3-6 is similar to STUNT #1 except that instead of spoofing SYNACK packets by STUNT server, the two hosts exchange the sequence numbers and each crafts a SYNACK packet the other expects to receive.

Figure 3-6 NATBlaster

3.2.3 P2PNAT

In [2], the authors take advantage of the simultaneous open scenario defined in the TCP specifications [2]. As illustrated in Figure 3-7, each host initiates a TCP 3-way handshake procedure to establish TCP connections. First, both hosts establish TCP connections with a well-known rendezvous server which records each registered client‟s public and private IP addresses. Second, client A uses its active TCP session with server to ask server for help connecting to client B. Third, server replies B‟s pub-lic and private address to A, and at the same time sends A‟s pubpub-lic and private address to B. Finally, client A and B each asynchronously make outgoing connection attempts to the other‟s public and private address as replied by server, while simultaneously listening for incoming connections on their respective local TCP ports. If one of the outgoing connection attempts fails due to a network error such as “connection reset”

or “host unreachable”, the host simply retries that connection attempt after a short de-lay (e.g., one second), up to an application-defined maximum timeout period.

Figure 3-7 P2PNAT

3.3 Issue in TCP NAT Traversal

NAT mapping rule, filtering rule and TCP state tracking are the characteristics that affect TCP NAT traversal. NATs handle outbound packets differently by using dif-ferent mapping rules and inbound packets by filtering rules so that NAT traversal may fail in establishing a connection between two hosts because of the two rules. NAT may block unexpected TCP packet sequence according to its TCP state tracking mechanism.

Many TCP NAT traversal methods have been proposed for TCP NAT traversal problem, and different methods may work for different NAT combinations. Therefore, we need to apply several traversal methods to increase direct connection rate while traversing NATs.

There are two general schemes for applying traversal methods to do connectivity check such as sequential connectivity check (SCC) and parallel connectivity check (PCC). The former scheme applies NAT traversal methods sequentially while the latter scheme per-forms in parallel. However, the two schemes have no idea about applicability of NAT Traversal methods to types of NATs, and apply traversal methods in a try-and-error fa-shion. So, they consume large amounts of system resources and time delay to traverse NATs.

In this paper, an effective NAT Behavior-Aware (NBA) TCP traversal scheme was proposed. It takes NAT information about mapping rules, filtering rules and TCP state tracking into consideration to select the most appropriate NAT traversal method.

Chapter 4

Analyze TCP NAT Traversal Methods

We have introduced many TCP NAT traversal methods in above chapter, actually there are three practical TCP NAT traversal methods in recent years, and each method may generate a specific packet sequence and thus only works well for the NATs that al-low such packet sequences. Therefore, as long as we realize the packet sequences ap-pear while applying each method, we will know what kinds of TCP NAT traversal me-thods can work well for the combination of two NATs. In this chapter, we review three practical TCP NAT traversal methods to realize kinds of packet sequences which appear while applying these methods. The results are important for NBA to determine NAT type examinations. The three traversal methods are listed as follows:

We have introduced many TCP NAT traversal methods in above chapter, actually there are three practical TCP NAT traversal methods in recent years, and each method may generate a specific packet sequence and thus only works well for the NATs that al-low such packet sequences. Therefore, as long as we realize the packet sequences ap-pear while applying each method, we will know what kinds of TCP NAT traversal me-thods can work well for the combination of two NATs. In this chapter, we review three practical TCP NAT traversal methods to realize kinds of packet sequences which appear while applying these methods. The results are important for NBA to determine NAT type examinations. The three traversal methods are listed as follows: