Résumé

  • RFC 7474 associe un compteur de démarrages de 32 bits à un compteur de paquets de 32 bits. L’époque survit en mémoire non volatile ; le récepteur rejette, pour chaque type de paquet OSPF, toute valeur qui ne dépasse pas la dernière valeur acceptée.
  • Acee Lindem est l’éditeur d’un texte collectif signé avec Manav Bhatia, Sam Hartman et Dacheng Zhang. La limite opérationnelle est nette : perte du compteur persistant signifie changement obligatoire des clés, tandis que la rotation normale exige des durées d’émission et d’acceptation cohérentes des deux côtés.

Un paquet ne vieillit pas tout seul

Un attaquant peut conserver un paquet OSPF Database Description sans connaître la clé qui l’a authentifié. Tant que le voisin garde en mémoire une séquence plus récente, le paquet enregistré est inutilisable. Puis l’adjacence tombe, le processus repart et l’état volatil revient à son point initial. Le paquet n’a acquis aucun nouveau droit. C’est le vérificateur qui a perdu la preuve de son ancienneté.

RFC 7474, publié sur le Standards Track en avril 2015, part de cette rupture. Dans le mécanisme précédent, la séquence cryptographique appartenait à l’état de l’adjacence. La disparition de l’adjacence pouvait donc remettre le compteur à zéro et rouvrir un espace où un ancien message, toujours correctement authentifié, paraissait plus récent.

Le document est l’œuvre de Manav Bhatia, Sam Hartman, Dacheng Zhang et Acee Lindem, ce dernier étant éditeur. Le profil public IETF de Lindem établit cette participation et une longue activité sur les protocoles de routage. Il ne prouve ni une invention solitaire, ni un contrôle sur OSPF, ni la conformité d’un produit. L’objet de cet article est plus précis : lire sa contribution dans une norme collective qui refuse qu’un redémarrage efface la chronologie de sécurité.

Le hachage répond à « qui », pas à « quand »

RFC 5709 avait introduit des algorithmes HMAC-SHA pour l’authentification OSPFv2. Ses auteurs sont Manav Bhatia, Vishwas Manral, Michael Fanto, Russ White, Michael Barnes, Tony Li et Randall Atkinson ; Lindem n’en est pas coauteur. Le passage à un mécanisme plus robuste protège mieux contre la falsification. Il ne suffit pas à distinguer un paquet actuel d’une copie authentique plus ancienne.

RFC 6039, par Vishwas Manral, Manav Bhatia, Joel Jaeggli et Russ White, décrit le problème plus général des clés manuelles dans les protocoles de routage : secrets durables, rotation difficile, rejeu et contexte incomplet. Il sert ici à caractériser la menace, non à attribuer ses analyses à Lindem.

Une console peut donc afficher « authentication succeeded » tout en omettant la question décisive. Le détenteur de la clé a-t-il produit ce message dans l’époque actuelle, pour ce protocole, depuis la source dont dépend l’identité du voisin ? L’intégrité des octets, la fraîcheur et le domaine d’usage sont trois preuves différentes.

Une époque conservée dans l’obscurité

RFC 7474 étend la séquence à 64 bits. Les 32 bits de poids fort contiennent le compteur de démarrages ; les 32 bits de poids faible, un compteur de paquets strictement croissant. Le premier désigne l’époque, le second la position du message dans cette époque.

Le compteur de démarrages doit rester en mémoire non volatile pendant toute la vie déployée du routeur OSPFv2. Chaque perte de l’ancien état de séquence, y compris un redémarrage à froid, l’incrémente. Le texte autorise l’emploi de snmpEngineBoots, mais recommande un compteur propre à OSPF afin qu’une réinitialisation SNMP ne devienne pas, par accident, l’horloge cryptographique du routage.

La partie basse augmente à chaque paquet émis. À la réception, la valeur doit dépasser celle du dernier paquet du même type accepté depuis ce voisin. Sinon, le paquet est un rejeu et doit être abandonné. La comparaison par type est importante : une priorité de traitement peut faire arriver des Hello et des Link State Update dans un ordre différent sans que l’un soit frauduleux.

Si les 32 bits bas atteignent leur limite, le compteur de démarrages peut avancer à nouveau pour préserver la monotonie de l’ensemble. La norme ne masque donc pas le redémarrage. Elle en fait un changement authentifiable qu’aucun enregistrement appartenant à une époque antérieure ne doit pouvoir dépasser.

Les huit octets de séquence sont placés après le paquet OSPF et couverts par le digest. Le type d’authentification 3 identifie la nouvelle forme, et le Key ID passe à 32 bits. Sans protection cryptographique de l’époque, un attaquant pourrait la remplacer ; sans distinction entre types de paquets, un réordonnancement légitime pourrait être pris pour une attaque.

L’adresse source entre dans la preuve

L’ancien calcul ne couvrait pas l’en-tête IPv4. Or, sur les réseaux broadcast et NBMA, OSPF utilise l’adresse source IP pour déterminer de quel voisin vient le paquet. Modifier cette adresse sur un enregistrement valide pouvait donc déplacer l’effet du message vers l’état de séquence d’un autre voisin sans invalider le digest.

