Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Principes de base IPsec

Présentation d’IPsec

IPsec est une suite de protocoles associés pour la sécurisation cryptographique des communications au niveau de la couche paquet IP. IPsec fournit également des méthodes pour la négociation manuelle et automatique des associations de sécurité (SA) et de la distribution des clés, tous les attributs pour lesquels sont regroupées dans un domaine d’interprétation (DOI). Le DOI IPsec est un document qui contient une définition de tous les paramètres de sécurité nécessaires à la réussite de la négociation d’un tunnel VPN. Il contient essentiellement l’ensemble des attributs requis pour les négociations SA et IKE de sécurité. Pour plus d’informations, consultez les exemples RFC 2407 et RFC 2408.

Pour utiliser les services de sécurité IPsec, vous créez des SA entre les hôtes. Une connexion SA est une connexion simplex qui permet à deux hôtes de communiquer entre eux en toute sécurité à l’moyen d’IPsec. Il existe deux types de SA: manuel 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 paramètres à utiliser pour sécuriser un canal de communication. La communication bidirectionnelle complète nécessite au moins deux SA, un pour chaque direction. Par le biais du 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, en cas d’utilisation de certificats, non répudiation (via l’authentification de l’origine des données)

Les fonctions de sécurité que vous employez dépendent de vos besoins. Si vous devez authentifier uniquement la source des paquets IP et l’intégrité du contenu, vous pouvez authentifier le paquet sans appliquer de chiffrement. D’autre part, si vous vous préoccupez uniquement de préserver la confidentialité, vous pouvez chiffrer le paquet sans appliquer de mécanismes d’authentification. Vous pouvez à la fois chiffrer et authentifier le paquet. La plupart des concepteurs de sécurité réseau choisissent de chiffrer, d’authentifier et de rejouer la protection de leur trafic VPN.

