Résumé

  • La RFC 9853 ajoute à DTLS 1.2 et 1.3 une vérification de retour authentifiée et chiffrée. Une réponse liée au défi peut justifier la mise à jour de l’adresse associée à un Connection ID ; l’expiration du délai laisse l’ancienne association intacte.
  • Ce résultat ne vaut ni identité, ni autorisation, ni migration terminée. Un reçu exploitable sépare le déclencheur, le modèle de menace, le budget de sondage, la réponse, le déplacement du contexte, l’acceptation applicative, l’observation et le retour arrière.

Le premier enregistrement reçu depuis l’adresse B est valide. Son CID sélectionne une association créée lorsque le pair se trouvait à l’adresse A ; l’epoch et le numéro de séquence conviennent ; le déchiffrement authentifié réussit. La question opérationnelle reste pourtant ouverte : le récepteur doit-il désormais envoyer les réponses applicatives à B ?

Le Connection ID détache utilement l’association DTLS du couple adresse-port. Un équipement mobile, un objet contraint ou un pair derrière un NAT peut continuer sa session après un changement d’adresse. Cette continuité ouvre aussi une surface de redirection. Une copie d’un enregistrement authentique peut arriver plus vite par une autre route ; une adresse source modifiée peut pousser un serveur imprudent à amplifier du trafic vers une victime.

La RFC 9146 imposait déjà trois conditions avant de remplacer l’adresse du pair : l’enregistrement doit être vérifié par DTLS, être plus récent selon l’epoch et le numéro de séquence, et une stratégie doit établir que la nouvelle adresse sait recevoir et traiter des enregistrements DTLS. La dernière stratégie restait volontairement non spécifiée.

Publiée en mars 2026 sur la filière IETF Standards Track, la RFC 9853 définit cette stratégie pour DTLS 1.2 et 1.3. Elle met à jour la RFC 9146 et la RFC 9147. Son sous-protocole Return Routability Check, RRC, intervient avant la modification de l’association CID-adresse.

L’ordre ne doit pas être aplati. Le CID retrouve l’état de sécurité ; la couche record établit que le datagramme appartient à cet état ; RRC teste un chemin ; le récepteur décide ensuite de modifier son association locale. Chaque preuve possède sa propre portée.

Une capacité convenue à l’avance

RRC se négocie avec l’extension vide rrc, code 61. Le client qui la propose doit aussi offrir connection_id. Le serveur l’accepte dans ServerHello. Aucune partie ne peut utiliser RRC sans échange réussi de l’extension dans les deux sens.

Cette négociation n’impose pas RRC à toute application. Lorsqu’un enregistrement avec CID vient d’une adresse différente, le récepteur devrait lancer RRC, sauf s’il peut déclencher un mécanisme applicatif. L’option Echo de la RFC 9175 permet ainsi à CoAP de demander une preuve de fraîcheur ou de joignabilité suivant la ressource, la méthode et la politique. Une route de transport et une opération acceptable ne constituent pas le même prédicat.

Le content type 27, return_routability_check, transporte trois messages : path_challenge, path_response et path_drop. Chacun contient un cookie de huit octets, soit 64 bits d’entropie, et doit être authentifié et chiffré avec le contexte actif.

Le cookie ne représente ni le pair, ni l’adresse, ni une permission. Il lie une réponse à une tentative précise. Pour conserver cette signification, le journal doit rattacher son engagement à la connexion, à l’adresse testée, à l’heure d’envoi et à l’expiration. Le libellé « RRC réussi » efface ces limites.

Le plafond précède la réponse

Dès qu’un changement d’adresse est observé, le récepteur arrête l’envoi des données applicatives en attente ou limite tout trafic vers l’adresse non validée au plafond anti-amplification. La RFC définit celui-ci comme trois fois le volume reçu de l’adresse candidate, hors enregistrements rejetés.

Il s’agit d’un budget de risque, pas d’une prévision de débit. Une petite requête usurpée ne doit pas libérer une réponse volumineuse. Le récepteur envoie d’abord un défi protégé. Une victime sans le contexte DTLS ne peut ni le déchiffrer ni produire la réponse liée ; l’ancienne adresse demeure donc active.

Dans la procédure simple, l’initiateur place un cookie imprévisible dans path_challenge, l’envoie à l’adresse nouvellement observée et lance le délai T. Le répondant vérifie le message puis renvoie le cookie dans path_response. L’association n’est modifiée qu’après réception de la bonne valeur. Si T expire, elle ne change pas.

La perte autorise des défis supplémentaires, non une rafale sans limite. Ils devraient partir dans des paquets distincts, être cadencés et contenir chacun de l’aléa. Sans règle applicative particulière, un défi par RTT peut être envoyé jusqu’au plafond anti-amplification. Le répondant, lui, renvoie exactement un message immédiat par défi valide vers l’adresse d’origine du défi. Les réponses invalides sont ignorées.

