NAT Traversal

Overview

NAT (Network Address Translation) is widely used to connect private networks to the internet. The main idea is to map several private IP addresses to only one public IP address. Having in mind that P2P network clients should be able to communicate with each other, one basic question comes into mind: how can internet hosts communicate with a host in a private network? We will first have a look at NAT itself and problems it brings. Then, we show how to traverse NATs by either changing router's configuration or by using other tricks.

Network Address Translation

A network address is simply the IP address ( + Port number for UDP/TCP). A NAT router receives an incoming IP packet, saves the address in its NAT table, rewrites sender address to one of its public addresses and sends the packet to the destination address. Now, the NAT router accepts incoming packets on this public address (NAT endpoint). These packets are forwarded to the private host. The most important facts are:

• The mapping depends on the sender's port number. If the private host uses two different outgoing port numbers, the NAT endpoints will differ.
• The private host has to send first. Otherwise no incoming packets will be forwarded to the private host.
• The client does not know all that... (NAT should be completely transparent to the client)

The behavior of the NAT router is not standardized. The only thing that works with every NAT router is simple request and answer. That means the remote host answers a request using the port number the client used for its request. Some NATs allow replies from other ports or even hosts, some use different endpoint mappings for every session.

According to their behavior, NATs can be classified into four types:

• Full Cone
• Restricted Cone
• Port Restricted Cone
• Symmetric

Full Cone NAT A private host (PH) sends an initial request to A. As a result, the NAT router opens a public endpoint. Every connection to any remote host from PH's port A will be mapped to the same port A' at the NAT router. If PH uses port B, the mapping will be B' and not A'. Now NAT's endpoint is availiable to all remote hosts. Every host may send a message from any source port to NAT's endpoint.

Figure 1: Full Cone NAT

Restricted Cone NAT The behavior of Restricted Cone NATs is nearly the same as Full Cone NATs, except that not every other host may send a message to the public endpoint. Depending on the implementation, NAT router rejects the packet or simply drops it. In case the PH sends a message to another remote host, this host will be able to give an answer. Whether the same NAT endpoint is used or not depends on the port PH uses for sending the message (see above).

Figure 2: Restricted Cone NAT

Port Restricted Cone NAT This type of NAT implements a stronger restriction then Restricted NAT. The restriction now focusses on the target port (and the target host since it is a higher restriction).

Figure 3: Port Restricted Cone NAT

Symmetric NAT Here are the highest restrictions. In opposition to cone NATs, every target host and port will be mapped to another endpoint. While Cone NATs use the same endpoint for every PH's source port, Symmetric NAT uses different endpoints. One endpoint mapps to exactly one (IP,Port_R,Port_PH)-Tuple. Port_R means remote port, Port_PH means private host's source port.

Figure 4: Symmetric NAT

Router configuration

NAT-Traversal kann dort durchgeführt werden, wo das Problem entsteht, nämlich im lokalen Netzwerk. Hierzu werden zwei Techniken vorgestellt, die lokal am NAT-Router durchgeführt werden.

Port forwarding

Ein probates Mittel für NAT-Traversal ist die manuelle Konfiguration des NAT-Routers. Dabei wird der NAT-Router so konfiguriert, dass er bestimmte Datenpakete an einen bestimmtem lokalen Rechner weiterleitet. Die Weiterleitung bestimmt der NAT-Router in der Regel auf Grund des Zielportes im Datenpaket. Der NAT-Router benötigt somit für das Port-Forwarding eine Portnummer (bzw. einen Portbereich) und die IP-Adresse des lokalen Rechners. Über diese feste Weiterleitung anhand der Portnummer ist der lokale Rechner außerhalb des Netzwerkes über diesen festgelegten Port (bzw. Portbereich) erreichbar (NAT-Traversal).

Der grosse Vorteil vom Port-Forwarding ist, dass es für viele Anwendungsfälle die einzig wirklich funktionierende NAT-Traversal-Technik darstellt. Demgegenüber stehen jedoch einige Nachteile:

