Dans cet article, nous discutions des méthodes permettant la traversée de NAT des messages SIP, tant pour les réponses que les requêtes. Nous avons mentionné une méthode permettant de maintenir les différentes associations au niveau du NAT valides en utilisant le protocole STUN. Toutefois, qu’est-ce que STUN et comment fonctionne-t-il ?
STUN fut une des premières tentatives permettant de résoudre le problème de la traversée de NAT. Connue à l’origine sous le nom Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs), l’évolution des techniques et de son utilité générale l’ont amené à être renommé sous le terme utilisé aujourd’hui : Session Traversal Utilities for NAT. Lors de sa spécification initiale, STUN avait été imaginé en tant que solution standalone, fonctionnant en tant que telle sur le réseau, et apportant à elle seule une solution valable au problème de NAT rencontré en UDP. Toutefois, l’usage de ce qu’il convient d’appeler aujourd’hui le STUN classique (classic STUN) a prouvé que, s’il était en mesure de résoudre dans certains cas les problèmes relatifs au NAT, il ne permettait pas d’apporter une certitude quant au fait que les informations apprises par son biais allait permettre, quelle que soit la situation, d’effectivement transmettre des informations à une destination et d’en recevoir les réponses.
Cette nouvelle spécification se repose sur les mêmes bases, que nous allons détailler, mais propose une approche quelque peu différente. En effet, au lieu de proposer STUN comme une solution à part entière, le protocole a cette fois-ci été pensé dans l’optique de pouvoir être intégré à d’autres mécanismes, tout en pouvant être facilement adapté, via des extensions, à de nouveaux usages et situations. Ce protocole se repose sur des échanges client/serveur classiques : le client émet une requête à destination du serveur, qui lui répondra en conséquence. Quel est le but de cet échange ?
Fonctionnement général
Lors de l’introduction à l’article sur la traversée de NAT en SIP, nous avions discuté le problème des informations contenues au sein des messages SIP, tant au niveau de SIP lui-même que du corps du message (SDP) contenant les informations nécessaires (notamment l’adresse IP et le port) à l’établissement des connexions multimédias. Les mécanismes introduits par STUN permettent aux clients de récupérer et de modifier dynamiquement les informations qu’ils insèrent dans les messages SIP (entêtes SIP, mais surtout corps SDP) en fonction de la réponse fournie par le serveur : l’adresse publique d’où provient la requête du client.
La représentation ci-dessus décrit le fonctionnement type de STUN, dans une infrastructure complexe (NAT en cascades). Le fait que le serveur STUN soit impérativement situé sur le réseau publique permet un fonctionnement idéal (l’adresse et port publiquement accessibles sont récupérés), et ce malgré l’étrangeté de l’environnement. Le protocole définit un formatage très précis des requêtes binding et de leurs réponses, permettant notamment de distinguer les messages STUN d’autres protocoles. Il n’est pas nécessaire de connaître le détail de ce formatage, mais attardons-nous plutôt sur un point intéressant : la réponse fournie par le serveur.
Il convient de noter que Classic STUN définissait une réponse MAPPED-ADDRESS, contenant, en plain text, le couple adresse/port public du client. Cet usage a cependant été mis à ma avec l’introduction d’autres méthodes de traversées de NAT au niveau des NAT eux-mêmes (ALG/SBC, dont nous discuterons prochainement), ceux-ci modifiant parfois indifféremment toutes les adresses IP et tous les ports rencontrés au sein d’une requête les traversant. STUN, dans sa version révisée, offre un mécanisme supplémentaire permettant d’outrepasser cette limitation. Il propose en effet, en plus de l’attribut MAPPED-ADDRESS un attribut XOR-MAPPED-ADDRESS. Un « ou exclusif » (eXclusive OR) est appliqué entre le premier attribut et un magic cookie (dont la valeur hexadécimale est 2112A442) résultant sur le second. Le NAT ne connaissant plus l’adresse contenue dans l’attribut, son ALG ne la modifiera pas. Par exemple :
123.4.56.78 -> 01111011 00000100 00111000 01001110
0x2112A442-> 00100001 00010010 10100100 01000010
XOR-> 01011010 00010110 10011100 00001100
15462-> 00111100 01100110
0x2112-> 00100001 00010010
XOR-> 00011101 01110100
Il est intéressant de noter que, en addition aux informations qu’il offre, STUN propose un mécanisme de retransmission, particulièrement dans le cadre de UDP qui n’en possède pas, lui permettant de s’assurer qu’une réponse est effectivement reçue. Ce mécanisme se repose sur l’usage d’un algorithme utilisé par TCP (l’algorithme de Karn) dans une optique similaire, entièrement configurable selon les besoins et se basant sur une succession de timers toujours plus longs échelonnant l’envoi des requêtes. Toutefois, dans le cadre de la VoIP, il est essentiel de modifier les valeurs par défaut, celles-ci étant particulièrement élevées (jusqu’à 39.5 secondes !) et mettant de ce fait à mal l’établissement rapide de sessions. Le principe reste néanmoins le même que celui décrit dans le schéma ci-dessous :
STUN dispose déjà de nombreux atouts et fonctionnalités alléchantes. Toutefois, son utilité ne s’arrête pas là : il propose en effet des mécanismes d’authentification qui, s’ils ne sont pas fréquemment utilisés dans le cadre de STUN en lui-même, seront particulièrement appréciés d’extensions (TURN) ou de protocoles se reposant sur lui (ICE). Au nombre de deux, ces méthodes proposent des approches différentes ayant chacune leur utilité. Il est important de noter que ce mécanisme ne chiffre en aucun cas les messages, cette fonctionnalité étant laissée à TLS, mais propose une notion d’intégrité des messages
- Short-term credentials
Valides généralement pour la durée d’une session, ces identifiants à court terme offrent un renouvellement relativement fréquent et dynamiquement négocié par les deux parties. Ce mécanisme offre de ce fait un bon niveau de sécurité, ne nécessitant pas d’échanges compliqués et prolongés. Leur utilisation reste cependant limitée à des cas très précis (notamment ICE), puisque ces informations sont échangées et négociées au sein d’un protocole de signalisation (SIP notamment), et ne peuvent donc pas être utilisées dans un cadre « classique » entre un client et un serveur (mais sont envisageables pour un échange client à client). Son usage, s’il peut paraître étrange à première vue, apparaîtra beaucoup plus clair lorsque ICE sera abordé dans un prochain article.
Alors que TLS peut servir au chiffrement des données, cette authentification crée, sur la base d’un couple nom d’utilisateur/mot de passe, un hash du message permettant de vérifier son intégrité. Cette intégrité permet à chacune des parties de détecter toute altération du message sur son trajet, qu’elle soit due à une tentative de détournement ou d’une perturbation survenue sur la ligne par exemple. Si la valeur d’intégrité est différente entre la source et la destination, le message est ignoré et une retransmission de l’information est attendue.
- Long-term credentials
Très similaire, dans leur fonctionnement, aux short-term credentials, ce mécanisme se repose sur des identifiants persistants, échangés de manière totalement indépendante (ils ne sont notamment pas échangés via le protocole de signalisation). Leur persistance dans le temps requière aussi un établissement de session plus complexe, mais permettant l’utilisation de ce mécanisme au sein d’échanges classiques entre un client et un serveur STUN.
Cet échange (ou challenge en anglais) ne doit pas vraiment surprendre toute personne familière avec d’autres protocoles communs. Outre le nom d’utilisateur et le mot de passe, le serveur génère un nonce, valeur unique et créée dynamiquement, valable sur une courte période. Toutes ces valeurs vont constituer la base avec laquelle la valeur d’intégrité va être créée. Lorsque le nonce arrive à échéance, il est automatiquement renouvelé par le serveur sur envoi d’une nouvelle requête binding (qui peut encore se baser sur l’ancien nonce), permettant par extension de réduire les risques liés à une éventuelle attaque (par dictionnaire sur le mot de passe notamment).
Le protocole STUN offre une large gamme de services intéressants et opérationnels en tant que tels. Toutefois, son fonctionnement le limite aux seuls NAT proposant une association indépendante, tels que décrits dans un précédent billet à ce sujet : il est en effet impossible pour un serveur STUN de répondre avec le bon couple adresse/port lorsque le NAT modifie son association lorsque le port et/ou l’adresse de destination changent. Dès lors, et afin que STUN s’avère aussi efficace même dans les situations qu’il n’est pas capable d’aborder en l’état, une extension au protocole a été créée sous la forme de TURN, protocole que nous détaillerons la prochaine fois !
