IKE pour VPN IPsec

Traitement des paquets IKE

Lorsqu’un paquet en texte clair arrive sur un équipement Juniper Networks nécessitant une tunnelisation, et qu’il n’existe pas de SA de phase 2 active pour ce tunnel, Junos OS entame les négociations IKE et abandonne le paquet. Les adresses source et de destination dans l’en-tête du paquet IP sont celles des passerelles IKE locales et distantes, respectivement. Dans la charge utile du paquet IP, il existe un segment UDP encapsulant un paquet ISAKMP (IKE). Le format des paquets IKE est le même pour la phase 1 et la phase 2. Voir Figure 1.

Pendant ce temps, l’hôte source a de nouveau envoyé le paquet abandonné. En règle générale, au moment où le deuxième paquet arrive, les négociations IKE sont terminées et Junos OS protège le paquet et tous les paquets suivants de la session, avec IPsec avant de le transférer.

Le champ Charge utile suivante contient un nombre indiquant l’un des types de charge utile suivants :

• 0002—Négociation de l’AS La charge utile contient une définition pour un SA de phase 1 ou de phase 2.

• 0004 : la charge utile de proposition peut être une proposition de phase 1 ou de phase 2.

• 0008—La charge utile de transformation est encapsulée dans une charge utile de proposition qui est encapsulée dans une charge utile SA.

• 0010 : échange de clés (KE) La charge utile contient les informations nécessaires à l’exécution d’un échange de clés, telles qu’une valeur publique DH.

• 0020—Identification (IDx) de la charge utile.

  • Dans la phase 1, IDii indique l’ID de l’initiateur et IDir indique l’ID du répondeur.

  • Dans la phase 2, IDui indique l’initiateur de l’utilisateur et IDur indique l’utilisateur qui répond.

  Les ID sont IKE types d’ID tels que FQDN, U-FQDN, adresse IP et ASN.1_DN.

• 0040 : charge utile de certificat (CERT).

• 0080—Demande de certificat (CERT_REQ) charge utile.

• 0100—Hachage (HASH) La charge utile contient la sortie de synthèse d’une fonction de hachage particulière.

• 0200—Signature (SIG) La charge utile contient une signature numérique.

• 0400—La charge utile Nonce (Nx) contient des informations pseudo-aléatoires nécessaires à l’échange).

• 0800 : notifier la charge utile.

• 1000—ISAKMP Supprimer la charge utile.

• 2000 : ID du fournisseur (VID) La charge utile peut être incluse n’importe où dans les négociations de phase 1. Junos OS l’utilise pour marquer la prise en charge de NAT-T.

Chaque charge utile ISAKMP commence par le même en-tête générique, comme illustré sur la Figure 2.

Il peut y avoir plusieurs charges utiles ISAKMP enchaînées, chaque type de charge utile suivant étant indiqué par la valeur dans le champ En-tête suivant. La valeur de 0000 indique la dernière charge utile ISAKMP. Voir la figure 3 pour un exemple.

Traitement IPsec des paquets

Une fois les négociations IKE terminées et les deux passerelles IKE ayant établi des SA de phase 1 et de phase 2, tous les paquets suivants sont transférés à l’aide du tunnel. Si la SA de phase 2 spécifie le protocole ESP (Encapsulating Security Protocol) en mode tunnel, le paquet ressemble à celui illustré à la Figure 4. Le périphérique ajoute deux en-têtes supplémentaires au paquet d’origine envoyé par l’hôte initiateur.

Comme illustré sur la Figure 4, le paquet créé par l’hôte initiateur comprend la charge utile, l’en-tête TCP et l’en-tête IP interne (IP1).

L’en-tête IP du routeur (IP2), ajouté par Junos OS, contient l’adresse IP de la passerelle distante comme adresse IP de destination et l’adresse IP du routeur local comme adresse IP source. Junos OS ajoute également un en-tête ESP entre les en-têtes IP externe et interne. L’en-tête ESP contient des informations qui permettent à l’homologue distant de traiter correctement le paquet lorsqu’il le reçoit. Voir Figure 5.

Le champ En-tête suivant indique le type de données dans le champ de charge utile. En mode tunnel, cette valeur est de 4, ce qui indique qu’un paquet IP est contenu dans la charge utile. Voir Figure 6.

Configuration d’IKEv2 dans Junos OS

Un homologue VPN est configuré en IKEv1 ou IKEv2. Lorsqu’un homologue est configuré en tant qu’IKEv2, il ne peut pas revenir à IKEv1 si son homologue distant initie une négociation IKEv1. Par défaut, les équipements de sécurité de Juniper Networks sont des homologues IKEv1.

Utilisez l’instruction de version v2-only configuration au niveau de la hiérarchie [edit security ike gateway gw-name ] pour configurer IKEv2.

La version IKE est affichée dans la sortie des commandes opérationnelles et show security ipsec security-associations de la show security ike security-associations CLI.

Les équipements Juniper Networks prennent en charge jusqu’à quatre propositions pour les négociations de phase 2, ce qui vous permet de définir le degré de restriction de la plage de paramètres de tunnel que vous accepterez. Junos OS fournit des ensembles prédéfinis de propositions de phase 2 standard, compatibles et basiques. Vous pouvez également définir des propositions personnalisées pour la phase 2.

Comprendre la charge utile de configuration IKEv2

La charge utile de configuration est une option d’Internet Key Exchange version 2 (IKEv2) proposée pour propager les informations de provisionnement d’un répondeur à un initiateur. La charge utile de configuration IKEv2 est prise en charge uniquement avec les VPN basés sur le routage.

