Résumé
- En remplaçant deux valeurs ECT possibles par un même marquage CE, un routeur efface une information choisie au hasard par l'émetteur. Un destinataire qui cache la congestion ne peut pas toujours reconstituer cette information.
- Le contrôle porte sur une parité cumulative, à interpréter avec les acquittements et la récupération après congestion. Il ne certifie ni l'identité du destinataire ni sa culpabilité.
- La fin de l'expérience en 2018 repose sur un déploiement restreint et sur d'autres usages possibles du codepoint, non sur la réfutation du mécanisme.
Une mesure qui ne tranche pas à elle seule
Quatre serveurs IPv6 utilisaient les deux valeurs ECT. Ce détail aurait pu fournir une conclusion commode : le nonce ECN avait donc été trouvé. Mais le compte rendu repris dans RFC 8311 laisse une autre possibilité ouverte, celle d'un remarquage erroné. L'observation ne portait pas son interprétation avec elle.
Les chiffres concernent une étude fondée sur des données de 2014 : quatre cas parmi 17 028 serveurs IPv6 testés, et aucun parmi 581 711 serveurs IPv4 employant les deux valeurs après négociation ECN. Ce ne sont ni les résultats d'un recensement actuel ni une mesure reproduite ici. Leur intérêt historique est précisément leur portée limitée. Ils éclairent une décision sur l'expérience sans autoriser l'affirmation que personne ne l'avait jamais mise en œuvre.
Cette retenue correspond bien au mécanisme étudié. Le nonce ECN cherchait à produire une preuve étroite de cohérence, pas une connaissance totale de ce qui se passe entre deux extrémités. Pour comprendre le résultat d'un contrôle, il fallait savoir ce qui avait pu être vu, ce qui avait été effacé et ce qui devait rester inconnu.
Le routeur détruit une différence, pas nécessairement le paquet
Dans l'ECN classique défini par RFC 3168, en septembre 2001, le champ de deux bits distingue Not-ECT, codé 00, ECT(1), codé 01, ECT(0), codé 10, et CE, codé 11. Un routeur peut signaler la congestion en marquant CE un paquet compatible, plutôt qu'en le supprimant. Le destinataire rapporte la congestion avec ECE ; l'émetteur indique sa réaction avec CWR.
Pour le routeur classique, ECT(0) et ECT(1) offrent la même possibilité de marquage. Leur remplacement par CE donne donc un résultat identique à partir de deux états différents. Les données arrivent éventuellement intactes, mais le destinataire ne peut plus retrouver, dans le paquet marqué, la valeur ECT d'origine.
L'expérience présentée en juin 2003 dans RFC 3540, par N. Spring, D. Wetherall et D. Ely, fait de cette différence un bit aléatoire. L'émetteur choisit ECT(0) ou ECT(1) et conserve la valeur attendue. Le routeur n'a pas à vérifier un secret ni à demander une autorisation : son marquage ordinaire suffit à faire disparaître le choix initial.
Un destinataire désireux de cacher CE se trouve alors dans une position inconfortable. Il peut prétendre n'avoir rien constaté, mais il doit aussi rendre un résultat compatible avec une information qu'il n'a plus. L'émetteur, lui, dispose encore de son propre relevé. La vérification devient locale, sans transformer le routeur en arbitre du comportement des extrémités.
Une mémoire d'un bit pour plusieurs acquittements
Renvoyer simplement le dernier bit reçu aurait laissé trop de place aux omissions. TCP n'acquitte pas nécessairement chaque paquet séparément. Les acquittements peuvent être retardés ou perdus ; un seul peut faire avancer la confirmation cumulative sur plusieurs segments. Une preuve liée uniquement au dernier paquet oublierait les précédents au moment même où la confirmation les englobe.
Le destinataire additionne donc les valeurs modulo deux, autrement dit calcule leur parité. La somme commence à un et revient dans le drapeau NS. Elle évolue avec les données reçues dans l'ordre que couvre l'acquittement cumulatif. L'émetteur conserve ses sommes attendues en fonction des numéros de séquence de fin des paquets d'origine.
Les données arrivées hors ordre ne contribuent qu'au moment où l'acquittement cumulatif les atteint. Il ne s'agit pas d'un contrôle de contenu, ni d'une somme distincte pour chaque bloc SACK. Les limites des segments comptent : extraire NS d'une capture sans les reconstruire revient à conserver la réponse tout en perdant la question.
Un bit uniforme inconnu laisse une chance sur deux de deviner la bonne parité. Cette probabilité ne garantit pas une détection immédiate. De nouvelles informations aléatoires indépendantes effacées peuvent offrir d'autres occasions de contrôle ; répéter une réponse dépendant du même bit manquant ne crée pas automatiquement des essais indépendants. Le nombre d'acquittements ne suffit donc pas à calculer un degré de certitude.
La parité ne mesure pas non plus toute la congestion. Elle ne fournit ni le nombre exact de marques ni leur chronologie complète. Rendre les retours plus détaillés et les rendre plus difficiles à falsifier sont deux objectifs distincts, même s'ils intéressent le même émetteur.
Quand la bonne réponse devient impossible
La difficulté essentielle apparaît sans aucune malveillance. Le destinataire honnête ne sait pas davantage quel bit se trouvait sous CE. RFC 3540 lui fait ignorer cette valeur manquante, ce qui revient à la traiter comme zéro, tout en signalant normalement la congestion avec ECE. Durant la récupération correspondante, l'émetteur suspend la vérification.
Après sa réduction de fenêtre et l'envoi de nouvelles données avec CWR, il peut reprendre une base commune lorsque l'acquittement approprié arrive. La somme donnée par le destinataire sert à resynchroniser le calcul ; un décalage d'un bit suffit à représenter l'ajustement. L'histoire perdue n'est pas récupérée. Elle cesse seulement de fausser les contrôles futurs.
Cette suspension n'est pas une tolérance envers la fraude. Elle empêche d'accuser un participant pour une information qu'un événement normal du réseau lui a retirée. La frontière entre période vérifiable et période de récupération fait partie de la preuve.
Les règles de 2003 plaçaient aussi les retransmissions en Not-ECT, sans nonce. Les intervalles non-ECT choisis par l'émetteur imposaient de traiter la synchronisation. Il faut garder la date attachée à ces conditions : RFC 8311 a ensuite assoupli les contraintes d'expérimentation touchant notamment les retransmissions et les paquets de contrôle. La règle de l'expérience n'est pas une interdiction universelle actuelle.
Une discordance sans tribunal automatique
RFC 3540 distingue le contrôle de la réaction. Le premier reste facultatif ; la seconde relève d'une politique locale. Lorsqu'une somme incorrecte entraîne une action, le texte envisage au minimum la réaction correspondant à ECE, ainsi que des réductions plus fortes ou l'abandon d'ECT. Il ne prescrit pas un régime uniforme de sanctions.
Plusieurs limites expliquent cette modestie. Un fragment IPv4 non marqué peut révéler le nonce initial alors qu'un autre fragment a été marqué, ce qui affaiblit la protection contre la dissimulation. Des erreurs de bits dans un en-tête IPv6 peuvent produire une somme incorrecte. Des acquittements partiels exigent de tenir compte des limites du segment initial. Dans ces situations, la discordance ne désigne pas à elle seule son responsable.
L'aléa n'a pas besoin d'être de qualité cryptographique, mais ses valeurs futures ne doivent pas être facilement prévisibles à partir des précédentes. La séquence ne doit pas être réemployée pour d'autres usages. Le mécanisme n'apporte pas de protection supplémentaire de l'intégrité de la connexion et ne contraint pas un émetteur malveillant à coopérer.
Même l'indication de prise en charge reste plus étroite qu'une authentification : un NS non nul dans les réponses initiales permet d'inférer le support du nonce, mais le texte précise qu'il ne s'agit pas d'une négociation. Aucun de ces échanges ne certifie une identité institutionnelle ou la bonne conduite de toute la chaîne.
Réserver une signification a un coût
Le contexte des usages alternatifs se précise avec RFC 4774, publié en novembre 2006. Il examine l'identification des nouvelles sémantiques ECN, leur déploiement progressif et leur coexistence avec les routeurs classiques, ceux sans ECN et les trafics concurrents. Un petit champ partagé reste une convention entre implémentations indépendantes, pas une réserve de bits librement réinterprétables.
En août 2015, RFC 7560 traite des exigences de retour de congestion plus précis. Il rapporte alors l'absence de déploiement connu du nonce dans les piles TCP et demande de considérer l'intégrité des retours et les incitations à coopérer. Il n'impose pas de conserver ce mécanisme particulier pour satisfaire ces objectifs.
RFC 8311, en janvier 2018, reconnaît de son côté des déploiements dans des environnements limités et affirme que le nonce fonctionne comme prévu. L'absence d'adoption large, plutôt qu'une invalidation de son principe, fonde la conclusion de l'expérience et le passage de RFC 3540 d'Experimental à Historic. Ces formulations ne sont pas contradictoires si l'on conserve leurs dates et leurs périmètres.
D'autres expériences et d'autres moyens d'assurer l'intégrité rendaient moins défendable la réservation exclusive d'ECT(1). La libération n'autorisait pas n'importe quelle incompatibilité : les expériences permises par RFC 8311 nécessitaient des RFC Experimental appropriés dans le circuit de l'IETF, avec les responsabilités de coexistence et de contrôle de congestion.
Le RFC 9331, Experimental de janvier 2023, donne à ECT(1) un usage différent comme identifiant L4S. Le registre actuel du champ ECN tenu par IANA présente toujours les quatre valeurs et renvoie aux documents d'expérimentation associés. Lire ECT(1) dans un trafic récent ne suffit donc plus à raconter l'expérience de 2003. Cela ne permet pas davantage de déduire ici la diffusion, les performances ou la sécurité générale de L4S.
L'histoire se ferme sur une distinction utile. Une convention publiée peut rester intelligible dans les archives sans conserver éternellement son exclusivité dans les paquets. Et une vérification peut être précieuse précisément parce qu'elle refuse de prétendre davantage que ce que ses données permettent.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
