Gruppen-VPNv2 – Übersicht

Grundlegendes zu Gruppen-VPNv2

Group VPN ist eine vertrauenswürdige Gruppe, die Punkt-zu-Punkt-Tunnel und das damit verbundene Overlay-Routing eliminiert. Alle Gruppenmitglieder teilen sich eine gemeinsame Sicherheitsvereinigung (SA), die als Gruppen-SA (GSA) bezeichnet wird. Die GSA ermöglicht es Gruppenmitgliedern, Datenverkehr zu entschlüsseln, der von einem anderen Gruppenmitglied verschlüsselt wurde. Ab Junos OS Version 18.2R1 bestätigen wir die Gruppen-VPN-Redundanz mit dem Service Redundanz Protocol [SRD], das auf MX-Routern ausgeführt wird. MX-Router mit Redundanz zwischen ihnen fungieren als Gruppen-VPN-Mitglieder. Weitere Informationen zu Service Redundanz Protocol finden Sie unter Übersicht über den Service-Redundanz-Daemon.

Ab Junos OS Version 15.1 unterstützt Junos OS Gruppen-VPNv2. Gruppen-VPNv2 ist eine VPN-Kategorie, die Punkt-zu-Punkt-VPN-Tunnel in einer Mesh-Architektur überflüssig macht. Es handelt sich um eine Reihe von Funktionen, die erforderlich sind, um Unicast Datenverkehr über einen privaten WAN zu sichern, der von einem Router stammt oder durch einen fließt.

Gruppen-VPNv2 führt das Konzept einer vertrauenswürdigen Gruppe ein, um Punkt-zu-Punkt-Tunnel und das damit verbundene Overlay-Routing zu eliminieren. Alle Gruppenmitglieder teilen sich eine gemeinsame Sicherheitsvereinigung (SA), die auch als Gruppen-SA bezeichnet wird. Auf diese Weise können Gruppenmitglieder Datenverkehr entschlüsseln, der von einem anderen Gruppenmitglied verschlüsselt wurde.

Gruppen-VPNv2 bietet die folgenden Vorteile:

• Bietet Datensicherheit und Transport-Authentifizierung und hilft durch Verschlüsselung des gesamten WAN-Datenverkehrs bei der Einhaltung von Sicherheits-Compliance und internen Vorschriften.

• Ermöglicht groß angelegte Netzwerk-Meshes und eliminiert die komplexe Verwaltung von Peer-to-Peer-Schlüsseln mit Gruppenverschlüsselungsschlüsseln.

• Reduziert die Anzahl der Änderungen an Endgeräten, die aufgrund einer Änderung von Gruppenmitgliedern oder Richtlinien vorgenommen werden müssen.

• Erhält Netzwerkintelligenz wie Full-Mesh-Konnektivität, natürlichen Routing-Pfad und Quality of Service (QoS) in MPLS-Netzwerken.

• Gewährt authentifizierte Mitgliedschaftskontrolle mit einem zentralisierten Schlüsselserver.

• Ermöglicht die Ver- und Entschlüsselung des Datenverkehrs zwischen allen in der Gruppenrichtlinie definierten Gruppenmitgliedern.

• Hilft bei niedriger Latenz und niedrigem Jitter, indem es eine direkte Kommunikation zwischen Standorten in Vollzeit ermöglicht, ohne dass der Transport über einen zentralen Hub erforderlich ist.

• Reduziert die Datenverkehrslast auf CPE-Geräten (Customer Premises Equipment) und Provider-Edge-Verschlüsselungsgeräten (PE), indem das Kernnetzwerk für die Datenverkehrsreplikation verwendet wird, wodurch eine Paketreplikation an jedem einzelnen Peer-Standort vermieden wird.

Gruppen-VPNv2 und Standard-IPsec-VPN

Gruppen-VPNv2 basiert auf standardbasierten Technologien, die Routing und Verschlüsselung gemeinsam im Netzwerk integrieren. Eine IPsec-Sicherheits-SA ist eine unidirektionale Vereinbarung zwischen VPN-Teilnehmern, die die Regeln für Authentifizierungs- und Verschlüsselungsalgorithmen, Schlüsselaustauschmechanismen und sichere Kommunikation definiert.

Herkömmliche IPsec-VPN-Bereitstellungen lösen das Problem der Sicherung des Datenverkehrs zwischen Gateways im Netzwerk, indem sie ein Overlay-Netzwerk erstellen, das auf der Verwendung von Punkt-zu-Punkt-Tunneln basiert. Der über diese Tunnel übertragene Datenverkehr wird normalerweise verschlüsselt und authentifiziert, um die Integrität und Vertraulichkeit der Daten zu gewährleisten. Sichere Gruppenmitglieder werden über das Group Domain of Interpretation Protocol (GDOI) verwaltet. Die GDOI-Lösung verfolgt einen anderen Ansatz, indem sie das Problem der Verschlüsselung und Authentifizierung vom Transport trennt. Auf diese Weise bieten GDOI-basierte Lösungen eine Möglichkeit, die Kommunikation zwischen Zweigstellen zu verschlüsseln, ohne dass Zweigstellentunnel konfiguriert werden müssen.

Bei den aktuellen VPN-Implementierungen ist die SA ein Punkt-zu-Punkt-Tunnel zwischen zwei Endpunkten. Group VPNv2 erweitert die IPsec-Architektur, um SAs zu unterstützen, die von einer Gruppe von Routern gemeinsam genutzt werden (siehe Abbildung 1). Ein Schlüsselserver verteilt Schlüssel und Richtlinien an alle registrierten und authentifizierten Mitgliedsrouter. Durch die Verteilung von Richtlinien von einem zentralen Punkt aus und durch die gemeinsame Nutzung derselben Gruppensicherheitszuordnung (die gesamte Gruppe hat eine einzige Phase-2-SA) mit authentifizierten Gruppenmitgliedern werden die Schlüsselverteilung und -verwaltung erheblich vereinfacht.

Gruppe VPNv2 ist eine Client/Server-Architektur. Alle Mitglieder verfügen über eine eindeutige Phase 1 IKE SA mit dem Schlüsselserver. Wenn es also Mitglieder gibt n , gibt es insgesamt n Phase 1 IKE SAs. Die gesamte Gruppe teilt sich jedoch eine einzige Phase-2-SA.

