IKEv2: Unterschied zwischen den Versionen

@@ 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 sein Null in der ersten Nachricht eines anfänglichen IKE-Austauschs.
-=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
-*Die Werte in der folgenden Tabelle sind nur aktuell als des Veröffentlichungsdatums von RFC 4306.
-*Andere Werte können gewesen sein seitdem hinzugefügt oder werden nach der Veröffentlichung dieser hinzugefügt dokumentieren.
-*Leser sollten sich auf [IKEV2IANA] beziehen, um die neuesten Informationen zu erhalten Werte.
-*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 Protokoll 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=
-{{#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

IKEv2: Unterschied zwischen den Versionen

Aktuelle Version vom 6. Dezember 2022, 12:15 Uhr

Navigationsmenü

Suche