Résumé

  • Trois tests Binding permettaient à RFC 3489 de nommer six situations, mais chaque réponse dépendait d’un socket, d’un serveur, d’un domaine d’adressage, d’une destination et d’un instant.
  • RFC 5389 conserva l’adresse observée tout en refusant d’en faire une preuve de traversée. Seul un contrôle avec le pair visé pouvait établir un chemin; un relais devait rester possible.

RFC 3489 proposait en 2003 un diagnostic séduisant. Le premier test comparait le socket local à MAPPED-ADDRESS. Le deuxième demandait au serveur de répondre depuis une autre adresse et un autre port. Le troisième ne changeait que le port. Une nouvelle requête vers CHANGED-ADDRESS permettait de comparer deux mappages. Le résultat rangeait la situation entre Internet ouvert, pare-feu UDP symétrique et quatre familles de NAT.

Les observations étaient valides, mais leur portée était plus étroite que leur étiquette. Une expérience liait une adresse locale, un serveur et son adresse secondaire, un ensemble éventuel de traducteurs, un domaine d’adressage et un moment. Le RFC demandait même de changer de socket lors d’une répétition, car l’état créé par la première mesure pouvait invalider la seconde. Mesurer modifiait l’objet mesuré.

La destination disparaissait dans le classement. Un mappage stable vers le serveur STUN pouvait changer vers le pair réel. Un filtre pouvait accepter une source et en refuser une autre. Plusieurs NAT en série étaient résumés par le comportement apparent du plus restrictif, sans identifier la boîte, la règle ou la minuterie responsable. Le mot « type » transformait ainsi une relation en propriété de l’équipement.

Le domaine d’adressage posait une autre limite. Un serveur placé dans le mauvais domaine pouvait annoncer une adresse inutilisable par l’autre participant. Deux pairs derrière le même NAT pouvaient échouer en utilisant l’adresse externe. MAPPED-ADDRESS disait seulement ce que ce serveur avait vu pour cette requête; il ne promettait pas que tout pair pourrait joindre cette adresse.

La durée de liaison était elle aussi une estimation. Le client maintenait une liaison et laissait l’autre vieillir. Une surcharge pouvait modifier dynamiquement les délais; deux liaisons pouvaient avoir des durées différentes; un redémarrage pouvait fausser l’expérience. Une valeur découverte n’était donc pas un bail garanti.

L’intégrité cryptographique ne corrigeait pas cette différence de portée. Elle pouvait authentifier une réponse sans prouver sa validité pour une autre destination. RFC 5389 expliqua plus tard qu’une fausse adresse mappée restait possible dans certaines topologies et que la cryptographie seule ne suffisait pas. L’authenticité du témoignage et l’autorité de sa conclusion restaient séparées.

Le bilan de RFC 5389 fut explicite: le STUN classique ne fonctionnait pas assez bien comme solution complète. Une adresse apprise marchait parfois, parfois non; l’algorithme ne savait ni le prévoir ni réparer l’échec. De nombreux NAT ne correspondaient pas aux catégories. La base supprima donc les anciens attributs de changement d’adresse et transforma STUN en utilitaire employé par des usages définis.

RFC 5780 sépara ensuite le comportement de mappage du comportement de filtrage. ICE, dans RFC 8445, forma des couples de candidats et les testa entre les participants réels avant d’en choisir un. TURN, dans RFC 8656, fournit un relais quand aucun chemin direct ne réussit. La question opérationnelle devint: « quel couple fonctionne maintenant? », non « quel nom porte le NAT? »

La lecture de Heng Lu éclaire cette correction. Un mécanisme initial minimal peut rester commun tandis que les usages choisissent localement serveurs, temporisation, authentification et repli. Les couches de réalité empêchent ensuite de confondre socket, réponse STUN, adresse observée, test du pair, nomination, paquets reçus et résultat applicatif.

Une classification peut résumer des preuves; elle ne doit pas effacer les conditions de leur production. RFC 3489 avait nommé la boîte. RFC 5389 remit le chemin au centre.

Sources