Annexe A. Comparaison avec les TCP Cookies (SYN Cookies)

Cette annexe compare en détail les mécanismes TCP Fast Open (TFO) et TCP SYN Cookies, afin d'aider à comprendre leurs objectifs différents et leurs cas d'utilisation.

A.1. Vue d'ensemble (Overview)

Bien que TFO et les SYN Cookies utilisent tous deux le concept de « cookie », ils servent des objectifs complètement différents :

TFO (TCP Fast Open) :
Objectif : réduire la latence de connexion, améliorer les performances
Mécanisme : cookie pré-alloué, permet les données SYN
État : avec état (cookie mis en cache)

SYN Cookies :
Objectif : défense contre les attaques SYN Flood, protection du serveur
Mécanisme : réponse sans état, informations encodées dans l'ISN
État : sans état (ne sauvegarde pas l'état SYN-RECEIVED)

A.2. Comparaison des objectifs de conception (Design Goals Comparison)

TCP Fast Open (TFO)

Objectifs principaux :

Optimisation des performances : réduire la latence d'établissement de connexion TCP
Compatibilité ascendante : coexister avec les implémentations TCP existantes
Sécurité : ne pas réduire la sécurité de TCP

Cas d'utilisation :

Dans des conditions réseau normales
Lorsque le client et le serveur supportent tous deux TFO
Applications sensibles à la latence (Web, API)

TCP SYN Cookies

Objectifs principaux :

Défense contre les SYN Flood : résister aux attaques DoS
Conception sans état : ne pas consommer de ressources serveur
Mesure d'urgence : activation automatique en cas d'attaque

Cas d'utilisation :

Pendant les attaques SYN Flood
Lorsque les ressources du serveur sont sous pression
Comme mécanisme de protection de dernier recours

A.3. Comparaison des mécanismes techniques (Technical Mechanisms)

Cookie TFO :

# Pré-généré, stocké de manière persistante
TFO_Cookie = Encrypt(ServerSecret, ClientIP || Timestamp)

Caractéristiques :
- Généré activement par le serveur et envoyé au client
- Le client met en cache le cookie pour les connexions suivantes
- Le cookie a une durée d'expiration explicite (heures à jours)
- Utilise des algorithmes de chiffrement robustes (par exemple AES-128)

SYN Cookie :

# Calculé dynamiquement et encodé dans l'ISN, pas besoin de stockage
SYN_Cookie = Hash(ServerIP, ServerPort, ClientIP, ClientPort, 
                  Timestamp, ServerSecret) + MSS_encoding

Caractéristiques :
- Calculé instantanément à la réception du SYN
- Encodé dans le numéro de séquence initial (ISN)
- Durée de validité très courte (ordre de la minute)
- Utilise des fonctions de hachage rapides

Gestion de l'état

Gestion de l'état TFO :

Client :
  ├─ Met en cache le cookie pour chaque serveur
  ├─ Suit la durée d'expiration du cookie
  └─ Stocké dans un stockage persistant (par exemple disque)

Serveur :
  ├─ État de connexion TCP normal (TCB)
  ├─ Vérifie le cookie reçu
  └─ Optionnel : suit les statistiques d'utilisation des cookies

Gestion de l'état SYN Cookies :

Client :
  └─ Aucun traitement spécial requis (TCP standard)

Serveur :
  ├─ Ne crée pas d'état SYN-RECEIVED
  ├─ Vérifie le numéro de séquence retourné dans l'ACK
  └─ Crée l'état ESTABLISHED uniquement après vérification réussie

Flux d'établissement de connexion

Établissement de connexion TFO :

Client                                Serveur
   |                                    |
   | SYN + cookie TFO + données         |
   |---------------------------------->|
   |                                    | (vérification du cookie, acceptation des données)
   |                                    | (création TCB, entrée dans SYN-RECEIVED)
   | SYN-ACK (+ données optionnelles)  |
   |<----------------------------------|
   |                                    |
   | ACK                                |
   |---------------------------------->|
   |                                    | (entrée dans ESTABLISHED)
   
Avantage : économie de 1 RTT, données transmissibles pendant la poignée de main

Établissement de connexion SYN Cookies :

Client                                Serveur
   |                                    |
   | SYN                                |
   |---------------------------------->|
   |                                    | (calcul du SYN Cookie)
   |                                    | (pas de création de TCB)
   | SYN-ACK (ISN = SYN Cookie)        |
   |<----------------------------------|
   |                                    |
   | ACK (ACK = ISN + 1)               |
   |---------------------------------->|
   |                                    | (vérification du SYN Cookie)
   |                                    | (création TCB, entrée dans ESTABLISHED)
   
Avantage : sans état, ne consomme pas de mémoire, résiste aux SYN Flood

A.4. Comparaison des fonctionnalités (Feature Comparison)

Fonctionnalité	TFO	SYN Cookies	Remarque
Objectif principal	Optimisation des performances	Protection de sécurité	Intentions de conception différentes
Transmission de données SYN	✓ Supporté	✗ Non supporté	Fonctionnalité centrale de TFO
Type d'état	Avec état	Sans état	L'absence d'état est la clé des SYN Cookies
Latence de connexion	Réduite de 1 RTT	3-way standard	Avantage de performance TFO
Ressources serveur	Consommation normale	Très faible consommation	Les SYN Cookies économisent les ressources
Conservation des options TCP	Complète	MSS uniquement	Limitation des SYN Cookies
Mise à l'échelle de fenêtre	✓ Supporté	✗ Limité	Les SYN Cookies perdent des options
Support SACK	✓ Supporté	✗ Limité	Idem
Option d'horodatage	✓ Supporté	✗ Limité	Idem
Support ECN	✓ Supporté	✗ Limité	Idem
Durée de validité du cookie	Heures-jours	Minutes	Cookie TFO persistant
Cache côté client	✓ Requis	✗ Non requis	TFO nécessite le support client
Protection contre les attaques	Modérée	Très forte	SYN Cookies conçus pour la défense
Complexité de déploiement	Modérée	Faible	SYN Cookies plus simples

A.5. Comparaison de l'impact sur les performances (Performance Impact)

Dans des conditions normales

TFO :

Première connexion :
   Latence : 1,5 RTT (identique au TCP standard)
   
Connexions suivantes :
   Latence : 0,5 RTT (économie de 1 RTT)
   Amélioration des performances : 15-40 % (requêtes HTTP)

SYN Cookies :

Toutes les connexions :
   Latence : 1,5 RTT (identique au TCP standard)
   
Effets secondaires :
   - Perte des options TCP (mise à l'échelle de fenêtre, SACK, etc.)
   - Peut affecter les performances des connexions longues
   - Limitation de l'encodage MSS (ne peut représenter qu'un nombre limité de valeurs MSS)

Dans des conditions d'attaque

TFO :

Sous SYN Flood :
   Problèmes :
   - Doit encore vérifier le cookie (consomme du CPU)
   - Peut accepter des données SYN (consomme de la mémoire)
   - L'attaquant peut abuser du mécanisme de cookie
   
   Contre-mesures :
   - Limiter la taille des données SYN
   - Limitation de débit
   - Désactiver TFO si nécessaire

SYN Cookies :

Sous SYN Flood :
   Avantages :
   - Complètement sans état, ne consomme pas de mémoire
   - Calcul rapide, faible consommation CPU
   - Résistance automatique aux attaques
   
   Compromis :
   - Fonctionnalités limitées (perte des options TCP)
   - Mais le service reste disponible

A.6. Comparaison de la sécurité (Security Comparison)

Considérations de sécurité TFO

Mécanismes de protection :

✓ Cookie lié à l'adresse IP
✓ Chiffrement et expiration du cookie
✓ Limitation de la taille des données SYN
✓ Limitation de la taille de la réponse SYN-ACK
✓ Limitation de débit

Menaces :
✗ Peut être utilisé pour des attaques par amplification
✗ Nécessite une surcharge de vérification supplémentaire
✗ Le cookie peut être rejoué (exigence d'idempotence)

Cas d'utilisation appropriés :

Environnement réseau normal
Clients de confiance
Besoin d'optimisation des performances

Considérations de sécurité SYN Cookies

Mécanismes de protection :

✓ Complètement sans état
✓ Calcul rapide
✓ Activation automatique (détection d'attaque)
✓ Ne consomme pas de ressources serveur

Limitations :
✗ Fonctionnalités limitées (perte des options TCP)
✗ Encodage MSS limité
✗ Ne supporte pas les extensions TCP

Cas d'utilisation appropriés :

Pendant les attaques SYN Flood
Ressources serveur sous pression
Comme mesure de protection d'urgence

A.7. Compatibilité et déploiement (Compatibility and Deployment)

Déploiement TFO

Exigences :

Client :
  ├─ Nécessite le support du noyau ou de l'application
  ├─ Nécessite un mécanisme de cache de cookies
  └─ Nécessite la capacité de repli vers le TCP standard

Serveur :
  ├─ Nécessite le support du noyau ou de l'application
  ├─ Nécessite la génération et la vérification des cookies
  └─ Nécessite configuration et gestion

Réseau :
  └─ Les équipements intermédiaires peuvent supprimer les options TCP

État du déploiement :

Support Linux 3.6+
Support progressif des principaux systèmes d'exploitation
Nécessite l'activation par les applications

Déploiement SYN Cookies

Exigences :

Client :
  └─ Aucune modification requise (transparent)

Serveur :
  ├─ Support au niveau du noyau
  ├─ Configurable (activation/désactivation)
  └─ Généralement activé par défaut

Réseau :
  └─ Complètement transparent, sans impact

État du déploiement :

Support par tous les principaux systèmes d'exploitation
Largement déployé, activé par défaut
Technologie mature et stable

A.8. Coexistence et coopération (Coexistence and Cooperation)

TFO et SYN Cookies peuvent coexister

Configuration recommandée :

En fonctionnement normal :
  ├─ TFO : activé (optimisation des performances)
  └─ SYN Cookies : activés mais non déclenchés (secours)

Attaque légère :
  ├─ TFO : continue de fonctionner (avec limitation de débit)
  └─ SYN Cookies : commencent à s'activer (connexions partielles)

Attaque sévère :
  ├─ TFO : désactivé ou strictement limité
  └─ SYN Cookies : complètement activés (protection principale)

Fin de l'attaque :
  ├─ SYN Cookies : désactivation progressive
  └─ TFO : réactivation

Optimisation coopérative

Stratégie :

def handle_syn(packet):
    if is_under_attack():
        # En cas d'attaque, priorité aux SYN Cookies
        if use_syn_cookies:
            return handle_with_syn_cookies(packet)
    
    if packet.has_tfo_option():
        # En fonctionnement normal, essayer TFO
        if validate_tfo_cookie(packet):
            return handle_tfo_connection(packet)
        else:
            # Échec TFO, repli vers TCP standard
            return handle_standard_tcp(packet)
    
    # Traitement TCP standard
    return handle_standard_tcp(packet)

A.9. Recommandations d'utilisation (Usage Recommendations)

Quand utiliser TFO

Scénarios recommandés :

✓ Applications nécessitant une faible latence (Web, API)
✓ Scénarios avec des connexions courtes fréquentes
✓ Modèle requête-réponse
✓ Opérations idempotentes
✓ Environnement réseau de confiance

Exemples :
- Requêtes HTTP GET
- Requêtes DNS
- Appels RPC
- API en lecture seule

Scénarios déconseillés :

✗ Opérations non idempotentes
✗ Exigences de sécurité élevées (opérations sensibles)
✗ Connexions longues (faible bénéfice)
✗ Environnements non fiables

Exemples :
- Transactions financières
- Opérations d'écriture (POST/PUT/DELETE)
- Connexions longues WebSocket
- Connexions de base de données

Quand s'appuyer sur les SYN Cookies

Scénarios recommandés :

✓ Tous les serveurs exposés à Internet
✓ Sites Web à fort trafic
✓ Services susceptibles de subir des attaques DDoS
✓ Serveurs avec ressources limitées

Recommandation : activer par défaut, comme dernier recours

Scénarios déconseillés :

✗ Réseau interne (optionnel)
✗ Environnement entièrement de confiance

Note : même dans ces scénarios, l'activation est sans danger

A.10. Résumé (Summary)

Différences clés

TFO (TCP Fast Open) :
   Positionnement : outil d'optimisation des performances
   Compromis : sacrifie une certaine sécurité pour les performances
   Déploiement : nécessite le support du client et du serveur
   Effet : réduction significative de la latence

SYN Cookies :
   Positionnement : outil de protection de sécurité
   Compromis : sacrifie certaines fonctionnalités pour la sécurité
   Déploiement : activation transparente côté serveur
   Effet : défense efficace contre les SYN Flood

Relation complémentaire

TFO et les SYN Cookies ne sont pas en concurrence, mais sont complémentaires :

TFO :
   "Rendre le rapide encore plus rapide" - optimiser les performances dans des conditions normales

SYN Cookies :
   "Maintenir le lent utilisable" - maintenir la disponibilité en cas d'attaque

Déploiement idéal :
   Activer les deux simultanément, basculer dynamiquement selon les conditions réseau

Perspectives d'avenir

Évolution du protocole :
├─ TFO peut être standardisé (de expérimental à standard)
├─ SYN Cookies continuent à s'améliorer (encodage de plus d'informations)
├─ Nouveaux protocoles (comme QUIC) supportent nativement le 0-RTT
└─ Mécanismes adaptatifs plus intelligents

Fin du document. Merci d'avoir lu la documentation technique RFC 7413 - TCP Fast Open.

Pour plus d'informations, veuillez consulter :

A.1. Vue d'ensemble (Overview)​

A.2. Comparaison des objectifs de conception (Design Goals Comparison)​

TCP Fast Open (TFO)​

TCP SYN Cookies​

A.3. Comparaison des mécanismes techniques (Technical Mechanisms)​

Génération du cookie​

Gestion de l'état​

Flux d'établissement de connexion​

A.4. Comparaison des fonctionnalités (Feature Comparison)​

A.5. Comparaison de l'impact sur les performances (Performance Impact)​

Dans des conditions normales​

Dans des conditions d'attaque​

A.6. Comparaison de la sécurité (Security Comparison)​

Considérations de sécurité TFO​

Considérations de sécurité SYN Cookies​

A.7. Compatibilité et déploiement (Compatibility and Deployment)​

Déploiement TFO​

Déploiement SYN Cookies​

A.8. Coexistence et coopération (Coexistence and Cooperation)​

TFO et SYN Cookies peuvent coexister​

Optimisation coopérative​

A.9. Recommandations d'utilisation (Usage Recommendations)​

Quand utiliser TFO​

Quand s'appuyer sur les SYN Cookies​

A.10. Résumé (Summary)​

Différences clés​

Relation complémentaire​

Perspectives d'avenir​