5. SCTP over DTLS over UDP Considerations (Considérations relatives à SCTP sur DTLS sur UDP)

Les caractéristiques importantes de SCTP dans le contexte WebRTC sont les suivantes :

Utilisation d'un contrôle de congestion compatible TCP (TCP-friendly Congestion Control).
Contrôle de congestion modifiable pour l'intégration avec le contrôle de congestion des flux de médias SRTP.
Prise en charge de plusieurs flux unidirectionnels (Unidirectional Streams), chacun fournissant sa propre notion de livraison ordonnée des messages.
Prise en charge de la livraison ordonnée et non ordonnée des messages.
Prise en charge de messages utilisateur de taille arbitrairement grande grâce à la fragmentation et au réassemblage.
Prise en charge de la découverte du PMTU.
Prise en charge du transport de messages fiable ou partiellement fiable.

Le mécanisme de canaux de données WebRTC ne prend pas en charge le multi-homing SCTP (Multihoming). La couche SCTP se comportera simplement comme si elle fonctionnait sur un hôte à domicile unique, car c'est l'abstraction exposée par la couche DTLS (service de datagramme non fiable orienté connexion).

L'encapsulation de SCTP sur DTLS définie dans [RFC8261] fournit un transport avec confidentialité, authentification de la source et protection de l'intégrité. L'utilisation de DTLS sur UDP avec ICE (Interactive Connectivity Establishment, établissement de connectivité interactif) [RFC8445] permet la traversée des middleboxes dans les réseaux basés sur IPv4 et IPv6. SCTP tel que spécifié dans [RFC4960] DOIT (MUST) être utilisé en combinaison avec l'extension définie dans [RFC3758] et fournit les caractéristiques suivantes pour le transport de données non-médias entre navigateurs :

Prise en charge de plusieurs flux unidirectionnels.
Livraison ordonnée et non ordonnée des messages utilisateur.
Transport fiable et partiellement fiable des messages utilisateur.

Chaque message utilisateur SCTP contient un identifiant de protocole de charge utile (Payload Protocol Identifier, PPID) qui est transmis à SCTP par sa couche supérieure côté émetteur et fourni à sa couche supérieure côté récepteur. Le PPID peut être utilisé pour multiplexer/démultiplexer plusieurs couches supérieures sur une seule association SCTP. Dans le contexte WebRTC, le PPID est utilisé pour distinguer les données utilisateur encodées en UTF-8, les données utilisateur encodées en binaire et le protocole d'établissement de canal de données (Data Channel Establishment Protocol, DCEP) défini dans [RFC8832]. Notez que le PPID n'est pas accessible via l'API JavaScript.

L'encapsulation de SCTP sur DTLS, combinée aux caractéristiques SCTP listées ci-dessus, satisfait toutes les exigences listées à la section 4.

La stratification de protocoles pour WebRTC est illustrée à la figure 2.

                                 +------+------+------+
                                 | DCEP | UTF-8|Binary|
                                 |      | Data | Data |
                                 +------+------+------+
                                 |        SCTP        |
                   +----------------------------------+
                   | STUN | SRTP |        DTLS        |
                   +----------------------------------+
                   |                ICE               |
                   +----------------------------------+
                   | UDP1 | UDP2 | UDP3 | ...         |
                   +----------------------------------+

Figure 2 : Couches de protocoles WebRTC

Les raisons du choix de cette pile de protocoles (notamment par rapport à DTLS sur SCTP [RFC6083] et à SCTP sur UDP [RFC6951] en combinaison) sont les suivantes :

Prise en charge du transport de messages utilisateur de taille arbitrairement grande.
Partage de la connexion DTLS avec les canaux de médias SRTP de la PeerConnection.
Fourniture de confidentialité pour les informations de contrôle SCTP.

En référence à la pile de protocoles illustrée à la figure 2 :

L'utilisation de DTLS 1.0 sur UDP est spécifiée dans [RFC4347].
L'utilisation de DTLS 1.2 sur UDP est spécifiée dans [RFC6347].
L'utilisation de DTLS 1.3 sur UDP est spécifiée dans le document à venir [TLS-DTLS13].
L'utilisation de SCTP sur DTLS est spécifiée dans [RFC8261].

Notez que le démultiplexage de STUN (Session Traversal Utilities for NAT, utilitaires de traversée de session pour NAT) [RFC5389] avec SRTP et DTLS est effectué comme décrit à la section 5.1.2 de [RFC5764], et que SCTP est la seule charge utile de DTLS.

Étant donné que DTLS est généralement implémenté dans l'espace utilisateur de l'application, la pile de protocoles SCTP doit également être une pile de protocoles en espace utilisateur.

La couche ICE/UDP peut gérer les changements d'adresse IP pendant une session sans interaction avec les couches DTLS et SCTP. Cependant, lorsqu'un changement d'adresse se produit, SCTP DEVRAIT (SHOULD) en être informé. Dans ce cas, SCTP DEVRAIT (SHOULD) re-tester le MTU de chemin et réinitialiser l'état de congestion à son état initial. Dans le cas d'un contrôle de congestion basé sur une fenêtre (tel que spécifié dans [RFC4960]), cela signifie réinitialiser la fenêtre de congestion et le seuil de démarrage lent à leurs valeurs initiales.

Les messages ICMP ou ICMPv6 entrants ne peuvent pas être traités par la couche SCTP, car l'association correspondante ne peut pas être identifiée. Par conséquent, SCTP DOIT (MUST) prendre en charge la découverte du MTU de chemin sans dépendre d'ICMP ou d'ICMPv6, comme décrit dans [RFC4821], en utilisant les messages de sondage spécifiés dans [RFC4820]. Le MTU de chemin initial au niveau de la couche IP NE DEVRAIT PAS (SHOULD NOT) dépasser 1200 octets pour IPv4 et NE DEVRAIT PAS (SHOULD NOT) dépasser 1280 octets pour IPv6.

En général, l'interface de couche inférieure des implémentations SCTP devrait s'adapter aux différences entre IPv4 et IPv6 (sans connexion) ou DTLS (orienté connexion).

Lors de l'utilisation de la pile de protocoles illustrée à la figure 2, DTLS protège le paquet SCTP complet, fournissant ainsi la confidentialité, l'intégrité et l'authentification de la source pour le paquet SCTP complet.

SCTP fournit un contrôle de congestion par association. Cela signifie que tous les flux SCTP au sein d'une seule association SCTP partagent la même fenêtre de congestion. Le trafic non envoyé via SCTP n'est pas couvert par le contrôle de congestion SCTP. L'utilisation d'un contrôle de congestion différent du standard peut améliorer l'impact sur les flux de médias SRTP parallèles.

SCTP utilise le même concept de numéros de port que TCP et UDP. Par conséquent, une association SCTP utilise deux numéros de port, un pour chaque point de terminaison SCTP.