AH ou ESP ? Décidez selon ce que le paquet doit protéger

Deux propositions IPsec peuvent nommer le même algorithme d’intégrité fondé sur SHA et demander pourtant des protocoles de protection différents ; AH et ESP ne sont pas deux orthographes d’un même réglage d’authentification. Lisez d’abord le protocole, puis ses algorithmes, puis son mode, et l’essentiel de l’ambiguïté disparaît. AH authentifie le paquet, y compris les champs d’en-tête IP qui restent inchangés en chemin, tandis qu’ESP authentifie et chiffre ce qu’il encapsule et laisse l’en-tête externe tranquille. Cet écart décide de plus de déploiements que n’importe quel nom de hachage.

Ce que AH couvre et que ESP ne couvre pas

AH fournit l’intégrité, l’authentification de l’origine des données et le service anti-rejeu qu’il définit, et aucune confidentialité. Sa couverture comprend les données de la couche supérieure et les champs d’en-tête IP que ses règles tiennent pour immuables, exactement la partie que ESP en mode transport laisse dehors. Quand une exigence dit que l’en-tête IP lui-même doit être authentifié, AH est le protocole qui y répond.

Cette couverture explique aussi pourquoi AH est fragile sur le terrain. Les champs variables comme le TTL, la somme de contrôle de l’en-tête et certaines options ne peuvent pas être authentifiés parce que les routeurs peuvent les réécrire, donc le protocole les met à zéro avant de calculer le contrôle. Tout ce qui réécrit des adresses casse donc le calcul, et pas seulement la politique.

NAT transforme le choix en contrainte

La traduction d’adresses réécrit la source ou la destination dans l’en-tête IP que AH vient d’authentifier, donc le contrôle d’intégrité échoue à l’autre bout, et il échoue comme erreur de protocole et non comme un message lisible. ESP n’authentifie pas l’en-tête externe, c’est pourquoi ESP avec traversée de NAT fonctionne et AH derrière NAT non. Un tunnel dont les deux extrémités sont derrière des routeurs ordinaires est précisément le lieu où cela apparaît d’abord. La première question n’est donc pas quel protocole est le plus fort, mais s’il y a un traducteur entre les extrémités.

S’il y en a un, AH est écarté, et la conversation passe à ESP et à ses choix d’algorithmes. C’est une contrainte et non une préférence, et c’est pourquoi elle se place en tête de la décision et non à la fin.

Le mode multiplie la question

ESP en mode transport protège la charge utile de la couche supérieure et laisse l’en-tête IP tranquille ; en mode tunnel, il encapsule tout le paquet interne, y compris l’en-tête IP interne, et le protège. AH a les mêmes deux modes, donc AH ou ESP représente en réalité quatre combinaisons avant tout choix d’algorithme.

Les algorithmes ESP en mode combiné règlent ensuite l’intégrité sans second protocole. AES-GCM et ChaCha20-Poly1305 authentifient et chiffrent dans une seule construction, donc ajouter AH par-dessus n’achète rien tout en coûtant un en-tête et une négociation de plus. L’architecture autorise AH et ESP ensemble, et la question pratique est de savoir si votre passerelle et votre version prennent en charge la combinaison et si quelqu’un pourra la maintenir ensuite.

Le remplacement honnête du AH seul

La variante ESP d’intégrité seule conserve l’algorithme et abandonne la prétention au chiffrement au lieu de la simuler, et elle passe NAT. Si une conception héritée utilisait AH parce qu’il fallait une authentification sans confidentialité, cette variante est la traduction directe, et non un tunnel chiffré avec une note attachée.

Voir ESP dans une proposition n’est pas non plus une preuve de chiffrement. Lisez l’algorithme de chiffrement : une entrée NULL signifie intégrité seule, et une entrée en mode combiné signifie les deux.

Décidez en trois questions

Demandez si la confidentialité est requise, si un traducteur se trouve sur le chemin, et quels champs d’en-tête doivent être authentifiés. Ces trois réponses désignent un protocole et un mode, et les écrire prend moins de temps que relire les RFC plus tard.

Vérifiez ensuite ce qui a été accepté et non ce qui a été proposé. ip xfrm state montre le protocole, le mode et les algorithmes de l’association installée, et une discordance n’installe rien, ce qui est un échec plus propre qu’un tunnel qui monte sans la protection voulue.

Gardez les échecs d’authentification, la couverture des sélecteurs et les fautes de routage à part de ce choix. Ils produisent des symptômes différents, et accuser le protocole d’un problème de sélecteur est un moyen sûr de passer une journée à changer des hachages sans raison.