La norme RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2), définit 15 attributs de configuration différents qui peuvent être renvoyés à l’initiateur par le répondant. Le Tableau 1 décrit les attributs de configuration IKEv2 pris en charge par les pare-feu.

Tableau 1 : attributs de configuration IKEv2

Type d’attribut	Valeur	Descriptif	Longueur
INTERNAL_IP4_ADDRESS	1	Spécifie une adresse sur le réseau interne. Plusieurs adresses internes peuvent être demandées. Le répondant peut envoyer jusqu’au nombre d’adresses demandées.	0 ou 4 octets
INTERNAL_IP4_NETMASK	2	Spécifie la valeur du masque de réseau interne. Une seule valeur de masque de réseau est autorisée dans les messages de demande et de réponse (par exemple, 255.255.255.0) et elle ne doit être utilisée qu’avec un attribut INTERNAL_IP4_ADDRESS.	0 ou 4 octets
INTERNAL_IP4_DNS	3	Spécifie l’adresse d’un serveur DNS au sein du réseau. Plusieurs serveurs DNS peuvent être demandés. Le répondant peut répondre avec zéro ou plusieurs attributs de serveur DNS.	0 ou 4 octets
INTERNAL_IP4_NBNS	4	Spécifie l’adresse d’un serveur de noms NetBIOS (NBNS), par exemple, un serveur WINS, au sein du réseau. Plusieurs serveurs NBNS peuvent être demandés. Le répondeur peut répondre avec zéro ou plusieurs attributs de serveur NBNS.	0 ou 4 octets
INTERNAL_IP6_ADDRESS	8	Spécifie une adresse sur le réseau interne. Plusieurs adresses internes peuvent être demandées. Le répondant peut envoyer jusqu’au nombre d’adresses demandées.	0 ou 17 octets
INTERNAL_IP6_DNS	10	Spécifie l’adresse d’un serveur DNS au sein du réseau. Plusieurs serveurs DNS peuvent être demandés. Le répondant peut répondre avec zéro ou plusieurs attributs de serveur DNS.	0 ou 16 octets

Pour que le répondeur IKE puisse fournir à l’initiateur des informations de provisionnement, il doit acquérir ces informations à partir d’une source spécifiée telle qu’un serveur RADIUS. Les informations de provisionnement peuvent également être renvoyées d’un serveur DHCP via un serveur RADIUS. Sur le serveur RADIUS, les informations utilisateur ne doivent pas inclure de mot de passe d’authentification. Le profil de serveur RADIUS est lié à la passerelle IKE à l’aide de la aaa access-profile profile-name configuration au niveau de la hiérarchie [edit security ike gateway gateway-name ].

Junos OS a amélioré la charge utile de configuration IKEv2 pour prendre en charge les fonctionnalités suivantes :

• Prise en charge des pools d’adresses locales IPv4 et IPv6. Vous pouvez également attribuer une adresse IP fixe à un pair.

  Lors de l’établissement de l’IKE, l’initiateur demande une adresse IPv4, une adresse IPv6, une adresse DNS ou une adresse WINS au répondeur. Une fois que le répondeur a authentifié l’initiateur avec succès, il attribue une adresse IP à partir d’un pool d’adresses local ou via le serveur RADIUS. Selon la configuration, cette adresse IP est attribuée dynamiquement chaque fois qu’un homologue se connecte ou en tant qu’adresse IP fixe. Si le serveur RADIUS répond avec un pool tramé, Junos OS attribue une adresse IP ou des informations en fonction de la configuration de son pool local correspondant. Si vous configurez à la fois un pool d’adresses local et un serveur RADIUS, l’adresse IP allouée à partir du serveur RADIUS est prioritaire sur le pool local. Si vous configurez un pool d’adresses IP local et que le serveur RADIUS n’a renvoyé aucune adresse IP, le pool local affecte l’adresse IP à la demande.

• Option supplémentaire, none introduite pour authentication-order. Voir ordre d’authentification (profil d’accès).

• Les messages de démarrage et d’arrêt de la comptabilité RADIUS informent de l’état du tunnel ou de l’homologue au serveur RADIUS. Ces messages peuvent être utilisés à des fins de suivi ou de notification à des sous-systèmes tels qu’un serveur DHCP.

  Assurez-vous que le serveur RADIUS prend en charge la comptabilité des messages de démarrage ou d’arrêt. Assurez-vous également que le pare-feu et le serveur RADIUS disposent des paramètres appropriés pour suivre ces messages.

• La prise en charge d’IPv6 permet d’utiliser des tunnels à double pile en utilisant la charge utile de configuration. Pendant le processus de connexion, IKE demande les adresses IPv4 et IPv6. AAA n’autorise la connexion que si toutes les adresses demandées ont été allouées avec succès. IKE met fin à la négociation si l’IP demandée n’est pas attribuée.

Dans un VPN basé sur le routage, les interfaces de tunnel sécurisé (st0) fonctionnent en mode point à multipoint ou point à point. L’attribution d’adresses via la charge utile de configuration IKEv2 est désormais prise en charge pour le mode point à multipoint ou point à point. Pour les interfaces point à multipoint, les interfaces doivent être numérotées et les adresses dans la charge utile de configuration INTERNAL_IP4_ADDRESS le type d’attribut doivent se situer dans la plage sous-réseau de l’interface point à multipoint associée.

