Résumé

  • Daté du 1er octobre, le brouillon IPSECME en révision 08 vise désormais expressément un message IKE protégé reçu sur une nouvelle connexion TCP dont l’adresse IP source et/ou le port a changé. L’hôte peut employer cette connexion pour l’association IKE, mais ne doit pas modifier le point d’origine des associations ESP enfants.
  • Le texte ajoute un autre indice prudent : si des échanges bidirectionnels sont attendus, l’absence de paquets ESP entrants peut révéler un problème de connectivité. Une sonde ESP chiffrée demeure possible. Ni le silence ni la réussite d’IKE sur TCP ne constituent à eux seuls un diagnostic du chemin de données.

On peut négocier un tunnel et ne jamais voir passer les données qu’il est censé protéger. Le paradoxe n’est qu’apparent. IKEv2 entretient la relation de contrôle ; ESP transporte les paquets utiles. Lorsque les deux empruntent des transports différents, une connexion TCP stable pour IKE ne garantit ni le passage d’ESP sur IP ou UDP ni la persistance de son état NAT. C’est précisément la séparation que traite la proposition du groupe de travail IPSECME, encore au stade d’Internet-Draft.

La modification décisive de la version 08 se trouve dans les considérations NAT. La version 07 parlait d’un message IKE protégé venant d’une nouvelle adresse ou d’un nouveau port. La nouvelle rédaction précise qu’il arrive sur une nouvelle connexion TCP avec adresse IP source et/ou port différents. L’hôte non placé derrière le NAT utilise cette connexion pour la seule association IKE ; il ne doit modifier l’adresse ni le port source d’aucune association ESP issue de cette association IKE. À l’inverse, un paquet ESP valide du point de vue de l’intégrité possède sa propre règle de mise à jour des associations ESP. Les deux événements ne sont pas interchangeables.

Cette précision ne signifie pas que la version 08 aurait inventé le mécanisme. Le brouillon prévoyait déjà une notification SEPARATE_TRANSPORTS. Un initiateur peut commencer IKE sur UDP 4500 et, si le répondant renvoie la notification, effectuer les échanges suivants sur TCP. Il peut aussi démarrer directement sur TCP lorsque le premier échange est volumineux. ESP reste alors sur IP direct ou UDP si possible. Si le répondant d’une tentative TCP ne renvoie pas la notification, IKE et ESP doivent tous deux passer par TCP conformément au mécanisme existant de la RFC 9329. Ce contexte éclaire la révision ; il n’en est pas la nouveauté.

L’autre retouche porte sur l’observation. En présence d’un trafic censé être bidirectionnel, aucun paquet ESP reçu est un signe possible de défaut de connectivité. La version précédente évoquait surtout la sonde ESP chiffrée ; celle-ci demeure une solution de rechange. Une absence de trafic peut aussi traduire une application inactive, une politique de filtrage voulue ou un mauvais point de mesure. Le brouillon ne permet pas d’attribuer automatiquement ce silence à un pare-feu, à un NAT ou à une attaque.

La séparation des états NAT et de l’épreuve de joignabilité figure déjà dans l’architecture du texte. Les keepalives du TCP IKE ne maintiennent pas la correspondance UDP d’ESP. Si IKE démarre sur TCP, ses échanges réussis ne prouvent pas qu’ESP atteint le pair ; une fois l’association enfant créée, l’initiateur devrait vérifier ce chemin, sauf preuve équivalente. S’il ne peut confirmer l’accessibilité, le texte lui impose de supprimer l’association IKE et de la recréer sur TCP sans proposer un transport ESP séparé. Ce repli est une réponse au manque de preuve sur les données, pas une conséquence logique de la seule poignée de main IKE.

Datatracker indique que le document actif a été soumis pour publication et que celle-ci est demandée ; il ne s’agit pas encore d’une RFC. Le numéro de notification est toujours à attribuer dans le texte. Aucune source examinée n’établit une panne réelle ni l’adoption par un produit. L’actualité tient à une frontière de compétence rendue plus nette : une reconnexion du contrôle ne peut pas redessiner silencieusement le chemin ESP.

Sources