Résumé

  • La RFC 3424 refuse l’idée d’un extérieur unique du NAT : une adresse réfléchie est l’observation locale d’un mapping par un service, dans un domaine et à un instant donnés.
  • Un mécanisme provisoire doit annoncer son périmètre, sa sortie, ses fragilités, les exigences de la solution durable et les leçons des déploiements ; sinon son succès finance sa permanence.

Au départ, la ligne budgétaire devait durer un trimestre. Un petit service renvoyait aux clients l’adresse et le port qu’il observait. Puis il a fallu de la redondance, des sondes, des keepalives, une astreinte, une capacité anti-abus et des relais. Trois ans plus tard, l’exception possédait une équipe, un SLO et aucun critère d’arrêt.

Ce glissement est au cœur de la RFC 3424. Publié en novembre 2002 sur le flux IAB avec le statut Informational, le texte examine les procédés UNSAF, par lesquels un terminal tente de découvrir ou de corriger lui-même l’adresse sous laquelle il est vu au-delà d’un NAT. Il ne normalise pas une identité extérieure universelle. Il demande comment empêcher une heuristique utile de devenir l’architecture définitive.

Une adresse rapportée reste une adresse située

L’état de traduction appartient au dispositif qui traduit. Le terminal peut interroger un service coopératif dans un autre domaine d’adressage ; ce service lui rend le tuple source reçu. Le résultat est exact dans une phrase bien formée : « ce service a vu ce mapping sur cette route à cet instant ».

Il devient faux lorsqu’on retire les compléments. La cible réelle peut se trouver derrière une autre frontière, suivre une autre route ou déclencher une autre règle de traduction. Elle peut voir un tuple différent, ou ne rien recevoir. La réflexion ne prouve ni la joignabilité relative à la cible, ni la permission du firewall, ni la durée du binding, ni l’établissement du transport, ni l’acceptation applicative.

Authentifier le réflecteur ne change pas cette géométrie. Une signature établit l’auteur de l’observation, pas son universalité. Une assertion fiable et locale ne devient pas une identité globale parce qu’elle est signée.

Le mot « public » est donc dangereux lorsqu’il efface le point de vue. La RFC 3424 insiste : il n’existe pas un extérieur unique du NAT. Conserver l’observateur, le realm, le chemin et l’heure est la condition minimale d’un diagnostic honnête.

La disponibilité du remède ajoute une panne possible

Les mappings peuvent expirer, être réattribués ou varier. Un client envoie alors du trafic de maintien, recommence la réflexion ou conserve avec le service un état présumé. Chaque geste prolonge l’utilité de l’observation passée sans obtenir de garantie sur la décision future du middlebox.

Le réflecteur n’est pas intégré au NAT. Il ignore l’algorithme de traduction, les facteurs qui le modifieront et les règles qui s’appliqueront à une nouvelle destination. Le système transforme donc une observation historique en prévision opérationnelle.

Cette prévision a une infrastructure. DNS, routage, capacité, filtrage des abus, synchronisation d’état et supervision du service rejoignent la chaîne critique. Le client et sa cible partagent désormais le sort d’un tiers dont ils n’avaient pas besoin dans le modèle end-to-end initial.

Un keepalive réussi n’est qu’un reçu de maintenance. Il ne prouve pas l’autorisation durable d’un trafic entrant. Quand les tableaux de bord ne gardent que le taux final de connexion, ils présentent le travail permanent du contournement comme une propriété naturelle du réseau.

Traverser n’est pas être autorisé

Sans communication explicite avec le middlebox, un mécanisme UNSAF ne peut garantir que le trafic entre sous la supervision de la politique prévue. Découvrir un mapping et recevoir une autorisation sont deux événements différents.

Cette frontière ne condamne pas tout traversal. Elle interdit d’attribuer au résultat plus d’autorité qu’il n’en a. Un packet passé une fois, un binding ouvert, une vérification de paire réussie, un transport établi et une transaction authentifiée constituent cinq reçus. Aucun ne remplace les autres.

Le risque est symétrique. L’application peut contourner une fonction de sécurité qu’elle ne sait pas interroger. L’opérateur peut, lui, imposer une dépendance à un comportement opaque sans fournir de motif de refus ni de procédure de correction. Dans les deux cas, la gouvernance disparaît derrière un effet de bord.