• Andere lokale Rechner können durch die feste Zuordnung von einer Portnummer zu einen bestimmten Rechner, diesen Port nicht nutzen
• viele Anwendungen wählen den Port dynamisch, so dass dieser vorher schwer bestimmbar ist oder wählen einen Port aus einem grossen Port-Bereich
• Port-Forwarding setzt einen Zugang zum Router und technisches Verständnis voraus

UPnP

Eine andere Möglichkeit, ausgehend vom Port-Forwarding, ist den Vorgang der Routerkonfiguration zu automatisieren. Der Gedanke hierbei ist, dass Anwendungen auf den lokalen Rechnern den NAT-Router nach ihren Bedürfnissen steuern können. Die Bedürfnisse hierbei sind vor allem das Port-Forwarding und die Kenntnis darüber welche öffentliche IP-Adresse der NAT-Router besitzt. Es wird bei dieser Technik davon ausgegangen, dass sich im lokalen Netzwerk, indem sich die loklalen Rechner und der NAT-Router befinden, niemand mit böswilliger Absicht aufhält und der Zugang zum lokalen Netzwerk entsprechend gesichert ist. Durch diese Technik werden einige Nachteile des manuellen Port-Forwarding behoben. Realisiert werden kann diese NAT-Traversal-Technik durch "Universal Plug and Play" (UPnP). UPnP wurde 1999 durch das UPnP-Forum spezifiziert und wird von diesem ständig weiterentwickelt. UPnP wurde nicht für NAT-Traversal entwickelt, sondern für eine herstellerunabhängige Steuerung von elektronischen Geräten über ein IP-Netzwerk und kann somit für NAT-Traversal benutzt werden. UPnP wurde so entworfen, dass es bereits vorhandene Netzwerkprotokolle und Datenformate, wie HTTP, SSDP, XML, usw. benutzt. Voraussetzung für die Implementierung von UPnP auf einem Gerät ist, dass auf diesem ein Betriebssystem und eine Netzwerkschnittstelle vorhanden ist. Viele im Handel erhältliche NAT-Router unterstützen bereits UPnP, sodass NAT-Traversal mittels UPnP bereits in Anwendung ist. Der allgemeine Ablauf für eine Kommunikation zwischen einem UPnP-Gerät (z.B. NAT-Router) und einem UPnP-Kontrollpunkt (z.B. lokaler Rechner) sieht im Groben folgendermaßen aus:

1. Das UPnP-Gerät macht sich und seine Dienste im lokalen Netzwerk über Multicast bekannt. Der UPnP-Kontrollpunkt erhält über diese Multicast-Nachrichten (Simple Service Discovery Protocol) Information darüber, um was für ein Gerät es sich handelt (z.B. Internet Gateway Device, Printer Device, HVAC (heating, ventilation, air conditioning) usw.) und unter welcher Adresse er detaillierte Informationen über das Gerät erhalten kann.
2. Der UPnP-Kontrollpunkt kann sich über diese Adresse die detaillierte Geräte- und Dienstbeschreibung (XML) vom Gerät holen.
3. Anhand dieser Informationen wird der Kontrollpunkt in die Lage versetzt, das Gerät zu steuern. Der Kontrollpunkt kann nun über spezielle Nachrichten (SOAP) Aktionen aufrufen (z.B. AddPortMapping).

Aufgrund der vom UPnP-Forum standardisierten Geräte kann diese Kommunikation mit einem UPnP-Gerät durch eine Client-Anwendung ausgeführt werden.

STUN

Einführung:

STUN - Simple Traversal of UDP through NATs ist ein einfaches Client-Server-Protokoll, das zu den ersten Lösungsansätzen der NAT-Problematik zählt. Im RFC 3489 (2003) wurde dieses Protokoll als Standard definiert. Da der Datenaustausch zwischen Client und Server einfache Requests- und Response-Messages sind, wählte man UDP als Kommunikationsbasis. STUN ist kein Allheilmittel, insbesondere hinter symmetrischen NATs ist der Einsatz von STUN kaum sinnvoll.

Ziel:

Mithilfe von STUN erlangt ein interner Client Kenntnisse darüber, ob er hinter einem NAT ins öffentliche Netz gelangt, erhält Informationen über bestehende NAT-Bindings (Adressumsetzungseinträge in einem NAT-Router) und kann testen, hinter welchem NAT-Typ er sich befindet. Diese Ziele werden im Wesentlichen dadurch erreicht, indem der externe STUN-Server dem internen Client mitteilt unter welcher öffentlichen IP- und PORT-Adresse der Client erreichbar ist. Diese Informationen sind wichtige Voraussetzungen für den Aufbau einer erfolgreichen P2P-Kommunikation. Ein interner Client kann bspw. somit in einem Datenpaket einem beliebigen externen Peer mitteilen, über welche PORTs er erreichbar ist. Dies ist zum Beispiel beim Aufbau einer VoIP-Verbindung sinnvoll, wenn es darum geht RTP und RTPC-Datenströme zu koordinieren. Näheres findet man hierzu im Kapitel "NAT and Voice over IP".

Im Vergleich zu UPnP und PORT-forwarding sind bei STUN keine Änderungen am NAT-Router nötig. Die Unterstützung von vielen NAT-Typen (Ausnahme: symmetrischer NAT) und die Tatsache, dass hierbei kein spezielles Router-Verhalten Voraussetzung ist, sorgt für eine breite Verwendung dieses Protkolls. Auch der typische Einsatz von mehreren NATs in Reihe beeinträchtigt die Funktionalität von STUN nicht.

Idee und Technik: Eine typische STUN-Konfiguration wird durch das nebenstehende Schaubild veranschaulicht. Hier durchqueren die Datenpakete des Clients zwei NATs, ehe sie den Weg ins öffentliche Netz gefunden haben. Der schon angesprochene STUN-Server muß sich in diesem öffentlichen Netzwerk (Internet) befinden.	Figure 8: STUN-Config
STUN-Datenpakete müssen gemäß RFC 3489 die folgende Struktur haben. Das Feld Message Type im Header eines STUN-Pakets identifiziert den Nachrichten-Typ. Das Protokoll sieht Nachrichten zur Authentifizierung vor und Nachrichten, die der eigentlichen STUN-Funktionalität dienen. Im letzeren Fall werden Binding Request, Binding Response und Binding Error Response unterschieden, wobei eine Nachricht von Typ Binding Error Response auf einen Fehler hindeutet, der im Payload des Datenpakets genauer spezifiziert wird.	Figure 9: STUN-Paket
Im folgenden Schaubild ist der typische Ablauf eines Binding Request und Binding Response abgebildet. Zuvor jedoch muß der Software, in der das STUN-Protokoll clientseitig implementiert ist, der Ort des STUN-Servers bekannt sein. In einigen Fällen ist die Adresse des STUN-Servers im Client voreingestellt. Anderenfalls ist es möglich per DNS-Anfrage, Adressdaten über mögliche STUN-Server zu beziehen. Bevor der Client ein Binding Request an den Server schicken kann, muß er sich jedoch zuvor beim Server authentifizieren. Nach dem Authentifizierungsvorgang und dem erfolgreichen Absenden eines Binding Request, erhält der Client ein Binding Response. Dieses Datenpaket enthält ein Attribut MAPPED-ADRESS, welches die öffentliche IP- und PORT-Adresse des Clients beinhaltet.	Figure 10: STUN-Ablauf

Der im vorherigen Absatz beschriebene Mechanismus wird unter gerinfügigen Änderungen mehrmals durchgeführt. Dabei sind drei Tests zu unterscheiden. Die Auswertung dieser Tests gibt Auskunft darüber, ob sich der Client hinter einem NAT befindet und wenn ja, um welchen Typ es sich dabei handelt.