Vous pouvez configurer un mot de passe commun pour les demandes de charge utile de configuration IKEv2 pour une configuration de passerelle IKE. Le mot de passe commun compris entre 1 et 128 caractères permet à l’administrateur de définir un mot de passe commun. Ce mot de passe est utilisé entre le pare-feu et le serveur RADIUS lorsque le pare-feu demande une adresse IP au nom d’un homologue IPsec distant à l’aide d’une charge utile de configuration IKEv2. Le serveur RADIUS correspond aux informations d’identification avant de fournir des informations IP au pare-feu pour la demande de charge utile de configuration. Vous pouvez configurer le mot de passe commun à l’aide config-payload-password configured-password de l’instruction de configuration au niveau de la hiérarchie [edit security ike gateway gateway-name aaa access-profile access-profile-name].

Le pare-feu et le serveur RADIUS doivent avoir le même mot de passe configuré, et le serveur RADIUS doit être configuré pour utiliser le protocole d’authentification par mot de passe (PAP) comme protocole d’authentification. Sans cela, la mise en place de tunnels ne sera pas couronnée de succès.

Remarque : Le processus iked ne dépend pas du pool DHCP ou de la méthode d’attribution d’adresses. Lorsque le tunnel VPN tombe en panne, Junos OS libère l’adresse attribuée.

La figure 7 montre un workflow typique pour une charge utile de configuration IKEv2.

La fonctionnalité de charge utile de configuration IKEv2 est prise en charge à la fois pour les interfaces de tunnel sécurisé point à multipoint (st0) et pour les interfaces point à point. Les interfaces point à multipoint doivent être numérotées et les adresses fournies dans la charge utile de configuration doivent se trouver dans la plage de sous-réseau de l’interface point à multipoint associée.

Comprendre le provisionnement des cellules Pico

La charge utile de configuration IKEv2 peut être utilisée pour propager des informations de provisionnement à partir d’un répondeur IKE, tel que le pare-feu, vers plusieurs initiateurs, tels que les stations de base de cellules pico LTE dans un réseau cellulaire. Les cellules pico sont expédiées de l’usine avec une configuration standard qui leur permet de se connecter au pare-feu, mais les informations de provisionnement des cellules pico sont stockées sur un ou plusieurs serveurs de provisionnement au sein d’un réseau protégé. Les cellules pico reçoivent des informations de provisionnement complètes après avoir établi des connexions sécurisées avec les serveurs de provisionnement.

Le flux de travail nécessaire pour amorcer et provisionner une cellule pico et la mettre en service comprend quatre étapes distinctes :

1. Acquisition initiale des adresses : la pico cell est expédiée de l’usine avec les informations suivantes :

   • Configuration du tunnel de passerelle sécurisée vers le pare-feu

   • Certificat numérique délivré par le fabricant

   • Nom de domaine complet (FQDN) des serveurs de provisionnement qui se trouvent dans le réseau protégé

   La cellule pico démarre et acquiert une adresse à utiliser pour la négociation IKE à partir d’un serveur DHCP. Un tunnel est ensuite construit vers la passerelle sécurisée sur le pare-feu à l’aide de cette adresse. Une adresse pour le trafic d’exploitation, d’administration et de gestion (OAM) est également attribuée par le serveur DHCP pour une utilisation sur le réseau protégé.

2. Provisionnement de la cellule Pico : à l’aide de l’adresse de trafic OAM qui lui est attribuée, la cellule Pico demande ses informations de provisionnement (généralement un certificat d’opérateur, une licence, un logiciel et des informations de configuration) aux serveurs du réseau protégé.

3. Redémarrer : la cellule pico redémarre et utilise les informations de provisionnement acquises pour les rendre spécifiques au réseau et au modèle opérationnel du fournisseur de services.

4. Prestation de services : lorsque la cellule pico entre en service, elle utilise un certificat unique contenant des valeurs de nom unique (DN) et d’autre nom d’objet avec un nom de domaine complet pour créer deux tunnels vers la passerelle sécurisée sur le pare-feu : un pour le trafic OAM et l’autre pour le trafic de données du projet de partenariat de troisième génération (3GPP).

Vue d’ensemble

Avec IKEv2, la nouvelle saisie et la réauthentification sont des processus distincts. La modification des clés établit de nouvelles clés pour l’association de sécurité (SA) IKE et réinitialise les compteurs d’ID de message, mais elle ne réauthentifie pas les pairs. La réauthentification vérifie que les homologues VPN conservent leur accès aux identifiants d’authentification. La réauthentification établit de nouvelles clés pour les SA IKE et les SA enfants ; les reclés de tout SA IKE ou enfant en attente ne sont plus nécessaires. Une fois la nouvelle SA IKE et enfant créée, l’ancienne SA IKE et enfant est supprimée.

La réauthentification IKEv2 est désactivée par défaut. Pour activer la réauthentification, configurez une valeur de fréquence de réauthentification comprise entre 1 et 100. La fréquence de réauthentification est le nombre de nouvelles clés IKE qui se produit avant que la réauthentification ne se produise. Par exemple, si la fréquence de réauthentification configurée est de 1, la réauthentification se produit chaque fois qu’il y a une nouvelle clé IKE. Si la fréquence de réauthentification configurée est de 2, la réauthentification se produit tous les autres re-clés IKE. Si la fréquence de réauthentification configurée est de 3, la réauthentification se produit tous les trois recléages IKE, et ainsi de suite.

Vous configurez la fréquence de réauthentification avec l’instruction reauth-frequency au niveau de la hiérarchie [edit security ike policy policy-name]. La réauthentification est désactivée en définissant la fréquence de réauthentification sur 0 (valeur par défaut). La fréquence de réauthentification n’est pas négociée par les pairs et chaque homologue peut avoir sa propre valeur de fréquence de réauthentification.

Fonctionnalités prises en charge

