Résumé

  • Un Connection ID est un repère choisi par l’extrémité qui reçoit : il achemine et rattache un paquet à la bonne connexion QUIC même lorsque l’adresse IP ou le port UDP change.
  • L’identifiant ne suffit pas pour accepter une migration. La nouvelle paire adresse-port est éprouvée par des données imprévisibles dans PATH_CHALLENGE et PATH_RESPONSE, avec une émission limitée tant qu’elle n’est pas validée.
  • Les flux peuvent survivre, mais pas toutes les hypothèses du chemin : congestion et RTT sont réinitialisés, un nouvel identifiant réduit le pistage entre réseaux et Stateless Reset reste le dernier recours d’une extrémité ayant perdu son état.

L’adresse n’était plus le nom de la conversation

Lorsqu’un ordinateur quitte le Wi-Fi pour le réseau mobile, son adresse change. Un NAT peut aussi oublier une association et attribuer un nouveau port UDP. Pourtant, les deux extrémités possèdent encore des flux, des accusés de réception, des clés et un travail applicatif communs.

Faire de tout changement une nouvelle connexion donnerait à l’adresse basse couche le pouvoir de détruire cet état. RFC 8999 définit donc une propriété indépendante de la version de QUIC : le Connection ID est un champ opaque dont la fonction première consiste à conduire le paquet vers la bonne instance, malgré les changements d’UDP, d’IP ou d’une couche inférieure.

RFC 9000 précise qu’une connexion possède plusieurs identifiants. Chaque extrémité choisit les valeurs que son pair utilisera pour lui envoyer des paquets. Le destinataire produit ainsi le repère qui permet à son propre système de retrouver l’état voulu.

Une réserve remplaçable plutôt qu’un matricule éternel

Les en-têtes longs échangent d’abord les identifiants source et destination. Plus tard, les en-têtes courts portent normalement l’identifiant de destination. NEW_CONNECTION_ID fournit de nouvelles valeurs ; RETIRE_CONNECTION_ID retire celles qui ne seront plus utilisées. Les numéros de séquence ordonnent ces opérations et active_connection_id_limit borne la réserve active.

Cette pluralité protège aussi la vie privée. Les valeurs fournies pour une même connexion ne doivent contenir aucune structure permettant à un observateur extérieur non coopérant de les relier. Réémettre la même valeur dans cette connexion est interdit.

Une longueur nulle reste possible quand l’adresse suffit au routage local. Elle retire le champ, pas le problème. Plusieurs connexions partageant une adresse et un port deviennent fragiles lors d’une migration, d’un rebinding NAT ou d’une réutilisation de port. L’extrémité qui choisit zéro pendant la poignée de main ne peut ensuite alimenter le pair en identifiants de remplacement ordinaires.

Les premiers identifiants ne sont pas acceptés sur simple apparition. RFC 9000 les répète dans les paramètres de transport et les lie à la poignée de main cryptographique. RFC 9001 fournit l’intégration TLS 1.3 et la protection des paquets. Une injection ne peut donc pas imposer les identifiants d’une connexion réussie. Cela ne transforme pas le champ isolé en certificat ni en identité civile.

Déplacer la connexion exige une preuve de chemin

L’identifiant assure la continuité du classement ; il ne prouve pas qu’une nouvelle adresse source appartient au pair. La migration active attend la confirmation de la poignée de main. Un changement peut aussi être involontaire : un NAT attribue parfois un nouveau port ou une nouvelle adresse sans décision de l’application.

Face à une adresse encore inconnue, l’extrémité envoie un PATH_CHALLENGE contenant des données imprévisibles. Le pair doit les renvoyer dans PATH_RESPONSE sur le chemin où le défi est arrivé. La conclusion est limitée : ce chemin a transporté le défi vers une entité capable de produire la réponse associée. Elle n’établit ni propriété juridique de l’adresse, ni intention bienveillante, ni qualité future.

La validation est directionnelle. Chaque extrémité construit sa propre preuve de réception. Un accusé ordinaire ne fournit pas assez d’aléa pour s’y substituer. Ce mécanisme n’est pas non plus une traversée NAT générale.

Avant validation, la règle anti-amplification limite les octets envoyés à la nouvelle adresse. Sans elle, une fausse migration pourrait diriger le serveur contre une victime. Si le nouveau chemin échoue et qu’un chemin antérieur reste valide, la connexion revient à ce dernier. L’échec d’une route n’oblige pas à jeter le reste.

La continuité ne transporte pas la capacité

La nouvelle route peut avoir un débit, un délai, des pertes et un comportement ECN différents. Une fois l’adresse confirmée, RFC 9000 réinitialise normalement le contrôleur de congestion et l’estimation RTT. Les paquets de l’ancien chemin ne décrivent pas le nouveau.

Un changement de port seul, souvent dû au NAT, peut conserver ces mesures avec prudence. Mais si le trajet réel a changé, cette mémoire peut provoquer une émission trop agressive. Les clés et les flux appartiennent à la connexion ; l’évaluation de capacité appartient au chemin.

Continuer sans devenir une balise

Réutiliser le même identifiant entre un réseau Wi-Fi et un réseau mobile permettrait à un observateur de raccorder les deux traces. QUIC interdit d’envoyer avec un même Connection ID depuis plusieurs adresses locales ou vers plusieurs adresses de destination.

Changer de valeur retire ce lien direct. La protection des numéros de paquet en retire un autre. Le temps et la taille des paquets peuvent encore trahir la continuité, tout comme une infrastructure coopérante qui connaît la logique de routage interne. La spécification réduit la corrélation ; elle ne promet pas l’anonymat.

Il faut aussi disposer d’identifiants inutilisés avant de bouger. Une réserve épuisée empêche de sonder un chemin ou d’y répondre correctement. La préparation à la mobilité précède le changement de réseau.

Le message ultime d’un serveur amnésique

Après un crash, une extrémité peut recevoir des paquets d’une connexion qu’elle ne connaît plus. Elle ne possède pas l’état nécessaire pour envoyer une fermeture normale. Stateless Reset fournit alors un dernier recours.

Un jeton difficile à deviner de 16 octets est associé à un Connection ID et communiqué dans un contexte protégé. Un datagramme qui se termine par le bon jeton fait abandonner la connexion au pair. Retirer l’identifiant invalide le jeton.

Le paquet de reset lui-même n’a pas de protection cryptographique et ressemble volontairement à un paquet court. La révélation du jeton donne un pouvoir de terminaison ; sa réutilisation est donc interdite. Stateless Reset ne signale pas une erreur active : il permet à une extrémité sans mémoire de mettre fin à l’état que son pair conserve encore.

Sources et limites

Le corpus fermé comprend RFC 8999, RFC 9000 et RFC 9001. Il ne donne ni part de déploiement, ni comportement de fournisseur, ni taux de migration, ni gain de performance. L’identifiant n’est pas une identité mondiale et la validation n’est pas un titre sur l’adresse.