Zum Hauptinhalt springen

RFC 7413 - TCP Fast Open

  • Status: Experimental
  • Veröffentlicht: December 2014
  • Stream: IETF
  • Errata: Keine Errata

Zusammenfassung​

Dieses Dokument beschreibt einen experimentellen TCP-Mechanismus namens TCP Fast Open (TFO). TFO ermöglicht den Datenaustausch während des TCP-Handshakes, indem TFO-Cookies (ein TCP-Optionsfeld) zur Validierung zuvor verbundener Clients verwendet werden. Dies reduziert die Latenz beim Aufbau neuer TCP-Verbindungen und ist besonders wertvoll für latenzempfindliche Anwendungen wie Webdienste.

Technische Bedeutung: TCP Fast Open kann die HTTP-Request-Response-Zeit um eine vollständige Round-Trip-Zeit (RTT) reduzieren, insbesondere für Kurzverbindungen.

Inhaltsverzeichnis​

Hauptabschnitte​

Anhänge​

Wichtige technische Punkte​

  • Cookie-Generierung: Server generiert Cookie mit Verschlüsselung basierend auf Client-IP-Adresse
  • Cookie-Validierung: Client trägt Cookie in nachfolgenden Verbindungen zur Validierung
  • Datenübertragung: Nach Validierung können Daten im SYN-Paket von der Anwendungsschicht empfangen werden

Leistungsvorteile​

  • Reduziert eine vollständige RTT-Latenz
  • Besonders geeignet für Kurzverbindungen und Request-Response-Muster
  • Signifikante Leistungsverbesserung für Web-Browsing und API-Aufrufe

Sicherheitsschutz​

  • Verhindert Verstärkungsangriffe: Begrenzt SYN-Datengröße
  • Verhindert Ressourcenerschöpfung: Cookie-Validierungsmechanismus
  • Kompatibilität: Kann transparent mit traditionellem TCP koexistieren

Verwandte RFCs​

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

Implementierungsstatus​

Dieses RFC ist experimentell und wurde in mehreren großen Betriebssystemen implementiert:

  • Linux-Kernel (3.6+)
  • Apple iOS und macOS
  • Windows 10 (1607+)

Hinweis: Experimenteller Status bedeutet, dass dieser Mechanismus noch evaluiert wird; Implementierungen sollten Sicherheits- und Kompatibilitätsauswirkungen sorgfältig berücksichtigen.

1. Introduction (Einführung)​

1.1. Motivation​

Die traditionelle TCP-Verbindungsherstellung erfordert einen Drei-Wege-Handshake (Three-Way Handshake), der mindestens eine vollständige Umlaufzeit (Round-Trip Time, RTT) Latenz einführt, bevor die Datenübertragung beginnen kann. Für viele moderne Anwendungen, insbesondere Webdienste und mobile Anwendungen, stellt diese Latenz einen erheblichen Leistungsengpass dar.

Latenzproblem in typischen Szenarien​

Im traditionellen TCP MUSS ein Client:

  1. Ein SYN-Paket senden
  2. Auf die SYN-ACK-Antwort des Servers warten
  3. Eine ACK-Bestätigung senden
  4. Erst dann Anwendungsdaten senden

Das bedeutet, dass die Übertragung von Anwendungsdaten mindestens 1,5 RTT erfordert (vorausgesetzt, der Server antwortet sofort nach Empfang des ACK).

Herausforderungen bei HTTP-Kurzzeitverbindungen​

Für das HTTP-Anfrage-Antwort-Muster gilt:

  • Jede neue Verbindung erfordert einen vollständigen Drei-Wege-Handshake
  • Bei Kurzzeitverbindungen (z. B. einzelne API-Aufrufe) macht die Handshake-Latenz einen großen Anteil der Gesamtzeit aus
  • Dieses Problem ist in Hochlatenz-Netzwerken (wie Mobilfunknetzen) noch ausgeprägter

Beispiel-Latenzberechnung:

  • 50 ms RTT-Netzwerk: Handshake-Latenz = 50 ms
  • 200 ms RTT-Netzwerk (transkontinental): Handshake-Latenz = 200 ms

Bei API-Aufrufen, die kleine Datenmengen zurückgeben, kann die Handshake-Latenz die eigentliche Datenübertragungszeit übersteigen.

1.2. Schlüsselkonzepte (Key Concepts)​

TCP Fast Open (TFO) löst dieses Problem, indem es den Datenaustausch während des TCP-Handshakes ermöglicht.

Ein TFO-Cookie ist ein verschlüsseltes Token zur Validierung der Client-Identität:

  1. Cookie-Anfragephase:

    • Der Client fordert beim ersten Verbindungsaufbau ein TFO-Cookie an
    • Der Server generiert und gibt ein Cookie zurück (verschlüsselt auf Basis der Client-IP-Adresse)
    • Der Client speichert das Cookie für die spätere Verwendung im Cache

  2. Fast-Open-Phase:

    • Der Client fügt Cookie und Anwendungsdaten in das SYN-Paket ein
    • Der Server validiert die Gültigkeit des Cookies
    • Bei erfolgreicher Validierung akzeptiert der Server die SYN-Daten und kann sofort antworten

Leistungsverbesserung​

Zeitplan der Datenübertragung mit TFO:

  1. Erstverbindung: Client sendet SYN (fordert Cookie an)
  2. Folgeverbindungen: Client sendet SYN + Cookie + Daten → Server verarbeitet sofort

Latenzreduzierung: Einsparung von 1 vollständigen RTT

Sicherheitsdesign​

Der TFO-Cookie-Mechanismus bietet folgende Sicherheitsschutzmaßnahmen:

  • Anti-Amplifikation: Begrenzt die Größe von SYN-Datenpaketen
  • Anti-Ressourcenerschöpfung: Cookie-Validierung stellt die Client-Identität sicher
  • Rückwärtskompatibilität: Server, die TFO nicht unterstützen, ignorieren die Option

Terminologie​

Gemäß RFC 2119 haben Schlüsselwörter in diesem Dokument folgende Bedeutungen:

  • MUSS (MUST): Absolute Anforderung
  • SOLLTE (SHOULD): Dringend empfohlen, kann aber unter bestimmten Umständen ignoriert werden
  • KANN (MAY): Vollständig optionale Funktion

Anwendungsfälle (Use Cases)​

TFO eignet sich besonders für:

  • Web-Browsing: HTTP/HTTPS-Anfragen
  • API-Aufrufe: RESTful API, RPC
  • Mobile Anwendungen: Häufige Kurzzeitverbindungsanfragen
  • IoT-Geräte: Periodische Datenmeldungen

Einschränkungen und Überlegungen​

Bei der Verwendung von TFO ist zu beachten:

  • SYN-Daten können erneut übertragen werden (Idempotenzanforderung)
  • Einige Netzwerkgeräte können TCP-Optionen beeinträchtigen
  • Cookies haben Ablaufzeiten und müssen regelmäßig erneuert werden

Nächster Abschnitt: 2. Protocol Overview (Protokollübersicht) beschreibt den TFO-Arbeitsablauf und die Nachrichtenaustauschsmuster im Detail.

2. Protocol Overview (Protokollübersicht)​

Dieses Kapitel beschreibt den vollständigen Arbeitsablauf von TCP Fast Open, einschließlich Cookie-Anfrage, -Gewährung und -Verwendung.

Der Client muss beim ersten Verbindungsaufbau zum Server zunächst ein TFO-Cookie abrufen.

Nachrichtenfluss​

Client                                Server
   |                                    |
   |  SYN + TFO Cookie-Anfrage (leer)   |
   |---------------------------------->|
   |                                    |
   |  SYN-ACK + TFO Cookie             |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|
   |                                    |
   |  Anwendungsdaten                   |
   |<--------------------------------->|

TCP-Optionsformat​

Cookie-Anfrageoption:

  • Kind: 34 (TCP Fast Open)
  • Length: 2 (nur Optionskopf, keine Cookie-Daten)
  • Cookie: leer (zeigt Cookie-Anfrage an)

Schlüsselpunkte​

  1. Transparenz: Server, die TFO nicht unterstützen, ignorieren die Option; die Verbindung wird normal hergestellt
  2. Kompatibilität: Der Client MUSS auf den Standard-TCP-Drei-Wege-Handshake zurückfallen können
  3. Cookie-Caching: Der Client SOLLTE empfangene Cookies für spätere Verbindungen im Cache speichern

