Qu’est-ce qu’IKEv2 ? Comprendre réellement le protocole

IKEv2 (Internet Key Exchange version 2) est le protocole de négociation défini par l’IETF (RFC 7296) permettant d’établir un tunnel IPsec sécurisé. Il authentifie le client et le serveur, négocie les paramètres cryptographiques et génère les clés utilisées par IPsec.
Point essentiel :
IKEv2 ne chiffre rien.
Le chiffrement, l’intégrité et la protection du trafic sont assurés par IPsec, via ESP (Encapsulating Security Payload).
IKEv2 orchestre. IPsec protège.

Illustration : Découvrir IKEv2

Développé par Microsoft et Cisco, IKEv2 s’est imposé comme standard sur mobile grâce à MOBIKE, une extension permettant de maintenir le tunnel VPN lors d’un changement d’adresse IP (Wi-Fi → 4G). Sa stabilité en mobilité, combinée à un support natif dans iOS, macOS, Windows et Android moderne, en fait un protocole incontournable.
Cette analyse clarifie son fonctionnement réel, ses garanties de sécurité, ses limites (notamment face à la censure), et les contextes où IKEv2 est un bon choix, ou un mauvais.

Qu'est-ce que IKEv2 ? : Sommaire

IKEv2 et IPsec : deux couches distinctes

IKEv2 : négociation

  • Authentification (certificats X.509, PSK, EAP)
  • Négociation des algorithmes cryptographiques
  • Échange Diffie-Hellman et dérivation des clés
  • Création des Security Associations (SA)

IPsec : chiffrement

  • Chiffrement via ESP
  • Intégrité via HMAC-SHA2
  • Transport des paquets
  • Conséquence pratique :
    La sécurité d’un tunnel IKEv2/IPsec dépend autant de la configuration IPsec que de la négociation IKEv2.

Fonctionnement d’IKEv2 : les 4 phases

IKEv2 simplifie radicalement IKEv1 : quatre messages seulement, réduisant la latence et les risques de désynchronisation.

Phase 1 — IKE_SA_INIT (2 messages)

Échange des propositions cryptographiques
Sélection du groupe Diffie-Hellman
Création du secret partagé
Pas encore d’authentification
Résistance accrue aux DoS via cookies de validation

Phase 3 — CREATE_CHILD_SA

Rekeying périodique sans recréer tout le tunnel
Possibilité de créer plusieurs Child SA pour différents flux
Réduit l’exposition des clés et le risque d’attaques long terme

Phase 2 — IKE_AUTH (2 messages)

Authentification mutuelle
Validation des identités
Création du premier Child SA
IPsec devient opérationnel

Phase 4 — DPD + MOBIKE

Dead Peer Detection : détection des pairs inactifs
MOBIKE : mise à jour des SA en cas de changement d’adresse IP
Assure la continuité du tunnel, même en mobilité

MOBIKE : l’avantage structurel d’IKEv2

MOBIKE (RFC 4555) est la fonctionnalité qui distingue réellement IKEv2 de la plupart des protocoles.

Pourquoi c’est essentiel

Un appareil mobile change fréquemment d’IP :

  • Wi-Fi → 4G
  • changement d’antenne
  • réveil après mise en veille

Sans MOBIKE, le tunnel casse. Avec IKEv2, il continue.

Limitations

  • Le client et le serveur doivent supporter MOBIKE
  • Certains fournisseurs ne l’activent pas côté serveur

Fonctionnement simplifié

1. Le client détecte une nouvelle interface réseau
2. Il notifie le serveur
3. Le serveur met à jour la SA
4. Le tunnel reste actif
→ Interruption : souvent < 1 seconde

Cas d’usage

  • Smartphones iOS/Android
  • Laptops très mobiles
  • VPN d’entreprise avec MFA
  • IoT en mouvement (véhicules, équipements industriels)

Sécurité : forces et limites réelles

A. Forces de sécurité

Perfect Forward Secrecy

  • Chaque session utilise un échange Diffie-Hellman unique.
  • Compromettre une clé n’expose pas les sessions passées.

Authentification robuste

  • Certificats X.509
  • PSK (acceptable dans de petits environnements, mais à risque si partagé)
  • EAP-TLS pour MFA et intégration RADIUS/AD

EAP-MSCHAPv2 est obsolète (vulnérable aux attaques par dictionnaire)

Algorithmes modernes

  • AES-128/256
  • Camellia (optionnel)
  • HMAC-SHA2
  • Groupes DH 14 à 21 (2048 à 521 bits)
  • ECDH modernes : X25519 / X448 selon la configuration IPsec

Maturité du protocole

  • Déployé depuis 2005 (RFC 4306), finalisé via RFC 7296
  • Maintenu par l’IETF IPsecME Working Group
  • Faiblesses d’IKEv1 corrigées
  • Vulnérabilités actuelles = erreurs d’implémentation, pas de conception

Icone de clés

B. Limites structurelles

Blocage par la censure (DPI)IKEv2/IPsec est trivial à identifier :

  • UDP 500
  • UDP 4500
  • ESP (IP 50)

