RFC 8835 - Transports for WebRTC

Statut: Proposed Standard
Publié: January 2021
Stream: IETF
Errata: Pas d'errata

Informations de Base

Numéro RFC: 8835
Titre: Transports for WebRTC
Titre Français: Transports pour WebRTC
Date de Publication: Janvier 2021
Statut: PROPOSED STANDARD (Standard Proposé)
Auteur: H. Alvestrand (Google)

Résumé (Abstract)

Cette spécification décrit la pile de protocoles de transport utilisée par WebRTC, incluant les composants principaux ICE, DTLS et SRTP. WebRTC transmet les médias et les données via UDP, utilise ICE pour la traversée NAT, DTLS pour établir des connexions sécurisées et SRTP pour chiffrer les flux médias.

Aperçu de la Pile de Transport WebRTC

Pile de Protocoles Complète

Pile de Protocoles WebRTC (de haut en bas):

┌─────────────────────────────────────────┐
│   Couche Application (Application)       │
│   - Flux Audio/Vidéo                     │
│   - Canaux de Données (DataChannel)      │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   RTP/RTCP (Protocole de Transport      │
│             Temps Réel)                  │
│   - Transmission Média                   │
│   - Informations de Contrôle             │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   SRTP/SRTCP (RTP Sécurisé)            │
│   - Flux Média Chiffrés                  │
│   - Authentification                     │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   DTLS (TLS pour Datagrammes)           │
│   - Négociation des Clés                │
│   - Chiffrement de Bout en Bout          │
│   - Vérification des Certificats         │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   ICE (Établissement de Connectivité    │
│        Interactive)                      │
│   - Traversée NAT                        │
│   - Collecte des Candidats               │
│   - Vérifications de Connectivité        │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   UDP (User Datagram Protocol)          │
│   - Transport de Base                    │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   IP (Internet Protocol)                │
│   - IPv4 / IPv6                          │
└─────────────────────────────────────────┘

Pile Supplémentaire pour Canaux de Données:

┌─────────────────────────────────────────┐
│   DataChannel API                       │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   SCTP (Stream Control Transmission     │
│          Protocol)                       │
│   - Transmission Fiable                  │
│   - Frontières de Messages               │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│   DTLS                                  │
└─────────────────────────────────────────┘
              ↓
         (ICE + UDP + IP)

Pourquoi UDP?

UDP vs TCP pour WebRTC:

Problèmes TCP:
❌ Blocage de Tête de File (Head-of-Line Blocking)
   - Une perte de paquet bloque tout le flux
   - Inacceptable pour audio/vidéo en temps réel

❌ Établissement de Connexion Lent
   - Délai du Three-Way Handshake
   - Délai du Handshake TLS

❌ Contrôle de Congestion Inflexible
   - Algorithme Fixe
   - Pas d'optimisation pour médias temps réel

Avantages UDP:
✓ Pas de Blocage de Tête de File
   - Paquets indépendants
   - Perte de paquet n'affecte pas les paquets suivants

✓ Faible Latence
   - Pas d'attente d'accusé de réception
   - Envoi immédiat

✓ Contrôle Flexible
   - Contrôle de congestion au niveau application
   - Optimisé pour les médias

Choix WebRTC:
UDP + Fiabilité au niveau application
→ Médias avec SRTP (non fiable)
→ Données avec SCTP (fiabilité optionnelle)

ICE (Interactive Connectivity Establishment)

Rôle d'ICE

Problème: Traversée NAT

Scénario:
Utilisateur A (192.168.1.100) ← NAT1 ← Internet → NAT2 → Utilisateur B (192.168.1.200)
         IP Privée                                        IP Privée

Problème:
- A ne sait pas comment atteindre l'IP privée de B
- B ne sait pas comment atteindre l'IP privée de A
- NAT bloque les connexions externes

Solution ICE:
1. Collecter les Candidats (Candidates)
   - Candidat Host: IP locale
   - Candidat Server Reflexive: IP publique NAT (via STUN)
   - Candidat Relay: Adresse relais (via TURN)

2. Échanger les Candidats (via signalisation)

3. Vérifications de Connectivité (Connectivity Checks)
   - Tester toutes les paires de candidats
   - Trouver le meilleur chemin

4. Établir la Connexion

Types de Candidats

// Candidat Host (adresse locale)
{
  type: 'host',
  ip: '192.168.1.100',
  port: 54321,
  protocol: 'udp',
  priority: 2130706431,
  foundation: '1',
  component: 1
}

// Candidat Server Reflexive (adresse publique obtenue via STUN)
{
  type: 'srflx',
  ip: '203.0.113.1',      // IP Publique
  port: 12345,            // Port mappé par NAT
  protocol: 'udp',
  priority: 1694498815,
  foundation: '2',
  relatedAddress: '192.168.1.100',  // IP Locale
  relatedPort: 54321
}

