Zum Hauptinhalt springen

3. Protocol Details (Protokolldetails)

Dieses Kapitel beschreibt die technischen Implementierungsdetails von TCP Fast Open im Einzelnen, einschließlich Optionsformat, Zustandsmaschinenübergänge und Datenverarbeitungsregeln.

TCP-Optionsformat​

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

Feldbeschreibung:

  • Kind: 8 Bit, Wert 34 (experimentelle Optionsnummer für TCP Fast Open)
  • Length: 8 Bit, Wert 2 (zeigt an, dass keine Cookie-Daten vorhanden sind – dies ist eine Anfrage)

Client-Verhaltensanforderungen​

Der Client MUSS beim Anfordern eines Cookies folgendes einhalten:

  1. Erstverbindung:

    • Kind=34, Length=2 in den TCP-Optionen des SYN-Pakets einschließen
    • Keine Anwendungsdaten übertragen
    • Drei-Wege-Handshake normal abschließen

  2. Optionsplatzierung:

    • TFO-Option SOLLTE nach anderen TCP-Optionen platziert werden
    • Sicherstellen, dass die maximale TCP-Optionslänge (40 Byte) nicht überschritten wird

  3. Wiederübertragungsbehandlung:

    • Wenn das SYN-Paket erneut übertragen werden muss, MUSS die TFO-Option beibehalten werden
    • Wiederübertragungszähler SOLLTE mit Standard-TCP übereinstimmen

Server-Antwortanforderungen​

Der Server SOLLTE beim Empfang einer Cookie-Anfrage:

  1. Cookie-Generierung:

    Eingabe:  ClientIP, ServerSecret, Timestamp
    Ausgabe: Cookie = Encrypt(ServerSecret, ClientIP || Timestamp)

  2. Antwortkonstruktion:

    • TFO-Cookie-Option in SYN-ACK einschließen
    • Cookie-Länge beträgt typischerweise 4 bis 16 Byte
    • Standard-TCP-Handshake-Ablauf fortsetzen

  3. Sicherheitsüberlegungen:

    • ServerSecret regelmäßig rotieren (empfohlen: alle paar Stunden)
    • Cookie-Ablaufmechanismus implementieren
    • Anomale Anfragemuster überwachen

TCP-Optionsformat​

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

Feldbeschreibung:

  • Kind: 8 Bit, Wert 34
  • Length: 8 Bit, Wert 6 bis 18 (2 + Cookie-Länge)
  • Cookie: 4 bis 16 Byte verschlüsseltes Token

Empfohlene interne Cookie-Struktur:

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

Bestandteile:
- ClientIP:   Client-IP-Adresse (4 oder 16 Byte)
- Timestamp:  Unix-Zeitstempel (4 Byte)
- Counter:    Anti-Replay-Zähler (optional, 4 Byte)

Wichtige Punkte der Server-Implementierung​

MUSS implementiert werden:

  • Cookie MUSS an die Client-IP-Adresse gebunden sein
  • Cookie MUSS verifizierbar sein (mit MAC oder Verschlüsselung)
  • Cookie MUSS eine Ablaufzeit haben

SOLLTE implementiert werden:

  • Algorithmus mit hoher Verschlüsselungsstärke verwenden (z. B. AES-128)
  • Schlüsselrotationsmechanismus implementieren
  • Cookie-Nutzungsstatistiken aufzeichnen

KANN implementiert werden:

  • Cookie-Versionsnummer (zur Unterstützung von Algorithmus-Upgrades)
  • Zusätzliche Client-Informationen (z. B. Portnummer)
  • Ratenbegrenzungsinformationen

3.3. TCP-Fast-Open-Verbindung (Fast Open)​

TCP-Optionsformat und Daten​

SYN-Paketstruktur:
+-------------+-------------+-------------------+
|   Kind=34   |   Length    |  Cookie (4-16 B)  |
+-------------+-------------+-------------------+

TCP-Segment:
+------------------------+
|      TCP-Kopf          |
+------------------------+
|      TCP-Optionen      | (enthält TFO-Cookie)
+------------------------+
|   Anwendungsdaten      | (optional, max. MSS)
+------------------------+