Un tunnel IPsec se compose d’une paire de SA unidirectionnels (un SA pour chaque direction du tunnel) qui spécifient l’index de paramètre de sécurité (SPI), l’adresse IP de destination et le protocole de sécurité (Authentification Header [AH] ou Encapsulating Security Payload [ESP] utilisé. Un saa rassemble les composants suivants pour sécuriser les communications:

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

  • Mode protocole, transport ou tunnel. Junos OS utilisent toujours un mode tunnel. (Voir le traitement des paquets en mode tunnel.)

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

  • Durée de vie des sa.

Pour le trafic entrant, Junos OS recherche le SA en utilisant le triplet suivant:

  • Adresse IP de destination.

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

  • Valeur de l’index des paramètres de sécurité (SPI).

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 pour une utilisation réussie 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

  • Équipements IKE auto-partagés avec une clé ou un certificat

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

Cette rubrique comprend les sections suivantes :

Clé manuelle

Avec les clés manuelles, les administrateurs aux 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 sécurisée de configurations à clés manuelles sur de longues distances pose des problèmes de sécurité. Mis à part la transmission des clés en face à face, vous ne pouvez pas être totalement sûr que ces clés n’ont pas été compromises lors de leur transit. En outre, chaque fois que vous souhaitez changer la clé, vous êtes confronté aux mêmes problèmes de sécurité que lors de votre distribution initiale.

Équipements IKE

Si 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 des clés et des associations de sécurité à l’aide du Internet Key Exchange (IKE). Junos OS référence aux négociations de tunnel automatisées comme la certification auto-clé IKE et prend en charge les IKE auto-clés pré-partagées et la certification automatique IKE des certificats.

  • IKE auto-clé avec clés partagées: à l’aide d’une IKE auto-clé avec clés pré-partagées pour authentifier les participants lors d’une session IKE, chaque partie doit configurer et échanger la clé pré-partagée à l’avance. À cet égard, la question de la distribution sécurisée des clés est la même que celle des clés manuelles. Toutefois, une fois distribuée, une clé automatique, contrairement à une clé manuelle, peut automatiquement changer ses clés à des intervalles prédéterminés à l’aide IKE protocole. Les changements fréquents de clés améliorent considérablement la sécurité, ce qui réduit automatiquement les responsabilités de gestion des clés. Cependant, la modification des clés augmente la charge de trafic; C’est pourquoi une modification trop souvent des clés peut réduire l’efficacité de transmission des données.

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

  • Certifications IKE automatiques 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 les deux parties font confiance à l’autorité de certification émettrice (AC), les participants peuvent récupérer la clé publique de l’pair et vérifier sa signature. Il n’est pas nécessaire de garder trace des clés et des SA; IKE automatiquement.

Diffie-Hellman Exchange

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 noncuré, sans transmettre la valeur secrète par le biais du fil. La taille du modulus de base utilisé dans le calcul de chaque groupe diffère, comme illustré dans le tableau ci-dessous. Les opérations d’échange Diffie Hellman (DH) peuvent être effectuées soit sur un logiciel, soit sur un matériel. Lorsque ces opérations d’échange sont exécutées dans le matériel, nous utilisons le cryptage de la technologie QuickAssist (QAT). Les listes suivantes répertorient différents groupes Tableau 1 diffie Hellman (DH) et indiquent si l’opération exécutée pour ce groupe se trouve au niveau du matériel ou du logiciel.

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

Groupe Diffie-Hellman (DH)

Taille du module Prime

DH Groupe 1

768-bit

DH Groupe 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 de 256 bits

DH Group 20

Courbe elliptique de 384 bits

DH Group 21

Courbe elliptique de 521 bits

DH Group 24

Sous-groupe 2048 bits avec commande de premier ordre 256 bits

À partir Junos OS version 19.1R1, SRX Series équipements mobiles sont utilisés par les groupes DH 15, 16 et 21.

À partir de Junos OS version 20.3R1, les instances vSRX avec le package Junos-ike installé soutiennent les groupes DH 15, 16 et 21.

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

Étant donné que le modulus de chaque groupe d’HD est de différentes tailles, 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:

  • En-tête de l’authentification (AH): un protocole de sécurité pour l’authentification de la source d’un paquet IP et la vérification de l’intégrité de son contenu

  • Encapsuling Security Payload (ESP): un protocole de sécurité pour le chiffrement de l’ensemble du paquet IP (et l’authentification de son contenu)

Vous pouvez choisir vos protocoles de sécurité, également appelés algorithmes d’authentificationet de chiffrement, 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 unités de traitement des services (SPUs) et 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 spUs d’ancrage sont mises à jour avec le protocole négocié, tandis que les spUs non ancrées conservent les sessions de tunnel ESP et AH. Les sessions de tunnel ESP et AH sont affichées dans les sorties pour les commandes du show security flow sessionshow security flow cp-session mode opérationnel.

Cette rubrique comprend les sections suivantes :

Algorithmes d’authentification IPsec (protocole AH)

Le protocole AH (Authentication Header) 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 le compte de vérification calculé à l’aide d’un code d’authentification des messages de hachage (HMAC) à 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é signature numérique ou digeste de message)à partir d’un message d’une longueur arbitraire et d’une clé à 16 chiffres. Le hachage qui en résulte est utilisé, à l’aide de l’empreinte numérique des données, 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é à 20 totes. En raison des hants qu’il produit, il est généralement considéré comme plus sécurisé que le md5. Étant donné que le traitement informatique est effectué dans les ASIC, le coût de performance est négligeable.

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

Algorithmes de chiffrement IPsec (Protocole ESP)

Le protocole ESP (Encapsulating Security Payload) permet d’assurer la confidentialité (chiffrement) et l’authentification des sources et l’intégrité du contenu (authentification). ESP en mode tunnel encapsule l’ensemble du paquet IP (en-tête et charge utile), puis append un nouvel en-tête IP au paquet désormais chiffré. Ce nouvel en-tête IP contient l’adresse de destination requise pour router les données protégées via le réseau. (Voir le traitement des paquets en mode tunnel.)

