Aller au contenu principal

3. Transport and Middlebox Specification (Spécification du transport et des boîtes intermédiaires)

Cette section définit les protocoles de transport et les fonctions de gestion des boîtes intermédiaires que les points de terminaison WebRTC doivent prendre en charge.

3.1. System-Provided Interfaces (Interfaces fournies par le système)​

Les spécifications de protocole utilisées ici supposent que les protocoles suivants sont disponibles pour les implémentations des protocoles WebRTC :

UDP [RFC0768] : C'est le protocole supposé par la plupart des éléments de protocole décrits.

TCP [RFC0793] : Il est utilisé pour HTTP/WebSockets, ainsi que pour TURN/TLS et ICE-TCP.

Pour les deux protocoles, le support IPv4 et IPv6 est supposé.

Pour UDP, cette spécification suppose la capacité de définir le point de code de services différenciés (Differentiated Services Code Point, DSCP) des sockets ouverts sur une base par paquet, afin d'atteindre les priorités décrites dans [RFC8837] (voir la section 4.2 de ce document) lorsque plusieurs types de médias sont multiplexés. Elle ne suppose pas que les DSCP seront honorés et suppose qu'ils peuvent être remis à zéro ou modifiés, car il s'agit d'un problème de configuration locale.

Les plateformes qui ne donnent pas accès à ces interfaces ne pourront pas prendre en charge un point de terminaison WebRTC conforme.

Cette spécification ne suppose pas que l'implémentation aura accès à ICMP ou à l'IP brut.

Les protocoles suivants peuvent être utilisés, mais ils peuvent être implémentés par un point de terminaison WebRTC et ne sont donc pas définis comme des « interfaces fournies par le système » :

  • TURN : Traversal Using Relays Around NAT [RFC8656]
  • STUN : Session Traversal Utilities for NAT [RFC5389]
  • ICE : Interactive Connectivity Establishment [RFC8445]
  • TLS : Transport Layer Security [RFC8446]
  • DTLS : Datagram Transport Layer Security [RFC6347]

3.2. Ability to Use IPv4 and IPv6 (Capacité à utiliser IPv4 et IPv6)​

Les applications Web s'exécutant dans un navigateur WebRTC doivent (MUST) pouvoir utiliser à la fois IPv4 et IPv6 lorsqu'ils sont disponibles -- c'est-à-dire que lorsque deux pairs n'ont qu'une connectivité IPv4 l'un avec l'autre, ou qu'ils n'ont qu'une connectivité IPv6 l'un avec l'autre, les applications s'exécutant dans le navigateur WebRTC doivent (MUST) pouvoir communiquer.

Lorsque TURN est utilisé et que le serveur TURN a une connectivité IPv4 ou IPv6 vers le pair ou le serveur TURN du pair, les candidats des types appropriés doivent (MUST) être pris en charge. La spécification « Happy Eyeballs » pour ICE [RFC8421] devrait (SHOULD) être prise en charge.

3.3. Usage of Temporary IPv6 Addresses (Utilisation des adresses IPv6 temporaires)​

La spécification de sélection d'adresse par défaut IPv6 [RFC6724] spécifie que les adresses temporaires [RFC4941] doivent être préférées aux adresses permanentes. Il s'agit d'un changement par rapport aux règles spécifiées par [RFC3484]. Pour les applications qui sélectionnent une seule adresse, cela se fait généralement par le drapeau de préférence IPV6_PREFER_SRC_TMP spécifié dans [RFC5014]. Cependant, cette règle, qui vise à garantir que les adresses améliorant la confidentialité sont utilisées de préférence aux adresses statiques, n'a pas le bon effet dans ICE, où toutes les adresses sont collectées et donc révélées à l'application. Par conséquent, la règle suivante est appliquée à la place :

Lorsqu'un point de terminaison WebRTC collecte toutes les adresses IPv6 sur son hôte et que des adresses temporaires non obsolètes et des adresses permanentes de même portée sont présentes, le point de terminaison WebRTC devrait (SHOULD) rejeter les adresses permanentes avant d'exposer les adresses à l'application ou de les utiliser dans ICE. Ceci est cohérent avec la politique par défaut décrite dans [RFC6724].

Si certaines, mais pas toutes, des adresses IPv6 temporaires sont marquées comme obsolètes, le point de terminaison WebRTC devrait (SHOULD) rejeter les adresses obsolètes, sauf si elles sont utilisées par une connexion en cours. Dans un redémarrage ICE, les adresses obsolètes actuellement utilisées peuvent (MAY) être conservées.

Le mécanisme principal pour traiter les boîtes intermédiaires est ICE, qui est un moyen approprié de traiter les boîtes NAT et les pare-feu qui acceptent le trafic de l'intérieur, mais seulement de l'extérieur s'il s'agit d'une réponse au trafic intérieur (pare-feu à état simple).

ICE [RFC8445] doit (MUST) être pris en charge. L'implémentation doit (MUST) être une implémentation ICE complète, et non ICE-Lite. Une implémentation ICE complète permet l'interopérabilité avec les implémentations ICE et ICE-Lite lorsqu'elles sont déployées de manière appropriée.

