Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Associations de sécurité dynamique

Configuration des propositions IKE

Les associations de sécurité dynamique (SA) nécessitent une configuration IKE. Avec les SA dynamiques, vous configurez d’abord IKE, puis la SA. IKE crée les SA dynamiques et les négocie pour IPsec. La configuration IKE définit les algorithmes et les clés utilisés pour établir la connexion IKE sécurisée avec la passerelle de sécurité homologue.

Vous pouvez configurer une ou plusieurs propositions IKE. Chaque proposition est une liste d’attributs IKE pour protéger la connexion IKE entre l’hôte IKE et son homologue.

Pour configurer une proposition IKE, incluez l’instruction proposal et spécifiez un nom au niveau de la [edit services ipsec-vpn ike] hiérarchie :

Remarque :

En mode FIPS de Junos, ECDSA n’est pas pris en charge pour la méthode d’authentification dans Junos OS version 17.3R1. À partir de Junos OS version 17.4R1, ECDSA est pris en charge en mode FIPS de Junos.

Cette section comprend les rubriques suivantes :

Configuration de l’algorithme d’authentification pour une proposition IKE

Pour configurer l’algorithme d’authentification d’une proposition IKE, incluez l’instruction authentication-algorithm au niveau de la [edit services ipsec-vpn ike proposal proposal-name] hiérarchie :

L’algorithme d’authentification peut être l’un des suivants :

  • md5: produit un condensé de 128 bits.

  • sha1: produit un condensé de 160 bits.

  • sha-256: produit un condensé de 256 bits.

    Remarque :

    Pour des informations de référence sur les algorithmes de hachage sécurisé (SHA), voir le projet draft-eastlake-sha2-02.txtInternet , Algorithmes de hachage sécurisé (SHA et HMAC-SHA) (expire en juillet 2006).

Configuration de la méthode d’authentification pour une proposition IKE

Pour configurer la méthode d’authentification d’une proposition IKE, incluez l’instruction authentication-method au niveau de la [edit services ipsec-vpn ike proposal proposal-name] hiérarchie :

Remarque :

Dans IKEv1, la méthode d’authentification des SA est négociée avec l’homologue distant en fonction du type de méthode d’authentification configuré dans la proposition IKE. Dans IKEv2, une telle négociation n’est pas effectuée avec l’homologue distant. Au lieu de cela, chaque homologue IKE utilise la méthode d’authentification configurée localement pour lui.

Pour les SA dans IKEv2, la méthode d’authentification est la valeur par défaut IKEv1 si une méthode d’authentification n’est pas configurée dans la proposition IKE. Si vous configurez une méthode d’authentification pour IKEv2, vous devez configurer la même méthode d’authentification pour toutes les propositions référencées dans la stratégie.

La méthode d’authentification peut être l’une des suivantes :

Remarque :

En mode FIPS de Junos, ECDSA n’est pas pris en charge pour la méthode d’authentification dans Junos OS version 17.3R1. À partir de Junos OS version 17.4R1, ECDSA est pris en charge en mode FIPS de Junos.

  • ecdsa-signatures-256—À partir de la version 17.3R1 de Junos OS pour les MS-MPC et MS-MIC, algorithme de signature numérique à courbe elliptique (ECDSA) pour les modules 256 bits.

  • ecdsa-signatures-384—À partir de la version 17.3R1 de Junos OS pour les MS-MPC et MS-MIC, l’algorithme de signature numérique à courbe elliptique (ECDSA) pour les modules de 384 bits.

  • pre-shared-keys—Une clé dérivée d’un mécanisme hors bande ; La clé authentifie les échanges.

  • rsa-signatures: algorithme de clé publique (prend en charge le chiffrement et les signatures numériques).

Configuration du groupe Diffie-Hellman pour une proposition IKE

Diffie-Hellman est un schéma de cryptographie à clé publique qui permet à deux parties d’établir un secret partagé sur un canal de communication non sécurisé. Il est également utilisé dans IKE pour établir des clés de session.

Pour configurer le groupe Diffie-Hellman pour une proposition IKE, incluez l’instruction dh-group au niveau de la [edit services ipsec-vpn ike proposal proposal-name] hiérarchie :

Le groupe peut être l’un des suivants :

  • group1: indique qu’IKE utilise le groupe de modules premiers de Diffie-Hellman 768 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group2: indique qu’IKE utilise le groupe de modules premiers de Diffie-Hellman 1024 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group5: indique qu’IKE utilise le groupe de modules premiers Diffie-Hellman 1536 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group14: indique qu’IKE utilise le groupe de modules premiers de Diffie-Hellman de 2048 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group19: indique qu’IKE utilise le groupe Diffie-Hellman à courbe elliptique aléatoire de 256 bits lors du nouvel échange Diffie-Hellman.

  • group20—-Spécifie qu’IKE utilise le groupe Diffie-Hellman à courbe elliptique aléatoire de 384 bits lors de l’exécution du nouvel échange Diffie-Hellman.

À partir de la version 17.4R1 de Junos OS, vous pouvez également utiliser group15, group16 et group 24 :

  • group15: spécifie qu’IKE utilise le groupe de modules premiers de Diffie-Hellman de 3072 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group16: indique qu’IKE utilise le groupe de modules premiers de Diffie-Hellman 4096 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group24: spécifie qu’IKE utilise le groupe de modules premiers de Diffie-Hellman de 2048 bits avec le sous-groupe d’ordre premier de 256 bits lors de l’exécution du nouvel échange de Diffie-Hellman.

