Zusammenfassung

  • RRDP-Sitzung und Serial bezeichnen eine Position in einer Synchronisationsfolge. Erst der zugehörige Hash bindet diese Position an Bytes; selbst diese Bindung sagt noch nichts über die Gültigkeit der enthaltenen RPKI-Objekte oder die spätere BGP-Policy aus.
  • Wird für ein überlappendes, bereits beobachtetes Serial ein anderer Hash angekündigt, darf der Relying Party die Delta-Folge nicht fortschreiben. Er sichert den Befund, lädt den jüngsten Snapshot und führt Manifest-, Zertifikats-, CRL- und Objektvalidierung erneut aus.

Nehmen wir zwei Validatoren mit scheinbar gleichem Zustand. Beide melden dieselbe Notification-URL, dieselbe Session-ID und das aktuelle Serial 1775. Das erste System hat Delta 1774 mit Hash A verarbeitet. Das zweite erhielt später für genau diese Position Hash B. Beide Downloads stimmen jeweils mit der zu diesem Zeitpunkt sichtbaren Notification überein. Trotzdem können ihre lokalen Repositories und Validated Payloads auseinanderlaufen.

Das Beispiel ist konstruiert, nicht als realer Vorfall behauptet. Es zeigt, warum die jüngste Nummer keine Historie ersetzt.

RFC 9697 verlangt den Vergleich überlappender Serial-Hash-Paare aus zwei erfolgreich verarbeiteten Notifications. Ändert sich ein Hash innerhalb derselben Sitzung, warnt der Client und verarbeitet den neuesten Snapshot. Damit wird nicht ein Server zum Schiedsrichter erklärt. Der Client prüft eine einfache, reproduzierbare Invariante.

Der Schlüssel besteht aus Ort, Sitzung, Serial und Hash

RFC 8182 beschreibt eine stabile Notification-URL, die Session-ID, aktuelles Serial, Snapshot und verfügbare Deltas nennt. Der Snapshot enthält den gegenwärtigen Repository-Bestand. Ein Delta enthält die Publish-, Replace- und Withdraw-Operationen eines Schritts.

Eine inkrementelle Fortsetzung ist nur zulässig, wenn die Sitzung passt, jedes fehlende Serial lückenlos vorhanden ist und die Deltas in genau dieser Reihenfolge verarbeitet werden. Die heruntergeladenen Bytes müssen den angekündigten Hash besitzen. Schlägt eine Bedingung fehl, bildet der aktuelle Snapshot die neue Ausgangsbasis.

Die Session-ID allein ist kein Repository-Prinzipal. RFC 8182 warnt davor, das zufällige UUID ohne Notification-Ort als global eindeutig zu behandeln. Erst der Ort grenzt die Sitzung ein; das Serial ordnet Übergänge; der Hash bindet einen Übergang an Inhalt.

RFC 6811 rechnet mit lockerer globaler Konsistenz, weil Relying Parties zu unterschiedlichen Zeiten abrufen. Zeitversatz bedeutet, dass zwei Systeme verschiedene legitime Punkte derselben Folge sehen. Eine Hashänderung am gleichen Punkt bedeutet dagegen, dass die Folge keine eindeutige Vergangenheit mehr hat.

Unveränderlichkeit macht den verteilten Abruf berechenbar

Snapshots und Deltas lassen sich über HTTP und CDNs effizient verteilen, weil veröffentlichte Artefakte unverändert bleiben sollen. Ein Cache kann dieselben Bytes lange vorhalten; viele Validatoren können denselben Übergang reproduzieren. Die Hashbindung macht einen Cache-Treffer überprüfbar.

Wird ein Delta unter seiner historischen URL ersetzt, können verschiedene CDN-Edges unterschiedliche Versionen speichern. Der Fehler muss in keinem einzelnen Transfer liegen. Die Divergenz entsteht, weil zwei Inhalte denselben Namen in derselben Geschichte beanspruchen.

RFC 9697 begrenzt die nötige Erinnerung. Der Client muss nicht jedes Delta für immer archivieren. Er hält die Serial-Hash-Paare, die zwischen der vorherigen und der neuen Notification überlappen. Diese kleine lokale Evidenz genügt, um stilles Umschreiben zu erkennen.

Eine brauchbare Meldung nennt Notification-Ort, Sitzung, Serial, alten und neuen Hash sowie Beobachtungszeiten. Eine Sammelmeldung wie „RRDP gestört“ vermischt lückenhafte Delta-Ketten, fehlgeschlagene Downloads, legitime neue Sitzungen und echte Geschichtsmutation.

