Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Présentation d’IPsec

Présentation de Junos VPN Site Secure

Junos VPN Site Secure est une suite de fonctionnalités IPsec prises en charge sur les cartes de ligne multiservices (MS-DPC, MS-MPC et MS-MIC), appelées services IPsec dans les versions de Junos antérieures à la version 13.2. Dans Junos OS version 13.2 et ultérieure, le terme fonctionnalités IPsec est utilisé exclusivement pour désigner l’implémentation d’IPsec sur les PIC Adaptive Services et Encryption Services. Cette rubrique vous donne une vue d’ensemble de Junos VPN Site Secure et comporte les sections suivantes :

IPsec (en anglais)

L’architecture IPsec fournit une suite de sécurité pour les couches réseau IP version 4 (IPv4) et IP version 6 (IPv6). La suite offre des fonctionnalités telles que l’authentification de l’origine, l’intégrité des données, la confidentialité, la protection contre la relecture et la non-répudiation de la source. En plus d’IPsec, Junos OS prend également en charge l’Internet Key Exchange (IKE), qui définit des mécanismes de génération et d’échange de clés, et gère les associations de sécurité (SA).

IPsec définit également une association de sécurité et un cadre de gestion des clés qui peuvent être utilisés avec n’importe quel protocole de couche réseau. La SA spécifie la stratégie de protection à appliquer au trafic entre deux entités de couche IP. IPsec fournit des tunnels sécurisés entre deux pairs.

Associations de sécurité

Pour utiliser les services de sécurité IPsec, vous devez créer des SA entre les hôtes. Une SA est une connexion simplex qui permet à deux hôtes de communiquer entre eux de manière sécurisée au moyen d’IPsec. Il existe deux types de SA :

  • Les SA manuelles ne nécessitent aucune négociation ; Toutes les valeurs, y compris les clés, sont statiques et spécifiées dans la configuration. Les SA manuelles définissent de manière statique les valeurs, les algorithmes et les clés de l’indice des paramètres de sécurité (SPI) à utiliser, et nécessitent des configurations correspondantes aux deux extrémités du tunnel. Chaque pair doit avoir les mêmes options configurées pour que la communication ait lieu.

  • Les SA dynamiques nécessitent une configuration supplémentaire. Avec les SA dynamiques, vous configurez d’abord l’IKE, puis l’AS. IKE crée des associations de sécurité dynamiques ; il négocie les SA 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. Cette connexion est ensuite utilisée pour convenir dynamiquement des clés et d’autres données utilisées par la SA IPsec dynamique. L’IKE SA est d’abord négociée, puis utilisée pour protéger les négociations qui déterminent les SA IPsec dynamiques.

IKE

IKE est un protocole de gestion des clés qui crée des SA dynamiques. il négocie les SA pour IPsec. Une configuration IKE définit les algorithmes et les clés utilisés pour établir une connexion sécurisée avec une passerelle de sécurité homologue.

IKE effectue les tâches suivantes :

  • Négocie et gère les paramètres IKE et IPsec.

  • Authentifie l’échange sécurisé de clés.

  • Fournit une authentification mutuelle des pairs au moyen de secrets partagés (pas de mots de passe) et de clés publiques.

  • Assure la protection de l’identité (en mode principal).

Deux versions du protocole IKE (IKEv1 et IKEv2) sont désormais prises en charge. IKE négocie les attributs de sécurité et établit des secrets partagés pour former l’IKE SA bidirectionnel. Dans IKE, les SA IPsec entrantes et sortantes sont établies et l’IKE SA sécurise les échanges. À 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. IKE génère également du matériel d’incrustation, fournit une confidentialité persistante parfaite et échange des identités.