Conséquence : blocage en Chine, Iran, Turkménistan, Égypte, Émirats…
Des contournements existent (IKEv2-over-TCP/TLS), mais :

  • hors standard
  • rares
  • instables
  • inefficaces face aux DPI industrielles

→ Sa signature réseau ne peut pas être déguisée sans sortir du RFC.

Complexité du code IPsec
Implémentations typiques :

  • strongSwan : ~200 000 lignes
  • Libreswan : ~150 000
  • kernel Linux (XFRM) : ~35 000

→ Total : 200 000 à 400 000 lignes
WireGuard : ~4 000.

Conséquence :
Plus de code = plus de chemins d’exécution = plus de bugs potentiels.
Exemple : strongSwan → 15+ CVE 2015–2023 (parsing, fragmentation).
WireGuard → 0 CVE critique à ce jour.

Serveur compromis = échec total
IKEv2 protège contre les attaquants réseau, pas contre un serveur compromis.
Le modèle de confiance repose sur :

  • la PKI
  • la politique de logs du fournisseur
  • la sécurité de l’infrastructure

Aucun protocole VPN n’élimine ce risque.

Performances, compatibilité et contraintes réseau

A. Performances

Avantages :

  • handshake court
  • cryptographie en espace noyau
  • overhead très faible (surtout avec AES-NI)

En débit brut :

  • WireGuard souvent plus rapide
  • IKEv2 très performant en usage réel (streaming, VoIP, navigation)

B. Compatibilité native

Système Support
iOS/iPadOS natif, stable
macOS natif
Windows natif
Android natif depuis Android 11 (API 30) ; implémentations constructeur avant
Linux nécessite strongSwan
→ IKEv2 idéal sur iOS/macOS/Windows
→ WireGuard/OpenVPN dominent sur Linux

C. Restrictions réseau

IKEv2 peut être bloqué si :

  • UDP 500 / 4500 filtrés
  • ESP interdit
  • portails captifs perturbent IPsec

OpenVPN TCP 443 contourne mieux ces blocages.

Quand utiliser IKEv2 (et quand l’éviter)

A. Scénarios où IKEv2 est excellent

strong>Mobilité
Le protocole le plus stable en mouvement :

  • MOBIKE
  • reconnexions instantanées
  • latence faible

Écosystème Apple / Microsoft
Support natif → simplicité → stabilité.
Réseaux non censurés
Expérience stable sans DPI agressive.
Environnements professionnels

  • certificats X509
  • EAP-TLS / RADIUS
  • flexibilité IPsec

B. Scénarios où éviter IKEv2

Censure
IKEv2 bloqué dans la majorité des pays utilisant la DPI.
→ alternatives : OpenVPN TCP 443, WireGuard + obfuscation tierce.

Linux desktop
strongSwan robuste mais complexe.
→ WireGuard recommandé.

Auditabilité prioritaire
IPsec = 200k–400k lignes
WireGuard = ~4k lignes
→ Avantage massif à WireGuard.

Comparatif IKEv2 vs WireGuard vs OpenVPN

Critère IKEv2 WireGuard OpenVPN
Mobilité ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐
Censure ⭐ ⭐⭐ (obfuscation tierce) ⭐⭐⭐⭐
Auditabilité ⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐
Performance ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐
Mode TCP Non standard Non Oui
iOS natif Oui Non Non
Simplicité du code Faible Très élevée Moyenne
Idéal pour Apple/Windows, mobilité Linux, performance Censure, compatibilité universelle

Ressources supplémentaires

IKEv2 en 2026 : excellent, mais pas universel

IKEv2 est un protocole robuste, mature et extrêmement efficace sur mobile grâce à MOBIKE et à son intégration native dans les OS Apple et Microsoft.
En contexte non censuré, il offre une combinaison rare de stabilité, rapidité, une faible latence ainsi qu’une intégration système exemplaire
Cependant, ses limites sont structurelles. Il est repérable par la DPI, le code IPsec est massif (auditabilité difficile) et le support Linux est moins fluide
Vérité utile :
IKEv2 excelle dans son domaine, mobilité et intégration native, mais ne remplace pas WireGuard ou OpenVPN.
Un fournisseur VPN sérieux doit proposer les trois, et adapter automatiquement :

  • Mobilité → IKEv2
  • Linux, auditabilité, performance → WireGuard®
  • Censure, ports bloqués → OpenVPN TCP 443

Les autres protocoles VPN

Pour replacer IKEv2 dans son contexte et mieux comprendre les compromis propres à chaque protocole VPN, consultez également :

  • WireGuard — protocole moderne, minimaliste et très performant
  • PPTP — protocole obsolète et compromis, à éviter
  • L2TP — encapsulation ancienne reposant sur IPsec
  • OpenVPN — protocole open source flexible et massivement audité
  • SoftEther — suite VPN multi-protocoles orientée flexibilité

  • Shadowsocks — proxy chiffré conçu pour la censure active, pas un VPN, pas d’anonymat

Share This