4. Allgemeines Verhalten
Dieser Abschnitt enthält allgemeine TURN-Verarbeitungsregeln, die für alle TURN-Nachrichten gelten.
TURN ist eine Erweiterung von STUN. Alle TURN-Nachrichten, mit Ausnahme der ChannelData-Nachricht, sind STUN-formatierte Nachrichten. Alle in [RFC5389] beschriebenen grundlegenden Verarbeitungsregeln gelten für STUN-formatierte Nachrichten. Dies bedeutet, dass alle Beschreibungen zur Nachrichtenbildung und Nachrichtenverarbeitung in diesem Dokument implizit mit den Regeln von [RFC5389] vorangestellt sind.
[RFC5389] spezifiziert einen Authentifizierungsmechanismus, der als Langzeit-Credential-Mechanismus (Long-Term Credential Mechanism) bezeichnet wird. TURN-Server und -Clients müssen diesen Mechanismus implementieren. Der Server muss verlangen, dass alle Anfragen vom Client mit diesem Mechanismus oder mit einem gleichwertigen oder stärkeren Mechanismus authentifiziert werden.
Beachten Sie, dass der Langzeit-Credential-Mechanismus nur für Anfragen gilt und nicht zur Authentifizierung von Indikationen verwendet werden kann; daher werden Indikationen in TURN niemals authentifiziert. Wenn der Server verlangt, dass Anfragen authentifiziert werden, muss der Administrator des Servers einen Realm-Wert wählen, der die Kombination aus Benutzername und Passwort, die der Client verwenden muss, eindeutig identifiziert, selbst wenn der Client mehrere Server unter verschiedenen Verwaltungen verwendet. Der Administrator des Servers kann jedem Client einen eindeutigen Benutzernamen zuweisen oder kann mehreren Clients denselben Benutzernamen zuweisen (z. B. für alle Clients derselben Abteilung oder desselben Unternehmens). Für jede Allokation sollte der Server bei der ersten Allokationsversuch einen neuen zufälligen Nonce generieren, wobei die Zufallsempfehlungen in [RFC4086] befolgt werden, und sollte den Nonce während der Lebensdauer der Allokation mindestens einmal pro Stunde ablaufen lassen.
Alle Anfragen nach der anfänglichen Allocate-Anfrage müssen denselben Benutzernamen verwenden, der zur Erstellung der Allokation verwendet wurde, um zu verhindern, dass ein Angreifer die Allokation des Clients kapert. Insbesondere, wenn der Server die Verwendung des Langzeit-Credential-Mechanismus verlangt und wenn eine Nicht-Allocate-Anfrage unter diesem Mechanismus die Authentifizierung besteht und wenn das 5-Tupel eine vorhandene Allokation identifiziert, die Anfrage jedoch nicht denselben Benutzernamen verwendet, der zur Erstellung der Allokation verwendet wurde, dann muss die Anfrage mit einem 441-Fehler (Wrong Credentials) abgelehnt werden.
Wenn eine TURN-Nachricht vom Client beim Server eintrifft, verwendet der Server das 5-Tupel in der Nachricht, um die zugehörige Allokation zu identifizieren. Für alle TURN-Nachrichten (einschließlich ChannelData) außer einer Allocate-Anfrage muss die Nachricht mit einem 437-Fehler (Allocation Mismatch) abgelehnt werden (wenn es sich um eine Anfrage handelt) oder stillschweigend ignoriert werden (wenn es sich um eine Indikation oder eine ChannelData-Nachricht handelt), wenn das 5-Tupel keine vorhandene Allokation identifiziert. Ein Client, der eine 437-Fehlerantwort auf eine Anfrage außer Allocate erhält, muss davon ausgehen, dass die Allokation nicht mehr existiert.
[RFC5389] definiert eine Reihe von Attributen, einschließlich der Attribute SOFTWARE und FINGERPRINT. Der Client sollte das SOFTWARE-Attribut in allen Allocate- und Refresh-Anfragen einschließen und kann es in jeder anderen Anfrage oder Indikation einschließen. Der Server sollte das SOFTWARE-Attribut in allen Allocate- und Refresh-Antworten (Erfolg oder Fehler) einschließen und kann es in anderen Antworten oder Indikationen einschließen. Der Client und der Server können das FINGERPRINT-Attribut in jeder STUN-formatierten Nachricht einschließen, die in diesem Dokument definiert ist.
TURN verwendet nicht den in [RFC5389] beschriebenen Rückwärtskompatibilitätsmechanismus.
Wie derzeit definiert, unterstützt TURN nur IPv4. Die IP-Adressen des Clients, des Servers und alle IP-Adressen, die in weitergeleiteten Transportadressen erscheinen, müssen IPv4-Adressen sein.
Standardmäßig läuft TURN auf denselben Ports wie STUN: 3478 für TURN über UDP und TCP und 5349 für TURN über TLS. TURN hat jedoch seinen eigenen Satz von Service-Record-Namen (SRV): „turn" für UDP und TCP und „turns" für TLS. Entweder die SRV-Verfahren oder die ALTERNATE-SERVER-Verfahren, die beide in Abschnitt 6 beschrieben sind, können verwendet werden, um TURN auf einem anderen Port auszuführen.
Um die Interoperabilität sicherzustellen, muss ein TURN-Server die Verwendung von UDP-Transport zwischen dem Client und dem Server unterstützen und sollte die Verwendung von TCP- und TLS-Transporten unterstützen.
Wenn UDP-Transport zwischen dem Client und dem Server verwendet wird, sendet der Client eine Anfrage erneut, wenn er innerhalb eines bestimmten Timeout-Zeitraums keine Antwort erhält. Aus diesem Grund kann der Server zwei (oder mehr) Anfragen mit demselben 5-Tupel und derselben Transaktions-ID erhalten. STUN verlangt, dass der Server diesen Fall erkennt und die Anfrage als idempotent behandelt (siehe [RFC5389]). Einige Implementierungen können diese Anforderung erfüllen, indem sie sich alle empfangenen Anfragen und die entsprechenden Antworten 40 Sekunden lang merken. Andere Implementierungen können die Anfrage erneut verarbeiten und dafür sorgen, dass eine solche Neuverarbeitung im Wesentlichen dieselbe Antwort zurückgibt. Um Implementierern zu helfen, die den letzteren Ansatz wählen (den sogenannten „zustandslosen Stack-Ansatz"), enthält diese Spezifikation einige Implementierungshinweise dazu. Implementierungen können frei wählen, welchen Ansatz sie verwenden oder einen anderen Ansatz wählen, der dieselben Ergebnisse liefert.
Wenn TCP-Transport zwischen dem Client und dem Server verwendet wird, können Bitfehler das Längenfeld in einem TURN-Paket beschädigen, wodurch der Empfänger die Synchronisation mit dem eingehenden Strom von TURN-Nachrichten verliert. Ein Client oder Server, der eine lange Sequenz ungültiger TURN-Nachrichten auf einem TCP-Transport erkennt, sollte die entsprechende TCP-Verbindung schließen, um dem anderen Ende zu helfen, die Situation schneller zu erkennen.
Um absichtliche oder unabsichtliche Denial-of-Service-Angriffe gegen den Server durch Clients mit gültigen Benutzernamen und Passwörtern zu mildern, wird empfohlen, dass der Server sowohl eine Begrenzung der Anzahl gleichzeitig aktiver Allokationen für einen bestimmten Benutzernamen als auch eine Begrenzung der Bandbreite, die diese Allokationen verwenden können, auferlegt. Der Server sollte neue Allokationen, die die Begrenzung der zulässigen Anzahl gleichzeitig aktiver Allokationen überschreiten würden, mit einem 486-Fehler (Allocation Quota Exceeded) ablehnen (siehe Abschnitt 6.2) und sollte Anwendungsdatenverkehr, der das Bandbreitenkontingent überschreitet, verwerfen.