Beim herkömmlichen IPsec werden die Tunnel-Endgerät-Adressen als neue Paketquelle und -ziel verwendet. Das Paket wird dann über die IP-Infrastruktur geleitet, wobei die Quell-IP-Adresse des verschlüsselnden Endpunkts und die entschlüsselnde Ziel-IP-Adresse des Endpunkts verwendet werden. Im Fall von Gruppen-VPN behalten IPsec-geschützte Datenpakete die ursprünglichen Quell- und Zieladressen des Hosts im äußeren IP-Header bei, um die IP-Adresse zu erhalten. Dies wird als Tunnel-Header-Erhaltung bezeichnet. Der größte Vorteil der Erhaltung von Tunnel-Headern ist die Möglichkeit, verschlüsselte Pakete über die zugrunde liegende Netzwerk-Routing-Infrastruktur weiterzuleiten.

Das GDOI-Protokoll verstehen

Das in RFC 6407 beschriebene Group Domain of Interpretation (GDOI)-Protokoll wird verwendet, um eine Reihe von kryptografischen Schlüsseln und Richtlinien an eine Gruppe von Geräten zu verteilen. GDOI ist definiert als die Internet Sicherheit Association Key Management Protocol (ISAKMP) Domain of Interpretation (DOI) für die Verwaltung von Gruppenschlüsseln. In einem Gruppenverwaltungsmodell arbeitet das GDOI-Protokoll zwischen einem Gruppenmitglied und einem Gruppencontroller oder Schlüsselserver (GC/KS) und verwaltet Gruppensicherheitszuordnungen und Gruppenschlüssel für eine Reihe von Sicherheitsteilnehmern. Das ISAKMP definiert zwei Verhandlungsphasen. GDOI ist ein Phase-2-Protokoll, das durch eine Phase-1-ISAKMP-Sicherheitsvereinigung geschützt ist. IKEv1 ist in RFC 6407 als Phase-1-Protokoll spezifiziert.

GDOI führt zwei verschiedene Verschlüsselungsschlüssel ein:

• Key Encryption Key (KEK): Wird zum Sichern der Steuerungsebene verwendet. KEK ist der Name des Schlüssels, der von den Gruppenmitgliedern zum Entschlüsseln von Rekey-Nachrichten aus dem GC/KS verwendet wird. Dieser Schlüssel ist Teil des Sicherheit Association Key Encryption Key (SAK).

• Datenverkehrsverschlüsselungsschlüssel (TEK): Wird zum Sichern der Data Plane verwendet. TEK ist der Name des Schlüssels, der von den Gruppenmitgliedern verwendet wird, um die Kommunikation zwischen anderen Gruppenmitgliedern zu verschlüsseln oder zu entschlüsseln. Dieser Schlüssel ist Teil des Sicherheit Association Transport Encryption Key (SA TEK).

Wie bei Standard-IPsec haben alle Schlüssel eine Lebensdauer und müssen neu verschlüsselt werden. Die über GDOI verteilten Schlüssel sind Gruppenschlüssel und werden von der gesamten Gruppe verwendet.

Die Gruppen-SAs und die Schlüsselverwaltung werden über zwei Arten von GDOI-Börsen abgewickelt:

• groupkey-pull– Dieser Austausch ermöglicht es einem Mitglied, von der Gruppe freigegebene SAs und Schlüssel vom Server anzufordern.

  Bei der pull-Methode fordert das Gruppenmitglied die Gruppen-SA und -richtlinie vom Schlüsselserver an. Diese Anfrage ist über die IKE SA geschützt.

  Das ist groupkey-pull der erste Austausch im GDOI-Protokoll und wird für die Registrierung von Gruppenmitgliedern beim GC/KS verwendet. Das Gruppenmitglied gibt die Gruppe an, bei der es sich registrieren möchte, und der GC/KS sendet alle erforderlichen Gruppen-SAs und Schlüssel an das Gruppenmitglied, wenn das Mitglied berechtigt ist, der Gruppe beizutreten. Der komplette Austausch ist durch eine Phase 1 SA (IKEv1 SA) gesichert, die vor Beginn des groupkey-pull Austauschs mit IKEv1 aufgebaut wird. Das groupkey-pull ist Teil von Phase 2 des GDOI-Protokolls.

• groupkey-push– Dieser Austausch ist eine einzelne Neuschlüsselnachricht, die es dem Server ermöglicht, Gruppen-SAs und Schlüssel an Mitglieder zu senden, bevor bestehende Gruppen-SAs ablaufen. Rekey-Nachrichten sind unerwünschte Nachrichten, die vom Server an Mitglieder gesendet werden.

  Dies groupkey-push ist der zweite Austausch im GDOI-Protokoll und wird vom GC/KS an alle registrierten Mitglieder der Gruppe initiiert. Tabelle 2 zeigt die Nutzlasten, die das Gruppenmitglied der MX-Serie in groupkey-push Nachrichten erwartet.

  Tabelle 2: Gruppenschlüssel-Push-Nachrichtennutzlasten

  Nutzlast	Beschreibung
  Gruppenzugehörige Richtlinie (GAP)	Eine GAP-Payload ermöglicht die Verteilung gruppenweiter Richtlinien, z. B. Anweisungen, wann SAs aktiviert und deaktiviert werden sollen. Diese Nutzlast enthält Werte für die Aktivierungszeitverzögerung (ATD) und die Deaktivierungszeitverzögerung (DTD) für den Datenverschlüsselungsschlüssel (TEK) sowie den Fenstertyp und die Fenstergröße für den IPsec-Datenverkehr des IP-Delivery Delayed Detection Protocol.
  Transport Encryption Key (SA TEK) der Sicherheit Association	Datenverkehrs-Selektoren.
  Sicherheitszuordnungsschlüssel (SAK) (optional)	Die Sicherheitszuordnung (SA) für den Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK). Auch bekannt als SA KEK. Hinweis: groupkey-push Nachrichten, die die optionalen Nutzdaten nicht enthalten, sind dennoch gültige Nachrichten.
  Datenverkehrsverschlüsselungsschlüssel (TEK) (optional)	Schlüssel zur Verschlüsselung des Datenverkehrs zwischen Gruppenmitgliedern.
  Schlüsselverschlüsselungsschlüssel (KEK) (optional)	Wird verwendet, um den TEK zu schützen.

  Die groupkey-push Börse ist durch eine SA KEK (SAK) gesichert, die während des Austauschs groupkey-pull installiert wird. Das groupkey-push ist Teil von Phase 2 des GDOI-Protokolls.