La réauthentification IKEv2 est prise en charge avec les fonctionnalités suivantes :

• Initiateurs ou répondeurs IKEv2

• Détection des pairs morts (DPD)

• Routeurs virtuels et interfaces de tunnel sécurisé (st0) dans les routeurs virtuels

• Traversée de traduction d’adresses réseau (NAT-T)

• Clusters de châssis en mode actif-actif et actif-passif

• Mise à niveau de logiciels en service (ISSU)

• Mise à niveau ou insertion d’une nouvelle unité de traitement de services (SPU) à l’aide de la procédure de mise à niveau matérielle en service (ISHU)

Limites

Notez les mises en garde suivantes lors de l’utilisation de la réauthentification IKEv2 :

• Avec le NAT-T, une nouvelle SA IKE peut être créée avec des ports différents de la SA IKE précédente. Dans ce scénario, l’ancienne SA IKE peut ne pas être supprimée.

• Dans un scénario NAT-T, l’initiateur derrière l’appareil NAT peut devenir le répondeur après la réauthentification. Si la session NAT expire, le périphérique NAT peut ignorer de nouveaux paquets IKE susceptibles d’arriver sur un autre port. NAT-T keepalive ou DPD doit être activé pour maintenir la session NAT active. Pour AutoVPN, nous recommandons que la fréquence de réauthentification configurée sur les rayons soit plus petite que la fréquence de réauthentification configurée sur le hub.

• En fonction de la fréquence de réauthentification, une nouvelle SA IKE peut être initiée par l’initiateur ou le répondant de la SA IKE d’origine. Étant donné que l’authentification EAP (Extensible Authentication Protocol) et les charges utiles de configuration nécessitent que l’architecture IKE soit initiée par le même tiers que l’architecture IKE d’origine, la réauthentification n’est pas prise en charge avec l’authentification EAP ou la charge utile de configuration.

Hiérarchie multiniveau pour l’authentification des certificats

L’authentification basée sur les certificats est une méthode d’authentification prise en charge sur les pare-feu lors des négociations IKE. Dans les grands réseaux, plusieurs autorités de certification (CA) peuvent émettre des certificats d’entité finale (EE) à leurs appareils finaux respectifs. Il est courant d’avoir des AC distincts pour des sites, des départements ou des organisations individuels.

Lorsqu’une hiérarchie à un seul niveau est utilisée pour l’authentification basée sur les certificats, tous les certificats EE du réseau doivent être signés par le même AC. Tous les périphériques de pare-feu doivent avoir le même certificat d’AC enregistré pour la validation du certificat homologue. La charge utile de certificat envoyée lors de la négociation IKE ne contient que des certificats EE.

La charge utile de certificat envoyée lors de la négociation IKE peut également contenir une chaîne de certificats EE et AC. Une chaîne de certificats est la liste des certificats requis pour valider le certificat EE d’un pair. La chaîne de certificats comprend le certificat EE et tous les certificats AC qui ne sont pas présents dans l’homologue local.

L’administrateur réseau doit s’assurer que tous les pairs participant à une négociation IKE ont au moins un AC de confiance commun dans leurs chaînes de certificats respectives. L’AC de confiance commune n’a pas besoin d’être l’AC racine. Le nombre de certificats dans la chaîne, y compris les certificats pour les EE et l’AC la plus élevée de la chaîne, ne peut pas dépasser 10.

La validation d’un homologue IKE configuré peut être effectuée avec un serveur AC ou un groupe de serveurs AC spécifiés. Avec les chaînes de certificats, l’AC racine doit correspondre au groupe d’AC ou au serveur d’AC approuvé configuré dans la stratégie IKE.

Dans l’exemple de hiérarchie d’AC illustré à la figure 8, Root-AC est l’AC de confiance commune à tous les appareils du réseau. L’autorité de certification Root-AC délivre des certificats d’AC aux autorités de certification d’ingénierie et de vente, identifiées respectivement comme Eng-AC et Sales-AC. Eng-AC délivre des certificats d’AC aux AC de développement et d’assurance qualité, qui sont identifiés comme Dev-AC et Qa-AC, respectivement. L’hôte A reçoit son certificat EE de Dev-AC, tandis que l’hôte B reçoit son certificat EE de Sales-AC.

Chaque terminal doit être chargé avec les certificats d’AC dans sa hiérarchie. L’hôte A doit avoir des certificats Root-AC, Eng-AC et Dev-AC ; Les certificats Sales-AC et Qa-AC ne sont pas nécessaires. L’hôte B doit être titulaire de certificats d’AC racine et d’AC de vente. Les certificats peuvent être chargés manuellement dans un appareil ou enrôlés à l’aide du processus simple d’inscription des certificats (SCEP).

Chaque terminal doit être configuré avec un profil d’AC pour chaque AC de la chaîne de certificats. La sortie suivante montre les profils d’AC configurés sur l’hôte A :

La sortie suivante montre les profils d’AC configurés sur l’hôte B :

Mise en œuvre de l’authentification des signatures dans IKEv2

Outre la prise en charge de l’authentification basée sur les signatures par algorithme, Junos OS prend également en charge la méthode d’authentification par signature numérique décrite dans RFC 7427. Dans cette méthode, la charge utile d’authentification IKEv2 indique non seulement le type de clé publique, mais également l’algorithme de hachage utilisé par l’appareil pour générer la signature. L’appareil utilise la notification SIGNATURE_HASH_ALGORITHM pour informer son homologue de la prise en charge de la RFC 7427 et fournir la liste des algorithmes de hachage pris en charge.

