Résumé

  • Dans RFC 9986, ISAAC fournit les valeurs d'authentification par pages de 256. Produire la page suivante est irréversible et détruit la page courante.
  • Avant de franchir cette limite pour vérifier un paquet, le récepteur doit copier tout l'état ISAAC. Une correspondance valide le nouvel état ; un échec restaure la copie.
  • Ce mode atteste la continuité d'un émetteur déjà en état Up, sans garantir l'intégrité de tout le paquet ni celle d'un service de bout en bout. La preuve d'exploitation doit montrer la validation comme la restauration, sans révéler les secrets.

Vérifier l'avenir sans perdre le présent

BFD échange des messages très fréquents afin de détecter rapidement la défaillance d'une adjacence. À cette cadence, authentifier chaque message avec le calcul le plus coûteux peut dépasser les capacités du matériel visé. RFC 9985 sépare donc les changements importants, protégés par une méthode forte, des messages qui maintiennent une session déjà Up.

RFC 9986 définit pour ce second cas un mode fondé sur ISAAC. Un secret partagé, une graine propre à la session et des valeurs issues de BFD initialisent un flux pseudo-aléatoire. Les résultats sont rangés par pages de 256 nombres de 32 bits. À l'intérieur d'une page, retrouver la valeur associée à un numéro de séquence coûte presque rien. Après la dernière case, la fonction de mélange fabrique une nouvelle page.

C'est là que l'optimisation change de nature. La fabrication est irréversible : l'ancienne page disparaît. Or le paquet qui oblige le récepteur à regarder sur la page suivante n'est pas encore authentifié. S'il est faux et que le récepteur a déjà avancé son unique état, rejeter le message ne suffit plus. Le vérificateur a déplacé sa propre référence à la demande de l'entrée qu'il devait juger.

La règle de RFC 9986 est donc une règle d'ordre. Avant tout calcul susceptible de créer une page, le récepteur doit conserver une copie de l'état ISAAC complet. Si la valeur obtenue correspond à l'Auth Key du paquet, l'ancienne copie peut être abandonnée et le nouvel état devient courant. Si elle ne correspond pas, le récepteur rétablit l'état sauvegardé ; la version modifiée est éliminée ou isolée pour un éventuel usage ultérieur.

La décision ne devient irréversible qu'après la preuve.

La perte de paquets autorise un saut, pas un blanc-seing

Ce regard vers l'avant n'est pas une anomalie. Plusieurs messages peuvent disparaître entre deux réceptions. Le numéro de séquence, augmenté à chaque émission, indique alors combien de positions il faut parcourir dans la page ISAAC. Une valeur correcte permet aux deux extrémités de se resynchroniser malgré la perte.

La recherche reste bornée. Lorsque le dernier numéro reçu est connu, RFC 9986 n'admet que la plage allant du numéro suivant jusqu'à trois fois Detect Mult plus loin, dans l'espace circulaire de 32 bits. Un numéro extérieur est rejeté avant de recevoir l'autorité d'entraîner une recherche arbitraire. Un numéro intérieur peut nécessiter une nouvelle page — et donc la sauvegarde.

Un journal d'exploitation utile conserve l'ancien numéro accepté, le numéro reçu, Detect Mult, la plage calculée, la base et l'index de page, ainsi que le fait qu'un mélange ait été nécessaire. Pour un succès, il montre que la copie précède le mélange et que le nouvel index est validé. Pour un échec, il montre que l'empreinte opaque de l'état initial réapparaît exactement.

Ni le secret ni l'état brut du générateur n'ont leur place dans ce journal. Une empreinte non reconstructible, des horodatages et le résultat suffisent. Publier de quoi prédire la prochaine valeur au nom de la transparence détruirait la sécurité que la preuve devait documenter.

L'émetteur est reconnu, le contenu ne l'est pas entièrement

Le champ Auth Key du format ISAAC contient la sortie de 32 bits liée à la graine, au secret et au numéro de séquence. Il ne contient ni résumé ni hachage du paquet de contrôle BFD. RFC 9986 précise donc que le contenu du paquet n'est pas authentifié dans son ensemble.

Une correspondance établit un fait limité : seul l'émetteur authentique pouvait produire ce signal de continuité. Le mode n'est utilisable que lorsque la session est déjà Up. Il ne peut pas annoncer un changement d'état. L'établissement de l'état, ses transitions et les contrôles périodiques plus forts reviennent au mode plus coûteux, qui vérifie l'intégrité du paquet.

