Résumé

  • La RFC 2154 associait une signature persistante à chaque LSA et diffusait une clé de routeur certifiée dans une Public Key LSA, au-delà de la confiance dans le voisin immédiat.
  • Le certificat bornait l’identité, le rôle et les plages d’adresses, sans observer l’existence d’un lien, l’honnêteté d’une métrique ou la disponibilité d’une destination.
  • Il faut donc conserver séparément l’ancre de confiance, la génération de clé, l’âge de la LSA, l’autorisation, la corroboration, le calcul SPF, le FIB et le résultat mesuré.

Un sceau intact devant une baie vide

Une LSA quitte son routeur avec un sceau. Deux relais la propagent sans pouvoir modifier les octets couverts. Tous les contrôles réussissent. Pourtant, au bout de la branche annoncée, la baie du réseau stub est vide. La cryptographie n’a pas menti : elle a correctement attribué une déclaration erronée.

C’est la limite féconde de la RFC 2154, publiée en juin 1997 avec le statut Experimental. L’authentification OSPFv2 ordinaire protégeait le paquet échangé entre voisins. La proposition signait chaque LSA transportée dans un Link State Update. Le voisin restait responsable du paquet local ; la signature de l’Advertising Router voyageait avec la donnée de routage.

Une vérification réussie établissait une provenance précise et l’absence de modification pendant le flooding. Elle ne transformait pas le routeur en capteur infaillible. Si la donnée était fausse à l’origine, le sceau identifiait sa source.

Le certificat ne regardait pas le câble

Une clé publique isolée ne suffit pas : n’importe qui peut revendiquer un Router ID. La RFC créait donc la Router Public Key LSA, ou PKLSA. Une Trusted Entity signait un certificat contenant l’identifiant, le rôle, les plages autorisées, la date de création, l’algorithme et la clé du routeur. Le destinataire vérifiait à la fois la certification TE et la signature du routeur ; un seul échec imposait le rejet.

La confiance avait dès lors un cycle de vie. La clé TE était configurée hors d’OSPF. La PKLSA devait être courante. Une LSA arrivée avant sa clé ne pouvait attendre que MAX_TRANSIT_DELAY. Une nouvelle clé certifiée remplaçait l’ancienne et obligeait le routeur à réémettre ses LSA ; les données liées à la clé précédente devaient disparaître.

Le certificat pouvait limiter les préfixes annoncés. Il ne savait pas si une interface était up, si la métrique était approuvée ou si l’hôte existait. Il certifiait une enveloppe d’autorité, non un état physique.

Même l’âge avait une autorité distincte

LS Age évolue pendant le transport et restait normalement hors signature. L’exception concernait une LSA créée à MaxAge par son origine : l’âge était alors signé, afin que seul l’auteur puisse déclencher un flush signé. Une LSA orpheline vieillissait néanmoins localement jusqu’à MaxAge et disparaissait séparément dans chaque LSDB, au prix d’une convergence plus lente.

Le même principe vaut pour les zones signées et non signées. Une zone ne mélangeait pas les deux formats. À la frontière, l’ABR produisait un résumé sous sa propre autorité. L’intégrité de la première déclaration ne se prolongeait pas magiquement dans la projection.

Le texte décrit lui-même le mensonge signé

La section 9 admet qu’un routeur interne peut annoncer une mauvaise métrique, déclarer up un lien down ou créer un stub et une route d’hôte inexistants. Un faux lien de transit rencontre parfois la corroboration de l’autre extrémité ; un stub n’en possède aucune.

Un ABR peut fabriquer des Summary LSA erronées sur une autre zone ou le backbone. Des contrôles croisés entre ABR sont envisagés puis écartés pour leur coût. Pour les routes externes d’un ASBR, la RFC reconnaît l’absence d’une autorité interne équivalente permettant d’autoriser les réseaux annoncés.

La signature facilite l’attribution lorsque la contradiction est découverte. Elle ne garantit pas sa découverte. La transmission des paquets de données est explicitement hors périmètre : une LSA valide peut alimenter un SPF correct et produire un prochain saut qui perd le trafic.

Neuf reçus sur une même chronologie

Il faut enregistrer la clé TE et son installateur, le certificat du routeur, la génération de clé, l’identité et le hash couvert de la LSA, la décision d’âge ou de remplacement, l’autorisation de changement, la preuve de l’autre extrémité, l’entrée LSDB et le choix SPF, le RIB/FIB, puis une sonde vers la destination et un résultat applicatif.

Les pages RFC Editor, Datatracker et historique fixent le statut Experimental ; les errata ne corrigent qu’une faute. RFC 2328 fournit le socle OSPFv2. RFC 6039 signalait ensuite l’absence d’expérience de déploiement, tandis que RFC 6863 séparait la protection de la donnée et celle contre le replay. RFC 7474 traite une autre frontière, la fraîcheur des paquets après redémarrage. Un brouillon individuel expiré critique les attaques internes sans représenter l’IETF.

Running-Code Primacy, Minimum Initial Specification et Reality Layers servent ici de lecture éditoriale déclarée : l’exécution, la règle commune vérifiable et le symbole de confiance restent trois plans distincts.

Sources