Zusammenfassung

  • Nach einem RRDP-Fehler kann ein Validator einen früheren Cache verwenden, einen erheblich größeren Snapshot laden oder auf rsync ausweichen; ein universeller Wiederanlauf-Timer existiert nicht.
  • Delta-Aufbewahrung, Manifest-Frische und Validator-Schwellen verteilen Last, Erholungszeit und Replay-Risiko auf unterschiedliche Akteure.
  • Betreiber brauchen einen Wiederanlaufbeleg je Repository und den Vergleich unabhängiger validierter Payloads, nicht nur eine grüne HTTP-Anzeige.

Um neun Uhr fordert ein Validator das nächste kleine Delta eines RPKI-Repositories an. Die Notification verweist darauf, doch die Datei ist nicht erreichbar. Ein Validator arbeitet mit dem letzten erfolgreichen Cache weiter. Ein zweiter lädt den vollständigen Snapshot. Ein dritter wartet eine zufällige Frist ab und versucht rsync. Alle drei Entscheidungen können technisch vertretbar sein. Eine identische Gegenwart zur identischen Minute garantieren sie nicht.

Deshalb wird der Wiederanlauf des Repositories zur Schaltstelle im Routing. RPKI wird meist vom signierten Objekt her erklärt: Der Ressourceninhaber autorisiert einen Ursprung, eine Relying Party validiert ihn, der Router wendet seine Origin-Validation-Policy an. Im Betrieb muss die signierte Absicht zunächst die Zertifizierungsstelle verlassen, veröffentlicht und über den Repository-Transport zugestellt werden, Manifest-, Zertifikats- und Widerrufsprüfungen bestehen und als validierte Payload enden. Eine intakte Signatur verhindert nicht, dass eine Störung der Zustellung die Evidenz für die nächste Stufe verändert.

Delta, Snapshot, Ersatzweg

RFC 8182 definiert drei RRDP-Bausteine. Die Notification nennt Session und Seriennummer, Deltas transportieren inkrementelle Änderungen, der Snapshot liefert eine vollständige aktuelle Sicht. Gibt es vom lokalen Stand bis zur Gegenwart eine lückenlose Delta-Kette, kann der Validator den leichten Weg nehmen. Fehlt ein Delta oder wird es abgelehnt, folgt der Snapshot.

Die Kosten sind ungleich. Ein Delta kann klein sein, ein Snapshot dagegen mehrere zehn bis mehrere hundert Megabyte umfassen. Der aktuelle SIDROPS-Entwurf zu Publication Services vom Mai 2026 beschreibt die Kaskade: Scheitern Deltas, versucht die Relying Party typischerweise den größeren Snapshot; scheitert auch der, weicht sie möglicherweise auf rsync aus; beim nächsten RRDP-Lauf beginnt sie häufig wieder mit dem Snapshot. Überlast kann damit einen Wiederanlauf auslösen, der die Last weiter erhöht. Ausgerechnet im Störungsfall wird das zu liefernde Paket schwerer.

Der Text ist ein laufender Working-Group-Entwurf, kein RFC. Seine Zahlen sind dennoch sauber begrenzt. Bei einem großen Repository entfiel im Januar 2024 auf eine Notification mit 144 Deltas über 14 Stunden ein Volumen von 251 GB bei insgesamt 55,5 TB — weniger als 0,5 Prozent. Mehr Deltas helfen einem zurückliegenden Validator, inkrementell aufzuschließen, verlängern aber die von allen gelesene Notification.

Weniger Deltas sparen im Normalbetrieb Bytes und schicken mehr Nachzügler zum Snapshot. Weil 2024 einige RP-Instanzen nur alle ein bis zwei Stunden synchronisierten, empfiehlt der Entwurf mindestens vier Stunden Delta-Aufbewahrung. Der Parameter beseitigt keine Kosten; er verschiebt sie.

Der Validator fügt eine weitere Policy hinzu. Die aktuelle Routinator-Dokumentation bietet für den rsync-Fallback nach RRDP-Fehlern never, stale und new. Dokumentierter Standard ist stale: Die lokale RRDP-Kopie gilt zunächst weiter als aktuell; danach wird rsync zu einem je Repository zufällig gewählten Zeitpunkt versucht. Die maximale Frist beträgt standardmäßig 3.600 Sekunden. Die Streuung verhindert, dass alle Validatoren zugleich den Nebeneingang stürmen.

Weitere Defaults verändern den Pfad: Snapshot bei mehr als 100 benötigten Deltas, eine als leer behandelte Liste oberhalb von 500, 600 Sekunden für eine RRDP-Ressource, 10 Sekunden Read-Timeout und 300 Sekunden für einen rsync-Befehl. Das sind Routinator-Werte, keine Naturkonstanten von RPKI. Wer sie ändert, macht aus demselben Repository-Fehler eine andere Folge von Anfragen und Cache-Entscheidungen.

Der Cache gehört zur Beweiskette

