Présentation de Group VPNv2

Comprendre le VPN de groupe v2

Group VPN est un groupe de confiance qui élimine les tunnels point à point et le routage superposé associé. Tous les membres du groupe partagent une association de sécurité (SA) commune, connue sous le nom de SA de groupe (GSA). La GSA permet aux membres du groupe de déchiffrer le trafic qui a été chiffré par tout autre membre du groupe. À partir de la version 18.2R1 de Junos OS, nous confirmons la redondance VPN de groupe avec le protocole de redondance de service [SRD] exécuté sur les routeurs MX. Les routeurs MX avec une redondance entre eux agissent comme des membres de Group VPN. Pour plus de détails sur le protocole de redondance de service, consultez Vue d’ensemble du démon de redondance de service.

À partir de la version 15.1 de Junos OS, Junos OS prend en charge Group VPNv2. Group VPNv2 est une catégorie de VPN qui élimine le besoin de tunnels VPN point à point dans une architecture maillée. Il s’agit d’un ensemble de fonctionnalités nécessaires pour sécuriser le trafic unicast sur un WAN privé provenant ou transitant par un routeur.

Group VPNv2 introduit le concept de groupe de confiance pour éliminer les tunnels point à point et le routage overlay associé. Tous les membres du groupe partagent une association de sécurité (SA) commune, également connue sous le nom d’association de groupe. Cela permet aux membres du groupe de déchiffrer le trafic chiffré par tout autre membre du groupe.

Group VPNv2 offre les avantages suivants :

• Assure la sécurité et l’authentification du transport des données, ce qui permet de respecter la conformité en matière de sécurité et la réglementation interne en chiffrant l’ensemble du trafic WAN.

• Permet des maillages réseau à grande échelle et élimine la gestion complexe des clés peer-to-peer grâce aux clés de chiffrement de groupe.

• Réduit le nombre de modifications de point de terminaison qui doivent être apportées en raison d’un changement de membre du groupe ou de stratégie.

• Gère l’intelligence du réseau, comme la connectivité full-mesh, le chemin de routage naturel et la qualité de service (QoS) dans les réseaux MPLS.

• Accorde un contrôle d’appartenance authentifié avec un serveur de clés centralisé.

• Permet le chiffrement et le déchiffrement du trafic entre tous les membres du groupe définis dans la stratégie de groupe.

• Contribue à minimiser la latence et la gigue en permettant des communications directes et permanentes entre les sites, sans avoir besoin d’être transportées via un hub central.

• Réduit la charge de trafic sur les équipements CPE (Customer Premises Equipment) et les dispositifs de chiffrement PE (Provider Edge) en utilisant le réseau central pour la réplication du trafic, évitant ainsi la réplication des paquets sur chaque site pair.

VPN de groupe VPNv2 et VPN IPsec standard

Group VPNv2 est construit sur des technologies basées sur des normes qui intègrent le routage et le chiffrement dans le réseau. Une SA de sécurité IPsec est un accord unidirectionnel entre les participants au VPN qui définit les règles à utiliser pour les algorithmes d’authentification et de chiffrement, les mécanismes d’échange de clés et les communications sécurisées.

Les déploiements VPN IPsec traditionnels s’attaquent au problème de la sécurisation du trafic entre les passerelles du réseau en créant un réseau overlay basé sur l’utilisation de tunnels point à point. Le trafic acheminé sur ces tunnels est normalement chiffré et authentifié afin de garantir l’intégrité et la confidentialité des données. Les membres sécurisés du groupe sont gérés via le protocole Group Domain of Interpretation (GDOI). La solution GDOI adopte une approche différente en dissociant le problème de cryptage et d’authentification du transport. Ainsi, les solutions basées sur GDOI permettent de chiffrer les communications entre sites distants sans qu’il soit nécessaire de configurer des tunnels entre sites.

Avec les implémentations VPN actuelles, l’architecture SA est un tunnel point à point entre deux points de terminaison. Group VPNv2 étend l’architecture IPsec pour prendre en charge les SA partagées par un groupe de routeurs (voir Figure 1). Un serveur de clés distribue les clés et les stratégies à tous les routeurs membres enregistrés et authentifiés. La distribution des stratégies à partir d’un point centralisé et le partage de la même association de sécurité de groupe (l’ensemble du groupe dispose d’une seule SA de phase 2) avec des membres authentifiés du groupe simplifient considérablement la distribution et la gestion des clés.

Group VPNv2 est une architecture client/serveur. Tous les membres disposent d’une SA IKE de phase 1 unique avec le serveur de clés. Par conséquent, s’il y a n des membres, il y a un total d’AS n IKE de phase 1. Cependant, l’ensemble du groupe partage une seule AS de phase 2.