Cette frontière entre maintien peu coûteux et autorité de changement est déjà le sujet d'un Article de production sur RFC 9985. Ici, l'objet est distinct : même pour un contrôle de continuité autorisé, l'algorithme de vérification peut franchir un seuil interne irréversible et doit garder une voie de retour.

La portée de BFD reste locale. Une session Up ne prouve pas qu'une application répond, qu'une route est correcte, qu'un client atteint son service ni qu'une charge utile a traversé un chemin complet. Le mécanisme répond à la question précise de l'adjacence qu'il surveille.

Un compromis expérimental, pas une recommandation universelle

Ashesh Mishra cosigne RFC 9986 avec Alan DeKok, Mahesh Jethanandani, Sonal Agarwal et Jeffrey Haas. Son nom figure également sur le projet précurseur de 2017, sur RFC 9985 et sur un brevet antérieur relatif à l'optimisation des contrôles d'intégrité BFD. Cette continuité documentaire relie Mishra au problème ; elle ne transforme pas un travail collectif en invention individuelle.

RFC 9986 est un document IETF expérimental. Son analyse de sécurité ne vend pas ISAAC comme le futur de la cryptographie. L'algorithme répond à la contrainte de systèmes dépourvus d'accélération matérielle adaptée. Il a été moins analysé que d'autres techniques, n'apporte aucun avantage lorsque cette accélération existe et est déclaré impropre aux autres protocoles IETF.

D'autres limites restent volontairement chez l'opérateur. La distribution des secrets n'est pas spécifiée. L'identifiant de clé ne peut pas être changé au milieu de la session faute de mécanisme de resynchronisation ; une rotation exige l'arrêt administratif et le réensemencement de BFD. Séparer les clés des modes fort et léger limite certains dommages, mais accroît le risque de configuration incohérente entre pairs.

La spécification commune s'arrête à ces frontières. Elle donne un comportement interopérable sans retirer aux exploitants la responsabilité des choix qu'ils contrôlent.

Tester le refus qui ne doit rien casser

Le scénario décisif est un paquet invalide placé juste après une limite de page, mais encore dans la fenêtre de perte permise. Le banc d'essai prend une empreinte privée de l'état, injecte un mauvais Auth Key et vérifie quatre événements dans l'ordre : copie terminée, mélange exécuté, comparaison échouée, état antérieur restauré. Le paquet légitime suivant doit ensuite être accepté.

Le même essai doit couvrir une mauvaise graine, un mauvais identifiant de clé, un mode ou une longueur incorrects, les sauts hors fenêtre et le bouclage du compteur. Il faut mesurer le coût de la copie, du mélange et de la restauration, puis soumettre une rafale de candidats futurs invalides pour détecter une consommation illimitée de mémoire ou de CPU.

Le reçu public mentionne la version du logiciel, la session, le ticket, l'identifiant de clé non secret, la fenêtre de séquence, la base et l'index, l'empreinte opaque de la sauvegarde, les durées et la décision de validation ou de retour. Il complète le contrôle fort périodique et la répétition d'une rotation avec redémarrage.

Qui contrôle quelle partie de la décision

Le principe d'agence de Heng Lu permet d'éviter une attribution magique. Les auteurs définissent l'invariant interopérable. Le développeur choisit la représentation et la protection de la copie. L'exploitant choisit les secrets, le rythme des contrôles forts et le moment du redémarrage. Le code du pair décide si une valeur correspond. Chaque pouvoir s'arrête là où commence le contrôle d'un autre.

La spécification minimale fixe « sauvegarder avant de détruire » et « restaurer après l'échec », sans figer tous les modèles de mémoire. Le choix local demeure possible, mais il devient vérifiable. Un MUST dans un texte ne démontre pas à lui seul que le chemin rare d'une implémentation fonctionne. L'injection de fautes et les empreintes avant/après fournissent ce reçu.

Une vérification ne devrait jamais obtenir le pouvoir de détruire un état légitime simplement parce qu'une entrée non fiable l'a conduite vers l'avenir. Conserver, essayer, puis seulement avancer : c'est la petite discipline qui rend la voie rapide défendable.

Sources