Nach Empfang einer Cookie-Anfrage generiert und gibt der Server ein Cookie zurück.

Der Server verwendet folgende Informationen zur Cookie-Generierung:

  • Client-IP-Adresse
  • Server-Geheimnis (Server Secret)
  • Zeitstempel (für Cookie-Ablauf)

Beispiel einer Verschlüsselungsfunktion:

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

TCP-Optionsformat​

Cookie-Gewährungsoption:

  • Kind: 34
  • Length: 6 bis 18 (2-Byte-Kopf + 4 bis 16 Byte Cookie)
  • Cookie: vom Server generiertes verschlüsseltes Token

Serververhalten​

  1. MUSS: TFO-Cookie-Option in SYN-ACK einschließen
  2. SOLLTE: Algorithmus mit ausreichender Verschlüsselungsstärke zur Cookie-Generierung verwenden
  3. MUSS: Server-Geheimnis regelmäßig wechseln, um die Sicherheit zu erhöhen

2.3. TCP-Fast-Open-Verbindung (Fast Open Connection)​

Der Client verwendet das gecachte Cookie in Folgeverbindungen, um Fast Open zu realisieren.

Nachrichtenfluss​

Client                                Server
   |                                    |
   |  SYN + TFO Cookie + Daten         |
   |---------------------------------->|
   |                                    | (Cookie validieren)
   |                                    | (Daten verarbeiten)
   |  SYN-ACK + Daten                  |
   |<----------------------------------|
   |                                    |
   |  ACK                               |
   |---------------------------------->|
   |                                    |
   |  Weitere Daten                     |
   |<--------------------------------->|

Wesentliche Vorteile​

Latenzeinsparung:

  • Traditionelles TCP: 1 RTT (Handshake) + 1 RTT (Anfrage-Antwort) = 2 RTT
  • TCP Fast Open: 1 RTT (Handshake + Anfrage-Antwort) = 1 RTT eingespart

SYN-Datenbeschränkungen​

Um Amplifikationsangriffe zu verhindern, sind die Daten im SYN-Paket begrenzt:

  1. Maximale Datenlänge:

    • Linux-Implementierung: Standardmäßig auf MSS (Maximum Segment Size) begrenzt
    • Typischer Wert: ca. 1460 Byte (Ethernet MTU 1500 - IP/TCP-Kopf)

  2. Datenanforderungen:

    • MUSS: Daten müssen idempotent sein (können sicher erneut übertragen werden)
    • SOLLTE: Daten sollten eine vollständige Anfrage sein (z. B. vollständige HTTP-Anfrage)

Server-Validierungsablauf​

Wenn der Server ein Fast-Open-SYN empfängt:

1. TFO-Cookie validieren
   ├─ Gültig → SYN-Daten akzeptieren, in SYN-RECEIVED-Zustand wechseln
   └─ Ungültig → SYN-Daten verwerfen, Standard-TCP-Handshake durchführen

2. Wenn Cookie gültig
   ├─ SYN-Daten an Anwendungsschicht weiterleiten
   ├─ Anwendung kann sofort verarbeiten und Antwort generieren
   └─ Antwortdaten optional in SYN-ACK einschließen

3. Drei-Wege-Handshake abschließen
   └─ Nach Empfang von ACK wechselt Verbindung in ESTABLISHED-Zustand

Gültigkeitsverwaltung:

  • Typische Gültigkeitsdauer: Stunden bis Tage
  • Aktualisierungsstrategie: Client kann regelmäßig neue Cookies anfordern
  • Ablaufbehandlung: Nach Cookie-Ablauf lehnt der Server Fast Open ab; Client fällt auf Standard-Handshake zurück

Ein Cookie kann in folgenden Situationen ungültig werden:

  1. Zeitablauf: Überschreitung der vom Server festgelegten Gültigkeitsdauer
  2. Server-Schlüsselwechsel: Server rotiert den Verschlüsselungsschlüssel
  3. IP-Adressänderung: Client-IP-Adresse ändert sich (Mobilfunknetz)
  4. Server-Richtlinie: Server widerruft Cookie aktiv (aus Sicherheitsgründen)

Client-Caching-Strategie​

Zu implementierende SOLLTE-Funktionen:

  • Für jede Server-IP:Port ein separates Cookie cachen
  • Cookie-Ablaufverwaltung implementieren
  • Bei Cookie-Ungültigkeit automatisch neu anfordern
  • Cookie-Verwaltung für mehrere Server unterstützen

Rückfallmechanismus​

Wenn Fast Open fehlschlägt, MUSS der Client zurückfallen können:

Fast Open versuchen
   ├─ Erfolgreich → weiter verwenden
   ├─ Cookie abgelehnt → Standard-Handshake abschließen, neues Cookie anfordern
   └─ Timeout → SYN erneut übertragen (möglicherweise ohne Daten)

2.5. Protokollinteraktionszusammenfassung (Protocol Interaction Summary)​

Vollständiger Lebenszyklus​

Phase 1: Initialisierung
   Client ──SYN(Cookie-Anfrage)──> Server
   Client <──SYN-ACK(Cookie)─── Server
   Client ──ACK──────────────> Server
   [Client speichert Cookie im Cache]

Phase 2: Fast Open (mehrfach)
   Client ──SYN(Cookie+Daten)──> Server
   Client <──SYN-ACK(Daten)───── Server
   Client ──ACK──────────────> Server
   [1 RTT eingespart]

Phase 3: Cookie-Aktualisierung (bei Bedarf)
   Phase 1 wiederholen

Leistungskennzahlen​

VerbindungstypBeginn der DatenübertragungRelative Leistung
Standard-TCP1,5 RTTReferenz
TFO (erstmalig)1,5 RTTGleich wie Standard-TCP
TFO (Folgeverbindung)0,5 RTT66 % Verbesserung

Kompatibilitätsmatrix​

ClientServerErgebnis
TFO unterstütztTFO unterstütztFast Open erfolgreich
TFO unterstütztTFO nicht unterstütztRückfall auf Standard-TCP
TFO nicht unterstütztTFO unterstütztStandard-TCP
TFO nicht unterstütztTFO nicht unterstütztStandard-TCP

Nächster Abschnitt: 3. Protocol Details (Protokolldetails) beschreibt das TFO-Optionsformat, den Zustandsautomaten und Implementierungsdetails eingehend.

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.

4. Security Considerations (Sicherheitsüberlegungen)​

TCP Fast Open führt einen Mechanismus zur Datenübertragung während des Handshakes ein, was neue Sicherheitsherausforderungen mit sich bringt. Dieses Kapitel analysiert diese Bedrohungen und die entsprechenden Schutzmaßnahmen im Detail.

4.1. Übersicht der Angriffsvektoren (Attack Threats Overview)​

Hauptbedrohungskategorien​

  1. Amplifikationsangriffe (Amplification Attacks)
  2. Ressourcenerschöpfungsangriffe (Resource Exhaustion Attacks)
  3. Replay-Angriffe (Replay Attacks)
  4. Datenschutzverletzungen (Privacy Leakage)

Bedrohungsmodell​

Annahmen zu Angreiferfähigkeiten:
├─ Kann Quell-IP-Adressen fälschen (IP-Spoofing)
├─ Kann Netzwerkpakete abfangen und wiedergeben
├─ Kann eine große Anzahl gleichzeitiger Verbindungen initiieren
└─ Kann Netzwerkverkehrsmuster beobachten

Schutzziele:
├─ Nicht anfälliger als Standard-TCP
├─ Amplifikationseffekt von Angriffen begrenzen
├─ Serverressourcen schützen
└─ Benutzerdatenschutz schützen

4.2. Amplifikationsangriffe (Amplification Attacks)​

Angriffsprinzip​

Angreifer nutzen Serverantworten, um Angriffsdatenverkehr zu verstärken:

Angriffsszenario:
1. Angreifer fälscht IP-Adresse des Opfers
2. Sendet kleines SYN-Paket (+ TFO-Cookie + Anfrage)
3. Server sendet große Antwort an das Opfer
4. Verstärkungsfaktor = Antwortgröße / Anfragegröße

Beispiel:
Anfrage: 60 Byte SYN + 100 Byte HTTP-Anfrage = 160 Byte
Antwort: 60 Byte SYN-ACK + 10 KB Daten = 10.060 Byte
Verstärkungsfaktor: 63x

Schutzmaßnahmen​

1. SYN-Datengröße begrenzen