Client-Sendeanforderungen​

Der Client MUSS bei Verwendung von Fast Open:

  1. Cookie einschließen:

    • Gecachtes Cookie in den TCP-Optionen des SYN-Pakets einschließen
    • Cookie MUSS ein gültiges Cookie sein, das vom Zielserver empfangen wurde

  2. Daten übertragen:

    • KANN Anwendungsdaten im SYN-Paket übertragen
    • Datenlänge DARF NICHT MSS überschreiten
    • Daten MÜSSEN idempotent sein (können sicher erneut übertragen werden)

  3. Sequenznummern:

    • SYN-Daten verwenden ISN (Initial Sequence Number)
    • Datensequenznummernbereich: [ISN+1, ISN+1+DataLen)

  4. Wiederübertragungsstrategie:

    Erstes SYN: Cookie + Daten einschließen
       ↓ (Timeout)
    SYN erneut übertragen:
       - Option 1: Cookie + Daten erneut übertragen (empfohlen)
       - Option 2: Nur SYN ohne Daten übertragen (konservativ)

Server-Empfangsanforderungen​

Verarbeitungsablauf, wenn der Server ein Fast-Open-SYN empfängt:

SYN + TFO-Cookie + Daten empfangen
   ↓
1. Cookie validieren
   ├─ Cookie-Formatprüfung
   ├─ IP-Adressabgleichprüfung
   ├─ Zeitstempelvalidierung (abgelaufen?)
   └─ MAC/Signaturvalidierung
   ↓
2. Cookie-Validierungsergebnis
   ├─ Gültig → Schritt 3 fortsetzen
   └─ Ungültig → Daten verwerfen, Standard-SYN-ACK senden (ohne Datenantwort)
   ↓
3. SYN-Daten akzeptieren
   ├─ TCB (Transmission Control Block) erstellen
   ├─ Zustand: SYN-RECEIVED
   ├─ Daten in Empfangspuffer legen
   └─ Anwendungsschicht über verfügbare Daten benachrichtigen
   ↓
4. SYN-ACK senden
   ├─ SYN und Daten bestätigen (ACK = ISN + 1 + DataLen)
   ├─ Optional: Antwortdaten in SYN-ACK einschließen
   └─ Optional: Cookie aktualisieren (neues Cookie zurückgeben)
   ↓
5. ACK empfangen
   └─ Verbindung wechselt in ESTABLISHED-Zustand

Datenverarbeitungsregeln​

Besonderheiten von SYN-Daten:

  1. Idempotenzanforderung:

    • Client MUSS sicherstellen, dass SYN-Daten sicher erneut übertragen werden können
    • Geeignet: HTTP-GET-Anfragen
    • Nicht geeignet: Operationen mit Nebeneffekten (z. B. POST, DELETE)

  2. Anwendungsschicht-Zustellung:

    • Server KANN Daten im SYN-RECEIVED-Zustand an die Anwendung zustellen
    • Anwendung SOLLTE Daten vorsichtig behandeln, bevor die Verbindung vollständig hergestellt ist
    • Server SOLLTE Ressourcenzuweisung im SYN-RECEIVED-Zustand begrenzen

  3. Datenwiederübertragung:

    Szenario: SYN-Paket verloren

    Client:
       SYN + Cookie + Daten (1. Versuch)
          ↓ (Timeout)
       SYN + Cookie + Daten (2. Versuch)

    Server: Kann doppelte Daten empfangen
       → MUSS Deduplizierungsmechanismus implementieren (über Sequenznummern)

Serverseitig:

# Cookie-Generierungs-Pseudocode
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)
        
        # IP-Adresse prüfen
        if stored_ip != client_ip:
            return False
        
        # Ablaufzeit prüfen
        if current_time() - timestamp > max_age:
            return False
        
        return True
    except:
        return False

Clientseitig:

# Cookie-Cache-Pseudocode
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]  # Abgelaufen, löschen
        return None

Aktive Aktualisierung:

  • Server KANN in jedem SYN-ACK ein neues Cookie zurückgeben
  • Client SOLLTE das zuletzt empfangene Cookie verwenden

