Summary

  • draft-acee-lsr-ospfv3-deprecate-ah-00 propose que les nouvelles implémentations OSPFv3 n’emploient plus l’Authentication Header IPsec et invite les opérateurs à choisir ESP sans chiffrement ou l’Authentication Trailer OSPFv3. Cette révision 00 reste un Internet-Draft individuel.
  • Un lien OSPFv3 n’effectue aucune migration parce qu’un document change d’étiquette. Le nouveau mode doit d’abord être accepté par tous les routeurs, puis devenir le mode d’émission ; l’ancien chemin ne peut disparaître qu’après vérification des adjacences, de la LSDB et du transfert.

Prenons un réseau multi-accès pendant une fenêtre de maintenance. Un premier routeur émet déjà avec le nouveau mécanisme. Un deuxième possède la clé mais pas la bonne association entrante. Un troisième sait traiter le mécanisme, sans l’avoir activé sur cette interface. Le dernier attend toujours AH. Ces quatre configurations peuvent toutes apparaître « prêtes » dans quatre outils différents. Le premier Hello montre qu’elles ne forment pas encore un même système.

Le projet Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication, daté du 30 septembre 2026, vise le Standards Track et mettrait à jour le RFC 4552 s’il était approuvé. Ce n’est ni un RFC, ni une décision déjà appliquée par un groupe de travail, un fournisseur ou un opérateur.

La modification proposée est précise. Le RFC 4552 exige ESP et autorise AH. Le projet déconseille aux nouvelles implémentations d’ajouter AH pour OSPFv3, laisse les implémentations existantes le conserver pour compatibilité avec un avertissement, et recommande de migrer soit vers ESP avec chiffrement NULL, soit vers l’Authentication Trailer du RFC 7166.

ESP-NULL assure ici intégrité et authentification, pas confidentialité. L’Authentication Trailer protège également l’adresse source IPv6 dans son calcul. Aucun des deux mécanismes ne neutralise un routeur compromis qui détient déjà une clé partagée valide.

La préférence documentaire ne négocie rien sur le fil

Les auteurs invoquent l’adoption limitée d’AH pour OSPFv3, son statut optionnel dans le RFC 8221 et le coût de deux chemins de code, de configuration et d’exploitation. Ils notent aussi que les paquets OSPFv3 ordinaires restent sur un lien, avec des adresses locales au lien et un Hop Limit de 1, ce qui réduit l’avantage supplémentaire de la couverture des champs IPv6 immuables par AH.

Ce raisonnement peut guider une architecture. Il ne constitue pas un recensement indépendant des produits et, surtout, il ne change aucun état opérationnel. Un document ne charge pas une clé, ne crée pas une SA entrante et ne demande pas aux voisins quand commencer à émettre autrement.

La révision 00 formule la contrainte : une interface ou un lien virtuel OSPFv3 est configuré avec un seul mécanisme d’authentification, et tous les routeurs du lien doivent s’accorder. L’unité de changement sûre est donc le lien entier.

Recevoir d’abord, émettre ensuite

Le RFC 4552 fournit déjà un ordre de re-clé utile. Chaque routeur reçoit d’abord une nouvelle SA entrante. Quand tous peuvent accepter le nouvel état, les SA sortantes changent. Les anciennes SA entrantes ne sont retirées qu’après le basculement de tous les émetteurs.

Passer d’AH à ESP n’est pas une simple rotation de clé, mais le principe reste valable : accepter le nouveau, émettre le nouveau, retirer l’ancien. Chaque seuil demande une preuve couvrant tous les membres du lien.

Le projet propose soit une préparation coordonnée dans une fenêtre de maintenance, soit un déploiement progressif sur des implémentations capables d’accepter plusieurs mécanismes pendant la transition. Cette capacité doit être testée sur le logiciel en cours d’exécution. Une case dans un catalogue ne démontre ni le comportement entrant ni sa portée par interface.

La période de recouvrement est un compromis. Trop courte, elle fragmente les adjacences. Trop longue, elle maintient un ancien chemin d’acceptation. Elle doit avoir un propriétaire, une liste exacte des routeurs, une échéance et une condition d’arrêt si une seule preuve manque.

La continuité peut élargir temporairement la confiance

L’Authentication Trailer n’est pas simplement un autre nom pour ESP-NULL. Il est transporté avec OSPFv3, s’appuie sur un identifiant de SA et un numéro cryptographique croissant de 64 bits. Le RFC 7166 prévoit aussi un mode de transition facultatif : émettre avec le Trailer tout en continuant d’accepter certains paquets sans celui-ci.

Ce mode aide les voisins anciens à rester joignables, mais le RFC avertit qu’il peut exposer le déploiement à des données non authentifiées pendant la transition. Une adjacence à l’état Full ne suffit donc pas. Il faut savoir par quel chemin d’acceptation les paquets sont passés.

Une preuve cryptographique valide établit l’accès à la clé partagée. Elle n’identifie pas un opérateur précis, ne garantit pas que le routeur n’est pas compromis et n’autorise pas automatiquement le contenu de chaque LSA.

La migration se termine après le retrait, pas avant

La chaîne de preuves doit distinguer : version exacte du projet ; prise en charge effective sur chaque image ; préparation des SA ou du Trailer et de l’époque de clé ; changement sortant ; réception authentifiée des Hello et Database Description ; retour stable de tous les voisins à Full ; convergence de la base d’état de liens ; programmation du transfert et test de trafic ; enfin retrait d’AH ou du mode permissif et répétition des contrôles.

Aucune étape ne prouve la suivante. Une adjacence peut rester Full grâce à l’ancien chemin. Une LSDB convergée ne prouve pas la FIB. Un trafic réussi avant le retrait ne prouve pas que le nouveau mécanisme l’a porté.

Le cadre de Heng Lu — spécification commune minimale, décision future localisée, adoption volontaire et primauté du code en exécution — sépare correctement les rôles. La norme décrit le minimum nécessaire à l’interopérabilité. L’opérateur choisit le mécanisme et la fenêtre. Seuls les paquets réellement vérifiés, les adjacences, la base et le transfert démontrent l’adoption.

La question de direction n’est donc pas « AH est-il désormais déconseillé ? », mais « tous les routeurs acceptent-ils la même nouvelle preuve, à la même époque de clé, et l’ancien chemin est-il effectivement fermé ? »

Sources