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 l’IKE, puis l’AS. 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 :

Note:

En mode FIPS 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 Junos.

Cette section aborde 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 suivante 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.

    Note:

    Pour plus d’informations sur les algorithmes de hachage sécurisés (SHA), voir le projet draft-eastlake-sha2-02.txtInternet , Algorithmes de hachage sécurisés (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 suivante authentication-method au niveau de la [edit services ipsec-vpn ike proposal proposal-name] hiérarchie :

Note:

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 pair 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, la même méthode d’authentification doit être configurée pour toutes les propositions référencées dans la stratégie.

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

Note:

En mode FIPS 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 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, algorithme de signature numérique à courbe elliptique (ECDSA) pour les modules 384 bits.

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

  • rsa-signatures—Algorithme à 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 système 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 suivante dh-group au niveau de la [edit services ipsec-vpn ike proposal proposal-name] hiérarchie :

Il peut s’agir de l’un des groupes suivants :

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

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

  • group5: spécifie que IKE utilise le groupe de modules premiers Diffie-Hellman 1 536 bits lors de l’exécution du nouvel échange Diffie-Hellman.

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

  • group19: spécifie que IKE utilise le groupe Diffie-Hellman à courbe elliptique aléatoire 256 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group20—-Spécifie que 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, les groupes15, 16 et 24 peuvent également être utilisés :

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

  • group16: spécifie que IKE utilise le groupe de modules premiers Diffie-Hellman 4 096 bits lors de l’exécution du nouvel échange Diffie-Hellman.

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

L’utilisation d’un groupe Diffie-Hellman basé sur un plus grand nombre de bits permet d’obtenir 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 temps 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 au encryption-algorithm 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înage de blocs avec une taille de clé de 24 octets ; La taille de sa clé est de 192 bits.

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

  • aes-128-cbc—Algorithme de chiffrement AES (Advanced Encryption Standard) 128 bits.

  • aes-192-cbc—Algorithme de chiffrement AES (Advanced Encryption Standard) 192 bits.

  • aes-256-cbc—Algorithme de chiffrement AES (Advanced Encryption Standard) 256 bits.

Note:

Pour obtenir la liste des clés faibles et semi-faibles de l’algorithme de chiffrement DES (Data Encryption Standard), reportez-vous à la 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, de sorte que 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 identiques aux 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 s’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 de sha1 pour l’authentification et 3des-cbc pour le chiffrement.

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

L’instruction lifetime-seconds définit la durée de vie d’une IKE SA. 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 suivante lifetime-seconds au niveau de la [edit services ipsec-vpn ike proposal proposal-name] hiérarchie :

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

Note:

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 pair 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 aucune autre durée de vie n’est 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.
Note:

Pour les propositions IKE, il n’existe qu’une seule valeur de 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 l’adresse d’un pair et les propositions nécessaires à cette connexion. Selon la méthode d’authentification utilisée, elle 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 stratégie IKE identique sur les deux homologues. L’homologue qui initie la négociation envoie toutes ses stratégies à l’homologue distant, et l’homologue distant essaie 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 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 du processus de gestion des clés (kmd) détermine quelle version d’IKE est utilisée dans une négociation. Si kmd est l’initiateur 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 à la proposition d’un pair distant.

Tout d’abord, vous configurez une ou plusieurs propositions IKE ; vous associez alors ces propositions à une politique IKE. Vous pouvez également hiérarchiser une liste de propositions utilisées par IKE dans l’instruction policy en répertoriant 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 aborde 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 au version niveau de la [edit services ipsec-vpn ike policy policy-name] hiérarchie :

Configuration du mode d’une stratégie IKE

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

Le mode agressif établit également une SA IKE et des clés authentifiées. Cependant, le mode agressif utilise deux fois moins de messages, a moins de pouvoir de négociation et ne protège pas l’identité. L’homologue peut utiliser le mode agressif ou principal pour lancer la négociation IKE ; L’homologue distant accepte le mode envoyé par l’homologue.

Note:

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 mode et spécifiez aggressive 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 stratégie IKE inclut une liste d’une ou plusieurs propositions associées à une stratégie 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 [edit services ipsec-vpn ike proposal proposal-name] clés prépartagées de la stratégie 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 authentication-method rsa-signatures au niveau de la [edit services ipsec-vpn ike proposal proposal-name] hiérarchie, les certificats numériques d’infrastructure à 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 suivante 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. En le configurant dans une stratégie IKE, vous pouvez 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 de confiance à utiliser avec un ensemble de services particulier. Cela vous permet de configurer des ensembles de services distincts pour les clients individuels auxquels vous fournissez des services IP. les ensembles de services distincts permettent de séparer logiquement un ensemble de sessions IKE d’un autre, en utilisant différentes adresses de passerelle locales ou la virtualisation. Pour configurer l’ensemble des autorités de certification approuvées, incluez l’instruction suivante 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. Il acquiert également la dernière CRL émise et vérifie que le numéro de série du certificat ne figure pas sur cette CRL.

Note:

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 peut 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 CRL 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 d’autorité de certification, 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 Junos OS.

Configuration de la description d’une stratégie IKE

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

Configuration des ID locaux et distants pour la négociation IKE Phase 1

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

À partir de Junos OS version 19.1R1, vous pouvez configurer l’un des types d’ID locaux en tant que nom distinctif et vous pouvez configurer l’un des types d’ID distant en tant que nom distinctif. Le champ de nom distinctif 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ériques.

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

  • CN=utilisateur

  • DC=exemple

  • DC=com

Pour la chaîne de conteneur, l’ordre des champs et de leurs valeurs doit correspondre exactement au nom distinctif 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 distinctif 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 la 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 :

L’option any-remote-id 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 contenant des valeurs SPI (Security Parameter Index) non valides peuvent être envoyés, et l’homologue récepteur abandonne ces paquets. Cela peut se produire, par exemple, lorsque l’un des homologues redémarre. À partir de la version 14.2 de Junos OS, vous pouvez activer la récupération du périphérique lors de la réception de paquets avec des SPI non valides en resynchronisant les SA.

Pour activer la récupération à partir de valeurs SPI non valides, incluez l’instruction suivante 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.

Note:

Les mises à jour apportées à la proposition IKE actuelle et à la configuration de la stratégie ne sont pas appliquées à l’IKE SA actuelle. 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 l’effacement de 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 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 aborde les 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 suivante 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 des 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 des 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 des paquets. Produit une valeur d’authentification 256 bits.

Note:

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 hmac-sha- 256-128 et que l’autre extrémité du tunnel contient le routeur 2 configuré avec l’algorithme d’authentification 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 en tant que 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 en tant que hmac-md5-96 à l’autre extrémité du tunnel, 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 et authentication- algorithm hmac-md5-96 au niveau de la [edit services ipsec-vpn ipsec proposal proposal-name] hiérarchie sur l’un 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 et 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, 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 puissant 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. En outre, pour une proposition par défaut, que le routeur prenne ou non en charge l’algorithme de chiffrement AES (Advanced Encryption Standard), l’algorithme 3des-cbc est choisi et non l’algorithme aes-cfb, ce 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 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 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 homologues ont une proposition.

Configuration de la description d’une proposition IPsec

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

Configuration de l’algorithme de chiffrement d’une proposition IPsec

Pour configurer l’algorithme de chiffrement d’une proposition IPsec, incluez l’instruction suivante 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 chiffrement dont la taille de bloc est de 24 octets ; La taille de sa clé est de 192 bits.

  • aes-128-cbc—Algorithme de chiffrement AES (Advanced Encryption Standard) 128 bits.

  • aes-192-cbc—Algorithme de chiffrement AES (Advanced Encryption Standard) 192 bits.

  • aes-256-cbc—Algorithme de chiffrement AES (Advanced Encryption Standard) 256 bits.

Note:

En mode FIPS 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 Junos.

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

  • aes-192-gcm—À partir de Junos OS version 17.3R1 pour MS-MPC et MS-MIC, algorithme de chiffrement 192 bits AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) avec une valeur de contrôle d’intégrité de 16 octets ICV.

  • aes-256-gcm—À partir de Junos OS version 17.3R1 pour MS-MPC et MS-MIC, algorithme de chiffrement 256 bits AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) avec une valeur de contrôle d’intégrité de 16 octets ICV.

  • des-cbc—Algorithme de chiffrement dont la taille de bloc est de 8 octets ; La taille de sa clé est de 48 bits.

