Summary

  • Le CID retrouve un contexte DTLS ; il ne valide pas la nouvelle adresse source du datagramme UDP.
  • Le contrôle simple sonde la nouvelle adresse, tandis que le contrôle renforcé interroge d'abord l'ancien chemin.
  • Le cookie correspondant borne une décision de liaison, sans prouver la symétrie, la stabilité ni l'issue applicative.

Une connexion reconnue n'est pas encore une adresse validée

Quand un enregistrement protégé arrive d'une adresse inconnue, son CID peut conduire au bon contexte de sécurité et l'authentification peut réussir. La RFC 9853 place pourtant une étape entre cette reconnaissance et la modification de l'adresse liée. Elle complète le CID de DTLS 1.2 décrit par la RFC 9146 et celui de DTLS 1.3 décrit par la RFC 9147.

Le protocole n'établit pas la cause du changement. Un rebinding NAT, une migration volontaire ou une copie de paquet acheminée plus vite peuvent produire la même observation initiale. Le journal doit donc conserver « adresse observée différente » sans la transformer automatiquement en diagnostic.

Le RRC négocie l'extension 61 et transporte des messages de type 27. Chaque message est chiffré et authentifié dans le contexte actif et porte un cookie de huit octets. Le registre IANA TLS distingue path_challenge, path_response et path_drop. Cette distinction commande l'état ; ce ne sont pas trois synonymes de succès.

Le contrôle simple et le contrôle renforcé ne répondent pas à la même menace

Dans le mode simple, l'initiateur envoie le défi à la nouvelle adresse. Une réponse protégée qui recopie le cookie permet de mettre à jour la liaison ; l'expiration de T l'interdit. L'échange montre qu'un défi est parti et qu'une réponse est revenue pendant cet épisode. Il ne montre pas que les deux directions suivent les mêmes liens, que le chemin restera valable, que la PMTU inverse convient ou que l'application a répondu.

Le mode renforcé traite le risque d'un observateur hors chemin capable de recopier des enregistrements authentiques et de gagner la course par une route plus rapide. Il sonde d'abord l'ancienne adresse. Si elle reste préférée, path_response signifie conserver l'ancienne liaison. Si elle est vivante mais délaissée, path_drop déclenche ensuite le contrôle simple de la nouvelle adresse. Un dépassement du délai mène aussi à ce contrôle, sans modifier la liaison par lui-même.

Cette séquence importe lors d'un rebinding NAT : l'initiateur voit un nouveau chemin, alors que le répondant peut encore considérer l'ancien comme préféré. Les deux extrémités ne partagent pas nécessairement la même étiquette de chemin. La défense renforcée reste imparfaite : un itinéraire relayé durablement plus rapide peut être indiscernable d'une amélioration réelle.

Avant validation, l'émetteur suspend les données applicatives en attente ou respecte la limite anti-amplification, soit trois fois les données acceptées depuis l'adresse non validée. Après validation, les envois peuvent reprendre vers l'adresse liée. « Reprendre » autorise une tentative ; ce n'est pas un accusé de réception distant.

La valeur de T dépend du contexte : trois RTT quand le RTT actif est connu, une seconde sinon, avec adaptation possible par profil. Une nouvelle modification d'adresse pendant le contrôle invalide la génération en cours : la réponse est abandonnée, le contrôle expire, la liaison reste intacte et de nouvelles données lancent un nouvel essai.

Les cinq pièces d'une affirmation de continuité

Une preuve défendable sépare : le CID et la génération du contexte ; le mode, le cookie frais, les adresses et le délai du contrôle ; l'acte exact de liaison ; le premier paquet protégé reçu dans chaque direction ; enfin la requête applicative acceptée et sa réponse corrélée dans le même intervalle. Un seul voyant vert ne doit pas hériter de ces cinq significations.

La RFC conseille des statistiques sur les contrôles échoués, les réponses multiples et les sondes fréquentes pour le SIEM et le dépannage. Ce sont des recommandations et des signaux possibles, pas la preuve d'une attaque ou d'une panne. La fiche RFC Editor, le Datatracker et la recherche d'errata documentent la norme, non son déploiement.

La primauté du code en fonctionnement, la spécification initiale minimale et la distinction des couches de réalité imposent la même discipline : le symbole « validé » reste plus étroit que les faits exécutables.

Sources