Résumé

  • RFC 2401 séparait la base de politiques de sécurité, ordonnée, de la base des associations actives : la première décidait de rejeter, laisser passer ou protéger un trafic ; la seconde conservait les paramètres d’associations à sens unique.
  • Ni la règle ni l’association ne constituaient le reçu d’un paquet. À l’émission, AH ou ESP devait réellement être appliqué ; à la réception, le paquet devait subir le traitement cryptographique puis une comparaison entre les associations employées et la politique entrante.

Deux registres dominaient l’architecture. Dans le premier, la Security Policy Database, chaque trafic recevait un sort. Dans le second, la Security Association Database, chaque association active conservait ses paramètres. Un troisième registre n’était pas une table : c’était le parcours effectif du paquet. Toute la discipline de RFC 2401 consistait à ne pas confondre ces trois réalités.

Publié en novembre 1998, le texte rassemblait une architecture de sécurité à la couche IP pour IPv4 et IPv6. Il décrivait contrôle d’accès, intégrité sans connexion, authentification de l’origine, protection contre le rejeu, confidentialité et une confidentialité limitée du flux. Ces services ne formaient pas un bloc indivisible. AH, ESP, modes transport ou tunnel, algorithmes et gestion des clés produisaient des garanties différentes selon leur combinaison.

La SPD devait, en pratique, couvrir tout paquet entrant ou sortant, y compris le trafic qui n’utiliserait pas IPsec. Ses entrées étaient totalement ordonnées. Des sélecteurs — adresses et champs des couches supérieures — définissaient le trafic visé. La première politique applicable menait à l’un de trois résultats : rejet, contournement d’IPsec ou application d’IPsec. Dans ce dernier cas, elle précisait encore protocole ou faisceau de protocoles, mode, algorithmes et ordre d’imbrication.

L’ordre n’était donc pas une commodité de présentation. Une règle générale placée avant une exception étroite pouvait décider du sort du paquet avant que l’exception ne soit examinée. Le sens comptait aussi : les sélecteurs et exigences d’une politique sortante ne se transféraient pas mécaniquement au contrôle entrant. Pour démontrer une décision, il fallait connaître la version chargée, l’interface, le sens, les sélecteurs et la position de la règle.

La SAD répondait à une autre question. Une association de sécurité était simplex, consacrée à un seul sens ; une protection bidirectionnelle ordinaire exigeait donc deux associations. L’association était identifiée par le Security Parameters Index, l’adresse de destination et le protocole AH ou ESP. Son entrée pouvait contenir l’état de séquence et d’anti-rejeu, les algorithmes et clés, la durée de vie, le mode et l’état de MTU de chemin.

Cet état était nécessaire sans être une preuve d’usage. La présence d’une association ne disait pas quel paquet l’avait sélectionnée. Elle ne prouvait ni la réception par le pair, ni l’autorisation par l’application, ni le résultat du service. RFC 2367 avait exposé la gestion de cet état au moyen de PF_KEY ; RFC 2401 replaçait cette opération dans un contrat plus large entre politique et traitement de paquets.

À l’émission, l’enchaînement devenait concret. Le paquet était comparé à la SPD. Le rejet arrêtait son parcours. Le contournement autorisait une transmission ordinaire sans IPsec. Une règle de protection choisissait une association convenable ou déclenchait la création de l’association ou du faisceau requis. Les opérations AH ou ESP devaient ensuite être exécutées dans l’ordre prescrit avant la transmission ou le routage. La politique stockée et l’association active restaient en amont de l’acte qu’elles étaient censées provoquer.

La réception ajoutait un contrôle décisif. L’adresse de destination, le protocole de sécurité et le SPI retrouvaient d’abord une association. Le traitement propre à AH ou ESP pouvait vérifier intégrité et origine, appliquer l’anti-rejeu et déchiffrer lorsque le service le prévoyait. Une réussite cryptographique ne suffisait pourtant pas à autoriser le paquet.

Après traitement des en-têtes IPsec, le paquet résultant devait correspondre à une politique entrante. L’implémentation vérifiait alors que les associations réellement utilisées, dans leur ordre réel, satisfaisaient cette politique. Si une règle candidate échouait à cette comparaison, d’autres règles applicables devaient être examinées. Le paquet ne pouvait atteindre la couche transport ou être routé qu’après cette vérification. Validité cryptographique et autorisation politique étaient deux reçus distincts.

AH et ESP ne permettaient pas davantage le raccourci « IPsec a chiffré ». L’Authentication Header de 1998 fournissait intégrité et authentification de l’origine, avec anti-rejeu optionnel, mais aucune confidentialité. ESP pouvait fournir la confidentialité et, en option, authentification et intégrité, avec une autre étendue de protection. Le contournement signifiait explicitement l’absence de protection IPsec.

Le document reconnaissait enfin ses dépendances. La sécurité globale reposait aussi sur la qualité de l’implémentation, la protection du système d’exploitation, les sources aléatoires et l’administration. RFC 3168 a ensuite modifié le traitement d’ECN. RFC 4301 a remplacé l’architecture en 2005 et affiné bases de politiques, sélecteurs, fragments et autorisation des pairs. RFC 2401 ne doit donc pas servir de guide de déploiement contemporain.

Sa leçon historique tient dans une séparation. L’intention politique, l’état installé et l’exécution du paquet appartiennent à des couches de preuve différentes. Les textes de Lu Heng sur le code en fonctionnement, la validation locale et les couches de réalité offrent ici une grille d’analyse ultérieure, non le vocabulaire du RFC.

Cette grille conduit à conserver une chaîne complète : source et version de la politique, chargement, correspondance ordonnée, protection requise, association actuelle, opération réellement exécutée, contrôle entrant, remise à la frontière réseau ou transport, réception par le pair, traitement applicatif et résultat de service. Aucun maillon ne vaut quittance pour le suivant.

Sources