Résumé

  • Les RFC 5202 et 7402 exigent que l’information ESP_INFO d’un rekey HIP reste accessible aux systèmes intermédiaires qui suivent les SPI. Le HMAC et la signature rendent le message vérifiable, pas confidentiel.
  • Une gouvernance exacte distingue le chiffrement du contenu, l’authenticité du contrôle, l’observabilité des coordonnées et la durée de leur conservation.

Partir du tableau du pare-feu

Imaginons un audit qui ne regarde pas d’abord le paquet, mais la table d’état. Une ligne associe une destination et un SPI à un contexte HIP. Quelques secondes plus tard, une autre ligne apparaît et l’ancienne attend son expiration. Cette chronologie est le travail normal d’un intermédiaire conscient de HIP.

ESP ne peut fonctionner sans sélecteur. La RFC 4303 place le SPI de 32 bits et le numéro de séquence avant la charge chiffrée. Ces champs sont protégés par l’intégrité, mais ne sont pas chiffrés. Ils permettent au récepteur de trouver la bonne association de sécurité et de traiter l’anti-rejeu.

Avec HIP, le SPI représente de manière compacte une paire de HIT. Cette représentation est circonstancielle : seul le couple destination/SPI désigne le HIT récepteur à un instant donné. Une même valeur peut exister ailleurs, et le même couple peut désigner un autre contexte plus tard. Parler d’« identifiant permanent » serait donc faux ; traiter la valeur comme du bruit serait tout aussi faux.

Le choix explicite de la RFC 5202

Le rekey transporte un paramètre ESP_INFO contenant l’ancien SPI, le nouveau et un indice dans le matériau de clés. L’UPDATE comprend aussi le séquencement, parfois une contribution Diffie–Hellman, un HMAC et une signature HIP. La réponse ajoute son acquittement et son propre état.

Le texte historique ne laisse aucune ambiguïté sur l’objectif. Les systèmes intermédiaires qui utilisent les SPI doivent inspecter les paquets HIP de rekey. Le paquet est signé à leur bénéfice. Comme ils peuvent avoir besoin du nouveau SPI, son contenu ne peut pas être chiffré. La RFC 7402, qui remplace la RFC 5202, conserve cette formulation dans une spécification Standards Track.

L’architecture échange donc volontairement une part de confidentialité de contrôle contre une continuité de fonction intermédiaire. Cela ne signifie pas que la charge ESP devient lisible. Cela signifie qu’une phrase commerciale comme « tout est chiffré » ne décrit pas le système réel.

Une preuve cryptographique peut accroître l’utilité d’une métadonnée

Une signature ne se contente pas d’accompagner la donnée. Pour l’intermédiaire autorisé, elle transforme une transition visible en transition attribuable au contexte cryptographique attendu. La fiabilité opérationnelle augmente précisément parce que le champ demeure disponible.

Il faut donc consigner deux résultats séparés. HIP_SIGNATURE vérifiée signifie que le vérificateur nommé a accepté le message sous les algorithmes et les clés indiqués. ESP_INFO non chiffré signifie que la coordination était accessible sur le chemin. Aucun résultat n’annule l’autre.

Le raccourci inverse est dangereux. Un observateur qui voit le champ n’a pas automatiquement l’identité civile d’une personne, l’organisation exploitante ou le contenu applicatif. Il dispose d’une coordonnée temporelle. La portée de l’inférence dépend de ce qu’il possède déjà : HIT, locateurs, historique, table d’association, autres capteurs et durée de conservation.

La rotation ne supprime pas le passé

Les RFC recommandent un SPI aléatoire, un SPI différent à chaque échange avec un pair et un changement obligatoire au rekey. Ce sont des précautions contre la réutilisation et le rejeu. Elles n’effacent pas une observation déjà stockée.

Une capture qui relie l’ancien et le nouveau SPI peut survivre au délai de la table opérationnelle. Un export vers un SIEM, un dossier d’incident ou une sauvegarde transforme une transition éphémère en trace durable. La RFC 9063 recommande aussi de faire tourner les identités hôtes non publiées pour perturber la traçabilité. Cette politique d’extrémité ne constitue pas une politique de suppression chez les intermédiaires.

La RFC 6973 donne le vocabulaire adéquat : l’analyse de trafic déduit des informations à partir de la présence, du sens, du moment, de la taille ou de la fréquence, même quand le flux est chiffré. L’enjeu n’est donc pas de prétendre que le SPI révèle tout. Il est de reconnaître qu’un événement structuré et daté peut faciliter une liaison.

Un registre de divulgation, pas un badge

Pour chaque pare-feu, NAT, sonde ou exportateur qui consomme ESP_INFO, l’opérateur devrait publier un enregistrement interne comprenant : finalité, champs lus, règle d’installation, administrateurs autorisés, destinations d’export, délai d’expiration et preuve de suppression.

Le reçu d’un événement doit garder le point d’observation, la direction, les locateurs, une référence protégée aux HIT si nécessaire, les deux SPI, la coordonnée SEQ/ACK, le résultat HMAC/signature, la version de règle et le délai prévu. Une trace distincte doit ensuite établir l’installation de la nouvelle SA au terminal, le premier paquet authentifié sur le nouveau SPI et la disparition de l’ancien état.

Cette séparation empêche un autre abus : lire le rekey n’est pas prouver qu’il a réussi. Un intermédiaire peut mettre sa table à jour alors qu’un terminal n’installe jamais la nouvelle association. La visibilité, la validité et l’effet sont trois réalités.

Le statut documentaire compte

La RFC 5202 date de 2008, était Experimental et a été rendue obsolète. Son erratum retenu corrige seulement « transport » en « transform » dans une phrase sans rapport avec cette analyse. En 2015, la RFC 7402 a repris le mécanisme pour HIPv2 sur la voie Standards Track.

Le rapport d’expérience RFC 6538 et l’architecture RFC 9063 documentent par ailleurs la tension entre protection de l’identité et participation des middleboxes. Les intermédiaires HIP peuvent observer passivement le trafic et maintenir un état souple. Ce n’est pas une raison pour leur prêter un mandat illimité ; c’est une raison pour rendre ce mandat explicite et minimal.

Décision de direction

Exiger quatre attestations différentes dans les contrats et les tableaux : contenu chiffré, contrôle authentifié, métadonnée observable, copie supprimée. Refuser tout produit qui répond à ces quatre questions par un seul voyant.

La spécification minimale peut justifier la lecture temporaire nécessaire à l’interopérabilité. Elle ne justifie ni l’analytique secondaire, ni la conservation indéfinie, ni le partage opaque. La primauté du code en cours d’exécution commence par le paquet réellement émis et se termine par la preuve que ses dérivés ont expiré.

Sources

  1. RFC 5202 en HTML
  2. RFC 5202 en texte
  3. Fiche RFC 5202
  4. Datatracker IETF : RFC 5202
  5. Historique RFC 5202
  6. Références RFC 5202
  7. Errata RFC 5202
  8. RFC 7402 en HTML
  9. RFC 7402 en texte
  10. Fiche RFC 7402
  11. Datatracker IETF : RFC 7402
  12. Historique RFC 7402
  13. Références RFC 7402
  14. Errata RFC 7402
  15. RFC 4303 — ESP
  16. RFC 4301 — architecture IPsec
  17. RFC 9063 — architecture HIP
  18. RFC 6538 — rapport d’expérience HIP
  19. RFC 6973 — considérations de vie privée
  20. Heng Lu — couches de réalité et pouvoir symbolique
  21. Heng Lu — spécification initiale minimale
  22. Heng Lu — primauté du code en exécution