Zusammenfassung

  • RFC 7474 verbindet einen 32-Bit-Boot-Zähler mit einem 32-Bit-Paketzähler. Die Epoche bleibt nichtflüchtig erhalten; der untere Wert steigt mit jedem Paket, und der Empfänger verwirft für jeden OSPF-Pakettyp alles, was den zuletzt akzeptierten Wert nicht überschreitet.
  • Acee Lindem editierte den gemeinsamen Standard mit Manav Bhatia, Sam Hartman und Dacheng Zhang. Geht die persistente Historie bei Reparatur, Upgrade oder Geräteaustausch verloren, müssen auch die alten Schlüssel weichen; ein normaler Rollover braucht nachweislich überlappende Sende- und Annahmezeiten.

Das Paket wartete, bis der Nachbar vergaß

Ein Angreifer zeichnet ein gültig geschütztes OSPF Database Description-Paket auf. Ohne Schlüssel kann er es nicht verändern. Solange der Empfänger eine spätere Sequenz kennt, bleibt die Aufnahme wertlos. Dann fällt die Adjacency, der Prozess startet neu und der flüchtige Nachbarzustand beginnt von vorn. Nicht das Paket wurde legitimer; der Prüfer verlor den Beweis seines Alters.

RFC 7474, seit April 2015 Standards Track, schließt genau diese Lücke. Beim früheren OSPFv2-Verfahren gehörten kryptografische Sequenzen zum Adjacency-Zustand. Dessen Verlust konnte die Zähler neu initialisieren und Inter-Session-Replay ermöglichen, obwohl der Digest unverändert korrekt war.

Das Dokument nennt Manav Bhatia, Sam Hartman, Dacheng Zhang und den Editor Acee Lindem. Das öffentliche IETF-Profil belegt Lindems Beteiligung und seine breitere Routing-Arbeit, nicht Alleinerfindung, OSPF-Eigentum oder Produktkonformität. Belegt ist ein engerer Beitrag zu einem kollektiven Ergebnis: Die Sicherheitschronologie soll die Störung überleben, die sie zuvor löschte.

Ein starker Hash kennt kein Datum

RFC 5709 führte HMAC-SHA für OSPFv2 ein. Seine Autoren sind Manav Bhatia, Vishwas Manral, Michael Fanto, Russ White, Michael Barnes, Tony Li und Randall Atkinson; Lindem gehört nicht dazu. Stärkere Algorithmen erschweren Fälschung, machen ein früher korrekt erzeugtes Paket aber nicht automatisch alt.

RFC 6039 von Vishwas Manral, Manav Bhatia, Joel Jaeggli und Russ White beschreibt langlebige manuelle Schlüssel, schwierigen Wechsel, Replay und fehlenden Kontext in Routing-Protokollen. Er liefert die Bedrohungsklasse, ohne seine Urheberschaft auf Lindem zu übertragen.

„Authentication succeeded“ beantwortet nur, ob geschützte Bytes und Schlüssel zusammenpassen. Ob das Paket zur aktuellen Boot-Epoche gehört, von der für Neighbor-Identität verwendeten Quelle kam und im OSPFv2-Kontext authentifiziert wurde, braucht eigene Evidenz.

Eine Epoche überlebt die Dunkelheit

RFC 7474 erweitert die Sequenz auf 64 Bit. Die oberen 32 Bit enthalten den Boot Count, die unteren einen streng steigenden Paketzähler. Der erste bezeichnet die Epoche, der zweite die Position darin.

Der Boot Count muss für die Einsatzlebensdauer des OSPFv2-Routers in nichtflüchtigem Speicher liegen. Bei jedem Verlust des vorherigen Sequenzzustands, auch beim Cold Restart, wird er erhöht. snmpEngineBoots darf verwendet werden; ein eigener OSPF-Zähler wird empfohlen, damit SNMP- und OSPF-Neustarts nicht dieselbe Sicherheitsuhr erzwingen.

Der untere Wert steigt mit jedem gesendeten OSPF-Paket. Der Empfänger verlangt mehr als den zuletzt akzeptierten Wert desselben Pakettyps vom Neighbor. Sonst wird als Replay verworfen. Die Typtrennung erlaubt legitime Umordnung durch Priorisierung, etwa zwischen Hello und Link State Update.

Beim Wrap kann der Boot Count erneut steigen, damit das Ganze monoton bleibt. Der Reboot wird nicht versteckt, sondern als authentifizierter Epochenwechsel dargestellt, den eine ältere Aufnahme nicht überholen kann.

Die acht Sequence-Octets folgen dem OSPF-Paket und gehen in den Digest ein. Authentication Type 3 kennzeichnet die Form; der Key ID wächst auf 32 Bit. Eine nicht authentifizierte Epoche ließe sich austauschen und würde ihren Zweck verlieren.

Die IP-Quelle wird Teil des Beweises

Die alte Berechnung schützte den IPv4-Header nicht. Auf Broadcast- und NBMA-Netzen nutzt OSPF jedoch die Source Address zur Bestimmung des sendenden Neighbors. Eine Aufnahme mit geänderter Quelle konnte dadurch den Sequenzzustand eines anderen Neighbors beeinflussen, ohne den alten Digest zu brechen.

