IKEv2 - Versionsgeschichte

Thomas.will: Der Seiteninhalt wurde durch einen anderen Text ersetzt: „IKEv2 Prinzip IKEv2 ausführlich“

2022-12-06T12:15:07Z

Der Seiteninhalt wurde durch einen anderen Text ersetzt: „*IKEv2 Prinzip *IKEv2 ausführlich“

Thomas.will: /* IKEv2 Verbindungsaufbau */

2022-09-26T05:55:23Z

IKEv2 Verbindungsaufbau

Thomas.will: /* IKEv2 Verbindungsaufbau */

2022-09-26T05:43:35Z

IKEv2 Verbindungsaufbau

Linkai.zhang: /* Nachrichten-ID (4 Oktette, Ganzzahl ohne Vorzeichen) */

2022-09-09T09:44:07Z

Nachrichten-ID (4 Oktette, Ganzzahl ohne Vorzeichen)

Linkai.zhang: /* Austauschtyp (1 Oktett) */

2022-09-09T09:39:40Z

Austauschtyp (1 Oktett)

Linkai.zhang: /* SPI des Responders (8 Oktette) */

2022-09-09T09:29:01Z

SPI des Responders (8 Oktette)

Linkai.zhang: /* SPI des Responders (8 Oktette) */

2022-09-09T09:26:55Z

SPI des Responders (8 Oktette)

Linkai.zhang: /* SPI des Initiators (8 Oktette) */

2022-09-09T09:18:42Z

SPI des Initiators (8 Oktette)

Thomas.will: /* Flags (1 Oktett) */

2022-09-03T08:27:24Z

Flags (1 Oktett)

Thomas.will: /* Austauschtyp (1 Oktett) */

2022-09-02T14:50:59Z

Austauschtyp (1 Oktett)