Dans IPsec traditionnel, les adresses de point de terminaison de tunnel sont utilisées comme nouvelle source et destination de paquet. Le paquet est ensuite acheminé sur l’infrastructure IP, en utilisant l’adresse IP source du point de terminaison de chiffrement et l’adresse IP de destination du point de terminaison de déchiffrement. Dans le cas d’un VPN de groupe, les paquets de données protégés par IPsec conservent les adresses source et de destination d’origine de l’hôte dans l’en-tête IP externe afin de préserver l’adresse IP. C’est ce qu’on appelle la préservation des en-têtes de tunnel. L’avantage principal de la préservation des en-têtes de tunnel est la possibilité d’acheminer des paquets chiffrés à l’aide de l’infrastructure de routage réseau sous-jacente.

Comprendre le protocole GDOI

Le protocole GDOI (Group Domain of Interpretation) décrit dans la norme RFC 6407 est utilisé pour distribuer un ensemble de clés et de stratégies cryptographiques à un groupe d’équipements. GDOI est défini comme le domaine d’interprétation (DOI) ISAKMP (Internet Sécurité Association Key Management Protocol) pour la gestion des clés de groupe. Dans un modèle de gestion de groupe, le protocole GDOI opère entre un membre du groupe et un contrôleur de groupe ou un serveur de clés (GC/KS) et gère les associations de sécurité de groupe et les clés de groupe pour un ensemble de participants à la sécurité. L’ISAKMP définit deux phases de négociation. GDOI est un protocole de phase 2 protégé par une association de sécurité ISAKMP de phase 1. IKEv1 est spécifié dans la RFC 6407 en tant que protocole de phase 1.

GDOI introduit deux clés de chiffrement différentes :

• Clé de chiffrement de clé (KEK) : utilisée pour sécuriser le plan de contrôle. KEK est le nom de la clé utilisée par les membres du groupe pour déchiffrer les messages de changement de clé du GC/KS. Cette clé fait partie de la clé de chiffrement de clé de la Sécurité Association (SAK).

• Clé de chiffrement du trafic (TEK) : utilisée pour sécuriser le plan de données. TEK est le nom de la clé utilisée par les membres du groupe pour chiffrer ou déchiffrer la communication entre les autres membres du groupe. Cette clé fait partie de la clé de chiffrement de transport de la Sécurité Association (SA TEK).

Comme pour IPsec standard, toutes les clés ont une durée de vie et doivent être redéfinies. Les clés distribuées via GDOI sont des clés de groupe et sont utilisées par l’ensemble du groupe.

Les SA de groupe et la gestion des clés sont gérées par deux types d’échanges GDOI :

• groupkey-pull: cet échange permet à un membre de demander au serveur des SA et des clés partagées par le groupe.

  Dans la méthode pull, le membre du groupe demande la SA et la stratégie du groupe au serveur de clés. Cette requête est protégée par l’AS IKE.

  Il groupkey-pull s’agit du premier échange dans le protocole GDOI et est utilisé pour l’enregistrement des membres du groupe auprès du GC/KS. Le membre du groupe spécifie le groupe auprès duquel il souhaite s’inscrire, et le GC/KS envoie toutes les SA et clés de groupe nécessaires au membre du groupe si le membre est autorisé à rejoindre le groupe. L’échange complet est sécurisé par une SA de phase 1 (IKEv1 SA), qui est établie avec IKEv1 avant le début de l’échange groupkey-pull . Le groupkey-pull fait partie de la phase 2 du protocole GDOI.

• groupkey-push: cet échange est un message de changement de clé unique qui permet au serveur d’envoyer des SA de groupe et des clés aux membres avant l’expiration des SA de groupe existantes. Les messages de recléage sont des messages non sollicités envoyés par le serveur aux membres.

  Il groupkey-push s’agit du deuxième échange dans le protocole GDOI et est initié par le GC/KS à tous les membres enregistrés du groupe. Le Tableau 2 indique les charges utiles que le membre du groupe MX Series s’attend à recevoir dans groupkey-push les messages.

  Tableau 2 : charges utiles de message groupkey-push

  charge utile	Descriptif
  Stratégie associée aux groupes (GAP)	Une charge utile GAP permet de distribuer des stratégies à l’échelle du groupe, telles que des instructions sur le moment d’activer et de désactiver les SA. Cette charge utile contient des valeurs pour les délais d’activation (ATD) et de désactivation (DTD) pour la clé de chiffrement du trafic (TEK), ainsi que le type de fenêtre et la taille de fenêtre du protocole de détection différée de livraison IP pour le trafic IPsec.
  Clé de chiffrement de transport de la Sécurité Association (SA TEK)	Sélecteurs de trafic.
  Clé de chiffrement de la clé de l’association de sécurité (SAK) (facultatif)	L’association de sécurité (SA) pour la clé de chiffrement de clé (KEK). Aussi connu sous le nom de SA KEK. Remarque : groupkey-push Les messages qui n’incluent pas les charges utiles facultatives sont toujours valides.
  Clé de chiffrement du trafic (TEK) (facultative)	Clé pour chiffrer le trafic de données entre les membres du groupe.
  clé de chiffrement de clé (KEK) (facultatif)	Utilisé pour protéger le TEK.

  L’échange groupkey-push est sécurisé par une SA KEK (SAK), qui est installée pendant l’échange groupkey-pull . Le groupkey-push fait partie de la phase 2 du protocole GDOI.

