pCDN:NAT

NAT

Network Address Translation (NAT) is a technique that allows multiple hosts on a private network to access the Internet using a single public IP address. This involves overwriting the IP address and port numbers of packets in the router that support address translation. Such a NAT device keeps track of the connections initiated by hosts inside its private network and adds a port mapping for each. Any incoming packet is examined to see if it belongs to a session initiated by one of the hosts inside the private network. The packet is forwarded to the appropriate host if a mapping exists for it, otherwise the packet is dropped. Therefore, hosts behind NAT cannot act as a server unless the NAT device is configured to forward the traffic appropriately. This causes connectivity problems for P2P and VoIP applications, which is referred to as the NAT traversal problem.

NAT Traversal

Several techniques have been proposed to address this NAT traversal problem:

• Relay Server: A straight-forward solution is to set up an indirect connection from a host to another via a relay server that has a public IP. While this approach clearly incurs high overhead and delay, it follows the client-server model well and thus is the most reliable approach.
• Connection Reversal: When a connection has to be set up to a host behind NAT from a host with a public IP, the connection originator can send an out-of-band request to the host behind NAT for a reverse connection. This approach is simple because no NAT configuration is required. It, however, does not solve the double-NAT traversal problem, where both hosts are behind NAT.
• Explicit Configuration: NAT configuration protocols, such as UPnP IGD , have been proposed to learn the public IP address and to add port mappings. This approach is limited because not all NAT devices support these protocols, not mention that there is no unified NAT configuration protocol.
• Implicit Configuration: UDP hole punching was proposed in late 90', in which two hosts behind NAT simultaneously send messages to each other for creating port mappings on both NATs. Similar idea has been recently applied to TCP connections FSK05 GF05 BFWP05. Since NAT behavior is not standardized, hole punching algorithms do not always work. For example, the authors of FSK05 reported 82% and 64% successful rate for UDP and TCP hole punching in a small-scale experiments (380 data points). STUNT protocol uses a public server with global access to discover NAT behavior, which can shed some light on increasing the successful rate. The authors of GF05 estimated a significant TCP hole punching successful rate increase (42% to 85%) by considering NAT behavior discovered by STUNT. They also compared several variations of the TCP hole punching algorithm in the literature, both analytically and empirically.

In pCDN, a peer receives a list of potential senders from the server in response to its query for a specific file. The peer chooses some of these senders, connects to them over TCP, and downloads the requested file. All potential senders are listening for incoming connections from other peers. If a potential sender is behind NAT, the receiver initiates a connection reversal via the server. If both peers are behind NAT however, no connection can be established unless the NAT device is configured properly to pass the traffic through. Moreover, the receiver needs to be aware of the public IP and external port of the sender it is going to connect to. This information should be discovered by each peer through examining and configuring the NAT device it is behind, and reporting it to the pCDN server. The pCDN server in turn provides downloading peers with this information.

Issues

• Not all NAT devices support UPnP IGD protocol, therefore we cannot rely on the NAT device to be easily configurable.
• The behavior of NAT devices can not be predicted precisely. A NAT device may assign a new port number for a connection established on the same local port twice. Therefore, even if we discover the mapping for a connection on local port through some mechanism similar to STUNT, closing the connection and opening it again does not hold the same mapping.
• No new mapping is automatically created unless a packet is sent from within the private network. Therefore, only listening on a local port number does not allow incoming traffic.

Future Work

I miss a recipe for a unified NAT traversal algorithm for peer-assisted applications. For example, each peer should determine whether it is behind NAT using the following steps:

• A peer discovers whether it is behind NAT using a public server.
• If this peer is behind NAT, configure its NAT using UPnP (or friends).
  • If the NAT configuration is successful, we consider this peer is not behind NAT, otherwise we consider it is behind NAT.
• (Optional) A peer behind NAT discovers the characteristics of its NAT device using protocols like STUNT.

When a receiver needs to download from a sender, the receiver takes different strategies based on the following circumstances.

1. Neither hosts is behind NAT: direct connection.
2. Only the receiver is behind NAT: direct connection.
3. Only the sender is behind NAT: connection reversal
4. Both hosts are behind NAT: try the follow until success:
   1. TCP hole punching
   2. UDP hole punching
   3. Relay

Intuitively, we hope most connections can be made without going deep into these steps. However, how deep do we need to go depends on how many users are behind NAT and other factors.