1.7. Wesentliche Unterschiede zwischen RFC 4306 und diesem Dokument

Dieses Dokument enthält Klarstellungen und Erweiterungen zu IKEv2 [IKEV2]. Viele der Klarstellungen basieren auf [Clarif]. Die in jenem Dokument aufgeführten Änderungen wurden in der IPsec Working Group diskutiert und, nach deren Auflösung, auf der IPsec-Mailingliste. Jenes Dokument enthält detaillierte Erklärungen von Bereichen, die in IKEv2 unanwendbar waren, und ist daher für Implementierer von IKEv2 nützlich.

Das in diesem Dokument beschriebene Protokoll behält dieselbe Hauptversionsnummer (2) und Nebenversionsnummer (0) bei, die in RFC

4306 verwendet wurde. Das heißt, die Versionsnummer ist gegenüber

RFC 4306 nicht geändert. Die kleine Anzahl hier aufgeführter technischer Änderungen wird voraussichtlich keine Auswirkungen auf RFC-4306-Implementierungen haben, die zum Zeitpunkt der Veröffentlichung dieses Dokuments bereits eingesetzt waren.

Dieses Dokument macht die Abbildungen und Referenzen etwas konsistenter als sie in [IKEV2] waren.

IKEv2-Entwickler haben festgestellt, dass die SHOULD-Ebene-Anforderungen in RFC 4306 oft unklar sind, da sie nicht sagen, wann es in Ordnung ist, die Anforderungen nicht zu befolgen. Sie haben auch festgestellt, dass es MUST-Ebene-Anforderungen gibt, die nicht mit Interoperabilität zusammenhängen. Dieses Dokument enthält mehr Erklärung zu einigen dieser Anforderungen. Alle nicht großgeschriebenen Verwendungen der Wörter SHOULD und MUST bedeuten nun ihren normalen englischen Sinn, nicht den Interoperabilitätssinn von [MUSTSHOULD].

IKEv2- (und IKEv1-)Entwickler haben festgestellt, dass es in den Tabellen der Codes in Abschnitt 3.10.1 in RFC 4306 viel Material gibt. Dies führt dazu, dass Implementierer nicht alle benötigten Informationen im Hauptteil des Dokuments haben. Viel des Materials aus jenen Tabellen wurde in die zugehörigen Teile des Hauptteils des Dokuments verschoben.

Dieses Dokument entfernt die Diskussion über das Verschachteln von AH und ESP. Dies war ein Fehler in RFC 4306, verursacht durch die Verzögerung zwischen dem Abschluss von RFC 4306 und RFC 4301. Im Wesentlichen basiert IKEv2 auf RFC 4301, das keine „SA-Bündel" enthält, die Teil von RFC 2401 waren. Während ein einzelnes Paket die IPsec-Verarbeitung mehrmals durchlaufen kann, verwendet jeder dieser Durchgänge eine separate SA, und die Durchgänge werden durch die Weiterleitungstabellen koordiniert. In IKEv2 muss jede dieser SAs mit einem separaten CREATE_CHILD_SA-Austausch erstellt werden.

Dieses Dokument entfernt die Diskussion über das INTERNAL_ADDRESS_EXPIRY-Konfigurationsattribut, da seine Implementierung sehr problematisch war. Implementierungen, die konform zu diesem Dokument sind, MÜSSEN Vorschläge ignorieren, die das Konfigurationsattribut Typ 5 haben, den alten Wert für INTERNAL_ADDRESS_EXPIRY. Dieses Dokument entfernte ebenfalls INTERNAL_IP6_NBNS als Konfigurationsattribut.

Dieses Dokument entfernt die Möglichkeit, Nachrichten abzulehnen, in denen die Payloads nicht in der „richtigen" Reihenfolge waren; nun DÜRFEN Implementierungen sie nicht mehr ablehnen. Dies liegt an mangelnder Klarheit, wo die Reihenfolgen für die Payloads beschrieben werden.

