Grundlegendes zum IPsec IKEv1-Protokoll

Einleitung

In diesem Dokument wird der IKEv1-Protokollprozess (Internet Key Exchange) für einen VPN-Aufbau (Virtual Private Network) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse folgender grundlegender Sicherheitskonzepte verfügen:

• Authentifizierung
• Vertraulichkeit
• Integrität
• IPsec

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Der IKEv1-Protokollprozess (Internet Key Exchange) für eine VPN-Einrichtung (Virtual Private Network) ist wichtig, um den Paketaustausch zu verstehen und so die Fehlerbehebung bei allen IPsec-Problemen mit IKEv1 zu vereinfachen.

IPsec

IPsec ist eine Protokoll-Suite, welche die Sicherheit der Internetkommunikation auf IP-Ebene gewährleistet. Die gängigste aktuelle Verwendung von IPsec ist die Bereitstellung eines Virtual Private Network (VPN) entweder zwischen zwei Standorten (Gateway-zu-Gateway) oder zwischen Remote-BenutzerInnen und einem Unternehmensnetzwerk (Host-zu-Gateway).

IKE-Protokoll

IPsec verwendet das IKE-Protokoll, um sichere Site-to-Site- oder Remote-Access-VPN-Tunnel (Virtual Private Network) auszuhandeln und einzurichten. Das IKE-Protokoll wird (intern bei Cisco) auch als Internet Security Association and Key Management Protocol (ISAKMP) bezeichnet.

Es gibt zwei Versionen von IKE:

• IKEv1: Definiert in RFC 2409, Internet Key Exchange
• IKE Version 2 (IKEv2): definiert in RFC 4306, Internet Key Exchange (IKEv2) Protocol

IKE-Phasen

ISAKMP unterteilt die Aushandlung in zwei Phasen:

• Phase 1: Die beiden ISAKMP-Peers richten einen sicheren und authentifizierten Tunnel ein, der ISAKMP-Aushandlungsnachrichten schützt. Dieser Tunnel wird als ISAKMP-Sicherheitszuordnung bezeichnet. ISAKMP hat zwei Modi: den Main-Modus (MM) und den Aggressive-Modus.
• Phase 2: Es werden Schlüsselmaterialien und Algorithmen für die Verschlüsselung (SAs) der über den IPsec-Tunnel zu übertragenden Daten ausgehandelt. Diese Phase wird als Quick-Modus bezeichnet.

Um alle abstrakten Konzepte zu verwirklichen, ist der Phase-1-Tunnel der Parent-Tunnel und Phase-2 ein Sub-Tunnel. Dieses Bild zeigt die beiden Phasen als Tunnel:

Hinweis: Phase-1-Tunnel (ISAKMP) schützt den VPN-Datenverkehr auf Kontrollebene zwischen den beiden Gateways. Kontrollebenen-Datenverkehr kann Verhandlungspakete, Informationspakete, DPD, Keepalives, rekey usw. sein. Die ISAKMP-Aushandlung verwendet die UDP-Ports 500 und 4500, um einen sicheren Kanal einzurichten.

Hinweis: Der Phase-2-Tunnel (IPsec) schützt den Datenverkehr auf Datenebene, der das VPN zwischen den beiden Gateways passiert. Die zum Schutz der Daten verwendeten Algorithmen werden in Phase 2 konfiguriert und sind unabhängig von den in Phase 1 angegebenen Algorithmen.
Das Protokoll, das zum Kapseln und Verschlüsseln dieser Pakete verwendet wird, ist ESP (Encapsulation Security Payload).

IKE-Modi (Phase 1)

Main-Modus