← Nächstältere Version		Version vom 6. Dezember 2022, 12:15 Uhr
Zeile 1:		Zeile 1:
−	~~=IKEv2 Header=~~	+	*[[IKEv2 Prinzip]]
−	~~{{#drawio:ikev2-2}}~~	+	*[[IKEv2 ausführlich]]
−	~~=SPI des Initiators (8 Oktette)=~~
−	*~~Ein vom Initiator gewählter Wert~~
−	*Identifiziert eine eindeutige IKE-Sicherheitszuordnung.
−	*Dieser Wert darf NICHT Null sein.
−
−	~~=SPI des Responders (8 Oktette)=~~
−	*Ein vom Responder gewählter Wert
−	*Identifiziert eine eindeutige IKE-Sicherheitszuordnung.
−	*Dieser Wert MUSS Null in der ersten Nachricht eines anfänglichen IKE-Austausch sein.
−
−	~~=Nächste Nutzlast (1 Oktett)=~~
−	*Zeigt die Art der Nutzlast an, die folgt direkt auf die Überschrift.
−	*Das Format und der Wert von jedem Nutzlast sind unten definiert.
−	~~=Hauptversion (4 Bits)=~~
−	*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
−	~~=Nebenversion (4 Bits)=~~
−	*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.
−	~~=Austauschtyp (1 Oktett)=~~
−	*Zeigt den Typ des Austauschs an, der genutzt wird.
−	*Dies schränkt die Nutzlasten ein, die in jeder Nachricht in einer gesendet werden können.
−	*Die Werte in der folgenden Tabelle sind von RFC 4306.
−	*Andere Werte könnten seitdem hinzugefügt worden sein.
−	*Leser sollten sich auf [~~IKEV2IANA] beziehen, um die neuesten Informationen über diese Werte zu erhalten.~~
−	*Austauschtypwert
−	**IKE_SA_INIT 34
−	**IKE_AUTH 35
−	**CREATE_CHILD_SA 36
−	**INFORMATION 37
−
−	~~=Flags (1 Oktett)=~~
−	*Zeigt bestimmte Optionen an, die für eingestellt sind Nachricht.
−	*Das Vorhandensein von Optionen wird durch das entsprechende Bit angezeigt
−	~~im Flags-Feld gesetzt. Die Bits sind wie folgt:~~
−	~~+-+-+-+-+-+-+-+-+~~
−	~~\|X\|X\|R\|V\|I\|X\|X\|X\|~~
−	~~+-+-+-+-+-+-+-+-+~~
−
−	*In der folgenden Beschreibung bedeutet ein Bit, das "gesetzt" ist, dass sein Wert "1" ist, während "gelöscht" bedeutet, dass sein Wert "0" ist.
−	*'X'-Bits MÜSSEN gelöscht werden beim Senden und MÜSSEN beim Empfang ignoriert werden.
−
−	* R (Antwort) – Dieses Bit zeigt an, dass diese Nachricht a ist
−	~~Antwort auf eine Nachricht mit derselben Nachrichten-ID. Dieses bisschen~~
−	~~MUSS in allen Anforderungsnachrichten gelöscht und MUSS in allen gesetzt werden~~
−	~~Antworten. Ein IKE-Endpunkt DARF KEINE Antwort auf a generieren~~
−	~~Nachricht, die als Antwort markiert ist (mit einer Ausnahme;~~
−	~~siehe Abschnitt 2.21.2).~~
−
−	* V (Version) – Dieses Bit zeigt an, dass der Sender ist
−	~~in der Lage, eine höhere Hauptversionsnummer der zu sprechen~~
−	~~Protokoll als das in der Hauptversionsnummer angegebene~~
−	~~aufstellen. Implementierungen von~~ IKEv2 ~~MÜSSEN dieses Bit löschen, wenn~~
−	~~Senden und MUSS es in eingehenden Nachrichten ignorieren.~~
−
−	* I (Initiator) - Dieses Bit MUSS in Nachrichten gesetzt werden, die von gesendet werden
−	~~ursprünglicher Initiator der IKE SA und MUSS eingeräumt werden~~
−	~~Nachrichten, die vom ursprünglichen Responder gesendet wurden. Es wird von der verwendet~~
−	~~Empfänger, um festzustellen, welche acht Oktetts der SPI waren~~
−	~~vom Empfänger generiert. Dieses Bit ändert sich, um widerzuspiegeln, wer~~
−	~~hat die letzte Schlüsselerneuerung der IKE SA initiiert.~~
−
−
−
−	~~=Nachrichten-ID (4 Oktette, Ganzzahl ohne Vorzeichen)=~~
−	*Verwendete Nachrichtenkennung um die erneute Übertragung verlorener Pakete und den Abgleich von Anforderungen zu steuern und Antworten.
−	*Es ist wesentlich für die Sicherheit des Protokolls, weil es verwendet wird, um Nachrichtenwiedergabeangriffe zu verhindern.
−
−	~~=Länge (4 Oktette, Ganzzahl ohne Vorzeichen)=~~
−	*Länge der gesamten Nachricht (Header + Payloads) in Oktetts.
−
−	~~=IKEv2 Verbindungsaufbau=~~
−	==Prinzip==
−	~~{{#drawio:ikev2--prinzip}}~~
−	~~==Austausch==~~
−	~~{{#drawio:ikev2-1}}~~
−
−	~~=IKEv2 verfügt im Prinzip nur über zwei anfängliche Verhandlungsphasen=~~
−	*~~IKE_SA_INIT-Exchange~~
−	*IKE_AUTH-Exchange
−	~~=IKE_SA_INIT-Exchange=~~
−	*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~~
−
−	~~=IKE_AUTH-Exchange=~~
−	*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.
−	~~;Spätere IKEv2-Austausche~~
−	~~=REATE_CHILD_SA Exchange=~~
−	*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~~
−
−	~~=Informationsaustausch=~~
−	*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.
−
−
−
−	~~=Links=~~
−	*https://www.heise.de/hintergrund/Einfacher-VPN-Tunnelbau-dank-IKEv2-270056.html
−	*https://www.cisco.com/c/de_de/support/docs/security-vpn/ipsec-negotiation-ike-protocols/115936-understanding-ikev2-packet-exch-debug.html

@@ Zeile 77: / Zeile 77: @@
 =IKEv2 Verbindungsaufbau=
 {{#drawio:ikev2-1}}
 =IKEv2 verfügt im Prinzip nur über zwei anfängliche Verhandlungsphasen=

@@ Zeile 78: / Zeile 78: @@
 =IKEv2 Verbindungsaufbau=
 {{#drawio:ikev2-1}}
 =IKEv2 verfügt im Prinzip nur über zwei anfängliche Verhandlungsphasen=
 *IKE_SA_INIT-Exchange

@@ Zeile 71: / Zeile 71: @@
 =Nachrichten-ID (4 Oktette, Ganzzahl ohne Vorzeichen)=
 *Verwendete Nachrichtenkennung um die erneute Übertragung verlorener Pakete und den Abgleich von Anforderungen zu steuern und Antworten.
-*Es ist wesentlich für die Sicherheit des Protokoll weil es verwendet wird, um Nachrichtenwiedergabeangriffe zu verhindern.
+*Es ist wesentlich für die Sicherheit des Protokolls, weil es verwendet wird, um Nachrichtenwiedergabeangriffe zu verhindern.
 =Länge (4 Oktette, Ganzzahl ohne Vorzeichen)=

@@ Zeile 25: / Zeile 25: @@
 *Sie MÜSSEN die Nebenversion ignorieren Versionsnummer der empfangenen Nachrichten.
 =Austauschtyp (1 Oktett)=
-*Zeigt den Typ des Austauschs an der genutzt wird.
+*Zeigt den Typ des Austauschs an, der genutzt wird.
-*Dies schränkt die Nutzlasten ein, die in jeder Nachricht in einer gesendet werden
+*Dies schränkt die Nutzlasten ein, die in jeder Nachricht in einer gesendet werden können.
-*Die Werte in der folgenden Tabelle sind nur aktuell als des Veröffentlichungsdatums von RFC 4306.
+*Die Werte in der folgenden Tabelle sind von RFC 4306.
-*Andere Werte können gewesen sein seitdem hinzugefügt oder werden nach der Veröffentlichung dieser hinzugefügt dokumentieren.
+*Andere Werte könnten seitdem hinzugefügt worden sein.
-*Leser sollten sich auf [IKEV2IANA] beziehen, um die neuesten Informationen zu erhalten Werte.
+*Leser sollten sich auf [IKEV2IANA] beziehen, um die neuesten Informationen über diese Werte zu erhalten.
 *Austauschtypwert
 **IKE_SA_INIT 34
@@ Zeile 35: / Zeile 35: @@
 **CREATE_CHILD_SA 36
 **INFORMATION 37
 =Flags (1 Oktett)=
 *Zeigt bestimmte Optionen an, die für eingestellt sind Nachricht.

@@ Zeile 9: / Zeile 9: @@
 *Ein vom Responder gewählter Wert
 *Identifiziert eine eindeutige IKE-Sicherheitszuordnung.
-*Dieser Wert MUSS Null in der ersten Nachricht eines anfänglichen IKE-Austausch seins.
+*Dieser Wert MUSS Null in der ersten Nachricht eines anfänglichen IKE-Austausch sein.
 =Nächste Nutzlast (1 Oktett)=

@@ Zeile 3: / Zeile 3: @@
 =SPI des Initiators (8 Oktette)=
 *Ein vom Initiator gewählter Wert
-*Identifizier5 eine eindeutige IKE-Sicherheitszuordnung.
+*Identifiziert eine eindeutige IKE-Sicherheitszuordnung.
 *Dieser Wert darf NICHT Null sein.
 =SPI des Responders (8 Oktette)=
 *Ein vom Responder gewählter Wert

@@ Zeile 41: / Zeile 41: @@
          +-+-+-+-+-+-+-+-+
-   In der folgenden Beschreibung bedeutet ein Bit, das "gesetzt" ist, dass sein Wert "1" ist,
+*In der folgenden Beschreibung bedeutet ein Bit, das "gesetzt" ist, dass sein Wert "1" ist, während "gelöscht" bedeutet, dass sein Wert "0" ist.
-   während "gelöscht" bedeutet, dass sein Wert "0" ist. 'X'-Bits MÜSSEN gelöscht werden
+*'X'-Bits MÜSSEN gelöscht werden beim Senden und MÜSSEN beim Empfang ignoriert werden.
        * R (Antwort) – Dieses Bit zeigt an, dass diese Nachricht a ist
@@ Zeile 67: / Zeile 66: @@
-   o Nachrichten-ID (4 Oktette, Ganzzahl ohne Vorzeichen) – Verwendete Nachrichtenkennung
+=Länge (4 Oktette, Ganzzahl ohne Vorzeichen)=
-      um die erneute Übertragung verlorener Pakete und den Abgleich von Anforderungen zu steuern
+*Länge der gesamten Nachricht (Header + Payloads) in Oktetts.
 =IKEv2 Verbindungsaufbau=

@@ Zeile 33: / Zeile 33: @@
 **CREATE_CHILD_SA 36
 **INFORMATION 37
+=Flags (1 Oktett)=
-   o Flags (1 Oktett) – Zeigt bestimmte Optionen an, die für eingestellt sind
+*Zeigt bestimmte Optionen an, die für eingestellt sind Nachricht.
-      Botschaft. Das Vorhandensein von Optionen wird durch das entsprechende Bit angezeigt
+*Das Vorhandensein von Optionen wird durch das entsprechende Bit angezeigt
-      im Flags-Feld gesetzt. Die Bits sind wie folgt:
+im Flags-Feld gesetzt. Die Bits sind wie folgt:
          +-+-+-+-+-+-+-+-+
          |X|X|R|V|I|X|X|X|
@@ Zeile 67: / Zeile 66: @@

IKEv2 - Versionsgeschichte

Thomas.will: Der Seiteninhalt wurde durch einen anderen Text ersetzt: „*IKEv2 Prinzip *IKEv2 ausführlich“

Thomas.will: /* IKEv2 Verbindungsaufbau */

Thomas.will: /* IKEv2 Verbindungsaufbau */

Linkai.zhang: /* Nachrichten-ID (4 Oktette, Ganzzahl ohne Vorzeichen) */

Linkai.zhang: /* Austauschtyp (1 Oktett) */

Linkai.zhang: /* SPI des Responders (8 Oktette) */

Linkai.zhang: /* SPI des Responders (8 Oktette) */

Linkai.zhang: /* SPI des Initiators (8 Oktette) */

Thomas.will: /* Flags (1 Oktett) */

Thomas.will: /* Austauschtyp (1 Oktett) */

Thomas.will: Der Seiteninhalt wurde durch einen anderen Text ersetzt: „IKEv2 Prinzip IKEv2 ausführlich“