Résumé

  • RFC 5207 distingue l’échange de base HIP du transport applicatif sous ESP ; un succès de contrôle ne certifie pas le plan de données.
  • Le SPI vu dans un sens ne révèle pas celui du retour, et un état appris sur un pare-feu peut devenir inutile si le chemin, le locator ou la politique change.
  • Un verdict de session saine doit relier paquets de négociation, décisions de chaque middlebox, deux sens ESP, validation aux hôtes et résultat applicatif.

Le bon pare-feu avait appris le mauvais trajet

Une entreprise possède deux sorties. Le premier pare-feu observe un échange HIP initié de l’intérieur, apprend deux valeurs destinées à identifier le trafic protégé et installe un état temporaire. Les quatre messages de l’échange sont présents dans les journaux. Le contrôleur annonce une session établie.

Au moment où les données commencent, la politique de multihoming préfère une autre adresse de retour. ESP atteint le deuxième pare-feu, qui n’a ni reçu le signal ni observé la négociation. Il applique son refus par défaut. Le contrôle a réussi ; l’application ne reçoit rien.

La scène est construite pour l’analyse. RFC 5207 ne rapporte pas cet incident et ne mesure aucun réseau actuel. Elle montre néanmoins pourquoi l’expression « session établie » est trop large lorsqu’elle provient uniquement de la phase de contrôle.

Le document a été publié en 2008 comme RFC informationnelle issue de l’IRTF. Sa fonction principale est de décrire les difficultés de HIP face aux NAT et pare-feu. Il sépare dès l’introduction les paquets de contrôle HIP du trafic de données porté par ESP. Cette séparation est encore une bonne discipline d’exploitation : deux phases, deux surfaces de décision, deux familles de preuves.

Le NAPT cherche des ports que HIP ne lui donne pas

Dans le modèle IPv4 initial, l’échange HIP emploie un type de charge utile IP distinct. Un NAT qui ne modifie que les adresses peut laisser ce paquet traverser. Un NAPT courant doit aussi départager plusieurs machines internes ; il s’appuie normalement sur les numéros de port.

Or ce paquet HIP ne présente pas les ports attendus. Le NAPT ne possède donc pas la clé habituelle pour choisir le destinataire. Si l’initiative vient de l’extérieur, aucun état de traduction créé par un flux sortant ne lui fournit cette décision.

Ce constat ne signifie pas que tout NAPT bloque toujours HIP. Il définit le renseignement manquant. Encapsuler le contrôle dans UDP peut fournir des ports et un état compréhensible. Mais cette réparation porte sur la première phase. Elle ne crée pas automatiquement la représentation nécessaire à ESP.

En IPv6, la forme change : les informations HIP se trouvent dans des en-têtes d’extension. Un filtre qui rejette les extensions inconnues peut interrompre l’échange. La capacité de l’hôte reste intacte alors que la capacité du chemin est nulle. Un inventaire qui attribue l’échec à l’hôte confond donc mise en œuvre et politique intermédiaire.

ESP retire au milieu ce qu’il utilisait pour décider

Après l’échange de base, HIP protège les données avec ESP. Les en-têtes de transport deviennent invisibles au NAT ou au pare-feu. L’équipement ne peut plus utiliser la paire de ports et le protocole applicatif pour classer le retour.

Le SPI semble offrir un substitut. Il est visible dans l’en-tête ESP et peut participer à une règle. Pourtant, sa signification est unidirectionnelle. Le SPI choisi pour A vers B ne permet pas de calculer celui de B vers A. Une observation sortante ne constitue donc pas un état bidirectionnel.

Plusieurs hôtes derrière le même NAT peuvent aussi choisir le même SPI. Une traduction de SPI peut résoudre la collision locale, comme une traduction de port, mais elle ajoute une nouvelle projection. Il faut savoir quel équipement l’a effectuée, quelle valeur originale correspond à quelle valeur publique, dans quel sens et pour quelle durée.

Le SPI ne nomme ni une personne ni une application. Il n’atteste pas la réception par le pair. Il identifie une association de sécurité dans un contexte donné. Lui attribuer une autorité globale transforme un champ précis en conclusion fausse.

Observer la négociation n’est pas gouverner tous les bords

RFC 5207 examine un NAT architecturé, parfois appelé SPINAT, capable d’observer l’échange HIP et d’en apprendre les SPI. Le mécanisme peut être pertinent parce que la négociation expose des données que le premier paquet ESP ne révèle pas à lui seul.

Mais l’apprentissage reste local. Le parseur doit reconnaître la version et les extensions. La politique doit autoriser la règle. L’état doit être installé dans la table qui traite réellement les paquets. Sa durée doit couvrir le trafic. Et la route ESP doit traverser ce même appareil.

Un journal learned n’est donc pas un reçu de forwarding. Il faut conserver le paquet qui a déclenché l’apprentissage, l’identité du dispositif, sa version, la décision de politique, la règle exacte, l’expiration et un compteur de paquets ayant rencontré cette règle.

Cette granularité évite une erreur fréquente : considérer le contrôleur comme le plan de données. Un appel réussi au service de politique démontre qu’une demande a été traitée. Seule une lecture de la table active, puis une observation avant et après le point de contrôle, montre l’effet réel.

