Die IP-Adresse ist das allgemeingültige Konzept, auf dem die Kommunikation im Internet basiert. Sie ermöglicht es, den Eigentümer oder den Standort einer Entität im Netz zu identifizieren und zu lokalisieren. Im Prinzip sind alle IP-Adressen gleichrangig, aber einige bedürfen eines besonderen Status. Oft werden etwa aus Sicherheitsgründen die Identitäten einzelner Computer oder Systeme im Netzwerk vor Außenstehenden verborgen. Dabei gilt es, sowohl die IP-Adressen als auch die logischen Namen der Rechner vor allen Zugriffen außerhalb der eigenen Organisation zu schützen.

Viele Netzwerkumgebungen wurden deshalb in den vergangenen Jahren auf Basis eines privaten IP-Adressraums eingerichtet und es kamen hierfür IP-Adressen zum Einsatz, die im öffentlichen Internet nicht funktionieren. Diese speziellen Adressräume haben die Router nicht ins öffentliche Internet übermittelt. Sie werden einfach als nicht routingfähig gekennzeichnet und verworfen.

Wollen jedoch diese privaten IP-Adressen ins Internet kommunizieren, müssen die internen IP-Adressen geändert und in externe, gültige IP-Adressen übersetzt werden, bevor diese das eigene Netzwerk verlassen. Diese Technik ist als Network Address Translation (NAT) bekannt und wird im RFC 8656 genauer spezifiziert.

Ein Host, der sich hinter einem Network Address Translator befindet, möchte Pakete mit anderen Hosts austauschen, von denen sich einige ebenfalls hinter NATs befinden können. Zu diesem Zweck können die beteiligten Hosts eine Technik verwenden, die als "Hole Punching" (siehe RFC 5128) bekannt ist. Es geht darum, einen direkten Kommunikationspfad zu finden, das heißt einen Pfad, der von einem Host zum anderen durch zwischengeschaltete NATs und Router führt, aber keine Relays durchläuft.

Hole-Punching-Techniken schlagen fehl, wenn sich beide Hosts hinter NATs befinden, die sich nicht korrekt verhalten. Wenn beispielsweise beide Hosts hinter NATs lokalisiert sind, die ein "adressabhängiges Mapping" oder "adress- und portabhängiges Mapping" aufweisen, versagt Hole-Punching im Allgemeinen.

Ist kein direkter Kommunikationspfad auffindbar, sind die Dienste eines Zwischenhosts gefragt, der als Relay für die Pakete fungiert. Dieser Relay-Server befindet sich in der Regel im öffentlichen Internet und leitet Pakete zwischen zwei Hosts weiter, die beide hinter NATs stehen.

In vielen Unternehmensnetzwerken sind direkte UDP-Übertragungen zwischen Clients im internen Netzwerk und externen IP-Adressen nicht erlaubt. Um in einer solchen Situation die Nutzung von UDP für Mediensitzungen zu ermöglichen und zu vermeiden, dass diese über TCP laufen, lässt sich eine Unternehmensfirewall so konfigurieren: Sie muss UDP-Verkehr zulassen, der über einen Relay-Server der eigenen Organisation weitergeleitet wird. WebRTC erfordert beispielsweise eine Unterstützung für dieses Szenario.

In diesem Fall findet der TURN-Mechanismus (Traversal Using Relays around NAT) Verwendung, der es einem Rechner hinter einem NAT, dem TURN-Client, erlaubt, einen anderen Rechner, den TURN-Server, zu bitten, als Relay zu fungieren. Der Client kann veranlassen, dass der Server Pakete zu und von bestimmten anderen Hosts, den Peers, weiterleitet, und der Client kann Aspekte der Weiterleitung kontrollieren. Dazu erhält der Client eine IP-Adresse und einen Port des Servers, die sogenannte Relayed Transport Address. Sendet ein Peer ein Paket an die Adresse, leitet der Server die Transportprotokolldaten des Pakets an den Client weiter.

