Résumé

  • La RFC 3360 documente des pare-feu et répartiteurs qui répondaient par RST à un SYN de mise en place ECN parce que les bits ECE et CWR leur étaient inconnus.
  • Le second SYN, dépourvu de ces bits, peut rétablir une connexion ordinaire tout en cachant l’auteur du premier reset, la capacité du serveur et la dette de compatibilité du chemin.

Le tableau de disponibilité affichait vert : la requête avait réussi après une reprise automatique. Le premier SYN, porteur d’ECE et CWR, avait reçu RST. Le second n’annonçait plus ECN ; il avait obtenu SYN-ACK. Pour le lecteur, aucune panne. Pour le protocole, une possibilité venait de disparaître sans ticket.

Publié en août 2002 comme BCP 60, Inappropriate TCP Resets Considered Harmful étudie ce décalage. La RFC 3360 n’est pas une mesure actuelle des équipements. Ses chiffres sont historiques et ne désignent aucun opérateur contemporain. Elle fournit plutôt une méthode pour ne pas confondre résultat final et intégrité du mécanisme qui devait négocier ce résultat.

Un reset possède une force parce qu’il signifie peu de choses

Dans TCP, RST sert à résoudre des contradictions d’état précises. Un segment paraît destiné à une connexion inexistante, ou une demande arrive là où aucune connexion ne peut l’accepter : le reset permet au récepteur d’abandonner rapidement et d’en informer l’application. RFC 793 formulait cette limite ; RFC 9293 a depuis consolidé les règles de génération et de validation.

Un pare-feu peut légitimement appliquer une politique. RFC 2979 reconnaît ce pouvoir. Mais le signal choisi détermine ce que l’autre extrémité croit savoir. Utiliser RST pour dire « je ne reconnais pas ces bits » fait passer un choix du chemin pour un verdict de l’hôte distant.

La RFC 3360 distingue ce cas du refus d’un port entièrement bloqué. Le problème apparaît quand l’équipement laisse passer le protocole, mais détruit une forme valide de ce protocole et parle avec la grammaire de l’extrémité. L’autorité locale n’est pas contestée ; son attribution est brouillée.

ECN dépendait de la tolérance des acteurs qui ne négociaient pas

La RFC 3168 utilise ECE et CWR, alloués dans l’ancien champ Reserved, pour proposer ECN dans le SYN. Une extrémité compatible peut répondre par un SYN-ACK ECN. Une pile TCP sans ECN doit ignorer les bits inconnus et répondre normalement. Le dispositif permet aux deux hôtes de décider sans exiger que chaque intermédiaire comprenne la fonction.

Certains intermédiaires ont pourtant envoyé RST ou supprimé le paquet. La RFC 3360 rapporte qu’en mars 2002, 203 sites sur 12 364 testés répondaient par reset et 420 ne répondaient pas au SYN ECN. Il s’agit d’un relevé de l’époque, non d’un taux transposable. Il démontre qu’un troisième acteur pouvait empêcher la découverte mutuelle des capacités.

Une capture côté client ne suffit pas à identifier cet acteur. Une adresse source plausible, un ACK cohérent et une faible latence ne sont pas une signature. Il faut des points d’observation répartis, la configuration du dispositif contrôlé ou une comparaison de chemins reproductible avant d’écrire que « le serveur a refusé ECN ».

Le repli échange de l’information contre de la continuité

La procédure de compatibilité autorise un nouvel essai après RST : ECE et CWR sont effacés, puis un SYN ordinaire est envoyé. Si le second essai réussit, TCP fonctionne sans ECN. Un nouveau reset doit alors être traité comme un refus normal.

Le premier RST devient donc provisoire pour cette branche. Cela protège l’accès, mais oblige à reconnaître ce qui a été dépensé. Le reset pouvait être authentique. La première tentative pouvait simplement avoir été perdue. Le serveur pouvait parfaitement prendre en charge ECN tandis que le chemin l’empêchait de le montrer. Et l’application peut n’exposer que le succès final.

La RFC relate les objections des implémenteurs : accepter le contournement signifie parfois ignorer un reset valable, désactiver ECN après une perte ordinaire, ajouter plusieurs secondes de délai et stabiliser les équipements défectueux. L’échec cesse alors d’être un événement qui appelle une correction ; il devient une propriété permanente du client.

