Résumé

  • Dans les états synchronisés, la RFC 793 acceptait un RST situé dans la fenêtre de réception ; la RFC 5961 réserve la fermeture immédiate à une correspondance exacte avec RCV.NXT.
  • Un RST plausible mais non exact reçoit un challenge ACK puis est abandonné : le véritable pair peut confirmer son état, contrairement à l'émetteur aveugle.

La faille tenait moins à la taille du paquet qu'au pouvoir qu'on lui accordait. Un attaquant hors chemin, incapable de voir une connexion, pouvait essayer des numéros de séquence jusqu'à tomber dans sa fenêtre de réception. Selon la règle de la RFC 793, un RST ainsi placé devenait valide. Une notion conçue pour demander « ces octets appartiennent-ils peut-être au flux ? » répondait aussi à une question bien plus grave : « faut-il supprimer tout l'état de la connexion ? »

La RFC 5961, publiée en 2010, n'a pas greffé une authentification cryptographique sur TCP. Elle a réorganisé la décision. Un RST hors fenêtre reste silencieusement écarté. Si son numéro de séquence est exactement le prochain attendu, RCV.NXT, la connexion est réinitialisée. Entre les deux — dans la fenêtre, mais sans égalité exacte — le récepteur envoie un accusé de réception portant SEQ=SND.NXT et ACK=RCV.NXT, puis jette le segment suspect.

Cette réponse est un « challenge ACK » parce qu'elle transforme une affirmation en épreuve. Si le pair distant a réellement fermé ou redémarré et ne possède plus l'ancien bloc de contrôle, l'ACK reçu peut lui faire émettre un nouveau RST dérivé du numéro d'accusé. Ce second RST peut alors correspondre exactement à l'état du pair survivant. L'attaquant aveugle, lui, ne voit normalement pas le défi et ne sait pas convertir son approximation en réponse exacte.

La rupture conceptuelle est nette. Être dans la fenêtre devient un indice suffisant pour répondre, mais pas une autorisation suffisante pour détruire. Le protocole introduit une action intermédiaire, réversible : demander une confirmation cohérente avec l'état de l'autre extrémité.

La RFC 5961 reprend ce raisonnement pour un SYN inattendu dans un état synchronisé. Au lieu de laisser ce SYN plausible provoquer immédiatement une réinitialisation, le récepteur envoie un challenge ACK, quelle que soit la séquence annoncée, puis cesse de traiter le segment. Un SYN usurpé ne produit en général qu'un ACK supplémentaire, ignoré comme doublon par le pair établi. Un hôte réellement redémarré ne dispose plus du même état et peut répondre de manière à confirmer que l'ancienne connexion doit disparaître.

Il ne faut pas surévaluer cette défense. Elle ne prouve pas l'identité du pair et ne protège pas contre un attaquant placé sur le chemin, capable d'observer les séquences courantes. Le texte signale aussi un cas limite de redémarrage, avec réemploi des mêmes adresse et port et choix fortuit d'un numéro initial particulier. La difficulté d'une attaque aveugle augmente ; TCP ne devient pas pour autant un protocole chiffré.

Les degrés normatifs restent différenciés. Les protections RST et SYN sont recommandées ; le contrôle plus strict de la plage d'ACK contre l'injection de données est facultatif. La RFC 9293, spécification de base actuelle de TCP, conserve le socle général et référence la RFC 5961 comme amélioration de robustesse. La correction historique s'ajoute donc au contrat existant sans effacer les choix antérieurs.

Sources primaires