Résumé

  • Un SYN cookie place dans le numéro de séquence du SYN-ACK assez d’informations vérifiables pour différer la création d’un état SYN-RECEIVED jusqu’au retour du troisième ACK.
  • Le reçu prouve qu’un acteur a récemment eu accès au chemin de retour du quadruplet concerné. Il ne prouve ni l’identité d’une personne, ni la bienveillance du client, ni la capacité de l’application à le servir.
  • Le champ de 32 bits impose un budget d’information. L’activation, les options conservées, les pertes de fidélité et les ressources encore exposées doivent être vérifiées sur la pile réellement en production.

Un serveur TCP à l’écoute prend normalement une première décision avant d’avoir reçu une réponse de son interlocuteur. Le SYN entrant le fait passer en SYN-RECEIVED. Il choisit son numéro de séquence, prépare un SYN-ACK et conserve les éléments de la tentative dans une file d’ouvertures incomplètes. Ce n’est qu’au troisième message que le client montre qu’il a vu la réponse du serveur.

Cette avance rend la poignée de main utile, mais elle crée aussi une dette. Chaque adresse source peut demander au serveur de retenir un peu de mémoire et un délai de retransmission sans jamais revenir. Une attaque par SYN flood accumule ces dettes jusqu’à remplir la ressource bornée qui reçoit les connexions embryonnaires. Le résultat visé est le refus de nouveaux clients légitimes, même si le réseau, l’application et les connexions déjà établies disposent encore de capacité.

Le RFC 4987 insiste sur cette précision. Une saturation de l’état d’établissement n’est pas automatiquement une saturation de lien, de processeur ou de tout le service. La distinction compte, car chaque remède protège un budget différent. Agrandir la file achète du temps au prix de davantage de mémoire exposée. Réduire les délais récupère plus vite les entrées, mais pénalise les chemins lents ou soumis aux pertes. Éliminer les plus anciennes demandes laisse l’âge décider à la place de la validité. Un SYN cache conserve un dossier plus petit. Un proxy assume l’ouverture ailleurs et déplace le coût vers un autre composant.

Le SYN cookie choisit une voie plus nette : ne pas créer de dossier explicite après le premier paquet. Le serveur fabrique à la place un numéro de séquence initial qui contient une représentation compacte de l’échange et un contrôle dépendant d’un secret local. Les constructions décrites historiquement associent le quadruplet d’adresses et de ports, le numéro initial du client, un compteur temporel lent, une classe de MSS et des secrets connus du serveur. L’algorithme exact reste une propriété de l’implémentation.

Le client n’a pas à connaître cette mécanique. Pour lui, le SYN-ACK demeure un message TCP ordinaire. Il renvoie un ACK portant le numéro du serveur augmenté de un. À l’arrivée, le serveur retrouve la valeur qu’il avait émise, examine les fenêtres temporelles encore acceptables et recalcule la fonction secrète à partir du tuple observé. Si le résultat concorde, il reconstruit assez d’état pour créer la connexion ESTABLISHED. Sinon, il peut rejeter le paquet sans chercher une entrée embryonnaire qui n’a jamais existé.

La métaphore correcte est celle d’un reçu, non d’un passeport. Le serveur remet une preuve qu’il saura reconnaître sans garder la transaction en mémoire. Le retour de cette preuve indique que quelqu’un a reçu, observé ou appris le SYN-ACK récent destiné à ce tuple. Cette information suffit pour une décision locale d’allocation. Elle ne nomme pas l’utilisateur, ne lie pas une entreprise, ne constitue pas une autorisation applicative et ne garantit pas que la connexion suivante sera bon marché.

Le secret protège le reçu contre la fabrication aveugle. Il ne transforme pas TCP en protocole d’identité. Un adversaire situé sur le chemin peut voir l’échange. Un parc de machines utilisant de vraies adresses peut rendre des cookies valides. Un client admis peut ensuite consommer une négociation TLS, un processus, une connexion de base de données ou un quota métier. Le mécanisme déplace la frontière de dépense ; il ne supprime pas la dépense.

Cette compression a un prix concret. Le numéro de séquence initial ne contient que 32 bits et doit continuer à jouer son rôle dans TCP. Une fiche normale pourrait retenir toutes les options du premier SYN. Un cookie de base doit réserver de la place à la fraîcheur, à la vérification et à quelques paramètres indispensables. Les schémas historiques utilisaient par exemple un petit index vers une liste de tailles MSS fréquentes. Ce qui n’est ni encodé ni déductible du troisième ACK n’est plus disponible lors de la reconstruction.

Window Scale rend cette limite visible. Le RFC 7323 prévoit que l’option n’est échangée que dans les segments portant SYN et que son facteur est fixé pour chaque direction à l’ouverture. Si le serveur oublie l’offre du client et ne possède aucune extension de cookie pour la récupérer, il ne peut pas la négocier après coup. Le RFC 4987 décrit donc les concessions des mécanismes de base sur Window Scale, SACK et d’autres paramètres, mais il présente aussi une technique FreeBSD qui utilisait des bits renvoyés dans Timestamp pour transporter davantage d’état.

