Qu'est-ce que l'IKE ?

Publié le 13 août 2026

← Tous les termes du glossaire Aller à la lettre I

Le protocole IKE (Internet Key Exchange) permet d'authentifier les deux extrémités d'un tunnel IPsec, de négocier les algorithmes cryptographiques et le groupe de Diffie-Hellman qu'elles utiliseront, et de générer les clés sur lesquelles repose une association de sécurité IPsec. Sans l'IKE, les pairs IPsec ne disposeraient d'aucun moyen sécurisé de s'accorder sur les clés avant de chiffrer le trafic.

Points clés à retenir

  • IKE authentifie les pairs IPsec et négocie leurs paramètres de chiffrement.
  • Le processus se déroule en deux phases : un canal sécurisé, puis les sessions de sécurité (SA) du plan de données.
  • IKEv2 est désormais le protocole par défaut ; IKEv1 est conservé pour les pairs hérités.
  • Ce sont les groupes de Diffie-Hellman qui déterminent la résistance des clés négociées.
  • Versa Les appareils VOS prennent en charge IKEv1, IKEv2 ou les deux, par tunnel.

Sur cette page : Pourquoi est-ce important ?Comment ça marcheTypesIKE & VersaFAQ

Pourquoi le protocole IKE est-il important ?

IKE est le protocole de plan de contrôle qui accompagne le chiffrement du plan de données d’IPsec. Sans négociation automatisée des clés, chaque tunnel devrait disposer de clés configurées et renouvelées manuellement, ce qui ne serait pas évolutif. IKE authentifie chaque pair avant l’établissement du trafic, empêchant ainsi toute usurpation d’identité, et négocie automatiquement la suite de chiffrement et le groupe de Diffie-Hellman que les deux parties utiliseront.

L'IKE assure également la pérennité des tunnels sans interruption : il renouvelle les clés des sessions selon une fréquence ou un volume prédéfinis, en actualisant les clés avant leur expiration, et détecte un pair inactif afin qu'un tunnel obsolète puisse être reconstruit plutôt que laissé à demi-ouvert. IKE étant une norme ouverte et indépendante des fournisseurs, un appareil « Versa » peut négocier un tunnel avec une passerelle Cisco, Palo Alto ou celle d’un fournisseur de cloud en utilisant le même protocole – une interopérabilité qui rend les VPN site à site et les superpositions SD-WAN pratiques sur des réseaux regroupant plusieurs fournisseurs.

Qu'est-ce que l'IKE ?

IKE négocie en deux phases. La phase 1 établit un canal sécurisé et authentifié entre les pairs – l’association de sécurité IKE – à l’aide d’un échange de Diffie-Hellman permettant de dériver un secret partagé, ainsi que des certificats ou une clé pré-partagée (PSK) pour prouver l’identité. La phase 2 utilise ce canal protégé pour négocier les associations de sécurité IPsec qui protègent le trafic de données : transformation de chiffrement, algorithme de hachage et durée de vie de la clé.

Toute négociation repose sur les mêmes principes fondamentaux. Les groupes de Diffie-Hellman permettent aux deux parties de générer un secret identique sans avoir à le transmettre. Les algorithmes de hachage, tels que SHA-256, vérifient que les messages négociés n’ont pas été altérés. La détection des pairs inactifs vérifie régulièrement que le pair est toujours joignable, et le renouvellement des clés – programmé ou basé sur le volume – remplace les clés avant leur expiration afin que le trafic protégé ne soit jamais interrompu.

Types d'IKE

Il existe deux versions du protocole. IKEv2 est la norme moderne : elle établit un tunnel en quatre messages au lieu des six ou plus requis par IKEv1, gère nativement la traversée NAT et les changements de réseau, et simplifie le renouvellement des clés. IKEv1 est principalement utilisé pour des raisons de compatibilité avec les pairs plus anciens ; les nouveaux tunnels doivent par défaut utiliser IKEv2, ou « l'une ou l'autre version » lorsque la capacité du pair est inconnue.

L'authentification constitue un deuxième axe. L'authentification par certificat (PKI) est la solution la plus adaptée aux déploiements à grande échelle et prend en charge la vérification des révocations. Les clés pré-partagées (PSK) conviennent à un petit nombre de tunnels point à point. Les déploiements d’accès à distance peuvent ajouter le protocole EAP en complément d’IKEv2 pour authentifier les utilisateurs individuels plutôt que les appareils. Les groupes de Diffie-Hellman – des groupes traditionnels à module de 768 bits aux groupes modernes à courbe elliptique – complètent le tableau, en faisant le compromis entre le coût de la négociation et la robustesse de la clé.

IKE & Versa

