Résumé

  • RFC 5128 décrit des techniques de traversée de NAT observées lors de sa publication ; son statut Informationnel ne vaut pas approbation d’une mise en œuvre.
  • Un service de rendez-vous peut diffuser des points de terminaison privés et publics sans pouvoir vérifier l’adresse privée revendiquée par un inscrit.
  • Une même adresse privée désigne des machines différentes dans des foyers, entreprises ou niveaux de NAT distincts.
  • Une sonde envoyée vers le candidat privé d’un pair peut donc atteindre un autre équipement du réseau local de l’expéditeur, même sans attaquant.
  • Un inscrit malveillant peut nommer une victime et faire converger vers elle les tentatives de nombreux pairs.
  • Avant un échange bidirectionnel authentifié, il faut plafonner paquets, octets, destinations, reprises, calcul et état conservé.
  • La réponse d’un point de terminaison prouve une propriété du chemin, pas l’identité attendue ni le droit de consommer une ressource.
  • L’adresse IP source ne suffit pas à authentifier : la compatibilité NAT suppose précisément que les adresses puissent être réécrites.
  • L’application doit authentifier son contenu avec une identité de niveau supérieur et lier cette identité au chemin retenu.
  • Un mappage indépendant du point de terminaison n’implique pas un filtrage indépendant ; réutilisation d’adresse et permission entrante sont deux contrôles.
  • ICE et TURN rendent le cycle de chemin plus explicite, sans transformer une vérification de connectivité ou une allocation de relais en identité métier.
  • La preuve doit rester séparée entre inscription, découverte, budget de sondes, chemin, identité, autorisation, engagement de ressources et résultat.

L’amplification commence par une délégation discrète

L’attaquant n’a pas besoin d’émettre lui-même tout le trafic. Il lui suffit de faire inscrire l’adresse de la victime puis de provoquer ou d’attendre de nombreuses découvertes. Chaque pair exécute alors une action apparemment légitime : quelques paquets vers le candidat qui lui a été communiqué. Leur somme devient la charge de la victime.

Cette forme d’amplification est facile à sous-estimer car chaque participant respecte peut-être sa limite locale. Dix paquets par session paraissent modestes ; des milliers de sessions visant le même hôte ne le sont plus. Une politique uniquement par session mesure l’obéissance de chaque émetteur, pas l’effet collectif du système de coordination.

RFC 5128 recommande de minimiser le débit et la taille des communications vers une adresse nouvellement découverte. La mise en œuvre doit traduire cette intention en budgets observables : nombre de candidats essayés, paquets et octets, calendrier des reprises, durée de vie de l’état, calcul cryptographique, mémoire et éventuelle préparation d’un relais.

Le contrôle doit aussi agréger par cible, préfixe, inscrit et objet de rendez-vous. Sinon, un adversaire peut répartir une même destination entre de multiples comptes ou conversations. La conformité locale masque alors une concentration globale, exactement comme plusieurs petites permissions peuvent produire une grande dépense lorsqu’aucune autorité ne voit leur somme.

Le serveur de rendez-vous ne voit pas l’intérieur des réseaux privés

Le rôle du rendez-vous est utile et limité. Il associe des participants à une conversation, observe éventuellement un tuple public créé par un NAT et transmet des candidats. Il ne dispose pas pour autant d’une vue universelle des espaces d’adresses privés.

192.168.1.100 peut être le portable de l’inscrit chez lui et une caméra chez le destinataire. Si le second essaie ce candidat privé, son propre réseau interprète l’adresse. L’intention du premier ne voyage pas avec les bits. Le paquet peut donc atteindre une machine étrangère à la conversation.

Le serveur peut avoir authentifié le compte qui a soumis la valeur. Cela prouve l’auteur de la déclaration selon son régime d’accès, pas la possession du point de terminaison dans chaque domaine où cette valeur sera interprétée. Il peut signer la réponse de découverte ; la signature prouve l’émission de la liste, non la justesse universelle de chaque adresse.

Cette confusion peut être accidentelle. Deux acteurs de bonne foi réutilisent les mêmes plages, comme le prévoit l’adressage privé. L’intention malveillante exige donc un élément supplémentaire : historique d’inscription, choix répété d’une cible, distribution, chronologie ou autre preuve. L’erreur de destination est observable ; le motif ne doit pas être inventé.

Une réponse n’est pas encore une identité

La mauvaise machine peut rester silencieuse, mais elle peut aussi répondre. Une socket s’ouvre, une transaction STUN revient ou un contrôle de connectivité ICE réussit. À ce stade, la télémétrie possède une preuve de chemin. Elle ne possède pas nécessairement la preuve que l’application parle à la personne, au compte ou à l’organisation attendus.

Les contrôles ICE avec identifiants ont une portée réelle : ils démontrent des propriétés de la paire candidate et la possession des identifiants courts de la session. Leur portée ne doit ni être minimisée ni étendue. L’application doit encore relier le transport à son identité supérieure et décider ce que cette identité est autorisée à demander.

Une migration de chemin oblige à préserver ce lien. Nouvelle nomination, mobilité, rebinding du NAT ou passage au relais : le tuple change. Le protocole applicatif doit décider si la session authentifiée reste liée au nouveau chemin, si un channel binding suffit ou si une nouvelle authentification est nécessaire. Conserver un voyant vert sans conserver cette décision produit une continuité graphique, pas une continuité prouvée.

Le résultat vient encore après. Un pair correct et autorisé peut disposer d’un chemin trop lent, perdre des données ou ne pas accomplir l’action attendue. « Connecté » ne doit donc pas recouvrir à la fois le paquet reçu, l’identité vérifiée, la permission accordée et le service rendu.