Dans certains cas, le GC/KS peut souhaiter recevoir des messages d’accusé de réception de clés de groupe de la part des membres du groupe. Les messages d’accusé de réception des membres du groupe confirment que le membre a reçu le message et a pris des mesures en fonction de sa stratégie. Le GC/KS peut également utiliser l’accusé de réception pour déterminer quels membres du groupe reçoivent la politique de groupe actuelle et quels membres du groupe ne participent plus au groupe. À partir de Junos OS 19.2R1, Junos OS envoie un message d’accusé de réception avec une somme de contrôle SHA-256 lorsqu’il reçoit un message Push groupkey avec une valeur KEK_ACK_REQUESTED standard de 9 dans la charge utile KEK SA telle que définie dans RFC 8263 ou une valeur KEK_ACK_REQUESTED de 129 utilisée pour les serveurs de clés plus anciens.

Protocole GDOI et VPN de groupe v2

Group VPNv2 est le nom de la technologie de sécurité mise en œuvre sur les plates-formes de routeur de Juniper Networks. Group VPNv2 utilise le protocole GDOI (RFC 6407) comme base, en plus d’autres fonctionnalités.

La technologie Group VPNv2 est basée sur le protocole GDOI pour gérer les fonctionnalités les plus importantes. Ce protocole est spécifié dans la norme RFC 6407 et définit un domaine d’interprétation (DOI) ISAKMP pour gérer les SA et les clés de groupe pour un groupe d’acteurs de la sécurité. Ainsi, tous les membres du groupe partagent les mêmes informations pour chiffrer et déchiffrer le trafic entre eux. La création, la gestion et la distribution des SA de groupe et des clés de groupe sont centralisées et effectuées par le GC/KS. La figure 2 donne un bref aperçu de la fonctionnalité Group VPNv2 à l’aide de GDOI.

Figure 2 : VPN de groupe v2 utilisant GDOI

Les membres du groupe utilisent le protocole ESP (Encapsulating Security charge utile) en mode tunnel pour sécuriser le trafic. Cependant, dans Group VPN, le mode de tunnel est modifié. Comme il n’y a pas d’association directe entre les membres du groupe, il n’est pas nécessaire d’utiliser des adresses IP spéciales dans l’en-tête IP externe (c’est-à-dire les adresses IP des passerelles IPsec). Chaque membre du groupe peut déchiffrer le trafic de tous les autres membres du groupe. Ainsi, l’en-tête IP interne est copié dans l’en-tête IP externe, et l’infrastructure de routage sous-jacente et l’infrastructure de QoS peuvent être utilisées. Cette fonctionnalité est appelée Header Preservation et est illustrée à la figure 3.

Figure 3 : Conservation des en-têtes

Pour obtenir des SA de groupe et des clés de groupe, le membre du groupe doit s’inscrire auprès du GC/KS d’un groupe spécifique. Le résultat est une SA IKEv1, qui n’est nécessaire que pour sécuriser le processus d’enregistrement. Après l’enregistrement, le membre du groupe dispose de toutes les informations nécessaires pour communiquer avec les autres membres du groupe (SA TEK), ainsi que des informations pour déchiffrer avec succès les messages de changement de clé (SAK). Le GC/KS envoie des messages de renouvellement de clé avant l’expiration de la durée de vie SA TEK ou SAK. Il est également possible d’envoyer une mise à jour SA TEK ainsi qu’une mise à jour SAK dans le même message de reclé. La SA IKEv1 n’est plus nécessaire et est supprimée après l’expiration de la durée de vie (pas de nouvelle saisie IKEv1).

Trafic VPN v2 de groupe

Le trafic VPNv2 de groupe comprend :

• Control-plane-traffic : trafic des membres du groupe vers le GC/KS dans le déploiement VPN de groupe v2 avec le protocole GDOI uniquement.

• Data-plane-traffic : trafic entre les membres du groupe dans le déploiement VPN de groupe v2 avec le protocole ESP uniquement, déjà connu d’IPsec.

Association de la sécurité du groupe

Contrairement aux solutions de chiffrement IPsec traditionnelles, Group VPN utilise le concept d’association de sécurité de groupe. Un SA de groupe est similaire à un SA en termes de fonctionnalités. Les CS de groupe sont partagés entre tous les membres d’un groupe GDOI commun. Tous les membres du groupe VPN de groupe peuvent communiquer entre eux en utilisant une politique de cryptage commune et une SA de groupe partagée. Avec une politique de chiffrement commune et une SA de groupe partagée, il n’est pas nécessaire de négocier IPsec entre les membres du groupe. Cela réduit la charge de ressources sur les membres du groupe. Les problèmes d’évolutivité IPsec traditionnels (nombre de tunnels et de SA associées) ne s’appliquent pas aux membres d’un groupe VPN de groupe.