Server MUSS:

  • Akzeptierte SYN-Datenlänge begrenzen (empfohlen: ≤ MSS, ca. 1460 Byte)
  • Überlange SYN-Datenpakete ablehnen

2. SYN-ACK-Antwortgröße begrenzen

Server SOLLTE:

  • Antwortdatengröße begrenzen, bevor die Verbindung vollständig hergestellt ist (ACK empfangen)
  • Empfohlene Begrenzung: ≤ 4 × SYN-Datenlänge

Implementierungsbeispiel:

MAX_SYN_DATA = 1460  # MSS
MAX_SYNACK_DATA_BEFORE_ACK = 4 * MAX_SYN_DATA  # 4x-Begrenzung

def handle_tfo_syn(syn_packet):
    if len(syn_packet.data) > MAX_SYN_DATA:
        # Fast Open ablehnen, auf Standard-Handshake zurückfallen
        return send_standard_synack()
    
    # Anfrage verarbeiten
    response = process_request(syn_packet.data)
    
    # Antwortgröße begrenzen (vor ACK)
    if len(response) > MAX_SYNACK_DATA_BEFORE_ACK:
        response = response[:MAX_SYNACK_DATA_BEFORE_ACK]
        # Restliche Daten nach ACK senden
    
    return send_synack_with_data(response)

3. Cookie-Validierung

Strenge Cookie-Validierung kann IP-Spoofing verhindern:

  • Cookie MUSS an Client-IP-Adresse gebunden sein
  • Anfragen mit ungültigem Cookie lösen keine Datenantwort aus

4. Ratenbegrenzung

Serverseitige Strategie:
├─ Ratenbegrenzung für Fast-Open-Verbindungen pro IP
├─ Globale Begrenzung der Fast-Open-Verbindungsanzahl
├─ Erkennung anomaler Muster (z. B. mehrfache Verwendung desselben Cookies)
└─ Temporäres Deaktivieren von Fast Open für verdächtige IPs

4.3. Ressourcenerschöpfungsangriffe (Resource Exhaustion)​

SYN-Flood-Angriffsvariante​

TFO kann für erweiterte SYN-Flood-Angriffe missbraucht werden:

Traditioneller SYN-Flood:
Angreifer → Viele SYNs → Server (erschöpft Halbverbindungswarteschlange)

TFO-SYN-Flood:
Angreifer → Viele SYNs + Cookie + Daten → Server
   ↓
Server muss:
   ├─ Cookie validieren (CPU)
   ├─ Daten verarbeiten (CPU + Speicher)
   └─ Möglicherweise Anwendungslogik auslösen (mehr Ressourcen)

Schutzmaßnahmen​

1. SYN-RECEIVED-Zustandsbegrenzung

Server MUSS:

  • Anzahl der Verbindungen im SYN-RECEIVED-Zustand begrenzen
  • Strengere Begrenzungen für TFO-Verbindungen festlegen

Implementierungsempfehlung:

#define MAX_SYN_RECEIVED_NORMAL  1024
#define MAX_SYN_RECEIVED_TFO     512   // TFO-Begrenzung niedriger

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++;
    }
    // ... Verarbeitung fortsetzen
}

2. Anwendungsschicht-Isolation

Server SOLLTE:

  • Zustellung von SYN-Daten an die Anwendungsschicht verzögern, bis ACK empfangen wird
  • Oder im SYN-RECEIVED-Zustand nur leichtgewichtige Verarbeitung durchführen

3. Kostenkontrolle der Cookie-Berechnung

Cookie-Validierung optimieren:
├─ Effizienten Verschlüsselungsalgorithmus verwenden (z. B. AES-NI-Hardwarebeschleunigung)
├─ Cookie-Cache implementieren (kurzfristige Caching-Validierungsergebnisse)
├─ Offensichtlich ungültige Cookies schnell ablehnen
└─ CPU-Auslastung überwachen, Strategie dynamisch anpassen

4. Integration mit SYN-Cookies

Server KANN TCP-SYN-Cookies kombiniert einsetzen:

  • SYN-Cookies: Zustandsloser SYN-Flood-Schutz
  • TFO-Cookies: Zustandsbehaftete Leistungsoptimierung
Schutzstrategie:
if (under_attack) {
    // Bei hoher Last TFO deaktivieren, SYN-Cookies aktivieren
    disable_tfo();
    enable_syn_cookies();
} else {
    // Normal: Beide aktivieren
    enable_tfo();
    enable_syn_cookies();  // Als Backup
}

4.4. Replay-Angriffe (Replay Attacks)​

Angriffsszenario​

Angreifer fangen TFO-SYN-Pakete ab und spielen sie erneut ab:

Szenario 1: Netzwerkabhören
Angreifer (Abhören) ─┐
                      ↓
Client ────SYN + Cookie + "GET /transfer?amount=100"───→ Server
                      ↑
Angreifer (Replay) ───┘  → Überweisungsoperation wiederholt ausführen!

Schutzmaßnahmen​

1. Idempotenzanforderung

Anwendungsschicht MUSS:

  • Nur idempotente Operationen in TFO-SYN senden
  • Beispiele:
    • ✓ Erlaubt: GET-Anfragen, Nur-Lese-Operationen
    • ✗ Verboten: POST, PUT, DELETE und andere Operationen mit Nebeneffekten

Client-Leitfaden:

def can_use_tfo(request):
    # TFO nur für idempotente Anfragen verwenden
    if request.method in ['GET', 'HEAD', 'OPTIONS']:
        return True
    if request.method == 'POST' and request.is_idempotent:
        return True  # Anwendung explizit als idempotent markiert
    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. TCP-Sequenznummernschutz

TCP-eigene Mechanismen bieten grundlegenden Schutz:

  • Server verfolgt empfangene Sequenznummern
  • Daten mit doppelten Sequenznummern werden verworfen
  • Einschränkung: Nur während der Verbindungsdauer gültig

3. Anwendungsschicht-Deduplizierung

Server-Anwendung SOLLTE:

  • Anfrage-Deduplizierungsmechanismus implementieren (z. B. Anfrage-ID)
  • Zusätzliche Validierung für sensible Operationen verwenden (z. B. CSRF-Token)

4. Cookie-Zeitgültigkeit

  • Nach Cookie-Ablauf werden alte Replay-Angriffe unwirksam
  • Kurze Cookie-Gültigkeitsdauer reduziert das Replay-Zeitfenster

4.5. Datenschutzüberlegungen (Privacy Considerations)​

Bedrohung: TFO-Cookies könnten als persistente Benutzer-Tracking-Bezeichner verwendet werden:

Datenschutzrisiko:
Client-IP ändert sich → Cookie bleibt gültig
   ↓
Server kann Verbindungen von verschiedenen IPs verknüpfen
   ↓
Potenzielle Benutzeridentitätsverknüpfung und -verfolgung

Schutzmaßnahmen​

1. Cookie an IP gebunden

Cookie MUSS an IP-Adresse gebunden sein:

  • Nach IP-Änderung wird Cookie ungültig
  • Neues Cookie muss angefordert werden

Abwägung:

  • ✓ Verbesserten Datenschutz
  • ✗ Häufige Cookie-Aktualisierungen in Mobilfunknetz-IP-Drift-Szenarien erforderlich

2. Begrenzte Cookie-Lebensdauer

  • Empfohlene Gültigkeitsdauer: Stunden bis 1 Tag
  • Cookies regelmäßig rotieren
  • Cookies löschen, wenn Benutzer Browserdaten löscht

3. Cookie enthält keine Benutzerinformationen

Cookie DARF NICHT:

  • Benutzer-ID oder Sitzungs-ID enthalten
  • Benutzeridentifizierbare Informationen enthalten
  • Über verschiedene Dienste hinweg geteilt werden

Cookie SOLLTE:

  • Nur zur Überprüfung verwendet werden, dass der Client zuvor mit dem Server verbunden war
  • Keine Zustandsinformationen übertragen

4. Benutzerkontrolle

Client SOLLTE bereitstellen:

  • Option zum Deaktivieren von TFO
  • Funktion zum Löschen von TFO-Cookies
  • TFO-Cookies im Datenschutzmodus deaktivieren

4.6. Interaktion mit anderen Sicherheitsmechanismen (Interaction with Other Security Mechanisms)​

TLS/SSL-Integration​

Überlegungen bei kombinierter Verwendung von TFO und TLS:

TFO + TLS-Handshake:
Client                              Server
   |                                  |
   | SYN + TFO Cookie + TLS ClientHello |
   |---------------------------------->|
   |                                  |
   | SYN-ACK + TLS ServerHello       |
   |<----------------------------------|
   |                                  |
   | ACK + TLS ...                    |
   |---------------------------------->|