Ein Snapshot setzt den Transport zurück, nicht die Gültigkeitsregeln

Der Snapshot löst die Abhängigkeit von der widersprüchlichen Delta-Folge. Er muss selbst dem angekündigten Hash entsprechen, parsebar sein und zu Sitzung und Serial passen. Wird auch er abgelehnt, ist der normale RRDP-Wiederherstellungsweg erschöpft.

Ein Flottenreset ist kein kostenloser Fallback. Viele vollständige Downloads können Ursprung, CDN und Validator gleichzeitig belasten. Unbegrenzte Wiederholung kann einen Verteilungsfehler verstärken. Kapazitätsreserve, Backoff, Jitter und stufenweise Ausführung gehören daher zur Sicherheitswirkung.

Vor dem Ersetzen des lokalen Zustands bleiben alte und neue Notification, überlappende Paare, HTTP-Herkunft, Redirects, Zeitpunkte und Ablehnungsgrund erhalten. Nur damit lassen sich Publisherfehler, CDN-Inkonsistenz, Implementierungsdefekt und gezielte Störung später unterscheiden.

RFC 9674 fordert für Snapshot-, Delta- und Redirect-URLs denselben Ursprung wie für die Notification: Schema, Host und Port müssen übereinstimmen. Das verhindert, dass ein Repository die Ressourcen eines fremden Servers über Clients belastet. Same-Origin beweist jedoch keine RPKI-Signatur und keine inhaltliche Berechtigung.

Jede Nummer gehört nur ihrer Zustandsmaschine

Die Schreibseite folgt einem eigenen Vertrag. RFC 8181 regelt, wie eine CA bei einem Publication Service Publish, Replace oder Withdraw anfordert. Die Geschäfts-PKI authentisiert diesen Austausch. Eine erfolgreiche Veröffentlichung bedeutet nicht, dass ein Relying Party das öffentliche Objekt akzeptieren wird.

RFC 6480 ordnet Repositories in die verteilte RPKI-Infrastruktur ein. RFC 6481 beschreibt Publication Points und die Notwendigkeit konsistenter Übergänge. Ein sauberer RRDP-Abruf kann eine auf der Schreibseite schlecht zusammengestellte Sicht nicht heilen.

RFC 6488 definiert die allgemeinen Prüfungen signierter RPKI-Objekte: CMS-Struktur, eingebettetes EE-Zertifikat, Content Type, Digest und Signatur, ergänzt um objektspezifische Regeln. Eine gültige Signatur beweist weder Aktualität noch Vollständigkeit.

Hier greift RFC 9286. Ein Manifest listet die Dateien eines CA-Publication-Points mit Hashes. Fehlt eine gelistete Datei, darf der Client nicht das zufällig verfügbare Teilset als vollständig behandeln. RFC 9981 präzisiert die Behandlung von Manifestnummern und Replay, einschließlich definierter Resetfälle.

Die Manifestnummer ist kein RRDP-Serial. Sie ordnet von einer CA ausgestellte Manifeste. Das RPKI-to-Router-Protokoll besitzt wiederum Cache-Sitzung und Serial für die Payload-Übertragung. Ein BGP-Router hat keine globale Versionsnummer für „die Routen“. Gleiche Ziffern über Domänengrenzen hinweg sind bedeutungslos.

RFC 8897 bündelt Pflichten des Relying Party. Abruf und Validierung können getrennte Komponenten sein, doch der Betreiber braucht eine durchgängige Provenienz: welche Bytes führten über welches Manifest und welche Prüfungen zu welchem Payload.

Der Router übernimmt Belege, keine Befehle

Nach Neuaufbau und Validierung können Prefix-Origin-Zuordnungen hinzukommen oder entfallen. RFC 6811 verlangt, betroffene Routen neu zu validieren, und stellt den Validierungszustand der lokalen Routing-Policy zur Verfügung. Die Policy entscheidet, ob Invalid verworfen, abgewertet, markiert oder ausnahmsweise zugelassen wird.

RRDP belegt Repository-Synchronisation. RPKI-Origin-Validation prüft Ursprungsgenehmigung. Sie validiert nicht den gesamten AS-Pfad und nicht den tatsächlichen Forwarding-Erfolg. Deshalb darf eine erkannte Delta-Mutation nicht direkt eine irreversible Routenlöschung auslösen.

Der Nachweis reicht bis zu Payload-Diff, RPKI-to-Router-Synchronisation, Policy-Zweig, Loc-RIB, FIB und Paketmessung. Ein repariertes Repository ist noch kein reparierter Dienst.

Quellen