In einigen Fällen möchte der GC/KS möglicherweise Push-Bestätigungsnachrichten von Gruppenschlüsseln von Gruppenmitgliedern erhalten. Die Push-Bestätigungsnachrichten von Gruppenmitgliedern bestätigen, dass das Mitglied die Nachricht erhalten und Maßnahmen gemäß seiner Richtlinie ergriffen hat. Der GC/KS kann über die Quittierung auch ermitteln, welche Gruppenmitglieder die aktuelle Gruppenrichtlinie erhalten und welche Gruppenmitglieder nicht mehr an der Gruppe teilnehmen. Ab Junos OS 19.2R1 sendet Junos OS eine Bestätigungsnachricht mit der Prüfsumme SHA-256, wenn es eine Gruppenschlüssel-Push-Nachricht mit einem Standardwert von KEK_ACK_REQUESTED 9 in der SA KEK-Nutzlast gemäß RFC 8263 oder einem KEK_ACK_REQUESTED Wert von 129 empfängt, der von älteren Schlüsselservern verwendet wird.

GDOI-Protokoll und Gruppen-VPNv2

Gruppe VPNv2 ist der Name der Sicherheitstechnologie, die auf den Router-Plattformen von Juniper Networks implementiert ist. Group VPNv2 verwendet neben anderen Funktionalitäten das GDOI-Protokoll (RFC 6407) als Basis.

Die Gruppen-VPNv2-Technologie basiert auf dem GDOI-Protokoll, um die wichtigsten Funktionen zu handhaben. Dieses Protokoll ist in RFC 6407 spezifiziert und definiert eine ISAKMP Domain of Interpretation (DOI) zur Verwaltung von Gruppen-SAs und Schlüsseln für eine Gruppe von Sicherheitsteilnehmern. Daher teilen alle Mitglieder der Gruppe identische Informationen, um den Datenverkehr untereinander zu verschlüsseln und zu entschlüsseln. Die Erstellung, Verwaltung und Verteilung von Gruppen-SAs und Gruppenschlüsseln erfolgt zentral und wird vom GC/KS durchgeführt. Abbildung 2 bietet einen kurzen Überblick über die Gruppen-VPNv2-Funktionalität mit GDOI.

Abbildung 2: Gruppen-VPNv2 mit GDOI

Die Gruppenmitglieder verwenden das ESP-Protokoll (Encapsulating Sicherheit Payload) im Tunnel-Modus, um den Datenverkehr zu sichern. In Gruppen-VPN wird der Tunnel-Modus jedoch geändert. Da keine direkte Zuordnung zwischen den Gruppenmitgliedern besteht, ist es nicht erforderlich, spezielle IP-Adressen im äußeren IP-Header (d. h. IP-Adressen von IPsec-Gateways) zu verwenden. Jedes Gruppenmitglied kann den Datenverkehr jedes anderen Gruppenmitglieds entschlüsseln. Somit wird der innere IP-Header in den äußeren IP-Header kopiert und die zugrunde liegende Routing-Infrastruktur und QoS-Infrastruktur kann verwendet werden. Dieses Feature wird als Headererhaltung bezeichnet und ist in Abbildung 3 dargestellt.

Abbildung 3: Beibehaltung der Kopfzeile

Um Gruppen-SAs und Gruppenschlüssel zu erhalten, muss sich das Gruppenmitglied beim GC/KS für eine bestimmte Gruppe registrieren. Das Ergebnis ist eine IKEv1 SA, die nur zur Absicherung des Registrierungsprozesses benötigt wird. Nach der Registrierung verfügt das Gruppenmitglied über alle Informationen, um mit den anderen Gruppenmitgliedern zu kommunizieren (SA TEK), sowie über die Informationen, um die Neuschlüsselungsnachrichten (SAK) erfolgreich zu entschlüsseln. Der GC/KS sendet Nachrichten zur erneuten Schlüsseleingabe, bevor entweder die SA TEK- oder SAK-Lebensdauer abläuft. Es ist auch möglich, ein SA TEK-Update sowie ein SAK-Update in derselben Rekey-Nachricht zu senden. Die IKEv1-SA wird nicht mehr benötigt und nach Ablauf der Lebensdauer gelöscht (keine IKEv1-Neuschlüsselung).

Gruppen-VPNv2-Datenverkehr

Der Gruppen-VPNv2-Datenverkehr umfasst:

• Control-plane-traffic: Datenverkehr von den Gruppenmitgliedern zum GC/KS in der Gruppen-VPNv2-Bereitstellung nur mit dem GVO-Protokoll.

• Data-plane-traffic: Datenverkehr zwischen den Gruppenmitgliedern in der Gruppen-VPNv2-Bereitstellung nur mit dem ESP-Protokoll, das bereits von IPsec bekannt ist.

Group Sicherheit Association

Im Gegensatz zu herkömmlichen IPsec-Verschlüsselungslösungen verwendet Gruppen-VPN das Konzept der Gruppensicherheitszuordnung. Eine Gruppen-SA ähnelt einer SA in Bezug auf die Funktionalität. Gruppen-SAs werden von allen Gruppenmitgliedern einer gemeinsamen GDOI-Gruppe gemeinsam genutzt. Alle Mitglieder in der Gruppen-VPN-Gruppe können über eine gemeinsame Verschlüsselungsrichtlinie und eine freigegebene Gruppen-SA miteinander kommunizieren. Mit einer gemeinsamen Verschlüsselungsrichtlinie und einer gemeinsam genutzten Gruppen-SA ist es nicht erforderlich, IPsec zwischen Gruppenmitgliedern auszuhandeln. Dadurch wird die Ressourcenbelastung der Gruppenmitglieder reduziert. Herkömmliche IPsec-Skalierbarkeitsprobleme (Anzahl der Tunnel und zugehörige SAs) gelten nicht für Gruppen-VPN-Gruppenmitglieder.

