1 – Définition du protocole STUN

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, ce protocole 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 :

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.

2 – Structure de l’entête STUN

Voici la structure de l’entête basé sur 20 octets.

Voici une analyse de trame montrant un échange de entete-stun capture wireshark stun version 1.

3 – Définition des différents champs

3.1 – Type

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 sont :

• 000 – Reservé
• 001 – Binding
• 002 – Reserved

Les méthodes du protocole 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).

3.2 – Longueur

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.

3.3 – Cookie magique

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.

3.4 – ID de la transaction

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.

4 – Les vidéos

• 4.1 - NAT Traversal guaranteed connectivity

  Guaranteed VoIP call completion as performed by Eyeball Networks AnyFirewall Engine, and AnyFirewall Server.

• 4.2 - Why VOIP has one way audio, and how to fix it.

  Is your VOIP device experiencing audio issues? This video explains why it happens and how to fix it.

  

• 4.3 - NAT Traversal & RTSP

  Cette vidéo en anglais présente ce qu'est et comment fonctionne la NAT transversal et le RTSP via le protocole STUN (Simple Traversal of UDP through NATs).

  

• 4.4 - What is STUN TURN and ICE ?

  So this is where STUN, TURN and ICE come in handy. ICE stands for Interactive Connectivity Establishment - and it's a overarching technique that utilizes STUN and TURN.

  

• 4.5 - STUN for accessible to the Public Internet

  Particularly with VoIP software, you may see STUN as an option for keeping your line of communication open. This video explains what STUN is, how it works, and if you can configure it.

  

5 – Suivi du document

Création et suivi de la documentation par _SebF

6 – Discussion autour du protocole STUN

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos du protocole STUN. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :