Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Bases de l’IPsec

Présentation d’IPsec

IPsec est une suite de protocoles associés pour sécuriser les communications cryptographiquement au niveau de la couche de paquets IP. IPsec fournit également des méthodes pour la négociation manuelle et automatique des associations de sécurité (SAs) et la distribution des clés, dont tous les attributs sont regroupés dans un domaine d’interprétation (DOI). Le DOI IPsec est un document contenant des définitions de tous les paramètres de sécurité nécessaires à la négociation d’un tunnel VPN, c’est-à-dire tous les attributs requis pour les négociations SA et IKE. Pour plus d’informations, voir RFC 2407 et RFC 2408.

Pour utiliser les services de sécurité IPsec, vous créez des SAs entre les hôtes. Un SA est une connexion simple qui permet à deux hôtes de communiquer entre eux en toute sécurité via IPsec. Il existe deux types d’AS : manuelle et dynamique.

IPsec prend en charge deux modes de sécurité (mode transport et mode tunnel).

Associations de sécurité

Une association de sécurité (SA) est un accord unidirectionnel entre les participants VPN concernant les méthodes et les paramètres à utiliser pour sécuriser un canal de communication. La communication bidirectionnelle complète nécessite au moins deux SAS, un pour chaque direction. Grâce au sa, un tunnel IPsec peut fournir les fonctions de sécurité suivantes :

  • Confidentialité (via le chiffrement)

  • Intégrité du contenu (via l’authentification des données)

  • Authentification de l’expéditeur et, si elle utilise des certificats, non-vérification (via l’authentification de l’origine des données)

Les fonctions de sécurité que vous utilisez dépendent de vos besoins. Si vous avez uniquement besoin d’authentifier la source du paquet IP et l’intégrité du contenu, vous pouvez authentifier le paquet sans appliquer de cryptage. D’autre part, si vous ne souhaitez que préserver la confidentialité, vous pouvez chiffrer le paquet sans appliquer de mécanismes d’authentification. Vous pouvez éventuellement chiffrer et authentifier le paquet. La plupart des concepteurs de sécurité réseau choisissent de chiffrer, d’authentifier et de rejouer leur trafic VPN.

