Résumé

  • STUN fournit une adresse réflexive de serveur, une observation ponctuelle, sans garantir la joignabilité universelle ou une identité durable.
  • STUN moderne (RFC 5389, RFC 8489) agit comme un outil modulaire, dont les observations sont utilisées par des protocoles comme ICE (RFC 8445) pour l'échange de candidats et les vérifications de connectivité.
  • La première version de STUN (RFC 3489) visait une classification NAT complète et la réutilisation de l'adresse, une ambition jugée impraticable.
  • La joignabilité, le consentement et la sécurité restent la responsabilité de l'usage applicatif, au-delà du rôle d'observation de STUN.

Le fait observé

Il faut partir d’un fait de paquet, pas d’une promesse de connexion : une application client, fonctionnant derrière un Traducteur d'Adresses Réseau (NAT), initie une requête STUN (Session Traversal Utilities for NAT) Binding. Cette requête est envoyée depuis une adresse IP locale et un port spécifiques, connus du client. Lorsque le paquet traverse le NAT, le dispositif NAT réécrit l'adresse IP source et le port, les transformant en une adresse de transport visible publiquement. Lorsque cette requête atteint un serveur STUN, le serveur enregistre l'adresse de transport source à partir de laquelle il a reçu le paquet. Le serveur STUN construit alors une réponse Binding, intégrant cette adresse de transport source observée dans l'attribut XOR-MAPPED-ADDRESS, et la renvoie au client ^1^. Cette adresse renvoyée est une observation spécifique du point de vue du serveur STUN à ce moment précis pour cette transaction particulière.

Le détour historique

Historiquement, STUN, tel que documenté à l'origine dans la [^2^ RFC 3489], nourrissait une vision plus ambitieuse. Il cherchait non seulement à révéler cette adresse réflexive de serveur, mais aussi à classer le type de dispositif NAT présent – comme le full-cone, restricted-cone ou port-restricted-cone – et à fournir une solution complète pour la traversée de la connectivité de pair à pair.

L'hypothèse sous-jacente était qu'en comprenant le type de NAT et en observant un mappage externe, les clients pourraient prédire de manière fiable comment leur adresse serait vue par d'autres pairs et ainsi faciliter les connexions directes. Cette approche visait à transformer une observation unique en une déclaration universelle de joignabilité.

La vérification par les usages

ICE rend cette prudence opérationnelle : dans [^5^ RFC 8445], l’adresse observée devient un candidat, jamais une preuve suffisante. ICE ne fait pas aveuglément confiance à une seule adresse observée par STUN comme preuve de joignabilité de pair à pair. Au lieu de cela, ICE traite les adresses réflexives de serveur, ainsi que les candidats hôtes et les candidats relayés (obtenus via TURN), comme un seul type de « candidat ». ICE s'engage ensuite dans un processus sophistiqué d'échange de multiples paires de candidats avec son pair et effectue des vérifications de connectivité explicites, de pair à pair, sur ces paires.

Cette vérification systématique établit la joignabilité réelle plutôt que de l'inférer d'une observation singulière. Différentes destinations, divers protocoles, l'état des dispositifs NAT, l'évolution des règles de pare-feu ou des chemins réseau alternatifs peuvent tous influencer indépendamment la question de savoir si une adresse observée particulière est effectivement utilisable par un pair. Une seule réponse STUN ne révèle pas la durée de vie d'un mappage, son comportement pour toutes les destinations possibles, les politiques de pare-feu spécifiques, ou si un pair distant a consenti à communiquer.

Les mécanismes d'authentification et d'intégrité au sein de STUN protègent les échanges définis, mais ne transforment pas un tuple mappé en une permission universelle ou une garantie de joignabilité pour chaque pair potentiel.

L'usage environnant, par conséquent, assume explicitement la responsabilité de l'échange de candidats, de l'exécution des vérifications de connectivité, de la gestion du consentement, de l'assurance de la fraîcheur, de la sélection du chemin optimal, de la gestion des retransmissions, de la mise en œuvre de stratégies de repli, et de la décision de recourir au comportement de relais via un serveur TURN.

De l’échec du classement au cadre actuel

Cependant, le déploiement pratique et l'expérience opérationnelle ont révélé des limitations importantes. La complexité et la variabilité des implémentations NAT réelles, des pare-feu et des topologies réseau signifiaient que la classification NAT était souvent peu fiable ou trompeuse. Une adresse apprise via STUN pouvait être utilisable par certains pairs mais pas par d'autres, ou sa durée de vie de mappage pouvait être imprévisible. La grande vision de la RFC 3489 en tant que solution de traversée autonome s'est avérée insuffisante.

Cette réévaluation critique a conduit à la [^3^ RFC 5389], qui a explicitement documenté les raisons de l'abandon de l'ambition de solution complète classique de la RFC 3489. Elle a réorienté le rôle de STUN, le repositionnant d'un mécanisme de traversée complet à un outil fondamental à employer par des usages de niveau supérieur. L'adresse observée par un serveur STUN est une preuve précieuse, mais ce n'est ni une identité publique durable ni une garantie qu'un pair arbitraire puisse utiliser le même mappage pour la communication.

La norme STUN actuelle, la [^4^ RFC 8489], maintient cette frontière d'outil et d'usage plus étroite et plus ciblée. Elle définit le mécanisme de base pour découvrir l'adresse de transport réflexive de serveur et spécifie d'autres attributs comme ERROR-CODE à des fins de diagnostic. Il est crucial de noter que la RFC 8489 précise que les protocoles et applications de niveau supérieur sont responsables de l'interprétation et de l'utilisation de cette observation. Ils sont propriétaires des décisions concernant le timing, la gestion de divers attributs, la sélection des serveurs STUN et le choix des protocoles de transport.