Contrôleur de groupe/serveur de clés

Un contrôleur de groupe ou serveur de clés (GC/KS) est un dispositif utilisé pour créer et maintenir le plan de contrôle VPN de groupe v2. Il est responsable de la création et de la distribution des SA de groupe et des clés de groupe. Toutes les informations dont les membres du groupe ont besoin pour communiquer avec les autres membres du groupe sont fournies par le GC/KS. Toutes les politiques de chiffrement, telles que le trafic intéressant, les protocoles de chiffrement, l’association de sécurité, les minuteries de changement de clé, etc., sont définies de manière centralisée sur le GC/KS et sont transmises à tous les membres du groupe au moment de l’inscription. Les membres du groupe s’authentifient auprès du GC/KS à l’aide d’IKE Phase 1, puis téléchargent les stratégies de chiffrement et les clés requises pour le fonctionnement du VPN de groupe. Le GC/KS est également responsable de l’actualisation et de la distribution des clés.

Membre du groupe

Un membre du groupe est un terminal IPsec utilisé pour le processus de chiffrement du trafic et est responsable du chiffrement et du déchiffrement du trafic de données. Un membre du groupe est configuré avec les paramètres de phase 1 d’IKE et les informations GC/KS. Les politiques de cryptage sont définies de manière centralisée sur le GC/KS et téléchargées sur le membre du groupe au moment de l’inscription réussie. Chaque membre du groupe détermine ensuite si le trafic entrant et sortant doit être déchiffré ou chiffré (à l’aide de sa SA) en fonction de son appartenance au groupe.

D’un point de vue fonctionnel, un membre du groupe est similaire à une passerelle IPsec. Toutefois, les SA dans IPsec normal existent entre deux passerelles IPsec. Dans GDOI, le membre du groupe s’inscrit auprès du GC/KS afin de participer au VPN de groupe. Lors de l’inscription, le membre du groupe fournit l’ID de groupe au GC/KS pour obtenir les stratégies, les SA et les clés respectives nécessaires pour ce groupe. La ressaisie est effectuée par les membres du groupe par la groupkey-pull méthode (réenregistrement) ou par le GC/KS par la groupkey-push méthode.

Protection anti-rejeu du trafic VPNv2 de groupe

Étant donné que la communication VPN de groupe est essentiellement une communication any-to-any sur la même association de sécurité partagée, l’utilisation de numéros de séquence pour la protection anti-rejeu ne fonctionne pas. Pour cette raison, Junos OS prend en charge un projet de spécification IETF pour un mécanisme anti-rejeu basé sur le temps, draft-weis-delay-detection-01. Il est disponible à http://tools.ietf.org/html/draft-weis-delay-detection-01 .

Pour implémenter cette fonctionnalité, les routeurs membres de la gamme MX Series utilisent un nouvel en-tête d’horodatage IP Delivery Delay Detection Protocol dans le paquet. Voir Implémentation du protocole de détection de retard de livraison IP (protection anti-rejeu basée sur le temps) pour plus de détails.

Basculement partiel sur les routeurs membres de la gamme MX Series

Les membres d’un groupe VPN de groupe s’appuient sur le GC/KS pour générer des éléments de clé pour la SA partagée. Par conséquent, la connectivité entre les membres du groupe et les GC/KS est nécessaire pour protéger initialement le trafic et pour protéger continuellement le trafic en cas d’événements de changement de clé. En cas d’échec de communication entre le membre du groupe et le GC/KS, le comportement par défaut des membres du groupe est d’arrêter le transfert de trafic. C’est ce qu’on appelle la fermeture par défaut.

Une option de configuration différente par défaut est disponible pour permettre à un trafic spécifiquement défini de circuler à travers le membre du groupe sans être chiffré jusqu’à ce que le membre soit en mesure de contacter le GC/KS et de récupérer l’ASA active. C’est ce qu’on appelle l’ouverture partielle.

La fonctionnalité d’ouverture partielle nécessite une option de configuration de stratégie qui crée une règle sur le membre du groupe MX Series applicable pour un groupe VPNv2 particulier défini par les adresses source et de destination. Cette règle d’ouverture faille n’est active que lorsque la SA de groupe est à l’état désactivé en raison d’un échec de connectivité avec le serveur de clés. Le trafic qui devrait normalement passer par le VPN de groupe mais qui ne correspond pas à la règle d’ouverture faille est abandonné. Plusieurs règles d’ouverture de faille peuvent être définies pour l’objet Group VPN. Si aucune règle d’ouverture faille n’est configurée, la fonctionnalité d’ouverture faille est désactivée.

