Internet Key Exchange (IKE) pour VPN IPsec

Traitement des paquets IKE

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

Pendant ce temps, l’hôte source a renvoyé le paquet abandonné. En règle générale, lorsque 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.

Figure 1 : Paquet IKE pour les phases 1 et 2

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

• 0002 : la charge utile de négociation SA contient une définition pour une SA de phase 1 ou de phase 2.

• 0004 : la charge utile de la 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 : la charge utile d’échange de clés (KE) contient les informations nécessaires à l’exécution d’un échange de clés, telles qu’une valeur publique DH.

• 0020 : charge utile d’identification (IDx).

  • 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 utilisateur et IDur indique l’utilisateur répondeur.

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

• 0040 : charge utile de certificat (CERT).

• 0080 : charge utile de demande de certificat (CERT_REQ).

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

• 0200—La charge utile Signature (SIG) 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 : la charge utile ID fournisseur (VID) 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é à la .Figure 2

Figure 2 : En-tête générique de charge utile ISAKMP

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

Figure 3 : En-tête ISAKMP avec charges utiles ISAKMP génériques

Traitement IPsec des paquets

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

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

Figure 4 : Paquet IPsec : ESP en mode tunnel

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. Ceci est illustré dans Figure 5.

Figure 5 : En-tête IP externe (IP2) et en-tête ESP

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

Figure 6 : En-tête IP interne (IP1) et en-tête TCP

Configuration de IKEv2 dans Junos OS

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

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

La version IKE s’affiche dans la sortie des commandes opérationnelles et show security ike security-associationsshow security ipsec 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 d’une plage de paramètres de tunnel que vous acceptez. Junos OS fournit des jeux prédéfinis de propositions de phase 2 standard, compatibles et de base. Vous pouvez également définir des propositions de phase 2 personnalisées.

Comprendre la charge utile de configuration IKEv2

La charge utile de configuration est une option IKEv2 (Internet Key Exchange version 2) 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 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épondeur. Tableau 1 décrit les attributs de configuration IKEv2 pris en charge sur les pare-feu SRX Series.

Pour que le répondeur IKE fournisse des informations de provisionnement à l’initiateur, 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 à partir 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 configuration au niveau de la aaa access-profile profile-name hiérarchie [edit security ike gateway gateway-name].

À partir de Junos OS version 20.3R1, sur la gamme SRX5000 avec SPC3 et le pare-feu virtuel vSRX exécutant le processus iked, nous avons amélioré la charge utile de configuration IKEv2 pour :

• 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 d’un 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épondant a authentifié l’initiateur, il attribue une adresse IP à partir d’un pool d’adresses local ou via un serveur RADIUS. Selon la configuration, cette adresse IP est attribuée de manière dynamique à chaque connexion d’un homologue 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 basées sur la configuration du pool local correspondant. Si vous configurez à la fois le pool d’adresses local et le serveur RADIUS, l’adresse IP allouée par le 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 attribue l’adresse IP à la demande.

• Option supplémentaire, none introduite pour authentication-order. Reportez-vous à la section Ordre d’authentification (profil d’accès).

• Les messages de début 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 comptabilisation des messages de démarrage ou d’arrêt. Assurez-vous également que les pare-feu SRX Series et le serveur RADIUS disposent des paramètres appropriés pour suivre ces messages.

• L’introduction de la prise en charge d’IPv6 permet la mise en place de tunnels à double pile à l’aide de la charge utile de configuration. Pendant le processus de connexion, requêtes IKE pour les adresses IPv4 et IPv6. AAA n’autorise la connexion que si toutes les adresses demandées ont été attribuées avec succès. IKE met fin à la négociation si l’adresse IP demandée n’est pas alloué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 de la charge utile de configuration INTERNAL_IP4_ADDRESS le type d’attribut doivent se trouver dans la plage de sous-réseaux de l’interface point à multipoint associée.

À partir de Junos OS version 20.1R1, 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 SRX Series et le serveur RADIUS lorsque le pare-feu SRX Series demande une adresse IP au nom d’un homologue IPsec distant à l’aide de la charge utile de configuration IKEv2. Le serveur RADIUS fait correspondre les informations d’identification avant de fournir des informations IP au pare-feu SRX Series pour la demande de charge utile de configuration. Vous pouvez configurer le mot de passe commun à l’aide de l’instruction config-payload-password configured-password de configuration au niveau de la hiérarchie [edit security ike gateway gateway-name aaa access-profile access-profile-name].

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

Figure 7 affiche un flux de travail typique pour une charge utile de configuration IKEv2.

Figure 7 : Workflow typique de charge utile de configuration IKEv2

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

À partir de Junos OS version 20.1R1, nous prenons en charge la fonctionnalité de charge utile de configuration IKEv2 avec des interfaces point à point sur la gamme SRX5000 et le pare-feu virtuel vSRX exécuté en iked.