Passive Aktualisierung:

  • Nach Cookie-Ablauf fordert der Client ein neues an
  • Nach Cookie-Validierungsfehler fällt der Client zurück und fordert ein neues Cookie an

Sicherheitsverstärkungsmaßnahmen​

Schutz vor Replay-Angriffen:

Cookie enthält Zeitstempel
   → Server lehnt abgelaufene Cookies ab
   → Cookie-Gültigkeitsdauer begrenzen (z. B. 24 Stunden)

Schutz vor IP-Spoofing:

Cookie an Client-IP gebunden
   → Clients mit unterschiedlichen IPs können nicht dasselbe Cookie verwenden
   → IP-Drift in Mobilfunknetzszenarien muss berücksichtigt werden

Schlüsselverwaltung:

Server-Schlüsselrotation
   ├─ Mehrere Schlüssel aktiv halten (aktueller + vorheriger)
   ├─ Regelmäßig neue Schlüssel generieren (z. B. alle 8 Stunden)
   └─ Alte Schlüssel nur zur Validierung verwenden, nicht zur Generierung

Fehlerbehandlung​

Behandlung von Cookie-Validierungsfehlern:

  1. Serververhalten:

    • Standard-SYN-ACK senden (SYN-Daten nicht bestätigen)
    • Optional: Neues Cookie für spätere Verwendung einschließen
    • Standard-TCP-Handshake fortsetzen

  2. Clientverhalten:

    • Fast-Open-Fehler erkennen (Daten nicht bestätigt)
    • Anwendungsdaten nach ACK erneut senden
    • Ungültiges Cookie löschen
    • Optional: Sofort neues Cookie anfordern

Störung durch Netzwerk-Middleboxen:

Einige Firewalls oder NATs können:
   - Unbekannte TCP-Optionen entfernen
   - SYN-Pakete mit Daten blockieren
   - Sequenznummern ändern

Client-Gegenmaßnahmen:
   - Rückfallmechanismus implementieren
   - Fehlgeschlagene Server aufzeichnen (wiederholte Versuche vermeiden)
   - Option zum Deaktivieren von TFO bereitstellen

3.5. Zustandsmaschinenerweiterungen (State Machine Extensions)​

Client-Zustandsmaschine​

CLOSED
   ↓ (Anwendung fordert Verbindung an + Cookie vorhanden)
SYN-SENT (SYN + Cookie + Daten senden)
   ↓ (SYN-ACK empfangen, ACK enthält Daten)
ESTABLISHED
   ↓
   [Fast Open erfolgreich!]

ODER

CLOSED
   ↓ (Anwendung fordert Verbindung an + kein Cookie)
SYN-SENT (SYN senden, Cookie anfordern)
   ↓ (SYN-ACK + Cookie empfangen)
ESTABLISHED
   ↓ (Cookie cachen)
   [Für nächste Verbindung vorbereitet]

Server-Zustandsmaschine​

LISTEN
   ↓ (SYN + gültiges Cookie + Daten empfangen)
SYN-RECEIVED (Daten akzeptieren, Anwendung benachrichtigen)
   ↓ (SYN-ACK senden, Daten bestätigen)
   ↓ (ACK empfangen)
ESTABLISHED
   ↓
   [Fast Open erfolgreich!]

ODER

LISTEN
   ↓ (SYN + ungültiges/kein Cookie empfangen)
SYN-RECEIVED
   ↓ (SYN-ACK senden, möglicherweise Cookie einschließen)
   ↓ (ACK empfangen)
ESTABLISHED
   ↓
   [Standard-TCP-Handshake]

Wichtige Zustandsübergänge​

Besondere Behandlung im SYN-RECEIVED-Zustand:

  • Server KANN in diesem Zustand SYN-Daten an die Anwendungsschicht zustellen
  • Anwendung SOLLTE sich bewusst sein, dass die Verbindung noch nicht vollständig hergestellt ist
  • Server MUSS Ressourcennutzung in diesem Zustand begrenzen (DoS-Schutz)

Nächster Abschnitt: 4. Security Considerations (Sicherheitsüberlegungen) analysiert die Sicherheitsbedrohungen und Schutzmaßnahmen von TFO im Detail.

Letztes Update am