Activation de Group VPNv2

Un ensemble de services est utilisé pour activer Group VPNv2 sur une interface particulière sur les routeurs MX Series applicables.

[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;
        }
    }
}

Enregistrement d’un membre du groupe

L’inscription des membres du groupe sur le serveur commence lorsque l’instruction ipsec-group-vpn est configurée pour un ensemble de services et que l’interface de service est active. Lorsque l’interface de service tombe en panne, toutes les SA de groupe associées à cette interface sont effacées et aucune inscription n’est déclenchée pour ces VPN de groupe tant que l’interface n’est pas activée.

L’enregistrement des membres du groupe implique l’établissement d’une SA IKE avec le GC/KS, suivie d’un groupkey-pull échange pour télécharger les SA et les clés de trafic pour l’identifiant de groupe spécifié.

Redéfinition des clés d’un membre du groupe (méthode groupkey-push)

Le GC/KS enverra un message unicast groupkey-push aux membres enregistrés du groupe afin de :

• Envoyez de nouvelles clés de chiffrement de clé (KEK) ou clés de chiffrement de trafic (TEK).

  Les messages push peuvent contenir tout ou partie seulement des éléments de charge utile indiqués dans le tableau 2. Lorsque la charge utile GAP contient à la fois d’anciennes SA et de nouvelles SA de remplacement, le routeur membre du groupe appliquera les valeurs ATD et DTD comme une nouvelle clé normale au moyen de push. S’il n’y a pas de valeur ATD dans la mise à jour, le routeur membre installe immédiatement les nouvelles SA. S’il n’y a pas de valeur DTD, les anciennes SA resteront en place jusqu’à leur expiration.

• Mettre à jour la stratégie associée au groupe (GAP) pour une SA existante.

  Un GC/KS peut envoyer un message push unicast pour mettre à jour la configuration des membres du groupe à tout moment. La charge utile GAP peut inclure des modifications de configuration du protocole IP Delivery Delay Detection, de l’algorithme de chiffrement, de la durée de vie, etc. La configuration mise à jour est appliquée immédiatement ou avec un délai. Les valeurs ATD et DTD sont utilisées pour obtenir le moment de l’activation de la nouvelle CET et de la suppression de la CET existante, respectivement. Si la durée de vie TEK existante doit être réduite, la valeur DTD est définie en conséquence dans le message push. Le nouveau TEK dans le message push est activé en fonction de la valeur ATD dans la charge utile.

• Envoyez des notifications de suppression de clé pour TEK ou KEK.

  Le GC/KS peut envoyer la charge utile de notification de suppression facultative dans le message push pour la suppression des clés et des SA sur le membre. Le message push contient l’ID de protocole qui indique si la notification de suppression concerne TEK ou KEK. Le routeur membre du groupe supprime la clé en fonction de l’ID de groupe et de la valeur SPI contenus dans la charge utile. La suppression d’un TEK ou d’une KEK spécifique peut être effectuée avec une valeur de retard spécifiée dans l’attribut DTD. Si la valeur de retard est égale à 0 et que la charge utile contient un SPI spécifique, le TEK ou la KEK correspondant est immédiatement supprimé. Si toutes les TEK ou KEK (ou les deux) doivent être supprimées du groupe, la valeur SPI est définie sur 0 pour l’ID de protocole correspondant dans la charge utile.

• Supprimez un routeur membre du VPN de groupe dans Group VPNv2.

  Les messages push sont utilisés pour permettre au GC/KS de supprimer des membres du VPN de groupe. Dans un cas, le GC/KS envoie un message de changement de clé avec uniquement les anciennes SA et une valeur DTD plus petite. Le routeur membre du groupe installe la nouvelle valeur DTD plus petite. Comme il n’a pas reçu de nouvelles clés SA, le routeur membre tente de se réinscrire à l’aide de la groupkey-pull méthode. Cette tentative de réinscription est rejetée par le GC/KS, supprimant ainsi le membre du VPN du groupe. Dans le second cas, le GC/KS envoie une charge utile de suppression pour le SPI de l’ancienne SA. Le routeur membre du groupe supprime immédiatement la SA et tente de se réinscrire à l’aide de la groupkey-pull méthode. Cette tentative de réinscription est rejetée par le GC/KS, supprimant ainsi le membre du VPN du groupe.

Les membres enregistrés du groupe MX Series renvoient un message PUSH ACK unicast au GC/KS pour accuser réception du message push d’origine.

Redéfinition des clés d’un membre du groupe (méthode groupkey-pull)