Deux généralisations sont alors interdites. On ne peut pas dire que tous les SYN cookies perdent toujours les mêmes options. Des piles modernes récupèrent davantage d’information par des encodages propres. On ne peut pas davantage supposer que toute option survit parce qu’une implémentation a trouvé de la place. Le contrat réel est celui du noyau, de la version, de l’accélérateur, du répartiteur et du chemin qui reçoit effectivement les paquets.

La perte du troisième ACK révèle une autre différence. Dans un protocole où le serveur parle en premier, comme SMTP, le client peut croire l’ouverture terminée après avoir envoyé son ACK puis attendre la bannière. Si cet ACK disparaît, le serveur sans état n’a aucune fiche permettant de retransmettre sa décision et n’a pas prévenu l’application. Les retransmissions suivantes et la pile choisie déterminent la récupération. Protéger la mémoire peut donc déplacer le côté qui constate l’échec en premier.

Une exploitation hybride respecte mieux cette diversité qu’un réglage permanent. En régime normal, un SYN cache ou la file ordinaire conserve un état riche et les comportements habituels. Sous pression, lorsque le seuil local déborde, la pile peut émettre des cookies au lieu d’évincer des demandes déjà présentes. Le cookie devient alors une politique de secours pour une ressource précise, assortie d’un point d’entrée et d’un point de sortie mesurables.

La documentation actuelle du noyau Linux formule explicitement cette limite. tcp_syncookies est présenté comme un repli lorsque la file SYN d’un socket déborde, et non comme un moyen de faire accepter à une machine sous-dimensionnée un taux légitime de connexions. tcp_max_syn_backlog décrit séparément le nombre de demandes SYN_RECV mémorisées par écouteur. Si la demande normale déclenche constamment le repli, l’opérateur doit examiner la capacité, les files et les délais au lieu de rebaptiser le manque de ressources en défense.

Même un cookie parfait ne protège pas les interruptions, le débit sortant des SYN-ACK, le calcul de la fonction secrète ou la validation des ACK. Il ne réserve pas de place dans la file d’acceptation. Il ne finance ni les négociations cryptographiques, ni les workers, ni les bases de données. Une attaque distribuée avec de vraies piles peut compléter chaque poignée de main et porter la pression après la frontière que le cookie vient de fortifier.

Le filtrage des adresses sources reste complémentaire. BCP 38 et BCP 84 réduisent la capacité d’un réseau à exporter des paquets usurpés et donc à faire envoyer des réponses vers des adresses fictives. Ils ne font pas disparaître les clients réels malveillants ni les pointes légitimes. L’amont décide quels paquets il accepte d’émettre ; le serveur décide quand il engage sa mémoire. Aucune de ces autorités ne remplace l’autre.

Les mesures doivent refléter la même séparation. Le RFC 4898 distingue la file embryonnaire, l’allocation complète des ressources et l’acceptation par l’application. Il note qu’un système utilisant des SYN cookies ne possède pas nécessairement de représentation explicite de l’état SYN-RCVD encodé. Une courbe montrant zéro entrée à demi ouverte peut donc signifier soit le calme, soit le fait que la machine a cessé de se souvenir.

Il faut rapprocher les taux de SYN, de SYN-ACK et de retransmission, les débordements, les cookies émis, les retours valides, invalides ou périmés, les connexions établies, la file d’acceptation et les admissions applicatives. Il faut aussi échantillonner MSS, Window Scale, SACK, Timestamp, ECN et Fast Open dans les connexions issues du repli. Sans mesure du changement de mode, la disparition de l’état devient une disparition de l’évidence.

TCP Fast Open complique encore l’hypothèse. Le RFC 7413 autorise des données applicatives dans le SYN selon un autre mécanisme de cookie et d’autres règles de rejeu. Rien ne permet de supposer qu’un repli SYN-cookie classique conserve ces données et leur sémantique. Le mélange d’options doit être testé avec le frontal, le noyau et les éventuels chemins d’offload déployés.

SCTP montre ce que permet un protocole qui réserve dès l’origine un contenant à l’état différé. Le RFC 9260 place dans sa poignée de main à quatre messages un State Cookie de longueur variable, protégé par MAC, horodaté et limité dans le temps. Ce cookie n’est ni le format ni l’algorithme de TCP. Il illustre seulement qu’une admission sans état garde plus fidèlement la négociation quand le protocole lui offre un espace dédié au lieu de comprimer une conversation évolutive dans un numéro de séquence.

La spécification commune peut décrire les invariants de l’échange et les compromis connus. Elle ne connaît pas la mémoire d’un écouteur précis, ses temps de trajet, ses options indispensables ou le coût de son application. Le principe de spécification initiale minimale de Heng Lu laisse donc à l’opérateur la décision de seuil et la perte acceptable. La primauté du code en exécution impose ensuite la preuve : une valeur de configuration n’est qu’une intention tant que les connexions observées n’ont pas montré ce qui a réellement été conservé.

Sources