Pour utiliser cette fonctionnalité, vous devez configurer la méthode d’authentification par signature numérique sur votre appareil. Pour plus d’informations sur la méthode d’authentification par signature numérique, consultez la proposition (Sécurité IKE). Vous pouvez utiliser l’option signature-hash-algorithm de configuration pour définir les algorithmes de hachage de signature spécifiques qui doivent correspondre dans l’ordre hiérarchique à chacun des algorithmes de hachage de signature reçus. Si vous ne spécifiez pas l’algorithme de hachage de signature, l’appareil correspond à l’algorithme de hachage de signature reçu dans la liste par défaut de tous les algorithmes de hachage pris en charge. Voir Algorithme de hachage de signature (Sécurité IKE).

Dans Junos OS, la méthode d’authentification implique les étapes suivantes qui sont définies dans le flux de messages IKEv2. Pour plus de détails, reportez-vous à RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2).

• Les deux homologues IKE se notifient initialement la liste des algorithmes de hachage pris en charge. Votre appareil envoie la charge utile SIGNATURE_HASH_ALGORITHM du message IKE_SA_INIT à l’appareil homologue et reçoit une réponse. Les pairs négocient ensuite un algorithme de hachage de signature.

• Dans le message IKE_AUTH, les pairs échangent la méthode d’authentification par signature numérique.

L’appareil utilise la méthode d’authentification par certificat par défaut dans l’un des scénarios suivants :

• Responder ne prend pas en charge la RFC 7427.

• L’initiateur ne prend pas en charge l’algorithme de hachage reçu.

Avantages

• Flexible : comprend les signatures numériques traditionnelles et nouvelles.

• Facilité d’utilisation : s’intègre à l’infrastructure à clé publique (PKI) existante.

• Solution robuste : effectue une meilleure vérification de l’identité par rapport à la méthode d’authentification basée sur les signatures, ce qui améliore la sécurité et la fiabilité globales des homologues IKE.

Vulnérabilités DDoS sur les implémentations d’IKE

Lorsque l’homologue distant (initiateur) envoie un message SA_INIT, l’homologue local (répondeur) répond et alloue de la mémoire à la structure du message. Nous appelons la session une session IKE semi-ouverte jusqu’à ce que l’authentification se produise à l’aide du message IKE_AUTH. Une fois que les pairs ont créé une association de sécurité (SA) IKE, la session devient une session IKE entièrement ouverte.

Pour comprendre les vulnérabilités DDoS d’IKEv2, examinons quelques-unes des façons dont un attaquant peut créer un vecteur d’attaque facile contre les SA d’IKE :

• Envoyer un grand nombre de messages SA_INIT (sans messages IKE_AUTH) pour lesquels l’attaquant peut créer des structures d’association de sécurité IKE semi-ouvertes. L’attaque entraîne l’utilisation des ressources et l’épuisement de la mémoire de l’appareil.

• Envoyez un grand nombre de paquets indésirables IKE_AUTH avec le bon SPI_i et le bon SPI_r sur l’initiateur et le répondeur, respectivement. L’appareil manque de mémoire lors de la tentative de déchiffrement des paquets.

• Envoyez SA_INIT paquets en continu. L’appareil manque de mémoire lorsqu’il tente de générer des clés pour les paquets chiffrés.

• Envoyez un grand nombre de demandes de changement de clé par seconde pendant les sessions IKE ouvertes complètes.

• Envoyez un grand nombre de messages avec des identifiants de message (ID) distincts. L’appareil met en file d’attente tous les messages IKE entrants et manque de mémoire.

Comment protéger les implémentations d’IKE

Nous fournissons une infrastructure robuste pour atténuer et surveiller les attaques DDoS pour les protocoles IKEv1 et IKEv2. Vous pouvez vous protéger contre les attaques contre les implémentations IKE lorsque votre pare-feu exécute le processus iked (dans le package junos-ike ) pour le service VPN IPsec.

Remarque :

Pour plus de détails sur la protection DDoS pour IKEv2, consultez RFC 8019, Protection des implémentations Internet Key Exchange Protocol version 2 (IKEv2) contre les attaques par déni de service distribué. Nous fournissons une protection similaire pour IKEv1 lorsque votre pare-feu exécute le service VPN IPsec à l’aide du processus iked. Nous ne prenons pas en charge le mécanisme de puzzle client présenté par la RFC.

Protection contre les attaques DDoS

Vous pouvez activer plusieurs mécanismes de défense contre les attaques DDoS pendant le processus de création de l’association de sécurité IKE. Ces mécanismes comprennent la configuration d’une limitation de débit et d’une période de conservation pour les SA IKE semi-ouvertes, ainsi qu’une gestion plus approfondie des taux de change entrants pour les demandes de changement de clé. Nous fournissons les mesures suivantes pour assurer la protection contre les attaques DDoS contre les SA IKE :