TCP Fast Open rencontrera plus tard une difficulté voisine. La RFC 7413 prévoit un retour à la poignée de main classique lorsque des options inconnues ou des données dans le SYN sont supprimées. Le service survit. La capacité, elle, peut mourir en silence.

Valider le paquet ne désigne pas son auteur légitime

La RFC 5961 renforce la résistance aux resets aveugles sur les connexions établies. Un RST situé dans la fenêtre mais ne portant pas exactement le prochain numéro attendu déclenche un challenge ACK. L’autre extrémité peut confirmer sa décision par un second reset correct.

Cette amélioration porte sur la recevabilité du segment. Elle ne dit pas pourquoi un RST qui acquitte le SYN initial a été créé, ni si un middlebox a parlé à la place du serveur. La même RFC décrit d’ailleurs des cas où un intermédiaire rejoue un ancien reset, provoque une boucle ACK/RST ou supprime le challenge après avoir détruit son propre état.

La syntaxe, la provenance et l’autorité sont trois preuves. Les fusionner donne à tout appareil capable de forger un paquet plausible le pouvoir d’énoncer l’état d’un hôte.

L’exception privée finit par définir TCP

La mise en garde générale de RFC 3360 concerne l’ossification. Une nouvelle utilisation de bits réservés peut recevoir l’approbation de l’IETF et rester inutilisable si les chemins installés la refusent. Le marché récompense alors le logiciel qui évite la nouveauté, pas l’équipement qui respecte l’extension.

Les RFC 6709 et 9170 expliquent pourquoi un point d’extension doit être activement exercé. Une valeur qui ne change jamais encourage des implémentations à confondre l’échantillon observé avec la totalité du protocole. Plus l’intolérance dure, plus sa suppression exige de coordination.

GREASE, défini par RFC 8701 pour TLS, introduit volontairement des valeurs inconnues afin de révéler tôt cette intolérance. Ce n’est pas une preuve que la même technique convient partout. C’est la reconnaissance qu’une capacité d’évolution non testée n’est qu’une promesse de document.

La doctrine de Heng Lu ajoute une limite institutionnelle utile : spécification initiale minimale, décisions futures localisées, adoption volontaire. L’opérateur peut refuser une capacité. Il ne devrait pas transformer cette décision locale en faux fait distant. Quand le refus prend la forme indifférenciée d’un reset du serveur, l’intermédiaire obtient un veto sans laisser de décision révisable.

Les preuves nécessaires après un succès dégradé

Il faut d’abord conserver le SYN original, ses flags, options, adresses et heure. Ensuite, situer les observations avant et après les équipements contrôlés. Le RST doit être validé comme paquet sans être promu en preuve d’identité.

Si le blocage correspond à une politique, son propriétaire, sa version, son motif, son approbation et sa date de réexamen doivent être liés à l’événement. Le repli doit indiquer son déclencheur : reset, timeout ou essai manuel. Le second SYN doit viser le même service et, si l’on compare des capacités, traverser un chemin équivalent.

Une réparation se prouve en rejouant la tentative avec extension. Le paquet atteint l’hôte prévu, la réponse reflète la capacité réelle de cet hôte, les données passent dans le mode négocié et une sonde applicative observe le résultat. Une mise à jour logicielle ou une règle supprimée n’est qu’une action jusqu’à cette observation.

Les chemins alternatifs doivent rester séparés. Le succès par un accès ne répare pas un autre accès qui contient encore l’intermédiaire intolérant.

Limites du dossier

Les sources n’établissent ni fréquence actuelle, ni comportement d’un fournisseur nommé, ni incident en cours. Elles ne disent pas que chaque RST reçu après un SYN ECN est illégitime. Elles ne donnent pas à tous les bits inconnus un droit de passage absolu.

Une connexion sans ECN ne prouve pas l’incapacité du serveur. Une négociation ECN réussie ne prouve pas un marquage de congestion, un retour au sender, une réaction de fenêtre ou un bénéfice applicatif. Ces résultats appartiennent aux étapes suivantes.

Le verdict porte uniquement sur la comptabilité de la compatibilité : lorsque le repli sauve l’utilisateur, l’organisation doit encore compter et réparer le mécanisme qu’il a dû abandonner.

Sources