Comprendre le provisionnement de Pico Cell

La charge utile de configuration IKEv2 peut être utilisée pour propager des informations de provisionnement à partir d’un répondeur IKE, tel qu’un pare-feu SRX Series, vers plusieurs initiateurs, tels que des stations de base de cellules picocellulaires LTE dans un réseau cellulaire. Les pico cellules sont livrées en usine avec une configuration standard qui leur permet de se connecter au pare-feu SRX Series, mais les informations de provisionnement des pico cellules 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 d’approvisionnement complètes après avoir établi des connexions sécurisées avec les serveurs d’approvisionnement.

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 picocellule est expédiée de l’usine avec les informations suivantes :

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

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

   • Nom de domaine complet (FQDN) des serveurs d’approvisionnement 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 SRX Series à 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 d’exploitation du fournisseur de services.

4. Fourniture de services : lorsque la cellule pico entre en service, elle utilise un certificat unique qui contient des valeurs de nom distinctif (DN) et de nom de sujet alternatif avec un nom de domaine complet pour construire deux tunnels vers la passerelle sécurisée sur le pare-feu SRX Series : l’un pour le trafic OAM et l’autre pour le trafic de données 3GPP (Third-Generation Partnership Project).

Présentation

Avec IKEv2, la ressaisie et la réauthentification sont des processus distincts. La ressaisie établit de nouvelles clés pour l’association de sécurité IKE (SA) et réinitialise les compteurs d’ID de message, mais elle ne réauthentifie pas les homologues. La réauthentification vérifie que les homologues VPN conservent leur accès aux informations d’identification d’authentification. La réauthentification établit de nouvelles clés pour la SA IKE et les SA enfants ; Il n’est plus nécessaire de refaire les clés de toute SA IKE ou enfant en attente. Une fois que le nouvel IKE et les SA enfants sont créés, l’ancien IKE et les SA enfants sont supprimés.

La réauthentification IKEv2 est désactivée par défaut. Pour activer la réauthentification, configurez une fréquence de réauthentification comprise entre 1 et 100. La fréquence de réauthentification correspond au nombre de nouvelles clés IKE qui se produisent avant que la réauthentification ne se produise. Par exemple, si la fréquence de réauthentification configurée est égale à 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 égale à 2, la réauthentification a lieu tous les deux renouvellements de clés IKE. Si la fréquence de réauthentification configurée est égale à 3, la réauthentification se produit tous les trois renouvellements de clés 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 homologues et chaque pair 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

• Dead Peer Detection (DPD)

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

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

• Clusters de châssis en mode actif-actif et actif-passif pour les équipements SRX5400, SRX5600 et SRX5800

• Mise à niveau logicielle en service (ISSU) sur les appareils SRX5400, SRX5600 et SRX5800

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

Limitations

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

• Avec NAT-T, il est possible de créer une nouvelle SA IKE avec des ports différents de l’ancienne IKE SA. Dans ce scénario, l’ancienne IKE SA peut ne pas être supprimée.

• Dans un scénario NAT-T, l’initiateur derrière l’équipement NAT peut devenir le répondeur après une nouvelle authentification. Si la session NAT expire, le périphérique NAT peut rejeter 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 inférieure à 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 et la configuration EAP (Extensible Authentication Protocol) nécessitent que la SA IKE soit initiée par la même partie que la SA IKE d’origine, la réauthentification n’est pas prise en charge avec l’authentification EAP ou la charge utile de configuration.

Hiérarchie à plusieurs niveaux pour l’authentification des certificats

L’authentification basée sur un certificat est une méthode d’authentification prise en charge par les pare-feu SRX Series lors de la négociation IKE. Sur les grands réseaux, plusieurs autorités de certification (CA) peuvent émettre des certificats d’entité finale (EE) sur leurs terminaux respectifs. Il est courant d’avoir des autorités de certification distinctes pour chaque site, service ou organisation.

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 la même autorité de certification. Tous les pare-feu doivent avoir le même certificat d’autorité de certification inscrit pour la validation du certificat pair. La charge utile de certificat envoyée lors de la négociation IKE contient uniquement des certificats EE.

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

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

À partir de Junos OS version 18.1R1, la validation d’un homologue IKE configuré peut être effectuée avec un serveur ou un groupe de serveurs d’autorité de certification spécifié. Avec les chaînes de certificats, l’autorité de certification racine doit correspondre au groupe d’autorités de certification approuvées ou au serveur d’autorités de certification configuré dans la stratégie IKE

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

Figure 8 : Hiérarchie à plusieurs niveaux pour l’authentification basée sur les certificats

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

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

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

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

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

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

• Envoyer de grandes quantités 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’appareil utilise alors les ressources et manque de mémoire.