Eine IKE-Sitzung beginnt, wenn der Initiator ein Angebot an den Responder sendet. Beim ersten Austausch zwischen Knoten wird die grundlegende Sicherheitsrichtlinie festgelegt. Der Initiator schlägt die zu verwendenden Verschlüsselungs- und Authentifizierungsalgorithmen vor. Der Responder wählt den passenden Vorschlag aus (vorausgesetzt, ein Vorschlag wird gewählt) und schickt ihn an den Initiator. Beim nächsten Austausch werden öffentliche Diffie-Hellman-Schlüssel und andere Daten weitergeleitet. Alle weiteren Aushandlungen werden innerhalb der IKE-Sicherheitszuordnung verschlüsselt. Der dritte Austausch authentifiziert die ISAKMP-Sitzung. Sobald die IKE-Sicherheitszuordnung eingerichtet ist, beginnt die IPSec-Aushandlung (Quick-Modus).

Aggressive-Modus

Der Aggressive-Modus zwingt die IKE-Sicherheitszuordnung in drei Pakete, wobei alle für die Sicherheitszuordnung erforderlichen Daten vom Initiator passiert werden. Der Responder sendet das Angebot, das Schlüsselmaterial und die ID und authentifiziert die Sitzung im nächsten Paket. Der Initiator antwortet und authentifiziert die Sitzung. Die Aushandlung ist schneller, und die Initiator- und Responder-ID werden gelöscht.

IPsec-Modus (Phase 2)

Quick-Modus

Die IPSec-(Quick-Modus) ähnelt einer IKE-Aushandlung im Aggressive-Modus, mit der Ausnahme, dass die Aushandlung in einer IKE-Sicherheitszuordnung geschützt werden muss. Der Quick-Modus handelt die Sicherheitszuordnung für die Datenverschlüsselung aus und verwaltet den Schlüsselaustausch für die IPSec-Sicherheitszuordnung.

IKE-Glossar

• Eine Sicherheitszuordnung (Security Association, SA) ist die Einrichtung gemeinsamer Sicherheitsattribute zwischen zwei Netzwerkentitäten, um eine sichere Kommunikation zu unterstützen. Eine Sicherheitszuordnung enthält Attribute wie den kryptografischen Algorithmus und Modus, Verschlüsselungsschlüssel für den Datenverkehr sowie Parameter für die Netzwerkdaten, die über die Verbindung übertragen werden sollen.
• Die VIDs (VIDs) werden verarbeitet, um zu bestimmen, ob der Peer NAT-Traversal, Dead Peer Detection, Fragmentation usw. unterstützt.
• Nonce: eine zufällig generierte Zahl, die der Initiator sendet. Diese Nonce wird zusammen mit den anderen Elementen mit dem verwendeten vereinbarten Schlüssel gehasht und zurückgesendet. Der Initiator überprüft das Cookie und die Nonce und lehnt alle Nachrichten ab, die nicht die richtige Nonce enthalten. Dies trägt dazu bei, eine Wiederholung zu verhindern, da kein Dritter die zufällig generierte Nonce vorhersagen kann.
• KE-Informationen (Schlüsselaustausch) für den sicheren Diffie-Hellman-Schlüsselaustauschprozess (DH).
• Der Identity Initiator/Responder (IDi/IDr) wird verwendet, um Authentifizierungsinformationen an den Peer zu senden. Diese Informationen werden unter dem Schutz des gemeinsamen geheimen Schlüssels übertragen.
• Der DH-Schlüsselaustausch (Diffie-Hellman) ist eine Methode für den sicheren Austausch von kryptografischen Algorithmen über einen öffentlichen Kanal.
  
• Der gemeinsame IPSec-Schlüssel kann mit dem verwendeten DH erneut abgeleitet werden, um Perfect Forward Secrecy (PFS) sicherzustellen, oder der ursprüngliche DH-Austausch wird auf den zuvor abgeleiteten Shared Secret aktualisiert.

Paketaustausch im Main-Modus

Jedes ISAKMP-Paket enthält Payload-Informationen für die Tunneleinrichtung. Das IKE-Glossar erläutert die IKE-Abkürzungen als Teil des Payload-Inhalts für den Paketaustausch im Main-Modus, wie in dieser Abbildung dargestellt.

Main-Modus 1 (MM1)

Um die Bedingungen der ISAKMP-Aushandlungen festzulegen, erstellen Sie eine ISAKMP-Richtlinie, die Folgendes enthält:

• Eine Authentifizierungsmethode, um die Identität der Peers sicherzustellen.
• Eine Verschlüsselungsmethode, um die Daten zu schützen und die Privatsphäre zu gewährleisten.
• Eine HMAC-Methode (Hashed Message Authentication Codes), um die Identität des Absenders sicherzustellen und sicherzustellen, dass die Nachricht während der Übertragung nicht geändert wurde.
• Eine Diffie-Hellman-Gruppe, um die Stärke des Algorithmus zur Bestimmung des Verschlüsselungscodes zu bestimmen. Die Security-Appliance verwendet diesen Algorithmus, um die Verschlüsselungs- und Hash-Schlüssel abzuleiten.
• Ein Grenzwert für die Verwendung eines Verschlüsselungscodes durch die Security-Appliance, bevor er ersetzt wird.

Das erste Paket wird vom Initiator der IKE-Aushandlung gesendet, wie in der Abbildung dargestellt:

 

Hinweis: Main-Modus 1 ist das erste Paket der IKE-Aushandlung. Daher wird der Initiator-SPI auf einen zufälligen Wert gesetzt, während der Responder-SPI auf 0 gesetzt wird. Im zweiten Paket (MM2) muss der Responder-SPI mit einem neuen Wert beantwortet werden, und die gesamte Verhandlung behält die gleichen SPI-Werte bei.

Wenn MM1 erfasst und ein Wireshark-Netzwerkprotokollanalysator verwendet wird, liegt der SPI-Wert innerhalb des Inhalts der Internet Security Association und des Key Management Protocol, wie in der Abbildung dargestellt:

Hinweis: Wenn das MM1-Paket auf dem Pfad verloren geht oder es keine MM2-Antwort gibt, behält die IKE-Aushandlung die MM1-Weiterleitungen bei, bis die maximale Anzahl der Neuübertragungen erreicht ist. Zu diesem Zeitpunkt behält der Initiator den gleichen SPI bei, bis die nächste Aushandlung erneut ausgelöst wird.

Tipp: Die Identifizierung der Initiator- und Responder-SPIs ist sehr hilfreich, um mehrere Aushandlungen für dasselbe VPN zu identifizieren und einige Aushandlungsprobleme einzugrenzen.

Identifizieren Sie zwei gleichzeitige Aushandlungen

Auf den Cisco IOS® XE-Plattformen können die Fehlerbehebungen pro Tunnel gefiltert werden, wobei eine Bedingung für die konfigurierte Remote-IP-Adresse verwendet wird. Die gleichzeitigen Verhandlungen werden jedoch in den Protokollen angezeigt, und es ist nicht möglich, sie zu filtern. Dies muss manuell erfolgen. Wie bereits erwähnt, werden während der gesamten Aushandlung die SPI-Werte für Initiator und Responder beibehalten. Wenn ein Paket von derselben Peer-IP-Adresse empfangen wird, aber der SPI nicht mit dem vorherigen nachverfolgten Wert übereinstimmt, bevor die Aushandlung die maximale Anzahl von Neuübertragungen erreicht hat, handelt es sich um eine andere Aushandlung für denselben Peer, wie in der Abbildung dargestellt:

Hinweis: Das Beispiel zeigt die gleichzeitige Aushandlung für das erste Paket in der Aushandlung (MM1). Dies kann jedoch zu jedem beliebigen Verhandlungspunkt erfolgen. Alle nachfolgenden Pakete müssen auf der Responder-SPI einen Wert ungleich 0 enthalten.

Main-Modus 2 (MM2)

Im Paket für Main-Modus 2 sendet der Responder die ausgewählte Richtlinie für die übereinstimmenden Angebote, und die Responder-SPI wird auf einen zufälligen Wert festgelegt. In der gesamten Aushandlung werden die gleichen SPIs-Werte beibehalten. MM2 antwortet auf MM1, und der SPI-Responder ist auf einen Wert ungleich 0 eingestellt, wie in der Abbildung dargestellt:

Wenn MM2 erfasst wird und ein Wireshark-Netzwerkprotokollanalysator verwendet wird, befinden sich die Initiator-SPI- und die Responder-SPI-Werte innerhalb des Inhalts der Internet Security Association und des Key Management Protocol, wie in der Abbildung dargestellt:

Main-Modus 3 und 4 (MM3-MM4)

Die MM3- und MM4-Pakete sind noch unverschlüsselt und nicht authentifiziert und der Austausch des geheimen Schlüssels erfolgt. MM3 und MM4 sind in der Abbildung dargestellt:

Main-Modus 5 und 6 (MM5-MM6)

Die MM5- und MM6-Pakete sind bereits verschlüsselt, aber noch nicht authentifiziert. Bei diesen Paketen erfolgt die Authentifizierung, wie in der Abbildung dargestellt:

Quick-Modus (QM1, QM2 und QM3)

Der Quick-Modus beginnt, nachdem der Main-Modus abgeschlossen ist und das IKE den sicheren Tunnel in Phase 1 eingerichtet hat. Der Quick-Modus handelt die gemeinsame IPSec-Richtlinie für die IPSec-Sicherheitsalgorithmen aus und verwaltet den Schlüsselaustausch für die Einrichtung der IPSec-Sicherheitszuordnung. Mithilfe der Nonces wird neues gemeinsames geheimes Schlüsselmaterial generiert und Replay-Angriffe durch gefälschte Sicherheitszuordnungen verhindert.

In dieser Phase werden drei Pakete ausgetauscht, wie in der Abbildung dargestellt:

Paketaustausch im Aggressive-Modus

 Der Aggressive-Modus zwingt die IKE-Sicherheitszuordnung in drei Pakete, wobei alle für die Sicherheitszuordnung erforderlichen Daten vom Initiator passiert werden.

• Der Responder sendet das Angebot, das Schlüsselmaterial und die ID und authentifiziert die Sitzung im nächsten Paket.
• Der Initiator antwortet und authentifiziert die Sitzung.
• Die Aushandlung ist schneller, und die Initiator- und Responder-ID werden gelöscht.

Die Abbildung zeigt die Payload-Inhalte für die drei Pakete, die im Aggressive-Modus ausgetauscht werden:

Main-Modus im Vergleich zum Aggressive-Modus

Im Vergleich zum Hauptmodus ist der aggressive Modus auf drei Pakete reduziert:

• AM 1 absorbiert MM1 und MM3.
• AM 2 nimmt MM2, MM4 und einen Teil von MM6 auf. Hier liegt der Grund für die Schwachstelle des Aggressive-Modus. Der AM 2 erstellt die IDr. und die Authentifizierung unverschlüsselt. Im Gegensatz zum Hauptmodus werden diese Informationen verschlüsselt.
• AM 3 stellt die IDi und die Authentifizierung bereit. Diese Werte werden verschlüsselt.

IKEv2- und IKEv1-Paketaustausch

Bei der IKEv2-Aushandlung werden weniger Nachrichten ausgetauscht, um einen Tunnel einzurichten. IKEv2 verwendet vier Nachrichten. IKEv1 verwendet entweder sechs Nachrichten (im Main-Modus) oder drei Nachrichten (im Aggressive-Modus).

Die IKEv2-Nachrichtentypen sind als Anfrage-Antwort-Paare definiert. Die Abbildung zeigt den Paketvergleich und den Payload-Inhalt von IKEv2 und IKEv1:

Hinweis: In diesem Dokument wird nicht näher auf den Austausch von IKEv2-Paketen eingegangen. Weitere Referenzen finden Sie unter IKEv2-Paketaustausch und Debugging auf Protokollebene.

Richtlinienbasiert im Vergleich zu routenbasiert

Richtlinienbasiertes VPN

Wie der Name schon sagt, ist ein richtlinienbasiertes VPN ein IPsec-VPN-Tunnel mit einer Richtlinienaktion für den übertragenen Datenverkehr, der die Übereinstimmungskriterien der Richtlinie erfüllt. Bei Cisco Geräten wird eine Zugriffsliste (Access List, ACL) konfiguriert und einer Krypto-Zuordnung angehängt, um den Datenverkehr anzugeben, der zum VPN umgeleitet und verschlüsselt werden soll.