À partir de la version 18.2R1 de Junos OS, vous pouvez configurer un routeur MX Series avec des MS-MPC ou MS-MIC pour qu’il agisse uniquement en tant que répondeur IKE. Dans ce mode de répondeur uniquement, le routeur MX Series ne lance pas de négociations IKE, mais répond uniquement aux négociations IKE initiées par la passerelle homologue. Cela peut être nécessaire lors de l’interopérabilité avec des équipements d’autres fournisseurs, tels que des périphériques Cisco. Étant donné que la MX Series ne prend pas en charge les valeurs de protocole et de port dans le sélecteur de trafic, elle ne peut pas initier de tunnel IPsec vers la passerelle homologue d’un autre fournisseur qui attend ces valeurs. En configurant le mode de réponse uniquement sur le MX Series, le MX peut accepter le sélecteur de trafic dans la négociation IKE initiée à partir de la passerelle homologue.

À partir de Junos OS version 18.2R1, vous pouvez configurer le routeur MX Series avec des MS-MPC ou des MS-MIC afin qu’ils envoient uniquement le certificat de l’entité finale pour l’authentification IKE basée sur les certificats au lieu de la chaîne de certificats complète. Cela permet d’éviter la fragmentation IKE.

À partir de Junos OS version 19.1R1, la prise en charge des noms distinctifs est ajoutée à l’identification IKE (IKE ID) utilisée pour la validation des périphériques homologues VPN lors de la négociation IKE. L’ID IKE reçu par un routeur MX Series d’un pair distant peut être une adresse IPv4 ou IPv6, un nom d’hôte, un nom de domaine complet (FQDN) ou un nom distinctif (DN). L’ID IKE envoyé par l’homologue distant doit correspondre à ce qui est attendu par le routeur MX Series. Dans le cas contraire, la validation de l’ID IKE échoue et le VPN n’est pas établi.

Non-prise en charge de NAT-T

Avant Junos OS version 17.4R1, la traversée de traduction d’adresses réseau (NAT-T) n’était pas prise en charge pour la suite de fonctionnalités IPsec Junos VPN Site Secure sur les routeurs MX Series. Vous devez donc désactiver NAT-T sur le routeur MX Series pour éviter d’exécuter un NAT-T non pris en charge (voir Désactivation de NAT-T sur les routeurs MX Series pour la gestion du NAT avec des paquets protégés par IPsec). NAT-T est une méthode permettant de contourner les problèmes de traduction d’adresses IP rencontrés lorsque des données protégées par IPsec passent par un périphérique NAT pour la traduction d’adresses.

Comparaison d’IPsec sur les ES PICS et de Junos VPN Site Secure sur les cartes LIne multiservices

Le Tableau 1 compare la configuration de premier niveau des fonctionnalités IPsec sur les interfaces ES PIC et IPsec sur les PIC Adaptive Services et Junos VPN Site Secure sur les cartes de ligne multiservices.

Tableau 1 : Équivalences d’instructions pour les interfaces ES et AS

ES PIC Configuration

Configuration des cartes de ligne AS et multiservices

 
[edit security ipsec]
proposal {...}

[edit services ipsec-vpn ipsec]
proposal {...}

[edit security ipsec]
policy {...}

[edit services ipsec-vpn ipsec]
policy {...}

[edit security ipsec]
security-association sa-dynamic {...}

[edit services ipsec-vpn rule rule-name]
term term-name match-conditions {...}
then dynamic {...}]

[edit security ipsec]
security-association sa-manual {...}

[edit services ipsec-vpn rule rule-name]
term term-name match-conditions {...}
then manual {...}]

[edit security ike]
proposal {...}

[edit services ipsec-vpn ike]
proposal {...}

[edit security ike]
policy {...}

[edit services ipsec-vpn ike]
policy {...}

Non disponible

 
[edit services ipsec-vpn]
rule-set {...}

Non disponible

 
[edit services ipsec-vpn]
service-set {...}

[edit interfaces es-fpc/pic/port]
tunnel source address

[edit services ipsec-vpn service-set set-name ipsec-vpn local-gateway address]

[edit interfaces es-fpc/pic/port]
tunnel destination address

[edit services ipsec-vpn rule rule-name]
remote-gateway address
Note:

Bien qu’un grand nombre des mêmes instructions et propriétés soient valides sur les deux plates-formes (MultiServices et ES), les configurations ne sont pas interchangeables. Vous devez valider une configuration complète pour le type de PIC installé sur votre routeur.

Algorithmes d’authentification

