Anupam Bera

Thursday, 10.06.2021

Introduction and Overview

Network Address Translation (NAT) is used to interact between private and public networks. NAT is a technology by which a gateway router maps the internal network (private IP) and external network (public IP) to facilitate –

• Protect and secure a private network from the outside world.
• The same private IP can be reused to the other private network.
• Using a single public IP address, a large number of hosts can access the global internet.

NAT supports client-to-server communication for various services like web browsing, Email access, File access using FTP, and so forth. As NAT has many benefits, it also has many drawbacks.

Some internet protocols require end-to-end connectivity. Behind NAT all private addresses are covered by one globally accessible address, so it is not always possible for an external host to establish a connection to a particular host in the private network without special configuration like port forwarding. Session Initiation Protocol (SIP) and other media signaling protocols that use the Offer/Answer model fail to establish a peer-to-peer connection when the clients are behind NAT.

There were various attempts to solve this NAT problem but they do not work perfectly in all types of networks. NAT traversal technique using STUN, TURN, and ICE is a solution that is widely used in the SIP client for media communication.

This document summarizes the details to understand NAT, its problems in dealing with SIP clients, and the solution using ICE protocol from a practical point of view.

IP addresses and Network

Network IP addresses can be classified into two major groups:

• Private/Local/Internal – The addresses that are used in the local network (LAN). Generally, this type of IP address is assigned by the network administrator and used to communicate within the same LAN. The private address space is defined in [RFC 1918] and as per this specification the Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internet:10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

• Global/public/External – The addresses that are used on the internet network. A Global or Public Network is an address realm with unique network addresses assigned by the Internet Assigned Numbers Authority (IANA) or an equivalent address registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise.

NAT

NAT (Network Address Translation) is a mechanism for mapping IP addresses and ports between public and private networks. When NAT forwards an outbound IP packet it allocates a temporary port number on the public network side and maps to the IP address and port of the internal host (originator of the packet). This mapping will be maintained for some specific time and upon receiving an inbound packet from the public network (internet) on this public port it forwards back to the internal host.

NAT devices do not behave uniformly. The NAT behavior can be classified into two different angles.

1. Traditional method of classification (RFC 3489).
2. Modern method of classification (RFC 4787).

The traditional method of NAT classification

According to RFC 3489 section 5, the behavior is classified into four different types:

• Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port.  Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address. It is also known as one-to-one NAT. It maps an internal address (I_IP:I_Port) to an external address (E_IP:E_Port); any packets from I_IP:I_Port are sent through E_IP:E_Port.Any external host can send packets to I_IP: I_Port by sending packets to E_IP: E_Port.

• Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port.  Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X. It is also called address-restricted cone NAT. It maps an internal address (I_IP:I_Port) to an external address (E_IP:E_Port); any packets from I_IP:I_Port are sent through E_IP:E_Port.An external host (H_IP: any) can send packets to I_IP: I_Port by sending packets to E_IP: E_Port only if I_IP: I_Port has previously sent a packet to H_IP: any. “any” means the port number doesn’t matter.

• Port Restricted Cone: A port-restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.It maps an internal address (I_IP:I_Port) to an external address (E_IP:E_Port); any packets from I_IP:I_Port are sent through E_IP:E_Port.An external host (H_IP: H_Port) can send packets to I_IP: I_Port by sending packets to E_IP: E_Port only if I_IP: I_Port has previously sent a packet to H_IP: H_Port.

• Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port.  If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used.  Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host. Mainly, it maps a unique internal address (I_IP: I_Port) to an external address (E_IP: E_Port). Only an external host that receives a packet from an internal host can send a packet back.

The modern method of NAT classification

As per the RFC 4787 sections 4 and 5, NAT behavioral types are divided into two attributes: the mapping behavior attribute and the filtering behavior attribute. Each attribute can be one of three types: Endpoint-Independent, Address-Dependent, and Address and Port-Dependent. With this new classification method, a Symmetric NAT is an Address and Port-Dependent mapping NAT.

The following address and port mapping behavior are defined:

Endpoint-Independent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port.  Specifically, X1′:x1′ equals X2′:x2′ for all Y.