Gruppencontroller/Schlüsselserver

Ein Gruppencontroller oder Schlüsselserver (GC/KS) ist ein Gerät, das zum Erstellen und Verwalten der Gruppen-VPNv2-Steuerungsebene verwendet wird. Es ist für die Erstellung und Verteilung von Gruppen-SAs und Gruppenschlüsseln verantwortlich. Alle Informationen, die die Gruppenmitglieder benötigen, um mit anderen Gruppenmitgliedern zu kommunizieren, werden vom GC/KS zur Verfügung gestellt. Alle Verschlüsselungsrichtlinien, wie z. B. interessanter Datenverkehr, Verschlüsselungsprotokolle, Sicherheitszuordnung, Rekey-Timer usw., werden zentral auf dem GC/KS definiert und bei der Registrierung an alle Gruppenmitglieder weitergegeben. Gruppenmitglieder authentifizieren sich mit dem GC/KS mithilfe von IKE Phase 1 und laden dann die Verschlüsselungsrichtlinien und Schlüssel herunter, die für den Gruppen-VPN-Betrieb erforderlich sind. Der GC/KS ist auch für die Aktualisierung und Verteilung der Schlüssel zuständig.

Mitglied der Gruppe

Ein Gruppenmitglied ist ein IPsec-Endgerät, das für den Datenverkehrsverschlüsselungsprozess verwendet wird und für die eigentliche Ver- und Entschlüsselung des Datenverkehrs verantwortlich ist. Ein Gruppenmitglied wird mit IKE-Phase-1-Parametern und GC/KS-Informationen konfiguriert. Verschlüsselungsrichtlinien werden zentral auf dem GC/KS definiert und zum Zeitpunkt der erfolgreichen Registrierung an das Gruppenmitglied heruntergeladen. Jedes Gruppenmitglied bestimmt dann anhand seiner Gruppenmitgliedschaft, ob eingehender und ausgehender Datenverkehr entschlüsselt oder verschlüsselt werden soll (unter Verwendung seiner SA).

Aus funktionaler Sicht ähnelt ein Gruppenmitglied einem IPsec-Gateway. Die SAs in normalem IPsec existieren jedoch zwischen zwei IPsec-Gateways. In GDOI meldet sich das Gruppenmitglied beim GC/KS an, um am Gruppen-VPN teilzunehmen. Während der Registrierung gibt das Gruppenmitglied die Gruppen-ID an den GC/KS weiter, um die entsprechenden Richtlinien, SAs und Schlüssel zu erhalten, die für diese Gruppe erforderlich sind. Die Neuschlüsselung wird von den Gruppenmitgliedern durch die groupkey-pull Methode (Neuregistrierung) oder durch den GC/KS durch die groupkey-push Methode durchgeführt.

Anti-Replay-Schutz für Gruppen-VPNv2-Datenverkehr

Da es sich bei der Gruppen-VPN-Kommunikation im Wesentlichen um eine Any-to-Any-Kommunikation über dieselbe freigegebene Sicherheitszuordnung handelt, funktioniert die Verwendung von Sequenznummern für den Anti-Replay-Schutz nicht. Aus diesem Grund unterstützt Junos OS eine IETF-Entwurfsspezifikation für einen zeitbasierten Anti-Replay-Mechanismus, draft-weis-delay-detection-01. Es ist bei http://tools.ietf.org/html/draft-weis-delay-detection-01 erhältlich.

Um diese Funktion zu implementieren, verwenden die Mitgliedsrouter der MX-Serie einen neuen Zeitstempel-Header des IP Delivery Delay Detection Protocol innerhalb des Pakets. Weitere Informationen finden Sie unter Implementierung des IP Delivery Delay Detection Protocol (Time-Based Anti-Replay Protection).

Teilweises Fail-Open bei Mitgliedsroutern der MX-Serie

Gruppenmitglieder in einem Gruppen-VPN verlassen sich auf den GC/KS, um Schlüsselmaterial für die gemeinsam genutzte SA zu generieren. Daher ist Konnektivität zwischen den Gruppenmitgliedern und GC/KSs erforderlich, um den Datenverkehr zunächst und über Rekey-Ereignisse hinweg kontinuierlich zu schützen. Im Falle eines Kommunikationsfehlers zwischen dem Gruppenmitglied und dem GC/KS ist das Standardverhalten der Gruppenmitglieder, die Weiterleitung des Datenverkehrs zu stoppen. Dies wird als Fail-Closed bezeichnet.

Es ist eine nicht standardmäßige Konfigurationsoption verfügbar, mit der ein speziell definierter Datenverkehr unverschlüsselt durch das Gruppenmitglied fließen kann, bis das Mitglied in der Lage ist, den GC/KS zu kontaktieren und die aktive SA abzurufen. Dies wird als partielles Fail-Open bezeichnet.

Die Funktion zum teilweisen Ausfall erfordert eine Richtlinienkonfigurationsoption, die eine Regel für das entsprechende Gruppenmitglied der MX-Serie für ein bestimmtes Gruppen-VPNv2 erstellt, das durch Quell- und Zieladressen definiert ist. Diese Fail-Open-Regel ist nur aktiv, wenn sich die Gruppen-SA aufgrund eines Verbindungsfehlers mit dem Schlüsselserver im deaktivierten Zustand befindet. Datenverkehr, der normalerweise das Gruppen-VPN passieren würde, aber nicht der Fail-Open-Regel entspricht, wird verworfen. Für das Gruppen-VPN-Objekt können mehrere Fail-Open-Regeln definiert werden. Wenn keine Fail-Open-Regeln konfiguriert sind, ist die Fail-Open-Funktion deaktiviert.

Aktivieren von Gruppen-VPNv2

Ein Service-Set wird verwendet, um Gruppen-VPNv2 auf einer bestimmten Schnittstelle auf entsprechenden Routern der MX-Serie zu aktivieren.