L’authentification est le processus de vérification de l’identité de l’expéditeur. Les algorithmes d’authentification utilisent une clé partagée pour vérifier l’authenticité des appareils IPsec. Junos OS utilise les algorithmes d’authentification suivants :

  • Message Digest 5 (MD5) utilise une fonction de hachage unidirectionnelle pour convertir un message de longueur arbitraire en un condensé de message de longueur fixe de 128 bits. En raison du processus de conversion, il est mathématiquement impossible de calculer le message d’origine en le calculant à rebours à partir du résumé du message résultant. De même, une modification d’un seul caractère dans le message entraînera la génération d’un numéro de résumé de message très différent.

    Pour vérifier que le message n’a pas été altéré, Junos OS compare le résumé de message calculé avec un résumé de message déchiffré avec une clé partagée. Junos OS utilise la variante du code d’authentification de message haché (HMAC) MD5 qui fournit un niveau supplémentaire de hachage. MD5 peut être utilisé avec l’en-tête d’authentification (AH), la charge utile de sécurité d’encapsulation (ESP) et l’Internet Key Exchange (IKE).

  • L’algorithme de hachage sécurisé 1 (SHA-1) utilise un algorithme plus puissant que MD5. SHA-1 prend un message de moins de 264 bits et produit un condensé de message de 160 bits. Le récapitulatif volumineux des messages garantit que les données n’ont pas été modifiées et qu’elles proviennent de la bonne source. Junos OS utilise la variante HMAC SHA-1 qui offre un niveau supplémentaire de hachage. SHA-1 peut être utilisé avec AH, ESP et IKE.

  • SHA-256, SHA-384 et SHA-512 (parfois regroupés sous le nom de SHA-2) sont des variantes de SHA-1 et utilisent des résumés de messages plus longs. Junos OS prend en charge la version SHA-256 de SHA-2, qui peut traiter toutes les versions du chiffrement AES (Advanced Encryption Standard), AES (Data Encryption Standard) et 3DES (Triple DES).

Algorithmes de chiffrement

Le chiffrement encode les données dans un format sécurisé afin qu’elles ne puissent pas être déchiffrées par des utilisateurs non autorisés. À l’instar des algorithmes d’authentification, une clé partagée est utilisée avec des algorithmes de chiffrement pour vérifier l’authenticité des appareils IPsec. Junos OS utilise les algorithmes de chiffrement suivants :

  • Le chiffrement par blocs de chiffrement standard (DES-CBC) est un algorithme symétrique de blocage de clé secrète. DES utilise une taille de clé de 64 bits, où 8 bits sont utilisés pour la détection des erreurs et les 56 bits restants fournissent le chiffrement. DES effectue une série d’opérations logiques simples sur la clé partagée, y compris des permutations et des substitutions. CBC prend le premier bloc de 64 bits de sortie de DES, combine ce bloc avec le deuxième bloc, le réinjecte dans l’algorithme DES et répète ce processus pour tous les blocs suivants.

  • Triple DES-CBC (3DES-CBC) est un algorithme de chiffrement similaire à DES-CBC, mais qui fournit un résultat de chiffrement beaucoup plus fort, car il utilise trois clés pour un chiffrement 168 bits (3 x 56 bits). 3DES fonctionne en utilisant la première clé pour chiffrer les blocs, la deuxième clé pour déchiffrer les blocs et la troisième clé pour rechiffrer les blocs.

  • Advanced Encryption Standard (AES) est une méthode de chiffrement de nouvelle génération basée sur l’algorithme de Rijndael développé par les cryptographes belges Dr. Joan Daemen et Dr. Vincent Rijmen. Il utilise un bloc de 128 bits et trois tailles de clé différentes (128, 192 et 256 bits). En fonction de la taille de la clé, l’algorithme effectue une série de calculs (10, 12 ou 14 tours) qui incluent la substitution d’octets, le mélange de colonnes, le décalage de lignes et l’ajout de clés. L’utilisation d’AES en conjonction avec IPsec est définie dans la RFC 3602, L’algorithme de chiffrement AES-CBC et son utilisation avec IPsec.

  • À partir de la version 17.3R1 de Junos OS, la norme de chiffrement avancée en mode Galois/compteur (AES-GCM) est prise en charge pour les MS-MPC et MS-MIC. Toutefois, 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-GCM est un algorithme de chiffrement authentifié conçu pour fournir à la fois l’authentification et la confidentialité. AES-GCM utilise un hachage universel sur un champ de Galois binaire pour fournir un chiffrement authentifié et permet un chiffrement authentifié à des débits de données de plusieurs dizaines de Gbit/s.

