Aller au contenu principal

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.

Dernière mise à jour le