Zusammenfassung

  • RFC 2154 versah jede OSPF-LSA mit einer dauerhaften Signatur und verteilte den zertifizierten Router-Schlüssel in einer Public Key LSA.
  • Das Zertifikat begrenzte Identität, Rolle und erlaubte Adressbereiche, beobachtete aber weder Existenz des Links noch Ehrlichkeit der Metrik oder Erreichbarkeit des Ziels.
  • Vertrauensanker, Schlüsselgeneration, Aktualität, Genehmigung, Gegenbeleg, SPF, FIB und gemessene Zustellung brauchen getrennte Nachweise.

Das Siegel blieb heil, der Anschluss war leer

Eine LSA verlässt ihren Router versiegelt. Mehrere Zwischenstationen reichen sie weiter, ohne ein geschütztes Byte zu ändern. Jede Prüfung ist erfolgreich. Am beworbenen Stub steht dennoch nur ein leeres Rack. Die Kryptografie hat funktioniert: Sie ordnet eine falsche Behauptung dem richtigen Urheber zu.

Diese Grenze prägt RFC 2154, veröffentlicht im Juni 1997 als Experimental. Gewöhnliche OSPFv2-Authentisierung schützte Pakete zwischen Nachbarn. Der Vorschlag signierte jede LSA im Link State Update einzeln, sodass der Nachweis des Advertising Routers mit der Routinginformation durch das Netz wanderte.

Eine erfolgreiche Prüfung belegte Herkunft und Unverändertheit der abgedeckten Bytes. Sie belegte nicht, dass der Ursprung die Topologie richtig wahrgenommen hatte.

Auch der Schlüssel brauchte eine Herkunft

Ein öffentlicher Schlüssel allein bindet keinen Router ID; jeder könnte ihn beanspruchen. Deshalb führte RFC 2154 die Router Public Key LSA, PKLSA, ein. Eine Trusted Entity signierte das Zertifikat mit Router ID, Rolle, erlaubten Netzbereichen, Erstellungszeit, Algorithmus und öffentlichem Schlüssel. Der Empfänger prüfte sowohl TE-Zertifizierung als auch Router-Signatur. Ein Fehler führte zum Verwerfen.

Der TE-Schlüssel wurde außerhalb von OSPF installiert. Die PKLSA musste aktuell sein. Traf eine LSA vor ihrem Schlüssel ein, durfte sie nur MAX_TRANSIT_DELAY warten. Ein neuer zertifizierter Schlüssel ersetzte den alten; der Router musste seine LSAs neu erzeugen, und alte Signaturen mussten auslaufen.

Adressbereiche im Zertifikat begrenzten mögliche Aussagen. Sie sahen keinen Port, prüften keine Metrikfreigabe und bewiesen keinen vorhandenen Host. Das Zertifikat war ein Herkunfts- und Umfangsnachweis, kein Topologiesensor.

MaxAge trennte Altern von Widerruf

LS Age ändert sich beim Flooding und blieb normalerweise außerhalb der Signatur. Nur wenn der Ursprung eine LSA mit MaxAge erzeugte, wurde das Alter mit signiert. So konnte der Ursprung synchron zurückziehen, während ein Relay keinen fremden Widerruf fälschen konnte. Eine verwaiste LSA alterte in jeder LSDB lokal aus, langsamer als der synchrone Flush von Standard-OSPF.

Signierte und unsignierte Areas konnten nebeneinander bestehen, aber nicht innerhalb einer Area gemischt werden. An der Grenze erzeugte der ABR eine neue Summary unter eigener Autorität. Die erste Signatur ging nicht automatisch auf diese Projektion über.

Der Standard beschrieb die signierte Unwahrheit

Abschnitt 9 räumt ein, dass ein interner Router eine falsche Metrik, einen ausgefallenen Link als aktiv oder ein nicht existentes Stub-Netz beziehungsweise eine Hostroute melden kann. Ein erfundener Transit-Link braucht häufig eine korrespondierende Aussage am anderen Ende; beim Stub fehlt dieses Gegenüber.

ABRs können falsche Summary LSAs über andere Areas erzeugen. Gegenseitige Prüfung wurde erwogen, wegen Rechen- und Nachrichtenaufwand aber nicht eingebaut. ASBRs können unrichtige externe Informationen originieren; innerhalb des AS gibt es laut Dokument keine gleichwertige Autorität, die jedes externe Netz freigibt.

Die Signatur verbessert die Zuordnung, sobald der Widerspruch sichtbar wird. Sie garantiert seine Entdeckung nicht. Datenweiterleitung liegt außerhalb des Scopes: Eine verifizierte LSA kann korrekt in SPF eingehen und trotzdem einen Next Hop erzeugen, der Pakete verwirft.

Neun Belege statt einer Ampel

Zu speichern sind TE-Schlüssel und Installateur, Router-Zertifikat, Rolle und Bereich, Schlüsselgeneration, LSA-Identität und Hash, Schlüsselwechsel und Alter, Change-Genehmigung, Gegenbeleg oder Telemetrie, LSDB-Generation und SPF, RIB/FIB sowie zuletzt Datenprobe und Anwendungsergebnis.

RFC Editor, Datatracker und Historie belegen den Experimental-Status; die Errata korrigieren nur einen Tippfehler. RFC 2328 liefert OSPFv2-Kontext. RFC 6039 berichtete später fehlende Betriebserfahrung, RFC 6863 trennte Routingdaten-Schutz von Paket-Replay. RFC 7474 behandelte die Frische nach Neustart. Ein abgelaufener individueller Entwurf kritisierte Insider-Schutz, ohne IETF-Stand zu erlangen.

Running-Code Primacy, Minimum Initial Specification und Reality Layers sind offengelegte redaktionelle Linsen, keine Anforderungen von RFC 2154.

Quellen