Voir aussi

Protocoles IPsec

Les protocoles IPsec déterminent le type d’authentification et de chiffrement appliqué aux paquets sécurisés par le routeur. Junos OS prend en charge les protocoles IPsec suivants :

  • AH : défini dans la RFC 2402, AH assure l’intégrité sans connexion et l’authentification de l’origine des données pour les paquets IPv4 et IPv6. Il offre également une protection contre les reprises. AH authentifie autant d’en-têtes IP que possible, ainsi que les données de protocole de niveau supérieur. Toutefois, certains champs d’en-tête IP peuvent changer en cours de route. Étant donné que la valeur de ces champs peut ne pas être prévisible par l’expéditeur, ils ne peuvent pas être protégés par AH. Dans un en-tête IP, AH peut être identifié par une valeur de 51 dans le Protocol champ d’un paquet IPv4 et le Next Header champ d’un paquet IPv6. La Figure 1 illustre la protection IPsec offerte par AH.

    Note:

    AH n’est pas pris en charge sur les routeurs T Series, M120 et M320.

Figure 1 : protocole AH Protocol AH

 

  • ESP : défini dans la RFC 2406, ESP peut fournir le chiffrement et la confidentialité des flux de trafic limités, ou l’intégrité sans connexion, l’authentification de l’origine des données et un service anti-rejeu. Dans un en-tête IP, ESP peut être identifié une valeur de 50 dans le Protocol champ d’un paquet IPv4 et le Next Header champ d’un paquet IPv6. La figure 2 illustre la protection IPsec offerte par ESP.

Figure 2 : protocole ESP Protocol ESP

  • Bundle : lorsque vous comparez AH et ESP, les deux protocoles présentent des avantages et des inconvénients. ESP fournit un niveau décent d’authentification et de chiffrement, mais ne le fait que pour une partie du paquet IP. À l’inverse, bien qu’AH ne fournisse pas de chiffrement, il fournit une authentification pour l’ensemble du paquet IP. Pour cette raison, Junos OS propose une troisième forme de protocole IPsec appelée bundle de protocoles. L’option groupée offre une combinaison hybride d’authentification AH et de chiffrement ESP.

Voir aussi

Transfert par trajets multiples IPsec avec encapsulation UDP

IPsec fournit des tunnels sécurisés entre deux homologues, et les paquets encapsulés IPsec ont des en-têtes IP qui contiennent des adresses IP de point de terminaison de tunnel qui ne changent pas. Il en résulte la sélection d’un chemin de transfert unique entre les homologues, comme illustré sur la Figure 3. Lorsque le trafic IPsec circule entre des datacenters comptant des milliers d’hôtes, cette sélection de chemin unique limite le débit.

Figure 3 : IPsec avec un chemin IPsec with One Forwarding Path de transfert unique

Vous pouvez résoudre ce problème en activant l’encapsulation UDP des paquets IPsec, qui ajoute un en-tête UDP après l’en-tête ESP, comme illustré à la Figure 4. Les routeurs intermédiaires reçoivent ainsi des informations sur les couches 3 et 4, et les paquets IPsec sont transférés via plusieurs chemins, comme illustré sur la Figure 5. Vous activez l’encapsulation UDP pour l’ensemble de services.

Figure 4 : en-tête Appended UDP Header UDP ajouté
Figure 5 : IPsec avec plusieurs chemins IPsec with Multiple Forwarding Paths de transfert

Vous pouvez configurer le port de destination UDP ou utiliser la valeur par défaut 4565. Vous ne pouvez pas configurer le port 4500 comme port de destination, car il s’agit d’un port bien connu pour les traversées NAT.

