Résumé

  • Le cookie TCP Fast Open est une preuve produite par le serveur et liée au contexte de l’adresse IP source ; ce n’est ni une identité utilisateur ni un identifiant de requête.
  • Un TFO valide peut livrer les données du SYN à l’application avant la fin de la poignée de main, tout en conservant le rare risque de remise en double décrit par la RFC 7413.
  • Un registre d’exécution doit relier séquences de transport, principal authentifié, identité de requête, déduplication, commit et réponse.

Le chemin rapide s’est arrêté avant la réponse métier

Un client envoie une réservation dans le SYN avec un cookie en cache. Le serveur valide le cookie, met les données en mémoire tampon, avertit l’application et acquitte SYN et données. La réponse utile n’arrive pas au client, qui renvoie ensuite la même demande logique.

Le cookie ne dit pas si la seconde arrivée répète la première. L’acquittement TCP ne dit pas qu’un commit durable a été achevé, qu’une autorisation a réussi ou qu’une réponse a atteint le client. Le transport peut être correct alors que l’issue métier reste inconnue.

La portée exacte du cookie

La RFC 7413 définit une valeur opaque générée par le serveur. Sa construction recommandée authentifie l’adresse IP source du SYN et empêche le client de la fabriquer. Le serveur peut accepter plusieurs cookies, y intégrer des données privées à son implémentation et les faire expirer à tout moment.

Cette portée limite certaines attaques par adresse usurpée ; elle n’authentifie pas une personne. Une adresse peut être partagée, traduite ou réattribuée. Un cookie valide signifie que le serveur accepte ce contexte IP pour Fast Open selon sa politique du moment, pas qu’il connaît l’auteur du contenu.

L’application doit activer TFO explicitement pour chaque port de service. Le serveur peut le désactiver ou refuser de nouvelles ouvertures rapides lorsque sa limite de requêtes en attente est atteinte. Validité du cookie, admission du listener et autorisation applicative sont trois décisions distinctes.

Admission, abandon et repli

Avec un cookie valide, le serveur peut remettre les données du SYN à l’application et les acquitter. Si le cookie est invalide ou TFO indisponible, il abandonne ces données et n’acquitte que le SYN ; le client retransmet alors les octets non acquittés après la poignée de main.

Des intermédiaires peuvent supprimer les SYN avec charge utile ou option inconnue. Après expiration du délai, la RFC 7413 prévoit un repli vers un SYN ordinaire qui ne transporte ni données ni option Fast Open. Le MSS mis en cache compte aussi, car les données partent avant l’annonce du MSS courant ; un excès entraîne une retransmission.

Un tableau de bord « TFO utilisé » masque donc plusieurs branches : données livrées tôt, données écartées, ou données renvoyées en TCP ordinaire.

Un ACK TCP reste une preuve de transport

La RFC 9293 donne à chaque octet un numéro de séquence et définit l’acquittement cumulatif. L’ACK confirme la réception des octets par le pair TCP. Il ne certifie pas la validation des identifiants, l’autorisation, l’écriture en base ou la réponse métier.

La RFC 7413 avertit en outre que les données du SYN peuvent, rarement, être remises plusieurs fois à l’application. Les opérations placées dans les données précoces doivent donc supporter ce risque, avec identifiant stable, portée de déduplication et résultat récupérable.

Sources