• Mesures de protection pour les SA IKE semi-ouvertes :

  • Le répondeur n’autorise pas la configuration de SA IKE semi-ouvertes pendant une certaine durée. Vous pouvez définir cette limite afin que le répondeur ne configure pas les SA tant qu’il n’a pas atteint la durée du délai d’expiration. Pour plus de détails, voir session (Sécurité IKE) pour l’option timeout.

  • Vous pouvez définir une limite sur le nombre maximal de SA IKE semi-ouvertes autorisées sur le répondeur. Lorsque le nombre total de SA IKE semi-ouvertes atteint le nombre maximum, le répondeur rejette les nouvelles connexions pour les SA IKEv1 et IKEv2. Pour plus de détails, voir l’option dans Session max-count (Sécurité IKE).

  • Le répondeur applique des valeurs de seuil sur le nombre de sessions pour les SA IKE semi-ouvertes. Lorsque le nombre total de SA IKE semi-ouvertes atteint les valeurs seuils :

    • Dans le cas des SA IKEv2, le répondant invoque un mécanisme de cookie pour toute nouvelle connexion.

    • Dans le cas des SA IKEv1, le répondeur rejette les nouvelles connexions.

    Pour plus de détails, reportez-vous à la section et send-cookie reduce-timeout options thresholdsde la session (Sécurité IKE).

  • Le répondeur peut ignorer les sessions en double. Pour plus de détails, voir l’option dans Session discard-duplicate (Sécurité IKE).

  • Vous pouvez définir des délais d’interruption pour les phases d’échec d’authentification et d’échec. Pour plus de détails, reportez-vous aux sections session (Sécurité IKE) pour connaître les options backoff-timeouts, init-phase-failure et auth-phase-failure.

• Pour les SA IKE ouvertes complètes :

  • Vous pouvez configurer des taux maximaux de demandes de renouvellement de clé entrantes pour limiter les demandes dans un scénario mis à l’échelle. Pour plus de détails, voir l’option dans Session incoming-exchange-max-rates (Sécurité IKE).

• Le répondeur peut bloquer une session IKE entrante à partir de pairs en fonction de l’ID IKE pair. Pour plus de détails, voir Listes de blocage (Sécurité IKE).

• Pour les passerelles dynamiques, vous pouvez définir une limite pour le nombre de connexions au niveau de la configuration de la passerelle IKE à l’aide de l’option connections-limit. Pour plus de détails, voir Passerelle (Sécurité IKE).

Pour plus de détails sur la configuration de ces options, consultez Configurer la protection contre les attaques DDoS IKE.

Nous ne prenons pas en charge :

• Protection DDoS avec service VPN IPsec basé sur le processus KMD.

• Protection contre les attaques par hachage et par codage de certificat d’URL , car nous ne prenons pas en charge ces types d’encodage.

Moyens de surveiller les attaques DDoS

Nous fournissons les mécanismes suivants pour surveiller les attaques DDoS :

• Utilisez la show security ike security-associations commande pour répertorier toutes les associations de sécurité IKE matures et non matures. Pour plus de détails, voir show security ike security-associations.

• Utilisez la commande pour afficher les statistiques IKE globales du tunnel VPN IPsec, telles que les show security ike stats statistiques en cours, établies et expirées. Pour plus de détails, consultez Afficher les statistiques de sécurité.

• Utilisez la show security ike active-peer commande pour afficher les détails des négociations IKE réussies avec les pairs distants. Pour plus de détails, voir show security ike active-peer.

• Utilisez la show security ike peers in-progress commande pour afficher les détails des SA IKE en cours, y compris les SA IKE semi-ouvertes. Pour plus d’informations, consultez Afficher les pairs ike de sécurité. Vous pouvez également voir les détails des homologues bloqués, échoués et interrompus à l’aide de cette commande.

• Utilisez la clear security ike peers commande pour effacer les homologues IKE qui sont bloqués, bloqués, en échec ou en cours. Pour plus d’informations, consultez Effacer la sécurité des pairs ike.

• Pour supprimer une association de sécurité IKE existante avec des pairs qui doit être bloquée pour toute communication ultérieure, utilisez la clear security ike security-associations commande. Pour plus d’informations, consultez Effacer la sécurité ike security-associations.

• Les messages du journal système iked (syslog) IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF et IKE_GATEWAY_PEER_FAILED fournissent des détails sur les négociations IKE bloquées, annulées et échouées avec les pairs distants, respectivement.

• Pour renforcer la sécurité, Junos OS fournit des services aux utilisateurs pour les protéger contre les attaques système basées sur les paquets, telles que le filtrage, le nombre de sessions et la limitation de débit. Pour plus de détails, voir la commande show firewall et l’instruction ids-option au niveau de la hiérarchie [edit security screen ids-option screen-name].

Fragmentation des messages

La fragmentation des messages IKEv2, telle que décrite dans la RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, permet à IKEv2 de fonctionner dans des environnements où les fragments IP peuvent être bloqués et les homologues ne peuvent pas établir d’association de sécurité IPsec (SA). La fragmentation IKEv2 divise un message IKEv2 volumineux en un ensemble plus petit afin qu’il n’y ait pas de fragmentation au niveau IP. La fragmentation a lieu avant que le message d’origine ne soit chiffré et authentifié, de sorte que chaque fragment est chiffré et authentifié séparément. Sur le récepteur, les fragments sont collectés, vérifiés, déchiffrés et fusionnés dans le message d’origine.

Pour qu’IKEv2 fragmentation se produise, les deux homologues VPN doivent indiquer fragmentation prise en charge en incluant la charge utile de notification IKEV2_FRAGMENTATION_SUPPORTED dans l’échange IKE_SA_INIT. Si les deux pairs indiquent un support de fragmentation, il appartient à l’initiateur de l’échange de messages de déterminer si la fragmentation IKEv2 est utilisée ou non.

Sur les pare-feu, un maximum de 32 fragments est autorisé par message IKEv2. Si le nombre de fragments de message IKEv2 à envoyer ou à recevoir dépasse 32, les fragments sont abandonnés et le tunnel n’est pas établi. La retransmission de fragments de messages individuels n’est pas prise en charge

La configuration