Un tunnel IPsec se compose d’une paire d’AAS unidirectionnelles (une SA pour chaque direction du tunnel) qui spécifient l’index de paramètres de sécurité (SPI), l’adresse IP de destination et le protocole de sécurité (Authentication Header [AH] ou Encapsulating Security Payload [ESP] employé. Un SA regroupe les composants suivants pour sécuriser les communications :

  • Algorithmes et clés de sécurité.

  • Mode protocole, transport ou tunnel. Les équipements Junos OS utilisent toujours le mode tunnel. (Voir Traitement des paquets en mode tunnel.)

  • Méthode de gestion des clés, clé manuelle ou IKE à clé automatique.

  • SA à vie.

Pour le trafic entrant, Junos OS recherche le système d’exploitation SA à l’aide du triplet suivant :

  • Adresse IP de destination.

  • Protocole de sécurité, AH ou ESP.

  • Valeur SPI (Security Parameter Index).

Pour le trafic VPN sortant, la stratégie appelle le SA associé au tunnel VPN.

Gestion des clés IPsec

La distribution et la gestion des clés sont essentielles à la réussite de l’utilisation des VPN. Junos OS prend en charge la technologie IPsec pour la création de tunnels VPN avec trois types de mécanismes de création clés :

  • Clé manuelle

  • IKE de clé automatique avec une clé ou un certificat pré-partagé

Vous pouvez choisir votre mécanisme de création de clés, également appelé méthode d’authentification, lors de la configuration de la proposition de phase 1 et de phase 2. Voir Internet Key Exchange.

Cette rubrique comprend les sections suivantes :

Clé manuelle

Grâce aux clés manuelles, les administrateurs des deux extrémités d’un tunnel configurent tous les paramètres de sécurité. Il s’agit d’une technique viable pour les réseaux statiques de petite taille où la distribution, la maintenance et le suivi des clés ne sont pas difficiles. Toutefois, la distribution en toute sécurité des configurations manuelles sur de grandes distances pose des problèmes de sécurité. En plus de passer les clés en face à face, vous ne pouvez pas être complètement sûr que ces clés n’ont pas été compromises pendant le transit. De plus, chaque fois que vous souhaitez changer la clé, vous devez faire face aux mêmes problèmes de sécurité que lors de sa distribution initiale.

IKE à clé automatique

Lorsque vous devez créer et gérer de nombreux tunnels, vous avez besoin d’une méthode qui ne vous oblige pas à configurer chaque élément manuellement. IPsec prend en charge la génération et la négociation automatisées de clés et d’associations de sécurité à l’aide du protocole Internet Key Exchange (IKE). Junos OS fait référence à une négociation de tunnel automatique sous le nom d’AutoKey IKE et prend en charge AutoKey IKE avec clés pré-partagées et AutoKey IKE avec certificats.

  • IKE de clé automatique avec clés pré-partagées : à l’aide d’AutoKey IKE avec des clés pré-partagées pour authentifier les participants à une session IKE, chaque partie doit configurer et échanger à l’avance la clé pré-partagée en toute sécurité. À cet égard, la question de la distribution sécurisée des clés est la même que celle des clés manuelles. Cependant, une fois distribuée, une clé automatique, contrairement à une clé manuelle, peut changer automatiquement ses clés à des intervalles prédéfinis à l’aide du protocole IKE. Le changement fréquent de clés améliore considérablement la sécurité, ce qui réduit automatiquement considérablement les responsabilités de gestion des clés. Toutefois, le changement de clés augmente les frais de trafic. Par conséquent, le changement de clés peut trop souvent réduire l’efficacité de la transmission des données.

    Une clé pré-partagée est une clé à la fois pour le chiffrement et le déchiffrement, que les deux participants doivent avoir avant d’initier une communication.

  • IKE autokey avec certificats : lors de l’utilisation de certificats pour authentifier les participants lors d’une négociation IKE AutoKey, chaque partie génère une paire de clés public-privé et acquiert un certificat. Tant que l’autorité de certification (CA) émise est approuvée par les deux parties, les participants peuvent récupérer la clé publique de l’pair et vérifier la signature de l’pair. Il n’est pas nécessaire de garder une trace des clés et des AS; IKE le fait automatiquement.

Échange Diffie-Hellman

Un échange Diffie-Hellman (DH) permet aux participants de produire une valeur secrète partagée. La force de la technique est qu’elle permet aux participants de créer la valeur secrète sur un support non sécurisé sans passer la valeur secrète par le fil. La taille du module principal utilisé dans le calcul de chaque groupe diffère comme le montre le tableau ci-dessous. Les opérations d’échange de Diffie Hellman (DH) peuvent être effectuées soit dans le logiciel, soit dans le matériel. Lorsque ces opérations d’échange sont effectuées dans le matériel, nous utilisons le cryptographie de la technologie QuickAssist (QAT). Les éléments suivants Tableau 1 répertorient différents groupes Diffie Hellman (DH) et spécifient si l’opération exécutée pour ce groupe est dans le matériel ou dans le logiciel.

Tableau 1 : Les groupes Diffie Hellman (DH) et leurs opérations d’échange exécutés

Groupe Diffie-Hellman (DH)

Taille du module Prime

Groupe DH 1

768-bit

Groupe DH 2

102-bit

Groupe DH 5

1536-bit

Groupe DH 14

2048-bit

Groupe DH 15

3072-bit

Groupe DH 16

4096-bit

Groupe DH 19

Courbe elliptique 256 bits

Groupe DH 20

Courbe elliptique 384 bits

Groupe DH 21

Courbe elliptique 521 bits

Groupe DH 24

2 048 bits avec sous-groupe de l’ordre premier de 256 bits

À partir de Junos OS version 19.1R1, les équipements SRX Series prennent en charge les groupes DH 15, 16 et 21.

À partir de Junos OS version 20.3R1, les instances vSRX avec package junos-ike installent la prise en charge des groupes DH 15, 16 et 21.

Nous déconseillent l’utilisation des groupes DH 1, 2 et 5.

Étant donné que le module de chaque groupe de DH a une taille différente, les participants doivent accepter d’utiliser le même groupe.

Protocoles de sécurité IPsec

IPsec utilise deux protocoles pour sécuriser les communications au niveau de la couche IP :

  • Authentification Header (AH) : protocole de sécurité permettant d’authentifier la source d’un paquet IP et de vérifier l’intégrité de son contenu

  • Encapsulating Security Payload (ESP) : protocole de sécurité permettant de chiffrer l’ensemble du paquet IP (et d’authentifier son contenu)

Vous pouvez choisir vos protocoles de sécurité, également appelés authentication and encryption algorithms, lors de la configuration de la proposition de phase 2. Voir Internet Key Exchange.

Pour chaque tunnel VPN, les sessions de tunnel AH et ESP sont installées sur les SPU (Services Processing Units) et sur le plan de contrôle. Les sessions de tunnel sont mises à jour avec le protocole négocié une fois la négociation terminée. Pour les équipements SRX5400, SRX5600 et SRX5800, les sessions de tunnel sur les SPU d’ancrage sont mises à jour avec le protocole négocié, tandis que les SPU non ancrées conservent les sessions de tunnel ESP et AH. Les sessions de tunnel ESP et AH sont affichées dans les sorties des commandes du show security flow session mode opérationnel.show security flow cp-session

Cette rubrique comprend les sections suivantes :

Algorithmes d’authentification IPsec (protocole AH)

Le protocole Authentification Header (AH) permet de vérifier l’authenticité et l’intégrité du contenu et de l’origine d’un paquet. Vous pouvez authentifier le paquet par la somme de contrôle calculée via un code HMAC (Hash Message Authentication Code) à l’aide d’une clé secrète et de fonctions de hachage MD5 ou SHA.

  • Message Digest 5 (MD5) : algorithme qui produit un hachage de 128 bits (également appelé digeste de signatures numériques ou de messages) à partir d’un message de longueur arbitraire et d’une clé de 16 octets. Le hachage résultant est utilisé, comme une empreinte de l’entrée, pour vérifier l’authenticité et l’intégrité du contenu et de la source.

  • Algorithme de hachage sécurisé (SHA) : algorithme qui produit un hachage de 160 bits à partir d’un message de longueur arbitraire et d’une clé de 20 octets. Il est généralement considéré comme plus sécurisé que le MD5 en raison des hachages plus importants qu’il produit. Le traitement de calcul étant effectué dans les ASIC, le coût des performances est négligeable.

Pour plus d’informations sur les algorithmes de hachage MD5, voir RFC 1321 et RFC 2403. Pour plus d’informations sur les algorithmes de hachage SHA, voir RFC 2404. Pour plus d’informations sur l’HMAC, voir RFC 2104.

Algorithmes de chiffrement IPsec (protocole ESP)

Le protocole ESP (Encapsulating Security Payload) fournit un moyen de garantir la confidentialité (chiffrement) et l’authentification source et l’intégrité du contenu (authentification). L’ESP en mode tunnel encapsule l’ensemble du paquet IP (en-tête et charge utile), puis ajoute un nouvel en-tête IP au paquet désormais chiffré. Ce nouvel en-tête IP contient l’adresse de destination nécessaire pour acheminer les données protégées vers le réseau. (Voir Traitement des paquets en mode tunnel.)

Avec ESP, vous pouvez à la fois chiffrer et authentifier, chiffrer uniquement ou simplement vous authentifier. Pour le chiffrement, vous pouvez choisir l’un des algorithmes de chiffrement suivants :

  • Data Encryption Standard (DES) : algorithme de blocage cryptographique avec une clé de 56 bits.

  • Triple DES (3DES) : version plus puissante de DES dans laquelle l’algorithme DES d’origine est appliqué en trois tours, à l’aide d’une clé de 168 bits. L’ER permet de réaliser d’importantes économies sur le rendement, mais elle est jugée inacceptable pour de nombreux transferts de matériel classés ou sensibles.

  • Norme de chiffrement avancée (AES) : une norme de chiffrement qui offre une plus grande interopérabilité avec les autres équipements. Junos OS prend en charge AES avec des clés 128 bits, 192 bits et 256 bits.

Pour l’authentification, vous pouvez utiliser des algorithmes MD5 ou SHA.

Même s’il est possible de sélectionner la valeur NULL pour le chiffrement, il a été démontré que l’IPsec pourrait être vulnérable aux attaques dans de telles circonstances. Par conséquent, nous vous suggérons de choisir un algorithme de chiffrement pour une sécurité maximale.

Négociation de tunnels IPsec

Les deux modes suivants déterminent comment le trafic est échangé dans le VPN.

  • Mode tunnel : protège le trafic en encapsulant le paquet IP d’origine dans un autre paquet du tunnel VPN. Ce mode utilise des clés pré-partagées avec IKE pour authentifier les pairs ou les certificats numériques avec IKE afin d’authentifier les pairs. Cette approche est le plus souvent utilisée lorsque les hôtes d’un réseau privé distinct souhaitent communiquer via un réseau public. Ce mode peut être utilisé à la fois par les clients VPN et les passerelles VPN, et protège les communications provenant de systèmes non IPsec ou qui y vont.

  • Mode de transport : protège le trafic en envoyant le paquet directement entre les deux hôtes ayant établi le tunnel IPsec. Autrement dit, lorsque le point de terminaison de communication et le point de terminaison cryptographique sont identiques. La partie de données du paquet IP est chiffrée, mais pas l’en-tête IP. Les passerelles VPN qui fournissent des services de chiffrement et de déchiffrement aux hôtes protégés ne peuvent pas utiliser le mode de transport pour les communications VPN protégées. Les adresses IP de la source ou de la destination peuvent être modifiées si le paquet est intercepté. En raison de sa construction, le mode de transport ne peut être utilisé que lorsque le point de terminaison de communication et le point de terminaison cryptographique sont identiques.

Normes IPsec et IKE prises en charge

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

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

  • 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 Explicit IV

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

  • RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP (obsolète par RFC 4306)

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

  • RFC 2409, 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 esp cbc mode

  • RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

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

  • RFC 3280, Internet X.509 Profil CRL (Public Key Key Infrastructure Certificate and Certificate Revocation List)

  • RFC 3602, Algorithme de chiffrement AES-CBC et son utilisation avec IPsec

  • RFC 3948, Encapsulation UDP des paquets ESP IPsec

  • RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)

  • RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (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, IP Encapsulating Security Payload (ESP)

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

  • RFC 4306, Protocole Internet Key Exchange (IKEv2)

  • RFC 4307, Algorithmes de cryptage à utiliser dans Internet Key Exchange version 2 (IKEv2)

  • RFC 4308, Suites cryptographiques pour IPsec

    Seule la suite VPN-A est prise en charge dans Junos OS.

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

  • RFC 4835, Exigences d’implémentation des algorithmes de cryptage pour l’encapsulation de la charge utile de sécurité (ESP) et 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 8200, Internet Protocol, spécification version 6 (IPv6)

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

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

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

  • RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) pour IKE et IKEv2

Les RFC ci-dessous et le projet d’Internet ne définissent pas de normes, mais fournissent des informations sur IPsec, IKE et les technologies associées. L’IETF les classe comme « Informational ».

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

  • RFC 2412, The OAKLEY Key Determination Protocol

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

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

Tableau de l'historique des versions
Version
Description
19.1R1
À partir de Junos OS version 19.1R1, les équipements SRX Series prennent en charge les groupes DH 15, 16 et 21.