Zusammenfassung

  • RFC 9986 liefert ISAAC-Authentisierungswerte in Seiten zu je 256. Die Erzeugung der nächsten Seite ist irreversibel und zerstört die aktuelle.
  • Muss ein Empfänger für eine Paketprüfung diese Grenze überschreiten, speichert er vorher den vollständigen ISAAC-Zustand. Bei Übereinstimmung gilt der neue Zustand, bei Abweichung kehrt er zur Kopie zurück.
  • Das Verfahren bestätigt das Lebenszeichen eines authentischen Senders in einer bereits Up stehenden Sitzung. Es schützt weder den gesamten Paketinhalt noch einen Ende-zu-Ende-Dienst. Der Betriebsnachweis muss Commit und Restore zeigen, ohne Geheimnisse offenzulegen.

Wenn die Prüfung ihren eigenen Ausgangspunkt verbraucht

BFD sendet Kontrollpakete in kurzen Abständen, um den Ausfall einer Nachbarschaft rasch festzustellen. Auf Geräten ohne geeignete Kryptobeschleunigung kann eine teure Vollprüfung jedes Pakets dieses Ziel zunichtemachen. RFC 9985 trennt deshalb starke Authentisierung für wesentliche Änderungen von einer billigeren Methode, die eine bereits Up stehende Sitzung hält.

RFC 9986 definiert dafür Meticulous Keyed ISAAC. Ein gemeinsames Geheimnis, ein Seed je Sitzung und Material aus BFD-Discriminators initialisieren einen Pseudozufallsstrom. ISAAC stellt 32-Bit-Ausgaben in Seiten mit 256 Einträgen bereit. Innerhalb einer Seite ist das Nachschlagen der zum Sequenzwert gehörenden Ausgabe fast kostenlos. Am Ende erzeugt eine Mischfunktion die nächste Seite.

Diese Erzeugung ist keine harmlose Vorschau. Sie vernichtet die aktuelle Seite und lässt sich nicht umkehren. Ein Paket, das auf eine Position jenseits der Grenze zeigt, ist zu diesem Zeitpunkt noch ungeprüft. Schiebt der Empfänger seinen einzigen Zustand vor, um es zu testen, und stellt erst danach einen falschen Auth Key fest, reicht Verwerfen nicht mehr. Die Prüfung hat die legitime Vergangenheit verbraucht.

RFC 9986 ordnet die Schritte deshalb ausdrücklich: Würde die Berechnung eine neue Seite erzeugen, muss der Empfänger zuvor den gesamten ISAAC-Zustand kopieren. Passt die Ausgabe, wird die Kopie verworfen und der neue Zustand übernommen. Passt sie nicht, wird die Kopie wiederhergestellt; der veränderte Kandidat wird verworfen oder getrennt für einen möglichen späteren Gebrauch gehalten.

Erst die Übereinstimmung darf aus dem Versuch einen unumkehrbaren Fortschritt machen.

Paketverlust gestattet nur begrenztes Vorwärtssuchen

Ein Sprung im Sequenzwert ist nicht automatisch bösartig. Zwischen zwei empfangenen Kontrollpaketen können mehrere verloren gehen. Die Differenz zeigt dem Empfänger, welchen ISAAC-Eintrag er prüfen muss; ein Treffer synchronisiert die Gegenstellen nach dem Verlust neu.

Die Erlaubnis ist eingegrenzt. Ist der letzte Empfangswert bekannt, muss der neue Wert zwischen plus eins und plus dreimal Detect Mult liegen, gerechnet im zirkulären 32-Bit-Raum. Außerhalb wird verworfen. Innerhalb darf der Empfänger nach vorn suchen — auch auf der nächsten Seite, wo die Kopierpflicht greift.

Ein bloßer Erfolgs-/Fehlerzähler kann diesen Ablauf nicht erklären. Der Nachweis braucht alten und neuen Sequenzwert, Detect Mult, das abgeleitete Fenster, Seitenbasis und -index sowie die Information, ob gemischt wurde. Ein Erfolg zeigt Kopie vor Mischung, Treffer und Übernahme. Ein Misserfolg zeigt Kopie vor Mischung, Abweichung und Rückkehr zu exakt demselben undurchsichtigen Zustandsfingerabdruck.

Geheimschlüssel und roher Generatorzustand gehören nicht ins öffentliche Protokoll. Nicht rekonstruierbare Kennungen, Zeitwerte und Ergebnisse genügen. Ein Nachweis, der die nächste gültige Ausgabe berechenbar macht, wäre selbst eine Schwachstelle.

Authentischer Sender, nicht authentischer Gesamtinhalt

Das ISAAC-Format führt Key ID, Sequenznummer, Seed und eine 32-Bit-Ausgabe. Falscher Typ, Modus, Länge, Schlüsselbezeichner, Bereich, Seed oder Auth Key führen zum Verwerfen.

Die ISAAC-Ausgabe enthält jedoch keinen Hash und keine Zusammenfassung des BFD Control Packet. RFC 9986 hält fest, dass der Paketinhalt als Ganzes nicht authentisiert ist. Ein korrekter Wert beweist, dass nur die authentische Gegenstelle dieses Kontinuitätssignal erzeugen konnte. Er prüft nicht sämtliche Felder.