Sur les pare-feu, la fragmentation IKEv2 est activée par défaut pour les messages IPv4 et IPv6. Pour désactiver la fragmentation IKEv2, utilisez l’instruction disable au niveau de la hiérarchie [edit security ike gateway gateway-name fragmentation]. Vous pouvez également utiliser l’instruction size pour configurer la taille du paquet à partir duquel les messages sont fragmentés ; la taille du paquet varie de 500 à 1300 octets. Si size n’est pas configuré, la taille de paquet par défaut est de 576 octets pour le trafic IPv4 et de 1280 octets pour le trafic IPv6. Un paquet IKEv2 supérieur à la taille configurée est fragmenté.

Une fois la fragmentation IKEv2 désactivée ou activée ou la taille du fragment de paquet modifiée, les tunnels VPN hébergés sur la passerelle IKE sont arrêtés et les SA IKE et IPsec sont renégociées.

Mises en garde

Les fonctionnalités suivantes ne sont pas prises en charge avec la fragmentation IKEv2 :

• Découverte de la MTU de chemin.

• SNMP.

Certificat local dans IKE

Internet Key Exchange (IKE) prend en charge l’authentification basée sur des certificats pour établir de manière sécurisée la confiance entre les pairs VPN. Dans cette méthode d’authentification, les deux pairs utilisent des certificats numériques pour vérifier l’identité de l’autre pendant la négociation IKE.

Pendant la phase d’authentification IKE, l’homologue distant (initiateur) envoie une charge utile de demande de certificat à l’appareil local (répondeur). En réponse, l’appareil local envoie une charge utile de certificat contenant son certificat local. L’initiateur utilise le certificat reçu pour valider l’identité du répondant en vérifiant la chaîne de certificats et en vérifiant la relation de confiance avec l’autorité de certification émettrice (AC). Cette validation garantit que le répondant est autorisé à participer à la négociation IKE.

Critères de sélection des certificats locaux

Le certificat local est le certificat que le répondant présente à l’initiateur lors de la négociation IKE pour prouver son identité. Un homologue VPN inclut des identifiants d’AC dans une demande de certificat pour indiquer les AC auxquelles il fait confiance. Le processus iked ne prend en compte que les huit premiers identifiants et ignore tout identifiant supplémentaire. L’appareil local examine les identifiants AC inclus dans la charge utile de la demande de certificat de l’homologue et sélectionne le certificat local en fonction des critères répertoriés dans le tableau suivant.

Tableau 2 : Critères de sélection des certificats locaux pour l’IKE

Version d’IKE	Critères de sélection des certificats
IKEv2	Sélectionne le certificat local en fonction du hachage AC fourni dans la charge utile de demande de certificat.
IKEv1	Sélectionne le certificat local en fonction du nom distinctif (DN) de l’objet de l’AC fourni dans la charge utile de demande de certificat.
Comportement de repli d’IKE	Sélectionne le premier certificat chargé dans la liste des certificats locaux lorsqu’aucune correspondance n’est trouvée.

Certificats locaux multiples

L’équipement sélectionne et gère les certificats locaux selon qu’il prend en charge un ou plusieurs certificats locaux.

Lorsque l’appareil ne prend en charge qu’un seul certificat local :

• Chaque nouvelle configuration de certificat local remplace le certificat existant.

• La passerelle utilise un seul certificat, même si elle dessert plusieurs homologues distants. Certains homologues peuvent ne pas avoir le certificat d’AC requis pour valider le certificat de passerelle, car la passerelle peut ne pas présenter de certificat local correspondant en réponse à la demande du pair.

Lorsque l’appareil prend en charge plusieurs certificats locaux avec le processus iked :

• Vous pouvez configurer plusieurs certificats locaux dans la stratégie IKE.

• Chaque certificat local configuré est ajouté à la liste existante au lieu de la remplacer. Les certificats restent disponibles jusqu’à ce qu’ils expirent ou qu’ils soient explicitement supprimés.

• L’appareil évalue les certificats locaux dans l’ordre indiqué. L’appareil sélectionne le premier certificat dont la chaîne (établie à partir d’un AC racine approuvé) correspond à l’un des identificateurs de AC homologues. Si aucun certificat configuré ne correspond aux identificateurs AC dans la demande de certificat, le processus iked sélectionne un certificat local dont la chaîne peut être construite vers un AC racine approuvé. Le processus évalue les certificats de manière séquentielle et sélectionne le premier certificat avec une chaîne valide à envoyer à l’homologue.

Rôle de l’ID IKE dans la sélection des certificats

• L’ID IKE local n’influence pas la sélection du certificat IKE, sauf lorsque le type d’ID IKE est un DN au niveau de la hiérarchie [edit security ike gateway name remote-identity distinguished-name] :

  • Lorsque l’ID IKE est un DN, IKE effectue une recherche PKI pour récupérer le certificat qui correspond au DN sans évaluer l’ordre indiqué.
  • Après la récupération, IKE met le certificat en cache pour une utilisation ultérieure.

Si l’ID IKE local ne correspond pas au certificat local sélectionné, l’établissement de liaison IKE peut échouer sur l’appareil pair.

Mise en cache des certificats locaux dans IKE

Une fois qu’un certificat local est sélectionné, IKE met en cache le certificat pour minimiser les recherches PKI futures. Une fois mis en cache dans IKE :

• Le processus iked utilise le certificat mis en cache pour les connexions suivantes, à condition qu’il corresponde aux identifiants AC entrants.

• Si le certificat mis en cache ne correspond pas aux identifiants de l’AC entrants, le processus iked sélectionne un nouveau certificat et reconstruit la chaîne de certificats à partir de la liste de certificats locaux configurés.

• L’ordre des certificats n’affecte pas la sélection des certificats.