Vorteile:

  • Weitere Latenzreduzierung (TLS 1.3 + TFO = 0-RTT)
  • TLS bietet zusätzliche Sicherheitsschicht

Hinweis:

  • TLS-0-RTT-Daten erfordern ebenfalls Idempotenz
  • Sicherheit von TFO und TLS muss gleichzeitig berücksichtigt werden

Firewalls und NAT​

Kompatibilitätsprobleme:

Einige Middleboxen können:
├─ TCP-Fast-Open-Optionen entfernen
├─ SYN-Pakete mit Daten blockieren
├─ TCP-Optionsfelder ändern
└─ Strenge Zustandsverfolgung implementieren

Gegenmaßnahmen:
├─ Client implementiert Rückfallmechanismus
├─ TFO-Unterstützung erkennen
├─ Deaktivierungsoption bereitstellen
└─ Server protokolliert Kompatibilitätsprobleme

DoS-Schutzsysteme​

TFO SOLLTE mit bestehenden DoS-Schutzsystemen koordiniert werden:

Integrationsempfehlungen:
├─ DDoS-Schutzgeräte SOLLTEN TFO-Optionen verstehen
├─ Ratenbegrenzung SOLLTE TFO-Datenverkehr berücksichtigen
├─ Anomalieerkennung SOLLTE TFO-Missbrauchsmuster erkennen
└─ TFO kann bei Angriffen dynamisch deaktiviert werden

4.7. Zusammenfassung der Sicherheits-Best-Practices (Security Best Practices Summary)​

Serverseitig​

MUSS implementiert werden:

  • ✓ Cookie an Client-IP binden
  • ✓ SYN-Datengröße begrenzen
  • ✓ SYN-ACK-Antwortgröße begrenzen (vor ACK)
  • ✓ Cookie-Ablaufmechanismus
  • ✓ Ratenbegrenzung

SOLLTE implementiert werden:

  • ✓ Server-Schlüssel regelmäßig rotieren
  • ✓ TFO-Nutzungsmuster überwachen
  • ✓ Mit SYN-Cookies integrieren
  • ✓ Anfrage-Deduplizierung auf Anwendungsschicht
  • ✓ Strategie dynamisch anpassen (basierend auf Last)

KANN implementiert werden:

  • ✓ Erweiterte Bedrohungserkennung
  • ✓ Cookie-Versionsverwaltung
  • ✓ Geolokalisierungsvalidierung
  • ✓ Machine-Learning-Anomalieerkennung

Clientseitig​

MUSS implementiert werden:

  • ✓ TFO nur für idempotente Operationen verwenden
  • ✓ Cookie sicher speichern
  • ✓ Fähigkeit zum Rückfall auf Standard-TCP

SOLLTE implementiert werden:

  • ✓ Cookie-Ablaufverwaltung
  • ✓ Benutzerdatenschutzkontrolle
  • ✓ Fehlererkennungs- und Wiederholungslogik
  • ✓ Datenschutzmodus-Unterstützung

Anwendungsschicht​

Empfehlungen:

Idempotenzprüfung:
├─ GET/HEAD-Anfragen → TFO standardmäßig erlauben
├─ POST/PUT/DELETE → TFO standardmäßig verbieten
├─ Anwendungsspezifische Logik → explizit markieren
└─ Sensible Operationen → TFO immer verbieten

Datenvalidierung:
├─ Nicht auf TFO-Sicherheit verlassen
├─ Anwendungsschicht-Authentifizierung implementieren
├─ TLS-Verschlüsselung verwenden
└─ Anfrage-Signierung und -Validierung

Nächster Abschnitt: 5. IANA Considerations (IANA-Überlegungen) erläutert die Optionsnummernzuweisung für TCP Fast Open.

5. IANA Considerations (IANA-Überlegungen)​

Dieses Kapitel erläutert die Anforderungen und Zuweisungen von TCP Fast Open für IANA-Registrierungen.

5.1. TCP-Optionsnummernzuweisung (TCP Option Kind Assignment)​

TCP Fast Open verwendet TCP-Optionen (TCP Options), um Cookies und zugehörige Informationen zu übertragen. Gemäß RFC 6994 „Shared Use of Experimental TCP Options" wurde TCP Fast Open eine experimentelle Optionsnummer zugewiesen.

Optionsnummer​

TCP Option Kind Number: 34

Offizieller Name: TCP Fast Open Cookie
Referenzdokument: RFC 7413
Zuweisungsstatus: Experimental (Experimentell)

Optionsformat​

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

Feldbeschreibung:

  • Kind: 8 Bit, fester Wert 34
  • Length: 8 Bit, Wertebereich 2–18
    • Length=2: Cookie-Anfrage (keine Cookie-Daten)
    • Length=6–18: Cookie-Antwort oder -Verwendung (4–16 Byte Cookie)
  • Cookie: variable Länge, 4–16 Byte

5.2. Erläuterung des experimentellen Status (Experimental Status)​

Bedeutung des experimentellen Protokolls​

TCP Fast Open ist als Experimental (Experimentell) gekennzeichnet, was bedeutet:

  1. Kein Standardpfad:

    • Nicht auf dem IETF-Standardpfad (Standards Track)
    • Zielt auf Experiment und Bewertung der technischen Machbarkeit ab
    • Kann in Zukunft überarbeitet oder aufgegeben werden

  2. Bereitstellungsempfehlungen:

    • Implementierer SOLLTEN den experimentellen Charakter verstehen
    • Bei der Bereitstellung SOLLTEN Kompatibilität und Sicherheit sorgfältig berücksichtigt werden
    • Anpassungen in späteren Versionen können erforderlich sein

  3. Entwicklung zum Standard:

    • Basierend auf Implementierungserfahrungen kann eine Hochstufung zum Standard erfolgen
    • Oder wesentliche Überarbeitungen basierend auf Rückmeldungen
    • Oder Ersatz durch neue Mechanismen

Hinweise für Implementierer​

Empfehlungen:

Bereitstellungs-Checkliste:
├─ Bei der Implementierung RFC 7413-Spezifikation befolgen
├─ Konfigurationsoption zum Deaktivieren von TFO bereitstellen
├─ Probleme in der tatsächlichen Nutzung überwachen
├─ Implementierungserfahrungen an IETF zurückmelden
└─ Nachfolgende RFC-Updates verfolgen

Kompatibilitätszusagen:

  • Experimentelle Protokolle können sich in zukünftigen Versionen ändern
  • Implementierungen SOLLTEN für Rückwärtskompatibilität ausgelegt sein
  • Unterstützung der Protokollversionsaushandlung wird empfohlen

5.3. Optionsnummernfreigabe (Option Number Sharing)​

Gemäß RFC 6994 können experimentelle TCP-Optionen den Nummernraum teilen. TCP Fast Open verwendet eine eigenständige Optionsnummer (34) und teilt diese nicht mit anderen experimentellen Optionen.

Konfliktvermeidung​

Identifikationsmechanismus:

  • Festen Kind-Wert (34) verwenden
  • Anfrage und Antwort über das Length-Feld unterscheiden
  • Cookie-Inhalt wird von der jeweiligen Implementierung definiert

Interoperabilität:

Kompatibilität zwischen verschiedenen Implementierungen:
├─ MUSS denselben Kind-Wert (34) verwenden
├─ MUSS dieselben Length-Konventionen einhalten
├─ Cookie-Format wird vom Server unabhängig definiert (keine Interoperabilität erforderlich)
└─ Client und Server MÜSSEN aus kompatiblen Implementierungen stammen

5.4. Zukünftige Überlegungen (Future Considerations)​

Standardisierungspfad​

Wenn TCP Fast Open sich als erfolgreich und weit verbreitet erweist, sind folgende Entwicklungspfade möglich:

  1. Hochstufung zum Proposed Standard:

    • Spezifikation basierend auf Implementierungserfahrungen überarbeiten
    • Bekannte Probleme und Einschränkungen beheben
    • Offiziell in den IETF-Standardpfad aufnehmen

  2. Neuzuweisung der Optionsnummer:

    • Möglicherweise offizielle (nicht-experimentelle) Optionsnummer zuweisen
    • Oder bestehende Nummer 34 beibehalten

  3. Protokollverbesserungen:

    • Möglicherweise Versionsfeld einführen
    • Cookie-Format erweitern
    • Neue Sicherheitsfunktionen hinzufügen