Address-Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address, regardless of the external port. Specifically, X1′:x1′ equals X2′:x2′ if and only if, Y2 equals Y1.

Address and Port-Dependent Mapping: The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address and port while the mapping is still active. Specifically, X1′:x1′ equals X2′:x2′ if and only if, Y2:y2 equals Y1:y1.

NAT Traversal Problems for peer-to-peer Communication

For client-server communication such as web and email applications, the NAT is working well because in this model the client always initiates the request to the server and gets the response in the same connection. For peer-to-peer communication, such as SIP where the Offer/Answer model is involved, NAT would cause various problems.

Peer-to-peer media communication: As media relay is costly (bandwidth and latency cost), SIP’s applications prefer media communication directly between the clients. One client passes the media transport information to the other client through the signaling (in the SDP message body inside the INVITE message) path and the other client sends its media to this transport. If the clients are behind the NAT then the other client would not be able to send media to this address and both can then communicate with each other.

Hairpinning: Hairpin is a behavior where a NAT device is able to detect that both clients are in the same internal network by verifying their same public address. All NAT devices do not support hairpinning behavior so in that case, two clients behind the same NAT will not be able to communicate with each other.

Binding Timeout: When NAT creates a mapping between public and private IP addresses it binds this map for a certain amount of time. If no traffic is there within this time it will destroy this binding. The keep-alive mechanism is used to keep this binding open by sending outbound packets periodically.

NAT Traversal Solution

There are various attempts to provide the solution of NAT traversal for peer-to-peer communication. Some of them are either client-centric or server-centric or a mix of server and client implementations such as Universal Plug-and-Play (UPnP), Back to Back User Agents (B2BUA), Application Layer Gateway (ALG), Session Border Controllers (SBC), and so on. The drawback of those solutions is that they are not able to handle all types of NAT.

STUN

Session Traversal Utilities for NAT (STUN) is a client-server protocol that enables a client to discover whether it is behind a NAT, the types of NAT, and which public IP address and port it is able to receive an inbound packet. When a STUN client sends a packet to the STUN server it examines the packet source IP and port, packs this information as STUN response, and sends it to the STUN client. When a host (with STUN client) wants to establish a peer-to-peer connection to the other host, it sends STUN discovered information to the remote peer to receive the inbound packet.

The STUN defined by RFC 5389, deprecated the use of NAT type detection (RFC 3489) and still provides a mechanism for a client to query its public/mapped address to a STUN server.

For peer-to-peer communication most cases (95%) it works. However, this STUN solution cannot solve the symmetric-to-symmetric or port-restricted NAT.

TURN

To overcome this problem it is necessary to use the services of an intermediate host that acts as a relay for the packets when a direct communication path can not be found.  This relay typically sits in the public Internet and relays packets between two hosts that both sit behind NATs.

Traversal Using Relays around NAT (TURN) is a network protocol that allows a host behind a NAT (called the TURN client) to request a TURN server to act as a relay.  The client can arrange for the server to relay packets to and from certain other hosts (called peers) and can control aspects of how the relaying is done.

As relaying is costly in terms of both bandwidth and latency, hence it should be used as the last option.

ICE

Interactive Connectivity Establishment (ICE) is the ultimate NAT traversal solution for a client who wants to make a peer-to-peer connection with a remote client. Combining the STUN and TURN protocol altogether, ICE allows the agents to discover enough information about their topologies to potentially find one or more candidate paths by which they can communicate. It also has the capability to prioritize the candidates, so that the more expensive alternative (relay using TURN) will only be used as the last option.

The basic idea behind ICE is as follows: it discovers the three types of candidate paths it could use to communicate with the other agent.

These might include:

1. Host Candidates: Host candidate to represent its physical network interfaces. A peer host may choose this for communication if both are behind the same NAT as defined in mark (1) in the above figure.
2. Server Reflexive Candidates: Server reflexive candidate for the address that has been resolved from STUN. A peer host selects this path if both are behind the Endpoint-Independent Mapping NAT as defined in mark (2) in the above figure.
3. Relayed Candidates: A transport address allocated from a TURN server (a “relayed address”). A peer host selects this path if both are not behind the Endpoint-Independent Mapping NAT as defined in mark (3) in the above figure.