RFC 9286 empfiehlt nach einem fehlgeschlagenen Abruf die Daten des letzten erfolgreichen Abrufs weiterzuverwenden, bis wieder ein vollständiger Fetch gelingt. Das schützt davor, eine unvollständige Repository-Sicht als neue Routing-Absicht zu deuten. Es bedeutet zugleich, dass die momentane Erreichbarkeit eines HTTPS-Endpunkts nichts über das Alter der Evidenz aussagt, die schließlich beim Router ankommt.

Manifeste begrenzen diese Kontinuität. Sie listen die vorgesehenen Objekte und helfen, Löschung, Austausch oder Unterdrückung einer neuen Version zu erkennen. Sie zeigen eine Differenz, können sie aber nicht reparieren. thisUpdate, nextUpdate, CRLs und Objektgültigkeiten bilden daher ein endliches Zeitfenster für den alten Cache.

Der Entwurf von 2026 benennt den Zielkonflikt. Längere Gültigkeit gibt mehr Zeit zur Reparatur, erweitert aber das Replay-Fenster. Kürzere Gültigkeit begrenzt dieses Risiko und erhöht die Neuausstellung. Bei einem großen Repository halbierte sich der Datenverbrauch ungefähr, als Manifeste und CRLs statt alle 24 nur alle 48 Stunden neu ausgestellt wurden, weil der Großteil der Änderungen aus diesen Wiederholungen und nicht aus neuen ROAs oder ASPAs bestand. Das ist kein globaler Faktor. Es zeigt aber die Machtverteilung: Die CA bestimmt den Takt; Repository und sämtliche Relying Parties verarbeiten die Last.

Die Standards schließen weitere Randfälle. RFC 9981 vom Mai 2026 behandelt den Ausnahmefall einer ausgeschöpften Manifestnummer. Zuvor hätten manche Implementierungen ein neues Manifest erst nach Ablauf des alten akzeptiert, andere neue Manifeste dauerhaft verworfen. Normales Zählen erreicht die Grenze praktisch nicht; Bugs und Fehlkonfigurationen sind plausibler. Entscheidend ist nicht die Häufigkeit, sondern der Nachweis, dass eine unklare Wiederanlaufkante zu verschiedenen nutzbaren Ergebnissen führen kann.

Kapazität und Sicherheit laufen nicht parallel

Der Wechsel auf rsync kann die Erreichbarkeit verbessern und die Transportsicherheit schwächen. RRDP nutzt HTTPS und verteilt unveränderliche, cachefähige Deltas und Snapshots. Rsync verlangt mehr Serverarbeit pro Verbindung und bietet selbst keine Kanalvertraulichkeit oder -integrität. Das Routinator-Bedrohungsmodell beschreibt, wie ein Angreifer auf dem Pfad RRDP stören und einen Downgrade auf rsync auslösen kann. Signaturen und Manifeste müssen dann mehr der Abwehr tragen.

NLnet Labs veranschaulichte 2020 die Kapazitätsfrage mit einer Zukunftsrechnung: 150.000 Validatoren, die alle zehn Minuten abfragen, ergäben etwa 250 Anfragen pro Sekunde, verglichen mit ungefähr drei beim damaligen rsync-Ersatzdienst. Das sind keine Messwerte von 2026. Sie erklären, weshalb sofortiger gemeinsamer Fallback eine schlechte Idee war und weshalb die Frist heute gestreut wird.

Eine Sensitivitätsrechnung braucht keine erfundene Weltzahl. Nehmen wir 10.000 Validatoren, 1 MB für ein normales Delta und 100 MB für einen komprimierten Snapshot. Bleiben alle inkrementell, sind es pro Runde 10 GB. Wechseln nur 20 Prozent zum Snapshot, werden daraus ungefähr 208 GB: 8.000 MB Deltas plus 200.000 MB Snapshots. Wiederholungen und rsync-Serverarbeit kommen hinzu. Für den Peak zählt nicht nur die Anzahl, sondern wie eng die Wiederanläufe zeitlich zusammenliegen.

Ein Repository kann also „verfügbar“ sein und trotzdem ein inkonsistentes Wiederanlaufprodukt liefern. Ein Load Balancer kann die Notification eines Backends anzeigen, bevor referenzierte Deltas oder Snapshots auf den anderen liegen. Eine alte Keepalive-Verbindung kann einen Failover überleben und eine frühere Session liefern. Der SIDROPS-Entwurf verlangt konsistente Backend-Sichten und weist darauf hin, dass RFC 8182 keine universelle Reaktion auf einen Seriennummernrückgang vorgibt; einige Implementierungen synchronisieren per Snapshot neu. Der Monitor sieht HTTP 200. Der Validator sieht eine gebrochene Zeitachse.

Die Quellen liefern keine globale Divergenzquote und keinen Beleg, dass ein benanntes Repository einen Routing-Ausfall verursacht hat. Sie belegen Mechanismus, Stellschrauben und Kostenverschiebung. Das genügt für einen kontrollierten Test.