Die Daten sind in einen Nachrichtenkopf eingekapselt, der es dem Client ermöglicht, den Peer zu erkennen, von dem die Transportprotokolldaten vom Server weitergeleitet wurden. Empfängt der Server ein ICMP-Fehlerpaket, übermittelt er bestimmte Header-Felder der Schichten 3 und 4 aus dem ICMP-Header an den Client. Wenn der Client eine Nachricht an den Server sendet, identifiziert der Server die Gegenstelle anhand des Nachrichtenkopfes und leitet die Nachrichtendaten an die gewünschte Gegenstelle weiter.

Ein Client, der TURN verwendet, muss über eine Möglichkeit verfügen, seinen Peers die weitergegebene Transportadresse mitzuteilen und die IP-Adresse sowie den Port jedes Peers zu erfahren (genauer gesagt die Server-reflexive Transportadresse jedes Peers). Wie dies geschieht, liegt nicht im Rahmen des TURN-Protokolls. Eine Möglichkeit ist, dass der Client und die Peers E-Mail-Nachrichten austauschen. Eine andere Option besteht darin, dass der Client und seine Peers ein spezielles Einführungs- oder Rendezvousprotokoll nutzen.

In einer typischen Konfiguration ist ein TURN-Client mit einem privaten Netz nach RFC 1918 und über ein oder mehrere NATs mit dem öffentlichen Internet verbunden. Im öffentlichen Internet befindet sich ein TURN-Server. Anderswo im Internet gibt es einen oder mehrere Peers, mit denen der TURN-Client kommunizieren möchte. Diese Peers können sich hinter einem oder mehreren NATs befinden oder auch nicht. Der Client benutzt den Server als Relay, um Pakete an diese Peers zu senden und um Pakete von diesen Peers zu empfangen.

In Bild 1 sind TURN-Client und -Server durch ein NAT getrennt, wobei sich der Client auf der privaten und der Server auf der öffentlichen Seite des NATs befindet. Der Client kommuniziert mit dem Server über eine Kombination von Merkmalen (IP-Adresse, Port), die als "Host-Transport-Adresse" des Clients bezeichnet wird. Die Kombination aus IP-Adresse und Port heißt "Transportadresse".

Der Client sendet TURN-Nachrichten von seiner Host-Transportadresse an eine Transportadresse auf dem TURN-Server, die mit "TURN-Server-Transportadresse" benannt wird. Der Client lernt die Transportadresse des TURN-Servers auf nicht spezifizierte Weise (zum Beispiel durch Konfiguration), und diese Adresse wird typischerweise von vielen Clients gleichzeitig verwendet.

Da sich der Client hinter einem NAT befindet, sieht der Server Pakete vom Client als von einer Transportadresse auf dem NAT selbst kommend. Diese Adresse wird als "Server-reflexive Transportadresse" des Clients bezeichnet; Pakete, die vom Server an diese Adresse des Clients gelangen, werden vom NAT an die Host-Transportadresse des Clients weitergeleitet.

Der Client setzt auf TURN-Befehle, um eine sogenannte Allokation auf dem Server zu erstellen und diese zu manipulieren. Eine Allokation ist eine Datenstruktur auf dem Server. Diese enthält unter anderem die weitergegebene Transportadresse für die Zuweisung. Die Relayed-Transport-Adresse ist die Transportadresse auf dem Server, die Peers verwenden können, damit der Server Daten an den Client weiterleitet. Eine Zuweisung lässt sich durch ihre Relayed-Transport-Adresse eindeutig identifizieren.

Sobald eine Zuweisung erstellt ist, kann der Client Anwendungsdaten an den Server senden, zusammen mit der Angabe, bei welchem Peer die Daten landen sollen, und der Server leitet diese Daten an den gewünschten Peer weiter. Der Client schickt die Anwendungsdaten in einer TURN-Nachricht an den Server. Auf dem Server werden die Daten aus der TURN-Nachricht extrahiert und in einem UDP-Datagramm an den Peer gesendet.

