5. SCTP over DTLS over UDP Considerations (Überlegungen zu SCTP über DTLS über UDP)

Die wichtigen Merkmale von SCTP im WebRTC-Kontext sind folgende:

• Verwendung von TCP-freundlicher Staukontrolle.
• Modifizierbare Staukontrolle für die Integration mit der SRTP-Medienstream-Staukontrolle.
• Unterstützung mehrerer unidirektionaler Streams, von denen jeder sein eigenes Konzept der geordneten Nachrichtenzustellung bietet.
• Unterstützung von geordneter und ungeordneter Nachrichtenzustellung.
• Unterstützung beliebig großer Benutzernachrichten durch Fragmentierung und Reassemblierung.
• Unterstützung der PMTU-Erkennung.
• Unterstützung von zuverlässigem oder teilweise zuverlässigem Nachrichtentransport.

Der WebRTC-Datenkanalsmechanismus unterstützt kein SCTP-Multihoming. Die SCTP-Schicht verhält sich einfach so, als würde sie auf einem Single-Homed-Host laufen, da dies die Abstraktion ist, die die DTLS-Schicht (ein verbindungsorientierter, unzuverlässiger Datagrammdienst) bereitstellt.

Die in [RFC8261] definierte Kapselung von SCTP über DTLS bietet Vertraulichkeit, Quellauthentifizierung und integritätsgeschützte Übertragungen. Die Verwendung von DTLS über UDP in Kombination mit Interactive Connectivity Establishment (ICE) [RFC8445] ermöglicht Middlebox-Traversal in IPv4- und IPv6-basierten Netzwerken. SCTP, wie in [RFC4960] spezifiziert, MUSS in Kombination mit der in [RFC3758] definierten Erweiterung verwendet werden und bietet folgende Funktionen für den Transport von Nicht-Mediendaten zwischen Browsern:

• Unterstützung mehrerer unidirektionaler Streams.
• Geordnete und ungeordnete Zustellung von Benutzernachrichten.
• Zuverlässiger und teilweise zuverlässiger Transport von Benutzernachrichten.

Jede SCTP-Benutzernachricht enthält einen Payload Protocol Identifier (PPID), der von seiner oberen Schicht auf der Sendeseite an SCTP übergeben und auf der Empfangsseite an seine obere Schicht weitergegeben wird. Der PPID kann verwendet werden, um mehrere obere Schichten über eine einzige SCTP-Assoziation zu multiplexen/demultiplexen. Im WebRTC-Kontext wird der PPID verwendet, um zwischen UTF-8-kodierten Benutzerdaten, binär-kodierten Benutzerdaten und dem in [RFC8832] definierten Data Channel Establishment Protocol (DCEP) zu unterscheiden. Bitte beachten Sie, dass der PPID nicht über die JavaScript-API zugänglich ist.

Die Kapselung von SCTP über DTLS erfüllt zusammen mit den oben aufgeführten SCTP-Funktionen alle in Abschnitt 4 aufgeführten Anforderungen.

Die Protokollschichtung für WebRTC ist in Abbildung 2 dargestellt.

              +------+------+------+
              | DCEP | UTF-8|Binär |
              |      | Daten| Daten|
              +------+------+------+
              |        SCTP        |
+----------------------------------+
| STUN | SRTP |        DTLS        |
+----------------------------------+
|                ICE               |
+----------------------------------+
| UDP1 | UDP2 | UDP3 | ...         |
+----------------------------------+

Abbildung 2: WebRTC-Protokollschichten

Dieser Stack wurde aus folgenden Gründen gewählt:

• unterstützt die Übertragung beliebig großer Benutzernachrichten;
• teilt die DTLS-Verbindung mit den SRTP-Medienkanälen der PeerConnection; und
• bietet Datenschutz für die SCTP-Steuerungsinformationen.

Bezüglich des in Abbildung 2 gezeigten Protokoll-Stacks:

• die Verwendung von DTLS 1.0 über UDP ist in [RFC4347] spezifiziert;
• die Verwendung von DTLS 1.2 über UDP ist in [RFC6347] spezifiziert;
• die Verwendung von DTLS 1.3 über UDP ist in einem kommenden Dokument [TLS-DTLS13] spezifiziert; und
• die Verwendung von SCTP über DTLS ist in [RFC8261] spezifiziert.

Bitte beachten Sie, dass das Demultiplexen von STUN [RFC5389] vs. SRTP vs. DTLS wie in Abschnitt 5.1.2 von [RFC5764] beschrieben durchgeführt wird, und SCTP ist die einzige Nutzlast von DTLS.

Da DTLS typischerweise im Benutzeranwendungsraum implementiert ist, muss der SCTP-Stack ebenfalls ein Benutzeranwendungsraum-Stack sein.

Die ICE/UDP-Schicht kann IP-Adressänderungen während einer Sitzung verarbeiten, ohne mit den DTLS- und SCTP-Schichten interagieren zu müssen. SCTP SOLLTE jedoch benachrichtigt werden, wenn eine Adressänderung stattgefunden hat. In diesem Fall SOLLTE SCTP den Path-MTU neu testen und den Staukontrollzustand auf den Anfangszustand zurücksetzen.

Eingehende ICMP- oder ICMPv6-Nachrichten können von der SCTP-Schicht nicht verarbeitet werden, da es keine Möglichkeit gibt, die entsprechende Assoziation zu identifizieren. Daher MUSS SCTP die Durchführung der Path-MTU-Erkennung ohne Abhängigkeit von ICMP oder ICMPv6 unterstützen, wie in [RFC4821] spezifiziert, unter Verwendung von Sondierungsnachrichten aus [RFC4820]. Der anfängliche Path-MTU auf der IP-Schicht SOLLTE 1200 Bytes für IPv4 und 1280 Bytes für IPv6 nicht überschreiten.

SCTP bietet Staukontrolle auf Assoziationsbasis. Das bedeutet, dass alle SCTP-Streams innerhalb einer einzigen SCTP-Assoziation dasselbe Staufenster teilen.

SCTP verwendet dasselbe Portnummernkonzept wie TCP und UDP. Daher verwendet eine SCTP-Assoziation zwei Portnummern, eine an jedem SCTP-Endpunkt.