Résumé

  • La révision 07 permet de transporter IKEv2 sur TCP tout en gardant ESP sur IP natif ou UDP, mais l’authentification réussie et la création d’une Child SA n’attestent pas l’accessibilité du chemin ESP.
  • La mise en service doit s’appuyer sur des reçus séparés : accord de capacité, état NAT propre à chaque transport, réponse ESP chiffrée, trafic applicatif et décision de repli.

Le piège commence par un tableau de bord presque trop rassurant. La connexion TCP est établie, les pairs IKEv2 se sont authentifiés, le matériel de clé a été échangé et la Child SA existe. Pour un centre d’exploitation pressé, le mot « tunnel » paraît mérité.

Il ne l’est pas encore.

Le pare-feu qui a laissé passer TCP peut refuser ESP natif. Le NAT qui entretient la connexion de contrôle ne possède peut-être aucune translation UDP pour les paquets protégés. La négociation a abouti, mais le service n’a toujours aucun chemin utilisable.

Le document actif de l’IPsecME, Separate Transports for IKE and ESP, transforme cette contradiction en règle d’exploitation. Sa révision 07 est un Internet-Draft de l’IETF, destiné au Standards Track, dont l’état Datatracker gelé est « WG Consensus: Waiting for Write-Up ». Ce n’est ni un RFC ni une preuve de déploiement. Son apport est de séparer deux jugements que les outils ont l’habitude de confondre.

IKEv2 s’appuie historiquement sur UDP. RFC 9329 a ensuite défini l’encapsulation TCP d’IKE et d’ESP lorsqu’UDP est bloqué. Cette solution améliore la traversée des réseaux restrictifs, mais place aussi le trafic ESP sous les contraintes de TCP. Dans le même temps, les échanges post-quantiques grossissent les clés publiques et les messages de contrôle. TCP devient attrayant pour la négociation sans être nécessairement souhaitable pour le trafic du tunnel.

La révision 07 introduit donc SEPARATE_TRANSPORTS. Si les deux pairs acceptent cette notification, les échanges IKE suivants restent sur TCP tandis qu’ESP utilise IP directement ou une encapsulation UDP sur le port 4500 en présence de NAT. Si le répondant ne confirme pas la capacité, IKE et ESP restent tous deux sur TCP conformément à RFC 9329.

Cette notification exprime une possibilité commune. Elle ne certifie pas la route choisie.

La différence apparaît nettement au démarrage. Lorsque IKE_SA_INIT passe d’abord par UDP, son aller-retour fournit déjà une indication de joignabilité UDP. Lorsqu’il commence sur TCP, aucune donnée de ce type n’existe pour ESP. Une fois la Child SA créée, l’initiateur doit donc vérifier le chemin ESP, sauf s’il détient une preuve équivalente, par exemple des paquets ESP entrants.

Une association de sécurité peut ainsi être correcte sur le plan cryptographique et inutilisable sur le plan opérationnel. Le draft le précise sans ambiguïté : l’impossibilité de confirmer ESP n’affaiblit pas, à elle seule, l’authentification IKEv2 ni la protection cryptographique de la Child SA. C’est la disponibilité qui manque. Dire « échec d’authentification » serait faux ; dire « service disponible » le serait tout autant.

Le NAT rend cette dualité mesurable. Les équipements intermédiaires conservent leur état par transport. La session TCP d’IKE n’entretient pas la translation UDP d’ESP. Les pairs doivent envoyer les keepalives nécessaires au chemin ESP. Une adresse apprise grâce à un paquet ESP valide met à jour les SA ESP concernées, pas l’extrémité IKE ; un message IKE protégé peut déplacer l’extrémité de contrôle sans fournir de preuve pour ESP.

Le pair est le même, les mémoires réseau ne le sont pas.

En démarrage TCP, le draft propose une épreuve ordonnée. Si un NAT a été détecté, l’initiateur sonde ESP encapsulé dans UDP sur le port 4500. Sans NAT détecté, il préfère ESP direct puis essaie aussi UDP après un bref délai sans réponse, car certains intermédiaires n’acceptent pas les paquets IP dépourvus de transport UDP ou TCP. Le premier chemin qui répond est retenu. C’est une logique proche de Happy Eyeballs : garder une préférence, sans transformer la préférence en panne longue.

L’Echo ESP chiffré peut servir de sonde. Sa réponse constitue une preuve forte mais limitée : une requête et une réponse ESP protégées ont traversé ce chemin sous cette SA. Elle ne démontre ni le passage de toutes les tailles de paquets, ni l’exactitude de tous les Traffic Selectors, ni la santé de l’application au-delà du tunnel. Il faut encore observer un trafic représentatif et son résultat.

Si aucun chemin ESP n’est confirmé, l’initiateur doit supprimer l’IKE SA courante puis la rétablir sur TCP sans proposer la séparation. Le repli rassemble à nouveau IKE et ESP sous RFC 9329. La politique locale doit décider auparavant si cette continuité dégradée est acceptable ou si l’établissement doit être interrompu.

Le choix dépend du service. Un accès d’urgence à travers un réseau filtrant peut accepter ESP sur TCP. Une charge sensible à la latence ou au débit peut le refuser. Un environnement soumis à contrôle peut exiger un reçu de chemin avant d’ouvrir les flux. Le protocole offre une bifurcation ; l’organisation doit désigner le propriétaire du risque.

MOBIKE ne dispense pas de recommencer l’épreuve. Une nouvelle adresse signifie de nouvelles règles intermédiaires et, en présence de NAT, une nouvelle translation. La continuité de l’IKE SA sur TCP ne transporte pas l’ancienne preuve ESP vers le nouveau réseau. De même, la reprise de session ne doit pas mémoriser le choix des transports : le client a pu changer de réseau pendant son absence, et la décision doit être renégociée.

La discipline rejoint les notes de Heng Lu sur la spécification minimale et les couches de réalité. Le standard partage la capacité interopérable minimale ; la décision future reste auprès de l’extrémité qui possède les faits actuels. Un objet symbolique « SA établie » n’a pas priorité sur le fait physique d’un paquet protégé qui traverse. Le running code n’est pas une ligne d’état : c’est l’échange réel, observé sur le chemin retenu.

Le dossier d’exploitation devrait donc conserver séparément le transport d’IKE, l’accord SEPARATE_TRANSPORTS, le résultat NAT, le chemin ESP essayé, son mapping et ses keepalives, la première réponse protégée, le test applicatif, l’autorité qui accepte le repli et toute revalidation après mobilité ou reprise. Le résumé « VPN up » est trop pauvre pour gouverner cette architecture.

Sources