NAT traversal

2.2.1 NAT

The NAT (Network Address Translation Protocol, [19]) provides a way to alleviate the need of the IP address space due to the Internet booming. It enables hosts beneath a NAT (internal host) to share one common IP address for creating network connections to hosts on the Internet (external host). The NAT replaces the source address and port as its IP address and a dynamically allocated port in the IP header in the outgoing packet. Therefore, the correspondent host believes that the connection is originated from the NAT. Within a NAT connections are identified by the bindings between internal hosts' source ports and NAT's outgoing ports. So, the NAT can pass the replied packet destined to the NAT to the exact internal host. The IP header of the replied packet is restored accordingly.

Though NATs are operated in port oriented, not all the inbound packets arrived at the binding port on a NAT will be redirected to the internal host. The NAT is further classified as full cone, restrict cone, port restrict, and symmetric NAT according to their port binding rules and delivery restrictions. The rule for the former three NAT types to create address binding is the same, where all requests from the same internal IP address and port are associated to the same port binding. However, delivery restrictions are different. A full cone NAT allows return packets to the internal host from any external host as long as the packet is sent to the associated port. A restrict cone NAT is similar to a full cone one except that an external host can send a packet to the internal host only if the internal host had previously sent a packet to it.

A restricted cone NAT maintains a database so as to track which hosts have been visited. A

port restricted cone NAT is like a restricted cone one, but the restriction includes port numbers. A symmetric NAT is more restrictive and secure. Every connection uses a different port binding. Furthermore, only the destination host is allowed to return packets back to the internal host.

Usually, users inside a NAT employ private IPs that are reserved by the Internet Assigned Numbers Authority (IANA, [20]). Since private addresses have no global meaning, routing information about private networks will not be propagated. Thus, any packet addressed to these private IP addresses will be ignored. Consequently, connections originated from an external host to an internal host are forbidden and the NAT traversal problem is formed. The impact of the traversal problem also includes the retention of port bindings, where there is no guarantee that the NAT implementation will keep the port binding for a long time [21]. In addition, locating an internal user is difficult because internal users under different NAT may use the same private IP address. These problems hinder the deployment of VoIP applications.

2.2.2 Application-aware NAT solutions

An application-awareness NAT means that a NAT has the ability to interpret application payloads and create port bindings on demand. An application-aware NAT acts as a translator that translates application packets back and forth and as a router that routes packets between internal hosts and external hosts. This is also referred to as an application level gateway (ALG [22]). An ALG is application dependent, so that it requires special handling for each VoIP application.

Kuthan and Rosenberg [23] suggested decomposition of application-awareness from the NAT. An ALG becomes an intermediate device and controls address processing and associations by communicating with a NAT through a generic application-independent firewall control protocol (FCP). The FCP allocates and releases NAT port binding. Such solution is also known as Middlebox Communications (MidCom [24,25]) where the Middlebox is a device that locates between different realms or networks. Example Middleboxes are NATs. A MidCom agent (an ALG) is a logical entity that is external to a

Middlebox, handling the application specific processing and communicating with one or more Middleboxes. For example, a SIP proxy can embed a MidCom agent and may communicate with NATs or firewalls to request port bindings. Clearly, this method makes changes to the NATs and is impractical because it is impossible to upgrade the all the NATs on the Internet.

2.2.3 Application-unaware NAT solutions

An application-unaware NAT solution leaves NATs unchanged. Rosenberg et al.

suggested such a solution called STUN (Simple Traversal of UDP through NAT, [26]). A STUN server is an external host and acts as a MidCom agent to learn the external NAT transport address of an outbound connection issued by an internal STUN client and report the learned port and address to the STUN client (this procedure is referred to as a port-learning).

Two STUN servers can be used to determine what NAT type an internal STUN client resided by performs sequences of tests for the port binding rule and delivery constraint of the NAT. If the NAT is a full-cone one, the internal user can proceed the call request and use the learned external transport address as its RTP receiving address since the full-cone NAT will relay any incoming packets reached at the bound port to the internal user.

A fortified version of STUN, called TURN (Traversal Using Relay NAT, [27]), was proposed to conquer the constraints of the symmetric NAT type. It uses an external server (TURN server) to relay the packets into a NAT. An internal user may request the TURN server to allocate a pair of transport addresses on the TURN server; one is used as user's destination RTP transport address, and the other is used as a relay transport address that the user host creates an outbound connection to it and receives inbound RTP packets from it.

Hereafter, the TURN server receives the inbound RTP packets coming into the destination port and pushes them out of the relay port into the NAT.

In STUN and TURN, though NATs remain intact, the user agent program should be STUN/TURN enabled and turn off the silence suppression to keep the port binding on NATs.

This requires changes to the VoIP application software.

2.2.4 Locating a VoIP user inside a NAT

To allow inbound calls, internal users are required to register at a registrar (such as SIP Registrar or SIP Proxy) with routable addresses, so that they can be located. J. Rosenberg et al.

[28] suggested employing a STUN server to learn an external signaling address from the outbound REGISTER message out of a NAT as a contact address for call parties. Once the external signaling port binding on the NAT is created, a keep-alive packet should be periodically sent, or the signaling address may expire. Thus, an inbound call request can go through the NAT to the internal user. Unfortunately, not only lots of keep-alive traffic is brought in, but also this external signaling address is not worked for the internal user within a symmetric NAT due to the stern restrictions.

Davies et al. [29] mandated a SIP proxy (a TURN-like server) to allocate transport addresses for relaying both signaling and RTP packets into a NAT. They also introduced a proxy interface agent (PIA) inside a NAT to intervene the call establishment between internal users and the SIP proxy. Internal users consider as if they are communicating with the PIA.

The PIA acts on behalf of one or more internal users and establishes calls with the external users. As a result, inbound RTP packets from an external user are first sent to the SIP proxy, then relayed via the NAT to the PIA, and finally delivered to the internal user. Meanwhile, outbound RTP packets also follow the same way in the reverse direction. A notable drawback is the performance deterioration due to an additional hop-count of the RTP packets via the PIA.

Sen proposed another solution that made changes to the SIP protocol [30]. First, a Behind-NAT tag is added to the REGISTER message indicating a user is behind a NAT. If the tag is set, the SIP proxy should take the source IP address of the REGISTER packet as the user' public address rather than the address specified in the message body. Second, a SIP PING message is introduced for the purpose of keeping the communication path alive between the internal user and the external SIP proxy. Thus, an inbound call request can be delivered to the internal user.

Sen's method does not need a broker to setup a call. Obviously, an internal user takes care of the NAT traversal problem. The internal user must use symmetric RTP, which sends and receives RTP packets at the same port, and acquire a relay transport address from the media proxy as its source and destination RTP connection. That is to say, the internal user sends RTP packets through a NAT to the media proxy, and then the media proxy relays those packets to the other call party. The symmetric RTP benefits inbound packets to travel into a NAT because the outbound packets have created a port binding for them.

The above solutions somehow change the user agent software, the signal proxy, NAT, or all of them, and mandate the coexistence of a signal proxy. Some even alters the protocol.

Since those programs and servers are the productions of some companies and may be difficult to be modified at our wish, it seems impractical to implement those solutions in the near future.