Test I Der erste Test verfährt nach dem einfachen Prinzip, welches wir jetzt bereits unter dem typischen Ablauf von Binding Request und Binding Response kennengelernt haben. Beim Analysieren der MAPPED-ADRESS wird die dort repräsentierte IP- und PORT-Adresse mit der lokalen verglichen. Sind beide identich, findet keine Adressumsetzung statt; der Client hat also direkten Zugang zum öffentlichen Netzwerk. Falls sich die Adressen unterscheiden, wird von dem Vorhandensein eines NAT-Routers ausgegangen. Test II Der Client sendet nun ein zweites Binding Request an den STUN-Server, dabei wird jedoch das CHANGE-REQUEST-ATTRIBUT verwendet. Dies veranlaßt den Server seine Absenderkennung (IP- und Port-Adresse) zu ändern. Empfängt der Client dieses Binding Response, ist es offensichtlich, dass der NAT-Router vom Typ Full Cone ist. Test Ia Analog zu Test I sendet der Client nun ein Binding Request an den STUN-Server, hierbei verwendet er jedoch als Ziel die veränderte Absenderkennung des STUN-Servers. Ein Blick in das Binding Response des Servers und ein Vergleich der MAPPED-ADRESS mit derjenigen aus Test I, läßt bei Ungleichheit auf einen symmetrischen NAT schließen. In diesem Fall wird deutlich, dass der NAT-Router für jede Verbindung zu jedem sich in IP- und Port-Adresse unterscheidenen externen Peer ein eigenes Binding erzeugt. Bei Gleichheit wird mit Test III fortgefahren. Gleichheit bedeutet in diesem Fall, dass der NAT-Router durchaus das Mapping mehrerer Peers auf ein und dasselbe interne Adresspaar (IP + Port) zuläßt, sofern der interne Client ein Datenpaket an den jeweiligen Peer im Vorfeld gesendet hat. Test III Das Ergebnis des letzten Testes läßt darauf schließen, ob sich der Client hinter einem Restricted oder PORT-Restricted NAT befindet. Hierfür sendet der Client ein Binding Response wiederum mit dem schon angesprochenen CHANGE-REQUEST-ATTRIBUTE. Dieses Attribut besteht im Wesentlichen aus 2 Flags (change IP, change Port). Während im Test II noch beide Flags gesetzt waren, ist jetzt nur das Flag change PORT gesetzt. Der Server wird also informiert lediglich den PORT in seiner Absenderkennung zu ändern. Die IP-Adresse entspricht der primären Zieladresse des STUN-Servers, an die das Binding Request gesendet wurde. Bleibt die Antwort (Binding Response) aus, kann der Client davon ausgehen, dass er sich hinter einem PORT-RESTRICTED-NAT befindet; der NAT-Router leitet also nur eingehende Pakete ins lokale Netzwerk, sofern die Absenderkennung (IP- und PORT-Adresse) mit einem im Vorfeld clientseitig adressiertem Ziel übereinstimmt. Trifft ein Binding Response ein, handelt es sich um einen RESTRICTED-NAT.

Figure 11: STUN-Test

TURN

Einführung:

TURN (Traversal Using Relay NAT), als ein noch sehr junger Ansatz zur Lösung des NAT-Problems, versucht die Grenzen des STUN-Protokolls aufzuweichen. Wie im vorherigen Kapitel angesprochen, macht der Einsatz von STUN hinter symmetrischen NATs wenig Sinn. Diesem und anderen typischen NAT-Problemen, versucht sich der Internet-Draft (2005) über TURN anzunehmen. Dabei liegt ein besonderes Augenmerk darauf, das schwierige Problem symmetrischer NATs in der Form zu vereinfachen, dass wir es im Endeffekt nur noch mit restriktiven NAT-Typen zu tun haben.

Ziel:

Das STUN-Protokoll ermöglicht es nicht beim Einsatz symmetrischer NATs, dass ein Client (intern) von mehreren externen Hosts adressiert werden kann. TURN, ein typisches Client-Server-Protokoll, welches eng an STUN anknüpft, weist einen ersten Ansatz zur Lösung dieses Problems auf. Im Gegensatz zu STUN, sind bei TURN TCP- und UDP-Verbindungen als Kommunikationsbasis erlaubt. TURN steckt sich das Ziel, dem internen Client eine öffentliche IP-Adresse zur Verfügung zu stellen, die von beliebigen externen Peers erreicht werden kann.

