Résumé

  • RFC 2406 définissait champ par champ ce qui restait visible, ce qui pouvait être chiffré et ce qui entrait dans l’authentification. Le mode transport laissait l’en-tête IP original dehors ; le mode tunnel protégeait le datagramme intérieur, mais ajoutait un nouvel en-tête extérieur observable.
  • Confidentialité, intégrité et anti-rejeu n’étaient pas une même preuve. Le numéro de séquence était toujours transmis, même si le récepteur désactivait la fenêtre anti-rejeu, et une charge chiffrée ne démontrait ni la dissimulation du flux ni l’acceptation par l’application.

Un tunnel a deux géographies. La première se trouve dans le paquet intérieur : les adresses des correspondants ultimes, invisibles après chiffrement. La seconde se trouve dans l’en-tête extérieur : les adresses des points qui portent le tunnel, nécessaires à chaque routeur du trajet. La première peut être cachée sans que la seconde disparaisse.

Cette géographie double résume l’apport de RFC 2406, publiée en novembre 1998. L’Encapsulating Security Payload n’y était pas présenté comme un état binaire appelé « paquet chiffré ». Le texte réunissait plusieurs services : confidentialité, authentification de l’origine, intégrité sans connexion, anti-rejeu et confidentialité limitée du flux. Leur combinaison dépendait de la Security Association et de l’emplacement du dispositif.

La version de 1995, RFC 1827, avait choisi une enveloppe minimale. Le SPI était son seul champ obligatoire indépendant du transform. Les documents de transform ajoutaient algorithmes, champs et règles. Trois ans plus tard, RFC 2406 expliquait que leur croissance combinatoire rendait nécessaire un socle plus complet. Numéro de séquence, bourrage, Next Header, Authentication Data et ordre des traitements entraient dans la définition commune.

Cette consolidation ne fusionnait pas les garanties. La confidentialité pouvait fonctionner sans authentification ESP. L’authentification pouvait fonctionner avec un algorithme de chiffrement NULL, donc sans secret du contenu. L’une au moins devait être sélectionnée. L’anti-rejeu, lui, exigeait l’authentification et restait un choix du récepteur.

La disposition des champs suffit à comprendre pourquoi. Un en-tête IPv4 ou IPv6 extérieur annonçait le protocole 50. Venaient ensuite le SPI de 32 bits et le Sequence Number de 32 bits, puis Payload Data, Padding, Pad Length, Next Header et, si le service avait été choisi, Authentication Data.

Avec des algorithmes distincts, le chiffrement couvrait Payload Data, le bourrage, sa longueur et Next Header. Il ne couvrait ni l’en-tête IP extérieur, ni le SPI, ni le numéro de séquence, ni l’ICV final. Un vecteur d’initialisation explicite pouvait apparaître au début de la charge. Le document précisait qu’il n’était généralement pas chiffré en lui-même, malgré l’habitude de l’appeler partie du texte chiffré.

L’authentification dessinait une autre surface. L’ICV englobait SPI, Sequence Number, Payload Data, Padding, Pad Length et Next Header. Authentication Data en était exclu puisqu’il portait le résultat. Le chiffrement précédait le calcul, de sorte que l’ICV voyait la forme chiffrée des champs protégés. L’en-tête IP extérieur restait encore hors de cette surface.

En mode transport, l’exclusion était directe. ESP se plaçait après l’en-tête IP original et avant le protocole supérieur. Les adresses originales restaient lisibles. Pour IPv6, les extensions situées avant ESP échappaient également à sa protection ; une option de destination placée après ESP pouvait au contraire entrer dans le périmètre. L’ordre des en-têtes n’était pas seulement syntaxique : il définissait une frontière de sécurité.

Le mode tunnel protégeait davantage de contenu. Le datagramme IP original entier, y compris son en-tête, devenait la charge d’ESP. Mais il fallait créer un nouvel en-tête IP pour acheminer le résultat. Un observateur perdait peut-être les adresses finales et voyait celles des passerelles. La confidentialité du flux dépendait alors de la capacité à mélanger plusieurs communications derrière ces mêmes points visibles.

RFC 2406 employait donc le mot « limitée ». Le masquage des relations bénéficiait du mode tunnel, d’une passerelle et de l’agrégation de trafic. Un bourrage supplémentaire pouvait rendre la longueur de charge moins précise, au prix de bande passante. Il ne supprimait pas le temps, le nombre de paquets, leurs tailles extérieures ni l’identité des extrémités du tunnel.

Le numéro de séquence posait une seconde limite. L’émetteur devait toujours l’insérer et l’incrémenter. Le récepteur pouvait pourtant décider de ne pas activer l’anti-rejeu pour cette SA. Voir le compteur sur le réseau ne prouvait donc pas qu’une fenêtre glissante avait été consultée.

Lorsque l’anti-rejeu était actif, l’authentification devait l’être aussi : sans intégrité, le compteur était modifiable. Le récepteur pouvait écarter provisoirement une valeur manifestement ancienne, mais il ne mettait sa fenêtre à jour qu’après réussite de l’ICV. La preuve complète associait une SA, un compteur authentifié et une décision locale. Une capture réseau ne contenait pas à elle seule ces trois éléments.

L’ordre de traitement continuait cette discipline. La politique IPsec choisissait d’abord une SA appelant ESP ; cette décision appartenait à RFC 2401. L’émetteur encapsulait, bourrait, chiffrait et, si demandé, authentifiait. La fragmentation venait après ESP. À la réception, le réassemblage devait précéder ESP ; un fragment encore présenté au traitement était rejeté et pouvait produire un événement d’audit.

Le récepteur retrouvait ensuite une SA unidirectionnelle à partir de la destination, d’ESP et du SPI. Cette SA indiquait quels contrôles et quels algorithmes employer. L’absence de SA imposait le rejet. Une ICV correcte validait le datagramme à cette étape, puis le déchiffrement reconstruisait le protocole supérieur ou le paquet intérieur. La politique d’entrée et l’application gardaient leurs propres décisions.

Le texte reconnaissait même que certaines sorties erronées pouvaient atteindre les traitements ultérieurs en l’absence d’authentification. Si vérification et déchiffrement étaient parallèles, aucune donnée déchiffrée ne devait être livrée avant la fin de la vérification. La cryptographie protégeait une transition ; elle ne décidait pas de la signification du contenu obtenu.

L’audit n’était pas une garantie automatique. Un système doté d’un audit devait y intégrer ESP et pouvait enregistrer SA absente, fragment inattendu, dépassement de compteur ou échec d’ICV. Mais tous les systèmes n’étaient pas tenus d’offrir l’audit, et sa granularité restait locale. Une norme qui nomme un événement ne prouve pas qu’un journal existe encore.

RFC 4303 a remplacé RFC 2406 en 2005. Elle a conservé la séparation entre champs visibles, confidentialité, intégrité, modes transport et tunnel et anti-rejeu contrôlé par le récepteur, tout en ajoutant notamment les numéros de séquence étendus, les modes combinés et un bourrage TFC explicite. RFC 2406 décrit donc une étape historique, non un conseil cryptographique actuel.

La leçon rejoint la méthode de Lu Heng : vérifier l’effet exécutable plutôt que laisser un label absorber toutes les conséquences. « ESP activé » ne dit pas quel mode fut choisi, quels services furent associés, quel trafic resta observable, si le récepteur vérifia le rejeu ni ce que l’application accepta. Le diagramme de 1998 obligeait déjà à poser ces questions séparément.

Sources