[edit services]
service-set service-set-name {
    interface-service {
        service-interface service-interface-name;
    }
}
ipsec-group-vpn vpn-name;

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name;
                }
                output {
                    service-set service-set-name;
                }
            }
            address 10.0.30.2/30;
        }
    }
}

Registrieren eines Gruppenmitglieds

Die Registrierung eines Gruppenmitglieds beim Server beginnt, wenn die ipsec-group-vpn Anweisung für einen Servicesatz konfiguriert ist und die Serviceschnittstelle aktiv ist. Wenn die Dienstschnittstelle ausfällt, werden alle dieser Schnittstelle zugeordneten Gruppen-SAs gelöscht, und es wird keine Registrierung für diese Gruppen-VPNs ausgelöst, bis die Schnittstelle aktiviert wird.

Die Registrierung eines Gruppenmitglieds umfasst die Einrichtung einer IKE-SA mit dem GC/KS, gefolgt von einem groupkey-pull Austausch zum Herunterladen der SAs und der Datenverkehrsschlüssel für die angegebene Gruppenkennung.

Erneutes Schlüsseln eines Gruppenmitglieds (groupkey-push-Methode)

Der GC/KS sendet eine Unicast-Nachricht groupkey-push an registrierte Gruppenmitglieder, um:

• Senden neuer Schlüsselverschlüsselungsschlüssel (KEKs) oder Datenverkehrverschlüsselungsschlüssel (TEKs).

  Die Push-Nachrichten können alle oder nur einige der in Tabelle 2 aufgeführten Nutzlastelemente enthalten. Wenn die GAP-Nutzlast sowohl alte SAs als auch neue Ersatz-SAs enthält, wendet der Router des Gruppenmitglieds die ATD- und DTD-Werte als normalen Rekey per Push an. Wenn das Update keinen ATD-Wert enthält, installiert der Mitglieds-Router die neuen SAs sofort. Wenn kein DTD-Wert vorhanden ist, bleiben die alten SAs bis zu ihrem Ablauf bestehen.

• Aktualisieren Sie die gruppenzugehörige Richtlinie (GAP) für eine vorhandene SA.

  Ein GC/KS kann jederzeit eine Unicast-Push-Nachricht senden, um die Konfiguration an Gruppenmitglieder zu aktualisieren. Die GAP-Nutzlast kann Konfigurationsänderungen am IP Delivery Delay Detection Protocol, dem Verschlüsselungsalgorithmus, der Lebensdauer usw. umfassen. Die aktualisierte Konfiguration wird entweder sofort oder verzögert angewendet. ATD- und DTD-Werte werden verwendet, um den Zeitpunkt für die Aktivierung der neuen TEK bzw. das Löschen der vorhandenen TEK zu erreichen. Wenn die vorhandene TEK-Lebensdauer reduziert werden muss, dann wird der DTD-Wert in der Push-Nachricht entsprechend gesetzt. Der neue TEK in der Push-Nachricht wird basierend auf dem ATD-Wert in der Nutzlast aktiviert.

• Senden von Löschschlüsselbenachrichtigungen für TEK oder KEK.

  Der GC/KS kann die optionale Nutzlast der Löschbenachrichtigung in der Push-Nachricht zum Löschen von Schlüsseln und SAs auf dem Member senden. Die Push-Nachricht enthält die Protokoll-ID, die angibt, ob die Löschbenachrichtigung für TEK oder KEK gilt. Der Router des Gruppenmitglieds löscht den Schlüssel basierend auf der Gruppen-ID und dem SPI-Wert, die in der Nutzlast enthalten sind. Das Löschen eines bestimmten TEK oder KEK kann mit einem im DTD-Attribut angegebenen Verzögerungswert erfolgen. Wenn der Verzögerungswert 0 ist und die Nutzlast einen bestimmten SPI enthält, wird der entsprechende TEK oder KEK sofort gelöscht. Wenn alle TEKs oder KEKs (oder beide) in der Gruppe gelöscht werden müssen, wird der SPI-Wert für die entsprechende Protokoll-ID in der Nutzlast auf 0 gesetzt.

• Entfernen Sie einen Mitglieds-Router aus dem Gruppen-VPN in Gruppe VPNv2.

  Die Push-Nachrichten werden verwendet, um dem GC/KS zu ermöglichen, Mitglieder aus dem Gruppen-VPN zu löschen. In einem Fall sendet der GC/KS eine Rekey-Nachricht, die nur die alten SAs und einen kleineren DTD-Wert enthält. Der Gruppenmitglied-Router installiert den neuen, kleineren DTD-Wert. Da er keine neuen SA-Schlüssel erhalten hat, versucht der Mitglieds-Router, sich mit der groupkey-pull Methode erneut zu registrieren. Dieser Neuregistrierungsversuch wird vom GC/KS abgelehnt, wodurch das Mitglied aus dem Gruppen-VPN gelöscht wird. Im zweiten Fall sendet der GC/KS eine Delete-Payload für den SPI der alten SA. Der Router des Gruppenmitglieds löscht die SA sofort und versucht, sich mit der groupkey-pull Methode erneut zu registrieren. Dieser Neuregistrierungsversuch wird vom GC/KS abgelehnt, wodurch das Mitglied aus dem Gruppen-VPN gelöscht wird.

Registrierte Gruppenmitglieder der MX-Serie senden eine Unicast-PUSH-ACK-Nachricht zurück an den GC/KS, um den Empfang der ursprünglichen Push-Nachricht zu bestätigen.

Neuschlüssel für ein Gruppenmitglied (groupkey-pull-Methode)

Bei der Neuschlüsselung von Gruppenmitgliedern mit der groupkey-pull Methode registrieren sich die Gruppenmitglieder in der Regel erneut beim GC/KS, wenn in der bestehenden TEK- oder KEK-Soft-Lebensdauer noch zwischen 7 und 5 Prozent verbleiben. Wenn die vorhandene IKE-Verbindungsliste verfügbar ist, wird sie in der Pull-Nachricht verwendet. Nachdem der GC/KS mit einem neuen Schlüssel antwortet, können sowohl der alte Schlüssel als auch der neue Schlüssel zur Entschlüsselung verwendet werden. Der neue Schlüssel wird jedoch erst dann für die Verschlüsselung verwendet, wenn die Lebensdauer des alten Schlüssels noch 30 Sekunden verbleibt. Wenn die vorhandene IKE-SA nicht verfügbar ist, führt die Pull-Nachricht zu neuen IKE-Verhandlungen zwischen dem Gruppenmitglied und dem GC/KS.