RFC 7474 insère l’adresse source IPv4 dans les quatre premiers octets de la valeur de bourrage utilisée par RFC 5709. L’émetteur authentifie l’adresse qu’il emploie ; le récepteur reprend celle réellement reçue. Toute substitution provoque désormais un échec d’authentification. Les scénarios visés incluent un voisin rendu artificiellement unidirectionnel ou une perturbation de l’échange Database Description.

Le choix est volontairement étroit. Tous les champs IPv4 ne deviennent pas immuables. La norme protège celui qu’OSPF consulte pour attribuer le paquet à un voisin. Elle partage le minimum nécessaire au sens interopérable, puis laisse le reste de la conduite réseau à l’opérateur.

La clé reçoit aussi un nom de protocole

Une base de clés de longue durée peut exposer le même secret à plusieurs protocoles. Sans séparation de domaine, une construction valide dans un usage peut parfois être transportée dans un autre. RFC 7474 ajoute un identifiant cryptographique OSPFv2 de deux octets à la clé avant le calcul.

Le secret stocké peut être identique par décision locale, mais la clé effective dit désormais « OSPFv2 ». Cette protection ne rend pas le partage souhaitable : une compromission du secret reste commune, et des clés séparées réduisent le rayon d’impact. L’identifiant de protocole limite une erreur d’architecture ; il ne la transforme pas en bonne pratique.

Une rotation possède deux fenêtres

Une clé d’émission n’est utilisable que pendant sa SendLifetime. Une clé de réception doit se trouver dans sa propre AcceptLifetime. L’asymétrie est utile : on peut commencer à accepter la nouvelle clé avant que tous les routeurs ne l’émettent, puis conserver brièvement l’ancienne en réception après le basculement.

La sélection tient également compte de l’algorithme, du pair ou de l’aire, de l’interface et de la direction. Une correspondance explicite l’emporte sur all. Si plusieurs clés d’émission restent candidates, celle dont le début de validité est le plus récent est choisie, ce qui permet une rotation progressive. Le Key ID du paquet guide le récepteur vers la clé symétrique, mais ce dernier vérifie encore interface, pair, direction et période d’acceptation.

Une rotation fiable est donc une séquence. Distribuer la nouvelle clé. Ouvrir son acceptation. Déplacer l’émission. Observer les adjacences. Fermer l’ancienne acceptation après preuve. « Deux clés installées » ne dit ni si leurs fenêtres se recouvrent, ni si les horloges concordent, ni si les deux extrémités ont sélectionné la même transition.

Refuser vaut mieux qu’abaisser silencieusement

Le nouveau type d’authentification n’est pas négocié vers une forme plus faible. S’il ne correspond pas au type configuré sur l’interface, le paquet est rejeté selon les règles OSPF existantes. Une migration partielle peut donc empêcher une adjacence.

Cette panne visible est préférable à une relation apparemment saine où chaque extrémité donne un sens différent à la fraîcheur. Le déploiement est une migration bilatérale : code compatible, type identique, clés effectives correspondantes, recouvrement temporel et état monotone. La réussite n’est pas la sauvegarde d’une configuration, mais l’acceptation symétrique, l’adjacence stable et le forwarding observé.

Perdre la mémoire périme la clé

La règle la plus coûteuse de RFC 7474 concerne la réparation, la mise à niveau ou le remplacement qui détruit le compteur non volatil : les clés d’authentification doivent changer. Restaurer l’ancien fichier de configuration ne restaure pas l’époque qui séparait les paquets du jour de ceux enregistrés hier.

Un appareil peut retrouver son Router ID, ses aires, ses adresses et les mêmes secrets, tout en ayant perdu le seul fait qui empêchait les anciennes captures de rivaliser avec sa nouvelle séquence basse. La continuité administrative devient alors une vulnérabilité cryptographique.

Le texte conserve d’autres réserves. Le rejeu d’un établissement complet et identique de session pour un routeur totalement retiré reste un scénario très improbable ; changer les clés le bloque aussi. Deux liens point à point non numérotés utilisant la même adresse source et la même séquence devraient recevoir des clés distinctes sous la menace d’une écoute active. La gestion automatique des clés demeure hors périmètre.

Spécification minimale, garde locale

La réflexion ultérieure de Lu Heng, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption, fournit à Sofia Ren une grille de lecture. Le format de séquence, la source authentifiée, l’identifiant de protocole, le Key ID et la règle de rejet peuvent former l’accord minimal. La génération des clés, leur stockage, leur portée, le calendrier de rotation et la reprise restent des responsabilités locales.

Running-Code Primacy fixe le test : relier le compteur persistant, la séquence émise, la clé choisie, le digest lié à la source, la décision de réception, les compteurs de rejeu, l’adjacence et le trafic. Ces textes sont l’analyse ultérieure de Sofia Ren ; ils ne décrivent ni l’intention privée de Lindem ni une intention IETF absente des RFC.

L’attaquant peut garder la mémoire plus longtemps que le routeur. RFC 7474 rend cette asymétrie mesurable et réversible. Si le routeur ne peut plus prouver son passé, l’ancienne clé ne doit pas authentifier son avenir.

Sources