Die Listen von Einträgen aus RFC 4306, die im IANA-Register landeten, wurden gekürzt, um nur Einträge einzuschließen, die tatsächlich in RFC

4306 definiert waren. Zudem werden viele dieser Listen nun mit der

sehr wichtigen Anweisung an Entwickler versehen, dass sie das IANA- Register zum Zeitpunkt der Entwicklung wirklich einsehen sollten, da seit RFC 4306 neue Einträge hinzugefügt wurden.

Dieses Dokument fügt Klarstellung hinzu, wann Benachrichtigungen verschlüsselt gesendet werden und wann nicht, abhängig vom Zustand der Aushandlung zum Zeitpunkt.

Dieses Dokument erörtert mehr darüber, wie kombinierte Modus-Chiffren ausgehandelt werden.

In Abschnitt 1.3.2 wurde "The KEi payload SHOULD be included" zu "The KEi payload MUST be included" geändert. Dies führte auch zu Änderungen in Abschnitt 2.18.

In Abschnitt 2.1 gibt es neues Material, das abdeckt, wie der SPI und/oder die IP des Initiators verwendet wird, um zu unterscheiden, ob dies eine „halboffene" IKE SA oder eine neue Anfrage ist.

Dieses Dokument klärt die Verwendung des kritischen Flags in Abschnitt 2.5.

In Abschnitt 2.8 wurde "Note that, when rekeying, the new Child SA MAY have different Traffic Selectors and algorithms than the old one" zu "Note that, when rekeying, the new Child SA SHOULD NOT have different Traffic Selectors and algorithms than the old one" geändert.

Der neue Abschnitt 2.8.2 deckt gleichzeitiges Neu-Schlüsseln der IKE SA ab.

Der neue Abschnitt 2.9.2 deckt Traffic Selectors beim Neu-Schlüsseln ab.

Dieses Dokument fügt die Einschränkung in Abschnitt 2.13 hinzu, dass alle mit IKEv2 verwendeten Pseudozufallsfunktionen (PRFs) variabel große Schlüssel annehmen MÜSSEN. Dies sollte keine Implementierungen beeinflussen, da es keine standardisierten PRFs mit festen Schlüsselgrößen gab.

Abschnitt 2.18 erfordert das Durchführen eines Diffie-Hellman- Austauschs beim Neu-Schlüsseln der IKE_SA. Theoretisch erlaubte RFC 4306 eine Richtlinie, bei der der Diffie-Hellman-Austausch optional war, aber dies war beim Neu-Schlüsseln der IKE_SA nicht nützlich (oder angemessen).

Abschnitt 2.21 wurde stark erweitert, um die verschiedenen Fälle abzudecken, in denen Fehlerantworten benötigt werden und die entsprechenden Antworten darauf.

Abschnitt 2.23 klärte, dass beim NAT-Traversal nun sowohl UDP- encapsulated IPsec-Pakete als auch nicht-UDP-encapsulated IPsec-Pakete beim Empfang verstanden werden müssen.

Abschnitt 2.23.1 hinzugefügt, um NAT-Traversal zu beschreiben, wenn Transportmodus angefordert wird.

Abschnitt 2.25 hinzugefügt, um zu erklären, wie zu handeln ist, wenn es Zeitkollisionen beim Löschen und/oder Neu-Schlüsseln von SAs gibt, und zwei neue Fehlerbenachrichtigungen (TEMPORARY_FAILURE und CHILD_SA_NOT_FOUND) wurden definiert.

In Abschnitt 3.6 wurde hinzugefügt: "Implementations MUST support the HTTP method for hash-and-URL lookup. The behavior of other URL methods is not currently specified, and such methods SHOULD NOT be used in the absence of a document specifying them".

In Abschnitt 3.15.3 wurde ein Verweis auf ein neues Dokument hinzugefügt, das sich auf die Konfiguration von IPv6-Adressen bezieht.

Anhang C wurde erweitert und geklärt.