Junos OS génère le port UDP source par le biais d’une fonction de hachage qui opère sur les données suivantes :

  • Adresse IP source

  • Adresse IP de destination

  • Protocole de transport

  • Port source de transport

  • Port de destination de transport

  • Un nombre aléatoire

Seuls les deux derniers octets du hachage résultant sont utilisés, de sorte que les détails de l’en-tête IP interne sont masqués.

Lorsque NAT-T est détecté, seule l’encapsulation UDP NAT-T se produit, et non l’encapsulation UDP pour les paquets IPsec.

Voir aussi

Normes IPsec et IKE prises en charge

Sur les routeurs équipés d’une ou plusieurs MS-MPC, MS-MIC ou DPC, les versions Canada et américaine de Junos OS prennent en charge pour la grande partie les RFC suivantes, qui définissent les normes de sécurité IP (IPsec) et d’Internet Key Exchange (IKE).

  • RFC 2085, Authentification IP HMAC-MD5 avec prévention du rejeu

  • RFC 2401, Architecture de sécurité pour le protocole Internet (obsolète par RFC 4301)

  • RFC 2402, En-tête d’authentification IP (obsolète par RFC 4302)

  • RFC 2403, Utilisation de HMAC-MD5-96 dans ESP et AH

  • RFC 2404, Utilisation de HMAC-SHA-1-96 dans ESP et AH (obsolète par RFC 4305)

  • RFC 2405, Algorithme de chiffrement ESP DES-CBC avec Explicit IV

  • RFC 2406, IP Encapsulating Security Payload (ESP) (obsolète par les RFC 4303 et RFC 4305)

  • RFC 2407, Domaine d’interprétation de la sécurité IP de l’Internet pour ISAKMP (obsolète par la RFC 4306)

  • RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP) (obsolète par RFC 4306)

  • RFC 2409, The Internet Key Exchange (IKE) (obsolète par RFC 4306)

  • RFC 2410, L’algorithme de chiffrement NULL et son utilisation avec IPsec

  • RFC 2451, Algorithmes de chiffrement en mode CBC de l’ESP

  • RFC 2560, X.509 Protocole d’état de certificat en ligne d’infrastructure à clé publique de l’Internet - OCSP

  • RFC 3193, Sécurisation de L2TP à l’aide d’IPsec

  • RFC 3280, Profil de certificat d’infrastructure à clé publique Internet X.509 et liste de révocation de certificats (CRL)

  • RFC 3602, L’algorithme de chiffrement AES-CBC et son utilisation avec IPsec

  • RFC 3948, Encapsulation UDP de paquets ESP IPsec

  • RFC 4106, Utilisation du mode Galois/Compteur (GCM) dans la charge utile de sécurité d’encapsulation IPsec (ESP)

  • RFC 4210, Internet X.509 Protocole de gestion des certificats d’infrastructure à clé publique (CMP)

  • RFC 4211, Internet X.509 Format de message de demande de certificat d’infrastructure à clé publique (CRMF)

  • RFC 4301, Architecture de sécurité pour le protocole Internet

  • RFC 4302, En-tête d’authentification IP

  • RFC 4303, Charge utile de sécurité à encapsulation IP (ESP)

  • RFC 4305, Exigences d’implémentation d’algorithmes cryptographiques pour l’encapsulation de la charge utile de sécurité (ESP) et de l’en-tête d’authentification (AH)

  • RFC 4306, Protocole Internet Key Exchange (IKEv2)

  • RFC 4307, Algorithmes cryptographiques à utiliser dans l’Internet Key Exchange version 2 (IKEv2)

  • RFC 4308, Suites cryptographiques pour IPsec

    Seul Suite VPN-A est pris en charge dans Junos OS.

  • RFC 4754, Authentification IKE et IKEv2 à l’aide de l’algorithme de signature numérique à courbe elliptique (ECDSA)

  • RFC 4835, Exigences d’implémentation d’algorithmes cryptographiques pour l’encapsulation de la charge utile de sécurité (ESP) et de l’en-tête d’authentification (AH)

  • RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2) (obsolète par RFC 7296)

  • RFC 7296, Internet Key Exchange Protocol version 2 (IKEv2)

  • RFC 7427, Authentification des signatures dans l’Internet Key Exchange version 2 (IKEv2)

  • RFC 7634, ChaCha20, Poly1305, et leur utilisation dans l’Internet Key Exchange Protocol (IKE) et IPsec

  • RFC 8200, Protocole Internet, version 6 (IPv6) Spécification