Wenn der GC/KS die Pull-Nachricht zu einem bestimmten Gruppen-VPN vom Gruppenmitglied erhält, antwortet er mit allen TEKs und dem KEK für diese Gruppe.

Wenn eine vorhandene SA nicht in der Antwort des GC/KS enthalten ist, werden die fehlenden SAs vom Gruppenmitglied gelöscht.

Am Beispiel ist der GC/KS mit einer Lebensdauer von 3600 Sekunden konfiguriert und ohne erneute Übertragung mit einem Gruppenmitglied verbunden. Basierend auf der Serverkonfiguration generiert der GC/KS einen neuen Schlüssel, wenn 10 Prozent der Lebensdauer verbleiben. Das Gruppenmitglied meldet sich jedoch erneut beim GC/KS an, wenn 5 bis 7 Prozent der Lebensdauer verbleiben.

Abbildung 4 stellt den Prozess der erneuten Eingabe zwischen dem GC/KS und dem Gruppenmitglied dar.

Abbildung 4: Neuschlüsselung von Gruppenmitgliedern

Authentifizieren eines Gruppenmitglieds

Junos OS bietet keine Public Key Infrastructure (PKI)-Unterstützung für Gruppen-VPN in Gruppen-VPNv2. Daher werden vorinstallierte Schlüssel für die Authentifizierung von Gruppenmitgliedern verwendet.

Fragmentierung von Gruppen-VPNv2-Datenverkehr

Aufgrund der Funktion zum Beibehalten von Headern und der Verwendung der zugrunde liegenden Routing-Infrastruktur ist es notwendig, die Pakete zu fragmentieren, bevor die Verschlüsselung erfolgt (wenn dies nicht verhindert werden kann).

Daher wird eine Vor-Fragmentierung unterstützt und für alle Bereitstellungen empfohlen.

Um eine nachträgliche Fragmentierung zu vermeiden, legen Sie in der VPNv2-Konfiguration der clearGruppe die Optionen , setund copy für das DF-Bit fest.

Basierend auf dieser Flageinstellung hat der IPsec-Header entweder den df-bit Wert auf clear, setoder copy aus dem inneren Paket.

[edit]
security {
    group-vpn {
        member {
            ipsec {
                vpn group-vpn-name {
                    df-bit clear;
                }
            }
        }
    }
}

Verschlüsseln von Gruppen-VPNv2-Datenverkehr

Gruppenmitglieder verschlüsseln den Datenverkehr basierend auf den Gruppen-SAs und -Schlüsseln, die von GC/KS bereitgestellt werden. Der Gruppen-VPNv2-Verschlüsselungspfad lautet wie folgt:

1. Das von der Packet Forwarding Engine empfangene Paket wird mit einer Datenstromübereinstimmung verglichen. Wird eine Übereinstimmung gefunden, wird das Paket weiterverarbeitet und übertragen.

2. Wenn keine Übereinstimmung gefunden wird, wird eine Regelsuche durchgeführt. Wenn eine Übereinstimmung gefunden wird, wird ein Fluss erstellt und das Paket wird weiterverarbeitet und übertragen.

3. Wenn die Regelsuche fehlschlägt, wird das Paket verworfen.

Entschlüsseln von Gruppen-VPNv2-Datenverkehr

Nachdem die Registrierung erfolgreich war und Gruppen-VPN-SAs installiert wurden, wird eine ESP-Sitzung erstellt. Gruppe VPNv2 erstellt die ESP-Sitzung mit einer Null-Quell- und Ziel-IP. Da die ESP-Sitzung bereits bei der SA-Installation erstellt wird, wird erwartet, dass die Pakete mit der vorhandenen ESP-Sitzung übereinstimmen.

Der Gruppen-VPNv2-Entschlüsselungspfad lautet wie folgt:

1. Das von der Packet Forwarding Engine empfangene Paket wird einer Fragmentierung unterzogen. Wenn das Paket fragmentiert ist, wird es für die weitere Verarbeitung zusammengestellt.

2. Nach der Paketzusammenstellung oder wenn das Paket nicht fragmentiert ist, wird eine Null-Quell- und Ziel-IP für die 5-Tupel-Entschlüsselungsflusssuche verwendet. Wird eine Übereinstimmung gefunden, wird das Paket weiterverarbeitet und übertragen.

3. Wenn die Suche nach dem Entschlüsselungsfluss fehlschlägt, wird das Paket mit einem SPI-Fluss ohne Quell- und Ziel-IP verglichen.

4. Wenn die SPI-Datenstromsuche fehlschlägt, wird das Paket verworfen.

5. Wenn eine SPI-Datenstromübereinstimmung gefunden wird, wird ein Entschlüsselungsfluss erstellt, um die SPI-Datenstromsuche für nachfolgende Pakete zu vermeiden.

Konfigurieren einer Routing-Instanz für Gruppen-VPNv2

Routinginstanzen werden sowohl für die Steuerung als auch für den Datenverkehr unterstützt. Um die Unterstützung von Routing-Instanzen im Datenverkehr der Steuerungsebene für ein Gruppenmitglied zu aktivieren, damit es den GC/KS in einer bestimmten VRF-Routing-Instanz erreicht, fügen Sie die routing-instance Anweisung auf Hierarchieebene [edit security group-vpn member ike gateway gateway-name local-address address] hinzu.

Es ist keine zusätzliche CLI erforderlich, um eine Routing-Instanz für Data-Plane-Pakete zu unterstützen, da sie basierend auf der Medienschnittstelle bestimmt wird, auf der der Servicesatz angewendet wird.

Einrichten mehrerer Gruppen, Richtlinien und SAs