// Candidat Relay (adresse relais TURN)
{
  type: 'relay',
  ip: '198.51.100.1',     // IP du serveur TURN
  port: 3478,
  protocol: 'udp',
  priority: 16777215,
  foundation: '3',
  relatedAddress: '203.0.113.1',
  relatedPort: 12345
}

Ordre de Priorité:
Host > Server Reflexive > Relay
(Connexion directe préférée, relais en dernier recours)

DTLS (Datagram Transport Layer Security)

Rôle de DTLS

Pourquoi DTLS est nécessaire:

Problème:
- UDP n'est pas sécurisé
- Les flux médias RTP doivent être chiffrés
- Négociation de clés nécessaire

Solution DTLS:
✓ Établir une connexion sécurisée
✓ Négocier les clés de chiffrement
✓ Authentifier la partie distante
✓ Protection d'intégrité

DTLS vs TLS:
TLS (basé sur TCP):
- Transport fiable
- Livraison ordonnée
- Transport en flux

DTLS (basé sur UDP):
- Transport non fiable
- Possiblement désordonné
- Transport en datagramme
→ Nécessite un traitement supplémentaire des pertes et du réordonnancement

Version DTLS:
WebRTC exige: DTLS 1.2 ou supérieur
Recommandé: DTLS 1.3

SRTP (Secure RTP)

Chiffrement SRTP

SRTP = RTP + Chiffrement + Authentification

Structure de Paquet RTP:
┌──────────────────────────────────────┐
│ En-tête RTP (12+ octets)             │
│ - V, P, X, CC, M, PT, Seq, TS, SSRC │
├──────────────────────────────────────┤
│ Charge Utile RTP (données média)     │
│ - Échantillons audio ou trames vidéo │
└──────────────────────────────────────┘

Structure de Paquet SRTP:
┌──────────────────────────────────────┐
│ En-tête RTP (texte clair)            │
├──────────────────────────────────────┤
│ Charge Utile Chiffrée (chiffrée)     │
│ - Données média chiffrées             │
├──────────────────────────────────────┤
│ Étiquette d'Authentification         │
│ - HMAC-SHA1 ou autre                 │
└──────────────────────────────────────┘

Contenu Chiffré:
✓ Charge utile RTP (données média)
✗ En-tête RTP (non chiffré - pour routage)

Contenu Authentifié:
✓ En-tête RTP + charge utile chiffrée

Canaux de Données (DataChannel)

SCTP sur DTLS sur UDP

Pile de Protocoles des Canaux de Données:

Couche Application: DataChannel API
  ↓
Couche Transport: SCTP (Stream Control Transmission Protocol)
  ↓
Couche Sécurité: DTLS
  ↓
Couche Réseau: ICE + UDP + IP

Pourquoi SCTP?
✓ Préserver les frontières de messages (pas comme flux TCP)
✓ Fiabilité optionnelle (retransmission configurable)
✓ Ordre optionnel (tri configurable)
✓ Support multi-flux (plusieurs flux sur une connexion)
✓ Contrôle de congestion

Fonctionnalités SCTP:
1. Fiable/Non fiable optionnel
2. Ordonné/Désordonné optionnel
3. Frontières de messages
4. Multiplexage

Résumé

Points Clés

✓ WebRTC utilise le transport UDP
✓ ICE gère la traversée NAT
✓ DTLS fournit le chiffrement
✓ SRTP protège les médias
✓ SCTP supporte les canaux de données

Pile de Transport:
Application → RTP/SCTP → SRTP/DTLS → ICE → UDP → IP

Types de Candidats:
Host > Server Reflexive > Relay

Chiffrement:
DTLS négocie les clés → SRTP chiffre les médias

Canaux de Données:
Fiable/Non fiable configurable
Ordonné/Désordonné configurable

Contrôle de Congestion:
Algorithme GCC
Sondage de bande passante
Adaptation de débit

Références

RFCs Connexes:

[RFC 8835] Transports for WebRTC ← Ce document
[RFC 8445] ICE
[RFC 6347] DTLS 1.2
[RFC 3711] SRTP
[RFC 4960] SCTP
[RFC 8831] WebRTC Data Channels

Résumé: La pile de transport WebRTC construit une infrastructure de communication temps réel sécurisée et efficace sur UDP non fiable grâce à la combinaison sophistiquée d'ICE, DTLS et SRTP. Comprendre ces protocoles de couche transport est la clé pour maîtriser WebRTC!

Informations de Base​

Résumé (Abstract)​

Aperçu de la Pile de Transport WebRTC​

Pile de Protocoles Complète​

Pourquoi UDP?​

ICE (Interactive Connectivity Establishment)​

Rôle d'ICE​

Types de Candidats​

DTLS (Datagram Transport Layer Security)​

Rôle de DTLS​

SRTP (Secure RTP)​

Chiffrement SRTP​

Canaux de Données (DataChannel)​

SCTP sur DTLS sur UDP​

Résumé​

Points Clés​

Références​