Pour la nouvelle saisie des membres du groupe, en utilisant cette groupkey-pull méthode, les membres du groupe se réenregistrent généralement auprès du GC/KS lorsqu’il reste entre 7 % et 5 % dans la durée de vie logicielle TEK ou KEK existante. Si la SA IKE existante est disponible, elle est utilisée dans le message d’extraction. Une fois que le GC/KS a répondu avec une nouvelle clé, l’ancienne clé et la nouvelle clé peuvent être utilisées pour le déchiffrement. Toutefois, la nouvelle clé n’est pas utilisée pour le chiffrement tant qu’il ne reste que 30 secondes de durée de vie de l’ancienne clé. Si la SA IKE existante n’est pas disponible, le message pull entraîne de nouvelles négociations IKE entre le membre du groupe et le GC/KS.

À la réception du message d’extraction concernant un VPN de groupe spécifique de la part du membre du groupe, le GC/KS répond avec tous les TEK et la KEK de ce groupe.

Si une SA existante n’est pas incluse dans la réponse du GC/KS, les SA manquantes sont supprimées par le membre du groupe.

Par exemple, le GC/KS est configuré avec une durée de vie de 3600 secondes et est connecté à un membre du groupe sans retransmission. En fonction de la configuration du serveur, le GC/KS génère une nouvelle clé lorsqu’il reste 10 % de la durée de vie. Le membre du groupe, cependant, se réinscrit auprès du GC/KS lorsqu’il reste 5 à 7 % de la vie.

La figure 4 représente le processus de renouvellement des clés entre le GC/KS et le membre du groupe.

Figure 4 : Nouvelle saisie des membres du groupe

Authentification d’un membre du groupe

Junos OS ne prend pas en charge l’infrastructure à clé publique (PKI) pour les VPN de groupe dans Group VPNv2. Par conséquent, des clés pré-partagées sont utilisées pour l’authentification des membres du groupe.

Fragmentation du trafic VPNv2 de groupe

En raison de la fonctionnalité de conservation des en-têtes et de l’utilisation de l’infrastructure de routage sous-jacente, il est nécessaire de fragmenter les paquets avant le chiffrement (s’il est impossible de l’empêcher).

Par conséquent, la pré-fragmentation est prise en charge et est recommandée pour tous les déploiements.

Pour éviter la post-fragmentation, définissez les clearoptions , setet pour copy le bit DF dans la configuration de Group VPNv2.

En fonction de ce paramètre d’indicateur, l’en-tête IPsec a soit la valeur , clearsetsoit copy le df-bit paquet interne.

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

Chiffrement du trafic VPNv2 de groupe

Les membres du groupe chiffrent le trafic en fonction des SA de groupe et des clés fournies par le GC/KS. Le chemin de chiffrement de Group VPNv2 est le suivant :

1. Le paquet reçu par le moteur de transfert de paquets est vérifié par rapport à une correspondance de flux. Si une correspondance est trouvée, le paquet est traité et transmis.

2. Si aucune correspondance n’est trouvée, une recherche de règle est effectuée. Si une correspondance est trouvée, un flux est créé et le paquet est traité et transmis.

3. Si la recherche de la règle échoue, le paquet est abandonné.

Déchiffrement du trafic VPNv2 de groupe

Une fois l’inscription réussie et l’installation des SA VPN de groupe, une session ESP est créée. Group VPNv2 crée la session ESP avec une IP source et une adresse IP de destination nulles. Étant donné que la session ESP est déjà créée lors de l’installation de la SA, les paquets doivent correspondre à la session ESP existante.

Le chemin de déchiffrement de Group VPNv2 est le suivant :

1. Le paquet reçu par le moteur de transfert de paquets fait l’objet d’un contrôle de fragmentation. Si le paquet est fragmenté, il est assemblé pour un traitement ultérieur.

2. Après l’assemblage des paquets ou si le paquet n’est pas fragmenté, une adresse IP source et une adresse IP de destination nulles sont utilisées dans la recherche de flux de déchiffrement à 5 uplets. Si une correspondance est trouvée, le paquet est traité et transmis.

3. Si la recherche de flux de déchiffrement échoue, le paquet est vérifié par rapport à un flux SPI sans IP source et de destination.

4. Si la recherche de flux SPI échoue, le paquet est abandonné.

5. Si une correspondance de flux SPI est trouvée, un flux de déchiffrement est créé pour éviter la recherche de flux SPI pour les paquets suivants.

Configuration d’une instance de routage pour un groupe VPNv2

Les instances de routage sont prises en charge pour le trafic de contrôle et de données. Pour activer la prise en charge des instances de routage sur le trafic du plan de contrôle pour qu’un membre du groupe atteigne le GC/KS dans une instance de routage VRF donnée, ajoutez l’instruction routing-instance au niveau de la [edit security group-vpn member ike gateway gateway-name local-address address] hiérarchie.

Aucune CLI supplémentaire n’est requise pour prendre en charge une instance de routage pour les paquets de plan de données, car elle est déterminée en fonction de l’interface multimédia sur laquelle l’ensemble de services est appliqué.

Établissement de plusieurs groupes, stratégies et SA