• La réorganisation des certificats (par exemple, le déplacement du premier certificat vers une autre position) ne déclenche pas de nouvelle recherche PKI ni ne supprime la connexion IPsec existante.

• IKE continue d’utiliser le certificat mis en cache tant qu’il répond aux critères de sélection requis.

• Si le certificat local est supprimé de l’appareil, le certificat mis en cache correspondant est également effacé.

• Le redémarrage du processus iked efface le cache des certificats.

Ajout ou suppression de certificats locaux

• L’ajout de certificats ne supprime pas les associations de sécurité (SA) existantes.

• Si un certificat est supprimé de la liste des certificats, toutes les SA IKE qui utilisent la stratégie IKE correspondante sont supprimées.

• La suppression d’un certificat local ou d’un certificat AC de PKI ne provoque pas d’erreur de commit dans IKE ni ne supprime la connexion IPsec existante.

Configurer la stratégie IKE avec plusieurs certificats locaux

Pour configurer plusieurs certificats locaux, procédez comme suit :

1. Configurez un profil d’AC et chargez le certificat d’AC. Voir Autorité de certification.

2. Chargez un certificat local existant sur l’appareil ou inscrivez un certificat local de l’AC dont le certificat d’AC a été précédemment chargé. Voir Certificats numériques.

   Répétez l’étape pour chaque certificat local de la stratégie IKE.

3. Associez les certificats locaux à la stratégie IKE. Utilisez l’une des commandes suivantes :

   ou

Configurez la stratégie IKE, la proposition IKE et la passerelle IKE, puis la stratégie IPsec et la proposition d’établissement d’un tunnel VPN IPsec de bout en bout.

Pour déterminer quel certificat local est sélectionné dans la liste de certificats configurée dans une stratégie IKE, consultez les journaux de suivi IKE. Les journaux affichent le DN de l’objet du certificat.

Présentation des groupes d’AC approuvés dans IKE

Un groupe d’autorités de certification (AC) de confiance regroupe un ou plusieurs profils d’AC et agit comme une ancre d’approbation unique pour valider le certificat homologue pendant les négociations IKE. L’appareil peut contenir plusieurs certificats d’AC. Vous pouvez configurer IKE pour utiliser un groupe d’AC approuvé, qui est un sous-ensemble des certificats d’AC configurés. Lors de l’authentification basée sur les certificats pour IKEv2 ou IKEv1, l’appareil vérifie que la chaîne de certificats de l’homologue jusqu’à la racine. Lorsqu’une politique IKE utilise un groupe d’AC approuvé, l’appareil valide le certificat de l’homologue par rapport à tous les profils d’AC inclus dans le groupe.

Les groupes AC de confiance simplifient la gestion des certificats dans les environnements qui utilisent plusieurs autorités de certification ou lors de la migration d’un AC à un autre. Vous pouvez mettre à jour le groupe d’AC à tout moment pour ajouter ou supprimer des profils d’AC.

Lorsqu’un homologue VPN établit une connexion, l’appareil valide le certificat de l’homologue à l’aide du groupe d’AC approuvé configuré dans la stratégie IKE :

• Si le certificat est signé par un AC du groupe approuvé, l’authentification réussit et la connexion est autorisée.

• Si le certificat n’est pas signé par un AC du groupe approuvé, l’authentification échoue et l’tunnel IPsec n’est pas établie.

Un groupe d’AC de confiance garantit donc que l’appareil accepte uniquement les certificats émis par les autorités de certification autorisées, ce qui simplifie la gestion des certificats tout en maintenant une authentification VPN sécurisée.

Configurer la stratégie IKE avec un groupe d’AC approuvé

Avant de configurer une stratégie IKE avec un groupe d’AC approuvé, assurez-vous que :

• Vous disposez d’une liste de toutes les autorités de certification auxquelles vous souhaitez faire confiance.

• La stratégie IKE utilise l’authentification basée sur les certificats.

• Vous avez accès aux paramètres PKI et IKE sur l’appareil.

Pour configurer et vérifier la stratégie IKE avec le groupe d’AC approuvé :

1. Créez des profils d’AC et chargez les certificats. Chaque profil d’AC représente une AC. Voir Configuration des profils AC.

   Chaque profil AC représente un AC de confiance qui peut valider les certificats homologues.

   Chargez les certificats d’AC dans leurs profils d’AC correspondants. Chaque certificat d’AC chargé permet à l’appareil de valider les certificats homologues émis par cette AC.

2. Créez un groupe d’AC approuvé. Regroupez les profils d’AC dans un groupe d’AC approuvé. L’ordre des profils d’AC dans le groupe d’AC approuvé n’affecte pas la validation des certificats. Voir Configuration d’un groupe d’AC approuvé.

   L’appareil utilise ce groupe pour valider les certificats homologues lors de l’authentification IKE.

3. Configurez la stratégie IKE pour utiliser l’authentification basée sur les certificats et associez le groupe d’AC approuvé à la stratégie.

4. Vérifiez que le groupe d’AC approuvé est correctement configuré.

   Vérifiez que le groupe d’AC approuvé est associé à la stratégie IKE.

Une fois la configuration terminée :

• L’appareil authentifie les homologues VPN à l’aide de certificats.

• L’appareil fait confiance aux certificats émis par n’importe quel AC du groupe de AC approuvé.

• Les connexions VPN entrantes réussissent si le certificat homologue est validé par le groupe d’AC.

Pour établir un tunnel VPN IPsec de bout en bout, terminez la configuration restante : configurez la stratégie IKE, la proposition IKE et la passerelle IKE, puis la stratégie IPsec et la proposition IPsec.