2. Funktionsübersicht
Dieser Abschnitt gibt einen Überblick über die Funktionsweise von TURN. Das Material in diesem Abschnitt ist nicht normativ.
In einer typischen Konfiguration ist ein TURN-Client mit einem privaten Netzwerk [RFC1918] verbunden und über einen oder mehrere NATs mit dem öffentlichen Internet verbunden. Im öffentlichen Internet befindet sich ein TURN-Server. Irgendwo anders im Internet befinden sich ein 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 verwendet den Server als Relay, um Pakete an diese Peers zu senden und Pakete von diesen Peers zu empfangen.
Peer A
Server-Reflexive +---------+
Transport Address | |
192.0.2.150:32102 | |
| /| |
TURN | / ^| Peer A |
Client's Server | / || |
Host Transport Transport | // || |
Address Address | // |+---------+
10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A
| | ||N| / Host Transport
| +-+ | ||A|/ Address
| | | | v|T| 192.168.100.2:49582
| | | | /+-+
+---------+| | | |+---------+ / +---------+
| || |N| || | // | |
| TURN |v | | v| TURN |/ | |
| Client |----|A|----------| Server |------------------| Peer B |
| | | |^ | |^ ^| |
| | |T|| | || || |
+---------+ | || +---------+| |+---------+
| || | |
| || | |
+-+| | |
| | |
| | |
Client's | Peer B
Server-Reflexive Relayed Transport
Transport Address Transport Address Address
192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191
Abbildung 1
Abbildung 1 zeigt eine typische Bereitstellung. In dieser Abbildung sind der TURN-Client und der TURN-Server durch einen NAT getrennt, wobei sich der Client auf der privaten Seite und der Server auf der öffentlichen Seite des NAT befindet. Es wird angenommen, dass dieser NAT ein „schlechter" NAT ist; er kann beispielsweise eine Mapping-Eigenschaft „Address-and-Port-Dependent Mapping" haben (siehe [RFC4787]).
Der Client kommuniziert mit dem Server von einer Kombination aus (IP-Adresse, Port), die als Host-Transportadresse des Clients (HOST TRANSPORT ADDRESS) bezeichnet wird. (Eine Kombination aus IP-Adresse und Port wird als Transportadresse (TRANSPORT ADDRESS) bezeichnet.)
Der Client sendet TURN-Nachrichten von seiner Host-Transportadresse an eine Transportadresse auf dem TURN-Server, die als TURN-Server-Transportadresse (TURN SERVER TRANSPORT ADDRESS) bekannt ist. Der Client erfährt die TURN-Server-Transportadresse auf nicht spezifizierte Weise (z. B. durch Konfiguration), und diese Adresse wird normalerweise von vielen Clients gleichzeitig verwendet.
Da sich der Client hinter einem NAT befindet, sieht der Server Pakete vom Client als von einer Transportadresse am NAT selbst kommend. Diese Adresse wird als serverreflexive Transportadresse des Clients (SERVER-REFLEXIVE TRANSPORT ADDRESS) bezeichnet, und vom Server an die serverreflexive Transportadresse des Clients gesendete Pakete werden vom NAT an die Host-Transportadresse des Clients weitergeleitet.
Der Client verwendet TURN-Befehle, um eine Allokation (ALLOCATION) auf dem Server zu erstellen und zu manipulieren. Eine Allokation ist eine Datenstruktur auf dem Server. Diese Datenstruktur enthält unter anderem die weitergeleitete Transportadresse für die Allokation. Die weitergeleitete Transportadresse ist die Transportadresse auf dem Server, die Peers verwenden können, damit der Server Daten an den Client weiterleitet. Eine Allokation wird durch ihre weitergeleitete Transportadresse eindeutig identifiziert.
Sobald eine Allokation erstellt ist, kann der Client Anwendungsdaten zusammen mit einer Angabe, an welchen Peer die Daten gesendet werden sollen, an den Server senden, und der Server leitet diese Daten an den entsprechenden Peer weiter. Der Client sendet die Anwendungsdaten innerhalb einer TURN-Nachricht an den Server; am 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 Allokation senden; der Server kapselt diese Daten dann in einer TURN-Nachricht und sendet sie an den Client, zusammen mit einer Angabe, welcher Peer die Daten gesendet hat. Da die TURN-Nachricht immer eine Angabe enthält, mit welchem Peer der Client kommuniziert, kann der Client eine einzelne Allokation verwenden, um mit mehreren Peers zu kommunizieren.
Wenn sich der Peer hinter einem NAT befindet, muss der Client den Peer anhand seiner serverreflexiven Transportadresse und nicht anhand seiner Host-Transportadresse identifizieren. Um beispielsweise Anwendungsdaten an Peer A im obigen Beispiel zu senden, muss der Client 192.0.2.150:32102 (die serverreflexive Transportadresse von Peer A) anstelle von 192.168.100.2:49582 (die Host-Transportadresse von Peer A) angeben.
Jede Allokation auf dem Server gehört zu einem einzelnen Client und hat genau eine weitergeleitete Transportadresse, die nur von dieser Allokation verwendet wird. Wenn ein Paket an einer weitergeleiteten Transportadresse auf dem Server ankommt, weiß der Server daher, für welchen Client die Daten bestimmt sind.
Ein Client kann gleichzeitig mehrere Allokationen auf einem Server haben.
2.1. Transportprotokolle
Wie in dieser Spezifikation definiert, verwendet TURN immer UDP zwischen dem Server und dem Peer. Diese Spezifikation erlaubt jedoch die Verwendung von UDP, TCP oder Transport Layer Security (TLS) über TCP zum Übertragen der TURN-Nachrichten zwischen dem Client und dem Server.
+----------------------------+---------------------+
| TURN-Client zu TURN-Server | TURN-Server zu Peer |
+----------------------------+---------------------+
| UDP | UDP |
| TCP | UDP |
| TLS über TCP | UDP |
+----------------------------+---------------------+
Wenn TCP oder TLS-über-TCP zwischen dem Client und dem Server verwendet wird, übersetzt der Server beim Weiterleiten von Daten an oder von dem Peer zwischen diesen Transporten und dem UDP-Transport.
Da diese Version von TURN nur UDP zwischen dem Server und dem Peer unterstützt, wird erwartet, dass die meisten Clients auch UDP zwischen dem Client und dem Server bevorzugen. Einige Leser fragen sich möglicherweise: Warum TCP und TLS-über-TCP unterstützen?
TURN unterstützt TCP-Transport zwischen dem Client und dem Server, da einige Firewalls so konfiguriert sind, dass sie UDP vollständig blockieren. Diese Firewalls blockieren UDP, aber nicht TCP, teilweise weil TCP Eigenschaften hat, die die Absicht der Knoten hinter der Firewall für die Firewall deutlicher machen. TCP hat beispielsweise einen dreifachen Handshake, der deutlicher macht, dass der geschützte Knoten diese bestimmte Verbindung wirklich herstellen möchte, während die Firewall bei UDP höchstens Filterregeln verwenden kann, um zu erraten, welche Flüsse gewünscht werden. Außerdem hat TCP einen expliziten Verbindungsabbau, während die Firewall bei UDP Timer verwenden muss, um zu erraten, wann ein Fluss beendet ist.
TURN unterstützt TLS-über-TCP-Transport zwischen dem Client und dem Server, da TLS zusätzliche Sicherheitseigenschaften bietet, die die Standard-Digest-Authentifizierung von TURN nicht bietet, und einige Clients möchten diese Eigenschaften möglicherweise nutzen. Insbesondere bietet TLS eine Möglichkeit für den Client zu überprüfen, dass er mit dem richtigen Server kommuniziert, und bietet Vertraulichkeit für TURN-Steuernachrichten. TURN erfordert nicht die Verwendung von TLS, da der Overhead der Verwendung von TLS höher ist als der der Digest-Authentifizierung, und beispielsweise kann die Verwendung von TLS bedeuten, dass die meisten Anwendungsdaten doppelt verschlüsselt werden (einmal durch TLS und einmal, um sicherzustellen, dass sie in den UDP-Datagrammen verschlüsselt bleiben).
Erweiterungen zu TURN sind geplant, um Unterstützung für TCP zwischen dem Server und dem Peer hinzuzufügen [TURN-TCP]. Daher werden Allokationen, die UDP zwischen dem Server und dem Peer verwenden, UDP-Allokationen (UDP ALLOCATIONS) genannt, während Allokationen, die TCP zwischen dem Server und dem Peer verwenden, TCP-Allokationen (TCP ALLOCATIONS) genannt werden. Diese Spezifikation beschreibt nur UDP-Allokationen.
Wie in dieser Spezifikation definiert, unterstützt TURN nur IPv4. Alle IP-Adressen in dieser Spezifikation müssen IPv4-Adressen sein. Erweiterungen zu TURN sind geplant, um Unterstützung für IPv6 und für Weiterleitung zwischen IPv4 und IPv6 hinzuzufügen [TURN-IPv6].
In einigen Anwendungen von TURN kann der Client möglicherweise andere Pakete als TURN-Pakete auf der Host-Transportadresse senden und empfangen, die er zur Kommunikation mit dem Server verwendet. Dies tritt beispielsweise auf, wenn TURN mit ICE verwendet wird. In diesen Fällen kann der Client TURN-Pakete von anderen Paketen unterscheiden, indem er die Quelladresse ankommender Pakete untersucht: Pakete vom TURN-Server sind TURN-Pakete.
2.2. Allokationen
Um eine Allokation auf dem Server zu erstellen, verwendet der Client eine Allocate-Transaktion. Der Client sendet eine Allocate-Anfrage an den Server, und der Server antwortet mit einer Allocate-Erfolgsantwort, die die weitergeleitete Transportadresse der Allokation enthält. Der Client kann Attribute in die Allocate-Anfrage aufnehmen, die den gewünschten Typ der Allokation beschreiben (z. B. die Lebensdauer der Allokation). Da das Weiterleiten von Daten Sicherheitsauswirkungen hat, erfordert der Server, dass der Client sich authentifiziert und dass der Client Authentifizierung mit seiner Allocate-Anfrage verwendet, typischerweise unter Verwendung des Langzeit-Anmeldeinformationsmechanismus von STUN, um zu beweisen, dass er berechtigt ist, den Server zu verwenden.
Sobald eine weitergeleitete Transportadresse zugewiesen ist, muss ein Client die Allokation am Leben erhalten. Dazu sendet der Client regelmäßig eine Refresh-Anfrage an den Server. TURN verwendet absichtlich eine andere Methode (Refresh statt Allocate) für Aktualisierungen, um sicherzustellen, dass der Client informiert wird, wenn die Allokation aus irgendeinem Grund verschwindet.
Die Häufigkeit der Refresh-Transaktion wird durch die Lebensdauer der Allokation bestimmt. Die Standardlebensdauer einer Allokation beträgt 10 Minuten - dieser Wert wurde so gewählt, dass die Aktualisierung normalerweise keine Belastung für den Client darstellt, während er kurz genug ist, dass ein nicht ordnungsgemäßer Client-Ausstieg die Allokation rechtzeitig ablaufen lässt. Der Client kann jedoch in der Allocate-Anfrage eine längere Lebensdauer anfordern und seine Anfrage in einer Refresh-Anfrage ändern, und der Server gibt immer die tatsächliche Lebensdauer in seiner Antwort an. Der Client muss innerhalb der „Lebensdauer"-Sekunden der vorherigen Allocate- oder Refresh-Transaktion eine neue Refresh-Transaktion ausgeben. Sobald der Client die Allokation nicht mehr verwenden möchte, sollte er die Allokation mit einer Refresh-Anfrage mit einer angeforderten Lebensdauer von Null löschen.
Sowohl der Server als auch der Client verfolgen einen Wert namens 5-TUPLE. Beim Client besteht das 5-Tupel aus der Host-Transportadresse des Clients, der Server-Transportadresse und dem Transportprotokoll, das der Client zur Kommunikation mit dem Server verwendet. Beim Server ist der Wert des 5-Tupels derselbe, außer dass die Host-Transportadresse des Clients durch die serverreflexive Adresse des Clients ersetzt wird, da dies die Adresse ist, die der Server als vom Client verwendet sieht.
Sowohl der Client als auch der Server merken sich das in der Allocate-Anfrage verwendete 5-Tupel. Nachfolgende Nachrichten zwischen dem Client und dem Server verwenden dasselbe 5-Tupel. Auf diese Weise wissen der Client und der Server, auf welche Allokation verwiesen wird. Wenn der Client eine zweite weitergeleitete Transportadresse zuweisen möchte, muss er eine zweite Allokation mit einem anderen 5-Tupel erstellen (z. B. durch Verwendung einer anderen Client-Host-Adresse oder eines anderen Ports).
Hinweis: Obwohl der in diesem Dokument verwendete Begriff sich auf ein 5-Tupel bezieht, kann der TURN-Server jeden beliebigen Bezeichner speichern, solange er dasselbe Ergebnis liefert. Insbesondere kann eine Implementierung anstelle eines 5-Tupels einen Dateideskriptor verwenden, um eine TCP-Verbindung darzustellen.
TURN TURN Peer Peer
Client Server A B
|-- Allocate-Anfrage --------------->| | |
| | | |
|<--------------- Allocate-Fehler ---| | |
| (401 Nicht autorisiert) | | |
| | | |
|-- Allocate-Anfrage --------------->| | |
| | | |
|<---------- Allocate-Erfolgsantwort | | |
| (192.0.2.15:50000) | | |
// // // //
| | | |
|-- Refresh-Anfrage ---------------->| | |
| | | |
|<----------- Refresh-Erfolgsantwort | | |
| | | |
Abbildung 2
In Abbildung 2 sendet der Client eine Allocate-Anfrage ohne Anmeldeinformationen an den Server. Da der Server die Verwendung des Langzeit-Anmeldeinformationsmechanismus von STUN für alle Anfragen erfordert, lehnt der Server die Anfrage mit einem 401 (Nicht autorisiert)-Fehlercode ab. Der Client versucht es dann erneut, diesmal mit Anmeldeinformationen (nicht gezeigt). Diesmal akzeptiert der Server die Allocate-Anfrage und gibt eine Allocate-Erfolgsantwort zurück, die (unter anderem) die der Allokation zugewiesene weitergeleitete Transportadresse enthält. Später entscheidet sich der Client, die Allokation zu aktualisieren, also sendet er eine Refresh-Anfrage an den Server. Die Aktualisierung wird akzeptiert und der Server antwortet mit einer Refresh-Erfolgsantwort.
2.3. Berechtigungen
Um Bedenken von Unternehmens-IT-Administratoren zu mildern, dass TURN zur Umgehung der Unternehmensfirewall-Sicherheit verwendet werden könnte, umfasst TURN das Konzept der Berechtigungen (PERMISSIONS). Eine TURN-Berechtigung imitiert den adresseingeschränkten Filtermechanismus eines NAT, der [RFC4787] entspricht.
Eine Allokation kann null oder mehr Berechtigungen haben. Jede Berechtigung besteht aus einer IP-Adresse und einer Lebensdauer. Wenn der Server ein UDP-Datagramm an der weitergeleiteten Transportadresse einer Allokation empfängt, überprüft er zunächst die Liste der Berechtigungen. Wenn die Quell-IP-Adresse des Datagramms mit einer Berechtigung übereinstimmt, werden die Anwendungsdaten an den Client weitergeleitet, andernfalls wird das UDP-Datagramm stillschweigend verworfen.
Wenn eine Berechtigung nicht aktualisiert wird, läuft sie nach 5 Minuten ab, und es gibt keine Möglichkeit, eine Berechtigung explizit zu löschen. Dieses Verhalten wurde gewählt, um dem Verhalten eines NAT zu entsprechen, der [RFC4787] entspricht.
Ein Client kann eine Berechtigung mit einer CreatePermission-Anfrage oder einer ChannelBind-Anfrage installieren oder aktualisieren. Mit einer CreatePermission-Anfrage können mehrere Berechtigungen mit einer einzigen Anfrage installiert oder aktualisiert werden - dies ist wichtig für Anwendungen, die ICE verwenden. Aus Sicherheitsgründen können Berechtigungen nur über Transaktionen installiert oder aktualisiert werden, die authentifiziert werden können, daher installieren oder aktualisieren Send-Indikationen und ChannelData-Nachrichten (die zum Senden von Daten an einen Peer verwendet werden) keine Berechtigungen.
Beachten Sie, dass Berechtigungen im Kontext einer Allokation stehen, sodass das Hinzufügen oder Ablaufen einer Berechtigung in einer Allokation andere Allokationen nicht beeinflusst.
2.4. Sendemechanismus
Es gibt zwei Mechanismen, mit denen der Client und Peers Anwendungsdaten über den TURN-Server austauschen. Der erste Mechanismus verwendet Send- und Data-Methoden, und der zweite verwendet Kanäle. Die beiden Mechanismen schließen sich für einen bestimmten Peer gegenseitig aus: Der Client kann wählen, welchen Mechanismus er für einen bestimmten Peer verwenden möchte, aber sobald er gewählt wurde, kann der Mechanismus nicht geändert werden. Beiden Mechanismen gemeinsam ist die Fähigkeit des Clients, mit mehreren Peers unter Verwendung einer einzigen zugewiesenen weitergeleiteten Transportadresse zu kommunizieren; daher enthalten beide Mechanismen eine Möglichkeit für den Client, dem Server anzuzeigen, welcher Peer die Daten empfangen soll, und für den Server, dem Client anzuzeigen, welcher Peer die Daten gesendet hat.
Der Send-Mechanismus verwendet Send- und Data-Indikationen. Send-Indikationen werden verwendet, um Anwendungsdaten vom Client zum Server zu senden, während Data-Indikationen verwendet werden, um Anwendungsdaten vom Server zum Client zu senden.
Bei Verwendung des Send-Mechanismus sendet der Client eine Send-Indikation an den TURN-Server, die (a) ein XOR-PEER-ADDRESS-Attribut enthält, das die (serverreflexive) Transportadresse des Peers angibt, und (b) ein DATA-Attribut, das die Anwendungsdaten enthält. Wenn der TURN-Server die Send-Indikation empfängt, extrahiert er die Anwendungsdaten aus dem DATA-Attribut und sendet sie in einem UDP-Datagramm an den Peer, wobei er die zugewiesene Relay-Adresse als Quelladresse verwendet. Beachten Sie, dass es nicht notwendig ist, die weitergeleitete Transportadresse anzugeben, da sie durch das für die Send-Indikation verwendete 5-Tupel impliziert wird.
In umgekehrter Richtung werden an der weitergeleiteten Transportadresse auf dem TURN-Server ankommende UDP-Datagramme in Data-Indikationen umgewandelt und an den Client gesendet, wobei die serverreflexive Transportadresse des Peers in einem XOR-PEER-ADDRESS-Attribut und die Daten selbst in einem DATA-Attribut enthalten sind. Da die weitergeleitete Transportadresse die Allokation eindeutig identifiziert, weiß der Server, welcher Client die Daten empfangen soll.
Send- und Data-Indikationen können nicht authentifiziert werden, da der Langzeit-Anmeldeinformationsmechanismus von STUN die Authentifizierung von Indikationen nicht unterstützt. Dies ist nicht so großes Problem, wie es zunächst scheinen mag, da der Pfad vom Client zum Server nur die Hälfte des gesamten Pfads zum Peer ist. Anwendungen, die angemessene Sicherheit wünschen, sollten die zwischen dem Client und dem Peer gesendeten Daten verschlüsseln.
Da Send-Indikationen nicht authentifiziert sind, könnte ein Angreifer eine gefälschte Send-Indikation an den Server senden, die der Server dann an den Peer weiterleiten würde. Um diesen Angriff teilweise zu mildern, erfordert TURN, dass der Client eine Berechtigung für den Peer installiert, bevor er Daten an diesen Peer mit einer Send-Indikation sendet.
TURN TURN Peer Peer
Client Server A B
| | | |
|-- CreatePermission-Anfrage (Peer A) | | |
|<-- CreatePermission-Erfolgsantwort --| | |
| | | |
|--- Send-Indikation (Peer A)------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<-------------- Data-Indikation (Peer A) | | |
| | | |
| | | |
|--- Send-Indikation (Peer B)------->| | |
| | verworfen | |
| | | |
| |<== data ==================|
| verworfen | | |
| | | |
Abbildung 3
In Abbildung 3 hat der Client bereits eine Allokation erstellt und möchte nun Daten an seine Peers senden. Der Client erstellt zunächst eine Berechtigung, indem er eine CreatePermission-Anfrage an den Server sendet und die (serverreflexive) IP-Adresse von Peer A in einem XOR-PEER-ADDRESS-Attribut angibt, da der Server ohne dies keine Daten zwischen dem Client und dem Server weiterleitet. Dann sendet der Client Daten an Peer A mit einer Send-Indikation, und am Server werden die Anwendungsdaten extrahiert und in einem UDP-Datagramm an Peer A weitergeleitet, wobei die weitergeleitete Transportadresse als Quelltransportadresse verwendet wird. Wenn ein UDP-Datagramm von Peer A an der weitergeleiteten Transportadresse empfangen wird, wird der Inhalt in eine Data-Indikation eingefügt und an den Client weitergeleitet. Später versucht der Client, Daten mit Peer B auszutauschen, jedoch wurde für Peer B keine Berechtigung installiert, sodass sowohl die Send-Indikation vom Client als auch das UDP-Datagramm vom Peer vom Server verworfen werden.
2.5. Kanäle
Für einige Anwendungen (z. B. Voice over IP) können die 36 Bytes Overhead, die eine Send-Indikation oder Data-Indikation zu den Anwendungsdaten hinzufügt, die zwischen dem Client und dem Server erforderliche Bandbreite erheblich erhöhen. Um dies zu beheben, bietet TURN eine zweite Möglichkeit für den Client und den Server, Daten mit einem bestimmten Peer zu assoziieren.
Diese zweite Möglichkeit verwendet ein alternatives Paketformat, das als ChannelData-Nachricht bekannt ist. Die ChannelData-Nachricht verwendet nicht den STUN-Header, der von anderen TURN-Nachrichten verwendet wird, sondern hat einen 4-Byte-Header, der eine als Kanalnummer (CHANNEL NUMBER) bekannte Zahl enthält. Jede verwendete Kanalnummer ist an einen bestimmten Peer gebunden und dient somit als Abkürzung 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 fügt eine ungebundene Kanalnummer und die Transportadresse des Peers hinzu. Sobald der Kanal gebunden ist, kann der Client eine ChannelData-Nachricht verwenden, um Daten an den für den Server bestimmten Peer zu senden. In ähnlicher Weise kann der Server Daten von diesem Peer an den Client unter Verwendung einer ChannelData-Nachricht weiterleiten.
Kanalbindungen dauern 10 Minuten, es sei denn, sie werden aktualisiert - diese Lebensdauer wurde gewählt, um länger als die Berechtigungslebensdauer zu sein. Eine Kanalbindung wird aktualisiert, indem eine weitere ChannelBind-Anfrage gesendet wird, die den Kanal erneut an den Peer bindet. Wie bei Berechtigungen (aber im Gegensatz zu Allokationen) gibt es keine Möglichkeit, eine Kanalbindung explizit zu löschen, und der Client muss einfach warten, bis sie abläuft.
TURN TURN Peer Peer
Client Server A B
| | | |
|-- ChannelBind-Anfrage ------------->| | |
| (Peer A an 0x4001) | | |
| | | |
|<---------- ChannelBind-Erfolgsantwort | | |
| | | |
|-- [0x4001] data ------------------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
|--- Send-Indikation (Peer A)------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
Abbildung 4
Abbildung 4 zeigt den verwendeten Kanalmechanismus. Der Client hat bereits eine Allokation erstellt und möchte nun einen Kanal an Peer A binden. Dazu sendet der Client eine ChannelBind-Anfrage an den Server, gibt die Transportadresse von Peer A und eine Kanalnummer (0x4001) an. Danach kann der Client Anwendungsdaten an Peer A gekapselt in einer ChannelData-Nachricht senden: dies wird als „[0x4001] data" angezeigt, wobei 0x4001 die Kanalnummer ist. Wenn die ChannelData-Nachricht am Server ankommt, überträgt der Server die Daten in ein UDP-Datagramm und sendet sie an Peer A (d. h. den an Kanalnummer 0x4001 gebundenen Peer).
In umgekehrter Richtung, wenn Peer A ein UDP-Datagramm an die weitergeleitete Transportadresse sendet, kommt dieses UDP-Datagramm am Server an der der Allokation zugewiesenen weitergeleiteten Transportadresse an. Da das UDP-Datagramm von Peer A empfangen wurde und Peer A eine Kanalnummer zugewiesen wurde, kapselt der Server die Daten in einer ChannelData-Nachricht beim Senden der Daten an den Client.
Sobald ein Kanal gebunden ist, kann der Client ChannelData-Nachrichten und Send-Indikationen frei mischen. In der Abbildung entscheidet sich der Client später, zusätzliche Daten an Peer A mit einer Send-Indikation anstelle einer ChannelData-Nachricht zu senden. Der Client könnte sich beispielsweise dafür entscheiden, das DONT-FRAGMENT-Attribut verwenden zu können (siehe nächster Abschnitt). Sobald ein Kanal gebunden ist, verwendet der Server jedoch immer eine ChannelData-Nachricht, wie im Aufruffluss gezeigt.
Beachten Sie, dass ChannelData-Nachrichten nur für Peers verwendet werden können, für die der Client einen Kanal gebunden hat. Im obigen Beispiel wurde Peer A an einen Kanal gebunden, Peer B jedoch nicht, sodass Anwendungsdaten zu oder von Peer B den Send-Mechanismus verwenden.
2.6. Nicht privilegierte TURN-Server
Diese Version von TURN ist so konzipiert, dass der Server als Anwendung implementiert werden kann, die im Benutzerbereich unter häufig eingesetzten Betriebssystemen ohne spezielle Berechtigungen ausgeführt wird. Diese Designentscheidung wurde getroffen, um die Bereitstellung von TURN-Servern zu erleichtern: Beispielsweise um TURN-Server in Peer-Anwendungen zu integrieren, sodass ein Peer einem anderen Peer NAT-Traversal-Dienste anbieten kann.
Diese Designentscheidung hat die folgenden Auswirkungen auf von einem TURN-Server weitergeleitete Daten:
-
Der Wert des Diffserv-Felds wird möglicherweise nicht über den Server hinweg erhalten.
-
Das Time to Live (TTL)-Feld wird möglicherweise über den Server hinweg zurückgesetzt, anstatt dekrementiert zu werden.
-
Das Explicit Congestion Notification (ECN)-Feld wird möglicherweise vom Server zurückgesetzt.
-
ICMP-Nachrichten werden nicht vom Server weitergeleitet.
-
Es gibt keine End-to-End-Fragmentierung, da Pakete am Server wieder zusammengesetzt werden.
Zukünftige Arbeiten können alternative TURN-Semantiken spezifizieren, die diese Einschränkungen adressieren.
2.7. Vermeidung von IP-Fragmentierung
Aus den in [Frag-Harmful] beschriebenen Gründen sollten Anwendungen, insbesondere solche, die große Datenmengen senden, versuchen, eine Fragmentierung ihrer Pakete zu vermeiden. Anwendungen, die TCP verwenden, können dieses Problem mehr oder weniger ignorieren, da Fragmentierungsvermeidung jetzt ein Standardteil von TCP ist, aber Anwendungen, die UDP verwenden (und daher jede Anwendung, die diese Version von TURN verwendet), müssen die Fragmentierungsvermeidung selbst handhaben.
Anwendungen, die auf dem Client und dem Peer ausgeführt werden, können einen von zwei Ansätzen wählen, um IP-Fragmentierung zu vermeiden.
Der erste Ansatz besteht darin, zu vermeiden, große Mengen an Anwendungsdaten in den zwischen dem Client und dem Peer ausgetauschten TURN-Nachrichten/UDP-Datagrammen zu senden. Dies ist der Ansatz, den die meisten VoIP-Anwendungen (Voice over IP) verfolgen. Bei diesem Ansatz nutzt die Anwendung die Tatsache, dass die IP-Spezifikation [RFC0791] festlegt, dass IP-Pakete bis zu 576 Bytes niemals fragmentiert werden müssen.
Die genaue Menge an Anwendungsdaten, die enthalten sein können (während Fragmentierung vermieden wird), hängt von den Details der TURN-Sitzung zwischen dem Client und dem Server ab: ob UDP-, TCP- oder TLS-Transport verwendet wird, ob ChannelData-Nachrichten oder Send/Data-Indikationen verwendet werden und ob zusätzliche Attribute (wie das DONT-FRAGMENT-Attribut) enthalten sind. Ein weiterer schwer zu bestimmender Faktor ist, ob die MTU irgendwo entlang des Pfads aus anderen Gründen reduziert wird, beispielsweise aufgrund der Verwendung von IP-in-IP-Tunneling.
Als Richtlinie wird das Senden von höchstens 500 Bytes Anwendungsdaten in einer einzelnen TURN-Nachricht (durch den Client auf dem Client-zu-Server-Pfad) oder einem UDP-Datagramm (durch den Peer auf dem Peer-zu-Server-Pfad) im Allgemeinen IP-Fragmentierung vermeiden. Um die Chance einer Fragmentierung weiter zu reduzieren, wird empfohlen, dass der Client ChannelData-Nachrichten verwendet, wenn große Datenmengen gesendet werden, da die ChannelData-Nachricht weniger Overhead als Send- und Data-Indikationen hat.
Der zweite Ansatz, den der Client und der Peer zur Vermeidung von Fragmentierung verwenden können, besteht darin, einen Pfad-MTU-Discovery-Algorithmus zu verwenden, um die maximale Menge an Anwendungsdaten zu bestimmen, die ohne Fragmentierung gesendet werden können.
Leider kann der in [RFC1191] definierte klassische Pfad-MTU-Discovery-Algorithmus die MTU des Übertragungspfads zwischen dem Client und dem Peer nicht ermitteln, da Server, die diese Version von TURN implementieren, keine ICMP-Nachrichten weiterleiten. (Und selbst wenn sie ICMP-Nachrichten weiterleiten würden, würde der Algorithmus nicht immer funktionieren, da ICMP-Nachrichten oft von kombinierten NAT/Firewall-Geräten herausgefiltert werden).
Daher müssen der Client und der Server einen Pfad-MTU-Discovery-Algorithmus verwenden, der keine ICMP-Nachrichten erfordert. Der in [RFC4821] definierte Packetized Path MTU Discovery-Algorithmus ist ein solcher Algorithmus.
Die Details zur Verwendung des Algorithmus von [RFC4821] mit TURN werden noch ausgearbeitet. Als Schritt in Richtung dieses Ziels unterstützt diese Version von TURN jedoch das DONT-FRAGMENT-Attribut. Wenn der Client dieses Attribut in einer Send-Indikation einschließt, weist dies den Server an, das DF-Bit im resultierenden UDP-Datagramm zu setzen, das der Server an den Peer sendet. Da einige Server möglicherweise nicht in der Lage sind, das DF-Bit zu setzen, sollte der Client dieses Attribut auch in die Allocate-Anfrage aufnehmen - jeder Server, der das DONT-FRAGMENT-Attribut nicht unterstützt, zeigt dies an, indem er die Allocate-Anfrage ablehnt.
2.8. RTP-Unterstützung
Eine der vorgesehenen Verwendungen von TURN ist als Relay für Clients und Peers, die Echtzeitdaten (wie Sprache oder Video) unter Verwendung von RTP austauschen möchten. Um die Verwendung von TURN für diesen Zweck zu erleichtern, umfasst TURN einige spezielle Unterstützung für ältere Versionen von RTP.
Ältere Versionen von RTP [RFC3550] erforderten, dass der RTP-Stream auf einer geraden Portnummer und der zugehörige RTP Control Protocol (RTCP)-Stream (falls vorhanden) auf dem nächsthöheren Port ist. Um Clients zu ermöglichen, mit Peers zu arbeiten, die dies noch erfordern, erlaubt TURN dem Client zu fordern, dass der Server eine weitergeleitete Transportadresse mit einer geraden Portnummer zuweist, und optional zu fordern, dass der Server die nächsthöhere Portnummer für eine nachfolgende Allokation reserviert.
2.9. Anycast-Erkennung von Servern
Diese Version von TURN ist so konzipiert, dass zukünftige Spezifikationen die Anycast-Erkennung von TURN-Servern über UDP ermöglichen können.
Insbesondere kann ein TURN-Server eine Allocate-Anfrage ablehnen und vorschlagen, dass der Client einen alternativen Server versucht. Um bestimmte Arten von Angriffen zu verhindern, muss der Client dieselben Anmeldeinformationen mit dem alternativen Server verwenden, die er mit dem ursprünglichen Server verwendet hätte.