Network Address Translators allow connecting networks using private range addresses to other networks by transparently changing the addresses of the packets that cross the net- work border. Different types of NATs exist and they can be classified by their filtering and mapping behavior. NATs help, among other things, with IPv4 address depletion but they also create problems especially for peer-to-peer connections.
Various NAT traversal mechanisms have been developed to solve these problems. ICE is a robust NAT traversal solution that uses UDP hole punching and STUN/TURN protocols for creating optimal paths between hosts in NATed environments. Basically ICE performs UDP hole punching by probing for connectivity on all different paths between the hosts, but this simple approach is enhanced with a set of optimizations.
Peer-to-peer SIP uses a distributed P2P network architecture for communication and is an example of a P2P application that needs a NAT traversal solution. The Host Identity Protocol solves various problems with host mobility, multihoming, and security by intro- ducing a new host identity namespace and a layer to the TCP/IP stack. HIP has problems with legacy NATs and different NAT traversal solutions have been proposed for it. In the next chapter we present a design and implementation for HIP NAT traversal and in the later chapters we discuss how it can be used for enabling NAT traversal for P2PSIP.
NAT Traversal Using HIP with ICE
In this chapter, we first briefly discuss the need for NAT traversal and present some of the benefits and drawbacks of HIP-based NAT traversal. For solving the NAT traversal problem using HIP, an ICE library was created that could be integrated into a HIP implementation. The following sections discuss how ICE can interwork with HIP and describe the archi- tecture of the library. Also design decision and some implementation experiences from implementing the ICE library are presented.
3.1
Need for NAT traversal
As mentioned in Section 2.1.2, NATs commonly multiplex connections using the transport layer identifiers. If the packets do not contain a transport protocol that is known to the NAT, such as UDP or TCP, they simply drop the them. This alone is enough to block HIP connections that are normally run on top of IP. Besides, HIP should work for both client-server and peer-to-peer connections, so the problems with connecting a host behind a NAT also apply to HIP. Therefore, HIP needs a NAT traversal solution before it can be successfully used in the Internet.
NAT traversal can be performed in many ways and also at different layers of the proto- col stack. Because, today, NATs are so widespread, many applications that need to create peer-to-peer connections must deal with NAT traversal. For example, the Internet tele- phony program Skype is well known for its capabilities for creating connections even in environments with NATs and firewalls [3]. Also, peer-to-peer file sharing programs, such as BitTorrent client BitLord [5], have developed their own NAT traversal techniques.
Instead of developing NAT traversal mechanisms for each protocol or application sepa- rately, all applications could benefit from a lower layer solution. The IPsec tunnel created with HIP looks like a normal IP-based path to the application layer and the applications can
run any protocol on top of it. With a proper NAT traversal solution, HIP is able to create an IPsec tunnel between two HIP-enabled hosts, through the NATs. This way, there is no need for protocol specific NAT traversal but any protocol can be run on top of HIP without worrying about NATs.
3.1.1 Benefits and Drawbacks of Using HIP
Many applications also need more than one concurrent connection between the hosts. For example, a signaling part of the protocol may use different ports than the actual data. The data may also need more than one UDP/TCP port: e.g., audio and video can be transmitted using different ports. Because all upper layer connections between two hosts can be mul- tiplexed into a single UDP encapsulated IPsec connection, the NAT traversal must be done only once between the hosts and all subsequent connections can use the same path.
The downside of this is that a NAT or a firewall in a gateway can no longer protect the host based on TCP/UDP port numbers because all the traffic appears to use the same port. However, even without NAT traversal a HIP host will need to use a firewall at the host since a firewall at the gateway does not know what is transferred in the encrypted ESP connection.1
As noted in Section 2.6, HIP can handle host mobility and multihoming securely and efficiently, which can be especially useful for P2PSIP. A personal communication device that uses P2PSIP, whether it is e.g., a mobile phone or a laptop computer, is likely to be carried around with the user. When the user moves, the terminal may switch to a different network and get a new IP address. A connection that does not support mobility would break, but HIP is able to restore connectivity without breaking upper layer connections. Also, both laptops and mobile phones have today often more than one network interface: laptop computers have commonly both Ethernet and WLAN interfaces and many high- end mobile phones have a WLAN interface in addition to the cellular interface. HIP’s multihoming support can utilize multiple interfaces and switch from an interface to another without disturbing the upper layer connections.