Résumé

  • Déposé le 30 septembre, draft-acee-lsr-ospfv3-deprecate-ah-00 propose de déconseiller l’en-tête d’authentification IPsec AH pour OSPFv3. Le texte oriente vers ESP avec chiffrement NULL ou vers la bande d’authentification déjà définie par RFC 7166. Il reste un Internet-Draft individuel, à l’état I-D Exists, et ne modifie pas aujourd’hui RFC 4552.
  • Le projet place la migration au niveau du lien : les routeurs qui y participent doivent s’accorder sur le mécanisme. RFC 7166 avertit qu’une divergence d’identifiant d’association de sécurité, de type d’authentification ou d’empreinte peut empêcher l’adjacence ; son mode transitoire permissif comporte, lui, une exposition aux paquets non authentifiés.

Le formulaire d’exploitation peut afficher « AH désactivé » sur une machine alors que le réseau n’a rien résolu. OSPFv3 échange ses paquets avec d’autres routeurs sur le même lien. Si ceux-ci attendent toujours AH, si les clés ne correspondent pas ou si le nouveau mécanisme n’est pas accepté, le changement local devient un problème d’adjacence. Voilà pourquoi le nouveau projet mérite une lecture de terrain plutôt qu’un simple inventaire d’algorithmes.

Son statut est limité. La fiche Datatracker présente la révision 00 du 30 septembre comme un Internet-Draft actif soumis par un auteur individuel, avec l’état IESG I-D Exists. Le document porte un en-tête mentionnant le groupe Link State Routing et la formule « Updates: 4552 (if approved) ». La condition est déterminante : ni adoption par le groupe de travail ni approbation d’une mise à jour de la norme ne se déduisent de ce libellé.

Le choix proposé s’inscrit dans un socle déjà connu. RFC 4552 exigeait le support d’ESP pour l’authentification OSPFv3 et ne rendait AH que facultatif. RFC 7166 a ensuite normalisé une bande d’authentification indépendante d’IPsec. La nouveauté du texte n’est donc pas la découverte d’une sortie de secours. Il demande aux nouvelles implémentations de ne plus mettre en œuvre AH pour OSPFv3, laisse les anciennes le conserver pour compatibilité en signalant sa dépréciation et recommande une migration vers l’une des deux options existantes. Les prescriptions d’ESP contenues dans RFC 4552 restent inchangées.

ESP avec chiffrement NULL n’équivaut pas à l’absence d’authentification : le chiffrement des données est nul, mais intégrité et authentification demeurent l’objet du mécanisme. La bande d’authentification suit une autre procédure et d’autres associations de sécurité. Le projet juge coûteux de maintenir une voie AH supplémentaire dans le code, les clés et les opérations. Il évoque une faible adoption d’AH, sans fournir dans les sources examinées un comptage vérifiable des réseaux OSPFv3 qui l’emploient encore. Cette motivation ne doit pas être transformée en statistique de déploiement.

Le paragraphe de migration du projet demande que tous les routeurs d’une interface ou d’un lien virtuel s’entendent sur l’authentification. Il envisage une préparation coordonnée des nouveaux paramètres et des clés en fenêtre de maintenance. Une progression par étapes dépend explicitement de la capacité réelle des équipements à accepter plusieurs mécanismes pendant le passage. Elle n’est pas une propriété garantie d’OSPFv3 ni une promesse de continuité sans incident.

RFC 7166 apporte un avertissement qu’il serait dangereux d’effacer. La discordance des paramètres d’authentification y est associée à un échec de formation de voisinage. Son mode de transition, facultatif, vise l’introduction de la bande d’authentification dans un environnement comportant encore des routeurs sans authentification configurée ; des paquets non authentifiés peuvent y être acceptés. Ce n’est pas un pont universel et sûr entre AH et la bande. Avant de l’utiliser, l’opérateur doit savoir exactement ce que chaque équipement accepte, et pendant combien de temps.

Le bon reçu de changement porte donc deux résultats distincts : les voisinages sont revenus et les paquets acceptés sont protégés comme prévu. Le projet rappelle en outre qu’un routeur compromis muni de clés valides n’est pas neutralisé par l’un ou l’autre mécanisme. Nous n’avons trouvé ni mesure d’adoption, ni incident observé, ni preuve de prise en charge par un fournisseur dans ces textes. La proposition réduit un menu normatif possible ; elle ne certifie pas une migration particulière.

Sources