Avec ESP, vous pouvez à la fois chiffrer et authentifier, chiffrer uniquement ou authentifier uniquement. 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 modèles à l’aide d’une clé 168 bits. Les des fournit des performances importantes mais sont considérées comme inacceptables pour de nombreux transferts de matériel sensibles ou classifiés.

  • Advanced Encryption Standard (AES): une norme de chiffrement offrant une meilleure interopérabilité avec les autres équipements. Junos OS prend en charge AES avec 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 NULL pour le chiffrement, il a été démontré que l’IPsec peut être vulnérable aux attaques dans de telles circonstances. C’est pourquoi nous vous suggérons de choisir un algorithme de chiffrement pour une sécurité maximale.

Négociation tunnel IPsec

Les deux modes suivants déterminent l’échange du trafic dans le VPN.

  • Mode tunnel: protège le trafic en encapsulant le paquet IP d’origine dans un autre paquet dans le tunnel VPN. Ce mode utilise des clés partagées avec des IKE authentifier les pairs ou les certificats numériques IKE authentifier les pairs. Cette pratique est plus couramment utilisée lorsque les hôtes de réseaux privés distincts souhaitent communiquer sur 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 ou allez vers des systèmes non IPsec.

  • Mode transport: protégez le trafic en envoyant le paquet directement entre les deux hôtes qui ont établi le tunnel IPsec. Autrement dit, lorsque le point de terminaison de communication et le point de terminaison cryptographique sont identiques. La partie 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 pour les hôtes protégés ne peuvent pas utiliser de 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é. Grâce à 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 prise en charge

Sur les routeurs équipés d’un ou plusieurs MPC MS, MS-MPC ou DPC, la version canada et américaine de Junos OS prend en charge considérablement les RFC suivantes, qui définissent des normes de sécurité IP (IPsec) et de Internet Key Exchange (IKE).

  • RFC 2085, Authentification IP HMAC-MD5 avec replay prevention

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

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

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

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

  • RFC 2405, Algorithme de chiffrement ESP DES-AUSE AVEC EXPLICIT IV

  • RFC 2406, Charge utile de sécurité (ESP) encapsulée IP (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 le RFC 4306)

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

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

  • RFC 2451, Algorithmes de chiffrement DE CHIFFREMENT ESPES-Mode

  • RFC 2460, Internet Protocol, version 6 (IPv6)

  • 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 Infrastructure Certificate and Certificate Revocation List)

  • RFC 3602, algorithme de chiffrement AES-S ET son utilisation avec IPsec

  • RFC 3948, Encapsulation UDP des paquets ESP IPsec

  • RFC 4106, Utilisation de Galois/Mode compteur (GCM) dans l’encapsulation IPsec des charges utiles de sécurité (ESP)

  • RFC 4210, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)

  • RFC 4211, Internet X.509 Public Key Infrastructure Request Format (CRMF)

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

  • RFC 4302, en-tête de l’authentification IP

  • RFC 4303, Charge utile de sécurité (ESP) encapsulée IP

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

  • RFC 4306, Internet Key Exchange (IKEv2)

  • RFC 4307, Algorithmes cryptographiques à 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 authentification IKEv2 à l’aide de l’algorithme de signature numérique (ECDSA) Elliptic Curve

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

  • RFC 5996, Internet Key Exchange Version 2 (IKEv2)

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

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

  • RFC 5114, Groupes Diffie-Hellman supplémentaires, pour une utilisation avec IETF standards

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

Les RFC et le projet Internet suivants ne définissent pas de normes, mais fournissent des informations sur les normes IPsec, les IKE et les technologies associées. Le IETF les classe comme « Informations ».

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

  • RFC 2412, The OAKLEY Key Determination Protocol

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

  • Projet Internet draft-eastlake-sha2-02.txt, algorithmes de hachage sécurisé (SHA et HMAC-SHA) (expire en juillet 2006)

Tableau de l'historique des versions
Version
Description
19.1R1
À partir Junos OS version 19.1R1, SRX Series équipements mobiles sont utilisés par les groupes DH 15, 16 et 21.