Junos OS prend en charge un VPN de groupe par service défini dans VPN de groupe v2. Toutefois, plusieurs ensembles de services peuvent être créés pour prendre en charge plusieurs groupes dans une instance de routage. Plusieurs SA peuvent être configurées par groupe. Cependant, plusieurs stratégies pour la même clé de trafic/SPI ne sont pas prises en charge. Si le serveur envoie deux politiques pour le même TEK, elles doivent être appariées pour être acceptées, par exemple, A-B et B-A, où A et B sont des adresses IP ou des sous-réseaux. Si plusieurs stratégies non appariées sont reçues pour un TEK donné, l’enregistrement échoue et un message de journal système est généré.

Connexion avec plusieurs GC/KS coopératifs

Pour qu’un membre du groupe puisse travailler avec un GC/KS en mode coopératif, la configuration est étendue pour autoriser un maximum de quatre serveurs dans la liste des serveurs.

Lors de la nouvelle saisie lors de l’utilisation de la groupkey-pull méthode, le membre du groupe tente de se connecter au GC/KS. Lorsque la connexion au GC/KS échoue, le membre du groupe tente de se reconnecter au GC/KS. Après trois nouvelles tentatives avec un intervalle de 10 secondes, si la connexion au GC/KS n’est pas rétablie, le membre du groupe tente d’établir une connexion avec le prochain serveur disponible sur la liste des serveurs. Ce processus est répété jusqu’à ce que le membre du groupe se connecte à un GC/KS. Pendant ce temps, les SA GDOI non expirées sur les membres du groupe ne sont pas nettoyées, de sorte que le trafic VPN du groupe n’est pas affecté. L’intervalle de temps entre la modification de la clé et l’expiration de la durée de vie matérielle laisse suffisamment de temps aux membres du groupe pour se connecter au prochain serveur disponible, dans ce cas.

Implémentation du protocole de détection de retard de livraison IP (protection anti-rejeu basée sur le temps)

Aucune configuration n’est nécessaire pour implémenter le protocole IP Delivery Delay Detection. Les membres du groupe MX Series obtiennent la taille de la fenêtre de relecture à utiliser dans le cadre de la charge utile GAP dans les messages push ou pull du serveur de clés. Si la taille de la fenêtre reçue est de 0, la protection anti-rejeu basée sur le temps est désactivée.

Si le protocole IP Delivery Delay Detection Protocol est activé, l’expéditeur ajoute son horodatage actuel et chiffre le paquet. Le destinataire déchiffre le paquet et compare son heure actuelle avec l’horodatage du paquet. Les paquets qui se trouvent en dehors de la taille de la fenêtre sont perdus. Pour cette raison, tous les membres du groupe doivent avoir leurs horloges synchronisées à l’aide du protocole NTP (Network Time Protocol).

Protocole de détection du retard de livraison IP Les temps sont mesurés en secondes. Pour plus d’informations, consultez IP Delivery Delay Detection Protocol-draft-weis-delay-detection-01 .

Modification de la configuration VPNv2 de groupe

La plupart des modifications apportées à la configuration de Group VPNv2 entraînent la suppression des SA existantes et la réinscription. Cela déclenche à la fois la phase 1 et le téléchargement SA avec de nouvelles clés de trafic.

Contournement de la configuration VPNv2 de groupe

Si certains trafics, comme un protocole de routage, doivent contourner un VPN de groupe dans le groupe VPNv2, un filtre de service doit être configuré sur l’interface sur laquelle l’ensemble de services est appliqué. Les paquets correspondant au filtre de service ne parviennent pas au PIC pour être traités et sont directement transférés au moteur de routage.

[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;
                }
            }
        }
    }
}

Implémentation de l’ouverture partielle en cas de panne sur les routeurs membres de la gamme MX Series

Par défaut, les paquets sont abandonnés si un routeur membre du groupe ne peut pas obtenir de SA à partir du GC/KS en raison d’une perte de connectivité. Si vous souhaitez autoriser le passage d’une partie du trafic non chiffré en cas d’échec de communication entre le membre du groupe et le GC/KS, vous devez configurer une fail-open règle au niveau de la hiérarchie [edit security group-vpn member ipsec vpn vpn-name ].

Les règles d’ouverture faille ne seront appliquées au trafic qu’en cas de perte de connectivité du serveur. Les règles d’ouverture en cas de faille seront désactivées une fois la connectivité rétablie et les clés reçues du GC/KS.

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

Un maximum de 10 règles d’ouverture de faille peut être configuré pour un groupe donné.

Paramètres IPsec GDOI pris en charge

Chaque groupe GDOI a un ID unique. Il est utilisé comme base commune entre GC/KS et le membre du groupe pour communiquer sur les SA de groupe et les clés de groupe.