In umgekehrter Richtung kann ein Peer Anwendungsdaten in einem UDP-Datagramm an die weitergeleitete Transportadresse für die Zuweisung senden. Der Server kapselt diese Daten dann in eine TURN-Nachricht ein und schickt sie zusammen mit einer Angabe, welcher Peer die Daten gesendet hat, an den Client. Da die TURN-Nachricht immer eine Angabe darüber enthält, mit welchem Peer der Client spricht, kann der Client eine einzige Zuweisung für die Kommunikation mit mehreren Peers verwenden.

Befindet sich der Peer hinter einem NAT, muss der Client den Peer über seine Server-reflexive Transportadresse und nicht über seine Host-Transportadresse identifizieren. Um etwa im Beispiel aus Bild 1 Anwendungsdaten an Peer A zu senden, muss der Client 192.0.2.150: 32102 (die Server-reflexive Transportadresse von Peer A) und nicht 203.0.113. 2:49582 (die Host-Transportadresse von Peer A) angeben.

Jede Zuweisung auf dem Server gehört zu einem einzigen Client und hat entweder eine oder zwei Relayed-Transport-Adressen, die nur von dieser Zuweisung verwendet werden. Wenn also ein Paket an einer weitergeleiteten Transportadresse auf dem Server ankommt, weiß der Server, für welchen Client die Daten bestimmt sind. Der Client kann gleichzeitig auch mehrere Zuweisungen auf einem Server haben.

TURN verwendet immer UDP zwischen dem Server und der Gegenstelle. Die Spezifikation erlaubt jedoch die Nutzung von UDP, TCP, Transport Layer Security (TLS) über TCP oder Datagram Transport Layer Security (DTLS) over UDP zur Übertragung der TURN-Nachrichten zwischen dem Client und dem Server.

Kommen TCP oder TLS-over-TCP zwischen dem Client und dem Server zum Einsatz, wechselt der Server zwischen diesen Transportarten. Da diese Version von TURN nur UDP zwischen dem Server und der Gegenstelle unterstützt, wird erwartet, dass die meisten Clients es vorziehen, auch zwischen Client und Server auf UDP zurückzugreifen.

TURN unterstützt den TCP-Transport zwischen dem Client und dem Server, weil einige Firewalls so konfiguriert sind, dass sie UDP vollständig blockieren. Diese Firewalls blockieren UDP, aber nicht TCP, zum Teil weil TCP Eigenschaften hat, die die Absicht der von der Firewall geschützten Knoten für die Firewall offensichtlicher machen. So verfügt TCP beispielsweise über einen Drei-Wege-Handshake, der klarer macht, dass der geschützte Knoten die betreffende Verbindung tatsächlich aufbauen möchte, während die Firewall bei UDP bestenfalls erraten kann, welche Datenströme mithilfe von Filterregeln erwünscht sind. Außerdem verfügt TCP über einen expliziten Verbindungsabbau, während die Firewall bei UDP mit Unterstützung von Zeitgebern erraten muss, wann der Datenfluss beendet ist.

TURN unterstützt TLS-over-TCP-Transport und DTLS-over-UDP-Transport zwischen dem Client und dem Server, weil DTLS zusätzliche Sicherheitseigenschaften aufweist, die die Standard-Digest-Authentifizierung von TURN nicht bietet.

Um eine Zuweisung auf dem Server zu erstellen, bedient sich der Client einer "Allocate"-Transaktion. Er sendet dazu eine Allocate-Anfrage an den Server, und dieser antwortet mit einer Allocate-Erfolgsmeldung, die die zugewiesene Relayed-Transportadresse enthält. Der Client kann Attribute in die Allocate-Anforderung aufnehmen, die die Art der gewünschten Zuweisung beschreiben, etwa die Lebensdauer der Zuweisung. Da die Weiterleitung von Daten Auswirkungen auf die Sicherheit hat, verlangt der Server, dass sich der Client authentifiziert – typischerweise unter Verwendung des STUN-Mechanismus für langfristige Berechtigungsnachweise oder der STUN-Erweiterung für die Autorisierung von Drittanbietern, um zu zeigen, dass er berechtigt ist, den Server zu benutzen.

