Les protocoles STUN et TURN

Le protocole STUN

STUN est l’acronyme de deux protocoles successifs :
- le premier STUN, "Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", fut spécifié en 2003 par la RFC 3489. Ce premier STUN est parfois appelé "STUN classique";
- le second STUN, "Session Traversal Utilities for NAT" est spécifié en 2008 par la RFC 5389, qui a rendu obsolète la RFC 3489.
L’acronyme STUN a été volontairement conservé à l’identique, et les "serveurs STUN" actuels mettent en œuvre la RFC 5389.

Il s’agit en fait d’une évolution, l’objectif restant, en gros, le même.

Pour établir une session de communication utilisant ici, par hypothèse, les protocoles RTP ("Real-Time Transport Protocol") et RTCP ("Real-Time Transport Control Protocol"), chacun des postes concernés doit connaître, pour chaque type de flux constituant cette communication :
- une adresse IP et un port de communication auxquels on peut lui adresser ce flux (selon le protocole RTP),
- une adresse IP (généralement la même) et un port de communication (différent) auxquels on peut lui adresser le flux de contrôle correspondant (selon le protocole RTCP).
Pour chacun de ces postes, la découverte de ces couples adresse/port revient à connaître le détail de NAT dynamiques mises en œuvre par des connexions initiées par ce poste, de l’intérieur du réseau local qui l’héberge, vers l’extérieur. Les flux RTP et RTCP envoyés par l’autre poste pourront alors utiliser "à l’envers" ces NAT dynamiques.
Pour ce faire, chaque poste concerné utilise un serveur STUN. Les adresses des serveurs STUN peuvent être obtenues par des requêtes DNS (enregistrements SRV _stun).

Le principe du protocole STUN est le suivant :
- par hypothèse, le "client STUN" se situe dans un réseau local, derrière un routeur mettant en œuvre des NAT dynamiques.
- ce client envoie une requête au serveur STUN. Dans les en-têtes de cette requête, le routeur a donc substitué une adresse IP publique du réseau local à l’adresse locale de ce client, et généralement a changé aussi le port.
- dans le corps de sa réponse, le serveur STUN recopie ces informations pour qu’elles parviennent intactes au client : en recevant cette réponse, le routeur n’en modifie à nouveau que les en-têtes, en y remettant l’adresse locale du client et son port utilisé.
- le client initiateur de cette requête reçoit donc en réponse un message dont le contenu lui décrit la NAT mise en œuvre par son routeur.
Ce poste est alors en mesure de faire connaître à quelles adresses IP et sur quels ports de communication on peut lui envoyer des flux RTP et RTCP.

L’information apportée par le serveur STUN est généralement appelée "adresse réflexive". Elle se trouve dans un champ appelé "XOR-MAPPED-ADDRESS". En fait, l’adresse et le port publics qui s’y trouvent ne sont pas transmis "en clair", mais sont légèrement obscurcis par application d’un "ou exclusif"  (aussi appelé "eXclusive OR", d’où le "XOR") :
- l’adresse IP est ainsi combinée avec la chaîne "2112A442" (ici en ASCII), appelée "magic cookie",
- le port avec "2112".
Cette opération permet d’empêcher l’action de dispositifs de type AGL ("Application Level Gateways") ou SBC ("Session Border Controllers"), éventuellement installés, et qui risqueraient alors de modifier toute adresse ou port figurant "en clair" dans un message les traversant.

Cette évolution du protocole STUN entre 2003 et 2008 vise plusieurs améliorations, décrites en détail dans la RFC 5389. Pour l’essentiel :
- il existe plusieurs types de NAT (voir billets précédents) et le "STUN classique" peine parfois à déterminer lequel il s’agit,
- surtout, il arrive au "STUN classique" d"échouer à remplir sa mission. Et il ne fournit alors aucun moyen de remédier à cet échec;
- de plus, le "STUN classique" est sujet à certaines attaques. Ce risque ne disparaît pas avec les nouvelles spécifications, mais est par ailleurs atténué du fait que le protocole STUN, maintenant, est mis en œuvre au sein de solutions plus vastes et plus complètes;
- enfin, le protocole STUN prend maintenant en charge aussi TCP (et même TLS-over-TCP), en plus que UDP.

Dans la pratique, une différence importante est que le protocole STUN, maintenant, n’ambitionne plus d’être la solution au problème exposé ci-dessus, mais un essai de solution, essai qui peut échouer pour un certain type de NAT (voir ci-dessous). Il en résulte que des solutions plus complètes prévoient maintenant, en cas d’échec du STUN, de recourir à d’autres méthodes, par exemple utiliser un serveur TURN : c’est ce que préconise le protocole ICE, abordé dans le dernier billet de ce groupe de billets.

 

Le protocole TURN

Cet protocole permet à un serveur TURN de jouer un rôle de proxy.
En effet, lorsqu’une NAT dynamique impose des restrictions sur l’adresse et éventuellement le port de destination (voir billets précédents), il ne sert à rien qu’un serveur STUN informe le poste local du détail de cette NAT mise en œuvre par son routeur : cette NAT n’acceptera comme destination (et donc, en fonctionnant "à l’envers", comme source) que ce serveur STUN, et pas un autre poste devant participer à la communication concernée.
La solution est donc que la communication passe par ce serveur. Pour ce faire, ce serveur doit supporter le protocole TURN, qui est considéré comme une extension du protocole STUN, et qui est décrit dans la RFC 5766, d’avril 2010.
Les adresses des serveurs TURN peuvent être obtenues par des requêtes DNS (enregistrements SRV _turn).

La procédure est la suivante :
- un poste A derrière un routeur mettant en œuvre une telle NAT, et devant communiquer avec un poste B, se connecte donc à un serveur TURN;
- cette connexion TURN créée une NAT dynamique dans le routeur du réseau du poste A, que le poste A aura pour charge de laisser active, en entretenant cette connexion;
- ce serveur TURN pourra alors utiliser "à l’envers" cette NAT dynamique, en servant ainsi de proxy pour les flux de communication qui doivent parvenir au poste A;
- le poste A devra informer le poste B de l’usage de ce proxy : le serveur TURN communique donc au poste A son adresse IP et son port de relais.
Ces dernières informations sont généralement appelée "adresse relayée". Elles sont transmises au poste A d’une façon similaire au cas d’une réponse selon le protocole STUN, aux différences suivantes :
- le champ transportant ces informations s’appelle ici "XOR-RELAYED-ADDRESS" (mêmes opérations XOR, avec le même magic cookie),
- et bien sûr, il ne s’agit plus de l’adresse IP et du port translatés à la sortie du routeur du poste A, mais de l’adresse IP et du port publics de ce serveur TURN.

Dans la pratique, un serveur TURN met aussi en œuvre le protocole STUN (l’inverse n’est pas vrai).
De sorte qu’en s’adressant à un serveur TURN, le poste A obtiendra à la fois l’adresse "réflexive" et l’adresse "relayée".

Par ailleurs, puisqu’un serveur TURN est destiné à relayer des flux de communication, notamment des flux vidéo, il faut envisager qu’il ait à supporter une charge significative, justifiant que son accès soit protégé par une authentification. Le poste A aura alors, dans sa requête au serveur TURN, à lui indiquer par exemple l’adresse et le port du poste B, futur utilisateur de ce relais (d’autres méthodes d’authentification sont ici utilisables).

 

 

WebRTC et les NAT
Les NAT dynamiques et les NAT statiques
La signalisation SIP et les NAT
Le protocole SDP
Les protocoles STUN et TURN
Le protocole ICE