Daher ist der günstige Modus nur in einer bereits Up stehenden Sitzung zulässig und darf keine Zustandsänderung signalisieren. Übergänge und regelmäßige stärkere Bestätigungen nutzen den rechenintensiveren Modus mit vollständiger Integrität. Diese Rollenverteilung aus RFC 9985 ist bereits Gegenstand eines veröffentlichten Artikels. Der eigenständige Mechanismus hier ist die interne Rückkehrmöglichkeit des RFC-9986-Prüfers an einer einseitigen Zustandsgrenze.

Auch Up bleibt eine begrenzte Aussage. Es belegt weder Anwendungsfunktion, korrekte Route, Kundenerreichbarkeit noch den Transport einer bestimmten Nutzlast über den gesamten Pfad. BFD beantwortet seine Sitzungsfrage, nicht jede betriebliche Frage.

Ein Experimental RFC mit offengelegtem Preis

Ashesh Mishra ist Mitautor von RFC 9986 zusammen mit Alan DeKok, Mahesh Jethanandani, Sonal Agarwal und Jeffrey Haas. Er steht außerdem im Vorgängerentwurf von 2017, in RFC 9985 und in einem früheren Patent zu optimierten BFD-Integritätsprüfungen. Das belegt eine längerfristige Verbindung zum Problem, keine Einzelerfindung.

RFC 9986 ist Experimental und kein Internet Standard. ISAAC wurde für Systeme ohne geeignete Kryptohardware gewählt. Die Analyse ist begrenzt; mit Beschleunigung besitzt es keinen Vorteil, und der Text schließt eine Verwendung in anderen IETF-Protokollen ausdrücklich aus.

Die Verteilung der Geheimnisse bleibt außerhalb der Spezifikation. Ein Auth Key ID lässt sich während der Sitzung nicht mit definiertem Resync wechseln; eine Rotation erfordert Abschalten und neues Seeding. Getrennte Schlüssel für starken und günstigen Modus begrenzen eine Kompromittierung, erhöhen aber das Risiko unterschiedlicher Konfigurationen, die eine Sitzung beim Moduswechsel sofort beenden.

Das gemeinsame Protokoll nimmt diese Entscheidungen dem Betreiber nicht ab. Es benennt die Interoperabilitätsgrenze und lässt den kontrollierenden Akteuren ihre Verantwortung.

Den Zustand nach dem Nein testen

Der aussagekräftige Test platziert ein ungültiges Paket knapp hinter der Seitengrenze, aber noch im erlaubten Verlustfenster. Das Labor bildet einen privaten Fingerabdruck, injiziert einen falschen Auth Key und prüft die Reihenfolge: Checkpoint vollständig, Mischung, Vergleich fehlgeschlagen, alter Zustand exakt wiederhergestellt. Danach muss das eigentlich erwartete legitime Paket weiterhin angenommen werden.

Die Prüfung wird mit falschem Seed, Key ID, Modus und Länge, mit Sprüngen innerhalb und außerhalb des Fensters sowie am 32-Bit-Überlauf wiederholt. Speicher und Laufzeit für Kopie, Mischung, Restore und normalen Zugriff werden gemessen. Eine Serie ungültiger Zukunftspakete darf CPU, Speicher oder Kandidatenzustände nicht grenzenlos wachsen lassen.

Der öffentliche Beleg hält Build, Sitzung, Ticket, nicht geheime Key ID, Fenster, Basis, Index, opaken Fingerabdruck, Zeiten und Commit-/Restore-Ergebnis fest. Er ergänzt die letzte starke Prüfung und die geprobte Rotation mit Neustart. Verhalten wird sichtbar, Authentisierungsmaterial bleibt verborgen.

Jede Autorität endet an ihrer Kontrollfläche

Nach Lu Hengs Agency-Prüfung definieren die Autoren das interoperable Invariant. Der Implementierer entscheidet über Darstellung und Schutz der Kopie. Der Betreiber wählt Schlüssel, Rhythmus der starken Prüfung und Neustart. Der laufende Code des Peers entscheidet über einen konkreten Treffer. Keiner verspricht die Entscheidung des anderen.

Die minimale Anfangsspezifikation schreibt „vor Zerstörung speichern“ und „nach Fehlschlag restaurieren“ vor, ohne jedes Speicherlayout zu vereinheitlichen. Lokale Zukunftsentscheidungen bleiben möglich, aber eine testbare Untergrenze gilt für alle.

Running Code liefert den letzten Beleg. Ein MUST beschreibt den richtigen Zweig; es beweist nicht, dass ein selten genutzter Fehlerpfad eines Produkts tatsächlich zurückkehrt. Fault Injection, Vorher-/Nachher-Fingerabdruck und das nächste gültige Paket schließen die Lücke.

Ein noch nicht vertrauenswürdiger Input darf den legitimen Zustand nicht unwiderruflich verbrauchen, nur weil seine Prüfung in die Zukunft blickt. Sichern, versuchen, dann erst fortschreiten: Darauf beruht die Glaubwürdigkeit des schnellen Pfads.

Quellen