Zum Hauptinhalt springen

6.1.1.2. Robuste TCP-Initialisierung (Robust TCP Initialization)

Dieser Abschnitt beschreibt Best Practices für robuste ECN-Verhandlung in Gegenwart möglicher Netzwerkprobleme.

6.1.1.2.1. Grundprinzipien​

Eine robuste TCP-ECN-Implementierung SOLLTE:

  1. Versuchen, ECN zu verwenden wenn möglich
  2. Nicht fehlschlagen, wenn ECN nicht funktioniert
  3. Lernen aus Erfahrung über problematische Pfade
  4. Benutzerfreundlich sein ohne manuelle Intervention

6.1.1.2.2. Empfohlener Verbindungsaufbau-Algorithmus​

Funktion: TCP_Connect(Ziel)

Wenn (Cache sagt "Ziel blockiert ECN"):
    Sende SYN ohne ECN-Flags (ECE=0, CWR=0)
Sonst:
    Sende SYN mit ECN-Flags (ECE=1, CWR=1)
    
    Wenn (keine SYN-ACK-Antwort nach N Versuchen):
        // Mögliches ECN-Blockierungsproblem
        Markiere Ziel in Cache als "blockiert ECN"
        Sende SYN ohne ECN-Flags (ECE=0, CWR=0)
    
    Wenn (SYN-ACK empfangen):
        Wenn (SYN-ACK hat ECE=1):
            ECN ist aktiviert für diese Verbindung
        Sonst:
            ECN ist nicht aktiviert

6.1.1.2.3. Timeout-Werte​

Für ECN-Fallback-Entscheidung:

  • SOLLTE nach 3-6 SYN-Neuübertragungen erfolgen
  • Dies entspricht typischerweise 3-12 Sekunden
  • Sollte Standard-TCP-SYN-Neuübertragungsverhalten nicht übermäßig verzögern

6.1.1.2.4. Cache-Management​

Cache-Einträge SOLLTEN enthalten:​

  • Ziel-IP-Adresse oder Präfix
  • Zeitstempel der letzten Überprüfung
  • Status: "ECN funktioniert" / "ECN blockiert" / "unbekannt"

Cache-Ablauf:​

  • Einträge SOLLTEN nach einigen Stunden ablaufen (z.B. 1-24 Stunden)
  • Erlaubt Wiederprüfung, falls Netzwerkprobleme behoben wurden
  • KANN konfigurierbarer Ablaufzeitraum sein

Cache-Größe:​

  • SOLLTE vernünftig begrenzt sein (z.B. 1000-10000 Einträge)
  • KANN LRU (Least Recently Used) Ersatzstrategie verwenden

6.1.1.2.5. Umgang mit gemischten Ergebnissen​

Wenn Verbindungen zum gleichen Ziel manchmal mit ECN gelingen und manchmal fehlschlagen:

  • KANN Wahrscheinlichkeitsansatz verwenden
  • KANN auf pfadspezifische Probleme hinweisen (Multi-Path)
  • SOLLTE konservativ sein und ECN für dieses Ziel deaktivieren

6.1.1.2.6. Interaktion mit Happy Eyeballs​

Bei gleichzeitigen IPv4/IPv6-Verbindungsversuchen:

  • Jede IP-Version SOLLTE unabhängig ECN verhandeln
  • IPv4- und IPv6-Cache-Einträge SOLLTEN getrennt sein
  • Ein Pfad kann ECN unterstützen, während der andere es nicht tut

6.1.1.2.7. Logging und Diagnose​

Implementierungen SOLLTEN optional loggen:

  • Erfolgreiche ECN-Verhandlungen
  • Fehlgeschlagene ECN-Verhandlungen
  • Fallback auf Nicht-ECN
  • Cache-Hit-/Miss-Statistiken

Diese Informationen helfen bei:

  • Netzwerk-Debugging
  • Identifizierung problematischer Middleboxen
  • Messung der ECN-Bereitstellungsrate

6.1.1.2.8. Sicherheitsüberlegungen​

Timing-Angriffe:

  • Ein Angreifer könnte SYN-Pakete mit ECN selektiv verwerfen
  • Dies führt zu Fallback, aber bricht Verbindungen nicht
  • Ist normalerweise kein ernsthaftes Sicherheitsproblem

Cache-Vergiftung:

  • Ein Angreifer könnte versuchen, Cache mit falschen Informationen zu füllen
  • Cache-Ablauf und Größenbegrenzungen mindern dies
  • Konservatives Verhalten (Deaktivieren von ECN) ist sicher

6.1.1.2.9. Empfehlungen für Netzwerkadministratoren​

Netzwerkadministratoren, die ECN bereitstellen möchten, SOLLTEN:

  1. Middleboxen konfigurieren, um ECN-Pakete durchzulassen
  2. Firewalls aktualisieren, um ECN-Flags zu erlauben
  3. Überwachung einrichten für ECN-bezogene Verwerfungen
  4. Stufenweise Bereitstellung für einfacheres Debugging
Letztes Update am