Entête STUN
par Sébastien FONTAINE (_SebF)
1 - Définition du
protocole
2 - Structure de l'entête
3 - Définition des différents champs
3.1 - Type
3.2 - Longueur
3.3 -
Cookie magique
3.4 -
ID de la transaction
4 - Discussion autour de la
documentation
5 - Suivi du document
Le protocole STUN à été crée en mars
2003 par la RCF 3489 avec la définition "Simple Traversal of UDP throught NAT".
Depuis Octobre 2008, le protocole STUN a été redéfinit par la
RFC 5389 avec la
définition "Session Traversal Utilities for NAT". Le protocole STUN permet
aux applications multimédia de type data, voix, vidéo de traverser les routeurs
et les Firewalls paramétrés avec de la
Translation d'adresses (NAT). Voici un exemple concret d'intérêt et
d'utilisation du protocole STUN :
Le téléphone référencé en CLT A est
client de son IPBX C en transitant un flux VoIP pour la signalisation (tel que
SIP) et un flux pour le transport de la voix (tel que RTP). Dans ce contexte, la
problématique est que le téléphone doit être translaté par le Firewall afin de
disposer d'une adresse IP publique. Dans ce cas de figure, cela perturbe le
protocole SIP qui doit connaitre, en tant que client, son adresse publique.
Pour résoudre cette problématique, le serveur STUN SRV B indiquera en réponse au
client CLT A son adresse IP publique, le type de NAT appliqué et les ports
translatés. Ainsi, l'application multimédia client SIP peut intégrer dans son
échange SIP et RTP l'adresse IP publique au lieu de l'adresse privée.
Le protocole STUN fonctionne par défaut sur le
port UDP 3478.
Voici la structure de l'entête STUN basé
sur 20 octets.
Voici une analyse de trame montrant un échange de requête et réponse du
protocole STUN V1.
Le champ Type est codé sur 16 bits et
détermine la nature du message STUN. Il se décompose en 3 parties distinctes qui
sont : "distinction protocole", "Classe" et "Méthode".
3.1.1 - Distinction protocole
Le champ Distinction protocole est codé
sur 2 bits et doit être égale à 0. Cette valeur permet de différentier les
datagrammes STUN des autres protocoles qui utilise le même port UDP 3478.
3.1.2 - Classe
Le champ Classe est codé sur 2 bits et
définit le type du message STUN par l'une des quatre possibilités suivante :
- 00 - Message de type : Requête
- 01 - Message de type : Indication
- 10 - Message de type : Réponse indiquant un succès
- 11 - Message de type : Réponse indiquant une erreur
Voici la liste des erreurs possibles :
- 300 - Essayer un un autre serveur.
- 400 - Mauvaise requête (La requête du client est malformée).
- 401 - Non autorisée (La requête ne contient pas les autorisation nécessaire).
- 420 - Attribue inconnu.
- 438 - Longueur du NONCE invalide (Le client doit réessayer en utilisant le
NONCE fournit dans la réponse afin d'éviter le rejeu).
- 500 - Erreur du serveur (Le client essayer plus tard).
3.1.3 - Méthode
Le champ Méthode est codé sur 12 bits et
spécifie la méthode utilisé dans ce message STUN. Les première méthode du
protocole STUN sont :
- 000 - Reservé
- 001 - Binding
- 002 - Reserved
Les méthodes du protocole STUN comprises entre 000 et 7FF sont assignés par l'IETF.
Alors que les méthodes comprises entre 800 et FFF sont assigné par Designated
Expert (RFC 5226).
Le champ Longueur est codé sur 16 bits
et spécifie la taille du message. La valeur du champ Longueur doit être spécifié en
octet et indiquer la longueur du message sans compter les 20 octets de sa propre
entête.
Le champ Cookie magique est codé sur 32
bits et doit contenir la valeur fixe 0x2112A442 (dans la RFC 3489, ce domaine
faisait partie de l'ID de transaction). L'ajout de la valeur fixe à cet endroit
permet principalement de distinguer les datagrammes STUN des autres protocoles
utilisant le même port 3478.
Le champ ID de la transaction est codé
sur 96 bits et permet d'identifier une transaction STUN. Le client choisit un ID
aléatoire pour la requête que le serveur doit répéter lors de sa réponse.
Vous pouvez poser toutes vos questions,
vos remarques et vos expériences à propos du protocole STUN. Pour cela,
rendez-vous sur le Forum
"ToIP - VoIP".
Le 01 mars 2009, par _SebF, création du document.
|