Idee und Technik:

Eine typische TURN-Konfiguration ähnelt stark der STUN-Konfiguration. Ein TURN-Client, der sich hinter einem NAT in einem privaten Netzwerk befindet, kommuniziert mit einem externen sich im öffentlichen Netzwerk befindlichen TURN-Server. Dieser TURN-Server dient als Datenrelay, er leitet also Daten zwischen dem Client und externen Peers weiter. Die Kommunikation zwischen Client und Server besteht anfänglich aus einfachen Request- und Response-Nachrichten. Der Syntax (Paketaufbau) dieser Nachrichten entspricht im Wesentlichen dem von STUN. Ebenfalls werden auf allg. Funktionen (z.B. Discovery und Authentifizierung) des STUN-Protokolls zurückgegriffen. Lediglich einige Attribute und Nachrichtentypen wurden ergänzt. Da bspw. die Kommunikation nicht nur aus einfachen Requests und Responses besteht, sondern auch datenintensivere Datenströme wie RTP über den TURN-Server weitergeleitet werden müssen, gibt es zusätzliche Attribute (z.B. BANDWITH) die von dem TURN-Server für die Bereitstellung und Verteilung von Ressourcen (z.B. Puffer, Bandbreite) verarbeitet werden.

Die ersten Schritte einer erfolgreichen Kommunikation mit einem TURN-Server sind Discovery und Mechanismen zur Authentifizierung. Nach erfolgreichem Discovery, erlangt der Client Kenntnis darüber, wo sich ein potentieller TURN-Server befindet und kann diesen kontaktieren, um sich im zweiten Vorbereitungsschritt authentifizieren zu lassen.

Der Client ist nun befähigt dem TURN-Server ein TURN-Request zu senden. Der TURN-Server teil dem Client in seiner Antwort eine durch den Server vergebene "allocated transport adress" mit. Diese IP/PORT-Adresse ist öffentlich und dient dem Client als emulierte zukünftige Absenderkennung bei der Kommunikation mit externen Peers.

Das rechtsstehende Schaubild verdeutlicht die Umgebung und Funktionsweise des TURN-Servers. Wie schon erwähnt befindet sich dieser im öffentlichen Netzwerk und hat somit auch Kontakt mit externen Peers. Der interne TURN-Client befindet sich in einem privaten Netzwerk, welches über einen NAT mit dem öffentlichen Netzwerk verbunden ist. Das besondere am TURN-Server ist, dass dieser mit einem eingehenden TURN-Request ein sog. 5er Tupel generiert und speichert, das Verbindungsinformationen eines TURN-Clients oder dessen gewünschten Kommunikationspartnern enthält. So unterscheidet man internal 5-Tupel (TURN-clientseitig) und external 5-Tupel (Verbindungsdaten zu Peers im öffentlichen Netzwerk). Mit Hilfe dieser Tupel ist es dem TURN-Server möglich einen adress-restricted NAT zu emulieren. Der TURN-Server leitet demnach Pakete von einem externen Host B nur dann an einen bekannten internen TURN-Client A weiter, wenn zuvor ein Paket über den TURN-Server von A nach B geschickt worden ist. Im Detail läuft dies folgendermaßen ab:

Figure 12: TURN-Server

1. interner Client X sendet Send Request (enthält Zieladresse des gewünschten Kommunikationspartners Y und Daten Z) an TURN-Server

1.2 falls dieser Kontakt erstmalig ist, wird ein entsprechendes external-5-Tupel instanziiert

2. TURN-Server sendet Datenpaket (Inhalt: Z) an Y

3. X erhält Bestätigung (Send Response) vom TURN-Server. Y ist nun befähigt über die "allocated transport adress" mit X zu kommunizieren.

Jedes durch X instanziierte external-5-Tupel stellt einen externen Kommunikationspartner (Peer) dar, der berechtigt ist in dieser Form mit X über die "allocated transport adress" zu kommunizieren. Beim symmetrischen NAT sind nur Verbindungen mit einer IP und Port-Kombination zwischen X und Y möglich. In diesem Fall, kann nur ein einziger externer Host Y mit X über dieselbe IP/PORT-Kombination in Kontakt treten, die X beim erstmaligen Kontaktieren des Y verwendet hat.

