Version vom 2. September 2022, 14:36 Uhr

IKEv2 Header

Ein vom Responder gewählter Wert
Identifiziert eine eindeutige IKE-Sicherheitszuordnung.
Dieser Wert MUSS sein Null in der ersten Nachricht eines anfänglichen IKE-Austauschs.

Zeigt die Hauptversion des IKE an Protokoll im Einsatz.
Implementierungen, die auf dieser Version von IKE basieren MUSS die Hauptversion auf 2 setzen.
Implementierungen basieren auf Frühere Versionen von IKE und ISAKMP MÜSSEN die Hauptversion auf 1 setzen
Implementierungen auf Basis dieser Version von IKE MÜSSEN bzw. ablehnen
Ignoriert Nachrichten mit einer Versionsnummer größer als 2 mit einem INVALID_MAJOR_VERSION-Benachrichtigungsmeldung

Zeigt die Nebenversion des IKE an Protokoll im Einsatz.
Implementierungen, die auf dieser Version von IKE basieren MUSS die Nebenversion auf 0 setzen.
Sie MÜSSEN die Nebenversion ignorieren Versionsnummer der empfangenen Nachrichten.

IKE_SA_INIT ist der erste Austausch, bei dem die Peers einen sicheren Kanal einrichten.
Nach Abschluss des ersten Austauschs werden alle weiteren Austauschvorgänge verschlüsselt.
Der Datenaustausch enthält nur zwei Pakete, da er alle Informationen enthält, die normalerweise in MM1-4 in IKEv1 ausgetauscht werden.
Das Ergebnis ist, dass der Responder das IKE_SA_INIT-Paket rechnerisch verarbeiten muss und das erste Paket verarbeiten kann.
Es lässt das Protokoll einem DOS-Angriff von gefälschten Adressen offen.
Zum Schutz vor solchen Angriffen verfügt IKEv2 über einen optionalen Austausch innerhalb von IKE_SA_INIT, um Spoofing-Angriffe zu verhindern.
Wenn ein bestimmter Grenzwert für unvollständige Sitzungen erreicht wird, verarbeitet der Responder das Paket nicht weiter
Sondern sendet stattdessen eine Antwort mit einem Cookie an den Initiator.
Damit die Sitzung fortgesetzt werden kann, muss der Initiator das IKE_SA_INIT-Paket erneut senden und das von ihm empfangene Cookie einfügen.
Der Initiator sendet das ursprüngliche Paket zusammen mit der Benachrichtigungs-Payload vom Responder erneut, um zu belegen, dass der ursprüngliche Austausch nicht gesaugt wurde.
Im folgenden Diagramm wird der Austausch IKE_SA_INIT mit Cookie-Herausforderung dargestellt:

understanding-ikev2-packet-exch-debug-02.gif

Nach Abschluss des IKE_SA_INIT-Austauschs wird die IKEv2 SA verschlüsselt.
Der Remote-Peer wurde jedoch nicht authentifiziert.
Der IKE_AUTH-Austausch dient zur Authentifizierung des Remote-Peers und zur Erstellung der ersten IPsec-SA.
Der Austausch enthält die ISAKMP-ID (Internet Security Association and Key Management Protocol) sowie eine Authentifizierungs-Payload.
Der Inhalt der Authentifizierungs-Payload hängt von der Authentifizierungsmethode ab
Pre-Shared Key (PSK), RSA-Zertifikate (RSA-SIG), Elliptic Curve Digital Signature Algorithm Certificates (ECDSA-SIG) oder EAP sein kann.
Zusätzlich zu den Authentifizierungs-Payloads enthält der Austausch die SA- und Traffic Selector-Payloads, die die zu erstellende IPsec SA beschreiben.

Wenn zusätzliche untergeordnete SAs erforderlich sind oder wenn die IKE SA oder eine der untergeordneten SAs neu codiert werden muss
- erfüllt sie dieselbe Funktion wie der Quick-Mode-Austausch in IKEv1.
Wie in diesem Diagramm gezeigt, befinden sich in diesem Austausch nur zwei Pakete.
Der Austausch wiederholt sich jedoch für jeden Schlüssel oder jede neue SA:

understanding-ikev2-packet-exch-debug-03.gif

Wie bei allen IKEv2-Austauschen erwartet jede Anforderung des Informationsaustauschs eine Antwort.
Drei Arten von Payloads können in einem INFORMATIONALEN Austausch enthalten sein.
Es können beliebig viele verschiedene Kombinationen von Payloads enthalten werden, wie im folgenden Diagramm gezeigt:

understanding-ikev2-packet-exch-debug-04.gif

Die Notify Payload (N) wurde bereits in Verbindung mit Cookies erkannt.
Es gibt auch mehrere andere Typen. Sie enthalten Fehler- und Statusinformationen wie in IKEv1.
Die Delete Payload (D) informiert den Peer, dass der Absender eine oder mehrere seiner eingehenden SAs gelöscht hat.
Der Responder muss diese SAs löschen und normalerweise die Payloads löschen, die für die SAs in der anderen Richtung in der Antwortnachricht übereinstimmen.
Die Configuration Payload (CP) dient zur Aushandlung von Konfigurationsdaten zwischen den Peers.
Ein wichtiger Zweck des CP besteht darin, eine Adresse in einem Netzwerk anzufordern (anzufordern) und zuzuweisen (zu antworten), das durch ein Sicherheits-Gateway geschützt ist.
In der Regel richtet ein mobiler Host ein Virtual Private Network (VPN) mit einem Sicherheits-Gateway im Heimnetzwerk ein und fordert, dass ihm eine IP-Adresse im Heimnetzwerk zugewiesen wird.

@@ Zeile 19: / Zeile 19: @@
 *Ignoriert Nachrichten mit einer Versionsnummer größer als 2 mit einem INVALID_MAJOR_VERSION-Benachrichtigungsmeldung
 =Nebenversion (4 Bits)=
-*Zeigt die Nebenversion des IKE an
+*Zeigt die Nebenversion des IKE an Protokoll im Einsatz.
-      Protokoll im Einsatz. Implementierungen, die auf dieser Version von IKE basieren
+*Implementierungen, die auf dieser Version von IKE basieren MUSS die Nebenversion auf 0 setzen.
-      MUSS die Nebenversion auf 0 setzen. Sie MÜSSEN die Nebenversion ignorieren
+*Sie MÜSSEN die Nebenversion ignorieren Versionsnummer der empfangenen Nachrichten.
-      Versionsnummer der empfangenen Nachrichten.
 =IKEv2 Verbindungsaufbau=