Junos OS prend partiellement en charge les RFC suivantes pour IPsec et IKE :

  • RFC 3526, Groupes Diffie-Hellman exponentiels (MODP) pour Internet Key Exchange (IKE)

  • RFC 5114, Groupes Diffie-Hellman supplémentaires à utiliser avec les normes IETF

  • RFC 5903, Groupes de courbes elliptiques modulo a prime (groupes ECP) pour IKE et IKEv2

Les RFC et les projets Internet suivants ne définissent pas de normes, mais fournissent des informations sur IPsec, IKE et les technologies associées. L’IETF les classe comme « informatifs ».

  • RFC 2104, HMAC : hachage de clé pour l’authentification des messages

  • RFC 2412, Protocole de détermination des clés OAKLEY

  • RFC 3706, Méthode basée sur le trafic pour détecter les homologues IKE (Internet Key Exchange) morts

  • Internet draft draft-eastlake-sha2-02.txt, US Secure Hash Algorithms (SHA et HMAC-SHA) (expire en juillet 2006)

Voir aussi

Termes et acronymes IPSec

Triple norme de chiffrement des données (3DES)

Un algorithme DES amélioré qui fournit un chiffrement 168 bits en traitant les données trois fois avec trois clés différentes.

PIC des services adaptatifs

Une carte d’interface physique (PIC) de nouvelle génération qui fournit des services IPsec et d’autres services, tels que la traduction d’adresses réseau (NAT) et le pare-feu dynamique, sur les plates-formes M Series et T Series.

AES (Advanced Encryption Standard)

Méthode de chiffrement de nouvelle génération basée sur l’algorithme de Rijndael qui utilise un bloc de 128 bits, trois tailles de clé différentes (128, 192 et 256 bits) et plusieurs cycles de traitement pour chiffrer les données.

en-tête d’authentification (AH)

Composant du protocole IPsec permettant de vérifier que le contenu d’un paquet n’a pas changé (intégrité des données) et de valider l’identité de l’expéditeur (authentification de la source de données). Pour plus d’informations sur AH, consultez RFC 2402.

autorité de certification (CA)

Organisation tierce de confiance qui génère, enregistre, valide et révoque des certificats numériques. L’autorité de certification garantit l’identité d’un utilisateur et émet des clés publiques et privées pour le chiffrement et le déchiffrement des messages.

liste de révocation de certificats (CRL)

Une liste des certificats numériques qui ont été invalidés avant leur date d’expiration, y compris les raisons de leur révocation et les noms des entités qui les ont émis. Une CRL empêche l’utilisation de certificats et de signatures numériques qui ont été compromis.

CBC (Cipher Block Chaining)

Méthode cryptographique qui chiffre des blocs de texte chiffré en utilisant le résultat du chiffrement d’un bloc pour chiffrer le bloc suivant. Lors du déchiffrement, la validité de chaque bloc de texte chiffré dépend de la validité de tous les blocs de texte chiffré précédents. Pour plus d’informations sur l’utilisation de CBC avec DES et ESP pour assurer la confidentialité, reportez-vous à la RFC 2405.

Norme de chiffrement des données (DES)

Algorithme de chiffrement qui chiffre et déchiffre les données relatives aux paquets en les traitant à l’aide d’une clé partagée unique. DES fonctionne par incréments de blocs de 64 bits et fournit un chiffrement de 56 bits.

certificat numérique

Fichier électronique qui utilise la technologie de clé privée et publique pour vérifier l’identité d’un créateur de certificat et distribuer les clés à ses pairs.

ES PIC

