Aller au contenu principal

RFC 7413 - TCP Fast Open

  • Statut: Experimental
  • Publié: December 2014
  • Stream: IETF
  • Errata: Pas d'errata

Résumé​

Ce document décrit un mécanisme TCP expérimental appelé TCP Fast Open (TFO). TFO permet l'échange de données pendant la poignée de main TCP en utilisant un TFO Cookie (un champ d'option TCP) pour valider les clients précédemment connectés. Cela réduit la latence des nouvelles connexions TCP et est particulièrement précieux pour les applications sensibles à la latence telles que les services Web.

Importance technique : TCP Fast Open peut réduire le temps de requête-réponse HTTP d'un temps de trajet aller-retour (RTT) complet, particulièrement bénéfique pour les connexions courtes.

Sommaire​

Sections principales​

Annexes​

Points techniques clés​

  • Génération de cookie : Le serveur génère un cookie en utilisant le chiffrement basé sur l'adresse IP du client
  • Validation de cookie : Le client inclut le cookie dans les connexions suivantes pour validation
  • Transport de données : Après validation, les données dans le paquet SYN peuvent être reçues par la couche application

Avantages en termes de performances​

  • Réduit une latence RTT complète
  • Particulièrement adapté aux connexions courtes et aux modèles requête-réponse
  • Amélioration significative des performances pour la navigation Web et les appels API

Protection de sécurité​

  • Empêche les attaques par amplification : Limite la taille des données SYN
  • Empêche l'épuisement des ressources : Mécanisme de validation des cookies
  • Compatibilité : Coexiste de manière transparente avec TCP traditionnel

RFC connexes​

  • RFC 793 : Transmission Control Protocol
  • RFC 6994 : Shared Use of Experimental TCP Options
  • RFC 7323 : TCP Extensions for High Performance

Statut d'implémentation​

Ce RFC est expérimental et a été implémenté dans plusieurs systèmes d'exploitation majeurs :

  • Noyau Linux (3.6+)
  • Apple iOS et macOS
  • Windows 10 (1607+)

Remarque : Le statut expérimental signifie que ce mécanisme est encore en cours d'évaluation ; les implémentations doivent soigneusement considérer les implications en matière de sécurité et de compatibilité.

1. Introduction​

1.1. Motivation​

L'établissement d'une connexion TCP traditionnelle nécessite une triple poignée de main (three-way handshake), ce qui introduit un délai d'au moins un temps d'aller-retour complet (Round-Trip Time, RTT) avant que la transmission de données puisse commencer. Pour de nombreuses applications modernes, notamment les services Web et les applications mobiles, ce délai constitue un goulot d'étranglement significatif en termes de performances.

Problème de latence dans les scénarios typiques​

Dans le TCP traditionnel, le client DOIT :

  1. Envoyer un paquet SYN
  2. Attendre la réponse SYN-ACK du serveur
  3. Envoyer un ACK de confirmation
  4. Puis seulement envoyer les données applicatives

