jni/pjproject-android/pjnath/docs/doc_nat.h

/* $Id: doc_nat.h 3553 2011-05-05 06:14:19Z nanang $ */
/* 
 * Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA 
 */


/**

@defgroup nat_intro Introduction to Network Address Translation (NAT) and NAT Traversal
@brief This page describes NAT and the problems caused by it and the solutions



\section into Introduction to NAT


NAT (Network Address Translation) is a mechanism where a device performs 
modifications to the TCP/IP address/port number of a packet and maps the 
IP address from one realm to another (usually from private IP address to 
public IP address and vice versa). This works by the NAT device allocating
a temporary port number on the public side of the NAT upon forwarding 
outbound packet from the internal host towards the Internet, maintaining
this mapping for some predefined time, and forwarding the inbound packets
received from the Internet on this public port back to the internal host.


NAT devices are installed primarily to alleviate the exhaustion of IPv4 
address space by allowing multiple hosts to share a public/Internet address.
Also due to its mapping nature (i.e. a mapping can only be created by 
a transmission from an internal host), NAT device is preferred to be 
installed even when IPv4 address exhaustion is not a problem (for example
when there is only one host at home), to provide some sort of security/shield
for the internal hosts against threats from the Internet.


Despite the fact that NAT provides some shields for the internal network,
one must distinguish NAT solution from firewall solution. NAT is not 
a firewall solution. A firewall is a security solution designed to enforce
the security policy of an organization, while NAT is a connectivity solution
to allow multiple hosts to use a single public IP address. Understandably
both functionalities are difficult to separate at times, since many 
(typically consumer) products claims to do both with the same device and
simply label the device a “NAT box”. But we do want to make this distinction
rather clear, as PJNATH is a NAT traversal helper and not a firewall bypass
solution (yet).



\section problems The NAT traversal problems


While NAT would work well for typical client server communications (such as
web and email), since it's always the client that initiates the conversation
and normally client doesn't need to maintain the connection for a long time,
installation of NAT would cause major problem for peer-to-peer communication,
such as (and especially) VoIP. These problems will be explained in more detail
below.


\subsection peer_addr Peer address problem


In VoIP, normally we want the media (audio, and video) to flow directly
between the clients, since relaying is costly (both in terms of bandwidth
cost for service provider, and additional latency introduced by relaying).
To do this, each client informs its media transport address to the other
client , by sending it via the VoIP signaling path, and the other side would
send its media to this transport address.


And there lies the problem. If the client software is not NAT aware, then
it would send its private IP address to the other client, and the other
client would not be able to send media to this address.


Traditionally this was solved by using STUN. With this mechanism, the client
first finds out its public IP address/port by querying a STUN server, then
send sthis public address instead of its private address to the other 
client. When both sides are using this mechanism, they can then send media 
packets to these addresses, thereby creating a mapping in the NAT (also 
called opening a "hole", hence this mechanism is also popularly called 
"hole punching") and both can then communicate with each other.


But this mechanism does not work in all cases, as will be explained below.



\subsection hairpin Hairpinning behavior


Hairpin is a behavior where a NAT device forwards packets from a host in
internal network (lets call it host A) back to some other host (host B) in
the same internal network, when it detects that the (public IP address)
destination of the packet is actually a mapped IP address that was created
for the internal host (host B). This is a desirable behavior of a NAT, 
but unfortunately not all NAT devices support this.


Lacking this behavior, two (internal) hosts behind the same NAT will not
be able to communicate with each other if they exchange their public
addresses (resolved by STUN above) to each other.



\subsection symmetric Symmetric behavior


NAT devices don't behave uniformly and people have been trying to classify
their behavior into different classes. Traditionally NAT devices are
classified into Full Cone, Restricted Cone, Port Restricted Cone, and 
Symmetric types, according to <A HREF="http://www.ietf.org/rfc/rfc3489.txt">RFC 3489</A>
section 5. A more recent method of classification, as explained by 
<A HREF="http://www.ietf.org/rfc/rfc4787.txt">RFC 4787</A>, divides 
the NAT behavioral types into two attributes: the mapping behavior 
attribute and the filtering behavior attribute. Each attribute can be 
one of three types: <i>Endpoint-Independent</i>, <i>Address-Dependent</i>,
or <i>Address and Port-Dependent</i>. With this new classification method,
a Symmetric NAT actually is an Address and Port-Dependent mapping NAT.


Among these types, the Symmetric type is the hardest one to work with. 
The problem is because the NAT allocates different mapping (of the same
internal host) for the communication to the STUN server and the 
communication to the other (external) hosts, so the IP address/port that
is informed by one host to the other is meaningless for the recipient 
since this is not the actual IP address/port mapping that the NAT device 
creates. The result is when the recipient host tries to send a packet to 
this address, the NAT device would drop the packet since it does not 
recognize the sender of the packet as the "authorized" hosts to send 
to this address.


There are two solutions for this. The first, we could make the client 
smarter by switching transmission of the media to the source address of 
the media packets. This would work since normally clients uses a well 
known trick called symmetric RTP, where they use one socket for both 
transmitting and receiving RTP/media packets. We also use this 
mechanism in PJMEDIA media transport. But this solution only works 
if a client behind a symmetric NAT is not communicating with other 
client behind either symmetric NAT or port-restricted NAT.


The second solution is to use media relay, but as have been mentioned 
above, relaying is costly, both in terms of bandwidth cost for service
provider and additional latency introduced by relaying.



\subsection binding_timeout Binding timeout

When a NAT device creates a binding (a public-private IP address 
mapping), it will associate a timer with it. The timer is used to 
destroy the binding once there is no activity/traffic associated with 
the binding. Because of this, a NAT aware application that wishes to 
keep the binding open must periodically send outbound packets, 
a mechanism known as keep-alive, or otherwise it will ultimately 
loose the binding and unable to receive incoming packets from Internet.


\section solutions The NAT traversal solutions


\subsection stun Old STUN (RFC 3489)

The original STUN (Simple Traversal of User Datagram Protocol (UDP) 
Through Network Address Translators (NATs)) as defined by 
<A HREF="http://www.ietf.org/rfc/rfc3489.txt">RFC 3489</A>
(published in 2003, but the work was started as early as 2001) was 
meant to be a standalone, standard-based solution for the NAT 
connectivity problems above. It is equipped with NAT type detection 
algoritm and methods to hole-punch the NAT in order to let traffic 
to get through and has been proven to be quite successful in 
traversing many types of NATs, hence it has gained a lot of popularity
 as a simple and effective NAT traversal solution.

But since then the smart people at IETF has realized that STUN alone 
is not going to be enough. Besides its nature that STUN solution cannot 
solve the symmetric-to-symmetric or port-restricted connection, 
people have also discovered that NAT behavior can change for different 
traffic (or for the same traffic overtime) hence it was concluded that 
NAT type detection could produce unreliable results hence one should not 
rely too much on it.

Because of this, STUN has since moved its efforts to different strategy. 
Instead of attempting to provide a standalone solution, it's now providing 
a part solution and framework to build other (STUN based) protocols 
on top of it, such as TURN and ICE.


\subsection stunbis STUN/STUNbis (RFC 5389)

The Session Traversal Utilities for NAT (STUN) is the further development 
of the old STUN. While it still provides a mechanism for a client to 
query its public/mapped address to a STUN server, it has deprecated 
the use of NAT type detection, and now it serves as a framework to build 
other protocols on top of it (such as TURN and ICE).


\subsection midcom_turn Old TURN (draft-rosenberg-midcom-turn)

Traversal Using Relay NAT (TURN), a standard-based effort started as early
as in November 2001, was meant to be the complementary method for the 
(old) STUN to complete the solution. The original idea was the host to use 
STUN to detect the NAT type, and when it has found that the NAT type is 
symmetric it would use TURN to relay the traffic. But as stated above, 
this approach was deemed to be unreliable, and now the prefered way to use
TURN (and it's a new TURN specification as well) is to combine it with ICE.


\subsection turn TURN (draft-ietf-behave-turn)

Traversal Using Relays around NAT (TURN) is the latest development of TURN. 
While the protocol details have changed a lot, the objective is still 
the same, that is to provide relaying control for the application. 
As mentioned above, preferably TURN should be used with ICE since relaying 
is costly in terms of both bandwidth and latency, hence it should be used 
as the last resort.


\subsection b2bua B2BUA approach

A SIP Back to Back User Agents (B2BUA) is a SIP entity that sits in the 
middle of SIP traffic and acts as SIP user agents on both call legs. 
The primary motivations to have a B2BUA are to be able to provision 
the call (e.g. billing, enforcing policy) and to help with NAT traversal 
for the clients. Normally a B2BUA would be equipped with media relaying 
or otherwise it wouldn't be very useful.

Products that fall into this category include SIP Session Border 
Controllers (SBC), and PBXs such as Asterisk are technically a B2BUA 
as well.

The benefit of B2BUA with regard to helping NAT traversal is it does not 
require any modifications to the client to make it go through NATs. 
And since basically it is a relay, it should be able to traverse 
symmetric NAT successfully.

However, since it is a relay, the usual relaying drawbacks apply, 
namely the bandwidth and latency issue. More over, since a B2BUA acts 
as user agent in either call-legs (i.e. it terminates the SIP 
signaling/call on one leg, albeit it creates another call on the other 
leg), it may also introduce serious issues with end-to-end SIP signaling.


\subsection alg ALG approach

Nowdays many NAT devices (such as consumer ADSL routers) are equipped 
with intelligence to inspect and fix VoIP traffic in its effort to help 
it with the NAT traversal. This feature is called Application Layer 
Gateway (ALG) intelligence. The idea is since the NAT device knows about 
the mapping, it might as well try to fix the application traffic so that 
the traffic could better traverse the NAT. Some tricks that are 
performed include for example replacing the private IP addresses/ports 
in the SIP/SDP packet with the mapped public address/port of the host 
that sends the packet.

Despite many claims about its usefullness, in reality this has given us 
more problems than the fix. Too many devices such as these break the 
SIP signaling, and in more advanced case, ICE negotiation. Some 
examples of bad situations that we have encountered in the past:

 - NAT device alters the Via address/port fields in the SIP response 
   message, making the response fail to pass SIP response verification 
   as defined by SIP RFC.
 - In other case, the modifications in the Via headers of the SIP 
   response hides the important information from the SIP server, 
   nameny the actual IP address/port of the client as seen by the SIP 
   server.
 - Modifications in the Contact URI of REGISTER request/response makes 
   the client unable to detect it's registered binding.
 - Modifications in the IP addresses/ports in SDP causes ICE 
   negotiation to fail with ice-mismatch status.
 - The complexity of the ALG processing in itself seems to have caused 
   the device to behave erraticly with managing the address bindings 
   (e.g. it creates a new binding for the second packet sent by the 
   client, even when the previous packet was sent just second ago, or
   it just sends inbound packet to the wrong host).


Many man-months efforts have been spent just to troubleshoot issues 
caused by these ALG (mal)functioning, and as it adds complexity to 
the problem rather than solving it, in general we do not like this 
approach at all and would prefer it to go away.


\subsection upnp UPnP

The Universal Plug and Play (UPnP) is a set of protocol specifications 
to control network appliances and one of its specification is to 
control NAT device. With this protocol, a client can instruct the 
NAT device to open a port in the NAT's public side and use this port 
for its communication. UPnP has gained popularity due to its 
simplicity, and one can expect it to be available on majority of 
NAT devices.

The drawback of UPnP is since it uses multicast in its communication,
it will only allow client to control one NAT device that is in the 
same multicast domain. While this normally is not a problem in 
household installations (where people normally only have one NAT 
router), it will not work if the client is behind cascaded routers 
installation. More over uPnP has serious issues with security due to 
its lack of authentication, it's probably not the prefered solution 
for organizations.

\subsection other Other solutions

Other solutions to NAT traversal includes:

 - SOCKS, which supports UDP protocol since SOCKS5.



\section ice ICE Solution - The Protocol that Works Harder

A new protocol is being standardized (it's in Work Group Last Call/WGLC 
stage at the time this article was written) by the IETF, called 
Interactive Connectivity Establishment (ICE). ICE is the ultimate 
weapon a client can have in its NAT traversal solution arsenals, 
as it promises that if there is indeed one path for two clients 
to communicate, then ICE will find this path. And if there are 
more than one paths which the clients can communicate, ICE will 
use the best/most efficient one.

ICE works by combining several protocols (such as STUN and TURN) 
altogether and offering several candidate paths for the communication, 
thereby maximising the chance of success, but at the same time also 
has the capability to prioritize the candidates, so that the more 
expensive alternative (namely relay) will only be used as the last
resort when else fails. ICE negotiation process involves several 
stages:

 - candidate gathering, where the client finds out all the possible 
   addresses that it can use for the communication. It may find 
   three types of candidates: host candidate to represent its 
   physical NICs, server reflexive candidate for the address that 
   has been resolved from STUN, and relay candidate for the address 
   that the client has allocated from a TURN relay.
 - prioritizing these candidates. Typically the relay candidate will
   have the lowest priority to use since it's the most expensive.
 - encoding these candidates, sending it to remote peer, and 
   negotiating it with offer-answer.
 - pairing the candidates, where it pairs every local candidates 
   with every remote candidates that it receives from the remote peer.
 - checking the connectivity for each candidate pairs.
 - concluding the result. Since every possible path combinations are 
   checked, if there is a path to communicate ICE will find it.


There are many benetifs of ICE:

 - it's standard based.
 - it works where STUN works (and more)
 - unlike standalone STUN solution, it solves the hairpinning issue, 
   since it also offers host candidates.
 - just as relaying solutions, it works with symmetric NATs. But unlike 
   plain relaying, relay is only used as the last resort, thereby 
   minimizing the bandwidth and latency issue of relaying.
 - it offers a generic framework for offering and checking address 
   candidates. While the ICE core standard only talks about using STUN 
   and TURN, implementors can add more types of candidates in the ICE 
   offer, for example UDP over TCP or HTTP relays, or even uPnP 
   candidates, and this could be done transparently for the remote 
   peer hence it's compatible and usable even when the remote peer 
   does not support these.
 - it also adds some kind of security particularly against DoS attacks, 
   since media address must be acknowledged before it can be used.


Having said that, ICE is a complex protocol to implement, making 
interoperability an issue, and at this time of writing we don't see 
many implementations of it yet. Fortunately, PJNATH has been one of 
the first hence more mature ICE implementation, being first released
on mid-2007, and we have been testing our implementation at 
<A HREF="http://www.sipit.net">SIP Interoperability Test (SIPit)</A>
events regularly, so hopefully we are one of the most stable as well.


\section pjnath PJNATH - The building blocks for effective NAT traversal solution

PJSIP NAT Helper (PJNATH) is a library which contains the implementation 
of standard based NAT traversal solutions. PJNATH can be used as a 
stand-alone library for your software, or you may use PJSUA-LIB library, 
a very high level library integrating PJSIP, PJMEDIA, and PJNATH into 
simple to use APIs.

PJNATH has the following features:

 - STUNbis implementation, providing both ready to use STUN-aware socket 
   and framework to implement higher level STUN based protocols such as 
   TURN and ICE.
 - NAT type detection, useful for troubleshooting purposes.
 - TURN implementation.
 - ICE implementation.


More protocols will be implemented in the future.

Go back to \ref index.

 */