Un PIC qui fournit des services de chiffrement de première génération et une prise en charge logicielle pour IPsec sur les plates-formes M Series et T Series.

Encapsulating Security Payload (ESP)

Composant du protocole IPsec utilisé pour chiffrer les données d’un paquet IPv4 ou IPv6, assurer l’intégrité des données et assurer l’authentification de la source de données. Pour plus d’informations sur ESP, reportez-vous à la RFC 2406.

Code d’authentification des messages hachés (HMAC)

Mécanisme d’authentification des messages à l’aide de fonctions de hachage cryptographique. HMAC peut être utilisé avec n’importe quelle fonction de hachage cryptographique itérative, telle que MD5 ou SHA-1, en combinaison avec une clé secrète partagée. Pour plus d’informations sur HMAC, reportez-vous à la RFC 2104.

Internet Key Exchange (IKE)

Établit des paramètres de sécurité communs pour tous les hôtes ou routeurs utilisant IPsec. IKE établit les SA pour IPsec. Pour plus d’informations sur IKE, consultez RFC 2407.

Résumé du message 5 (MD5)

Algorithme d’authentification qui prend un message de données de longueur arbitraire et produit un condensé de message de 128 bits. Pour plus d’informations, consultez RFC 1321.

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.

infrastructure à clé publique (PKI)

hiérarchie de confiance qui permet aux utilisateurs d’un réseau public d’échanger des données de manière sécurisée et privée à l’aide de paires de clés cryptographiques publiques et privées obtenues et partagées avec leurs homologues par l’intermédiaire d’une autorité de confiance.

autorité d’enregistrement (AR)

Organisation tierce de confiance qui agit pour le compte d’une autorité de certification afin de garantir l’identité d’un utilisateur.

Moteur de routage

Partie architecturale PCI d’un routeur basé sur Junos OS qui gère le processus de protocole de routage, le processus d’interface, certains composants du châssis, la gestion du système et l’accès des utilisateurs.

association de sécurité (SA)

Spécifications qui doivent faire l’objet d’un accord entre deux périphériques réseau avant que IKE ou IPsec ne soient autorisés à fonctionner. Les SA spécifient principalement les options de protocole, d’authentification et de chiffrement.

Base de données de la Security Association (SADB)

Base de données dans laquelle toutes les SA sont stockées, surveillées et traitées par IPsec.

Algorithme de hachage sécurisé 1 (SHA-1)

Algorithme d’authentification qui prend un message de données d’une longueur inférieure à 264 bits et produit un condensé de message de 160 bits. Pour plus d’informations sur SHA-1, consultez RFC 3174.

Algorithme de hachage sécurisé 2 (SHA-2)

Successeur de l’algorithme d’authentification SHA-1 qui inclut un groupe de variantes de SHA-1 (SHA-224, SHA-256, SHA-384 et SHA-512). Les algorithmes SHA-2 utilisent des tailles de hachage plus grandes et sont conçus pour fonctionner avec des algorithmes de chiffrement améliorés tels que AES.

Base de données de stratégies de sécurité (SPD)

Une base de données qui fonctionne avec la SADB pour assurer une sécurité maximale des paquets. Pour les paquets entrants, IPsec vérifie le SPD pour vérifier si le paquet entrant correspond à la sécurité configurée pour une stratégie donnée. Pour les paquets sortants, IPsec vérifie le SPD pour voir si le paquet doit être sécurisé.

Indice des paramètres de sécurité (SPI)

Identificateur utilisé pour identifier de manière unique une SA au niveau d’un hôte réseau ou d’un routeur.

Protocole SCEP (Simple Certificate Enrollment Protocol)

Protocole qui prend en charge la distribution de clés publiques, l’inscription et la révocation de certificats, la révocation de certificats, les requêtes de certificats et les requêtes de liste de révocation de certificats (CRL) des autorités de certification et des autorités d’enregistrement (RA).

Présentation d’IPsec pour ACX Series

Le système d’exploitation Junos de Juniper Networks (Junos OS) prend en charge IPsec. Cette rubrique comprend les sections suivantes, qui fournissent des informations générales sur la configuration d’IPsec sur les routeurs métro universels ACX Series.

