7. Base Protocol Procedures (Basisprotokollverfahren)
Dieser Abschnitt definiert die Basisverfahren des STUN-Protokolls. Er beschreibt, wie Nachrichten gebildet werden, wie sie gesendet werden und wie sie bei Empfang verarbeitet werden. Er definiert auch die detaillierte Verarbeitung der Binding-Methode. Andere Abschnitte dieses Dokuments beschreiben optionale Verfahren, die eine Verwendung in bestimmten Situationen wählen kann. Andere Dokumente können weitere Erweiterungen zu STUN definieren, indem sie neue Methoden, neue Attribute oder neue Fehlerantwortkodes hinzufügen.
7.1. Forming a Request or an Indication (Bildung einer Anfrage oder Anzeige)
Bei der Bildung einer Anfrage- oder Anzeigemeldung muss (MUST) der Agent die Regeln in Abschnitt 6 zur Erstellung des Headers befolgen. Zusätzlich muss (MUST) die Nachrichtenklasse entweder "Request" oder "Indication" (je nach Fall) sein, und die Methode muss (must) Binding oder eine in einem anderen Dokument definierte Methode sein.
Der Agent fügt dann alle von der Methode oder Verwendung spezifizierten Attribute hinzu. Beispielsweise können einige Verwendungen spezifizieren, dass der Agent eine Authentifizierungsmethode (Abschnitt 10) oder das FINGERPRINT-Attribut (Abschnitt 8) verwendet.
Wenn der Agent eine Anfrage sendet, sollte (SHOULD) er ein SOFTWARE-Attribut zur Anfrage hinzufügen. Je nach Methode kann (MAY) der Agent ein SOFTWARE-Attribut in Anzeigen einschließen. Erweiterungen zu STUN sollten diskutieren, ob SOFTWARE in neuen Anzeigen nützlich ist.
Für die Binding-Methode ohne Authentifizierung sind keine Attribute erforderlich, es sei denn, die Verwendung spezifiziert etwas anderes.
Alle über UDP gesendeten STUN-Nachrichten sollten (SHOULD) kleiner als die Pfad-MTU sein, falls bekannt. Wenn die Pfad-MTU unbekannt ist, sollten (SHOULD) Nachrichten das kleinere von 576 Bytes und der First-Hop-MTU für IPv4 [RFC1122] und 1280 Bytes für IPv6 [RFC2460] sein. Dieser Wert entspricht der Gesamtgröße des IP-Pakets. Folglich muss die tatsächliche STUN-Nachricht für IPv4 kleiner als 548 Bytes sein (576 minus 20-Byte-IP-Header, minus 8-Byte-UDP-Header, unter der Annahme, dass keine IP-Optionen verwendet werden). STUN bietet nicht die Möglichkeit, den Fall zu handhaben, in dem die Anfrage unter die MTU passt, die Antwort jedoch größer als die MTU wäre. Es wird nicht erwartet, dass diese Einschränkung ein Problem für STUN darstellt. Die MTU-Einschränkung ist ein SHOULD und kein MUST, um Fälle zu berücksichtigen, in denen STUN selbst verwendet wird, um MTU-Eigenschaften zu untersuchen [BEHAVE-NAT]. Außerhalb solcher oder ähnlicher Anwendungen muss (MUST) die MTU-Beschränkung eingehalten werden.
7.2. Sending the Request or Indication (Senden der Anfrage oder Anzeige)
Der Agent sendet dann die Anfrage oder Anzeige. Dieses Dokument spezifiziert, wie STUN-Nachrichten über UDP, TCP oder TLS-over-TCP gesendet werden; andere Transportprotokolle können in Zukunft hinzugefügt werden. Eine STUN-Verwendung muss (must) spezifizieren, welches Transportprotokoll verwendet wird und wie der Agent die IP-Adresse und den Port des Empfängers bestimmt. Abschnitt 9 beschreibt eine DNS-basierte Methode zur Bestimmung der IP-Adresse und des Ports eines Servers, die eine Verwendung wählen kann. STUN kann mit Anycast-Adressen verwendet werden, aber nur mit UDP und nur wenn keine Authentifizierung verwendet wird.
Zu jedem Zeitpunkt kann (MAY) ein Client mehrere ausstehende STUN-Anfragen an denselben STUN-Server haben (d.h. mehrere laufende Transaktionen mit unterschiedlichen Transaktions-IDs). In Abwesenheit anderer Beschränkungen der Rate neuer Transaktionen (wie sie von ICE für Konnektivitätsprüfungen spezifiziert sind oder wenn STUN über TCP läuft), sollte (SHOULD) ein Client neue Transaktionen zu einem Server im Abstand von RTO durchführen und sollte (SHOULD) sich auf maximal zehn ausstehende Transaktionen zum selben Server beschränken.
7.2.1. Sending over UDP (Senden über UDP)
Beim Ausführen von STUN über UDP können STUN-Nachrichten vom Netzwerk verloren gehen. Die Zuverlässigkeit von STUN-Anfrage/Antwort-Transaktionen wird durch die Wiederübertragung der Anfragenachricht durch die Client-Anwendung selbst erreicht. STUN-Anzeigen werden nicht erneut übertragen; daher sind Anzeigetransaktionen über UDP nicht zuverlässig.
Ein Client sollte (SHOULD) eine STUN-Anfragenachricht beginnend mit einem Intervall von RTO ("Retransmission TimeOut", Wiederübertragungszeitüberschreitung) erneut übertragen und nach jeder Wiederübertragung verdoppeln. Das RTO ist eine Schätzung der Rundlaufzeit (RTT, round-trip time) und wird wie in RFC 2988 [RFC2988] beschrieben berechnet, mit zwei Ausnahmen. Erstens sollte (SHOULD) der Anfangswert für RTO konfigurierbar sein (anstelle der in RFC 2988 empfohlenen 3 s) und sollte (SHOULD) größer als 500 ms sein. Die Ausnahme von diesem "SHOULD" gilt für Fälle, in denen andere Mechanismen verwendet werden, um Überlastungsschwellen abzuleiten (wie die von ICE für feste Ratenströme definierten Mechanismen) oder wenn STUN in Nicht-Internet-Umgebungen mit bekannten Netzwerkkapazitäten verwendet wird. In Festnetz-Zugangsverbindungen wird ein Wert von 500 ms empfohlen (RECOMMENDED). Zweitens sollte (SHOULD NOT) der Wert von RTO nicht auf die nächste Sekunde aufgerundet werden. Stattdessen sollte (SHOULD) eine Genauigkeit von 1 ms beibehalten werden. Wie bei TCP wird der Karn-Algorithmus [KARN87] empfohlen (RECOMMENDED). Dies bedeutet, dass RTT-Schätzungen nicht (SHOULD NOT) aus STUN-Transaktionen berechnet werden sollten, die zu einer Wiederübertragung einer Anfrage führen.
Der Wert für RTO sollte (SHOULD) von einem Client nach Abschluss der Transaktion zwischengespeichert und als Startwert für RTO für die nächste Transaktion zum selben Server (basierend auf IP-Adressengleichheit) verwendet werden. Der Wert sollte (SHOULD) nach 10 Minuten als veraltet betrachtet und verworfen werden.
Wiederübertragungen werden fortgesetzt, bis eine Antwort empfangen wird oder bis insgesamt Rc Anfragen gesendet wurden. Rc sollte (SHOULD) konfigurierbar sein und sollte (SHOULD) einen Standardwert von 7 haben. Wenn nach der letzten Anfrage eine Dauer gleich Rm mal dem RTO ohne Antwort vergangen ist (was ausreichend Zeit bietet, um eine Antwort zu erhalten, wenn nur diese letzte Anfrage tatsächlich erfolgreich ist), sollte (SHOULD) der Client die Transaktion als abgelaufen betrachten. Rm sollte (SHOULD) konfigurierbar sein und sollte (SHOULD) einen Standardwert von 16 haben. Eine STUN-Transaktion über UDP wird auch als fehlgeschlagen betrachtet, wenn ein harter ICMP-Fehler [RFC1122] aufgetreten ist. Zum Beispiel würden bei einem RTO von 500 ms Anfragen zu den Zeiten 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms und 31500 ms gesendet. Wenn der Client nach 39500 ms keine Antwort erhalten hat, wird der Client die Transaktion als abgelaufen betrachten.
7.2.2. Sending over TCP or TLS-over-TCP (Senden über TCP oder TLS-over-TCP)
Für TCP und TLS-over-TCP öffnet der Client eine TCP-Verbindung zum Server.
In einigen STUN-Verwendungen wird STUN als einziges Protokoll über die TCP-Verbindung gesendet. In diesem Fall kann es ohne Hilfe zusätzlicher Rahmung oder Demultiplexierung gesendet werden. In anderen Verwendungen oder mit anderen Erweiterungen kann es mit anderen Daten über eine TCP-Verbindung multiplexiert werden. In diesem Fall muss (MUST) STUN auf einer Art Rahmungsprotokoll ausgeführt werden, das von der Verwendung oder Erweiterung spezifiziert wird und es dem Agent ermöglicht, vollständige STUN-Nachrichten und vollständige Anwendungsschichtnachrichten zu extrahieren. Der STUN-Dienst, der auf dem bekannten Port oder auf einem über die DNS-Verfahren in Abschnitt 9 entdeckten Port läuft, ist nur für STUN und nicht für STUN multiplexiert mit anderen Daten. Folglich werden in Verbindungen zu diesen Servern keine Rahmungsprotokolle verwendet. Wenn zusätzliche Rahmung verwendet wird, gibt die Verwendung an, wie der Client weiß, sie anzuwenden und mit welchem Port er sich verbinden soll. Zum Beispiel werden diese Informationen im Fall von ICE-Konnektivitätsprüfungen durch Out-of-Band-Verhandlung zwischen Client und Server gelernt.
Wenn STUN allein über TLS-over-TCP ausgeführt wird, muss (MUST) die TLS_RSA_WITH_AES_128_CBC_SHA-Cipher-Suite mindestens implementiert werden. Eine Implementierung kann (MAY) auch jede andere Cipher-Suite unterstützen. Wenn eine TLS-Zertifikatsnachricht empfangen wird, sollte (SHOULD) der Client das Zertifikat überprüfen und prüfen, ob das Zertifikat die entsprechende Partei identifiziert. Wenn das Zertifikat ungültig oder widerrufen ist oder wenn es die entsprechende Partei nicht identifiziert, darf (MUST NOT) der Client die STUN-Nachricht nicht senden oder anderweitig mit der STUN-Transaktion fortfahren. Der Client muss (MUST) die Identität des Servers überprüfen. Dazu folgt er den in Abschnitt 3.1 von RFC 2818 [RFC2818] definierten Identifikationsverfahren. Diese Verfahren gehen davon aus, dass der Client einen URI dereferenziert. Für die Verwendung mit dieser Spezifikation behandelt der Client den in Abschnitt 8.1 verwendeten Domainnamen oder die IP-Adresse als Hostteil des dereferenzierten URI. Alternativ kann (MAY) ein Client mit einer Reihe vertrauenswürdiger Domains oder IP-Adressen konfiguriert werden; wenn ein Zertifikat empfangen wird, das eine dieser Domains oder IP-Adressen identifiziert, betrachtet der Client die Identität des Servers als verifiziert.
Wenn STUN mit anderen Protokollen über eine TLS-over-TCP-Verbindung multiplexiert wird, funktionieren die obligatorischen Cipher-Suites und TLS-Behandlungsverfahren wie von diesen Protokollen definiert.
Die Zuverlässigkeit von STUN über TCP und TLS-over-TCP wird von TCP selbst gehandhabt, und es gibt keine Wiederübertragungen auf STUN-Protokollebene. Für eine Anfrage/Antwort-Transaktion gilt jedoch: Wenn der Client innerhalb von Ti Sekunden nach dem Senden des SYN zum Aufbau der Verbindung keine Antwort erhält, betrachtet er die Transaktion als abgelaufen. Ti sollte (SHOULD) konfigurierbar sein und sollte (SHOULD) einen Standardwert von 39,5 Sekunden haben. Dieser Wert wurde gewählt, um gleich dem TCP-Timeout mit Standard-Initial-RTO für TCP und UDP zu sein.
(Der Inhalt wird in der tatsächlichen Implementierung fortgesetzt)