Die Datenverkehrsauswahl erfolgt durch die Subnetze oder Hosts, die in der Richtlinie angegeben sind, wie in der Abbildung dargestellt:

Routenbasiertes VPN

Eine Richtlinie ist nicht erforderlich. Der Datenverkehr wird über Routen in die Tunnel umgeleitet und unterstützt dynamisches Routing über die Tunnelschnittstelle. Die Datenverkehrs-Selektoren (Datenverkehr, der durch das VPN verschlüsselt wird) reichen standardmäßig von 0.0.0.0. bis 0.0.0.0, wie im Bild gezeigt:

Hinweis: Da die Datenverkehrsauswahl 0.0.0.0 lautet, sind alle Hosts oder Subnetze darin enthalten. Daher wird nur eine SA erstellt. Es gibt eine Ausnahme für dynamische Tunnel. Dieses Dokument beschreibt keine dynamischen Tunnel.

Das richtlinien- und routenbasierte VPN kann wie in der Abbildung dargestellt realisiert werden:

Hinweis: Im Gegensatz zu einem routenbasierten VPN, bei dem nur eine Sicherheitszuordnung erstellt wird, kann das richtlinienbasierte VPN mehrere Sicherheitszuordnungen erstellen. Da eine ACL konfiguriert ist, erstellt jede Anweisung in der ACL (sofern sie sich unterscheidet) einen Subtunnel.

Häufige Probleme mit Datenverkehr, der nicht über das VPN empfangen wird

ISP blockiert UDP 500/4500

Es ist ein sehr häufiges Problem, dass der Internet Services Provider (ISP) die UDP 500-/4500-Ports blockiert. Für den Aufbau eines IPsec-Tunnels können zwei verschiedene ISPs eingesetzt werden. Einer von ihnen kann die Ports blockieren, der andere erlaubt es ihnen.

Das Bild zeigt die beiden Szenarien, in denen ein ISP die UDP 500/4500-Ports in nur einer Richtung blockieren kann:

Hinweis: Port UDP 500 wird vom Internet Key Exchange (IKE) für die Einrichtung sicherer VPN-Tunnel verwendet. UDP 4500 wird verwendet, wenn NAT in einem VPN-Endpunkt vorhanden ist.

Hinweis: Wenn der ISP UDP 500/4500 blockiert, ist der Aufbau des IPsec-Tunnels beeinträchtigt und er wird nicht aktiviert.

ISP blockiert ESP

Ein weiteres sehr häufiges Problem bei IPsec-Tunneln ist, dass der ISP den ESP-Datenverkehr blockiert, jedoch die UDP 500/4500-Ports zulässt. Die UDP 500/4500-Ports sind beispielsweise bidirektional zulässig. Der Tunnel wurde erfolgreich eingerichtet, aber die ESP-Pakete werden von dem oder den ISPs in beide Richtungen blockiert. Dies führt dazu, dass der verschlüsselte Datenverkehr über das VPN fehlschlägt, wie im Bild gezeigt:

Hinweis: Wenn der ISP ESP-Pakete blockiert, ist der IPsec-Tunnelaufbau erfolgreich, der verschlüsselte Datenverkehr ist jedoch betroffen. Dies kann sich im VPN nach oben widerspiegeln, der Datenverkehr fließt jedoch nicht darüber. 

Tipp: Das Szenario, in dem der ESP-Datenverkehr nur in eine Richtung blockiert wird, kann ebenfalls vorhanden sein. Die Symptome sind die gleichen, aber es kann leicht mit den Tunnel-Statistiken Informationen gefunden werden, Kapselung, Entkapselung Zähler oder RX und TX Zähler.

Zugehörige Informationen

• KEv2-Paketaustausch und Debugging auf Protokollebene
• Internet Key Exchange (IKE) – RFC 2409
• IKEv2-Protokoll (Internet Key Exchange)
• Technischer Support und Dokumentation für Cisco Systeme