Summary

  • Pour un datagramme candidat d’au moins 21 octets, la correspondance des 16 derniers octets avec un jeton associé à la connexion impose l’arrêt au récepteur ; elle n’authentifie pas l’émetteur.
  • Elle n’indique ni pourquoi l’état a disparu, ni quel serveur était responsable, ni quand la perte s’est produite.
  • L’analyse d’incident doit joindre au paquet les décisions de routage, la version de clé et le dernier état encore attesté.

Un répartiteur de charge déplace un flux vers un autre serveur. Quelques instants plus tard, le client reçoit un paquet dont les seize derniers octets correspondent à un jeton de réinitialisation connu et abandonne immédiatement la connexion. Le signal est décisif pour l’action du client, mais trop étroit pour conclure que « le serveur a perdu l’état ».

Le RFC 9000, section 10.3, réserve la réinitialisation sans état à une extrémité qui ne peut plus accéder à l’état de la connexion. En QUIC v1, avec les fonctions AEAD définies, un paquet à en-tête court de moins de 21 octets n’est jamais valide et doit être rejeté. À partir de 21 octets, le récepteur compare les 16 derniers octets aux jetons associés à ses identifiants de connexion actifs. Une correspondance entraîne la fermeture immédiate, mais n’authentifie pas l’émetteur et ne transporte ni cause, ni identifiant de serveur, ni horodatage de la perte initiale.

Le paquet est volontairement difficile à distinguer d’un paquet ordinaire à en-tête court. Sa forme aléatoire protège le signal contre une identification triviale par un observateur. Les règles de taille évitent notamment qu’une réponse plus grande n’alimente une boucle de réinitialisations. Une capture passive ne peut donc pas classer tout paquet ressemblant comme preuve certaine d’une réinitialisation.

La section 10.3.1 décrit la construction du jeton et permet de le dériver à partir d’une clé statique et d’un identifiant de connexion. Cette propriété autorise une couche de routage qui ne conserve pas l’état complet à produire un jeton concordant. Elle ne permet pas au destinataire de découvrir quelle version de clé, quelle instance ou quel événement opérationnel l’a produit.

La section 10.3.2 pose une autre limite essentielle : des identifiants différents ne doivent pas partager le même jeton. Une collision ou une réutilisation incorrecte peut créer un faux positif et faire fermer une connexion encore saine. Le fait que le client ait correctement reconnu le jeton ne prouve donc pas que les systèmes qui l’ont attribué ou conservé ont respecté tout leur cycle de vie.

Les considérations de sécurité de la section 21.11 renforcent cette séparation. Un jeton divulgué ou mal géré peut permettre l’injection d’une réinitialisation. La correspondance d’un jeton ne suffit donc ni à attribuer une attaque, ni à exonérer un déploiement, ni à prouver qu’un basculement a correctement préservé l’état.

À titre de recommandation éditoriale, chaque incident devrait conserver une preuve jointe : heure d’observation ; tuple d’adresses et de ports ; longueur et forme du paquet ; empreinte du CID et du jeton plutôt que leurs valeurs largement diffusées ; numéro de séquence correspondant ; serveur émetteur et version de clé ; décision du répartiteur ; dernier paquet valide observé ; événements de déploiement ou de basculement ; et preuve indépendante de présence ou d’absence dans le magasin d’état.

Cette chronologie distingue des mécanismes qui produisent le même résultat côté client : redémarrage, éviction, expiration, erreur de routage, dérive de réplication, rotation de clé incohérente, collision de jeton ou injection malveillante. Le reset explique pourquoi le client ferme maintenant. Seule la preuve opérationnelle explique pourquoi l’état n’était plus disponible.