Systematically the ICE discovers all possible candidate pairs of addresses until it finds one or more pairs of addresses that work. The steps of the ICE negotiation process involve:

• Gathering Candidate Addresses: As mentioned above, it finds three types of candidates:
  • Local Address.
  • Server Reflexive Address resolved by STUN.
  • Relayed Address allocated from the TURN server.

• Prioritizing Candidates: The priority order candidates are Host Candidates, Server Reflexive Candidates, and Relayed Candidates.
• Encoding: Encode these candidates and send them to the peer. In the case of the SIP application, the encoded candidates are sent through the SDP message body in the INVITE request or response for the negotiation.
• Pairing: It pairs every local candidate with every remote candidate that it receives from the remote peer.
• Connectivity Checking: It performs a series of checks by sending a STUN request from the local candidate to the remote candidate to see which pairs work. It checks the high-priority candidates pair first followed by low-priority one. The basic principle of the connectivity checks is simple:
  • Sort the candidate pairs in priority order.
  • Send checks on each candidate pair in priority order.
  • Acknowledge checks received from the other agent.
• Concluding ICE: After checking every possible combination of paths it concludes the result by nominating pairs and updating their state.

ICE in SIP/SDP negotiation

Using an ICE agent, an SIP client gathers all possible candidate pairs of addresses and includes all of them in an SDP offer/answer message body for peer-to-peer media communication.

The following is an example of an SDP offer for both RTP and RTCP that includes ICE attributes. [Color code – Blue: Local Address, Green: Server Reflexive Address resolved by STUN, and Orange: Relayed Address allocated from the TURN server] :

v=0
o=root 492018058 492018058 IN IP4 192.168.19.58
s=Asterisk PBX 13.7.0
c=IN IP4 192.168.19.58
t=0 0
m=audio 20032 RTP/AVP 107 0 8 3 111 101
a=rtpmap:107 opus/48000/2
a=fmtp:107 useinbandfec=1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:60
a=ice-ufrag:62eff296425104a34022ad6c758cf9cb
a=ice-pwd:3d28c3210fb7e60f309713af54a52bee
a=candidate:Hc0a8133a 1 UDP 2130706431 192.168.19.58 20032 typ host
a=candidate:Sb6498922 1 UDP 1694498815 182.73.137.34 20032 typ srflx raddr 192.168.19.58 rport 20032
a=candidate:R12da1700 1 UDP 16777215 18.218.23.0 50402 typ relay raddr 182.73.137.34 rport 51130
a=candidate:Hc0a8133a 2 UDP 2130706430 192.168.19.58 20033 typ host
a=candidate:Sb6498922 2 UDP 1694498814 182.73.137.34 20033 typ srflx raddr 192.168.19.58 rport 20033
a=candidate:R12da1700 2 UDP 16777214 18.218.23.0 64271 typ relay raddr 182.73.137.34 rport 37256
a=sendrecv

The answer of the SDP offer that includes ICE attributes:

v=0
o=- 3751784693 3751784694 IN IP4 182.73.137.34
s=pjmedia
b=AS:117
t=0 0
a=X-nat:1
m=audio 34634 RTP/AVP 107 101
c=IN IP4 182.73.137.34
b=TIAS:96000
a=rtcp:35264 IN IP4 182.73.137.34
a=sendrecv
a=ice-ufrag:6c774083
a=ice-pwd:30024871
a=candidate:Sc0a81362 1 UDP 1862270975 182.73.137.34 34634 typ srflx raddr 192.168.19.98 rport 34634
a=candidate:Hc0a81362 1 UDP 1694498815 192.168.19.98 34634 typ host
a=candidate:Sc0a81362 2 UDP 1862270974 182.73.137.34 35264 typ srflx raddr 192.168.19.98 rport 35264
a=candidate:Hc0a81362 2 UDP 1694498814 192.168.19.98 35264 typ host
a=rtpmap:107 opus/48000/2
a=fmtp:107 useinbandfec=1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

 

References

• RFC 1918 – Address Allocation for Private Internets
• RFC 3489 – STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
• RFC 4787 – Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
• RFC 5245 – Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

To read other blogs click here.