9.2. IPsec-Tunnel (IPsec Tunnels)

Dieser Abschnitt spezifiziert die ECN-Behandlung für IPsec-Tunnel.

9.2.1. IPsec-Tunnel-Übersicht

IPsec-Tunnel unterscheiden sich von einfachen IP-in-IP-Tunneln durch:

• Sicherheitsverarbeitung: Verschlüsselung, Authentifizierung
• Security Associations (SAs): Explizite Tunnel-Vereinbarungen
• IKE-Verhandlung: Internet Key Exchange für SA-Aufbau

9.2.2. ECN-Herausforderungen für IPsec

Sicherheitsüberlegungen

• ECN-Feld ist außerhalb des verschlüsselten Payloads (in IP-Header)
• ECN-Bits können von Zwischenknoten geändert werden
• Änderungen an ECN müssen mit Sicherheitszielen kompatibel sein

Verhandlung erforderlich

• IPsec-Tunnel MÜSSEN ECN-Modus zwischen Endpunkten verhandeln
• SA-Parameter müssen ECN-Verhalten spezifizieren
• Beide Endpunkte müssen sich auf Limited vs. Full-Functionality einigen

9.2.3. IPsec-Modi und ECN

Tunnel-Modus (Tunnel Mode)

• Gesamtes IP-Paket wird gekapselt
• ECN-Regeln aus Abschnitt 9.1 gelten
• Inneres und äußeres ECN-Feld existieren

Transport-Modus (Transport Mode)

• Kein äußerer IP-Header hinzugefügt
• Nur ein ECN-Feld (im Original-IP-Header)
• Standard-ECN-Verarbeitung, keine speziellen Tunnel-Regeln

9.2.4. Grundlegendes IPsec-ECN-Verhalten

Für IPsec-Tunnel-Modus:

Encapsulation (Tunnel-Eintritt)

• Wende Regeln aus Abschnitt 9.1.2 an
• Berücksichtige SA-ECN-Attribut
• Limited oder Full-Functionality basierend auf SA

Decapsulation (Tunnel-Austritt)

• Wende Regeln aus Abschnitt 9.1.3 an
• Überprüfe SA-ECN-Attribut
• Kombiniere innere und äußere ECN-Felder entsprechend

9.2.5. SA-Parameter für ECN

Jede IPsec-SA SOLLTE enthalten:

• ECN-Tunnel-Attribut: Gibt an, ob Full-Functionality verwendet wird
• Werte:
  • 0: Limited-Functionality (äußeres verwendet Not-ECT)
  • 1: Full-Functionality (äußeres verwendet ECT wenn inneres ECT ist)
  • Nicht vorhanden: Standardwert (Limited-Functionality)

9.2.6. Verhandlung zwischen Tunnel-Endpunkten

Die Verhandlung des ECN-Modus erfolgt während der SA-Einrichtung:

• IKE (Internet Key Exchange) wird verwendet
• Neues SA-Attribut für ECN wird ausgetauscht
• Beide Seiten müssen Full-Functionality unterstützen, damit es verwendet wird

Siehe Abschnitt 9.2.1 für Details der Verhandlung.

9.2.7. ESP und ECN

Encapsulating Security Payload (ESP):

• Verschlüsselt Payload, aber nicht äußeren IP-Header
• ECN-Feld im äußeren Header ist sichtbar und änderbar
• Inneres ECN-Feld ist geschützt (innerhalb verschlüsselten Payloads)

Implikationen:

• Router im Tunnel können äußeres ECN sehen und CE setzen
• Inneres ECN bleibt authentisch (kann nicht ohne Erkennung geändert werden)
• Decapsulation kombiniert beide korrekt

9.2.8. AH und ECN

Authentication Header (AH):

• Authentifiziert Teile des IP-Headers
• ECN-Feld ist veränderlich (nicht authentifiziert)
• AH erlaubt explizit Änderungen an ECN

Begründung:

• ECN muss von Zwischenroutern geändert werden können
• AH schließt ECN von Authentifizierung aus
• Dies ist beabsichtigtes Verhalten

9.2.9. Kompatibilität mit älteren IPsec-Implementierungen

Ältere Implementierungen ohne ECN-Unterstützung:

• Verwenden Limited-Functionality (standardmäßig)
• Setzen äußeres auf Not-ECT
• Funktionieren korrekt, nutzen nur ECN nicht im Tunnel

Neue Implementierungen mit ECN:

• SOLLTEN Full-Functionality verhandeln können
• MÜSSEN mit Limited-Functionality kompatibel sein
• SOLLTEN sich korrekt verhalten, wenn andere Seite ECN nicht unterstützt

9.2.10. IPsec und ECN-Nonce

Wenn ECN-Nonce verwendet wird (siehe Abschnitt 11.2):

• Inneres Paket verwendet ECT(0)/ECT(1) nach Nonce-Wahl
• Äußeres Paket KANN ECT(0) oder ECT(1) verwenden
• Äußeres muss nicht innere Nonce-Auswahl widerspiegeln

9.2.11. Empfehlungen für IPsec-Implementierungen

IPsec-Implementierungen, die ECN-Tunnel unterstützen, SOLLTEN:

1. Full-Functionality implementieren
2. ECN-SA-Attribut während IKE verhandeln
3. Korrekte Encap/Decap-Logik implementieren
4. Mit Limited-Functionality fallback kompatibel sein
5. Dokumentieren Sie ECN-Konfigurationsoptionen