12. Summary of changes required in IP and TCP (Zusammenfassung der erforderlichen Änderungen in IP und TCP)

12. Summary of changes required in IP and TCP (Zusammenfassung der erforderlichen Änderungen in IP und TCP)

Dieses Dokument legt die Verwendung von zwei Bits im IP-Header für ECN (Explicit Congestion Notification) fest. Der Not-ECT-Codepunkt zeigt an, dass das Transportprotokoll den CE-Codepunkt (Congestion Experienced) ignorieren wird. Dies ist der Standardwert für den ECN-Codepunkt. Der ECT-Codepunkt (ECN-Capable Transport) zeigt an, dass das Transportprotokoll bereit und in der Lage ist, an ECN teilzunehmen.

Ein Router setzt den CE-Codepunkt, um den Endknoten Überlastung anzuzeigen. Der CE-Codepunkt in einem Paketheader DARF NICHT von einem Router zurückgesetzt werden.

TCP erfordert drei Änderungen für ECN: eine Einrichtungsphase und zwei neue Flags im TCP-Header. Das ECN-Echo-Flag wird vom Datenempfänger verwendet, um den Datensender über den Empfang eines CE-Pakets zu informieren. Das CWR-Flag (Congestion Window Reduced, Überlastungsfenster reduziert) wird vom Datensender verwendet, um den Datenempfänger darüber zu informieren, dass das Überlastungsfenster reduziert wurde.

Bei der Verwendung von ECN ist es erforderlich, dass Überlastungsanzeigen, die innerhalb eines IP-Tunnels entstehen, am Tunnelausgang nicht verloren gehen. Wir legen geringfügige Änderungen an der Verarbeitung des ECN-Felds durch das IP-Protokoll während der Kapselung und Entkapselung fest, um Flows, die einen IP-Tunnel durchqueren, die Verwendung von ECN zu ermöglichen.

Für ECN in Tunneln werden zwei Optionen festgelegt:

1. Die Eingeschränkte-Funktionalität-Option (Limited-Functionality Option), die ECN innerhalb des IP-Tunnels nicht verwendet, indem das ECN-Feld im äußeren Header auf Not-ECT gesetzt wird und der innere Header bei der Entkapselung nicht geändert wird.

2. Die Volle-Funktionalität-Option (Full-Functionality Option), die das ECN-Feld im äußeren Header auf Not-ECT oder einen der ECT-Codepunkte setzt, abhängig vom ECN-Feld im inneren Header. Bei der Entkapselung wird der CE-Codepunkt in den inneren Header kopiert, wenn der CE-Codepunkt im äußeren Header gesetzt ist und der innere Header auf einen der ECT-Codepunkte gesetzt ist.

Für IPsec-Tunnel definiert dieses Dokument außerdem ein optionales IPsec-Sicherheitsassoziations-Attribut (Security Association, SA), das die Aushandlung der ECN-Nutzung innerhalb von IPsec-Tunneln ermöglicht, sowie ein optionales Feld in der Sicherheitsassoziationsdatenbank (Security Association Database), um anzugeben, ob ECN im Tunnelmodus auf einer SA erlaubt ist. Die für IPsec-Tunnel mit ECN erforderlichen Änderungen modifizieren RFC 2401 [RFC2401], das die IPsec-Architektur definiert und bestimmte Aspekte ihrer Implementierung festlegt. Das neue IPsec-SA-Attribut ist eine Ergänzung zu den bereits in Abschnitt 4.5 von [RFC2407] definierten Attributen.

Dieses Dokument ersetzt RFC 2481 „A Proposal to add Explicit Congestion Notification (ECN) to IP", das ECN als experimentelles Protokoll für die Internetgemeinschaft definierte. Der Rest dieses Abschnitts beschreibt die Beziehung zwischen diesem Dokument und seinem Vorgänger.

RFC 2481 enthielt eine kurze Diskussion der Verwendung von ECN mit gekapselten Paketen und stellte fest, dass Flows mit den damaligen IPsec-Spezifikationen (Januar 1999) ECN nicht sicher verwenden konnten, wenn sie einen IPsec-Tunnel durchqueren würden. RFC 2481 beschrieb auch die Änderungen, die an den IPsec-Tunnelspezifikationen vorgenommen werden könnten, um sie mit ECN kompatibel zu machen.

Dieses Dokument enthält auch nach RFC 2481 abgeschlossene Arbeiten. Erstens die detaillierte Beschreibung der Änderungen an IPsec-Tunneln und eine ausführliche Diskussion der Sicherheitsimplikationen von ECN (jetzt als Abschnitte 18 und 19 dieses Dokuments enthalten). Zweitens die Erweiterung der Diskussion über IPsec-Tunnel auf alle IP-Tunnel. Da ältere IP-Tunnel mit der ECN-Nutzung von Flows inkompatibel sind, wird die Einführung von ECN im Internet einen starken Druck erzeugen, ältere IP-Tunnel auf ECN-kompatible Versionen zu aktualisieren, entweder mit der Eingeschränkten-Funktionalität- oder der Vollen-Funktionalität-Option.

Dieses Dokument behandelt nicht die Fragen der Einbeziehung von ECN in Nicht-IP-Tunnel wie MPLS, GRE, L2TP oder PPTP. Ein frühes vorläufiges Dokument zur Hinzufügung von ECN-Unterstützung zu MPLS wurde nicht weiterverfolgt.

Eine dritte Ergänzung nach RFC 2481 ist die Beschreibung der ECN-Verfahren für neu übertragene Pakete, nämlich dass der ECT-Codepunkt bei neu übertragenen Paketen NICHT gesetzt werden SOLLTE. Die Motivation für diese zusätzliche Spezifikation ist die Beseitigung eines möglichen Angriffsvektors für Denial-of-Service-Angriffe auf bestehende TCP-Verbindungen. Einige zuvor eingesetzte ECN-fähige TCPs entsprechen möglicherweise nicht der (neuen) Anforderung, den ECT-Codepunkt bei neu übertragenen Paketen nicht zu setzen; wir glauben, dass dies in der Praxis keine wesentlichen Probleme verursachen wird.

Dieses Dokument erweitert auch geringfügig die Spezifikation der ECN-Aushandlung unter Verwendung des SYN-Pakets. Obwohl einige zuvor eingesetzte ECN-fähige TCPs möglicherweise nicht den in diesem Dokument festgelegten Anforderungen entsprechen, glauben wir, dass dies keine Leistungs- oder Kompatibilitätsprobleme für TCP-Verbindungen mit TCP-Implementierungskombinationen von Endpunkten verursachen wird.

Dieses Dokument enthält auch die Spezifikation des ECT(1)-Codepunkts, der von TCP als Teil der Implementierung des ECN-Nonce verwendet werden könnte.