Le choix de T est une donnée de preuve. Avec une mesure externe du RTT du chemin actif, T devrait valoir trois RTT ; sans elle, une seconde est recommandée, sauf profil de déploiement plus adapté. Une expiration signifie que la condition n’a pas été établie dans cette fenêtre, pas que le pair a définitivement disparu.

Interroger d’abord l’ancien chemin

La procédure simple réduit l’amplification mais ne couvre pas seule l’adversaire hors chemin qui observe des paquets valides et en expédie des copies par une route plus rapide. La copie gagnante ressemble à une migration. Une validation limitée à la nouvelle route peut alors installer l’adversaire sur le chemin.

La procédure renforcée commence donc par l’ancienne adresse. Un path_response sur le chemin encore préféré maintient l’association. Un path_drop indique que ce chemin fonctionne mais n’est plus préféré ; le récepteur passe alors au test simple de la nouvelle adresse. L’expiration du sondage ancien déclenche également ce test, jamais une migration automatique.

Le protocole distingue ainsi silence, abandon explicite et confirmation du chemin précédent. Il ne promet pas une certitude impossible. La RFC reconnaît qu’une route adverse durablement plus rapide peut être impossible à distinguer d’une amélioration réelle du routage. Des indices tels que des paquets très récents sur l’ancien chemin ou des doublons peuvent informer une politique locale sans devenir une nouvelle sémantique du cookie.

Une seconde reliaison pendant la première validation révèle une autre limite : les algorithmes ne gèrent pas les reliaisons imbriquées. La réponse devenue étrangère est rejetée, la tentative expire, l’association ne bouge pas et de nouvelles données peuvent lancer un nouveau test. Un état unique « migration » ne permettrait pas de savoir quelle adresse a effectivement été éprouvée.

Joignable ne signifie pas habilité

Une réussite RRC prouve seulement qu’une partie utilisant le contexte DTLS actif a reçu un défi protégé sur le chemin testé et renvoyé la valeur liée dans la fenêtre choisie. Elle ne prouve pas le propriétaire légal de l’adresse, l’identité d’une personne ou d’un équipement, l’autorité ayant demandé le déplacement, la durée future du chemin ni l’absence d’observation.

Elle ne commande pas davantage la poursuite de l’application. Une opération CoAP peut exiger une fraîcheur spécifique même lorsque la route est valide. Une commande d’actionneur peut avoir expiré, un travail en file peut ne plus être idempotent, ou une autorisation peut avoir changé. Reprendre l’émission d’octets est un résultat du transport ; préserver le sens des octets relève de l’application.

Le principe de spécification initiale minimale, décision future localisée et adoption volontaire de Lu Heng permet de lire cette séparation. La couche commune définit les preuves déterministes nécessaires à la sécurité et à l’interopérabilité ; les acteurs exécutant le code conservent le choix du modèle de menace, de la méthode applicative, du moment de déploiement et des effets acceptés.

Le Policy Mirror conduit au véritable point de pouvoir : la transition locale qui remplace l’adresse et libère la sortie applicative. Ni le code IANA, ni le CID, ni le cookie ne réalisent seuls cette transition.

La production d’un signal exploitable

La RFC recommande de compter les échecs, les réponses multiples à un même défi et les sondages fréquents. Un échec peut refléter une usurpation ou un retour cassé ; plusieurs réponses peuvent signaler une course hors chemin ; une succession de sondages peut révéler une connectivité instable malgré des validations finales positives.

Les versions diffèrent. DTLS 1.3 masque le type d’enregistrement aux observateurs du chemin. En DTLS 1.2, un message RRC non enveloppé dans tls12_cid expose son type et peut être filtré par un intermédiaire ; l’usage de CID dans les deux directions réduit ce risque. DTLS 1.3 permet aussi de demander de nouveaux CIDs afin d’éviter leur réutilisation sur plusieurs chemins. DTLS 1.2 ne le permet pas pendant la session et convient mal à un multihoming où la corrélation est une menace.

RRC ne neutralise pas un attaquant déjà sur le chemin, qui peut nuire à la connectivité ou rediriger le test vers le pair réel. Le registre IANA des paramètres TLS coordonne le type 27, l’extension 61 et les trois codes initiaux. Il ne certifie ni implémentation, ni identité, ni décision applicative.

Sources et limites

Le socle est constitué de la RFC 9853 et de sa fiche d’état et d’errata, des RFC 9146, 9147, 9175 et 9000, du registre IANA et de la RFC 8126. Ces textes fixent des contrats normatifs et de registre ; ils ne mesurent ni adoption, ni performances, ni comportement des fournisseurs, ni politique d’un opérateur.

Le registre d’errata propre à la RFC 9853 conserve l’historique des corrections vérifié à la date de recherche.