Da diese Form der Kommunikation aufgrund der Kapselung der Datenpakete durch den TURN-Server in TURN-Messages nicht sehr effizient ist, bietet TURN die Möglichkeit mit Hilfe des Aufrufs "Set Active Destination" ein Ziel Y als aktiv zu setzen. Alle Pakete von Y werden fortan als ungekapselte reine Datenpakete an X weitergeleitet, was einen Performancevorteil mit sich bringt. Diese Option sollte dann eingesetzt werden, wenn davon auszugehen ist, dass eine länger andauernde Verbindung mit hohem Datenaufkommen (z.B. eine VoIP-Session) aufgebaut werden soll.

Hole punching

Hole punching deals with the problem that two clients have behind NAT routers, when they want to establish direct connections. Here, a client A cannot establish a connection with client B, because B is behind a NAT and vice versa. However, using a slightly modified STUN server enables both clients to obtain the public NAT endpoint addresses and the clients' private addresses. Now hole punching can be tried: both clients send messages to one another. Now, the following happens: client A's message is the first one. It will be rejected or dropped at B's NAT. Hence, A's NAT opened a public endpoint for A's connection. Now, B sends his message. This message will be forwarded by A's NAT. As a result, both NATs have open endpoints; direct communication is established. One special case is when A and B send their messages synchronously. Here, both messages will reach their targets. What about Symmetric NAT? That's the problem case hole punching cannot handle. We require public endpoint addresses obtained by STUN; so here is the failure. Symmetric NAT assigns different endpoints to different communication partners, so connection attempts from other servers than the STUN server automatically fail.

Figure 5: Hole punching

Since hole punching works for two clients behind different NATs, we now focus on a special case when two clients are behind the same NAT. Remember the restrictions to the STUN protocol: the clients may find out they are behind the same NAT, but they actually do not know whether they are in the same private network (--> cascaded NATs). Now the clients can try normal hole punching. If this works or not depends on the NAT's ability of doing so-called hairpin translation. Since clients from private network try to connect to NAT's public addresses, the NAT may deny this communication. In the best case, the NAT will translate the request internally by opening a direct route to the NATed client. Also possible were to send the request to the internet and receive it like a normal request, but this is inefficient. To achieve the best performance, clients may try to connect to the private address obtained from STUN server. If the clients are located in the same subnet, this will work. By the way, this is a possible method for traversing symmetric NATs.

Figure 6: Hairpin translation

Conclusion: hole punching is not a cure-all for traversing NATs, but works fine for Cone-type NATs. Symmetric NATs cannot be traversed by using these simple methods. Hairpin translation is a special case for hole punching and may allow direct communication for clients behind the same symmetric NAT. If all that does not work, the fallback strategy is to establish relayed connections using the TURN protocol.

NAT and Voice over IP

NAT-Traversal bei Voice over IP (VoIP) gilt als sehr problematisch und wird daher kurz für SIP/SDP-basiertes Voice over IP vorgestellt. Die Problematik für VoIP besteht darin, dass die NAT-Traversal-Technik die Latenzzeiten für Signalisierungs- und Sprachdaten nicht erhöhen sollte, da sonst die Qualität des Gespräches darunter leidet. Des Weiteren wird VoIP zunehmend als kommerzielles Produkt angeboten, womit NAT-Traversal für den Absatz eine wichtige Rolle spielt. Gerade im privaten Bereich werden zunehmend NAT-Router eingesetzt. Die NAT-Traversal-Technik darf somit kein technisches Verständnis voraussetzen. Auch die Trennung beim SIP basiertem Voice over IP zwischen dem Aufbau eines Gesprächs und dem Gespräch selber stellt hohe Anforderungen an die NAT-Traversal-Technik.

Allgemeine Ablauf bei VoIP