Bekannte Implementierungen (Known Implementations)​

Zum Zeitpunkt der Veröffentlichung von RFC 7413 existierten mehrere Implementierungen:

Betriebssysteme:

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

Anwendungen:

  • Google Chrome
  • Mozilla Firefox
  • curl
  • nginx

Die weit verbreitete Bereitstellung dieser Implementierungen bietet eine praktische Grundlage für die Standardisierung.

5.5. Registrierungszusammenfassung (Registration Summary)​

Element: TCP Option
Parameter: Kind
Wert: 34
Name: TCP Fast Open Cookie
Referenz: RFC 7413
Datum: 2014-12
Hinweis: Experimental

Kontaktinformationen​

Dokumenteditoren:

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

IETF-Arbeitsgruppe:

  • TCP Maintenance and Minor Extensions (tcpm)

Mailingliste:

Nächster Abschnitt: 6. References (Referenzen) listet die normativen und informativen Referenzen dieser Spezifikation auf.

6. References (Referenzen)​

Dieses Kapitel listet die normativen und informativen Referenzen auf, die in RFC 7413 zitiert werden.

6.1. Normative Referenzen (Normative References)​

Diese Dokumente sind für das Verständnis und die Implementierung von TCP Fast Open erforderlich.

[RFC793] Transmission Control Protocol​

Titel: Transmission Control Protocol
Autor: J. Postel
Datum: September 1981
Status: Internet Standard (STD 7)

Relevanz: Die grundlegende TCP-Spezifikation, die die Kernmechanismen des TCP-Protokolls definiert, einschließlich Drei-Wege-Handshake, Zustandsmaschine, Sequenznummern usw. TCP Fast Open ist eine Erweiterung dieses Basisprotokolls.

Wichtige referenzierte Inhalte:

  • TCP-Verbindungsherstellung (Drei-Wege-Handshake)
  • TCP-Zustandsmaschine
  • TCP-Optionsmechanismus
  • Sequenz- und Bestätigungsnummern

Link: RFC 793 - Transmission Control Protocol

[RFC2119] Key words for use in RFCs​

Titel: Key words for use in RFCs to Indicate Requirement Levels
Autor: S. Bradner
Datum: März 1997
Status: Best Current Practice (BCP 14)

Relevanz: Definiert die Bedeutung von Schlüsselwörtern in RFCs (MUST, SHOULD, MAY usw.) zur Klarstellung der Anforderungsstufen der Spezifikation.

Schlüsselbegriffe:

  • MUST / REQUIRED / SHALL: Absolute Anforderung
  • MUST NOT / SHALL NOT: Absolutes Verbot
  • SHOULD / RECOMMENDED: Dringend empfohlen
  • SHOULD NOT / NOT RECOMMENDED: Nicht empfohlen
  • MAY / OPTIONAL: Optional

Link: RFC 2119 - Key words for use in RFCs

[RFC6994] Shared Use of Experimental TCP Options​

Titel: Shared Use of Experimental TCP Options
Autor: J. Touch
Datum: August 2013
Status: Proposed Standard

Relevanz: Definiert den Zuweisungs- und Freigabemechanismus für experimentelle TCP-Optionen. Die Optionsnummer (34) von TCP Fast Open basiert auf diesem Framework.

Wichtige Inhalte:

  • Bereich der experimentellen Optionsnummern
  • Mechanismus zur Optionsnummernfreigabe
  • Leitfaden für experimentelle Bereitstellung

[RFC5925] The TCP Authentication Option​

Titel: The TCP Authentication Option
Autor: J. Touch, A. Mankin, R. Bonica
Datum: Juni 2010
Status: Proposed Standard

Relevanz: TCP-Authentifizierungsoption, die mit TCP Fast Open im Optionsraum koordiniert werden muss.

6.2. Informative Referenzen (Informative References)​

Diese Dokumente liefern Hintergrundinformationen und relevanten Kontext, sind aber keine Voraussetzung für die Implementierung.

[RFC4987] TCP SYN Flooding Attacks and Common Mitigations​

Titel: TCP SYN Flooding Attacks and Common Mitigations
Autor: W. Eddy
Datum: August 2007
Status: Informational

Relevanz: Beschreibt SYN-Flood-Angriffe und Schutzmaßnahmen. Das Sicherheitsdesign von TCP Fast Open muss diese Bedrohungen berücksichtigen.

Wichtige Inhalte:

  • Prinzip des SYN-Flood-Angriffs
  • SYN-Cookies-Mechanismus
  • Schutzstrategien

Beziehung zu TFO:

  • TFO DARF NICHT die SYN-Flood-Bedrohung verschlimmern
  • TFO kann mit SYN-Cookies koexistieren

[RFC4953] Defending TCP Against Spoofing Attacks​

Titel: Defending TCP Against Spoofing Attacks
Autor: J. Touch
Datum: Juli 2007
Status: Informational

Relevanz: Diskutiert TCP-Spoofing-Angriffe und Schutzmaßnahmen. Der TFO-Cookie-Mechanismus orientiert sich teilweise an diesen Prinzipien.

Schlüsselkonzepte:

  • IP-Spoofing-Angriffe
  • Sequenznummernrandomisierung
  • Verbindungsvalidierung

[RFC5681] TCP Congestion Control​

Titel: TCP Congestion Control
Autor: M. Allman, V. Paxson, E. Blanton
Datum: September 2009
Status: Draft Standard

Relevanz: TCP-Staukontrollmechanismus. TFO muss korrekt mit der Staukontrolle interagieren.

Wichtige Inhalte:

  • Slow Start (Langsamer Start)
  • Congestion Avoidance (Stauvermeidung)
  • Schnelle Wiederübertragung und schnelle Wiederherstellung

Beziehung zu TFO:

  • Staukontrollbehandlung von SYN-Daten
  • Anfängliches Staufenster

Titel: TCP Cookie Transactions (TCPCT)
Autor: W. Simpson
Datum: Januar 2011
Status: Experimental

Relevanz: Ein weiterer TCP-Cookie-Mechanismus mit ähnlichen Zielen, aber unterschiedlichem Design.

Vergleich:

  • TCPCT ist komplexer und unterstützt mehr Funktionen
  • TFO ist einfacher und leichter bereitzustellen
  • TFO hat letztendlich eine breitere Implementierung erhalten

[RFC7323] TCP Extensions for High Performance​

Titel: TCP Extensions for High Performance
Autor: D. Borman, B. Braden, V. Jacobson, R. Scheffenegger
Datum: September 2014
Status: Proposed Standard

Relevanz: TCP-Leistungserweiterungen, einschließlich Fensterskalierung, Zeitstempel usw. TFO ist eine weitere Leistungsoptimierungserweiterung.

Wichtige Erweiterungen:

  • Window Scale (Fensterskalierung)
  • Timestamps (Zeitstempel)
  • PAWS (Protection Against Wrapped Sequences)

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

Titel: RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
Autor: E. Rescorla
Datum: August 2018
Status: Proposed Standard

Relevanz: Die 0-RTT-Funktion von TLS 1.3 kann in Kombination mit TFO die Latenz weiter reduzieren.

Synergieeffekte:

TFO + TLS 1.3 0-RTT:
   Client ──SYN + TFO Cookie + TLS ClientHello + App-Daten──> Server
   
   Gesamtlatenz: 0-RTT (theoretisch)

Sicherheitsüberlegungen:

  • Sicherheitsannahmen beider Mechanismen müssen gleichzeitig erfüllt sein
  • Idempotenzanforderung für 0-RTT-Daten

Link: RFC 8446 - TLS 1.3

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

Titel: RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)
Autor: M. Belshe, R. Peon, M. Thomson
Datum: Mai 2015
Status: Proposed Standard

Relevanz: HTTP/2 kann in Kombination mit TFO zur Optimierung der Web-Leistung verwendet werden.

Synergismechanismus:

  • TFO reduziert Verbindungsaufbaulatenz
  • HTTP/2-Multiplexing reduziert Verbindungsanzahl
  • Kombination beider maximiert die Leistung

Link: RFC 7540 - HTTP/2

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

Titel: RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
Autor: J. Iyengar, M. Thomson
Datum: Mai 2021
Status: Proposed Standard

Relevanz: QUIC ist ein neues Transportprotokoll mit nativem 0-RTT-Verbindungsaufbau und kann als Verkörperung des TFO-Konzepts in einem neuen Protokoll betrachtet werden.