Note:

IPsec n’est pris en charge que sur les routeurs ACX1100 AC et ACX500. Modification du service (GRE, NAT et IPSec) sur les routeurs ACX1100-AC et ACX500 ne sont pas pris en charge.
Note:

Les routeurs ACX5048 et ACX5096 ne prennent pas en charge les configurations IPsec.

Pour obtenir la liste des normes IPsec et IKE prises en charge par Junos OS, reportez-vous à la hiérarchie Junos OS et à la référence RFC.

IPsec (en anglais)

L’architecture IPsec fournit une suite de sécurité pour la couche réseau IP version 4 (IPv4). La suite fournit des fonctionnalités telles que l’authentification de l’origine, l’intégrité des données, la confidentialité, la protection contre la relecture et la non-répudiation de la source. En plus d’IPsec, Junos OS prend également en charge l’Internet Key Exchange (IKE), qui définit des mécanismes de génération et d’échange de clés, et gère les associations de sécurité.

IPsec définit également une association de sécurité et un cadre de gestion des clés qui peuvent être utilisés avec n’importe quel protocole de couche de transport. L’association de sécurité spécifie la stratégie de protection à appliquer au trafic entre deux entités de couche IP. IPsec fournit des tunnels sécurisés entre deux pairs.

Associations de sécurité

Pour utiliser les services de sécurité IPsec, vous devez créer des associations de sécurité entre les hôtes. Une association de sécurité est une connexion simplex qui permet à deux hôtes de communiquer entre eux en toute sécurité au moyen d’IPsec. Il existe deux types d’associations de sécurité :

  • Les associations de sécurité manuelles ne nécessitent aucune négociation ; Toutes les valeurs, y compris les clés, sont statiques et spécifiées dans la configuration. Les associations de sécurité manuelles définissent de manière statique les valeurs, les algorithmes et les clés de l’indice des paramètres de sécurité (SPI) à utiliser, et nécessitent des configurations correspondantes aux deux extrémités du tunnel. Chaque pair doit avoir les mêmes options configurées pour que la communication ait lieu.

  • Les associations de sécurité dynamique nécessitent une configuration supplémentaire. Avec les associations de sécurité dynamiques, vous configurez d’abord IKE, puis l’association de sécurité. IKE crée des associations de sécurité dynamiques ; il négocie les associations de sécurité 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. Cette connexion est ensuite utilisée pour convenir dynamiquement des clés et d’autres données utilisées par l’association de sécurité IPsec dynamique. L’association de sécurité IKE est d’abord négociée, puis utilisée pour protéger les négociations qui déterminent les associations de sécurité IPsec dynamiques.

IKE

IKE est un protocole de gestion des clés qui crée des associations de sécurité dynamiques. il négocie les associations de sécurité pour IPsec. Une configuration IKE définit les algorithmes et les clés utilisés pour établir une connexion sécurisée avec une passerelle de sécurité homologue.

IKE effectue les tâches suivantes :

  • Négocie et gère les paramètres IKE et IPsec.

  • Authentifie l’échange sécurisé de clés.

  • Fournit une authentification mutuelle des pairs au moyen de secrets partagés (pas de mots de passe) et de clés publiques.

  • Assure la protection de l’identité (en mode principal).

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
18.2R1
À partir de la version 18.2R1 de Junos OS, vous pouvez configurer un routeur MX Series avec des MS-MPC ou MS-MIC pour qu’il agisse uniquement en tant que répondeur IKE.
18.2R1
À partir de Junos OS version 18.2R1, vous pouvez configurer le routeur MX Series avec des MS-MPC ou des MS-MIC afin qu’ils envoient uniquement le certificat de l’entité finale pour l’authentification IKE basée sur les certificats au lieu de la chaîne de certificats complète.
17.4R1
À partir de la version 17.4R1 de Junos OS, AES-GCM est pris en charge en mode FIPS Junos.
17.3R1
À partir de la version 17.3R1 de Junos OS, la norme de chiffrement avancée en mode Galois/compteur (AES-GCM) est prise en charge pour les MS-MPC et MS-MIC.