Ein VoIP-Client nutzt einem ihm vorher bekannten Server (SIP-Proxy des VoIP-Anbieters), um sich bei ihm zu registrieren. Diese Registration ist wichtig für die Signalisierung von eingehenden Anrufen. Bei einem Verbindungsaufbauwunsch sendet der Client eine entsprechende Nachricht an seinen SIP-Proxy, der diese dann entsprechend der VoIP-Zieladresse weiterleitet. Der Angerufene empfängt daraufhin den Verbindungsaufbauwunsch von seinem SIP-Proxy und hat die Möglichkeit das Gespräch anzunehmen. Bei Gesprächsannahme, wird die Annahme wieder über die SIP-Proxies dem Anrufer mitgeteilt und eine direkte Kommunikation zwischen den beiden Parteien beginnt.

Problematik anhand eines Beispiels

Um die Problematik bei VoIP mit NAT zu verdeutlichen, wird in einem Beispiel vereinfachend angenommen, dass sich nur ein Rechner hinter einem NAT-Router befindet. Bei diesem Rechner (Rechner A) besteht nun die Problematik, dass er sich mit einer öffentlichen IP-Adresse beim SIP-Proxy registrieren muss (Punkt 1 in Figure 7). Dem Rechner A ist aber ohne Hilfmittel nur seine lokale, private IP-Adresse bekannt und nicht die des NAT-Routers unter der er für den SIP-Proxy erreichbar wäre. Bei einem Anruf von A nach B mittels SIP-Nachricht, befindet sich im Payload der SIP-Nachricht das Session Description Protocol (SDP), in dem unter anderem die IP-Adresse von A zur direkten Kommunikation mit B verzeichnet ist (Punkt 2 in Figure 7). In der Regel wird zur direkten Kommunikation das Real Time Protocal (RTP) eingesetzt, das aber wiederrum einen extra Port zu Steuerung der Datenstroms benötigt. Die Schwierigkeit für A besteht nun darin, beim Verbindungsaufbau dem Rechner B eine IP-Adresse sowie zwei Portnummern mitzuteilen über die er zur direkten Kommunikation erreichbar ist (Punkt 2 in Figure 7). Dies bedeutet, dass der Rechner A sicherstellen muss, dass Datenpakete, die an diese Adresse geschickt werden, der NAT-Router an ihn weitergeleit. Bei Gesprächsannahme von B (Punkt 3 in Figure 7) schickt dieser nämlich sofort die Gesprächsannahme (SIP-Nachricht OK) und die Sprachdaten an A (Punkt 4 in Figure 7). Ein weiteres Problem besteht darin, dass das NAT-Binding zum SIP-Proxy, das bei der Registrierung von A entsteht, am NAT-Router nach einer gewissen Zeit auslaufen kann und der NAT-Router Datenpakete vom SIP-Proxy (z.B. ankommende Anrufe) nicht an A weiterleitet.

Figure 7: NAT und VoIP

Die Schwierigkeit für NAT-Traversal erhöht sich natürlich, wenn sich z.B. beide Gesprächspartner hinter einem oder sogar demselben NAT-Router befinden. Neben diesen Problemen besteht zusätzlich die Anforderung, dass die NAT-Traversal-Technik die Qualität des Gespräches nicht herabsetzt, also Signalisierungsdaten oder Sprachdaten nicht verzögert.

Aktuelle Lösung

Bekannte VoIP-Anbieter (z.B. Sipgate, 1und1, Nikotel, usw.) benutzen vor allem STUN für NAT-Traversal. Dazu stellen die Anbieter STUN-Server zur Verfügung (z.B. stun.1und1.de, stun.sipgate.net), die den VoIP-Clients bekannt sind. Die STUN-Server der Anbieter führen in der Regel keine Authentifizierung durch, so dass sie allgemein nutzbar sind. Sie werden vor allem dazu genutzt die öffentliche IP-Adresse des NAT-Routers herauszufinden (Punkt 1 in Figure 7) und zum Erzeugen von NAT-Bindings am NAT-Router, die dann je nach NAT-Typ zur direkten Kommunikation dienen sollen (Punkt 4 in Figure 7). Neben STUN werden meist ergänzend andere Techniken eingesetzt. Hierzu zählt vor allem keep-alive Nachrichten an den SIP-Proxy (Aufrechterhaltung des NAT-Bindings), SIP-Protokollerweiterungen für NAT (siehe NAT-friendly SIP, link) und UPnP (siehe oben). Der populäre Ansatz mittels STUN funktioniert je nach NAT-Typ und Konstellation sehr gut bis gar nicht. Auf den FAQ-Seiten der VoIP-Anbieter wird bei Problemen in der Regel auf Port-Forwarding verwiesen, was zu den oben genannten Nachteilen führen kann.