RFC 7474 setzt die ersten vier Octets des von RFC 5709 verwendeten Authentifizierungs-Paddings auf die IPv4-Quelle. Sender und Empfänger rechnen mit der tatsächlich verwendeten Adresse. Eine Änderung erzeugt Authentication Failure. Damit werden reflektierte Pakete begrenzt, die One-Way-Kommunikation vortäuschen oder den Database-Description-Austausch stören könnten.

Nicht jeder IPv4-Wert wird eingefroren. Geschützt wird derjenige, mit dem OSPF Neighbor-Identität zuweist. Das ist eine minimale gemeinsame Spezifikation mit konkreter Wirkung.

Ein Secret braucht einen Protokollraum

Long-lived Key Databases können denselben geheimen Wert mehreren Protokollen geben. RFC 7474 hängt vor der Verwendung eine zwei Octets lange OSPFv2 Cryptographic Protocol ID an. Der gespeicherte Wert mag lokal gleich sein; der wirksame Kontext sagt nun OSPFv2.

Das empfiehlt keinen Shared Key. Ein kompromittiertes Secret bleibt ein gemeinsames Risiko, getrennte Schlüssel begrenzen es besser. Die Domain Separation ergänzt eine Grenze, wenn gemeinsame Infrastruktur bereits besteht.

Rollover ist eine Überlappung

Ein Sendeschlüssel gilt innerhalb seiner SendLifetime, ein Empfangsschlüssel innerhalb seiner AcceptLifetime. Die neue Version kann zuerst angenommen und später zum Senden bevorzugt werden; die alte darf nach dem Wechsel begrenzt akzeptiert bleiben. So entsteht kein erzwungener gleichzeitiger Schaltpunkt.

Algorithmus, Peer oder Area, Interface und Direction begrenzen die Auswahl. Ein expliziter Match schlägt all. Bleiben mehrere Sendeschlüssel, gewinnt der mit dem jüngsten Sendestart. Der 32-Bit-Key-ID führt den Empfänger zum symmetrischen Schlüssel, ersetzt aber nicht Scope- und Zeitprüfung.

Der Ablauf lautet: neuen Schlüssel verteilen, Annahme öffnen, Senden umstellen, beide Seiten beobachten, alte Annahme schließen. Zwei installierte Schlüssel beweisen weder Überlappung noch Clock-Gleichlauf noch die tatsächliche Auswahl.

Kompatibilität zeigt sich als klares Nein

Authentication Type 3 fällt nicht still auf einen alten Typ zurück. Passt der empfangene Typ nicht zur Interface-Konfiguration, wird das Paket verworfen. Während einer Teilmigration kann die Adjacency ausbleiben. Das ist sicherer als ein grüner Zustand, in dem beide Enden Freshness verschieden auslegen.

Die Änderungseinheit umfasst beide Seiten: Code, Typ, Algorithmus, Key ID, Secret, Lifetime und Epoche. Erfolg ist symmetrische Annahme neuer Pakete, Ablehnung der alten Capture, stabile Adjacency und beobachtetes Forwarding—not ein gespeichertes Config-Objekt.

Ohne Historie ist auch der alte Schlüssel abgelaufen

Die härteste Regel betrifft Reparatur, Upgrade und Austausch. Geht der nichtflüchtige Boot Count verloren, müssen die Schlüssel geändert werden. Router ID, Areas, Interfaces und ein altes Secret-Backup stellen die administrative Form wieder her, nicht die Epoche, die heute von gestern trennte.

Alter Schlüssel plus zurückgesetzte Epoche lässt frühere Captures wieder im niedrigen Sequence-Raum antreten. Geräteaustausch ist deshalb ein kryptografisches Lifecycle-Ereignis.

Grenzen bleiben. Die vollständige identische Wiederholung eines Session Establishment für einen ausgemusterten Router ist sehr unwahrscheinlich, aber genannt; Rekeying stoppt sie. Zwei aktiv abhörbare unnumbered Links mit gleicher Source und Sequence sollten getrennte Schlüssel verwenden. Automatisches Key Management liegt außerhalb des Dokuments.

Kleine gemeinsame Regel, große lokale Verwahrung

Lu Hengs späterer Text Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption dient Sofia Ren als Analyse. Sequence-Form, authentifizierte Quelle, Protocol ID, Key ID und Reject-Regel können gemeinsam sein. Erzeugung, Speicherung, Scope, Zeitplan, Rollout und Recovery bleiben lokal.

Running-Code Primacy verlangt die Verbindung von persistentem Count, gesendeter Sequence, ausgewähltem Key, Source-bound Digest, Receiver-Entscheidung, Replay Drops, Adjacency und Forwarding. Diese Übertragung ist Sofia Rens spätere Analyse, nicht Lindems private Absicht oder eine IETF-Absicht außerhalb der RFCs.

Der Angreifer kann die Vergangenheit länger speichern als der Router. RFC 7474 verlangt deshalb eine beweisbare Erinnerung. Kann der Router seine frühere Epoche nicht mehr nachweisen, darf der alte Schlüssel seine neue Lebensphase nicht authentifizieren.

Quellen