Zusammenfassung

  • Nach RFC 9986 vergleicht ein BFD-Empfänger einen 32-Bit-Auth-Key aus einer geschlüsselten ISAAC-Folge. Ein Treffer kann gemeinsames Schlüsselwissen und eine zulässige Sequenzposition anzeigen, authentifiziert aber nicht die übrigen Paketfelder.
  • Belastbare Evidenz umfasst Build, Discriminators, Schlüsselepoche, Seed, Fenster, ISAAC-Seitenzustand, Vergleich und spätere MCI-Reauthentisierung. Daraus folgt weder Routing- noch Servicezustand.

Im Abnahmeprotokoll stand hinter dem empfangenen Wert „valid“. Eine spätere Management-Folie machte daraus „packet integrity validated“. Zwischen beiden Sätzen lag keine zusätzliche Messung. Lediglich das Wort integrity war hinzugekommen – und mit ihm eine Garantie, die der Algorithmus nie berechnet hatte.

Der Fall ist konstruiert und berichtet nicht über Hersteller, Betreiber oder Vorfall. Die Grenze stammt aus RFC 9986. Meticulous Keyed ISAAC ist der LCI-Mechanismus für die optimierte Authentisierung nach RFC 9985. Zugleich erklärt die Spezifikation, dass diese Pakete weder signiert noch als Paket authentifiziert sind und keine Zustandsänderung signalisieren dürfen.

Geprüft wird eine kleinere Aussage: Kann die Gegenseite aus Shared Secret, BFD-Sitzungswerten, Seed und zulässiger Sequenzposition denselben 32-Bit-Wert erzeugen? Ein Match ist ein Indiz für Wissen und Synchronität. Es bindet Diagnostic, State, Flags, Timer, Discriminators und weitere Felder nicht an einen kryptografischen Integritätsnachweis.

Die Bezeichnung Auth Key erweitert den Rechenbereich nicht. Wer prüft, muss die Ableitungseingaben und die ungeschützten Bytes benennen. Aus dem Namen der Authentication Section lässt sich keine Paketgarantie ableiten.

RFC 9986 definiert Typ, Länge, Key ID, Seed, Sequenzoffset und den 32-Bit-Auth-Key. Der Empfänger wählt den Schlüssel, prüft den Seed, sucht eine Position im Empfangsfenster und leitet einen Kandidaten ab. Gleichheit erfüllt den LCI-Test; sie validiert keinen MAC über den Paketkörper.

Ein begrifflicher Vergleich mit RFC 8439 hilft: Bei AEAD bindet ein Tag Chiffretext und zugehörige Daten. Damit wird kein Algorithmuswechsel für BFD empfohlen. Es zeigt lediglich, warum die Prüfung eines inhaltgebundenen Tags etwas anderes ist als der Vergleich eines einzelnen Pseudozufallswerts.

ISAAC macht Evidenz zustandsabhängig. Der Generator liefert Seiten und bewegt seinen internen Zustand destruktiv weiter. Um Verlust, Verzögerung oder begrenzte Umordnung zu tolerieren, kann der Empfänger vorausrechnen. RFC 9986 verlangt, den Zustand beim Erzeugen einer möglichen künftigen Seite zu sichern und anschließend wiederherzustellen. Sonst verändert die Prüfung den aktiven Generator, ein gültiges Folgepaket erscheint falsch und der frühere Entscheid lässt sich nicht reproduzieren.

Der Seed trennt Epochen. Bei jedem Übergang nach Up ist ein neuer Seed nötig; während dieser Up-Epoche bleibt er konstant. Ein Logeintrag „Key ID 9, match“ verschweigt, in welcher Epoche und an welcher Position die Aussage galt. Seed, Up-Epoche, Sequenz und Fensterregel gehören zusammen. Das Secret bleibt geschützt; Provisionierungs- und Rotationsepoche können ohne Offenlegung dokumentiert werden.

Auch erlaubte Schlüsselwiederverwendung ist kein Freipass. Sitzungsdaten differenzieren die Ausgaben, doch ein Schlüssel für viele Sessions vergrößert den Schaden bei Verlust, unvollständiger Rotation oder fehlenden Protokollen. Kontrolliert werden müssen Population, Ableitungseingaben, Eigentümer und Ablauf jeder Schlüsselepoche – nicht nur „ISAAC enabled“.

Die RFC-Editor-Seite führt den Text als Experimental. Niedrigere Rechenlast wird mit geringerer Sicherheit erkauft. ISAAC gilt für diesen Zweck höchstens als tolerierbar; die Kryptoanalyse ist begrenzt, ein Beweis fehlt, und für andere IETF-Protokolle wird es als ungeeignet bezeichnet. Die IACR-Arbeit begründet Vorsicht, nicht die Behauptung eines Angriffs auf eine RFC-9986-Installation.

Ebenso wenig entsteht allgemeine Interoperabilität. RFC 9986 gehört zur konkreten Architektur von RFC 9985 und ist nicht automatisch mit gewöhnlicher RFC-5880-Authentisierung kompatibel. Das Register IANA BFD Parameters weist Protokollwerte zu; es belegt keine Implementierung, Verbreitung oder Betriebserfahrung.

RFC 5881 begrenzt BFD auf einen Single-Hop-Forwarding-Pfad. RFC 7419, RFC 8177 und RFC 9127 liefern Kryptografie- und Protokollkontext. Keine dieser Quellen macht aus einem LCI-Match einen Beleg für Route, Anwendungstransaktion oder Kundenergebnis.

Die periodische MCI-Reauthentisierung nach RFC 9985 ist ein eigener Kontrollpunkt. Abhängig vom Intervall kann sie die Dauer eines unzulässigen Up-Zustands begrenzen. Sie authentifiziert nicht rückwirkend den Inhalt der ISAAC-Pakete dazwischen. Beide Ereignisarten werden verknüpft, aber nicht gleichgesetzt.

Heng Lus Realitätsebenen trennen Standard, Fähigkeit, Konfiguration, beobachteten Auth Key, BFD-Zustand, Clientreaktion und Servicewirkung. Running-Code Primacy stellt gemessenes Implementierungsverhalten über das RFC-Etikett. Minimum Initial Specification hält den gemeinsamen Nachweis schmal und belässt Folgeentscheidungen beim verantwortlichen Betreiber.

Der Nachweis nennt RFC- und Errata-Stand, Build, beide Discriminators, Key ID, Schlüssel- und Rotationsepoche, Seed und Up-Epoche, gesendete und akzeptierte Positionen, Fenster, ISAAC-Seite, Save/Restore, Match, ungeschützte Felder, MCI-Ergebnis, Clientreaktion, Entscheider und Rollback. Er erlaubt Replay der Logik, ohne das Secret preiszugeben.

Der Treffer ist nützlich, solange er nicht für eine größere Aussage verwendet wird.

Quellen