Afin de traiter les situations où les deux parties sont derrière des NAT du type qui effectuent un mappage dépendant du point de terminaison (tel que défini dans [RFC5128], section 2.4), TURN [RFC8656] doit (MUST) être pris en charge.

Les navigateurs WebRTC doivent (MUST) prendre en charge la configuration des serveurs STUN et TURN, à partir de la configuration du navigateur et d'une application.

Notez qu'il existe d'autres travaux autour de la découverte et de la gestion des serveurs STUN et TURN, y compris [RFC8155] pour la découverte de serveurs, ainsi que [RETURN].

Afin de traiter les pare-feu qui bloquent tout le trafic UDP, le mode TURN qui utilise TCP entre le point de terminaison WebRTC et le serveur TURN doit (MUST) être pris en charge, et le mode TURN qui utilise TLS sur TCP entre le point de terminaison WebRTC et le serveur TURN doit (MUST) être pris en charge. Voir la section 3.1 de [RFC8656] pour plus de détails.

Afin de traiter les situations où une partie est sur un réseau IPv4 et l'autre partie est sur un réseau IPv6, les extensions TURN pour IPv6 doivent (MUST) être prises en charge.

Les candidats TURN TCP, où la connexion du serveur TURN du point de terminaison WebRTC au pair est une connexion TCP, [RFC6062] peuvent (MAY) être pris en charge.

Cependant, ces candidats ne sont pas considérés comme offrant un avantage significatif, pour les raisons suivantes.

Premièrement, l'utilisation de candidats TURN TCP ne serait pertinente que dans les cas où les deux pairs sont tenus d'utiliser TCP pour établir une connexion.

Deuxièmement, ce cas d'utilisation est pris en charge d'une manière différente par les deux côtés établissant des candidats de relais UDP en utilisant TURN sur TCP pour se connecter à leurs serveurs de relais respectifs.

Troisièmement, l'utilisation de TCP entre le serveur TURN du point de terminaison WebRTC et le pair peut entraîner plus de problèmes de performances que l'utilisation d'UDP, par exemple en raison du blocage en tête de ligne (Head of Line Blocking).

Les candidats ICE-TCP [RFC6544] doivent (MUST) être pris en charge ; cela peut permettre aux applications de communiquer avec des pairs ayant des adresses IP publiques à travers des pare-feu bloquant UDP sans utiliser de serveur TURN.

Si des connexions TCP sont utilisées, le cadrage RTP selon [RFC4571] doit (MUST) être utilisé pour tous les paquets. Cela inclut les paquets RTP, les paquets DTLS utilisés pour transporter les canaux de données et les paquets de vérification de connectivité STUN.

Le mécanisme ALTERNATE-SERVER spécifié dans la section 11 de [RFC5389] (300 Try Alternate) doit (MUST) être pris en charge.

Le point de terminaison WebRTC peut (MAY) prendre en charge l'accès à Internet via un proxy HTTP. S'il le fait, il doit (MUST) inclure l'en-tête « ALPN » tel que spécifié dans [RFC7639], et l'authentification proxy telle que décrite dans la section 4.3.6 de [RFC7231] et [RFC7235] doit (MUST) également être prise en charge.

3.5. Transport Protocols Implemented (Protocoles de transport implémentés)​

Pour le transport des médias, le RTP sécurisé est utilisé. Les détails du profil RTP utilisé sont décrits dans « Media Transport and Use of RTP in WebRTC » [RFC8834], qui impose l'utilisation d'un disjoncteur (Circuit Breaker) [RFC8083] et d'un contrôle de congestion (voir [RFC8836] pour plus d'informations).

L'échange de clés doit (MUST) être effectué en utilisant DTLS-SRTP, comme décrit dans [RFC8827].

Pour le transport de données sur le canal de données WebRTC [RFC8831], les points de terminaison WebRTC doivent (MUST) prendre en charge SCTP sur DTLS sur ICE. Cette encapsulation est spécifiée dans [RFC8261]. La négociation de ce transport dans le protocole de description de session (Session Description Protocol, SDP) est définie dans [RFC8841]. L'extension SCTP pour I-DATA [RFC8260] doit (MUST) être prise en charge.

Le protocole de configuration pour les canaux de données WebRTC décrit dans [RFC8832] doit (MUST) être pris en charge.

Note : L'interaction entre DTLS-SRTP tel que défini dans [RFC5764] et ICE tel que défini dans [RFC8445] est décrite dans la section 6 de [RFC8842]. L'effet de cette spécification est que toutes les paires de candidats ICE associées à un seul composant font partie de la même association DTLS. Ainsi, il n'y aura qu'une seule poignée de main DTLS, même s'il existe plusieurs paires de candidats valides.

Les points de terminaison WebRTC doivent (MUST) prendre en charge le multiplexage de DTLS et RTP sur la même paire de ports, comme décrit dans la spécification DTLS-SRTP [RFC5764], section 5.1.2, avec des clarifications dans [RFC7983]. Toutes les charges utiles de protocole de couche application sur cette connexion DTLS sont des paquets SCTP.

L'identification du protocole doit (MUST) être fournie dans le cadre de la poignée de main DTLS, comme spécifié dans [RFC8833].

Dernière mise à jour le