Note:

Pour obtenir la liste des clés faibles et semi-faibles de l’algorithme de chiffrement DES (Data Encryption Standard), reportez-vous à la 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, de sorte que 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 identiques aux 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 efficace, vous devez toujours spécifier le protocole ESP (Encapsulating Security Payload) 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

Lorsqu’une SA IPsec dynamique est créée, deux types de durées de vie sont utilisés : hard et soft. La durée de vie matérielle spécifie la durée de vie de la SA. La durée de vie logicielle, qui est dérivée de la durée de vie matérielle, informe le système de gestion de clé 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 dure.

Note:

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 pair 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 aucune autre durée de vie n’est 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 hard lifetime, 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 logicielle, lifetime-diff est calculé initialement. Ensuite, selon que l’homologue est l’initiateur ou le répondeur, la durée de vie logicielle est calculée.

Le calcul de la différence de durée de vie est effectué comme suit :

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

    Note:

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

  • Si (3*hard-lifetime)/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*hard-lifetime)/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*hard-lifetime)/10 est INFÉRIEUR à 90 secondes, alors lifetime-diff = 90 secondes + gigue aléatoire entre 0 et 10 secondes.

Sur la base de lifetime-diff, la durée de vie logicielle est calculée comme suit :

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

  • Initiateur soft lifetime = hard-lifetime - lifetime-diff

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