Vergleich:

  • QUIC 0-RTT: UDP-basiert, integrierte Verschlüsselung
  • TCP TFO: TCP-basiert, erfordert zusätzliche TLS-Schicht
  • QUIC vermeidet einige historische Einschränkungen von TCP

Link: RFC 9000 - QUIC

Linux-Kernel-Dokumentation​

Documentation/networking/tcp-fast-open.txt

Implementierungsdokumentation für TCP Fast Open im Linux-Kernel.

IETF-Arbeitsgruppe​

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

Arbeitsgruppe zur Diskussion von TCP-Protokollwartung und -erweiterungen.

Leistungsmesswerkzeuge​

  • netstat: TFO-Statistiken anzeigen
  • tcpdump/wireshark: TFO-Pakete erfassen und analysieren
  • ss (socket statistics): TFO-Status unter Linux anzeigen

Akademische Forschung​

Mehrere akademische Arbeiten analysieren die Leistung und Sicherheit von TFO:

  • Googles TFO-Leistungsforschung (SIGCOMM 2011)
  • TFO-Sicherheitsanalyse (USENIX Security)
  • Berichte über praktische Bereitstellungserfahrungen

Nächster Abschnitt: 7. Acknowledgments (Danksagungen) dankt den Personen und Organisationen, die zu dieser Spezifikation beigetragen haben.

7. Acknowledgments (Danksagungen)​

Die Entwicklung und Standardisierung von TCP Fast Open profitierte von den Beiträgen vieler Einzelpersonen und Organisationen.

7.1. Hauptbeitragende (Primary Contributors)​

RFC-Autoren (Authors)​

Yuchung Cheng
Google, Inc.
E-Mail: [email protected]

Jerry Chu
Google, Inc.
E-Mail: [email protected]

Sivasankar Radhakrishnan
Google, Inc.
E-Mail: [email protected]

Arvind Jain
Google, Inc.
E-Mail: [email protected]

Diese Autoren haben den TCP-Fast-Open-Mechanismus während ihrer Tätigkeit bei Google entworfen, implementiert und getestet und die Erstellung des RFC geleitet.

7.2. Technische Beiträge (Technical Contributions)​

Protokolldesign​

Dank an folgende Personen für ihre wertvollen Beiträge zum TFO-Protokolldesign:

  • Nandita Dukkipati (Google) – Leistungsanalyse und Staukontrolle
  • Neal Cardwell (Google) – TCP-Implementierungsexperte
  • Lawrence Brakmo (Facebook) – Frühe Überprüfung und Rückmeldungen
  • Eric Dumazet (Google) – Linux-Kernel-Implementierung

Sicherheitsanalyse​

Das Kapitel zu Sicherheitsüberlegungen profitierte von:

  • Joe Touch (USC/ISI) – TCP-Sicherheitsexperte, lieferte wichtige Sicherheitsempfehlungen
  • Wesley Eddy (MTI Systems) – SYN-Flood-Schutzexperte
  • Michael Scharf (Alcatel-Lucent) – Sicherheitsbedrohungsanalyse
  • Mirja Kühlewind (ETH Zürich) – Risikobewertung für experimentelle Bereitstellung

Implementierung und Tests​

Dank an die Organisationen für ihre Beiträge zur TFO-Implementierung und -Tests:

Linux-Kernel:

  • Wei Wang (Google) – Kernel-Implementierung und -Optimierung
  • David S. Miller – Netzwerk-Subsystem-Betreuer
  • Eric Dumazet – Leistungsoptimierung

BSD-Systeme:

  • FreeBSD-Team – FreeBSD-Implementierung
  • Apple – macOS/iOS-Implementierung

Anwendungen:

  • Chrome-Team (Google) – Browser-Integration
  • Firefox-Team (Mozilla) – Browser-Unterstützung
  • nginx-Team – Webserver-Unterstützung
  • curl-Projekt – Befehlszeilenwerkzeug-Unterstützung

7.3. IETF-Gemeinschaft (IETF Community)​

TCPM-Arbeitsgruppe​

Besonderer Dank an die Mitglieder der TCP Maintenance and Minor Extensions (TCPM)-Arbeitsgruppe:

Arbeitsgruppenvorsitzende:

  • Wesley Eddy
  • Yoshifumi Nishida

Aktive Teilnehmer:

  • 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

Mailinglisten-Diskussionen​

Dank an alle Mitglieder der Mailingliste [email protected], die an Diskussionen teilgenommen und Rückmeldungen und Vorschläge gegeben haben.

7.4. Gutachter (Reviewers)​

Besonderer Dank an folgende Personen für ihre detaillierte Überprüfung der RFC-Entwürfe:

  • Joe Touch – Mehrere eingehende Überprüfungsrunden mit zahlreichen technischen Verbesserungsvorschlägen
  • Alexander Zimmermann – Protokolldetails und Implementierungsempfehlungen
  • Mark Allman – Staukontrolle und Leistungsüberlegungen
  • Fernando Gont – Sicherheits- und Betriebsüberlegungen
  • Ted Faber – Leitfaden für experimentelle Protokolle

IETF-Bereichsüberprüfung​

Dank an die IETF-Bereichsdirektoren und das Überprüfungsteam:

  • Transport Area Directors – Leitfaden für den Standardisierungsprozess
  • Security Area Review Team – Sicherheitsüberprüfung
  • Operations Area Review Team – Überprüfung der Betriebsüberlegungen

7.5. Forschungsunterstützung (Research Support)​

Akademische Zusammenarbeit​

Dank an folgende akademische Einrichtungen für ihre Forschungsunterstützung:

  • UC Berkeley – Netzwerkleistungsforschung
  • MIT – Protokolldesign und -analyse
  • ETH Zürich – Forschung zur experimentellen Bereitstellung
  • University of Southern California (USC/ISI) – TCP-Protokoll-Expertise

Leistungsmessungen​

Dank an die Organisationen, die tatsächliche Netzwerkmessdaten bereitgestellt haben:

  • Google – Daten aus großflächiger Bereitstellung
  • Facebook – Tests in Rechenzentrumsumgebungen
  • Akamai – CDN-Bereitstellungserfahrungen
  • Cloudflare – Globale Netzwerkleistungsdaten

Das Design von TCP Fast Open wurde von folgenden früheren Arbeiten inspiriert:

RFC 6013 von William Allen Simpson
TCPCT ist ein weiterer TCP-Cookie-Mechanismus. Obwohl TFO ein anderes Design verfolgt, lieferte TCPCT wertvolle Designerfahrungen und Lektionen.

T/TCP (TCP for Transactions)​

RFC 1644 von Bob Braden
T/TCP war ein früher Versuch, den TCP-Verbindungsaufwand zu reduzieren. Obwohl es nicht weit verbreitet wurde, legte es die theoretische Grundlage für spätere Arbeiten.

SYN-Cookies​

Der von Daniel J. Bernstein erfundene SYN-Cookies-Mechanismus inspirierte das zustandslose Validierungskonzept von TFO.

7.7. Industrieunterstützung (Industry Support)​

Hauptunterstützer​

Google:

  • Finanzierung der ursprünglichen Forschung und Entwicklung
  • Bereitstellung einer Plattform für großflächige Bereitstellung
  • Open-Source-Kernel-Implementierung

Linux Foundation:

  • Unterstützung der Linux-Kernel-Implementierung
  • Förderung der Open-Source-Community-Zusammenarbeit

IETF:

  • Bereitstellung einer Standardisierungsplattform
  • Organisation von Überprüfungen und Diskussionen

Frühe Anwender​

Dank an folgende Organisationen für frühe Bereitstellung und Rückmeldungen:

  • Google – Suche, YouTube, Gmail und andere Dienste
  • Facebook – Mobile Anwendungen und Webdienste
  • LinkedIn – API-Dienste
  • CloudFlare – CDN-Dienste
  • Fastly – Edge-Computing-Plattform

Die praktischen Bereitstellungserfahrungen dieser Organisationen waren entscheidend für die Validierung der Praxistauglichkeit von TFO und die Entdeckung potenzieller Probleme.

7.8. Kontinuierliche Verbesserung (Continuous Improvement)​

TCP Fast Open wird kontinuierlich verbessert. Wir ermutigen:

  • Implementierer: Bereitstellungserfahrungen und Implementierungstipps teilen
  • Forscher: Leistungs- und Sicherheitsanalysen veröffentlichen
  • Betreiber: Probleme in tatsächlichen Netzwerken melden
  • Standardisierer: Protokollverbesserungsvorschläge einbringen

