2.5. Version Numbers and Forward Compatibility (Versionsnummern und Vorwärtskompatibilität)

2.5. Version Numbers and Forward Compatibility (Versionsnummern und Vorwärtskompatibilität)

Dieses Dokument beschreibt IKE 2.0 (Major 2, Minor 0) und ersetzt [IKEV2]. Implementierungen können 1.0 und 2.0 oder später weitere Versionen unterstützen.

Die Major-Version steigt nur, wenn Formate oder Pflichtverhalten so stark ändern, dass alte Knoten mit neuen nicht interagieren könnten, selbst wenn unbekannte Felder ignoriert werden. Die Minor-Version kennzeichnet neue Fähigkeiten: Knoten mit kleinerer Minor MÜSSEN sie ignorieren; größere Minor können sie informativ nutzen (z. B. neuer Notify-Typ).

Bei höherer Major im empfangenen Paket MUSS es verworfen werden; es SOLL ein unauthentifiziertes INVALID_MAJOR_VERSION mit der höchsten unterstützten Version gesendet werden. Unterstützte Majors n und m schließen alle dazwischen ein. Bei unterstützter Major MUSS mit dieser Major geantwortet werden. Ein Flag zeigt höhere Major-Fähigkeit an, um Downgrade-Tricks zu verhindern.

Die Major im IKE-Header ist die der Nachricht, nicht die höchste des Senders. Fehlverhandlung auf n bei gemeinsam höherer Fähigkeit → Verbindung trennen und mit n+1 neu verbinden.

IKEv1 folgt diesen Regeln nicht; Angreifer können v2-Knoten auf v1 zwingen → protokollieren.

RESERVED-Felder MÜSSEN in 2.0 null sein und von 2.0 ignoriert werden [IP]. Unbekannte Payload-Typen MÜSSEN übersprungen und ignoriert werden.

Das „critical“-Bit: bei unbekanntem Typ und critical MUSS die Nachricht abgelehnt und UNSUPPORTED_CRITICAL_PAYLOAD in der Antwort stehen (1 Oktett Typ in Daten). Ohne critical unbekannter Typ → Payload ignorieren. Antwort-Payloads ohne critical. Bekannter Typ, unbekannter Inhalt → critical ignorieren.

Neue Payload-Typen können eingestreut sein; Reihenfolge aus Abschnitt 1 und 2 SOLLTEN eingehalten werden, andere Reihenfolge DARF nicht als ungültig abgelehnt werden.