L’utilisation d’un groupe Diffie-Hellman basé sur un plus grand nombre de bits donne un tunnel IKE plus sécurisé que l’utilisation d’un groupe basé sur moins de bits. Toutefois, cette sécurité supplémentaire peut nécessiter un délai de traitement supplémentaire.

Configuration de l’algorithme de chiffrement pour une proposition IKE

Pour configurer l’algorithme de chiffrement d’une proposition IKE, incluez l’instruction encryption-algorithm au niveau de la [edit services ipsec-vpn ike proposal proposal-name] hiérarchie :

L’algorithme de chiffrement peut être l’un des suivants :

  • 3des-cbc- Algorithme de chiffrement par chaîne de blocs de chiffrement avec une taille de clé de 24 octets ; Sa taille de clé est de 192 bits.

  • des-cbc—Algorithme de chiffrement par chaîne de blocs de chiffrement avec une taille de clé de 8 octets ; Sa taille de clé est de 56 bits de long.

  • aes-128-cbc: algorithme de chiffrement AES (Advanced Encryption Standard) de 128 bits.

  • aes-192-cbc: algorithme de chiffrement AES (Advanced Encryption Standard) de 192 bits.

  • aes-256-cbc: algorithme de chiffrement AES (Advanced Encryption Standard) 256 bits.

Remarque :

Pour obtenir la liste des clés faibles et semi-faibles de l’algorithme de chiffrement DES (Data Encryption Standard), reportez-vous à la section RFC 2409, The Internet Key Exchange (IKE). Les algorithmes de chiffrement AES utilisent une implémentation logicielle qui a un débit beaucoup plus faible, donc DES reste l’option recommandée.

Pour 3des-cbc, les 8 premiers octets doivent différer des 8 octets suivants, et les 8 octets suivants doivent être les mêmes que les 8 octets troisièmes.

Si vous configurez une proposition d’authentification mais que vous n’incluez pas l’instruction encryption , le résultat est un chiffrement NULL. Certaines applications attendent ce résultat. Si vous ne configurez aucune valeur d’authentification ou de chiffrement spécifique, Junos OS utilise les valeurs par défaut pour sha1 l’authentification et 3des-cbc pour le chiffrement.

Configuration de la durée de vie d’une SA IKE

Le lifetime-seconds relevé définit la durée de vie d’une SA IKE. Lorsque la SA IKE expire, elle est remplacée par une nouvelle SA (et SPI) ou la connexion IPsec est interrompue.

Pour configurer la durée de vie d’une SA IKE, incluez l’instruction lifetime-seconds au niveau de la [edit services ipsec-vpn ike proposal proposal-name] hiérarchie :

Par défaut, la durée de vie de la SA IKE est de 3600 secondes. La plage est de 180 à 86 400 secondes.

Remarque :

Dans IKEv1, la durée de vie des SA est négociée avec l’homologue distant en fonction du type de durée de vie configuré dans la proposition IKE. Dans IKEv2, une telle négociation n’est pas effectuée avec l’homologue distant. Au lieu de cela, chaque homologue IKE utilise la durée de vie configurée localement pour lui.

Pour les SA dans IKEv2, la durée de vie est soit la valeur par défaut IKEv1 (si une autre durée de vie n’est pas configurée dans la proposition IKE), soit toutes les propositions IKEv2 de la stratégie IKE doivent être configurées avec la même valeur de durée de vie.
Remarque :

Pour les propositions IKE, il n’y a qu’une seule valeur à vie SA, spécifiée par Junos OS. Les propositions IPsec utilisent un mécanisme différent.

Exemple : configuration d’une proposition IKE

Configurer une proposition IKE :

Voir aussi

Configuration des stratégies IKE

Une stratégie IKE définit une combinaison de paramètres de sécurité (propositions IKE) à utiliser lors de la négociation IKE. Il définit une adresse de pair et les propositions nécessaires pour cette connexion. Selon la méthode d’authentification utilisée, il définit la clé pré-partagée pour l’homologue donné ou le certificat local. Au cours de la négociation IKE, IKE recherche une politique IKE qui est la même pour les deux pairs. L’homologue qui initie la négociation envoie toutes ses stratégies à l’homologue distant, qui tente de trouver une correspondance.

Une correspondance est établie lorsque les deux stratégies des deux homologues ont une proposition qui contient les mêmes attributs configurés. Si les durées de vie ne sont pas identiques, la durée de vie la plus courte entre les deux stratégies (de l’hôte et de l’homologue) est utilisée. La clé prépartagée configurée doit également correspondre à son homologue.

À partir de la version 11.4 de Junos OS, IKEv1 et IKEv2 sont pris en charge par défaut sur tous les routeurs M Series, MX Series et T Series. Vous pouvez configurer la phase IKE spécifique à prendre en charge pour la négociation. Toutefois, si seul IKEv1 est pris en charge, Junos OS rejette les négociations IKEv2. De même, si seul IKEv2 est pris en charge, Junos OS rejette toutes les négociations IKEv1.

