Résumé

  • Dans RFC 9986, le récepteur BFD compare une Auth Key de 32 bits issue d’une séquence ISAAC à clé. La correspondance peut attester la connaissance du secret et une position recevable, pas l’intégrité des autres champs du paquet.
  • La preuve exploitable doit conserver la version du logiciel, les discriminators, l’époque de clé, le seed, la fenêtre de séquence, l’état des pages ISAAC, le résultat et la réauthentification MCI ultérieure. Elle ne vaut ni état de route ni résultat de service.

Le premier rapport de test était exact : identifiant de clé reconnu, position admise, valeur reçue égale à la valeur calculée. Le second rapport, destiné à la direction, avait raccourci le tout en « paquet authentifié ». La simplification avait changé la nature de la preuve.

Ce cas est construit ; il ne décrit ni fournisseur, ni réseau, ni incident. Il met en lumière la limite énoncée par RFC 9986. Meticulous Keyed ISAAC fournit le mécanisme LCI de l’architecture optimisée de RFC 9985. Le texte précise aussi que ces paquets ne sont pas signés, ne sont pas authentifiés en tant que paquets et ne doivent pas signaler de changement d’état.

La comparaison répond à une question étroite : avec le secret partagé, les valeurs de la session BFD, le seed et une position admissible, le pair a-t-il produit la même sortie de 32 bits ? Si oui, on dispose d’un signal de connaissance et de synchronisation. Les champs Diagnostic, State, Poll, Final, Demand, les timers et les discriminators ne sont pas pour autant liés par une empreinte couvrant le paquet.

L’expression Auth Key est trompeuse si elle devient un verdict global. Un nom de champ indique une fonction protocolaire, pas l’étendue mathématique d’une garantie. L’audit doit inventorier les octets entrant dans le calcul et ceux qui restent hors de sa portée.

La section définie par RFC 9986 porte notamment le type, la longueur, le Key ID, le seed, un décalage de numéro de séquence et l’Auth Key de 32 bits. Le récepteur choisit la clé, vérifie le seed, cherche une position dans sa fenêtre puis calcule une valeur candidate. Une égalité valide le test LCI spécifié. Aucun authenticator n’enveloppe le corps complet du paquet.

La comparaison avec RFC 8439 est utile pour le vocabulaire. Dans une construction AEAD, le tag lie le texte chiffré et les données associées. Il ne s’agit pas de prescrire ChaCha20-Poly1305 à BFD, mais de rappeler que vérifier un tag portant sur du contenu n’est pas comparer une sortie pseudorandom isolée.

La preuve ISAAC possède aussi un état temporel. Le générateur émet des pages et avance de manière destructive. Pour tolérer pertes, retards et certains réordonnancements, le récepteur peut calculer une page future. RFC 9986 lui impose alors de sauvegarder puis de restaurer l’état. Sans cette discipline, une simple exploration déplace la séquence active : le prochain paquet légitime peut être rejeté et la décision antérieure devient impossible à rejouer.

Le seed ouvre et ferme une époque. Chaque transition vers Up exige un seed nouveau ; il reste ensuite fixe tant que cette époque Up dure. Un journal disant seulement « Key ID 4 : match » a perdu le repère essentiel. Il faut réunir seed, époque Up, position de séquence et règle de fenêtre. Le secret ne doit pas apparaître dans un journal public ; son époque de provisionnement et de rotation, elle, peut être tracée.

La réutilisation encadrée d’une clé ne supprime pas la gouvernance. Les données de session différencient les sorties, mais une même clé couvrant un vaste parc agrandit les conséquences d’une fuite, d’une rotation partielle ou d’archives lacunaires. Le bon objet de contrôle est la population de sessions, les entrées de dérivation, le propriétaire et l’échéance de chaque époque de clé.

Le statut du document interdit aussi l’excès de confiance. La notice RFC Editor le classe Experimental. La baisse de coût accepte une baisse de sécurité ; ISAAC n’y est jugé qu’au mieux tolérable, avec une cryptanalyse limitée et sans preuve, et ne convient pas à d’autres protocoles IETF. L’étude IACR fonde la prudence, pas l’affirmation d’une attaque contre un déploiement RFC 9986.

Le mécanisme n’est pas davantage un certificat d’interopérabilité générale. Il s’insère dans RFC 9985 et ne saurait être présumé compatible avec l’authentification ordinaire de RFC 5880. Le registre IANA BFD Parameters attribue des valeurs de protocole ; il ne recense ni implémentations, ni adoption, ni réussite opérationnelle.

RFC 5881 borne l’observation à un chemin de transmission à un saut. RFC 7419, RFC 8177 et RFC 9127 donnent le contexte cryptographique. Aucun de ces textes ne transforme l’acceptation LCI en preuve de routage, de transaction applicative ou d’expérience client.

La réauthentification MCI périodique de RFC 9985 reste un contrôle distinct. Elle peut limiter la durée d’un état Up inapproprié selon l’intervalle choisi ; elle n’authentifie pas rétroactivement le contenu des paquets ISAAC intermédiaires. Les événements doivent être reliés, jamais fusionnés.

Les couches de réalité de Heng Lu séparent standard, capacité, configuration, observation, état BFD, réaction cliente et effet de service. Running-Code Primacy place le comportement constaté avant l’étiquette RFC. Minimum Initial Specification invite à partager un reçu minimal tout en laissant la décision ultérieure au responsable local.

Ce reçu nomme la base RFC et errata, le build, les deux discriminators, le Key ID, l’époque de provisionnement, le seed et l’époque Up, les positions émises et reçues, la fenêtre, la page ISAAC, les sauvegardes et restaurations, le résultat, les champs non protégés, le MCI, la réaction cliente, le décideur et le retour arrière. Il permet de rejouer le raisonnement sans divulguer le secret.

La correspondance a une valeur précisément parce qu’elle reste une affirmation limitée.

Sources