Sobald eine Relayed-Transport-Adresse zugewiesen ist, muss ein Client die Zuweisung aufrechterhalten. Zu diesem Zweck sendet der Client in regelmäßigen Abständen eine Auffrischungsanforderung an den Server. TURN nutzt absichtlich eine andere Methode (Refresh statt Allocate) für ein erneutes Anstoßen des gesamten Prozesses, um sicherzustellen, dass der Client informiert wird, wenn die Zuweisung aus irgendeinem Grund verschwindet.

Die Häufigkeit der Auffrischungstransaktion wird durch die Lebensdauer der Zuweisung bestimmt. Die Standardlebensdauer einer Zuteilung beträgt zehn Minuten. Dieser Wert wurde so gewählt, dass die Auffrischung in der Regel keine Belastung für den Client darstellt, wenn die Zuteilung abläuft und der Client unerwartet rechtzeitig die Verbindung beendet hat. Der Client kann jedoch in der Allocate-Anforderung eine längere Lebensdauer anfordern und seine Anforderung in einer Refresh-Anforderung ändern, und der Server gibt in der Antwort immer die aktuelle Lebensdauer an. Der Client muss eine neue Refresh-Transaktion innerhalb von "Lifetime"-Sekunden nach der vorherigen Allocate- oder Refresh-Transaktion durchführen. Sobald ein Client eine Zuweisung nicht mehr verwenden möchte, sollte er die Zuweisung mit einer Refresh-Anfrage mit einer angeforderten Lebensdauer von null löschen.

Sowohl der Server als auch der Client behalten einen Wert im Auge, der als "5-Tupel" bezeichnet wird. Beim Client besteht das 5-Tupel aus der Host-Transportadresse des Clients, der Transportadresse des Servers und dem vom Client für die Kommunikation mit dem Server genutzten Transportprotokoll. Auf dem Server ist der Wert des 5er-Tupels derselbe, nur dass die Host-Transportadresse des Clients durch die Server-Reflexionsadresse des Clients ersetzt wird, da dies die Adresse des Clients ist, die der Server sieht.

Client und Server merken sich das in der Allocate-Anfrage enthaltene 5er-Tupel. Nachfolgende Nachrichten zwischen dem Client und dem Server setzen auf das gleiche 5-Tupel. Auf diese Weise wissen der Client und der Server, auf welche Zuweisung sie sich beziehen. Wenn der Client eine zweite Relayed-Transport-Adresse zuweisen möchte, muss er auch eine zweite Zuweisung unter Verwendung eines anderen 5-Tupels erstellen, beispielsweise durch die Nutzung einer anderen Client-Host-Adresse oder eines anderen Ports.

In Bild 2 sendet der Client eine Allocate-Anforderung an den Server mit ungültigen oder fehlenden Anmeldeinformationen. Da der Server verlangt, dass alle Anfragen mithilfe des STUN-Mechanismus für langfristige Anmeldeinformationen authentifiziert werden, weist der Server die Anfrage mit einem 401-Unauthorized-Fehlercode zurück. Der Client versucht es dann erneut, jedoch mit Anmeldeinformationen. Diesmal akzeptiert der Server die Allocate-Anfrage und gibt eine Allocate-Erfolgsantwort zurück, die unter anderem die zugewiesene Transportadresse enthält. Einige Zeit später aktualisiert der Client die Zuweisung und sendet eine Refresh-Anfrage an den Server. Die Auffrischung wird akzeptiert, und der Server antwortet mit einer "Refresh Success Response".