Cela signifie que la transmission des données applicatives nécessite au moins 1,5 RTT (en supposant que le serveur réponde immédiatement après réception de l'ACK).

Défi des connexions HTTP courtes​

Pour le modèle requête-réponse HTTP :

  • Chaque nouvelle connexion nécessite une triple poignée de main complète
  • Dans les connexions courtes (par exemple, un seul appel API), le délai de poignée de main représente une grande proportion du temps total
  • Ce problème est encore plus grave sur les réseaux à haute latence (comme les réseaux mobiles)

Exemple de calcul de latence :

  • Réseau à 50 ms RTT : délai de poignée de main = 50 ms
  • Réseau à 200 ms RTT (transocéanique) : délai de poignée de main = 200 ms

Pour les appels API retournant de petites quantités de données, le délai de poignée de main peut dépasser le temps de transmission réel des données.

1.2. Concepts clés​

TCP Fast Open (TFO) résout ce problème en permettant l'échange de données pendant la poignée de main TCP.

Le cookie TFO est un jeton (token) cryptographique utilisé pour authentifier l'identité du client :

  1. Phase de demande de cookie :

    • Le client demande un cookie TFO lors de la connexion initiale
    • Le serveur génère et retourne le cookie (chiffré à partir de l'adresse IP du client)
    • Le client met en cache le cookie pour une utilisation ultérieure

  2. Phase Fast Open :

    • Le client transporte le cookie et les données applicatives dans le paquet SYN
    • Le serveur vérifie la validité du cookie
    • Si la vérification réussit, le serveur accepte les données SYN et peut répondre immédiatement

Amélioration des performances​

Avec TFO, la chronologie de transmission des données :

  1. Première connexion : le client envoie SYN (demande de cookie)
  2. Connexions suivantes : le client envoie SYN + cookie + données → le serveur traite immédiatement

Réduction de la latence : économie d'un RTT complet

Conception de la sécurité​

Le mécanisme de cookie TFO offre les protections de sécurité suivantes :

  • Anti-amplification (Anti-Amplification) : limite la taille des paquets SYN
  • Anti-épuisement des ressources (Anti-Resource Exhaustion) : la vérification du cookie garantit l'identité du client
  • Compatibilité ascendante (Backward Compatibility) : les serveurs ne supportant pas TFO ignorent cette option

Définitions des termes​

Conformément aux dispositions du RFC 2119, les mots-clés de ce document ont les significations suivantes :

  • MUST (DOIT) : exigence absolue
  • SHOULD (DEVRAIT) : fortement recommandé mais peut être ignoré dans des circonstances particulières
  • MAY (PEUT) : fonctionnalité entièrement optionnelle

Cas d'utilisation​

TFO est particulièrement adapté aux scénarios suivants :

  • Navigation Web : requêtes HTTP/HTTPS
  • Appels API : API RESTful, RPC
  • Applications mobiles : requêtes de connexions courtes fréquentes
  • Appareils IoT : rapports de données périodiques

Limitations et considérations​

Lors de l'utilisation de TFO, il convient de noter :

  • Les données SYN peuvent être retransmises (exigence d'idempotence)
  • Certains équipements réseau peuvent interférer avec les options TCP
  • Les cookies ont une durée d'expiration et doivent être mis à jour périodiquement

Section suivante : 2. Vue d'ensemble du protocole (Protocol Overview) présentera en détail le flux de travail de TFO et les modes d'échange de messages.

2. Vue d'ensemble du protocole (Protocol Overview)​

Ce chapitre décrit le flux de travail complet de TCP Fast Open, incluant les processus de demande, d'octroi et d'utilisation du cookie.

Lors de la première connexion à un serveur, le client doit d'abord obtenir un cookie TFO.

Flux de messages​

Client                                Serveur
   |                                    |
   |  SYN + demande cookie TFO (vide)   |
   |---------------------------------->|
   |                                    |
   |  SYN-ACK + cookie TFO             |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|
   |                                    |
   |  Données applicatives              |
   |<--------------------------------->|

Format de l'option TCP​

Option de demande de cookie :

  • Kind : 34 (TCP Fast Open)
  • Length : 2 (en-tête d'option uniquement, sans données de cookie)
  • Cookie : vide (indique une demande de cookie)

Points clés​

  1. Transparence : les serveurs ne supportant pas TFO ignorent cette option, la connexion s'établit normalement
  2. Compatibilité : le client DOIT être prêt à revenir à la triple poignée de main TCP standard
  3. Mise en cache du cookie : le client DEVRAIT mettre en cache le cookie reçu pour les connexions ultérieures

Après réception d'une demande de cookie, le serveur génère et retourne le cookie.

Le serveur utilise les informations suivantes pour générer le cookie :

  • Adresse IP du client
  • Clé secrète du serveur (Server Secret)
  • Horodatage (Timestamp) (pour l'expiration du cookie)

Exemple de fonction de chiffrement :

Cookie = AES-128(ServerSecret, ClientIP || Timestamp)

Format de l'option TCP​

Option d'octroi de cookie :

  • Kind : 34
  • Length : 6 à 18 (2 octets d'en-tête + 4 à 16 octets de cookie)
  • Cookie : jeton chiffré généré par le serveur

Comportement du serveur​

  1. DOIT : inclure l'option cookie TFO dans le SYN-ACK
  2. DEVRAIT : utiliser un algorithme de chiffrement suffisamment robuste pour générer le cookie
  3. DOIT : renouveler périodiquement la clé secrète du serveur pour renforcer la sécurité

2.3. Connexion TCP Fast Open (Fast Open Connection)​

Le client utilise le cookie mis en cache lors des connexions suivantes pour réaliser le Fast Open.

Flux de messages​

Client                                Serveur
   |                                    |
   |  SYN + cookie TFO + données        |
   |---------------------------------->|
   |                                    | (vérification du cookie)
   |                                    | (traitement des données)
   |  SYN-ACK + données                |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|
   |                                    |
   |  Données supplémentaires           |
   |<--------------------------------->|

Avantages clés​

Économie de latence :

  • TCP traditionnel : 1 RTT (poignée de main) + 1 RTT (requête-réponse) = 2 RTT
  • TCP Fast Open : 1 RTT (poignée de main + requête-réponse) = économie de 1 RTT

Limitation des données SYN​

Pour prévenir les attaques par amplification, les données dans le paquet SYN sont limitées :

  1. Longueur maximale des données :

    • Implémentation Linux : limite par défaut au MSS (Maximum Segment Size)
    • Valeur typique : environ 1460 octets (MTU Ethernet 1500 - en-têtes IP/TCP)

  2. Exigences sur les données :

    • DOIT : les données doivent être idempotentes (peuvent être retransmises en toute sécurité)
    • DEVRAIT : les données devraient constituer une requête complète (par exemple, une requête HTTP complète)

Flux de validation du serveur​

Lorsque le serveur reçoit un SYN Fast Open :

1. Vérification du cookie TFO
   ├─ Valide → accepter les données SYN, entrer dans l'état SYN-RECEIVED
   └─ Invalide → rejeter les données SYN, traiter selon la poignée de main TCP standard

2. Si le cookie est valide
   ├─ Transmettre les données SYN à la couche applicative
   ├─ L'application peut traiter immédiatement et générer une réponse
   └─ Transporter les données de réponse dans le SYN-ACK (optionnel)

3. Compléter la triple poignée de main
   └─ Après réception de l'ACK, la connexion entre dans l'état ESTABLISHED

Gestion de la validité :

  • Durée de validité typique : de quelques heures à quelques jours
  • Stratégie de mise à jour : le client peut demander périodiquement un nouveau cookie
  • Gestion de l'expiration : après expiration du cookie, le serveur refuse le Fast Open, le client revient à la poignée de main standard

Le cookie peut devenir invalide dans les situations suivantes :

  1. Expiration temporelle : dépassement de la durée de validité définie par le serveur
  2. Rotation de la clé du serveur : le serveur fait tourner sa clé de chiffrement
  3. Changement d'adresse IP : l'adresse IP du client change (réseau mobile)
  4. Politique du serveur : le serveur révoque activement le cookie (raisons de sécurité)

Stratégie de mise en cache côté client​

Fonctionnalités que le client DEVRAIT implémenter :

  • Mettre en cache un cookie distinct pour chaque IP:Port de serveur
  • Implémenter la gestion de l'expiration des cookies
  • Redemander automatiquement un cookie lorsque celui-ci expire
  • Gérer les cookies pour plusieurs serveurs

Mécanisme de repli​

Lorsque le Fast Open échoue, le client DOIT pouvoir revenir en arrière :

Tentative de Fast Open
   ├─ Succès → continuer à utiliser
   ├─ Cookie rejeté → compléter la poignée de main standard, demander un nouveau cookie
   └─ Délai d'attente → retransmettre SYN (éventuellement sans données)

2.5. Résumé des interactions du protocole (Protocol Interaction Summary)​

Cycle de vie complet​

Phase 1 : Initialisation
   Client ──SYN(demande cookie)──> Serveur
   Client <──SYN-ACK(cookie)─── Serveur
   Client ──ACK──────────────> Serveur
   [Client met en cache le cookie]

Phase 2 : Fast Open (plusieurs fois)
   Client ──SYN(cookie+données)──> Serveur
   Client <──SYN-ACK(données)───── Serveur
   Client ──ACK──────────────> Serveur
   [Économie de 1 RTT]

Phase 3 : Mise à jour du cookie (si nécessaire)
   Répéter la phase 1

Indicateurs de performance​

Type de connexionDébut de transmission des donnéesPerformance relative
TCP standard1,5 RTTRéférence
TFO (première fois)1,5 RTTIdentique au TCP standard
TFO (suivantes)0,5 RTTAmélioration de 66 %

Matrice de compatibilité​

ClientServeurRésultat
Supporte TFOSupporte TFOFast Open réussi
Supporte TFONe supporte pas TFORepli vers TCP standard
Ne supporte pas TFOSupporte TFOTCP standard
Ne supporte pas TFONe supporte pas TFOTCP standard

Section suivante : 3. Détails du protocole (Protocol Details) présentera en profondeur le format des options TFO, la machine à états et les détails d'implémentation.

3. Détails du protocole (Protocol Details)​

Ce chapitre décrit en détail les aspects techniques de l'implémentation de TCP Fast Open, notamment le format des options, les transitions de la machine à états et les règles de traitement des données.

Format de l'option TCP​

+-------------+-------------+
|   Kind=34   |  Length=2   |
+-------------+-------------+

Description des champs :

  • Kind : 8 bits, valeur 34 (numéro d'option expérimentale TCP Fast Open)
  • Length : 8 bits, valeur 2 (indique l'absence de données de cookie, c'est une demande)

Spécifications du comportement du client​

Lors de la demande d'un cookie, le client DOIT respecter :

  1. Connexion initiale :

    • Inclure Kind=34, Length=2 dans les options TCP du paquet SYN
    • Ne pas transporter de données applicatives
    • Compléter normalement la triple poignée de main

  2. Placement de l'option :

    • L'option TFO DEVRAIT être placée après les autres options TCP
    • S'assurer de ne pas dépasser la longueur maximale des options TCP (40 octets)

  3. Gestion des retransmissions :

    • Si le paquet SYN doit être retransmis, DOIT conserver l'option TFO
    • Le compteur de retransmissions DEVRAIT être cohérent avec le TCP standard

Spécifications de la réponse du serveur​

Lorsque le serveur reçoit une demande de cookie, il DEVRAIT :

  1. Génération du cookie :

    Entrée :  ClientIP, ServerSecret, Timestamp
    Sortie : Cookie = Encrypt(ServerSecret, ClientIP || Timestamp)

  2. Construction de la réponse :

    • Inclure l'option cookie TFO dans le SYN-ACK
    • La longueur du cookie est généralement de 4 à 16 octets
    • Poursuivre le flux de la poignée de main TCP standard

  3. Considérations de sécurité :

    • Faire tourner périodiquement le ServerSecret (recommandé toutes les quelques heures)
    • Implémenter un mécanisme d'expiration des cookies
    • Surveiller les schémas de requêtes anormaux

Format de l'option TCP​

+-------------+-------------+-------------------+
|   Kind=34   |   Length    |  Cookie (4-16 o.) |
+-------------+-------------+-------------------+

Description des champs :

  • Kind : 8 bits, valeur 34
  • Length : 8 bits, valeur de 6 à 18 (2 + longueur du cookie)
  • Cookie : jeton chiffré de 4 à 16 octets

Structure interne recommandée du cookie :

Cookie = AES-128(ServerSecret, ClientIP || Timestamp || Counter)

Composants :
- ClientIP :   adresse IP du client (4 ou 16 octets)
- Timestamp :  horodatage Unix (4 octets)
- Counter :    compteur anti-rejeu (optionnel, 4 octets)

Points clés d'implémentation côté serveur​

DOIT implémenter :

  • Le cookie DOIT être lié à l'adresse IP du client
  • Le cookie DOIT être vérifiable (utiliser un MAC ou un chiffrement)
  • Le cookie DOIT avoir une durée d'expiration

DEVRAIT implémenter :

  • Utiliser des algorithmes de chiffrement robustes (par exemple AES-128)
  • Implémenter un mécanisme de rotation des clés
  • Enregistrer les statistiques d'utilisation des cookies

PEUT implémenter :

  • Numéro de version du cookie (pour la mise à niveau des algorithmes)
  • Informations supplémentaires sur le client (par exemple le numéro de port)
  • Informations de limitation de débit

3.3. Connexion TCP Fast Open (Fast Open)​

Format de l'option TCP et données​

Structure du paquet SYN :
+-------------+-------------+-------------------+
|   Kind=34   |   Length    |  Cookie (4-16 o.) |
+-------------+-------------+-------------------+

Segment TCP :
+------------------------+
|      En-tête TCP       |
+------------------------+
|      Options TCP       | (contient le cookie TFO)
+------------------------+
|   Données applicatives | (optionnel, au plus MSS)
+------------------------+

Spécifications d'envoi côté client​

Lors de l'utilisation du Fast Open, le client DOIT :

  1. Inclusion du cookie :

    • Inclure le cookie mis en cache dans les options TCP du paquet SYN
    • Le cookie DOIT être un cookie valide reçu du serveur cible

  2. Transport des données :

    • PEUT transporter des données applicatives dans le paquet SYN
    • La longueur des données NE DOIT PAS dépasser le MSS
    • Les données DOIVENT être idempotentes (peuvent être retransmises en toute sécurité)

  3. Numéros de séquence :

    • Les données SYN utilisent l'ISN (Initial Sequence Number)
    • Plage des numéros de séquence des données : [ISN+1, ISN+1+DataLen)

  4. Stratégie de retransmission :

    Premier SYN : contient cookie + données
       ↓ (délai d'attente)
    Retransmission SYN :
       - Option 1 : retransmettre cookie + données (recommandé)
       - Option 2 : retransmettre uniquement SYN, sans données (conservateur)

Spécifications de réception côté serveur​

Flux de traitement lorsque le serveur reçoit un SYN Fast Open :

Réception de SYN + cookie TFO + données
   ↓
1. Vérification du cookie
   ├─ Vérification du format du cookie
   ├─ Vérification de la correspondance de l'adresse IP
   ├─ Validation de l'horodatage (expiration ?)
   └─ Vérification du MAC/signature
   ↓
2. Résultat de la vérification du cookie
   ├─ Valide → continuer à l'étape 3
   └─ Invalide → rejeter les données, envoyer un SYN-ACK standard (sans réponse de données)
   ↓
3. Acceptation des données SYN
   ├─ Créer un TCB (Transmission Control Block)
   ├─ État : SYN-RECEIVED
   ├─ Placer les données dans le tampon de réception
   └─ Notifier la couche applicative que des données sont disponibles
   ↓
4. Envoi du SYN-ACK
   ├─ Confirmer SYN et données (ACK = ISN + 1 + DataLen)
   ├─ Optionnel : transporter des données de réponse dans le SYN-ACK
   └─ Optionnel : rafraîchir le cookie (retourner un nouveau cookie)
   ↓
5. Réception de l'ACK
   └─ La connexion entre dans l'état ESTABLISHED

Règles de traitement des données​

Particularités des données SYN :

  1. Exigence d'idempotence :

    • Le client DOIT s'assurer que les données SYN peuvent être retransmises en toute sécurité
    • Approprié : requêtes HTTP GET
    • Inapproprié : opérations avec effets secondaires (comme POST, DELETE)

  2. Livraison à la couche applicative :

    • Le serveur PEUT livrer les données à l'application dans l'état SYN-RECEIVED
    • L'application DEVRAIT traiter les données avec prudence avant que la connexion soit complètement établie
    • Le serveur DEVRAIT limiter l'allocation de ressources dans l'état SYN-RECEIVED

  3. Retransmission des données :

    Scénario : perte du paquet SYN

    Client :
       SYN + cookie + données (1er)
          ↓ (délai d'attente)
       SYN + cookie + données (2e)

    Serveur : peut recevoir des données dupliquées
       → DOIT implémenter un mécanisme de déduplication (via les numéros de séquence)

Gestion du cycle de vie des cookies​

Côté serveur :

# Pseudo-code de génération de cookie
def generate_cookie(client_ip, server_secret, timestamp):
    data = client_ip + timestamp
    cookie = aes_encrypt(server_secret, data)
    return cookie

def validate_cookie(cookie, client_ip, server_secret, max_age):
    try:
        data = aes_decrypt(server_secret, cookie)
        stored_ip, timestamp = parse(data)
        
        # Vérification de l'adresse IP
        if stored_ip != client_ip:
            return False
        
        # Vérification de l'expiration
        if current_time() - timestamp > max_age:
            return False
        
        return True
    except:
        return False

Côté client :

# Pseudo-code de cache de cookie
class TFOCookieCache:
    def __init__(self):
        self.cookies = {}  # {(server_ip, server_port): (cookie, timestamp)}
    
    def store(self, server_ip, server_port, cookie):
        key = (server_ip, server_port)
        self.cookies[key] = (cookie, current_time())
    
    def get(self, server_ip, server_port, max_age):
        key = (server_ip, server_port)
        if key in self.cookies:
            cookie, timestamp = self.cookies[key]
            if current_time() - timestamp < max_age:
                return cookie
            else:
                del self.cookies[key]  # Expiré, supprimer
        return None

Stratégie de mise à jour des cookies​

Mise à jour active :

  • Le serveur PEUT retourner un nouveau cookie dans n'importe quel SYN-ACK
  • Le client DEVRAIT utiliser le cookie le plus récemment reçu

Mise à jour passive :

  • Après expiration du cookie, le client redemande
  • Après échec de la vérification du cookie, le client revient en arrière et demande un nouveau cookie

Mesures de renforcement de la sécurité​

Protection contre les attaques par rejeu :

Le cookie contient un horodatage
   → Le serveur rejette les cookies expirés
   → Limite la durée de validité du cookie (par exemple 24 heures)

Protection contre l'usurpation d'IP :

Le cookie est lié à l'IP du client
   → Les clients avec des IP différentes ne peuvent pas utiliser le même cookie
   → Les scénarios de dérive d'IP sur les réseaux mobiles doivent être pris en compte

Gestion des clés :

Rotation des clés du serveur
   ├─ Maintenir plusieurs clés actives (actuelle + précédente)
   ├─ Générer périodiquement de nouvelles clés (par exemple toutes les 8 heures)
   └─ Les anciennes clés servent uniquement à la vérification, pas à la génération

Gestion des erreurs​

Traitement des échecs de vérification du cookie :

  1. Comportement du serveur :

    • Envoyer un SYN-ACK standard (sans confirmer les données SYN)
    • Optionnel : inclure un nouveau cookie pour une utilisation ultérieure
    • Poursuivre la poignée de main TCP standard

  2. Comportement du client :

    • Détecter l'échec du Fast Open (données non confirmées)
    • Renvoyer les données applicatives après l'ACK
    • Effacer le cookie invalide
    • Optionnel : demander immédiatement un nouveau cookie

Interférence des équipements intermédiaires :

Certains pare-feux ou NAT peuvent :
   - Supprimer les options TCP inconnues
   - Bloquer les paquets SYN contenant des données
   - Modifier les numéros de séquence

Stratégies d'adaptation côté client :
   - Implémenter un mécanisme de repli
   - Enregistrer les serveurs en échec (éviter les tentatives répétées)
   - Fournir une option pour désactiver TFO

3.5. Extensions de la machine à états (State Machine Extensions)​

Machine à états côté client​

CLOSED
   ↓ (application demande connexion + cookie disponible)
SYN-SENT (envoi SYN + cookie + données)
   ↓ (réception SYN-ACK, ACK inclut les données)
ESTABLISHED
   ↓
   [Fast Open réussi !]

OU

CLOSED
   ↓ (application demande connexion + pas de cookie)
SYN-SENT (envoi SYN, demande de cookie)
   ↓ (réception SYN-ACK + cookie)
ESTABLISHED
   ↓ (mise en cache du cookie)
   [Préparation pour la prochaine connexion]

Machine à états côté serveur​

LISTEN
   ↓ (réception SYN + cookie valide + données)
SYN-RECEIVED (acceptation des données, notification de l'application)
   ↓ (envoi SYN-ACK, confirmation des données)
   ↓ (réception ACK)
ESTABLISHED
   ↓
   [Fast Open réussi !]

OU

LISTEN
   ↓ (réception SYN + cookie invalide/absent)
SYN-RECEIVED
   ↓ (envoi SYN-ACK, peut inclure un cookie)
   ↓ (réception ACK)
ESTABLISHED
   ↓
   [Poignée de main TCP standard]

Transitions d'état clés​

Traitement spécial dans l'état SYN-RECEIVED :

  • Le serveur PEUT livrer les données SYN à la couche applicative dans cet état
  • L'application DEVRAIT être consciente que la connexion n'est pas encore complètement établie
  • Le serveur DOIT limiter l'utilisation des ressources dans cet état (prévention DoS)

Section suivante : 4. Considérations de sécurité (Security Considerations) analysera en détail les menaces de sécurité de TFO et les mesures de protection.

4. Considérations de sécurité (Security Considerations)​

TCP Fast Open introduit un mécanisme de transmission de données pendant la poignée de main, ce qui crée de nouveaux défis en matière de sécurité. Ce chapitre analyse en détail ces menaces et les mesures de protection correspondantes.

4.1. Vue d'ensemble des menaces d'attaque (Attack Threats Overview)​

Principales catégories de menaces​

  1. Attaques par amplification (Amplification Attacks)
  2. Attaques par épuisement des ressources (Resource Exhaustion Attacks)
  3. Attaques par rejeu (Replay Attacks)
  4. Fuite de confidentialité (Privacy Leakage)

Modèle de menace​

Hypothèses sur les capacités de l'attaquant :
├─ Peut usurper des adresses IP sources (IP spoofing)
├─ Peut intercepter et rejouer des paquets réseau
├─ Peut initier un grand nombre de connexions simultanées
└─ Peut observer les schémas de trafic réseau

Objectifs de protection :
├─ Ne pas être plus vulnérable que le TCP standard
├─ Limiter l'effet d'amplification des attaques
├─ Protéger les ressources du serveur
└─ Protéger la vie privée des utilisateurs

4.2. Attaques par amplification (Amplification Attacks)​

Principe de l'attaque​

L'attaquant utilise les réponses du serveur pour amplifier le trafic d'attaque :

Scénario d'attaque :
1. L'attaquant usurpe l'adresse IP de la victime
2. Envoie un petit paquet SYN (+ cookie TFO + requête)
3. Le serveur envoie une grande réponse à la victime
4. Facteur d'amplification = taille de la réponse / taille de la requête

Exemple :
Requête : 60 octets SYN + 100 octets requête HTTP = 160 octets
Réponse : 60 octets SYN-ACK + 10 Ko de données = 10 060 octets
Facteur d'amplification : 63x

Mesures de protection​

1. Limitation de la taille des données SYN

Le serveur DOIT :

  • Limiter la longueur des données SYN acceptées (recommandé ≤ MSS, environ 1460 octets)
  • Rejeter les paquets SYN avec des données trop longues

2. Limitation de la taille de la réponse SYN-ACK

Le serveur DEVRAIT :

  • Limiter la taille des données de réponse avant que la connexion soit complètement établie (réception de l'ACK)
  • Limite recommandée : ≤ 4 × longueur des données SYN

Exemple d'implémentation :

MAX_SYN_DATA = 1460  # MSS
MAX_SYNACK_DATA_BEFORE_ACK = 4 * MAX_SYN_DATA  # Limite 4x

def handle_tfo_syn(syn_packet):
    if len(syn_packet.data) > MAX_SYN_DATA:
        # Refuser le Fast Open, revenir à la poignée de main standard
        return send_standard_synack()
    
    # Traitement de la requête
    response = process_request(syn_packet.data)
    
    # Limiter la taille de la réponse (avant ACK)
    if len(response) > MAX_SYNACK_DATA_BEFORE_ACK:
        response = response[:MAX_SYNACK_DATA_BEFORE_ACK]
        # Les données restantes sont envoyées après l'ACK
    
    return send_synack_with_data(response)

3. Vérification du cookie

Une vérification stricte du cookie peut prévenir l'usurpation d'IP :

  • Le cookie DOIT être lié à l'adresse IP du client
  • Les requêtes avec un cookie invalide ne déclenchent pas de réponse de données

4. Limitation de débit

Politique côté serveur :
├─ Limite de débit des connexions Fast Open par IP
├─ Limite globale du nombre de connexions Fast Open
├─ Détection de schémas anormaux (par exemple, même cookie utilisé plusieurs fois)
└─ Désactivation temporaire du Fast Open pour les IP suspectes

4.3. Attaques par épuisement des ressources (Resource Exhaustion)​

Variante d'attaque SYN Flood​

TFO peut être utilisé pour des attaques SYN Flood améliorées :

SYN Flood traditionnel :
Attaquant → grand nombre de SYN → serveur (épuise la file des demi-connexions)

SYN Flood avec TFO :
Attaquant → grand nombre de SYN + cookie + données → serveur
   ↓
Le serveur doit :
   ├─ Vérifier le cookie (CPU)
   ├─ Traiter les données (CPU + mémoire)
   └─ Peut déclencher la logique applicative (plus de ressources)

Mesures de protection​

1. Limitation de l'état SYN-RECEIVED

Le serveur DOIT :

  • Limiter le nombre de connexions dans l'état SYN-RECEIVED
  • Définir des limites plus strictes pour les connexions TFO

Recommandations d'implémentation :

#define MAX_SYN_RECEIVED_NORMAL  1024
#define MAX_SYN_RECEIVED_TFO     512   // Limite TFO plus basse

int syn_received_count_normal = 0;
int syn_received_count_tfo = 0;

int accept_syn(packet, is_tfo) {
    if (is_tfo) {
        if (syn_received_count_tfo >= MAX_SYN_RECEIVED_TFO)
            return REJECT;
        syn_received_count_tfo++;
    } else {
        if (syn_received_count_normal >= MAX_SYN_RECEIVED_NORMAL)
            return REJECT;
        syn_received_count_normal++;
    }
    // ... continuer le traitement
}

2. Isolation de la couche applicative

Le serveur DEVRAIT :

  • Retarder la livraison des données SYN à la couche applicative jusqu'à réception de l'ACK
  • Ou effectuer uniquement un traitement léger dans l'état SYN-RECEIVED

3. Contrôle du coût de calcul des cookies

Optimisation de la vérification des cookies :
├─ Utiliser des algorithmes de chiffrement efficaces (par exemple accélération matérielle AES-NI)
├─ Implémenter un cache de cookies (cache à court terme des résultats de vérification)
├─ Rejeter rapidement les cookies manifestement invalides
└─ Surveiller l'utilisation du CPU, ajuster dynamiquement la stratégie

4. Intégration avec les SYN Cookies

Le serveur PEUT combiner l'utilisation des TCP SYN Cookies :

  • SYN Cookies : protection sans état contre les SYN Flood
  • Cookies TFO : optimisation des performances avec état
Stratégie de protection :
if (under_attack) {
    // En cas de forte charge, désactiver TFO, activer les SYN Cookies
    disable_tfo();
    enable_syn_cookies();
} else {
    // En fonctionnement normal, activer les deux
    enable_tfo();
    enable_syn_cookies();  // En secours
}

4.4. Attaques par rejeu (Replay Attacks)​

Scénario d'attaque​

L'attaquant intercepte et rejoue des paquets SYN TFO :

Scénario 1 : écoute réseau
Attaquant (écoute) ─┐
                    ↓
Client ────SYN + cookie + "GET /transfer?amount=100"───→ Serveur
                    ↑
Attaquant (rejeu) ──┘  → Exécution répétée de l'opération de transfert !

Mesures de protection​

1. Exigence d'idempotence

La couche applicative DOIT :

  • N'envoyer que des opérations idempotentes dans le SYN TFO
  • Exemples :
    • ✓ Autorisé : requêtes GET, opérations en lecture seule
    • ✗ Interdit : opérations avec effets secondaires comme POST, PUT, DELETE

Guide pour le client :

def can_use_tfo(request):
    # Utiliser TFO uniquement pour les requêtes idempotentes
    if request.method in ['GET', 'HEAD', 'OPTIONS']:
        return True
    if request.method == 'POST' and request.is_idempotent:
        return True  # Application explicitement marquée comme idempotente
    return False

def send_request(request):
    if can_use_tfo(request) and has_cookie(server):
        send_with_tfo(request)
    else:
        send_with_standard_tcp(request)

2. Protection par numéros de séquence TCP

Le mécanisme TCP lui-même fournit une protection de base :

  • Le serveur suit les numéros de séquence reçus
  • Les données avec des numéros de séquence dupliqués sont rejetées
  • Limitation : valable uniquement pendant la durée de la connexion

3. Déduplication au niveau applicatif

L'application serveur DEVRAIT :

  • Implémenter un mécanisme de déduplication des requêtes (par exemple, ID de requête)
  • Utiliser une validation supplémentaire pour les opérations sensibles (par exemple, jeton CSRF)

4. Validité temporelle du cookie

  • Après expiration du cookie, les anciennes attaques par rejeu deviennent inefficaces
  • Une courte durée de validité du cookie réduit la fenêtre de rejeu

4.5. Considérations de confidentialité (Privacy Considerations)​

Menace : Le cookie TFO peut être utilisé comme identifiant de suivi persistant de l'utilisateur :

Risque de confidentialité :
L'IP du client change → le cookie reste valide
   ↓
Le serveur peut corréler des connexions provenant d'IP différentes
   ↓
Association et suivi potentiels de l'identité de l'utilisateur

Mesures de protection​

1. Liaison du cookie à l'IP

Le cookie DOIT être lié à l'adresse IP :

  • Après changement d'IP, le cookie devient invalide
  • Un nouveau cookie doit être demandé

Compromis :

  • ✓ Renforce la protection de la vie privée
  • ✗ Les scénarios de dérive d'IP sur les réseaux mobiles nécessitent des mises à jour fréquentes du cookie

2. Durée de vie limitée du cookie

  • Durée de validité recommandée : de quelques heures à 1 jour
  • Rotation périodique des cookies
  • Effacer les cookies lorsque l'utilisateur efface ses données de navigation

3. Le cookie ne contient pas d'informations utilisateur

Le cookie NE DOIT PAS :

  • Contenir un ID utilisateur ou un ID de session
  • Contenir des informations permettant d'identifier l'utilisateur
  • Être partagé entre différents services

Le cookie DEVRAIT :

  • Servir uniquement à vérifier que le client s'est déjà connecté au serveur
  • Ne transporter aucune information d'état

4. Contrôle utilisateur

Le client DEVRAIT fournir :

  • Une option pour désactiver TFO
  • Une fonctionnalité pour effacer les cookies TFO
  • Désactivation des cookies TFO en mode privé

4.6. Interaction avec d'autres mécanismes de sécurité (Interaction with Other Security Mechanisms)​

Intégration TLS/SSL​

Considérations lors de l'utilisation combinée de TFO et TLS :

Poignée de main TFO + TLS :
Client                              Serveur
   |                                  |
   | SYN + cookie TFO + TLS ClientHello |
   |---------------------------------->|
   |                                  |
   | SYN-ACK + TLS ServerHello       |
   |<----------------------------------|
   |                                  |
   | ACK + TLS ...                    |
   |---------------------------------->|

Avantages :

  • Réduction supplémentaire de la latence (TLS 1.3 + TFO = 0-RTT)
  • TLS fournit une couche de sécurité supplémentaire

Remarque :

  • Les données 0-RTT de TLS exigent également l'idempotence
  • La sécurité de TFO et de TLS doit être considérée simultanément

Pare-feux et NAT​

Problèmes de compatibilité :

Certains équipements intermédiaires peuvent :
├─ Supprimer les options TCP Fast Open
├─ Bloquer les paquets SYN contenant des données
├─ Modifier les champs d'options TCP
└─ Implémenter un suivi d'état strict

Stratégies d'adaptation :
├─ Le client implémente un mécanisme de repli
├─ Détecter si TFO est supporté
├─ Fournir une option de désactivation
└─ Le serveur enregistre les problèmes de compatibilité

Systèmes de protection DoS​

TFO DEVRAIT être coordonné avec les systèmes de protection DoS existants :

Recommandations d'intégration :
├─ Les équipements de protection DDoS devraient comprendre les options TFO
├─ La limitation de débit devrait tenir compte du trafic TFO
├─ La détection d'anomalies devrait identifier les schémas d'abus TFO
└─ TFO peut être désactivé dynamiquement en cas d'attaque

4.7. Résumé des meilleures pratiques de sécurité (Security Best Practices Summary)​

Côté serveur​

DOIT implémenter :

  • ✓ Cookie lié à l'IP du client
  • ✓ Limitation de la taille des données SYN
  • ✓ Limitation de la taille de la réponse SYN-ACK (avant ACK)
  • ✓ Mécanisme d'expiration des cookies
  • ✓ Limitation de débit

DEVRAIT implémenter :

  • ✓ Rotation périodique de la clé du serveur
  • ✓ Surveillance des schémas d'utilisation TFO
  • ✓ Intégration avec les SYN Cookies
  • ✓ Déduplication des requêtes au niveau applicatif
  • ✓ Ajustement dynamique de la stratégie (selon la charge)

PEUT implémenter :

  • ✓ Détection avancée des menaces
  • ✓ Gestion des versions de cookies
  • ✓ Vérification géographique
  • ✓ Détection d'anomalies par apprentissage automatique

Côté client​

DOIT implémenter :

  • ✓ Utiliser TFO uniquement pour les opérations idempotentes
  • ✓ Stockage sécurisé des cookies
  • ✓ Capacité de repli vers le TCP standard

DEVRAIT implémenter :

  • ✓ Gestion de l'expiration des cookies
  • ✓ Contrôles de confidentialité pour l'utilisateur
  • ✓ Logique de détection des échecs et de nouvelle tentative
  • ✓ Support du mode privé

Couche applicative​

Recommandations :

Vérification d'idempotence :
├─ Requêtes GET/HEAD → autoriser TFO par défaut
├─ POST/PUT/DELETE → interdire TFO par défaut
├─ Logique spécifique à l'application → marquage explicite
└─ Opérations sensibles → toujours interdire TFO

Validation des données :
├─ Ne pas dépendre de la sécurité de TFO
├─ Implémenter l'authentification au niveau applicatif
├─ Utiliser le chiffrement TLS
└─ Signature et vérification des requêtes

Section suivante : 5. Considérations IANA (IANA Considerations) expliquera l'attribution du numéro d'option TCP Fast Open.

5. Considérations IANA (IANA Considerations)​

Ce chapitre décrit les exigences et les attributions d'enregistrement IANA pour TCP Fast Open.

5.1. Attribution du numéro d'option TCP (TCP Option Kind Assignment)​

TCP Fast Open utilise des options TCP (TCP Option) pour transmettre le cookie et les informations associées. Conformément au RFC 6994 « Shared Use of Experimental TCP Options », TCP Fast Open s'est vu attribuer un numéro d'option expérimentale.

Numéro d'option​

Numéro de type d'option TCP (TCP Option Kind Number) : 34

Nom officiel : TCP Fast Open Cookie
Document de référence : RFC 7413
Statut d'attribution : Experimental (expérimental)

Format de l'option​

+-------------+-------------+-------------------+
|   Kind=34   |   Length    |   Cookie (opt.)   |
+-------------+-------------+-------------------+

Description des champs :

  • Kind : 8 bits, valeur fixe 34
  • Length : 8 bits, plage de valeurs 2-18
    • Length=2 : demande de cookie (sans données de cookie)
    • Length=6-18 : réponse ou utilisation du cookie (cookie de 4-16 octets)
  • Cookie : longueur variable, 4-16 octets

5.2. Description du statut expérimental (Experimental Status)​

Signification d'un protocole expérimental​

TCP Fast Open est marqué comme Experimental (expérimental), ce qui signifie :

  1. Hors piste standard :

    • N'est pas sur la piste des standards IETF (Standards Track)
    • Vise à expérimenter et évaluer la faisabilité technique
    • Peut être révisé ou abandonné à l'avenir

  2. Recommandations de déploiement :

    • Les implémenteurs doivent comprendre la nature expérimentale
    • Le déploiement doit considérer soigneusement la compatibilité et la sécurité
    • Des ajustements peuvent être nécessaires dans les versions ultérieures

  3. Évolution vers un standard :

    • Sur la base de l'expérience d'implémentation, peut être promu au rang de standard
    • Ou faire l'objet de révisions majeures selon les retours
    • Ou être remplacé par de nouveaux mécanismes

Notes pour les implémenteurs​

Recommandations :

Liste de contrôle de déploiement :
├─ Respecter la spécification RFC 7413 lors de l'implémentation
├─ Fournir une option de configuration pour désactiver TFO
├─ Surveiller les problèmes rencontrés en utilisation réelle
├─ Faire remonter l'expérience d'implémentation à l'IETF
└─ Suivre les mises à jour RFC ultérieures

Engagements de compatibilité :

  • Les protocoles expérimentaux peuvent changer dans les versions futures
  • Les implémentations devraient être conçues pour être rétrocompatibles
  • Il est recommandé de supporter la négociation de version du protocole

5.3. Partage du numéro d'option (Option Number Sharing)​

Conformément au RFC 6994, les options TCP expérimentales peuvent partager l'espace de numérotation. TCP Fast Open utilise un numéro d'option indépendant (34) et ne partage pas ce numéro avec d'autres options expérimentales.

Évitement des conflits​

Mécanisme d'identification :

  • Utilisation d'une valeur Kind fixe (34)
  • Distinction entre demande et réponse via le champ Length
  • Le contenu du cookie est défini indépendamment par chaque implémentation

Interopérabilité :

Compatibilité entre différentes implémentations :
├─ Doivent utiliser la même valeur Kind (34)
├─ Doivent respecter les mêmes conventions Length
├─ Le format du cookie est défini indépendamment par le serveur (pas besoin d'interopérabilité)
└─ Le client et le serveur doivent provenir d'implémentations compatibles

5.4. Considérations futures (Future Considerations)​

Chemin vers la standardisation​

Si TCP Fast Open s'avère réussi et largement déployé, les voies d'évolution possibles sont :

  1. Promotion en Proposed Standard (standard proposé) :

    • Révision de la spécification basée sur l'expérience d'implémentation
    • Résolution des problèmes et limitations connus
    • Intégration formelle dans la piste des standards IETF

  2. Réattribution du numéro d'option :

    • Peut se voir attribuer un numéro d'option officiel (non expérimental)
    • Ou continuer à utiliser le numéro existant 34

  3. Améliorations du protocole :

    • Peut introduire un champ de version
    • Extension du format du cookie
    • Ajout de nouvelles fonctionnalités de sécurité

Implémentations connues (Known Implementations)​

Au moment de la publication du RFC 7413, plusieurs implémentations existaient :

Systèmes d'exploitation :

  • Noyau Linux (3.6+)
  • FreeBSD
  • Apple macOS/iOS
  • Windows 10 (1607+)

Applications :

  • Google Chrome
  • Mozilla Firefox
  • curl
  • nginx

Le déploiement étendu de ces implémentations fournit une base pratique pour la standardisation.

5.5. Résumé des informations d'enregistrement (Registration Summary)​

Élément : Option TCP
Paramètre : Kind
Valeur : 34
Nom : TCP Fast Open Cookie
Référence : RFC 7413
Date : 2014-12
Remarque : Experimental

Informations de contact​

Éditeurs du document :

  • Yuchung Cheng (Google)
  • Jerry Chu (Google)
  • Sivasankar Radhakrishnan (Google)
  • Arvind Jain (Google)

Groupe de travail IETF :

  • TCP Maintenance and Minor Extensions (tcpm)

Liste de diffusion :

Section suivante : 6. Références (References) liste les références normatives et informatives citées dans cette spécification.

6. Références (References)​

Ce chapitre liste les références normatives et informatives citées dans le RFC 7413.

6.1. Références normatives (Normative References)​

Ces documents sont nécessaires pour comprendre et implémenter TCP Fast Open.

[RFC793] Transmission Control Protocol​

Titre : Transmission Control Protocol
Auteur : J. Postel
Date : septembre 1981
Statut : Internet Standard (STD 7)

Pertinence : Spécification de base du TCP, définissant les mécanismes fondamentaux du protocole TCP, notamment la triple poignée de main, la machine à états, les numéros de séquence, etc. TCP Fast Open est une extension de ce protocole de base.

Contenu clé cité :

  • Établissement de connexion TCP (triple poignée de main)
  • Machine à états TCP
  • Mécanisme d'options TCP
  • Numéros de séquence et de confirmation

Lien : RFC 793 - Transmission Control Protocol

[RFC2119] Key words for use in RFCs​

Titre : Key words for use in RFCs to Indicate Requirement Levels
Auteur : S. Bradner
Date : mars 1997
Statut : Best Current Practice (BCP 14)

Pertinence : Définit la signification des mots-clés (MUST, SHOULD, MAY, etc.) dans les RFC, utilisés pour clarifier les niveaux d'exigence des spécifications.

Termes clés :

  • MUST / REQUIRED / SHALL : exigence absolue
  • MUST NOT / SHALL NOT : interdiction absolue
  • SHOULD / RECOMMENDED : fortement recommandé
  • SHOULD NOT / NOT RECOMMENDED : déconseillé
  • MAY / OPTIONAL : optionnel

Lien : RFC 2119 - Key words for use in RFCs

[RFC6994] Shared Use of Experimental TCP Options​

Titre : Shared Use of Experimental TCP Options
Auteur : J. Touch
Date : août 2013
Statut : Proposed Standard

Pertinence : Définit le mécanisme d'attribution et de partage des options TCP expérimentales. Le numéro d'option (34) de TCP Fast Open est basé sur ce cadre.

Contenu clé :

  • Plage des numéros d'options expérimentales
  • Mécanisme de partage des numéros d'options
  • Guide de déploiement expérimental

[RFC5925] The TCP Authentication Option​

Titre : The TCP Authentication Option
Auteur : J. Touch, A. Mankin, R. Bonica
Date : juin 2010
Statut : Proposed Standard

Pertinence : Option d'authentification TCP, qui doit être coordonnée avec TCP Fast Open dans l'espace des options.

6.2. Références informatives (Informative References)​

Ces documents fournissent des informations de contexte et des éléments de référence, mais ne sont pas des prérequis pour l'implémentation.

[RFC4987] TCP SYN Flooding Attacks and Common Mitigations​

Titre : TCP SYN Flooding Attacks and Common Mitigations
Auteur : W. Eddy
Date : août 2007
Statut : Informational

Pertinence : Décrit les attaques SYN Flood et les mesures de protection. La conception de la sécurité de TCP Fast Open doit tenir compte de ces menaces.

Contenu clé :

  • Principe des attaques SYN Flood
  • Mécanisme des SYN Cookies
  • Stratégies de protection

Relation avec TFO :

  • TFO NE DOIT PAS aggraver les menaces SYN Flood
  • TFO peut coexister avec les SYN Cookies

[RFC4953] Defending TCP Against Spoofing Attacks​

Titre : Defending TCP Against Spoofing Attacks
Auteur : J. Touch
Date : juillet 2007
Statut : Informational

Pertinence : Discute des attaques par usurpation TCP et des protections. Le mécanisme de cookie TFO s'inspire partiellement de ces principes.

Concepts clés :

  • Attaques par usurpation d'IP
  • Randomisation des numéros de séquence
  • Vérification de connexion

[RFC5681] TCP Congestion Control​

Titre : TCP Congestion Control
Auteur : M. Allman, V. Paxson, E. Blanton
Date : septembre 2009
Statut : Draft Standard

Pertinence : Mécanismes de contrôle de congestion TCP. TFO doit interagir correctement avec le contrôle de congestion.

Contenu clé :

  • Démarrage lent (Slow Start)
  • Évitement de congestion (Congestion Avoidance)
  • Retransmission rapide et récupération rapide

Relation avec TFO :

  • Traitement du contrôle de congestion pour les données SYN
  • Fenêtre de congestion initiale

Titre : TCP Cookie Transactions (TCPCT)
Auteur : W. Simpson
Date : janvier 2011
Statut : Experimental

Pertinence : Un autre mécanisme de cookie TCP avec des objectifs similaires mais une conception différente.

Comparaison :

  • TCPCT est plus complexe, supporte plus de fonctionnalités
  • TFO est plus simple, plus facile à déployer
  • TFO a finalement obtenu une implémentation plus large

[RFC7323] TCP Extensions for High Performance​

Titre : TCP Extensions for High Performance
Auteur : D. Borman, B. Braden, V. Jacobson, R. Scheffenegger
Date : septembre 2014
Statut : Proposed Standard

Pertinence : Extensions de performance TCP, incluant la mise à l'échelle de fenêtre, les horodatages, etc. TFO est une autre extension d'optimisation des performances.

Extensions clés :

  • Mise à l'échelle de fenêtre (Window Scale)
  • Option d'horodatage (Timestamps)
  • PAWS (Protection Against Wrapped Sequences)

[TFO-ANALYSIS] TCP Fast Open Performance Analysis​

Titre : TCP Fast Open (Internet-Draft)
Auteurs : S. Radhakrishnan, Y. Cheng, J. Chu, A. Jain, B. Raghavan
Date : 2011

Pertinence : Article d'analyse des performances de TFO, fournissant des données expérimentales et des évaluations.

Résultats clés :

  • Réduction de la latence des requêtes HTTP de 15 à 40 %
  • Réduction du temps de chargement des pages de 4 à 10 %
  • Effet plus significatif sur les réseaux à haute latence

[TLS13] The Transport Layer Security (TLS) Protocol Version 1.3​

Titre : RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
Auteur : E. Rescorla
Date : août 2018
Statut : Proposed Standard

Pertinence : La fonctionnalité 0-RTT de TLS 1.3 combinée à TFO peut réduire davantage la latence.

Effet synergique :

TFO + TLS 1.3 0-RTT :
   Client ──SYN + cookie TFO + TLS ClientHello + données app.──> Serveur
   
   Latence totale : 0-RTT (théoriquement)

Considérations de sécurité :

  • Les hypothèses de sécurité des deux mécanismes doivent être satisfaites simultanément
  • Exigence d'idempotence pour les données 0-RTT

Lien : RFC 8446 - TLS 1.3

[HTTP2] Hypertext Transfer Protocol Version 2 (HTTP/2)​

Titre : RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
Auteurs : M. Belshe, R. Peon, M. Thomson
Date : mai 2015
Statut : Proposed Standard

Pertinence : HTTP/2 peut être utilisé conjointement avec TFO pour optimiser les performances Web.

Mécanisme synergique :

  • TFO réduit la latence d'établissement de connexion
  • Le multiplexage HTTP/2 réduit le nombre de connexions
  • La combinaison des deux maximise les performances

Lien : RFC 7540 - HTTP/2

[QUIC] QUIC: A UDP-Based Multiplexed and Secure Transport​

Titre : RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
Auteurs : J. Iyengar, M. Thomson
Date : mai 2021
Statut : Proposed Standard

Pertinence : QUIC est un nouveau protocole de transport qui supporte nativement l'établissement de connexion 0-RTT, pouvant être considéré comme une incarnation de la philosophie TFO dans un nouveau protocole.

Comparaison :

  • QUIC 0-RTT : basé sur UDP, chiffrement intégré
  • TCP TFO : basé sur TCP, nécessite une couche TLS supplémentaire
  • QUIC évite certains héritages historiques de TCP

Lien : RFC 9000 - QUIC

Documentation du noyau Linux​

Documentation/networking/tcp-fast-open.txt

Documentation de l'implémentation de TCP Fast Open dans le noyau Linux.

Groupe de travail IETF​

TCP Maintenance and Minor Extensions (tcpm)
URL : https://datatracker.ietf.org/wg/tcpm/

Groupe de travail discutant de la maintenance et des extensions du protocole TCP.

Outils de mesure des performances​

  • netstat : afficher les statistiques TFO
  • tcpdump/wireshark : capturer et analyser les paquets TFO
  • ss (socket statistics) : afficher l'état TFO sous Linux

Recherche académique​

Plusieurs articles académiques ont analysé les performances et la sécurité de TFO :

  • Étude de performance TFO par Google (SIGCOMM 2011)
  • Analyse de sécurité TFO (USENIX Security)
  • Rapports d'expérience de déploiement réel

Section suivante : 7. Remerciements (Acknowledgments) remercie les individus et organisations ayant contribué à cette spécification.

7. Remerciements (Acknowledgments)​

Le développement et la standardisation de TCP Fast Open ont bénéficié des contributions de nombreux individus et organisations.

7.1. Contributeurs principaux (Primary Contributors)​

Auteurs du RFC (Authors)​

Yuchung Cheng
Google, Inc.
Email : [email protected]

Jerry Chu
Google, Inc.
Email : [email protected]

Sivasankar Radhakrishnan
Google, Inc.
Email : [email protected]

Arvind Jain
Google, Inc.
Email : [email protected]

Ces auteurs ont conçu, implémenté et testé le mécanisme TCP Fast Open lors de leur travail chez Google, et ont dirigé la rédaction du RFC.

7.2. Contributions techniques (Technical Contributions)​

Conception du protocole​

Remerciements aux personnes suivantes pour leurs précieuses contributions à la conception du protocole TFO :

  • Nandita Dukkipati (Google) - analyse des performances et contrôle de congestion
  • Neal Cardwell (Google) - expert en implémentation TCP
  • Lawrence Brakmo (Facebook) - révision précoce et retours
  • Eric Dumazet (Google) - implémentation dans le noyau Linux

Analyse de sécurité​

La section sur les considérations de sécurité a bénéficié des contributions de :

  • Joe Touch (USC/ISI) - expert en sécurité TCP, a fourni des recommandations de sécurité essentielles
  • Wesley Eddy (MTI Systems) - expert en protection contre les SYN Flood
  • Michael Scharf (Alcatel-Lucent) - analyse des menaces de sécurité
  • Mirja Kühlewind (ETH Zurich) - évaluation des risques de déploiement expérimental

Implémentation et tests​

Remerciements aux organisations pour leurs contributions à l'implémentation et aux tests de TFO :

Noyau Linux :

  • Wei Wang (Google) - implémentation et optimisation dans le noyau
  • David S. Miller - mainteneur du sous-système réseau
  • Eric Dumazet - optimisation des performances

Systèmes BSD :

  • Équipe FreeBSD - implémentation FreeBSD
  • Apple - implémentation macOS/iOS

Applications :

  • Équipe Chrome (Google) - intégration dans le navigateur
  • Équipe Firefox (Mozilla) - support dans le navigateur
  • Équipe nginx - support dans le serveur Web
  • Projet curl - support dans l'outil en ligne de commande

7.3. Communauté IETF (IETF Community)​

Groupe de travail TCPM​

Remerciements particuliers aux membres du groupe de travail TCP Maintenance and Minor Extensions (TCPM) :

Présidents du groupe de travail :

  • Wesley Eddy
  • Yoshifumi Nishida

Participants actifs :

  • Alexander Zimmermann
  • Anantha Ramaiah
  • Bob Briscoe
  • David Borman
  • Fernando Gont
  • Ilpo Järvinen
  • John Leslie
  • Mark Allman
  • Martin Duke
  • Michael Scharf
  • Mirja Kühlewind
  • Richard Scheffenegger
  • Ted Faber
  • Yoshifumi Nishida

Discussions sur la liste de diffusion​

Remerciements à tous les membres de la liste de diffusion [email protected] qui ont participé aux discussions, fourni des retours et des suggestions.

7.4. Relecteurs (Reviewers)​

Remerciements particuliers aux personnes suivantes pour leur relecture détaillée des brouillons du RFC :

  • Joe Touch - plusieurs rondes de révision approfondie, nombreuses suggestions d'amélioration technique
  • Alexander Zimmermann - détails du protocole et suggestions d'implémentation
  • Mark Allman - considérations sur le contrôle de congestion et les performances
  • Fernando Gont - considérations de sécurité et opérationnelles
  • Ted Faber - guide des protocoles expérimentaux

Révision par les zones IETF​

Remerciements aux directeurs de zone IETF et aux équipes de révision :

  • Transport Area Directors - guidage du processus de standardisation
  • Security Area Review Team - révision de sécurité
  • Operations Area Review Team - révision des considérations opérationnelles

7.5. Soutien à la recherche (Research Support)​

Collaboration académique​

Remerciements aux institutions académiques suivantes pour leur soutien à la recherche :

  • UC Berkeley - recherche sur les performances réseau
  • MIT - conception et analyse de protocoles
  • ETH Zurich - recherche sur le déploiement expérimental
  • University of Southern California (USC/ISI) - expertise en protocoles TCP

Mesures de performance​

Remerciements aux organisations ayant fourni des données de mesure réseau réelles :

  • Google - données de déploiement à grande échelle
  • Facebook - tests en environnement de centre de données
  • Akamai - expérience de déploiement CDN
  • Cloudflare - données de performance réseau mondial

La conception de TCP Fast Open s'est inspirée des travaux antérieurs suivants :

RFC 6013 par William Allen Simpson
TCPCT est un autre mécanisme de cookie TCP. Bien que TFO ait adopté une conception différente, TCPCT a fourni une expérience de conception précieuse et des leçons apprises.

T/TCP (TCP for Transactions)​

RFC 1644 par Bob Braden
T/TCP était une tentative précoce de réduire la surcharge des connexions TCP. Bien qu'il n'ait pas été largement déployé, il a fourni une base théorique pour les travaux ultérieurs.

SYN Cookies​

Le mécanisme SYN Cookies inventé par Daniel J. Bernstein a inspiré la philosophie de vérification sans état de TFO.

7.7. Soutien industriel (Industry Support)​

Principaux soutiens​

Google :

  • Financement de la recherche et du développement initiaux
  • Fourniture d'une plateforme de déploiement à grande échelle
  • Implémentation open source dans le noyau

Linux Foundation :

  • Soutien à l'implémentation dans le noyau Linux
  • Promotion de la collaboration dans la communauté open source

IETF :

  • Fourniture d'une plateforme de standardisation
  • Organisation des révisions et des discussions

Premiers adoptants​

Remerciements aux organisations suivantes pour leur déploiement précoce et leurs retours :

  • Google - services de recherche, YouTube, Gmail, etc.
  • Facebook - applications mobiles et services Web
  • LinkedIn - services API
  • CloudFlare - services CDN
  • Fastly - plateforme de calcul en périphérie

L'expérience de déploiement réel de ces organisations a été cruciale pour valider l'utilité pratique de TFO et identifier les problèmes potentiels.

7.8. Amélioration continue (Continuous Improvement)​

TCP Fast Open continue d'être amélioré. Nous encourageons :

  • Les implémenteurs : à partager leur expérience de déploiement et leurs astuces d'implémentation
  • Les chercheurs : à publier des analyses de performances et de sécurité
  • Les opérateurs : à signaler les problèmes rencontrés dans les réseaux réels
  • Les standardiseurs : à proposer des améliorations du protocole

Canaux de retour​

Conclusion​

TCP Fast Open est le fruit de la collaboration de nombreux individus et organisations. De la conception initiale à la conception du protocole, l'implémentation, les tests, le déploiement et finalement la standardisation, chaque étape a bénéficié du soutien et des contributions de la communauté.

Remerciements particuliers à toutes les personnes qui ont cru en cette technologie et ont été prêtes à investir du temps et de l'énergie pour la concrétiser. Le déploiement réussi de TCP Fast Open témoigne de la puissance des standards ouverts et de la collaboration communautaire.

Nous espérons que TFO continuera à se développer à l'avenir, offrant une expérience réseau plus rapide et plus efficace aux utilisateurs d'Internet dans le monde entier.

Section suivante : Annexe A. Comparaison avec les TCP Cookies (SYN Cookies) compare en détail les mécanismes TFO et SYN Cookies.

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 :

  1. Optimisation des performances : réduire la latence d'établissement de connexion TCP
  2. Compatibilité ascendante : coexister avec les implémentations TCP existantes
  3. 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 :

  1. Défense contre les SYN Flood : résister aux attaques DoS
  2. Conception sans état : ne pas consommer de ressources serveur
  3. 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éTFOSYN CookiesRemarque
Objectif principalOptimisation des performancesProtection de sécuritéIntentions de conception différentes
Transmission de données SYN✓ Supporté✗ Non supportéFonctionnalité centrale de TFO
Type d'étatAvec étatSans étatL'absence d'état est la clé des SYN Cookies
Latence de connexionRéduite de 1 RTT3-way standardAvantage de performance TFO
Ressources serveurConsommation normaleTrès faible consommationLes SYN Cookies économisent les ressources
Conservation des options TCPComplèteMSS uniquementLimitation 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 cookieHeures-joursMinutesCookie TFO persistant
Cache côté client✓ Requis✗ Non requisTFO nécessite le support client
Protection contre les attaquesModéréeTrès forteSYN Cookies conçus pour la défense
Complexité de déploiementModéréeFaibleSYN 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 :