Le démon KMD (Key Management Process) détermine la version d’IKE utilisée dans une négociation. Si kmd est l’initiateur de l’IKE, il utilise IKEv1 par défaut et conserve la version configurée pour les négociations. Si kmd est le répondeur IKE, il accepte les connexions d’IKEv1 et d’IKEv2.

Vous pouvez créer plusieurs propositions classées par ordre de priorité pour chaque pair afin de vous assurer qu’au moins une proposition correspond à celle d’un pair distant.

Tout d’abord, vous configurez une ou plusieurs propositions IKE ; alors vous associez ces propositions à une politique IKE. Vous pouvez également hiérarchiser une liste de propositions utilisées par IKE dans la policy déclaration en listant les propositions que vous souhaitez utiliser, de la première à la dernière.

Pour configurer une stratégie IKE, incluez l’instruction policy et spécifiez un nom de stratégie au niveau de la [edit services ipsec-vpn ike] hiérarchie :

Cette section comprend les rubriques suivantes :

Configuration de la phase IKE

À partir de la version 11.4 de Junos OS, IKEv1 et IKEv2 sont pris en charge par défaut sur tous les routeurs M Series, MX Series et T Series. Vous pouvez configurer la phase IKE spécifique à prendre en charge pour la négociation. Toutefois, si seul IKEv1 est pris en charge, Junos OS rejette les négociations IKEv2. De même, si seul IKEv2 est pris en charge, Junos OS rejette toutes les négociations IKEv1.

Pour configurer la phase IKE utilisée, incluez l’instruction version au niveau de la [edit services ipsec-vpn ike policy policy-name] hiérarchie :

Configuration du mode d’une stratégie IKE

La politique IKE comporte deux modes : agressif et principal. Par défaut, le mode principal est activé. Le mode principal utilise six messages, répartis en trois échanges, pour établir la SA de l’IKE. (Ces trois étapes sont la négociation IKE SA, un échange Diffie-Hellman et l’authentification du pair.) Le mode principal permet également à un pair de masquer son identité.

Le mode agressif établit également une SA IKE authentifiée et des clés. Cependant, le mode agressif utilise la moitié du nombre de messages, a moins de pouvoir de négociation et n’offre pas de protection de l’identité. L’homologue peut utiliser le mode agressif ou principal pour commencer la négociation IKE ; L’homologue distant accepte le mode envoyé par l’homologue.

Remarque :

La configuration du mode n’est requise que si l’option version est définie sur 1.

Pour configurer le mode d’une stratégie IKE, incluez l’instruction et aggressive specify mode ou main au niveau de la [edit services ipsec-vpn ike policy policy-name] hiérarchie :

Configuration des propositions dans une stratégie IKE

La politique IKE comprend une liste d’une ou plusieurs propositions associées à une politique IKE.

Pour configurer les propositions dans une stratégie IKE, incluez l’instruction proposals et spécifiez un ou plusieurs noms de proposition au niveau de la [edit services ipsec-vpn ike policy policy-name] hiérarchie :

Configuration de la clé prépartagée pour une stratégie IKE

Lorsque vous incluez l’instruction authentication-method pre-shared-keys au niveau de la hiérarchie, les clés prépartagées de stratégie [edit services ipsec-vpn ike proposal proposal-name] IKE authentifient les pairs. Vous devez configurer manuellement une clé prépartagée, qui doit correspondre à celle de son homologue. La clé prépartagée peut être une clé de texte ASCII (alphanumérique) ou une clé hexadécimale.

Pour configurer la clé prépartagée dans une stratégie IKE, incluez l’instruction pre-shared-key et une clé au niveau de la [edit services ipsec-vpn ike policy policy-name] hiérarchie :

La clé peut être l’une des suivantes :

  • ascii-text: clé de texte ASCII. Avec l’option des-cbc , la clé contient 8 caractères ASCII. Avec l’option 3des-cbc , la clé contient 24 caractères ASCII.

  • hexadecimal: clé hexadécimale. Avec l’option des-cbc , la clé contient 16 caractères hexadécimaux. Avec l’option 3des-cbc , la clé contient 48 caractères hexadécimaux.

Configuration du certificat local pour une stratégie IKE

Lorsque vous incluez l’instruction au niveau de la hiérarchie, les certificats numériques d’infrastructure authentication-method rsa-signatures [edit services ipsec-vpn ike proposal proposal-name] à clé publique (PKI) authentifient les pairs. Vous devez identifier un certificat local qui est envoyé à l’homologue pendant la phase d’authentification IKE.

Pour configurer le certificat local d’une stratégie IKE, incluez l’instruction local-certificate au niveau de la [edit services ipsec-vpn ike policy policy-name] hiérarchie :

L’instruction local-certificate spécifie l’identifiant utilisé pour obtenir le certificat de l’entité finale auprès de l’autorité de certification. Sa configuration dans une stratégie IKE vous permet d’utiliser un certificat distinct pour chaque homologue distant si nécessaire. Vous devez également spécifier l’identité de l’autorité de certification en configurant l’instruction ca-profile au niveau de la [edit security pki] hiérarchie.

