Zum Hauptinhalt springen

2.5. Versionsnummern und Rückwärtskompatibilität

2.5. Versionsnummern und Rückwärtskompatibilität​

Dieses Dokument beschreibt Version 2.0 von IKE, was bedeutet, dass die Hauptversionsnummer 2 ist und die Nebenversionsnummer 0. Dieses Dokument ersetzt [IKEV2]. Es ist wahrscheinlich, dass einige Implementierungen sowohl Version 1.0 als auch Version 2.0 sowie in Zukunft andere Versionen unterstützen wollen.

Die Hauptversionsnummer sollte nur inkrementiert werden, wenn sich die Paketformate oder erforderlichen Aktionen so dramatisch geändert haben, dass ein Knoten mit älterer Version nicht in der Lage wäre, mit einem Knoten mit neuerer Version zu interoperieren, wenn er einfach die Felder, die er nicht versteht, ignorieren und die in der älteren Spezifikation angegebenen Aktionen ausführen würde. Die Nebenversionsnummer zeigt neue Fähigkeiten an und MUSS von einem Knoten mit kleinerer Nebenversionsnummer ignoriert werden, aber zu Informationszwecken von einem Knoten mit größerer Nebenversionsnummer verwendet werden. Zum Beispiel könnte sie die Fähigkeit anzeigen, einen neu definierten Notify-Nachrichtentyp zu verarbeiten. Der Knoten mit der größeren Nebenversionsnummer würde einfach zur Kenntnis nehmen, dass sein Korrespondent nicht in der Lage wäre, diese Nachricht zu verstehen, und sie daher nicht senden.

Wenn ein Endpunkt eine Nachricht mit einer höheren Hauptversionsnummer empfängt, MUSS er die Nachricht verwerfen und SOLLTE eine nicht authentifizierte Notify-Nachricht vom Typ INVALID_MAJOR_VERSION senden, die die höchste (nächste) Version enthält, die er unterstützt. Wenn ein Endpunkt die Hauptversion n und die Hauptversion m unterstützt, MUSS er alle Versionen zwischen n und m unterstützen. Wenn er eine Nachricht mit einer Hauptversion empfängt, die er unterstützt, MUSS er mit dieser Versionsnummer antworten. Um zu verhindern, dass zwei Knoten dazu verleitet werden, mit einer niedrigeren Hauptversionsnummer als dem Maximum, das beide unterstützen, zu koppeln, hat IKE ein Flag, das angibt, dass der Knoten in der Lage ist, eine höhere Hauptversionsnummer zu sprechen.

So zeigt die Hauptversionsnummer im IKE-Header die Versionsnummer der Nachricht an, nicht die höchste Versionsnummer, die der Sender unterstützt. Wenn der Initiator in der Lage ist, die Versionen n, n+1 und n+2 zu sprechen, und der Responder die Versionen n und n+1 sprechen kann, dann werden sie aushandeln, n+1 zu sprechen, wobei der Initiator ein Flag setzt, das seine Fähigkeit angibt, eine höhere Version zu sprechen. Wenn sie fälschlicherweise (vielleicht durch einen aktiven Angreifer, der Fehlernachrichten sendet) auf Version n aushandeln, dann werden beide bemerken, dass die andere Seite eine höhere Versionsnummer unterstützen kann, und sie MÜSSEN die Verbindung abbrechen und sich erneut mit Version n+1 verbinden.

Beachten Sie, dass IKEv1 diese Regeln nicht befolgt, da es in v1 keine Möglichkeit gibt, zu vermerken, dass Sie in der Lage sind, eine höhere Version zu sprechen. So kann ein aktiver Angreifer zwei Knoten, die v2 sprechen können, dazu verleiten, v1 zu sprechen. Wenn ein Knoten, der v2 sprechen kann, auf v1 aushandelt, sollte er dies in seinen Protokollen vermerken.

Ebenso sollten für Rückwärtskompatibilität alle als RESERVED markierten Felder von einer Implementierung, die Version 2.0 ausführt, auf null gesetzt werden, und ihr Inhalt MUSS von einer Implementierung, die Version 2.0 ausführt, ignoriert werden („Sei konservativ in dem, was du sendest, und liberal in dem, was du empfängst" [IP]). Auf diese Weise können zukünftige Versionen des Protokolls diese Felder auf eine Weise verwenden, die garantiert von Implementierungen ignoriert wird, die sie nicht verstehen. Ebenso sind nicht definierte Payload-Typen für zukünftige Verwendung reserviert; Implementierungen einer Version, in der sie undefiniert sind, MÜSSEN diese Payloads überspringen und ihren Inhalt ignorieren.

IKEv2 fügt jedem Payload-Header ein „kritisches" Flag für mehr Rückwärtskompatibilitätsflexibilität hinzu. Wenn das kritische Flag gesetzt ist und der Payload-Typ nicht erkannt wird, MUSS die Nachricht abgelehnt werden und die Antwort auf die IKE-Anfrage, die diesen Payload enthält, MUSS einen UNSUPPORTED_CRITICAL_PAYLOAD-Notify-Payload einschließen, der angibt, dass ein nicht unterstützter kritischer Payload enthalten war. In diesem Notify-Payload enthalten die Benachrichtigungsdaten den ein Oktett großen Payload-Typ. Wenn das kritische Flag nicht gesetzt ist und der Payload-Typ nicht unterstützt wird, MUSS dieser Payload ignoriert werden. Payloads, die in IKE-Antwortnachrichten gesendet werden, DÜRFEN nicht das kritische Flag gesetzt haben. Beachten Sie, dass das kritische Flag nur für den Payload-Typ gilt, nicht für den Inhalt. Wenn der Payload-Typ erkannt wird, aber der Payload etwas enthält, das nicht erkannt wird (wie eine unbekannte Transform innerhalb eines SA-Payloads oder ein unbekannter Notify-Nachrichtentyp innerhalb eines Notify-Payloads), wird das kritische Flag ignoriert.

Obwohl neue Payload-Typen in Zukunft hinzugefügt werden und zwischen den in dieser Spezifikation definierten Feldern erscheinen können, SOLLTEN Implementierungen die in dieser Spezifikation definierten Payloads in der in den Abbildungen der Abschnitte 1 und 2 gezeigten Reihenfolge senden; Implementierungen DÜRFEN eine Nachricht mit diesen Payloads in anderer Reihenfolge nicht als ungültig ablehnen.