Junos OS bietet Unterstützung für ein Gruppen-VPN pro Servicesatz in Gruppe VPNv2. Es können jedoch mehrere Service-Sets erstellt werden, um mehrere Gruppen in einer Routing-Instanz zu unterstützen. Pro Gruppe können mehrere SAs konfiguriert werden. Mehrere Richtlinien für denselben Datenverkehrsschlüssel/SPI werden jedoch nicht unterstützt. Wenn der Server zwei Richtlinien für dieselbe TEK sendet, müssen sie gekoppelt werden, um akzeptiert zu werden, z. B. A-B und B-A, wobei A und B IP-Adressen oder Subnetze sind. Wenn mehrere nicht gekoppelte Richtlinien für eine bestimmte TEK empfangen werden, schlägt die Registrierung fehl und es wird eine Systemprotokollmeldung generiert.

Verbindung mit mehreren kooperativen GC/KSs

Damit ein Gruppenmitglied mit einem GC/KS im kooperativen Modus arbeiten kann, wird die Konfiguration erweitert, um maximal vier Server in der Serverliste zuzulassen.

Während der erneuten Eingabe bei Verwendung der groupkey-pull Methode versucht das Gruppenmitglied, eine Verbindung zum GC/KS herzustellen. Wenn die Verbindung zum GC/KS fehlschlägt, versucht das Gruppenmitglied, die Verbindung zum GC/KS wiederherzustellen. Wenn nach drei Wiederholungen im Abstand von 10 Sekunden die Verbindung zum GC/KS nicht wiederhergestellt wird, versucht das Gruppenmitglied, eine Verbindung mit dem nächsten verfügbaren Server in der Serverliste herzustellen. Dieser Vorgang wird wiederholt, bis das Gruppenmitglied eine Verbindung zu einem GC/KS herstellt. Während dieser Zeit werden die nicht abgelaufenen GDOI-SAs auf den Gruppenmitgliedern nicht bereinigt, sodass der Gruppen-VPN-Datenverkehr nicht betroffen ist. Die Zeitlücke zwischen der erneuten Schlüsselerstellung und dem harten Ablauf der Lebensdauer bietet den Gruppenmitgliedern in solchen Fällen genügend Zeit, um eine Verbindung mit dem nächsten verfügbaren Server herzustellen.

Implementierung des IP Delivery Delay Detection Protocol (zeitbasierter Anti-Replay-Schutz)

Für die Implementierung des IP Delivery Delay Detection Protocol ist keine Konfiguration erforderlich. Gruppenmitglieder der MX-Serie erhalten die Größe des Wiedergabefensters, die sie als Teil der GAP-Nutzlast in Push- oder Pull-Nachrichten vom Schlüsselserver verwenden können. Wenn die empfangene Fenstergröße 0 ist, ist der zeitbasierte Anti-Replay-Schutz deaktiviert.

Wenn das IP Delivery Delay Detection Protocol aktiviert ist, fügt der Absender seinen aktuellen Zeitstempel hinzu und verschlüsselt das Paket. Der Empfänger entschlüsselt das Paket und vergleicht die aktuelle Uhrzeit mit dem Zeitstempel im Paket. Pakete, die außerhalb der Fenstergröße liegen, werden verworfen. Aus diesem Grund sollten die Uhren aller Gruppenmitglieder mithilfe des Network Time Protocol (NTP) synchronisiert werden.

Die Zeit des IP Delivery Delay Detection Protocol wird in Sekunden gemessen. Weitere Informationen finden Sie unter IP Delivery Delay Detection Protocol-draft-weis-delay-detection-01 .

Ändern der Gruppen-VPNv2-Konfiguration

Die meisten Änderungen an der Gruppen-VPNv2-Konfiguration führen zum Löschen sowohl bestehender SAs als auch zu einer erneuten Registrierung. Dies löst sowohl Phase 1 als auch den SA-Download mit neuen Datenverkehrsschlüsseln aus.

Umgehung der Gruppen-VPNv2-Konfiguration

Wenn bestimmter Datenverkehr wie ein Routingprotokoll ein Gruppen-VPN in Gruppe VPNv2 umgehen muss, muss ein Dienstfilter auf der Schnittstelle konfiguriert werden, auf der die Dienstgruppe angewendet wird. Pakete, die mit dem Servicefilter übereinstimmen, kommen nicht zur Serviceverarbeitung in den PIC und werden direkt an die Routing-Engine weitergeleitet.

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name service-filter filter-name;
                }
                output {
                    service-set service-set-name service-filter filter-name;
                }
            }
        }
    }
}

Implementierung von teilweisem Fail-Open auf Mitgliedsroutern der MX-Serie

Standardmäßig werden Pakete verworfen, wenn ein Router eines Gruppenmitglieds aufgrund eines Verbindungsverlusts keine SAs vom GC/KS abrufen kann. Wenn Sie möchten, dass ein Teil des Datenverkehrs im Falle eines Kommunikationsfehlers zwischen dem Gruppenmitglied und dem GC/KS unverschlüsselt durchgelassen wird, müssen Sie eine fail-open Regel auf der Hierarchieebene [edit security group-vpn member ipsec vpn vpn-name ] konfigurieren.

Fail-Open-Regeln werden nur dann auf den Datenverkehr angewendet, wenn die Serverkonnektivität unterbrochen wird. Fail-Open-Regeln werden deaktiviert, sobald die Verbindung wiederhergestellt ist und die Schlüssel vom GC/KS empfangen wurden.

[edit security group-vpn member ipsec vpn vpn-name]
fail-open {
    rule rule-name{
        source-address source-ip-address
            destination-address destination-ip-address}
        }
    }

Für jede Gruppe können maximal 10 Fail-Open-Regeln konfiguriert werden.

Unterstützte GDOI-IPsec-Parameter

Jede GDOI-Gruppe hat eine eindeutige ID. Es wird als gemeinsame Basis zwischen GC/KS und dem Gruppenmitglied verwendet, um über Gruppen-SAs und Gruppenschlüssel zu kommunizieren.

