8. Backward-Compatibility Considerations (Rückwärtskompatibilitätsüberlegungen)
8. Backward-Compatibility Considerations (Rückwärtskompatibilitätsüberlegungen)
Es gibt keine Versionsnummer in ESP und keinen Mechanismus, der es IPsec-Peers ermöglicht, zu entdecken oder auszuhandeln, welche Version von ESP jeder verwendet oder verwenden sollte. Dieser Abschnitt diskutiert daraus resultierende Rückwärtskompatibilitätsprobleme.
Erstens, wenn keine der in ESP v3 verfügbaren neuen Funktionen verwendet wird, dann ist das Format eines ESP-Pakets in ESP v2 und v3 identisch. Wenn ein kombinierter Modus-Verschlüsselungsalgorithmus verwendet wird, eine Funktion, die nur in ESP v3 unterstützt wird, dann kann das resultierende Paketformat von der ESP v2-Spezifikation abweichen. Ein Peer, der jedoch nur ESP v2 implementiert, würde niemals einen solchen Algorithmus aushandeln, da diese nur für die Verwendung im ESP v3-Kontext definiert sind.
Die Aushandlung erweiterter Sequenznummern (ESN) wird von IKE v2 unterstützt und wurde für IKE v1 durch das ESN-Addendum zur IKE v1 Domain of Interpretation (DOI) behandelt.
Im neuen ESP (v3) treffen wir zwei Vorkehrungen, um die Verkehrsflussvertraulichkeit (TFC) besser zu unterstützen:
- beliebiges Padding nach dem Ende eines IP-Pakets
- eine Verwerfungskonvention unter Verwendung von Next Header = 59
Das erste Feature sollte keine Probleme für einen Empfänger verursachen, da das IP-Gesamtlängenfeld angibt, wo das IP-Paket endet. Daher sollten alle TFC-Padding-Bytes nach dem Ende des Pakets an irgendeinem Punkt während der IP-Paketverarbeitung nach der ESP-Verarbeitung entfernt werden, selbst wenn die IPsec-Software ein solches Padding nicht entfernt. Dies ist somit eine ESP v3-Funktion, die ein Sender unabhängig davon verwenden kann, ob ein Empfänger ESP v2 oder ESP v3 implementiert.
Das zweite Feature ermöglicht es einem Sender, eine Nutzlast zu senden, die eine beliebige Zeichenkette von Bytes ist, die nicht notwendigerweise ein wohlgeformtes IP-Paket darstellen, innerhalb eines Tunnels für TFC-Zwecke. Es ist eine offene Frage, was ein ESP v2-Empfänger tut, wenn das Next Header-Feld in einem ESP-Paket den Wert "59" enthält. Er könnte das Paket verwerfen, wenn er einen fehlerhaften IP-Header findet, und dieses Ereignis protokollieren, aber er sollte sicherlich nicht abstürzen, da ein solches Verhalten eine DoS-Schwachstelle in Bezug auf Verkehr darstellen würde, der von authentifizierten Peers empfangen wird. Daher ist dieses Feature eine Optimierung, die ein ESP v3-Sender unabhängig davon nutzen kann, ob ein Empfänger ESP v2 oder ESP v3 implementiert.