Résumé

  • TIME-WAIT est une frontière temporelle : après une fermeture active, le RFC 9293 impose de conserver l’état pendant deux durées maximales de segment afin que les paquets de l’ancienne connexion ne contaminent pas la suivante.
  • Dans le scénario du RFC 1337, un ancien segment irrecevable déclenche un ACK ; le pair déjà fermé répond par un RST, et l’acceptation de ce RST supprime TIME-WAIT avant la fin de la quarantaine.

Le mémo démontre trois conséquences possibles après une réouverture rapide, mais dans une simulation volontairement extrême. Il établit une possibilité, non la fréquence actuelle du phénomène.

Une application peut avoir terminé alors que le réseau transporte encore des fragments de son passé. Un segment de données retardé peut attendre derrière un lien congestionné. Un ACK dupliqué peut emprunter une route plus longue. Aucun de ces paquets ne sait que les sockets ont été fermés ni que le même couple d’adresses et de ports pourra bientôt désigner une autre connexion.

TIME-WAIT empêche ces deux histoires de se confondre. Le pair qui ferme activement ne détruit pas immédiatement son bloc de contrôle : il garde assez de mémoire pour protéger la prochaine incarnation. Le RFC 9293 rend ce coût obligatoire. L’extrémité doit rester dans TIME-WAIT pendant deux fois la durée maximale de vie d’un segment, ou 2xMSL. L’attente n’est pas un nettoyage différé ; elle laisse aux anciens paquets le temps de disparaître avant une réutilisation du même quadruplet.

Le RFC 1337 part d’une observation plus gênante : le mécanisme de quarantaine pouvait être supprimé par les réactions ordinaires de TCP face à un trafic périmé.

Une réponse exacte qui provoque le mauvais reset

Le scénario commence lorsqu’un ancien segment de données ou d’acquittement atteint l’extrémité A, encore en TIME-WAIT. Le segment est irrecevable, par exemple parce que son numéro de séquence ou son horodatage appartient à une autre incarnation. A répond correctement avec un ACK portant ses valeurs courantes SND.NXT et RCV.NXT.

L’extrémité B, elle, a déjà oublié la connexion. Elle reçoit donc un ACK pour un état qu’elle ne possède plus et le renvoie sous la forme d’un RST. Si A traite ce reset comme une raison de quitter TIME-WAIT, elle supprime précisément l’état qui devait survivre aux anciens paquets. Le segment périmé n’a pas ordonné directement la fermeture. Il a amené A à parler, puis la réponse exacte de A a conduit un pair sans état à produire le signal destructeur. Le RFC 1337 appelle cette chaîne « TIME-WAIT Assassination ».

L’assassinat ne signifie pas encore qu’une nouvelle application a reçu de mauvaises données. Il retire la protection qui empêchait cette erreur. Pour que le danger se matérialise, le même identifiant de connexion doit être réutilisé avant la disparition des duplicatas et les espaces de séquence de l’ancienne et de la nouvelle incarnation doivent se recouvrir suffisamment. Un ancien paquet doit ensuite tomber dans une plage que le nouveau contexte juge recevable.

Le mémo distingue trois issues. H1 est l’acceptation erronée de données anciennes. H2 est une désynchronisation : dans le comportement spécifié à l’époque, les deux extrémités peuvent acquitter un état qui n’a jamais été envoyé et entrer dans une boucle d’ACK permanente. H3 est la mort de la nouvelle connexion, lorsqu’un ancien segment rencontré pendant l’ouverture conduit au reset d’une connexion qui semblait avoir réussi.

Ces conditions expliquent pourquoi le texte qualifie H1, H2 et H3 de moins probables que l’assassinat lui-même. Il faut non seulement supprimer TIME-WAIT, mais aussi rouvrir assez vite, recouvrir les espaces de séquence et recevoir le mauvais duplicata au bon endroit. Le RFC 1337 a reproduit les quatre phénomènes sur une pile SunOS 4.1.1 dans un environnement simulé qui dupliquait massivement les segments et dont les paramètres avaient été ajustés pour provoquer les coïncidences. Il présente le résultat comme une preuve d’existence. Ce n’est ni une mesure d’incidence actuelle ni une accusation contre une pile moderne nommée.

Trois remèdes, trois limites différentes

Le premier remède du RFC 1337 est aussi le plus direct : ignorer les RST pendant TIME-WAIT. Si la MSL de deux minutes retenue par le mémo est effectivement appliquée, le texte estime que ce choix évite H1, H2 et H3. L’argument est structurel. Puisque TIME-WAIT sert à laisser mourir les anciens segments, un segment non authentifié ne devrait pas pouvoir écourter cette période.

Le document reste pourtant prudent. Il est publié à titre informatif et demande un essai prolongé en production pour repérer d’éventuels effets indésirables. Il ne prouve pas que toutes les implémentations ont adopté cette règle ni qu’ignorer tout reset dans cet état est sans conséquence dans chaque architecture.

La deuxième piste emploie PAWS et les horodatages TCP. Si TIME-WAIT résiste assez longtemps pour que les horloges avancent, les nouveaux SYN portent des valeurs supérieures à celles des anciens segments ; les vieilles données peuvent alors être rejetées. Mais le remède reste partiel. Lorsqu’un ancien ACK arrive en TIME-WAIT, l’extrémité peut générer son propre ACK avec un horodatage courant. Ce « nouveau vieux duplicata » est susceptible de franchir le contrôle PAWS après la réouverture. H1 peut être bloqué sans que H2 et H3 disparaissent nécessairement.

La troisième piste élargit l’espace de séquence à 64 bits. Une telle largeur réduirait fortement la possibilité de réutiliser rapidement le même espace, mais elle n’empêcherait pas le RST de supprimer TIME-WAIT. Le RFC 1337 n’y voit donc pas un correctif autonome : il faudrait aussi modifier les paramètres qui séparent les incarnations, au prix d’un changement majeur du protocole.

Le contrat actuel conserve la tension

Le RFC 9293, norme Internet actuelle de base pour TCP, maintient le principe de l’attente. Après une fermeture active, une extrémité doit rester en TIME-WAIT pendant 2xMSL. Elle peut accepter directement un nouveau SYN du même pair, mais seulement si elle choisit un nouvel ISN supérieur au plus grand numéro utilisé précédemment et revient en TIME-WAIT si le SYN s’avère être un ancien duplicata. Le texte recommande aussi un algorithme amélioré fondé sur les horodatages pour les serveurs qui établissent beaucoup de connexions.

Le même automate de base conserve cependant la sortie qui rend le problème intéressant : après les vérifications de recevabilité, un RST traité en TIME-WAIT fait entrer dans CLOSED et supprime le bloc de contrôle. À l’inverse, la retransmission du FIN distant est acquittée et redémarre la temporisation 2xMSL. Deux paquets de contrôle peuvent donc prolonger ou interrompre la frontière selon la branche qu’ils empruntent.

Cette juxtaposition interdit les slogans simples. « Réduire TIME-WAIT » ne décrit pas la preuve utilisée pour séparer les incarnations. « Garder davantage d’état » ne dit pas si cet état résiste aux signaux qui peuvent le supprimer. Le mécanisme pose une question d’autorité : quelle observation suffit pour déclarer qu’une quarantaine destinée à survivre à du trafic ancien non authentifié peut être levée sans attendre ?

Les seules sources de ce paquet sont le RFC 1337, publié à titre informatif en mai 1992, et le RFC 9293, norme Internet publiée en août 2022. Elles décrivent le mécanisme, ses conditions et les règles de base ; elles ne documentent ni la fréquence contemporaine du phénomène ni le comportement d’un produit précis.