Während des Registrierungsprozesses sendet der GC/KS Sicherheit Association Transport Encryption Keys (SA TEKs) an die Gruppenmitglieder. Alle Parameter für die gesamte Gruppensicherheitsrichtlinie sind auf dem GC/KS konfiguriert. Der SA TEK wird von den Gruppenmitgliedern verwendet, um den untereinander ausgetauschten Datenverkehr zu schützen. Tabelle 3 zeigt die Parameter des SA TEK.

Neben den kryptografischen Algorithmen ist der Datenverkehr, der von den Gruppenmitgliedern verschlüsselt werden soll, Teil der SA TEK-Richtlinie (Traffic Selektor).

Die folgenden Anweisungen können für ein Gruppenmitglied von Juniper Networks verwendet werden. Daher müssen die Adressen unter der IKE-Hierarchieebene angegeben werden. Die Aufzählung wird ebenfalls priorisiert. In der folgenden Beispielkonfiguration wird also KS1 vor KS2 kontaktiert.

[edit security]
group-vpn {
    member {
        ike {
            gateway gateway-name {
                ike-policy policy-name;
                server-address <IP_KS1> <IP_KS2> <IP_KS3> <IP_KS4>;
                local-address <IP_GM> routing-instance routing-instance-name;
            }
        }
        ipsec {
            vpn vpn-group-name {
                ike-gateway gateway-name;
                fail-open {
                    rule rule-name {
                    source-address 198.51.100.1/24 
                    destination-address 192.0.2.1/24 
                    }
                }
                group group-ID;
                match-direction output;
            }
        }
    }
}

Unterstützte GDOI IKEv1-Parameter

Die oben genannten IKEv1-Standards sind wie folgt konfiguriert:

Anwenden dynamischer Richtlinien

output Die input und-Optionen unter der ipsec-group-vpn Anweisung geben an, ob die vom Server empfangenen dynamischen Richtlinien verwendet werden, wenn die Schnittstelle, auf die der Servicesatz angewendet wird, die eingehende oder ausgehende Schnittstelle ist. Dies bietet die Flexibilität, unterschiedliche Regeln in der eingehenden und ausgehenden Richtung festzulegen.

Unterstützung von TOS und DSCP

Servicetyp- (TOS) und DiffServ-Codepunkte (DSCP-Bits werden aus dem inneren Paket in das ESP-Paket kopiert.

Interoperabilität der Gruppenmitglieder

Ciscos Implementierung von GDOI heißt Group Encryption Transport (GET) VPN. Während Group VPNv2 in Junos OS und GET VPN von Cisco beide auf RFC 6407, The Group Domain of Interpretation, basieren, gibt es einige Unterschiede bei der Implementierung, die Sie beachten müssen, wenn Sie GDOI in einer Netzwerkumgebung bereitstellen, die sowohl Sicherheits- und Routing-Geräte von Juniper Networks als auch Cisco-Router umfasst. Weitere Informationen finden Sie in den aktuellen Versionshinweisen zu Junos OS.

Die Interoperabilität von Gruppen-VPNv2 ist wie folgt:

• Junos OS bietet Interoperabilitätsunterstützung mit Cisco IOS GC/KS-Unterstützung.

• Junos OS bietet keine Unterstützung für Gruppen-VPNv2-Interoperabilität mit dem Gruppen-VPN-Server der SRX-Serie.

  Tabelle 5: Interoperabilität von Gruppen-VPNv2

  Mitglied der Gruppe	Mitglied der SRX-Gruppe	MX Group VPNv2-Mitglied	Mitglied der Cisco Gruppe	SRX GC	SRX KS	Cisco GC/KS
  MX Group VPNv2-Mitglied	Nein	Nein	Nein	Nein	Nein	Nein
  Mitglied der SRX-Gruppe	Nein	Nein	Nein	Nein	Nein	Nein

Junos OS unterstützt nicht die Verweigerungsrichtlinie, die auf einem Cisco GC/SK-Server verwendet wird, um der Gruppenrichtlinie eine Ausnahme hinzuzufügen. Um dieses Problem zu umgehen, können Sie Firewall-Regeln für ein Gruppenmitglied der MX-Serie konfigurieren. Außerdem können Mitglieder der Junos OS-Gruppe mit der Verweigerungsrichtlinie arbeiten, indem sie die Verhandlung nicht scheitern lassen und den Inhalt einfach ignorieren. Auf diese Weise können Systemadministratoren einfach Netzwerke verwalten, in denen sowohl Cisco- als auch Junos OS-Gruppenmitglieder koexistieren.

Einschränkungen von Gruppen-VPNv2

Junos OS Group VPNv2 bietet keine Unterstützung für Folgendes:

• Multicast-Push-Nachrichten

• Multicast-Datenverkehr

• GDOI SNMP MIBs

• Protokoll und Port in den vom Server gesendeten Richtlinien. Das Gruppenmitglied berücksichtigt nur die in der Richtlinie angegebene IP-Adresse/das Subnetz.

• Mehrere nicht gekoppelte Richtlinien für denselben Datenverkehrsschlüssel/SPI

• Überlappung von lokaler und Remote-IP über Routing-Instanzen in einer IKE-Gateway-Konfiguration hinweg

• Überlappende VPNv2-Gruppenrichtlinien, die zu nicht übereinstimmenden SAs führen können

• IPv6 für Steuerung und Datenverkehr

• Koexistenz von IPsec und Gruppen-VPN auf demselben Service-Set

• Koexistenz von Services wie NAT und ALG auf demselben Service-Set. NAT und Gruppen-VPN können auf verschiedenen Servicesets nebeneinander existieren. Sie können jedoch nicht im selben Service-Set koexistieren.

• Site-to-Site (S2S) VPN und Dynamic End Point (DEP) VPN können mit Gruppen-VPN auf verschiedenen Servicesets koexistieren. Sie können jedoch nicht im selben Service-Set koexistieren.

• Mehrere Gruppen für dasselbe Serviceset

• Unterstützung von Gruppenmitgliedern mit GC/KS der SRX-Serie

• Unterstützung für Gruppenmitglieder mit SRX-Serie Gruppenmitglied

• Logische Schlüsselhierarchie (LKH)

• Eleganter Neustart

• Hohe Verfügbarkeit

• Vereinheitlichtes ISSU

• PKI-Unterstützung für die Authentifizierung