Rückmeldungskanäle​

Schlussfolgerung (Conclusion)​

TCP Fast Open ist das Ergebnis der Zusammenarbeit vieler Einzelpersonen und Organisationen. Von der ursprünglichen Konzeption über das Protokolldesign, die Implementierung, Tests, Bereitstellung bis hin zur endgültigen Standardisierung war jeder Schritt auf die Unterstützung und Beiträge der Gemeinschaft angewiesen.

Besonderer Dank gilt allen, die an diese Technologie geglaubt und bereit waren, Zeit und Energie zu investieren, um sie Wirklichkeit werden zu lassen. Die erfolgreiche Bereitstellung von TCP Fast Open beweist die Kraft offener Standards und der Zusammenarbeit in der Gemeinschaft.

Wir freuen uns darauf, dass TFO sich in Zukunft weiterentwickelt und Internetnutzern weltweit ein schnelleres und effizienteres Netzwerkerlebnis bietet.

Nächster Abschnitt: Anhang A. Vergleich mit TCP Cookies (SYN Cookies) vergleicht die TFO- und SYN-Cookies-Mechanismen im Detail.

Anhang A. Vergleich mit TCP Cookies (SYN Cookies)​

Dieser Anhang vergleicht TCP Fast Open (TFO) und TCP SYN Cookies im Detail und hilft dabei, ihre unterschiedlichen Ziele und Anwendungsszenarien zu verstehen.

A.1. Übersicht (Overview)​

Obwohl TFO und SYN Cookies beide das „Cookie"-Konzept verwenden, dienen sie völlig unterschiedlichen Zwecken:

TFO (TCP Fast Open):
Ziel: Verbindungslatenz reduzieren, Leistung verbessern
Mechanismus: Vorab zugewiesenes Cookie, erlaubt SYN-Daten
Zustand: Zustandsbehaftet (Cookie gecacht)

SYN Cookies:
Ziel: SYN-Flood-Angriffe abwehren, Server schützen
Mechanismus: Zustandslose Antwort, Informationen in ISN kodiert
Zustand: Zustandslos (kein SYN-RECEIVED-Zustand gespeichert)

A.2. Vergleich der Designziele (Design Goals Comparison)​

TCP Fast Open (TFO)​

Hauptziele:

  1. Leistungsoptimierung: Latenz beim TCP-Verbindungsaufbau reduzieren
  2. Rückwärtskompatibilität: Koexistenz mit bestehenden TCP-Implementierungen
  3. Sicherheit: TCP-Sicherheit nicht verschlechtern

Anwendungsszenarien:

  • Unter normalen Netzwerkbedingungen
  • Wenn Client und Server TFO unterstützen
  • Latenzsensitive Anwendungen (Web, API)

TCP SYN Cookies​

Hauptziele:

  1. SYN-Flood-Abwehr: DoS-Angriffe abwehren
  2. Zustandsloses Design: Keine Serverressourcen verbrauchen
  3. Notfallmaßnahme: Bei Angriffen automatisch aktivieren

Anwendungsszenarien:

  • Während SYN-Flood-Angriffen
  • Wenn Serverressourcen knapp sind
  • Als letzte Verteidigungslinie

A.3. Vergleich der technischen Mechanismen (Technical Mechanisms)​

TFO-Cookie:

# Vorab generiert, persistent gespeichert
TFO_Cookie = Encrypt(ServerSecret, ClientIP || Timestamp)

Eigenschaften:
- Server generiert aktiv und sendet an Client
- Client speichert Cookie für spätere Verbindungen im Cache
- Cookie hat eine explizite Ablaufzeit (Stunden bis Tage)
- Verwendet starken Verschlüsselungsalgorithmus (z. B. AES-128)

SYN-Cookie:

# Dynamisch in ISN kodiert, keine Speicherung erforderlich
SYN_Cookie = Hash(ServerIP, ServerPort, ClientIP, ClientPort, 
                  Timestamp, ServerSecret) + MSS_encoding

Eigenschaften:
- Wird beim Empfang eines SYN sofort berechnet
- In der Initial Sequence Number (ISN) kodiert
- Sehr kurze Gültigkeitsdauer (Minutenbereich)
- Verwendet schnelle Hash-Funktion

Zustandsverwaltung​

TFO-Zustandsverwaltung:

Client:
  ├─ Cookie für jeden Server cachen
  ├─ Cookie-Ablaufzeit verfolgen
  └─ In persistentem Speicher ablegen (z. B. Festplatte)

Server:
  ├─ Normaler TCP-Verbindungszustand (TCB)
  ├─ Empfangenes Cookie validieren
  └─ Optional: Cookie-Nutzungsstatistiken verfolgen

SYN-Cookies-Zustandsverwaltung:

Client:
  └─ Keine besondere Behandlung erforderlich (Standard-TCP)

Server:
  ├─ Kein SYN-RECEIVED-Zustand erstellen
  ├─ Zurückgegebene Sequenznummer im ACK validieren
  └─ ESTABLISHED-Zustand erst nach erfolgreicher Validierung erstellen

Verbindungsherstellungsablauf​

TFO-Verbindungsherstellung:

Client                                Server
   |                                    |
   | SYN + TFO Cookie + Daten          |
   |---------------------------------->|
   |                                    | (Cookie validieren, Daten akzeptieren)
   |                                    | (TCB erstellen, SYN-RECEIVED)
   | SYN-ACK (+ optionale Daten)       |
   |<----------------------------------|
   |                                    |
   | ACK                                |
   |---------------------------------->|
   |                                    | (ESTABLISHED)
   
Vorteil: 1 RTT eingespart, Daten können während Handshake übertragen werden

SYN-Cookies-Verbindungsherstellung:

Client                                Server
   |                                    |
   | SYN                                |
   |---------------------------------->|
   |                                    | (SYN-Cookie berechnen)
   |                                    | (kein TCB erstellen)
   | SYN-ACK (ISN = SYN-Cookie)        |
   |<----------------------------------|
   |                                    |
   | ACK (ACK = ISN + 1)               |
   |---------------------------------->|
   |                                    | (SYN-Cookie validieren)
   |                                    | (TCB erstellen, ESTABLISHED)
   
Vorteil: Zustandslos, kein Speicherverbrauch, SYN-Flood-Abwehr

A.4. Vergleich der Funktionsmerkmale (Feature Comparison)​

MerkmalTFOSYN CookiesErläuterung
HauptzielLeistungsoptimierungSicherheitsschutzUnterschiedliche Designabsichten
SYN-Datenübertragung✓ Unterstützt✗ Nicht unterstütztKernmerkmal von TFO
ZustandstypZustandsbehaftetZustandslosZustandslosigkeit ist Schlüssel bei SYN Cookies
Verbindungslatenz1 RTT reduziertStandard 3-WayTFO-Leistungsvorteil
ServerressourcenNormaler VerbrauchSehr geringSYN Cookies sparen Ressourcen
TCP-Optionen erhaltenVollständigNur MSSEinschränkung bei SYN Cookies
Fensterskalierung✓ Unterstützt✗ EingeschränktSYN Cookies verlieren Optionen
SACK-Unterstützung✓ Unterstützt✗ EingeschränktWie oben
Zeitstempel-Option✓ Unterstützt✗ EingeschränktWie oben
ECN-Unterstützung✓ Unterstützt✗ EingeschränktWie oben
Cookie-GültigkeitsdauerStunden–TageMinutenTFO-Cookie persistent
Client-Caching✓ Erforderlich✗ Nicht erforderlichTFO benötigt Client-Unterstützung
AngriffsschutzMittelSehr starkSYN Cookies speziell für Abwehr
BereitstellungskomplexitätMittelGeringSYN Cookies einfacher

A.5. Vergleich der Leistungsauswirkungen (Performance Impact)​

Unter normalen Bedingungen​

TFO:

Erstverbindung:
   Latenz: 1,5 RTT (gleich wie Standard-TCP)
   
Folgeverbindungen:
   Latenz: 0,5 RTT (1 RTT eingespart)
   Leistungsverbesserung: 15–40 % (HTTP-Anfragen)

SYN Cookies:

Alle Verbindungen:
   Latenz: 1,5 RTT (gleich wie Standard-TCP)
   
Nebeneffekte:
   - TCP-Optionen verloren (Fensterskalierung, SACK usw.)
   - Kann Leistung bei Langzeitverbindungen beeinträchtigen
   - MSS-Kodierungsbeschränkung (nur begrenzte MSS-Werte darstellbar)