Le signal peut atteindre un appareil parfaitement inutile

Les hôtes peuvent aussi signaler explicitement les SPI nécessaires à un système générique de contrôle NAT/pare-feu. RFC 5207 cite MIDCOM et les travaux NSIS NATFW. Cette approche déplace la connaissance : le middlebox n’a pas besoin de parser tout HIP, mais l’hôte ou un mandataire doit viser les bons équipements.

Le multihoming rend ce choix difficile. Si plusieurs frontières existent, quel pare-feu faut-il signaler ? Une demande authentifiée et acceptée par le bord A ne sert pas au retour qui entre par B. La validité administrative du message ne prouve pas sa pertinence topologique.

Le signalement couplé au chemin cherche à joindre les appareils effectivement traversés. Même alors, une convergence de routage ultérieure peut déplacer le trafic. Le reçu doit donc lier la demande à une époque de chemin et vérifier que les paquets suivants ont conservé cette relation.

Ouvrir un pinhole ou créer une association NAT est une action de sécurité. L’identité du demandeur ne suffit pas : il faut aussi l’autorisation, la portée, la durée, la révocation et la preuve de retrait. Une syntaxe HIP correcte ne confère pas à elle seule le droit de traverser une frontière privée.

UDP peut rendre visible le premier succès et le second échec

Un équipement ancien sait souvent traiter UDP. L’encapsulation peut donc permettre à un échange initié de l’intérieur de créer une association et de recevoir des réponses. RFC 5207 refuse toutefois d’en conclure que la session est complète : même lorsque l’échange HIP passe, ESP continue de poser problème.

Les fonctions de « VPN pass-through » ont essayé de rapprocher les flux IPsec à partir des SPI. Le document souligne leur fragilité lorsqu’un grand nombre d’hôtes partagent le même NAT et que les collisions deviennent possibles. Cette aide est une heuristique locale, pas un contrat de bout en bout.

L’encapsulation UDP d’ESP fournit des ports et a nourri des mécanismes HIP ultérieurs, dont RFC 5770 et RFC 9028. RFC 9063 décrit une architecture plus récente. Une citation dans une fiche fournisseur ne prouve pourtant ni activation, ni version, ni politique, ni résultat sur le trajet observé.

Le registre opérationnel doit associer le mode exact, le port, l’adresse externe, le keepalive, l’époque de binding et les paquets reçus aux deux extrémités. NAT traversal supported n’est qu’une déclaration de capacité.

Une preuve propre empêche les remèdes trop larges

Quand l’écran agrège authentification et trafic, chaque équipe hérite d’un coupable commode. L’application accuse le réseau. Le réseau montre l’échange réussi. La sécurité montre la création d’une règle. Le fournisseur affirme supporter HIP. Aucun de ces éléments ne prouve le trajet retour d’ESP.

Sans preuve directionnelle, l’organisation élargit souvent la règle : ESP autorisé depuis davantage d’adresses, expiration prolongée, helper générique activé ou inspection désarmée. Le service peut revenir, mais l’exception dépasse le besoin initial et le diagnostic reste faux.

La chronologie sûre s’arrête au premier reçu absent. I1/R1/I2/R2 vus aux deux extrémités ; SPI sortant et entrant nommés ; état installé à chaque frontière ; ESP vu avant et après ; intégrité, anti-rejeu et déchiffrement acceptés ; transaction applicative terminée. L’absence d’une étape devient un renseignement, pas une invitation à inventer le reste.

Le document décrit une frontière, pas un parc installé

RFC 5207 appartient à une époque précise de HIP et à la série informationnelle. Les mécanismes ont ensuite évolué. Cette histoire doit empêcher deux erreurs opposées : traiter l’analyse de 2008 comme une photographie de tous les réseaux actuels, ou l’écarter parce que des RFC plus récentes existent.

La bonne utilisation est méthodologique. La spécification indique les champs et décisions à observer. Le logiciel déployé indique ce qui a été mis en œuvre. La configuration indique ce qui a été permis. Les captures indiquent le chemin utilisé. Les journaux d’extrémité indiquent le résultat cryptographique. L’application indique l’utilité.

Ces autorités ne se remplacent pas. Le principe de primauté du code en fonctionnement ne réduit pas la valeur du texte ; il refuse simplement que le texte soit pris pour l’état du système.

Un reçu bref peut garder les deux sens

Le dossier minimal doit contenir la version HIP et le mode de traversal, les HIT et locators, les empreintes et temps des quatre messages, le mapping NAT ou la règle de pare-feu, les deux SPI orientés, le principal qui a demandé l’ouverture, la décision et l’expiration de chaque appareil, l’identité du chemin, les observations ESP dans les deux directions, les résultats d’intégrité et de déchiffrement, puis l’identifiant de transaction applicative.

Les lacunes sont marquées inconnu. Cette valeur est essentielle. Elle empêche la réussite locale d’un équipement de devenir une certification de tout le chemin.

Le NAT peut dire qu’il a créé une association. Le pare-feu peut dire qu’une règle a correspondu. L’hôte peut dire qu’il a authentifié le pair et accepté ESP. L’application peut dire qu’un travail a été accompli. La session n’est saine que lorsque ces reçus se rejoignent sans substitution.

Sources