Vous pouvez utiliser les profils configurés pour établir un ensemble d’autorités de certification approuvées à utiliser avec un ensemble de services particulier. Cela vous permet de configurer des ensembles de services distincts pour chaque client auquel vous fournissez des services IP ; les ensembles de services distincts permettent une séparation logique d’un ensemble de sessions IKE d’un autre, en utilisant différentes adresses de passerelle locale ou la virtualisation. Pour configurer l’ensemble des autorités de certification approuvées, incluez l’affirmation trusted-ca au niveau de la [edit services service-set service-set-name ipsec-vpn-options] hiérarchie :

Pour configurer une liste de révocation de certificats, reportez-vous à ce qui suit :

Configuration d’une liste de révocation de certificats

Une liste de révocation de certificats (CRL) contient une liste de certificats numériques qui ont été annulés avant leur date d’expiration. Lorsqu’un pair participant utilise un certificat numérique, il vérifie la signature et la validité du certificat. Elle acquiert également la liste de révocation de certificats la plus récente et vérifie que le numéro de série du certificat ne figure pas sur cette liste.

Remarque :

Par défaut, la vérification de la liste de révocation de certificats est activée. Vous pouvez désactiver la vérification de la liste de révocation de certificats en incluant l’instruction disable au niveau de la [edit security pki ca-profile ca-profile-name revocation-check] hiérarchie.

Par défaut, si le routeur ne parvient pas à accéder à l’URL LDAP (Lightweight Directory Access Protocol) ou à récupérer une liste de révocation de certificat valide, la vérification du certificat échoue et le tunnel IPsec n’est pas établi. Pour remplacer ce comportement et autoriser l’authentification de l’homologue IPsec lorsque la liste de révocation de certificats n’est pas téléchargée, incluez l’instruction disable on-download-failure au niveau de la [edit security pki ca-profile ca-profile-name revocation-check crl] hiérarchie.

Pour utiliser la liste de révocation de certificats de l’AC, vous devez inclure des instructions au niveau de la [edit security pki ca-profile ca-profile-name revocation-check] hiérarchie. Pour plus de détails, reportez-vous au Guide de configuration de base du système d’exploitation Junos OS.

Configuration de la description d’une stratégie IKE