Dans Versa Director, les paramètres IKE sont définis au sein des profils VPN IPsec: les administrateurs choisissent la version IKE v1, v2 ou v2-ou-v1, configurent le délai de renouvellement de clé, le délai d’expiration de la détection de pair inactif et la taille des fragments, puis sélectionnent les fonctions de hachage, de chiffrement et les transformations du groupe Diffie-Hellman – sous la forme d’une transformation unique ou d’une liste hiérarchisée. L’authentification des pairs et l’authentification locale s’effectuent soit à l’aide de certificats, avec une chaîne d’autorités de certification et une vérification facultative de la révocation OCSP, soit à l’aide d’une clé pré-partagée.

Les configurations de tunnels site à site montrent l'interopérabilité d'IKE avec des passerelles tierces : tunnels IKEv2 basés sur les routes vers des appareils Cisco ASR et CSR, tunnels IKEv1 basés sur des politiques vers des appareils Cisco ASA – chacune de ces configurations étant confirmée en vérifiant que l'historique des événements indique « IKE Done » avant de s'assurer que l'interface du tunnel est active. Les modèles d'appareils définissent également un mode d'authentification IKE par défaut pour chaque organisation, PSK ou PKI, appliqué à chaque succursale.

Questions fréquentes

Quelle est la différence entre IKEv1 et IKEv2 ?

IKEv2 établit des tunnels en utilisant moins de messages qu'IKEv1, prend en charge nativement la traversée NAT et la mobilité réseau, et simplifie le renouvellement des clés, ce qui fait qu'il arrive rarement qu'une session soit interrompue en cours de rafraîchissement. IKEv1 reste principalement utilisé pour des raisons de compatibilité avec les pairs plus anciens ; les nouveaux déploiements devraient utiliser IKEv2 par défaut, ou « v2-ou-v1 » lorsque le pair est inconnu.

Quelle est la différence entre IKE et IPsec ?

IKE est le protocole du plan de contrôle qui authentifie les pairs et négocie les clés et les paramètres. IPsec – et plus précisément ESP – est le protocole du plan de données qui chiffre et authentifie le trafic lui-même, à l'aide des clés générées par IKE. Un tunnel opérationnel nécessite ces deux protocoles : IKE pour établir l'association de sécurité, et IPsec pour protéger les paquets.

Quelles méthodes d'authentification IKE prend-il en charge ?

IKE authentifie les pairs à l'aide de certificats numériques, avec une chaîne d'autorités de certification et une vérification facultative des révocations via OCSP, ou à l'aide d'une clé pré-partagée (PSK) échangée hors bande. Les déploiements d'accès à distance peuvent superposer des méthodes EAP telles que MSCHAPv2 ou TLS à IKEv2, afin d'authentifier les utilisateurs individuels plutôt que les identités des appareils.

Qu'est-ce qu'un groupe de Diffie-Hellman dans l'IKE ?

Un groupe de Diffie-Hellman est un ensemble numéroté de paramètres – une taille de module ou une courbe elliptique – utilisé par l'IKE pour permettre à deux pairs de dériver un secret partagé identique sans jamais le transmettre sur le réseau. Les groupes dont le numéro est plus élevé fournissent des clés plus sûres, au prix d'un temps de négociation plus long.

Que se passe-t-il lorsque le partenaire d'un tunnel IKE cesse de répondre ?

La détection de pair inactif envoie une requête de vérification si aucun trafic ne provient du pair dans un délai d'attente configuré. Si le pair ne répond pas, le dispositif met fin à l'association de sécurité et renégocie un nouveau tunnel, plutôt que de laisser en place indéfiniment une connexion obsolète et unilatérale.

En savoir plus sur IKE

Si vous souhaitez en savoir plus, voici des sources auxquelles nous faisons confiance.

RFC 7296 : Protocole d'échange de clés Internet version 2 (IKEv2) RFC 2409 : Échange de clés sur Internet (IKE)
La norme IKEv2 actuelle : échanges de messages, authentification, traversée NAT et renouvellement de clé, tels qu'ils sont mis en œuvre dans les implémentations modernes. La spécification originale de 1998 définissant les phases 1 et 2 de la négociation, remplacée par IKEv2 pour les nouveaux déploiements.

Si vous vous intéressez à IKE, voici quelques liens qui pourraient vous intéresser.

Sécurité du protocole Internet Association de sécurité Groupe de Diffie-Hellman
La suite de protocoles IKE permet à ESP de chiffrer le trafic d'un tunnel à l'aide des clés et de l'association de sécurité négociées par IKE. Le résultat négocié d'un échange IKE : les clés, les algorithmes et la durée de validité qui déterminent la manière dont un tunnel protège son trafic. L'ensemble de paramètres utilisé par l'IKE pour dériver des clés partagées sans les transmettre ; les groupes dont le numéro est le plus élevé privilégient la sécurité au détriment de la charge de calcul.