Les cinq questions qui coûtent moins cher avant le lancement

La première demande un problème précis et limité. Une promesse générale de « traverser les NAT » n’a pas de fin naturelle. Le périmètre doit dire quelles applications, quels chemins et quelles défaillances restent hors contrat.

La deuxième exige une stratégie de sortie ou de transition. Un bon mécanisme temporaire doit être moins utilisé lorsque la technologie adéquate se déploie. Il faut un propriétaire, un indicateur décroissant, un seuil et un test de retrait.

La troisième rend la fragilité visible : services supplémentaires, état distribué, couplage entre couches, coûts de débogage et difficultés de migration. Le graphe des pannes fait partie du produit.

La quatrième transforme l’expérience en exigences pour une solution saine à long terme. Si le pont attire des utilisateurs sans financer son remplacement, il ne mène nulle part.

La cinquième confronte la proposition aux comportements NAT réellement déployés et aux retours d’expérience. Le running code borne la théorie ; un cas réussi ne suffit toutefois pas à créer une loi universelle.

Ces questions déplacent la charge de preuve. Les promoteurs de l’exception doivent montrer non seulement son démarrage, mais aussi la manière dont elle perdra son autorité.

STUN, ICE et PCP ont réduit la portée des mots

La RFC 3489 présentait le premier STUN dans un cadre de traversal plus large. La RFC 5389 l’a rendue obsolète, a renommé STUN en Session Traversal Utilities for NAT et a abandonné l’idée que l’outil suffirait à résoudre seul la traversée. Chaque usage doit décrire le mécanisme environnant et son traitement de sécurité. La RFC 8489 a ensuite actualisé l’outil sans transformer une adresse server-reflexive en identité universelle.

ICE rassemble plusieurs candidats — host, server-reflexive et relayed — puis vérifie des paires. La paire sélectionnée fournit une preuve de connectivité pour cette session ICE. Elle ne promet ni la même route demain, ni l’acceptation de l’application, ni la validité globale du candidat réfléchi.

PCP rend explicite une autre relation en permettant de demander le contrôle d’un mapping. Une concession du middlebox reste distincte d’un reçu de la cible. La lisibilité du contrôle ne supprime pas le besoin d’une preuve end-to-end.

Le progrès commun tient à la modestie du vocabulaire : utilitaire, candidat, vérification, paire sélectionnée, mapping accordé. Un nom plus étroit protège mieux les décisions futures.

Le registre de sortie comporte douze reçus

Il commence par l’interface locale et le tuple transport. Il identifie ensuite le réflecteur, la route et le domaine d’adressage, puis conserve le mapping, l’heure et l’hypothèse de durée. Toute règle ou concession explicite du middlebox occupe sa propre ligne.

La cible doit laisser un reçu de ce qu’elle a réellement observé. Viennent ensuite la vérification de paire, l’établissement du transport, l’échange applicatif authentifié et le résultat visible. Une lumière verte à la fin ne réécrit pas rétroactivement la provenance des étapes précédentes.

Le registre teste aussi le retry, l’expiration, le changement de réseau et le changement de chemin. Enfin, il nomme le propriétaire de l’exception, son périmètre, son déclencheur de retrait et la preuve que l’usage diminue.

Sans ce dernier indicateur, « provisoire » décrit l’intention initiale, pas l’état actuel.

Limites de preuve

La RFC 3424 n’est pas un recensement contemporain des NAT. Elle n’établit aucun comportement d’un fournisseur, opérateur, produit ou incident nommé. Elle ne désigne ni IPv6, ni STUN, ni TURN, ni ICE, ni PCP comme sortie universelle. Une adresse réfléchie n’est pas une identité ; un connectivity check n’est pas une autorisation applicative ; un keepalive n’est pas une politique stable.

Les notes de Heng Lu servent ici de grille éditoriale déclarée. Une spécification initiale minimale doit laisser les choix futurs au niveau local et préserver l’adoption volontaire ; le code en fonctionnement doit limiter les affirmations. Ces principes ne constituent pas des données de déploiement.

Sources