Présentation d’IPsec

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) et était appelée 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 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
• Associations de sécurité
• IKE
• Non-prise en charge du NAT-T
• Comparaison d’IPsec sur les PIC ES et de Junos VPN Site Secure sur cartes LIne 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 {...}

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

[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

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 résumé 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é falsifié, Junos OS compare le résumé de message calculé à un résumé de message déchiffré avec une clé partagée. Le système d’exploitation Junos OS utilise la variante MD5 avec code d’authentification de message haché (HMAC) qui fournit un niveau de hachage supplémentaire. MD5 peut être utilisé avec l’en-tête d’authentification (AH), l’encapsulation d’une charge utile de sécurité (ESP) et l’IKE (Internet Key Exchange).

• Secure Hash Algorithm 1 (SHA-1) utilise un algorithme plus puissant que MD5. SHA-1 prend un message de moins de 264 bits et produit un résumé de message de 160 bits. Le résumé des messages volumineux garantit que les données n’ont pas été modifiées et qu’elles proviennent de la bonne source. Junos OS utilise la variante SHA-1 HMAC qui fournit un niveau de hachage supplémentaire. 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), DES (Data Encryption Standard) et Triple DES (3DES).

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. Comme pour les algorithmes d’authentification, une clé partagée est utilisée avec les algorithmes de chiffrement pour vérifier l’authenticité des appareils IPsec. Junos OS utilise les algorithmes de chiffrement suivants :

• Le chaînage de blocs de chiffrement standard de chiffrement des données (DES-CBC) est un algorithme symétrique de bloc 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. Le 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 le chiffrement 168 bits (3 x 56 bits). Le 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 chiffrer à nouveau 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 conjointement avec IPsec est définie dans la norme RFC 3602, 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 les MS-MIC. Toutefois, 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-GCM est un algorithme de chiffrement authentifié conçu pour assurer à la fois l’authentification et la confidentialité. AES-GCM utilise le hachage universel sur un champ Galois binaire pour fournir un chiffrement authentifié et permet un chiffrement authentifié à des débits de données de plusieurs dizaines de Gbit/s.

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 norme 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 rediffusions. AH authentifie autant que possible l’en-tête IP, ainsi que les données de protocole de niveau supérieur. Toutefois, certains champs d’en-tête IP peuvent changer en transit. Comme 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é avec 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.

  Remarque :

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

Figure 1 : Protocole AH

• ESP : défini dans la norme RFC 2406, l’ESP peut fournir un chiffrement et un flux de trafic limité, la confidentialité ou l’intégrité sans connexion, l’authentification de l’origine des données et un service anti-relecture. 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 montre un exemple de la protection IPsec offerte par ESP.

Figure 2 : Protocole ESP

• Bundle : lorsque vous comparez AH et ESP, les deux protocoles présentent des avantages et des lacunes. L’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 que AH ne fournisse pas de chiffrement, il assure l’authentification de l’ensemble du paquet IP. C’est pourquoi 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.

IPsec fournit des tunnels sécurisés entre deux pairs, 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. Ainsi, un chemin de transfert unique est sélectionné entre les pairs, comme illustré à la Figure 3. Lorsque le trafic IPsec circule entre des datacenters comptant des milliers d’hôtes, cette sélection d’un seul chemin limite le débit.

Figure 3 : IPsec avec un chemin de transfert unique

Vous pouvez surmonter 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 informations des couches 3 et 4 sont ainsi transmises aux routeurs intermédiaires, et les paquets IPsec sont transférés sur plusieurs chemins, comme illustré sur la Figure 5. Vous activez l’encapsulation UDP pour l’ensemble de services.

Figure 4 : En-tête UDP ajouté

Figure 5 : IPsec avec plusieurs chemins de transfert

Vous pouvez configurer le port de destination UDP ou utiliser la valeur par défaut 4565. Vous ne pouvez pas configurer 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 via une fonction de hachage qui fonctionne sur les données suivantes :

• Adresse IP source

• Adresse IP de destination

• Protocole de transport

• Port source de transport

• Port de destination du 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 le NAT-T est détecté, seule l’encapsulation UDP NAT-T se produit, et non l’encapsulation UDP pour les paquets IPsec.

Sur les routeurs équipés d’un ou de plusieurs MS-MPC, MS-MIC ou DPC, les versions canadienne et américaine de Junos OS prennent en charge de manière substantielle les RFC suivantes, qui définissent les normes pour la sécurité IP (IPsec) et l’Internet Key Exchange (IKE).

• RFC 2085, authentification IP HMAC-MD5 avec prévention de relecture

• 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, L’utilisation de HMAC-MD5-96 dans ESP et AH

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

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

• RFC 2406, Encapsulation IP de la charge utile de sécurité (ESP) (obsolète par RFC 4303 et RFC 4305)

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

• RFC 2408, Internet Sécurité 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, Les algorithmes de chiffrement en mode CBC de l’ESP

• Protocole OCSP (Internet Public Key Infrastructure) RFC 2560, X.509 - OCSP (Internet Public Key Infrastructure)

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

• RFC 3280, Certificat d’infrastructure à clé publique Internet X.509 et profil de 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 IPsec ESP

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

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

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

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

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

• RFC 4303, Encapsulation IP des charges utiles de sécurité (ESP)

• RFC 4305, Exigences d’implémentation des algorithmes cryptographiques pour l’encapsulation d’une charge utile de sécurité (ESP) et d’un 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.

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

• RFC 4835, Exigences d’implémentation des algorithmes cryptographiques pour l’encapsulation d’une charge utile de sécurité (ESP) et d’un 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 le protocole Internet Key Exchange (IKE) et IPsec

• RFC 8200, spécification du protocole Internet, version 6 (IPv6)

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

• RFC 3526, Groupes de Diffie-Hellman MODP (More Modular Exponentiel) 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 l’ébauche Internet suivantes ne définissent pas les normes, mais fournissent des informations sur IPsec, IKE et les technologies associées. L’IETF les classe comme « informationnels ».

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

• RFC 2412, Le protocole de détermination de clé OAKLEY

• RFC 3706, Une méthode basée sur le trafic de détection des pairs Internet Key Exchange morts (IKE)

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

Le système d’exploitation Junos (Junos OS) de Juniper Networks 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.

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
• Associations de sécurité
• IKE