Résumé

  • draft-ietf-ipsecme-encrypted-esp-ping-03 transporte une requête et une réponse Echo dans des SA ESP établies et permet de demander un SPI précis pour le retour.
  • Le SPI demandé exprime une intention ; seul le SPI réellement observé dans la réponse indique quelle SA de retour a fonctionné à cet instant.
  • Ni une réponse positive ni un silence ne suffisent à conclure sur le trafic métier : politique SPD, compteurs authentifiés, charge du répondant et résultat applicatif restent des preuves distinctes.

Le test part par le lien satellite et demande un retour par la fibre. Quelques millisecondes plus tard, l’identifiant et le numéro de séquence correspondent, l’authentification ESP réussit et la console affiche « reçu ». Pourtant la réponse a emprunté la SA satellite. La fibre n’a rien prouvé.

C’est la distinction la plus utile de la révision 03. La fiche courante et l’historique la présentent comme l’Internet-Draft actif du groupe IPsecME, publié le 4 mai 2026. L’API des soumissions montre bien une révision 04 téléversée le 28 septembre, mais son état reste uploaded. Le texte publié et analysable demeure la révision 03 : un travail en cours, pas un RFC ni un rapport de déploiement.

Le mécanisme intervient après l’établissement d’une SA. La requête Echo est un paquet ESP protégé par cette SA. Le premier mode réutilise la charge de contrôle de congestion de USE_AGGFRAG. Le second négocie ENCRYPTED_PING_SUPPORTED dans IKE_AUTH et emploie un format dédié. Les registres IANA actuels des sous-types AGGFRAG et des notifications IKEv2 ne contiennent pas encore les noms proposés : les valeurs du projet restent à attribuer.

Le format dédié porte un identifiant de requête, un numéro de séquence Echo, une longueur, des données facultatives et, si le bit correspondant est activé, un SPI de retour sur 32 bits. Ce numéro Echo ne remplace pas la séquence ESP. Les données peuvent être raccourcies lorsque les ressources manquent. Surtout, le SPI demandé n’est pas une commande absolue.

L’initiateur doit vérifier que le SPI appartient à sa base de SA et au même pair. Le répondant effectue sa propre validation. Si sa politique ne lie pas ce SPI au pair, il ne doit pas l’utiliser ; il peut répondre sur la SA qui a reçu la requête. Même si la validation réussit, la révision 03 ne lui impose qu’un meilleur effort et lui laisse la décision finale. L’initiateur doit donc signaler la différence entre retour demandé et retour réel.

Cette latitude vient de l’architecture IPsec elle-même. RFC 4301 définit une SA comme une connexion simplexe. Une communication bidirectionnelle ordinaire exige une paire. Le même RFC exige que plusieurs SA puissent partager les mêmes sélecteurs, tandis que leur répartition reste un choix local de l’émetteur. Deux SA peuvent donc représenter le même trafic logique tout en traversant des chemins et des politiques distincts.

Une réponse authentifiée fournit alors un reçu précis : la requête a quitté l’équipement par telle SA et la réponse a été associée à telle autre SA. RFC 4303 encadre cette association par le SPI, les adresses lorsqu’elles participent à la recherche SAD, l’intégrité et éventuellement l’anti-rejeu. Ce reçu ne remonte pas jusqu’au service utilisateur.

Le trafic normal passe par un autre contrôle. La SPD de RFC 4301 choisit PROTECT, DISCARD ou BYPASS selon les sélecteurs et la politique locale. Le projet Echo prévoit justement que son paquet ne soit pas soumis à la politique de sécurité ordinaire et qu’un pair puisse l’accepter sans adresse locale correspondante dans la SPD. Cette exception rend le diagnostic possible ; elle interdit de présenter son succès comme preuve qu’un paquet client de mêmes adresses apparentes, mais de ports, protocole ou taille différents, sera traité pareillement.

RFC 9347 fournit AGGFRAG_PAYLOAD et la charge de contrôle réutilisée. Ses tunnels sont eux aussi unidirectionnels. Il précise que le mode IP-TFS ne fournit pas une livraison fiable des paquets internes ni des accusés par paquet. Une petite sonde réussie ne certifie donc ni le sort d’un paquet plus grand, ni la fragmentation, ni la remise à l’application.

Le silence impose une discipline différente. Une fois ENCRYPTED_PING_SUPPORTED négocié, le pair s’engage à répondre sur les SA ESP entre les deux extrémités. Cette promesse donne plus de poids à l’absence. Mais le texte maintient des contraintes locales de ressources et ne dit qu’un délai dépassé peut indiquer une panne. Il demande ailleurs de ne pas démonter une connexion sur cette seule absence.

La vérification complémentaire est le compteur de paquets ou d’octets entrants par SA. Une progression signifie que des paquets ESP authentifiés arrivent encore. Elle ne prouve pas la réponse Echo, la direction opposée ou l’usage par une application. Elle suffit néanmoins à réfuter le verdict trop large « plus aucun chemin chiffré ne fonctionne ». Un sous-système cryptographique chargé peut continuer à traiter du trafic et manquer la réponse de diagnostic.

La réussite d’IKE n’est pas davantage une preuve du plan de données. RFC 7296 établit les associations et leurs sélecteurs. Le projet Separate Transports for IKE and ESP illustre une séparation encore plus visible lorsque IKE emprunte TCP. Le projet ESP Echo avant IKE est, lui, non authentifié et répond à une autre question.

La référence à RFC 7110 explique l’enjeu du retour imposé. LSP Ping pouvait déclarer un LSP défaillant uniquement parce que sa réponse s’était perdue sur un chemin IP différent. Demander un retour déterminé réduit cette ambiguïté ; cela ne transforme pas la demande en preuve d’exécution.

Le dossier de preuve doit donc conserver la révision du projet et l’état IANA, la capacité négociée, l’identité des pairs, l’heure, l’identifiant et la séquence de la requête, le SPI de départ, le SPI de retour demandé, le SPI réellement reçu, le verdict cryptographique, les compteurs avant/après, la charge locale, puis les sélecteurs, la décision SPD, la taille et l’accusé applicatif du trafic métier.

La distinction des couches de réalité empêche de confondre annonce de capacité, configuration, paquet observé et résultat. La spécification initiale minimale justifie un format commun vérifiable sans centraliser les seuils de retrait. La primauté du code en fonctionnement rappelle enfin qu’un texte et une négociation décrivent une possibilité ; les SA actives et les résultats observés établissent la réalité opérationnelle.

Sources