Lösungsansatz mit ICE

Das Interactive Connectivity Establishment (ICE) Protokoll soll SIP-basiertes VoIP entscheidend verbessern. Das Protokoll wird von der IETF entwickelt und bedient sich bekannter Protkolle wie STUN und TURN. Bei ICE wird angenommen, dass Rechner mehrere Verbindungsmöglichkeiten besitzen, also mehrere Schnittstellen zu verschiedenen Netzwerken. Unter dieser Annahme sammeln die VoIP-Clients vor einem Gespräch alle ihnen verfügbaren Adressen. Diese Adressen können z.B. private Netzwerkadressen sein, über STUN ermittelte öffentliche Adressen oder auch Adressen, die sie über ein TURN-Server erhalten haben. Die Sammlung der Adressen sollte möglichst vor einem Gespräch stattfinden, um die Gültigkeit dieser Adressen zu gewährleisten. Dies kann zum Beispiel bei einem Nachschlag im einem Telefonadressbuch oder beim Abheben des Telefonhörers geschehen. Nachdem der Client alle Adressen gesammelt hat, priorisiert er sie und schickt sie über seinen SIP-Proxy seinem Geprächspartner. Dieser verfährt genauso. Nachdem beide Parteien die Adressen des Geprächsparters erhalten haben, werden anhand der Priorisierungen Adresspaare gebildet und für diese Verbindungstests durchgeführt. Hierzu laufen auf beiden Rechern STUN-Server und -Clients. Jeder Gesrächspartner sendet direkt STUN-Nachrichten von seiner zu der fremden Adresse aus dem Adresspaar. Ein Adresspaar ist dann gültig, wenn ein STUN-Request beantwortet und ein STUN-Request empfangen wird. Bei diesen Verbindungstests können auch neue Adressen entdeckt werden, wenn zum Beispiel durch ein symmetrisches NAT ein neues NAT-Binding zum Gesprächspartner erzeugt wird. ICE ermöglicht es, diese neu entdeckten Adressen für die Sprachkommunikation zu nutzen. Die Verbindungstests finden statt während das Telefon beim dem Anrufenden klingelt, so dass bei der ersten Adresseübermittlung eine Adresse besonders gekennzeichnet bzw. am höchsten priorisiert wird, die dann benutzt wird, falls das Gespräch sofort zustande kommt. Die Clients haben auch die Möglickeit während den Verbindungstests aktualisierte Adresslisten mit einer neuen besonders gekennzeichneten Adresse über die SIP-Proxies zu senden.

Durch ICE wird es möglich symmetrisches NAT bei VoIP zu überwinden und bietet für viele Fälle ein besseres NAT-Traversal. Auch die gemeinsame Unterstützung des Protokolls von Microsoft und Cisco lässt vermuten, dass es in der Zukunft breite Anwendung findet.

Refereces

• Ford, Srisuresh, Kegel: Peer-to-Peer Communication Across Network Address Translators (link)
• Rosenberg, Huitema, Mahy: Traversal using relay NAT (TURN), Internet Draft (link)
• Rosenberg, Weinberger, Huitema, Mahy: STUN – simple traversal of user datagram protocol (UDP) through network address translators (NATs), March 2003, RFC3489 (link)
• Rosenberg: Interactive Connection Establishment (ICE), Internet Draft (link)
• Schulzrinne: diverse documents concerning NAT and SIP, e.g. NAT Types.pdf (NAT and SIP)
• STUN Client und Server (link)