Résumé

  • Un PATH_RESPONSE correspondant montre que le pair qui a reçu un PATH_CHALLENGE imprévisible pouvait en renvoyer les huit octets.
  • Cette preuve ne vaut ni authentification cryptographique, ni identité de personne, d’appareil ou de compte, ni autorisation, ni validation de MTU.
  • Le registre opérationnel doit conserver la joignabilité bornée séparément de l’identité, du résultat applicatif et de la joignabilité future.

Imaginez un opérateur qui reçoit un PATH_RESPONSE correspondant et l’inscrit aussitôt comme preuve d’identité durable. Cette conclusion dépasse le protocole. Dans RFC 9000, la validation de chemin vérifie la joignabilité d’un pair sur un chemin réseau. Elle intervient lors d’une migration de connexion et peut sonder une nouvelle adresse locale avant migration. Elle ne cherche pas à établir qui se trouve derrière l’adresse.

L’émetteur place PATH_CHALLENGE sur le chemin qu’il veut tester. La donnée doit fournir au moins 64 bits d’entropie, sous la forme d’une valeur imprévisible de huit octets. Le récepteur répond par PATH_RESPONSE en recopiant exactement cette donnée. La réponse doit être envoyée sur le chemin où le challenge est arrivé. En revanche, l’initiateur accepte une réponse correspondante reçue sur n’importe quel chemin réseau.

Cette formulation est importante : le répondeur démontre le retour de la valeur sur le chemin de réception, tandis que l’initiateur ne doit pas exiger un chemin précis pour la réponse, car cette contrainte pourrait favoriser une attaque de migration.

La validation réussit lorsque la réponse contient la donnée d’un PATH_CHALLENGE antérieur. Un ACK du paquet qui transportait le challenge ne suffit pas, puisqu’un pair malveillant pourrait usurper cet accusé. Plusieurs challenges peuvent être envoyés pour tolérer la perte, mais ils ne devraient pas être regroupés dans un seul paquet. Aucun autre paquet ni aucune autre trame ne remplace la PATH_RESPONSE correspondante.

Le résultat porte sur une condition d’adresse et de chemin à un moment donné. Il ne prouve pas l’identité d’une personne, d’un appareil, d’un compte ou d’une application. Il ne prouve pas non plus une identité cryptographique, une autorisation, une issue métier ou la disponibilité future du chemin. Ces séparations sont des limites opérationnelles déduites de la condition de succès étroite de RFC 9000. L’authentification cryptographique, l’identité applicative, l’autorisation, le résultat et la politique de conservation doivent donc occuper des champs distincts.

La validation du chemin ne doit pas être confondue avec celle de la MTU. Un challenge réussi dans un datagramme inférieur à 1200 octets peut valider l’adresse ou le chemin sans démontrer la prise en charge de la MTU requise. Il faut un challenge étendu pour cette question. Les datagrammes PATH_RESPONSE sont normalement étendus à au moins 1200 octets, sans dépasser la limite anti-amplification. Le registre doit ainsi séparer le résultat de validation d’adresse du résultat de validation de MTU et conserver la taille du datagramme et l’état anti-amplification.

Une réponse manquante ne signifie pas immédiatement un échec. RFC 9000 recommande un temporisateur fondé sur trois fois la plus grande des PTO du chemin actuel et du nouveau chemin, en laissant plusieurs PTO afin qu’une seule perte ne tranche pas. La validation échoue lorsque l’endpoint abandonne la tentative. L’abandon d’un chemin n’oblige pas à fermer la connexion si un autre chemin valide reste utilisable. Un sondage échoué signifie seulement que ce chemin candidat n’est pas utilisable pour cette connexion.

Un changement d’adresse, notamment une réaffectation NAT, impose une nouvelle validation sauf si cette adresse avait déjà été validée. Cela ne transforme pas la validation QUIC en mécanisme de traversée NAT : RFC 9000 ne fournit pas les mécanismes de synchronisation nécessaires. Lors d’une migration, capacité et temps de réponse peuvent différer. QUIC réinitialise donc l’état du contrôle de congestion et du RTT au lieu de traiter les mesures précédentes comme des garanties.

Le registre recommandé peut contenir un identifiant de chemin limité à la connexion et un condensat de challenge préservant la vie privée, les instants du challenge et de la réponse, le tuple d’adresses testé, la taille du datagramme, le résultat de correspondance et le chemin d’arrivée de la réponse. Il doit distinguer validation de l’adresse du pair et validation de MTU, noter l’état anti-amplification avant et après, les entrées PTO des chemins actuel et candidat, la raison d’abandon et le résultat du temporisateur.

Le déclencheur NAT-rebinding ou migration, l’adresse déjà validée et les chemins alternatifs utilisables doivent rester explicites. Les condensats et la conservation limitée sont des recommandations d’exploitation, pas des exigences QUIC.

La séparation avec les travaux voisins doit rester visible. TR-039 porte sur le budget d’amplification avant validation. TR-033 traite la preuve de retour des DNS Cookies. TR-043 porte sur l’intégrité de Retry. TR-040 sépare les connection IDs de l’identité. TR-061 traite la preuve d’adresse NEW_TOKEN entre connexions futures. Ces axes ne doivent pas être fusionnés.