L’authentification précède l’ouverture du budget

RFC 5128 situe le seuil à la communication bidirectionnelle authentifiée. Avant ce seuil, une application peut réaliser le travail minimal nécessaire à la découverte. Elle ne devrait pas réserver une grande quantité de mémoire, lancer un calcul long, envoyer un objet volumineux ou maintenir indéfiniment des reprises.

Le budget porte sur davantage que le réseau. Un petit datagramme peut créer un minuteur, une entrée de paire candidate, un contexte cryptographique, une écriture de journal et une tâche de travail. Une limitation en octets qui laisse la création d’état sans plafond déplace simplement l’attaque.

Après authentification, l’autorisation reste une étape distincte. Le fait de savoir qui est le pair ne lui donne pas automatiquement droit à une allocation TURN coûteuse, à un téléchargement important ou à une opération de calcul. Le reçu d’identité, la règle d’autorisation et le reçu de ressource doivent pouvoir être comparés.

Cette séparation améliore aussi la reprise après incident. Si une dépense anormale apparaît, l’opérateur peut déterminer si elle a commencé lors de la découverte, avant l’identité, après une autorisation trop large ou à cause d’une ressource qui n’a pas expiré. Un unique état « session réussie » ne permet aucune de ces réponses.

Mappage, filtrage et hairpin sont trois faits

Le hole punching exige notamment que le mappage puisse être réutilisé vers différents correspondants. Un mappage dépendant du point de terminaison peut créer un tuple externe différent selon la destination et casser la prédiction échangée par les pairs.

Mais la politique de filtrage ne suit pas automatiquement la politique de mappage. Un NAT peut réutiliser le même tuple externe tout en n’acceptant les réponses que des destinations contactées auparavant. Dire qu’un mappage indépendant « ouvre » le NAT confond allocation d’adresse et autorisation de source entrante.

Le hairpin est une autre capacité. Deux pairs placés derrière des NAT aval différents peuvent partager un grand NAT amont. Pour utiliser leurs candidats publics, ce dernier doit pouvoir renvoyer vers l’intérieur un paquet adressé à son propre tuple externe. Les candidats et mappages peuvent être exacts, mais le chemin direct échoue sans ce retour.

La connexion inversée ne couvre que le cas où un pair est public et l’autre derrière un NAT. Le relais reste le procédé le plus fiable lorsque les deux clients peuvent atteindre le serveur, au prix de calcul, de bande passante et souvent de latence. Le hole punching est une économie conditionnelle, pas une preuve supérieure.

La réécriture d’adresse interdit d’ériger l’IP en identité

Une signalisation compatible NAT doit accepter que l’adresse annoncée localement diffère de celle qu’observe le réseau public. Cette souplesse laisse à un acteur sur le chemin la possibilité de substituer une adresse et d’essayer de se placer dans les communications futures.

Authentifier seulement l’IP source ne résout pas une architecture dont la fonction normale inclut sa réécriture. L’identité doit être portée par le contenu applicatif et par des justificatifs de niveau supérieur. Elle doit ensuite être liée à la session et au chemin retenu.

Le chiffrement peut empêcher un intermédiaire de lire ou de modifier le contenu protégé. Il ne fait pas disparaître nécessairement le volume, le rythme et les relations visibles. La confidentialité doit donc elle aussi être décrite par son périmètre plutôt que par un label absolu.

Le service de rendez-vous n’a pas besoin de devenir une autorité d’identité globale. Il doit protéger ses propres inscriptions, conserver la provenance des candidats, exposer les limites de ses observations et borner l’effet qu’une déclaration peut déclencher. L’application garde la charge d’authentifier le pair et d’autoriser le travail.

ICE et TURN ont ajouté des reçus, pas une preuve universelle

RFC 5389 a recentré STUN sur des opérations de protocole, au lieu d’une classification durable du NAT. RFC 8445 organise la collecte des candidats, les paires, les contrôles et la nomination. RFC 8656 formalise allocations, permissions, canaux et expirations TURN. RFC 8835 situe cet ensemble dans le transport WebRTC.

Ces mécanismes fournissent davantage d’étapes vérifiables. Ils ne les fusionnent pas. Un candidat existe ; une paire est formée ; un contrôle fonctionne ; une paire est nommée ; un pair applicatif est authentifié ; une action est autorisée ; une ressource est engagée ; un résultat est livré. Chaque verbe décrit un état différent.

Le relais ne doit donc pas être puni dans les indicateurs de confiance. Il peut être coûteux mais contrôlé. Le direct peut être économique mais viser la mauvaise machine. La comparaison valable porte sur identité vérifiée, politique, coût, performance, résilience et résultat.

Ce que le dossier permet d’affirmer

Les registres RFC Editor et Datatracker établissent l’identité et l’histoire de RFC 5128. Le texte établit les méthodes décrites, leur caractère non prescriptif et les risques anticipés. Les RFC voisines précisent NAT, STUN, ICE, TURN, UDP et WebRTC.

Ils ne mesurent ni la fréquence actuelle des mauvaises destinations, ni le facteur d’amplification d’un produit, ni la part des NAT avec hairpin, ni le taux de réussite direct ou relayé. Aucun recensement de fournisseurs, incident actuel ou résultat utilisateur mesuré n’appartient au dossier.

Les normes donnent le mécanisme et ses limites. Une exploitation doit apporter configuration, traces, échanges authentifiés, consommation et résultats. Remplacer ces observations par l’autorité symbolique d’une référence RFC serait précisément confondre une règle écrite avec la réalité exécutée.

Sources