Um die Bedenken von IT-Administratoren in Organisationen zu zerstreuen, dass TURN dazu verwendet werden könnte, die Firewall-Sicherheit des Unternehmens zu umgehen, enthält TURN das Konzept der Berechtigungen. Diese imitieren den adressbeschränkten Filtermechanismus von NATs, die RFC 4787 entsprechen.

Eine Zuweisung kann mehre Berechtigungen enthalten, die jeweils aus einer IP-Adresse und einer Lebensdauer bestehen. Empfängt der Server ein UDP-Datagramm an der weitergeleiteten Transportadresse der Zuweisung, prüft dieser zunächst die Liste der Berechtigungen. Stimmt die Quell-IP-Adresse des Datagramms mit einer Berechtigung überein, werden die Anwendungsdaten an den Client weitergeleitet. Anderenfalls wird das UDP-Datagramm stillschweigend verworfen. Eine Berechtigung läuft nach fünf Minuten ab, wenn sie nicht erneuert wird, und es gibt keine Möglichkeit, eine Berechtigung explizit zu löschen.

Der Client kann eine Berechtigung entweder mit einer CreatePermission-Anfrage oder einer ChannelBind-Anfrage installieren oder aktualisieren. Mit der CreatePermission-Anforderung lassen sich mehrere Berechtigungen mit einer einzigen Anforderung installieren oder aktualisieren. Aus Sicherheitsgründen können Berechtigungen nur durch Transaktionen installiert oder aktualisiert werden, die eine Authentifizierung beinhalten.

Bei einigen Anwendungen, beispielsweise bei Voice-over-IP, können die 36 Bytes Overhead, die eine Sende- oder Datenanzeige zu den Anwendungsdaten hinzufügt, die benötigte Bandbreite zwischen dem Client und dem Server erheblich erhöhen. Um hier Abhilfe zu schaffen, bietet TURN eine zweite Möglichkeit für den Client und den Server, Daten mit einem bestimmten Peer zu verknüpfen.

Diese Methode setzt auf ein alternatives Paketformat, das auch als ChannelData-Nachricht bekannt ist. Diese nutzt nicht den STUN-Header, der von anderen TURN-Nachrichten verwendet wird, sondern hat stattdessen einen 4-Byte-Header, der eine Kanalnummer enthält. Jede Kanalnummer ist an einen bestimmten Peer gebunden. Sie dient also als Kurzform für die Host-Transportadresse des Peers.

Um einen Kanal an einen Peer zu binden, sendet der Client eine ChannelBind-Anfrage an den Server und gibt eine ungebundene Kanalnummer und die Transportadresse des Peers an. Sobald der Kanal gebunden ist, kann der Client eine ChannelData-Nachricht einsetzen, um dem Server Daten zu senden, die für den Peer bestimmt sind. Ebenso kann der Server mit einer ChannelData-Nachricht Daten von diesem Peer an den Client weiterleiten.

Kanalbindungen gelten für zehn Minuten, sofern sie nicht erneuert werden; diese Lebensdauer ist so gewählt, dass sie länger ist als die Lebensdauer der Berechtigung. Kanalbindungen lassen sich auffrischen, indem eine weitere ChannelBind-Anforderung gesendet wird, die den Kanal erneut an den Peer bindet. Wie bei Berechtigungen, aber anders als bei Zuweisungen, gibt es keine Möglichkeit, eine Kanalbindung explizit zu löschen; der Client muss warten, bis sie abgelaufen ist.

Der Client aus Bild 3 hat bereits eine Zuweisung erstellt und möchte nun einen Kanal an Peer A binden. Dazu sendet er eine ChannelBind-Anfrage an den Server und gibt dabei die Transportadresse von Peer A und eine Kanalnummer (0x4001) an.