• Envoyez une grande quantité de paquets de IKE_AUTH de courrier indésirable avec une SPI_i et une SPI_r correctes sur l’initiateur et le répondeur, respectivement. Cela entraîne un manque de mémoire de l’appareil lors de la tentative de déchiffrement des paquets.

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

• Envoyez de grandes quantités de demandes de renouvellement de clé par seconde pendant les sessions IKE ouvertes complètes.

• Envoyez de grandes quantités de messages avec des ID de message distincts. L’appareil met alors tous les messages IKE entrants en file d’attente et manque de mémoire.

Comment protéger les implémentations 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 sur les implémentations IKE lorsque votre pare-feu exécute le processus iked (junos-ike package) pour le service VPN IPsec.

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 incluent la configuration d’une limitation de débit et d’une période de rétention pour les associations de sécurité IKE semi-ouvertes, ainsi qu’une gestion plus poussée des taux de change entrants pour les demandes de reclé. Pour assurer la protection, nous prenons les mesures suivantes :

• Pour les SA IKE semi-ouvertes :

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

  • Vous pouvez définir la limite du 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 maximal, le répondeur rejette les nouvelles connexions pour les SA IKEv1 et IKEv2. Pour plus de détails, reportez-vous à la section session (Security IKE) pour l’option max-count.

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

    • Dans le cas des IKEv2 SA, le répondeur appelle le mécanisme de cookie pour toute nouvelle connexion.

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

    Pour plus d’informations, reportez-vous aux sections session (Security IKE) pour les options thresholds, send-cookie et reduce-timeout.

  • Le répondeur peut ignorer les sessions en double. Pour plus de détails, reportez-vous à la section session (Security IKE) pour l’option discard-duplicate.

  • Vous pouvez définir des délais d’attente pour les phases d’échec d’authentification et d’échec d’initiation. Pour plus d’informations, reportez -vous aux sections session (Security IKE) pour les options backoff-timeouts, init-phase-failure et auth-phase-failure.

• Pour les SA IKE entièrement ouvertes :

  • Vous pouvez configurer des taux maximaux de demandes de renouvellement de clés entrantes pour limiter les demandes dans un scénario mis à l’échelle. Pour plus de détails, reportez-vous à la section session (Security IKE) pour l’option incoming-exchange-max-rates.

• Le répondeur peut bloquer une session IKE entrante des homologues en fonction de l’ID IKE de l’homologue. Pour plus de détails, reportez-vous à la section blocklists (Security IKE)RLI41450 Review this entire topic.

• 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 d’informations, consultez  Passerelle (IKE de sécurité).

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

Nous ne prenons pas en charge :

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

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

Méthodes de surveillance des 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 associationsde sécurité IKE matures et non matures. Pour plus d’informations, consultez show security ike security-associations.

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

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

• Utilisez la show security ike peers in-progress commande pour afficher les détails des IKE SA en cours, y compris les IKE SA semi-ouverts. Pour plus de détails, reportez-vous à la section show security ike peersRLI41450. Vous pouvez également voir les détails des homologues bloqués, en échec et en attente à l’aide de cette commande.

• Utilisez la clear security ike peers commande pour effacer les homologues IKE qui sont en cours d’interruption, bloqués, en échec ou en cours. Pour plus de détails, reportez-vous à la section clear security ike peersRLI41450.

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

• Les messages syslog d’IKED 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 plus de sécurité, Junos OS fournit aux utilisateurs des services de protection 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, reportez-vous à 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 de messages plus petits 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 que la fragmentation IKEv2 se produise, les deux homologues VPN doivent indiquer la prise en charge de la fragmentation en incluant la charge utile de notification IKEV2_FRAGMENTATION_SUPPORTED dans l’échange IKE_SA_INIT. Si les deux homologues indiquent la prise en charge de la fragmentation, c’est à l’initiateur de l’échange de messages de déterminer si la fragmentation IKEv2 est utilisée ou non.

Sur les pare-feu SRX Series, 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

Configuration

Sur les pare-feu SRX Series, la fragmentation IKEv2 est activée par défaut pour les messages IPv4 et IPv6. Pour désactiver la fragmentation IKEv2, utilisez l’instruction au niveau de la disable hiérarchie [edit security ike gateway gateway-name fragmentation]. Vous pouvez également utiliser l’instruction size pour configurer la taille du paquet auquel les messages sont fragmentés ; la taille du paquet est comprise entre 500 et 1300 octets. Si size elle n’est pas configurée, 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 dont la taille est supérieure à la taille de paquet configurée est fragmenté.

Une fois que la fragmentation IKEv2 est désactivée ou activée ou que la taille du fragment de paquet est 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.

Avertissements

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

• Découverte MTU de chemin.

• SNMP.