Pour spécifier une description textuelle facultative pour une stratégie IKE, incluez l’instruction description au niveau de la [edit services ipsec-vpn ike policy policy-name hiérarchie :

Configuration des ID locaux et distants pour la négociation de la phase 1 d’IKE

Vous pouvez éventuellement spécifier des identificateurs locaux à utiliser dans la négociation de la phase 1 d’IKE. Si l’instruction local-id est omise, l’adresse de la passerelle locale est utilisée.

À partir de la version 19.1R1 de Junos OS, vous pouvez configurer l’un des types d’ID local en tant que nom unique et vous pouvez configurer l’un des types d’ID distant en tant que nom unique. Le champ de nom unique peut être un conteneur avec des valeurs de chaîne de conteneur ou un caractère générique avec des valeurs de chaîne générique.

Un nom distinctif est un nom utilisé avec les certificats numériques pour identifier un utilisateur de manière unique. Par exemple, un nom distinctif peut être :

  • CN=utilisateur

  • DC=exemple

  • DC=com

Pour la chaîne de conteneur, l’ordre des champs et leurs valeurs doivent correspondre exactement au nom unique dans le certificat numérique de l’homologue. Exemple : container ["C=US, ST=CA, L=Sunnyvale, O=Juniper, CN=local_neg, CN=test@juniper.net, OU=QA" "cn=admin, ou=eng, o=example, dc=net" ];

Pour la chaîne générique, le champ et la valeur configurés doivent correspondre au nom unique dans le certificat numérique de l’homologue, mais l’ordre des champs dans le DN n’a pas d’importance. Exemple : wildcard [ "L=Sunnyvale, O=Juniper" "C=US, ST=CA" ];

Pour spécifier un ou plusieurs ID locaux, incluez l’instruction local-id au niveau de la [edit services ipsec-vpn ike policy policy-name] hiérarchie :

Vous pouvez également spécifier les identificateurs de passerelle distante pour lesquels la stratégie IKE est utilisée. L’adresse de passerelle distante dans laquelle cette stratégie est définie est ajoutée par défaut.

Pour spécifier un ou plusieurs ID distants, incluez l’instruction remote-id au niveau de la [edit services ipsec-vpn ike policy policy-name] hiérarchie :

Cette any-remote-id option permet à n’importe quelle adresse distante de se connecter. Cette option n’est prise en charge que dans les configurations de points de terminaison dynamiques et ne peut pas être configurée avec des valeurs spécifiques.

Activation de la récupération SPI non valide

Lorsque les homologues d’une association de sécurité (SA) ne sont plus synchronisés, des paquets avec des valeurs SPI (Security Parameter Index) incorrectes peuvent être envoyés et l’homologue destinataire abandonne ces paquets. Par exemple, cela peut se produire lorsque l’un des pairs redémarre. À partir de la version 14.2 de Junos OS, vous pouvez permettre à l’équipement de récupérer lorsque des paquets avec des SPI non valides sont reçus en resynchronisant les SA.

Pour activer la récupération à partir de valeurs SPI non valides, incluez l’instruction respond-bad-spi au niveau de la [edit services ipsec-vpn ike policy] policy-name hiérarchie :

Exemple : configuration d’une stratégie IKE

Définissez deux stratégies IKE : policy 10.1.1.2 et policy 10.1.1.1. Chaque stratégie est associée à proposal-1 et proposal-2. La configuration suivante utilise uniquement IKEv1 pour la négociation.

Remarque :

Les mises à jour de la proposition actuelle de l’IKE et de la configuration de la politique ne s’appliquent pas à la SA actuelle de l’IKE ; les mises à jour sont appliquées aux nouvelles SA IKE.

Si vous souhaitez que les nouvelles mises à jour prennent effet immédiatement, vous devez effacer les associations de sécurité IKE existantes afin qu’elles soient rétablies avec la configuration modifiée. Pour plus d’informations sur la façon d’effacer l’association de sécurité IKE actuelle, consultez Effacer les services ipsec-vpn ike security-associations.

Voir aussi

Configuration des propositions IPsec

Une proposition IPsec répertorie les protocoles et les algorithmes (services de sécurité) à négocier avec l’homologue IPsec distant.

Pour configurer une proposition IPsec, incluez l’instruction proposal et spécifiez un nom de proposition IPsec au niveau de la [edit services ipsec-vpn ipsec] hiérarchie :

Cette section traite des sujets suivants :

Configuration de l’algorithme d’authentification pour une proposition IPsec

Pour configurer l’algorithme d’authentification d’une proposition IPsec, incluez l’instruction authentication-algorithm au niveau de la [edit services ipsec-vpn ipsec proposal proposal-name] hiérarchie :

L’algorithme d’authentification peut être l’un des suivants :

  • hmac-md5-96: algorithme de hachage qui authentifie les données de paquets. Il produit un condensé de 128 bits. Seuls 96 bits sont utilisés pour l’authentification.

  • hmac-sha1-96: algorithme de hachage qui authentifie les données de paquets. Il produit un condensé de 160 bits. Seuls 96 bits sont utilisés pour l’authentification.

  • hmac-sha-256-128: algorithme de hachage qui authentifie les données de paquets. Produit une valeur d’authentificateur de 256 bits.

Remarque :

Gardez à l’esprit les points suivants lorsque vous configurez l’algorithme d’authentification dans une proposition IPsec :

  • Lorsque les deux extrémités d’un tunnel VPN IPsec contiennent la même proposition IKE mais des propositions IPsec différentes, une erreur se produit et le tunnel n’est pas établi dans ce scénario. Par exemple, si une extrémité du tunnel contient le routeur 1 configuré avec l’algorithme d’authentification comme hmac-sha- 256-128 et l’autre extrémité du tunnel contient le routeur 2 configuré avec l’algorithme d’authentification comme hmac-md5-96, le tunnel VPN n’est pas établi.

  • Lorsque les deux extrémités d’un tunnel VPN IPsec contiennent la même proposition IKE mais des propositions IPsec différentes, et lorsqu’une extrémité du tunnel contient deux propositions IPsec pour vérifier si un algorithme moins sécurisé est sélectionné ou non, une erreur se produit et le tunnel n’est pas établi. Par exemple, si vous configurez deux algorithmes d’authentification pour une proposition IPsec comme hmac-sha-256-128 et hmac-md5-96 à une extrémité du tunnel, le routeur 1, et si vous configurez l’algorithme pour une proposition IPsec comme hmac-md5-96 à l’autre extrémité du tunnel, le routeur 2, le tunnel n’est pas établi et le nombre de propositions ne correspond pas.

  • Lorsque vous configurez deux propositions IPsec aux deux extrémités d’un tunnel, telles que les authentication-algorithm hmac-sha-256-128 instructions and authentication- algorithm hmac-md5-96 au niveau de la hiérarchie sur l’un [edit services ipsec-vpn ipsec proposal proposal-name] des tunnels, le routeur 1 (avec les algorithmes dans deux instructions successives pour spécifier l’ordre), et les authentication-algorithm hmac-md5-96 instructions and authentication- algorithm hmac-sha-256-128 au niveau de la [edit services ipsec-vpn ipsec proposal proposal-name] hiérarchie sur l’un des tunnels, le routeur 2 (avec les algorithmes dans deux instructions successives pour spécifier l’ordre, qui est l’ordre inverse du routeur 1), le tunnel est établi dans cette combinaison comme prévu car le nombre de propositions est le même aux deux extrémités et elles contiennent le même ensemble d’algorithmes. Cependant, l’algorithme d’authentification sélectionné est hmac-md5-96 et non l’algorithme plus fort de hmac-sha-256-128. Cette méthode de sélection de l’algorithme se produit parce que la première proposition d’appariement est sélectionnée. De plus, pour une proposition par défaut, que le routeur prenne en charge ou non l’algorithme de chiffrement AES (Advanced Encryption Standard), l’algorithme 3des-cbc est choisi et non l’algorithme AES-CFB, qui est dû au fait que le premier algorithme de la proposition par défaut est sélectionné. Dans l’exemple de scénario décrit ici, sur le routeur 2, si vous inversez l’ordre de la configuration de l’algorithme dans la proposition afin qu’il soit dans le même ordre que celui spécifié sur le routeur 1, hmac-sha-256-128 est sélectionné comme méthode d’authentification.

  • Vous devez connaître l’ordre des propositions dans une stratégie IPsec au moment de la configuration si vous souhaitez que la mise en correspondance des propositions se produise dans un certain ordre de préférence, par exemple l’algorithme le plus fort à prendre en compte en premier lorsqu’une correspondance est établie lorsque les deux stratégies des deux pairs ont une proposition.

Configuration de la description d’une proposition IPsec

Pour spécifier une description textuelle facultative pour une proposition IPsec, incluez l’instruction description au niveau de la [edit services ipsec-vpn ipsec proposal proposal-name] hiérarchie :

Configuration de l’algorithme de chiffrement pour une proposition IPsec

Pour configurer l’algorithme de chiffrement d’une proposition IPsec, incluez l’instruction encryption-algorithm au niveau de la [edit services ipsec-vpn ipsec proposal proposal-name] hiérarchie :

L’algorithme de chiffrement peut être l’un des suivants :

  • 3des-cbc- Algorithme de cryptage d’une taille de bloc de 24 octets ; Sa taille de clé est de 192 bits.

  • aes-128-cbc: algorithme de chiffrement AES (Advanced Encryption Standard) de 128 bits.

  • aes-192-cbc: algorithme de chiffrement AES (Advanced Encryption Standard) de 192 bits.

  • aes-256-cbc: algorithme de chiffrement AES (Advanced Encryption Standard) 256 bits.

Remarque :

En mode FIPS de Junos, AES-GCM n’est pas pris en charge dans Junos OS version 17.3R1. À partir de la version 17.4R1 de Junos OS, AES-GCM est pris en charge en mode FIPS de Junos.

  • aes-128-gcm—À partir de la version 17.3R1 de Junos OS pour MS-MPC et MS-MIC, algorithme de chiffrement 128 bits en mode Galois/compteur (AES-GCM) avec une valeur de contrôle d’intégrité (ICV) de 16 octets.

  • aes-192-gcm—À partir de la version 17.3R1 de Junos OS pour les MS-MPC et MS-MIC, algorithme de chiffrement 192 bits en mode Galois/compteur (AES-GCM) avec une valeur de contrôle d’intégrité de 16 octets.

  • aes-256-gcm—À partir de la version 17.3R1 de Junos OS pour les MS-MPC et MS-MIC, algorithme de chiffrement 256 bits en mode Galois/compteur (AES-GCM) avec une valeur de contrôle d’intégrité de 16 octets.

  • des-cbc- Algorithme de cryptage qui a une taille de bloc de 8 octets ; Sa taille de clé est de 48 bits.

Remarque :

Pour obtenir la liste des clés faibles et semi-faibles de l’algorithme de chiffrement DES (Data Encryption Standard), reportez-vous à la section RFC 2409, The Internet Key Exchange (IKE). Les algorithmes de chiffrement AES utilisent une implémentation logicielle qui a un débit beaucoup plus faible, donc DES reste l’option recommandée.

Pour 3des-cbc, les 8 premiers octets doivent différer des 8 octets suivants, et les 8 octets suivants doivent être les mêmes que les 8 octets troisièmes.

Si vous ne configurez pas de paramètres d’authentification ou de chiffrement spécifiques, Junos OS utilise les valeurs par défaut de sha1 pour l’authentification et 3des-cbc pour le chiffrement. Pour que le chiffrement NULL soit effectif, vous devez toujours spécifier le protocole ESP (Encapsulating Security Charge utile) pour l’algorithme de chiffrement NULL en incluant l’instruction protocol esp au niveau de la [edit services ipsec-vpn ipsec proposal proposal-name] hiérarchie, quelles que soient les autres configurations système.

Configuration de la durée de vie d’une SA IPsec

Lors de la création d’une SA IPsec dynamique, deux types de durée de vie sont utilisés : dure et douce. La durée de vie matérielle spécifie la durée de vie de l’AS. La durée de vie souple, qui est dérivée de la durée de vie matérielle, informe le système de gestion de clés IPsec que la SA est sur le point d’expirer. Cela permet au système de gestion des clés de négocier une nouvelle SA avant l’expiration de la durée de vie matérielle.

Remarque :

Dans IKEv1, la durée de vie des SA est négociée avec l’homologue distant en fonction du type de durée de vie configuré dans la proposition IPsec. Dans IKEv2, une telle négociation n’est pas effectuée avec l’homologue distant. Au lieu de cela, chaque homologue IKE utilise la durée de vie configurée localement pour lui.

Pour les SA dans IKEv2, la durée de vie est soit la valeur par défaut IKEv1 (si une autre durée de vie n’est pas configurée dans la proposition IPsec), soit toutes les propositions IKEv2 de la stratégie IPsec doivent être configurées avec la même valeur de durée de vie.

Pour configurer la valeur de durée de vie matérielle, incluez l’instruction lifetime-seconds et spécifiez le nombre de secondes au niveau de la [edit services ipsec-vpn ipsec proposal proposal-name] hiérarchie :

La durée de vie par défaut est de 28 800 secondes. La plage est de 180 à 86 400 secondes.

Pour calculer la durée de vie souple, lifetime-diff est calculé initialement. Ensuite, selon que l’homologue est l’initiateur ou le répondeur, la durée de vie souple est calculée.

Le calcul de la différence de durée de vie est effectué comme ci-dessous :

  • Si (3*hard-lifetime)/10 est SUPÉRIEUR à 850 secondes, alors lifetime-diff = 850 secondes + gigue entre 0 et 850 secondes.

    Remarque :

    La valeur de gigue passe de 0 à 850 à chaque installation de la SA IPsec et est réinitialisée à 0.

  • Si (3*durée de vie matérielle)/10 est SUPÉRIEUR à 600 secondes et INFÉRIEUR à 850, alors lifetime-diff = 600 secondes + gigue aléatoire entre 0 et 45 secondes.

  • Si (3*durée de vie matérielle)/10 est SUPÉRIEUR à 90 secondes et INFÉRIEUR à 600, alors lifetime-diff = 90 secondes + gigue aléatoire entre 0 et 45 secondes.

  • Si (3*durée de vie matérielle)/10 est INFÉRIEUR à 90 secondes, alors lifetime-diff = 90 secondes + gigue aléatoire entre 0 et 10 secondes.

Sur la base du différentiel de durée de vie, la durée de vie souple est calculée comme suit :

  • Si lifetime-diff est SUPÉRIEUR à hard-lifetime, soft lifetime = (9*hard-lifetime)/10

  • Durée de vie logicielle de l’initiateur = durée de vie dure - diff à vie

  • Durée de vie logicielle du répondeur = durée de vie dure - diff à vie + 45 secondes

Remarque :

La durée de vie logicielle de l’initiateur sera toujours inférieure à la durée de vie logicielle du répondeur. Il s’agit de s’assurer que la durée de vie logicielle de l’initiateur expirera en premier afin qu’il puisse lancer le processus de changement de clé.

Par exemple, si la durée de vie dure est configurée à 3600 secondes pour les SA IPSec :

  • La durée de vie maximale de l’initiateur est de : 3600 - 850 (la gigue est égale à 0) = 2750 secondes

  • La durée de vie molle minimale de l’initiateur est : 3600 - 850 - 850 (la gigue est égale à 850) = 1900 secondes

  • La durée de vie maximale du répondeur est de : 3600 - 850 (la gigue est égale à 0) + 45 = 2795 secondes

  • La durée de vie minimale du répondeur est de : 3600 - 850 - 850 (la gigue est égale à 850) + 45 = 1945 secondes

Configuration du protocole pour une SA dynamique

L’instruction protocol définit le protocole d’une SA dynamique. IPsec utilise deux protocoles pour protéger le trafic IP : ESP et AH. Le protocole ESP peut prendre en charge l’authentification, le chiffrement ou les deux. Le protocole AH est utilisé pour l’authentification forte. AH authentifie également le paquet IP. L’option bundle utilise l’authentification AH et le chiffrement ESP ; elle n’utilise pas l’authentification ESP, car AH fournit une authentification plus forte des paquets IP.

Pour configurer le protocole d’une SA dynamique, incluez l’instruction protocol et spécifiez l’option ah, espou bundle au niveau de la [edit services ipsec-vpn ipsec proposal proposal-name] hiérarchie :

Voir aussi

Configuration des politiques IPsec

Une stratégie IPsec définit une combinaison de paramètres de sécurité (propositions IPsec) utilisés lors de la négociation IPsec. Il définit la Perfect Forward Secrecy (PFS) et les propositions nécessaires à la connexion. Lors de la négociation IPsec, IPsec recherche une proposition identique sur les deux pairs. L’homologue qui initie la négociation envoie toutes ses stratégies à l’homologue distant, qui tente de trouver une correspondance.

Une correspondance est établie lorsque les deux stratégies des deux homologues ont une proposition qui contient les mêmes attributs configurés. Si les durées de vie ne sont pas identiques, la durée de vie la plus courte entre les deux stratégies (de l’hôte et de l’homologue) est utilisée.

Vous pouvez créer plusieurs propositions IPsec classées par ordre de priorité pour chaque homologue afin de vous assurer qu’au moins une proposition correspond à celle d’un homologue distant.

Tout d’abord, vous configurez une ou plusieurs propositions IPsec ; vous associez ces propositions à une politique IPsec. Vous pouvez hiérarchiser une liste de propositions utilisées par IPsec dans l’instruction policy en listant les propositions que vous souhaitez utiliser, de la première à la dernière.

Pour configurer une stratégie IPsec, incluez l’instruction policy , et spécifiez le nom de la stratégie et une ou plusieurs propositions à associer à la stratégie, au niveau de la [edit services ipsec-vpn ipsec] hiérarchie :

Cette section comprend les rubriques suivantes relatives à la configuration d’une stratégie IPsec :

Configuration de la description d’une stratégie IPsec

Pour spécifier une description textuelle facultative pour une stratégie IPsec, incluez l’instruction description au niveau de la [edit services ipsec-vpn ipsec policy policy-name] hiérarchie :

Configuration de Perfect Forward Secrecy

La confidentialité persistante parfaite (PFS) fournit une sécurité supplémentaire au moyen d’une valeur secrète partagée Diffie-Hellman. Avec PFS, si une clé est compromise, les clés précédentes et suivantes sont sécurisées car elles ne sont pas dérivées des clés précédentes. Cette instruction est facultative.

Pour configurer PFS, incluez l’instruction perfect-forward-secrecy et spécifiez un groupe Diffie-Hellman au niveau de la [edit services ipsec-vpn ipsec policy policy-name] hiérarchie :

La clé peut être l’une des suivantes :

  • group1: spécifie qu’IKE utilise le groupe de modules premiers de Diffie-Hellman 768 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group2: indique qu’IKE utilise le groupe de modules premiers de Diffie-Hellman 1024 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group5: spécifie qu’IKE utilise le module premier de Diffie-Hellman 1536 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group14: indique qu’IKE utilise le groupe de modules premiers de Diffie-Hellman 2048 bits lors de l’exécution du nouvel échange Diffie-Hellman.

À partir de la version 17.4R1 de Junos OS, group15, group16 et group 24 peuvent également être utilisés pour la clé :

  • group15: spécifie qu’IKE utilise le groupe de modules premiers de Diffie-Hellman de 3072 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group16: indique qu’IKE utilise le groupe de modules premiers de Diffie-Hellman 4096 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group24: spécifie qu’IKE utilise le groupe de modules premiers de Diffie-Hellman de 2048 bits avec le sous-groupe d’ordre premier de 256 bits lors de l’exécution du nouvel échange de Diffie-Hellman.

Les groupes numérotés les plus élevés offrent plus de sécurité que les groupes numérotés inférieurs, mais nécessitent plus de temps de traitement.

Configuration des propositions dans une politique IPsec

La stratégie IPsec comprend une liste d’une ou plusieurs propositions associées à une stratégie IPsec.

Pour configurer les propositions dans une stratégie IPsec, incluez l’instruction proposals et spécifiez un ou plusieurs noms de proposition au niveau de la [edit services ipsec-vpn ipsec policy policy-name] hiérarchie :

Stratégie IPsec pour les points de terminaison dynamiques

Une stratégie IPsec pour les points de terminaison dynamiques définit une combinaison de paramètres de sécurité (propositions IPsec) utilisés lors de la négociation IPsec entre des passerelles de sécurité homologues dynamiques, dans lesquelles les extrémités distantes des tunnels n’ont pas d’adresse IP affectée de manière statique. Lors de la négociation IPsec, la stratégie IPsec recherche une proposition IPsec identique sur les deux pairs. L’homologue qui initie la négociation envoie toutes ses stratégies à l’homologue distant, qui tente de trouver une correspondance. Une correspondance est établie lorsque les stratégies des deux pairs ont une proposition qui contient les mêmes attributs configurés. Si les durées de vie ne sont pas identiques, la durée de vie la plus courte entre les deux stratégies (de l’hôte et de l’homologue) est utilisée.

Si aucune stratégie n’est définie, toute stratégie proposée par l’homologue dynamique est acceptée.

Exemple : configuration d’une stratégie IPsec

Définir une politique IPsec, dynamic policy-1associée à deux propositions (dynamic-1 et dynamic-2) :

Remarque :

Les mises à jour de la proposition IPsec actuelle et de la configuration de la stratégie ne s’appliquent pas à la SA IPsec actuelle. les mises à jour sont appliquées aux nouvelles SA IPsec.

Si vous souhaitez que les nouvelles mises à jour prennent effet immédiatement, vous devez effacer les associations de sécurité IPsec existantes afin qu’elles soient rétablies avec la configuration modifiée. Pour plus d’informations sur la façon d’effacer l’association de sécurité IPsec actuelle, reportez-vous à la référence des commandes Principes de base et services du système Junos OS.

Voir aussi

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libération
Descriptif
17.4R1
À partir de Junos OS version 17.4R1, ECDSA est pris en charge en mode FIPS de Junos.
17.4R1
À partir de Junos OS version 17.4R1, ECDSA est pris en charge en mode FIPS de Junos.
17.4R1
À partir de la version 17.4R1 de Junos OS, il est également possible d’utiliser group15, group16 et group 24
17.4R1
À partir de la version 17.4R1 de Junos OS, AES-GCM est pris en charge en mode FIPS de Junos.
17.4R1
À partir de la version 17.4R1 de Junos OS, group15, group16 et group 24 peuvent également être utilisés pour la clé
17.3R1
À partir de Junos OS version 17.3R1 pour les MS-MPC et MS-MIC, algorithme de signature numérique à courbe elliptique (ECDSA) pour les modules 256 bits.
17.3R1
À partir de la version 17.3R1 de Junos OS pour les MS-MPC et MS-MIC, l’algorithme de signature numérique à courbe elliptique (ECDSA) pour les modules 384 bits.
17.3R1
À partir de la version 17.3R1 de Junos OS pour MS-MPC et MS-MIC, algorithme de chiffrement 128 bits en mode Galois/compteur (AES-GCM) avec une valeur de contrôle d’intégrité (ICV) de 16 octets.
17.3R1
À partir de la version 17.3R1 de Junos OS pour MS-MPC et MS-MIC, algorithme de chiffrement 192 bits en mode Galois/compteur (AES-GCM) avec une valeur de contrôle d’intégrité de 16 octets.
17.3R1
À partir de la version 17.3R1 de Junos OS pour les MS-MPC et les MS-MIC, algorithme de chiffrement 256 bits en mode Galois/compteur (AES-GCM) avec une valeur de contrôle d’intégrité de 16 octets.
14.2
À partir de la version 14.2 de Junos OS, vous pouvez permettre à l’équipement de récupérer lorsque des paquets avec des SPI non valides sont reçus en resynchronisant les SA.