Danach kann er Anwendungsdaten, die in ChannelData-Nachrichten gekapselt sind, an Peer A senden. Dies wird als "(0x4001) data" angezeigt, wobei 0x4001 die Kanalnummer ist. Wenn die ChannelData-Nachricht beim Server eintrifft, überträgt der Server die Daten in ein UDP-Datagramm und sendet es an Peer A (den Peer, der an Kanalnummer 0x4001 gebunden ist).

In umgekehrter Richtung, wenn Peer A ein UDP-Datagramm an die Relayed-Transport-Adresse sendet, kommt dieses UDP-Datagramm beim Server an der Relayed-Transport-Adresse an, die der Zuweisung zugeordnet ist. Da das UDP-Datagramm von Peer A empfangen wurde, dem eine Kanalnummer zugewiesen ist, kapselt der Server die Daten in eine ChannelData-Nachricht ein, wenn er sie an den Client sendet.

Sobald ein Kanal gebunden ist, steht es dem Client frei, ChannelData-Nachrichten und Sendeanzeigen miteinander zu mischen. In Bild 3 beschließt der Client dann später, eine "Send-Indication" anstelle einer ChannelData-Nachricht einzusetzen, um zusätzliche Daten an Peer A zu senden.

Der Client könnte dies beispielsweise tun, um das Attribut DONT-FRAGMENT zu verwenden. Sobald jedoch ein Kanal gebunden ist, wird der Server immer auf eine ChannelData-Nachricht zurückgreifen, wie im Ablaufdiagramm gezeigt.

Mit STUN lassen sich auch die folgenden IP/UDP-Paketübersetzungen vornehmen:

- Übersetzung IPv4-zu-IPv6

- Übersetzung IPv6-zu-IPv6

- Übersetzung IPv6-zu-IPv4

- Relay UDP-zu-UDP

- Relay TCP-zu-UDP

- Relay UDP-zu-TCP

Die Übersetzungen sind in TURN so gestaltet, dass ein TURN-Server als eine Anwendung implementiert werden kann, die im Userspace unter allgemein verfügbaren Betriebssystemen läuft und keine besonderen Privilegien benötigt.

Ein wichtiger Sicherheitsaspekt von TURN ist, dass es den Schutz durch Firewalls, die zwischen einem Client und einem TURN-Server stehen, nicht schwächen darf. Es ist davon auszugehen, dass TURN-Server oft im öffentlichen Internet untergebracht sind und dass sich die Clients in Unternehmensnetzwerken mit Firmen-Firewalls befinden. Sollten TURN-Server eine Hintertür bieten, um in das Unternehmen zu gelangen, muss TURN von diesen Firewalls blockiert werden.

TURN-Server emulieren daher das Verhalten von NAT-Geräten, die adressabhängige Filterung gemäß RFC 4787 implementieren, eine Eigenschaft, die auch in vielen Firewalls zu finden ist. Wenn ein NAT oder eine Firewall dieses Verhalten integriert, dürfen Pakete von einer externen IP-Adresse nur dann bei einer internen IP-Adresse und einem Port landen, wenn die interne IP-Adresse und der Port kürzlich ein Paket an diese externe IP-Adresse gesendet haben.

Ein Angreifer kann dadurch kein Paket an einen TURN-Server senden und erwarten, dass es an den Client weitergeleitet wird, es sei denn, der Client hat zuerst versucht, den Angreifer zu kontaktieren. Firewalls lassen sich auch mit adress- und portabhängiger Filterung konfigurieren, oder sie sind so einstellbar, dass sie den eingehenden Datenverkehr vollständig verbieten.

TURN ist die verbleibende Möglichkeit, wenn die Kommunikation zwischen Rechnern über NAT- oder Firewall-Grenzen sonst nicht mehr möglich ist. Es fungiert für die am Kommunikationsprozess beteiligten Rechner als Relay-Server. TURN bietet somit einen letzten Notnagel, wenn ein Datenaustausch per UDP oder TCP über komplexe NAT-Strukturen erforderlich ist.