Au cours du processus d’inscription, le GC/KS envoie des clés de chiffrement de transport de l’association de sécurité (SA TEK) aux membres du groupe. Tous les paramètres concernant l’ensemble de la politique de sécurité du groupe sont configurés sur le GC/KS. Le ZEC SA est utilisé par les membres du groupe pour protéger le trafic échangé entre eux. Le Tableau 3 présente les paramètres de la CET SA.

Outre les algorithmes cryptographiques, le trafic, qui doit être chiffré par les membres du groupe, fait partie de la politique SA TEK (sélecteur de trafic).

Les instructions suivantes peuvent être utilisées sur un membre du groupe Juniper Networks. Ainsi, les adresses doivent être spécifiées au niveau de la hiérarchie IKE. L’énumération est également prioritaire. Ainsi, dans l’exemple de configuration suivant, KS1 est contacté avant KS2.

[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;
            }
        }
    }
}

Paramètres GDOI IKEv1 pris en charge

Les normes IKEv1 mentionnées ci-dessus sont configurées comme suit :

Application de stratégies dynamiques

Les input options et output sous l’instruction ipsec-group-vpn spécifient si les stratégies dynamiques reçues du serveur sont utilisées lorsque l’interface sur laquelle l’ensemble de services est appliqué est l’interface entrante ou sortante. Cela offre la flexibilité de spécifier des règles différentes dans les directions entrante et sortante.

Prise en charge de TOS et DSCP

Les bits de type de service (TOS) et de points de code DiffServ (DSCP) sont copiés du paquet interne vers le paquet ESP.

Interopérabilité des membres du groupe

L’implémentation de GDOI par Cisco s’appelle Group Encryption Transport (GET) VPN. Bien que Group VPNv2 de Junos OS et GET VPN de Cisco soient tous deux basés sur RFC 6407, The Group Domain of Interpretation, vous devez tenir compte de certaines différences d'implémentation lorsque vous déployez GDOI dans un environnement réseau qui comprend à la fois des équipements de sécurité et de routage Juniper Networks et des routeurs Cisco. Pour plus d’informations, reportez-vous aux notes de mise à jour actuelles de Junos OS.

L’interopérabilité de Group VPNv2 est la suivante :

• Junos OS prend en charge l’interopérabilité avec Cisco iOS GC/KS.

• Junos OS ne prend pas en charge l’interopérabilité Group VPNv2 avec le serveur VPN de groupe SRX Series.

  Tableau 5 : Interopérabilité VPNv2 de groupe

  Membre du groupe	Membre du groupe SRX	Membre VPNv2 de MX Group	Membre du groupe Cisco	SRX GC	SRX KS	Cisco GC/KS
  Membre VPNv2 de MX Group	Non	Oui	Oui	Non	Oui	Oui
  Membre du groupe SRX	Oui	Non	Non	Oui	Oui	Oui

Junos OS ne prend pas en charge la stratégie de refus utilisée sur un serveur Cisco GC/SK pour ajouter une exception à la stratégie de groupe. Pour contourner ce problème, vous pouvez configurer des règles de pare-feu sur un membre du groupe MX Series. De plus, les membres du groupe Junos OS peuvent utiliser la politique de refus en n’échouant pas lors de la négociation et en ignorant simplement le contenu. Les administrateurs système peuvent ainsi gérer facilement les réseaux dans lesquels cohabitent des membres du groupe Cisco et Junos OS.

Limites de Group VPNv2

Junos OS Group VPNv2 ne prend pas en charge les éléments suivants :

• Messages push multicast

• Trafic multicast

• MIB SNMP GDOI

• Protocole et port dans les politiques envoyées par le serveur. Le membre du groupe ne respecte que l’adresse IP/le sous-réseau spécifié dans la stratégie.

• Plusieurs stratégies non appariées pour la même clé de trafic/SPI

• Chevauchement d’adresses IP locales et distantes entre les instances de routage dans une configuration de passerelle IKE

• Chevauchement des politiques VPNv2 de groupe pouvant entraîner des incompatibilités des SA

• IPv6 pour le contrôle et le trafic des données

• Coexistence d’IPsec et de Group VPN sur le même ensemble de services

• Coexistence de services tels que NAT et ALG sur le même ensemble de services. Le NAT et le VPN de groupe peuvent coexister sur différents ensembles de services. Cependant, ils ne peuvent pas coexister sur le même ensemble de services.

• Le VPN S2S (Site To Site) et le VPN DEP (Dynamic End Point) peuvent coexister avec Group VPN sur différents ensembles de services. Cependant, ils ne peuvent pas coexister sur le même ensemble de services.

• Plusieurs groupes sur le même ensemble de services

• Prise en charge des membres du groupe avec GC/KS SRX Series

• Prise en charge des membres du groupe avec membre du groupe SRX Series

• Hiérarchie de clés logiques (LKH)

• Redémarrage en douceur

• Haute disponibilité

• ISSU unifié

• Prise en charge de l’authentification par PKI