Note:

La durée de vie douce 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 reclé.

Par exemple, si la durée de vie matérielle est configurée comme étant de 3600 secondes pour les SA IPSec :

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

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

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

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

Configuration du protocole d’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 stratégies 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 confidentialité persistante (PFS) et les propositions nécessaires à la connexion. Au cours de la négociation IPsec, IPsec recherche une proposition identique sur les deux homologues. L’homologue qui initie la négociation envoie toutes ses stratégies à l’homologue distant, et l’homologue distant essaie 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 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 hiérarchisées au niveau de chaque pair pour vous assurer qu’au moins une proposition correspond à la proposition d’un pair distant.

Tout d’abord, vous configurez une ou plusieurs propositions IPsec ; puis vous associez ces propositions à une stratégie IPsec. Vous pouvez hiérarchiser une liste de propositions utilisées par IPsec dans l’instruction policy en répertoriant 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 d’une stratégie IPsec, incluez l’instruction suivante description au niveau de la [edit services ipsec-vpn ipsec policy policy-name] hiérarchie :

Configuration de la confidentialité persistante parfaite

La confidentialité persistante parfaite (PFS) offre 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 que IKE utilise le groupe de modules premiers Diffie-Hellman 768 bits lors de l’exécution du nouvel échange Diffie-Hellman.

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

  • group5: spécifie que IKE utilise le groupe de modules premiers Diffie-Hellman 1 536 bits lors de l’exécution du nouvel échange Diffie-Hellman.

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

À partir de la version 17.4R1 de Junos OS, les groupes15, 16 et 24 peuvent également être utilisés pour la clé :

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

  • group16: spécifie que IKE utilise le groupe de modules premiers Diffie-Hellman 4 096 bits lors de l’exécution du nouvel échange Diffie-Hellman.

  • group24: spécifie que IKE utilise le groupe de modules premiers Diffie-Hellman de 2 048 bits avec le sous-groupe d’ordre premier de 256 bits lors de l’exécution du nouvel échange 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 stratégie IPsec

La stratégie IPsec inclut 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. Au cours de la négociation IPsec, la stratégie IPsec recherche une proposition IPsec identique sur les deux homologues. L’homologue qui initie la négociation envoie toutes ses stratégies à l’homologue distant, et l’homologue distant essaie de trouver une correspondance. Une correspondance est établie lorsque les 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 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éfinissez une stratégie IPsec, dynamic policy-1, associée à deux propositions (dynamic-1 et dynamic-2) :

Note:

Les mises à jour apportées à la proposition IPsec actuelle et à la configuration de la stratégie ne sont pas appliquées à 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 au Guide de référence des commandes de base et de services 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érer
Description
17.4R1
À partir de Junos OS version 17.4R1, ECDSA est pris en charge en mode FIPS Junos.
17.4R1
À partir de Junos OS version 17.4R1, ECDSA est pris en charge en mode FIPS Junos.
17.4R1
À partir de la version 17.4R1 de Junos OS, les groupes15, 16 et 24 peuvent également être utilisés
17.4R1
À partir de la version 17.4R1 de Junos OS, AES-GCM est pris en charge en mode FIPS Junos.
17.4R1
À partir de la version 17.4R1 de Junos OS, les groupes15, 16 et 24 peuvent également être utilisés pour la clé
17.3R1
À 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.
17.3R1
À 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 384 bits.
17.3R1
À partir de Junos OS version 17.3R1 pour MS-MPC et MS-MIC, algorithme de chiffrement 128 bits AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) avec une valeur de contrôle d’intégrité (ICV) de 16 octets.
17.3R1
À partir de Junos OS version 17.3R1 pour MS-MPC et MS-MIC, algorithme de chiffrement 192 bits AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) avec une valeur de contrôle d’intégrité de 16 octets ICV.
17.3R1
À partir de Junos OS version 17.3R1 pour MS-MPC et MS-MIC, algorithme de chiffrement 256 bits AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) avec une valeur de contrôle d’intégrité de 16 octets ICV.
14.2
À partir de la version 14.2 de Junos OS, vous pouvez activer la récupération du périphérique lors de la réception de paquets avec des SPI non valides en resynchronisant les SA.