Unter Angriffsbedingungen​

TFO:

Unter SYN-Flood:
   Probleme:
   - Cookie muss noch validiert werden (CPU-Verbrauch)
   - Kann SYN-Daten akzeptieren (Speicherverbrauch)
   - Angreifer kann Cookie-Mechanismus missbrauchen
   
   Gegenmaßnahmen:
   - SYN-Datengröße begrenzen
   - Ratenbegrenzung
   - TFO bei Bedarf deaktivieren

SYN Cookies:

Unter SYN-Flood:
   Vorteile:
   - Vollständig zustandslos, kein Speicherverbrauch
   - Schnelle Berechnung, geringer CPU-Verbrauch
   - Angriffe automatisch abwehren
   
   Abwägung:
   - Eingeschränkte Funktionalität (TCP-Optionen verloren)
   - Aber Dienst bleibt verfügbar

A.6. Sicherheitsvergleich (Security Comparison)​

TFO-Sicherheitsüberlegungen​

Schutzmechanismen:

✓ Cookie an IP-Adresse gebunden
✓ Cookie-Verschlüsselung und -Ablauf
✓ SYN-Datengröße begrenzt
✓ SYN-ACK-Antwortgröße begrenzt
✓ Ratenbegrenzung

Bedrohungen:
✗ Kann für Amplifikationsangriffe verwendet werden
✗ Zusätzlicher Validierungsaufwand erforderlich
✗ Cookie kann wiedergegeben werden (Idempotenzanforderung)

Geeignete Szenarien:

  • Normale Netzwerkumgebung
  • Vertrauenswürdige Clients
  • Leistungsoptimierung erforderlich

SYN-Cookies-Sicherheitsüberlegungen​

Schutzmechanismen:

✓ Vollständig zustandslos
✓ Schnelle Berechnung
✓ Automatische Aktivierung (Angriffserkennung)
✓ Keine Serverressourcen verbraucht

Einschränkungen:
✗ Eingeschränkte Funktionalität (TCP-Optionen verloren)
✗ MSS-Kodierung eingeschränkt
✗ TCP-Erweiterungen nicht unterstützt

Geeignete Szenarien:

  • Während SYN-Flood-Angriffen
  • Wenn Serverressourcen knapp sind
  • Als Notfallschutzmaßnahme

A.7. Kompatibilität und Bereitstellung (Compatibility and Deployment)​

TFO-Bereitstellung​

Anforderungen:

Client:
  ├─ Kernel- oder Anwendungsunterstützung erforderlich
  ├─ Cookie-Caching-Mechanismus erforderlich
  └─ Rückfall auf Standard-TCP erforderlich

Server:
  ├─ Kernel- oder Anwendungsunterstützung erforderlich
  ├─ Cookie-Generierung und -Validierung erforderlich
  └─ Konfiguration und Verwaltung erforderlich

Netzwerk:
  └─ Middleboxen können TCP-Optionen entfernen

Bereitstellungsstatus:

  • Linux 3.6+ unterstützt
  • Mainstream-Betriebssysteme unterstützen schrittweise
  • Anwendungen müssen TFO aktivieren

SYN-Cookies-Bereitstellung​

Anforderungen:

Client:
  └─ Keine Änderungen erforderlich (transparent)

Server:
  ├─ Kernel-Level-Unterstützung
  ├─ Konfigurierbar aktivierbar/deaktivierbar
  └─ Normalerweise standardmäßig aktiviert

Netzwerk:
  └─ Vollständig transparent, keine Auswirkungen

Bereitstellungsstatus:

  • Alle Mainstream-Betriebssysteme unterstützen
  • Weit verbreitet, standardmäßig aktiviert
  • Ausgereifte und stabile Technologie

A.8. Koexistenz und Zusammenarbeit (Coexistence and Cooperation)​

TFO und SYN Cookies können koexistieren​

Empfohlene Konfiguration:

Normal:
  ├─ TFO: Aktiviert (Leistungsoptimierung)
  └─ SYN Cookies: Aktiviert aber nicht ausgelöst (Backup)

Leichter Angriff:
  ├─ TFO: Weiter aktiv (mit Ratenbegrenzung)
  └─ SYN Cookies: Beginnen zu aktivieren (für einige Verbindungen)

Schwerer Angriff:
  ├─ TFO: Deaktiviert oder streng begrenzt
  └─ SYN Cookies: Vollständig aktiviert (Hauptschutz)

Nach Angriff:
  ├─ SYN Cookies: Schrittweise deaktivieren
  └─ TFO: Wieder aktivieren

Kooperative Optimierung​

Strategie:

def handle_syn(packet):
    if is_under_attack():
        # Bei Angriff SYN Cookies bevorzugen
        if use_syn_cookies:
            return handle_with_syn_cookies(packet)
    
    if packet.has_tfo_option():
        # Normal: TFO versuchen
        if validate_tfo_cookie(packet):
            return handle_tfo_connection(packet)
        else:
            # TFO fehlgeschlagen, auf Standard-TCP zurückfallen
            return handle_standard_tcp(packet)
    
    # Standard-TCP-Verarbeitung
    return handle_standard_tcp(packet)

A.9. Verwendungsempfehlungen (Usage Recommendations)​

Wann TFO verwenden​

Empfohlene Szenarien:

✓ Anwendungen mit geringen Latenzanforderungen (Web, API)
✓ Szenarien mit häufigen Kurzzeitverbindungen
✓ Anfrage-Antwort-Muster
✓ Idempotente Operationen
✓ Vertrauenswürdige Netzwerkumgebung

Beispiele:
- HTTP-GET-Anfragen
- DNS-Abfragen
- RPC-Aufrufe
- Nur-Lese-APIs

Nicht empfohlene Szenarien:

✗ Nicht-idempotente Operationen
✗ Hohe Sicherheitsanforderungen (sensible Operationen)
✗ Langzeitverbindungen (geringer Nutzen)
✗ Nicht vertrauenswürdige Umgebungen

Beispiele:
- Finanztransaktionen
- Schreiboperationen (POST/PUT/DELETE)
- WebSocket-Langzeitverbindungen
- Datenbankverbindungen

Wann SYN Cookies verwenden​

Empfohlene Szenarien:

✓ Alle öffentlich zugänglichen Server
✓ Websites mit hohem Datenverkehr
✓ Dienste, die DDoS-Angriffen ausgesetzt sein könnten
✓ Server mit begrenzten Ressourcen

Empfehlung: Standardmäßig aktivieren, als letzte Verteidigungslinie

Nicht empfohlene Szenarien:

✗ Interne Netzwerke (optional)
✗ Vollständig vertrauenswürdige Umgebungen

Hinweis: Aber selbst in diesen Szenarien schadet die Aktivierung nicht

A.10. Zusammenfassung (Summary)​

Wesentliche Unterschiede​

TFO (TCP Fast Open):
   Positionierung: Leistungsoptimierungswerkzeug
   Abwägung: Gewisse Sicherheit für Leistung opfern
   Bereitstellung: Client- und Server-Unterstützung erforderlich
   Wirkung: Latenz deutlich reduziert

SYN Cookies:
   Positionierung: Sicherheitsschutzmechanismus
   Abwägung: Einige Funktionen für Sicherheit opfern
   Bereitstellung: Serverseitig transparent aktivierbar
   Wirkung: SYN-Flood effektiv abgewehrt

Komplementäre Beziehung​

TFO und SYN Cookies sind keine Konkurrenten, sondern ergänzen sich:

TFO:
   „Das Schnelle noch schneller machen" – Leistung unter normalen Bedingungen optimieren

SYN Cookies:
   „Das Langsame nutzbar halten" – Verfügbarkeit unter Angriffsbedingungen aufrechterhalten

Ideale Bereitstellung:
   Beide gleichzeitig aktivieren, dynamisch je nach Netzwerkbedingungen umschalten

Ausblick​

Protokollentwicklung:
├─ TFO kann standardisiert werden (von experimentell zu Standard)
├─ SYN Cookies werden kontinuierlich verbessert (mehr Informationen kodieren)
├─ Neue Protokolle (wie QUIC) unterstützen 0-RTT nativ
└─ Intelligentere adaptive Mechanismen

Dokumentende. Vielen Dank für das Lesen der technischen Dokumentation zu RFC 7413 – TCP Fast Open.

Weitere Informationen finden Sie unter: