Zusammenfassung

  • Am 28. August 2026 eröffnete die IETF bis zum 11. September den Last Call für eine Best Current Practice zum Betrieb von RPKI-Publikationsmaschinen sowie RRDP- und rsync-Repositories. Der Text ist noch keine verabschiedete BCP.
  • Eine neue RRDP-Notification darf nicht vor den referenzierten Snapshot- und Delta-Dateien sichtbar werden. Bei mehreren Backends muss ein Client einer konsistenten Ansicht folgen oder jedes Backend die Daten erhalten, bevor irgendeines die Meldung freigibt.
  • Ein neuer Session- oder Serial-Wert belegt die Antwort eines Endpunkts. Er belegt weder die Abrufbarkeit aller Bytes noch RPKI-Validität, RP-Ausgabe, Routerübernahme oder Paketwirkung.

Ein RP liest die neue Notification. Das Load-Balancing schickt die nächste Anfrage an einen anderen Rechner. Dort ist die Notification repliziert, das genannte Delta aber noch nicht. Der Server liefert 404. Eine alte Keepalive-Verbindung führt später zu einem aus dem Pool genommenen Rechner, der eine frühere Serial zeigt.

Die Signaturen können dabei völlig intakt sein. Der Widerspruch entsteht, weil der Dienst eine Referenz veröffentlicht hat, bevor ihr Gegenstand öffentlich verfügbar war.

Der Last Call vom 28. August macht daraus eine aktuelle Koordinationsfrage. Der Entwurf zu Publikationsdiensten steht bis 11. September zur Diskussion. Er ist weder endgültiger Konsens noch ein Nachweis für einen Vorfall bei einem benannten Betreiber.

Die Notification ist ein Commit gegenüber dem Leser

RFC 8182 trennt Notification, Snapshot und Deltas. Die Notification nennt Session und Serial und weist auf die Synchronisationsdaten. Wer sie ausliefert, behauptet deshalb mehr als die Existenz einer kleinen XML-Datei: Die referenzierte Ansicht soll benutzbar sein.

Auf einem Einzelserver kann der Schreibprozess die Inhalte abschließen und zuletzt den Verweis wechseln. In einer Farm bleiben zwei Wege. Session-Affinität hält aufeinanderfolgende Anfragen auf demselben lokalen Zeitstrahl. Globale Sichtbarkeitsordnung verteilt zuerst Snapshot und Deltas auf alle Knoten und schaltet danach die Notification frei. In beiden Fällen darf der Client keine neue Referenz mit altem Speicher kombinieren.

Zur öffentlichen Fläche gehören CDN und Cache. Ein vor der Dateierzeugung gespeicherter 404 kann ein vorhandenes Delta weiterhin verbergen. Eine zu lange gecachte Notification hält Clients zurück. Keepalive zu einem abgeschalteten Backend kann eine alte Session liefern. Die Ursprungsmaschine allein ist daher nicht der Messpunkt; externe Canaries müssen die angebotenen Pfade benutzen.

Selbst eine Serial-Regression hat keine einheitliche Bedeutung. RFC 8182 bestimmt nicht, wie ein RP reagieren muss. Manche Implementierungen holen erneut einen Snapshot. Das kann Kohärenz wiederherstellen, erklärt aber nicht automatisch, welche Ansicht die Absicht der CA wiedergab.

Ein fehlendes Delta vergrößert die Wiederherstellung

Nach einem Delta-Fehler kann der RP den größeren Snapshot laden. Scheitert auch dieser, folgt rsync. Beim nächsten RRDP-Lauf beginnt er möglicherweise wieder mit einem Snapshot. Eine zu früh sichtbare Notification kann somit viele kleine Aktualisierungen in wiederholte Vollübertragungen verwandeln.

Der Entwurf empfiehlt, Kapazität, Speicher, I/O und unerwartete Snapshot-Fallbacks mit einem externen Canary-RP zu beobachten. Die Bandbreite allein sagt wenig. Erst die Verbindung zu Session, Serial, Backend, URI, Cache-Alter und HTTP-Ergebnis trennt normale Last von selbst erzeugter Wiederholung.

Nicht mehr referenzierte Snapshots und Deltas sollen noch zwei Stunden abrufbar bleiben. Das schützt langsame Clients und laufende Anfragen. Es heilt nicht die umgekehrte Reihenfolge einer neuen Notification. Auch das Bündeln von Änderungen in höchstens einem Delta pro Minute spart Arbeit, ohne die Pflicht „Daten vor Index“ aufzuheben.

Der Weg zur Route hat mehrere Belege

Eine CA erzeugt signiertes Material und übermittelt es nach RFC 8181 an die Publikationsmaschine. Eine list-Abfrage vor der Änderung deckt Abweichungen auf. Mehrere PDUs in einer Multi-Element-Abfrage verringern das Risiko, eine zusammengehörige Änderung nur teilweise anzuwenden.

Danach gilt für jeden Beleg eine andere Autorität. Das CA-Inventar beschreibt Absicht. Die RFC-8181-Antwort beschreibt Annahme durch die Maschine. Die Notification beschreibt die Aussage eines Endpunkts. Der Download beschreibt gelieferte Bytes. Ein RP bewertet Zertifikate, Manifest, CRL und signierte Objekte. Router-Feed, lokale Policy, FIB und beobachtetes Paket folgen als weitere Ebenen.

Abrufbare Bytes können am aktuellen Manifest oder an Hash und Zertifikatskette scheitern. Eine gültige ROA beschreibt eine begrenzte Herkunftsautorisierung, keine aktuell sichtbare BGP-Route. Heng Lus Trennung der Realitätsebenen verhindert, dass ein erfolgreicher Download spätere Entscheidungen vereinnahmt.

Für rsync zeigt der Entwurf dieselbe Regel mit einer anderen Technik. Werden Dateien während einer Sitzung einzeln ersetzt, liest der Client eine Phantom-Mischung. Ein vollständiges neues Verzeichnis, korrigierte Zeitstempel und ein abschließender Symlink-Wechsel schaffen eine einheitliche Ansicht. Der öffentliche Zustand wechselt erst nach seiner Fertigstellung.

Fortschreitende Nummern sind keine Frischegarantie

Die Serial ordnet Änderungen innerhalb einer Session. Sie ist keine Uhr. Verspäteter Inhalt kann mit steigenden Nummern erscheinen; ein neues Objekt kann an der Validierung scheitern.

Nach einer Wiederherstellung aus einem älteren Backup verlangt der Entwurf bei Inhaltsrückgang einen RRDP-Session-Reset. Abhängige CAs sollen informiert und zur vollständigen Synchronisation veranlasst werden. Der Reset macht den Bruch sichtbar; er stellt verlorene ROAs, Publisher oder bald veraltete Manifeste nicht von selbst wieder her.

Die Priorität laufender Systeme verlangt echte Abrufe statt Vertrauen in den Rollout-Status. Praktische Kontrolle besitzt, wer die Notification sperren, Caches löschen, alte Verbindungen entleeren, die Session zurücksetzen und die vorherige Ansicht erhalten kann.

Notification-last beweist keine korrekte Route. Es macht den ersten öffentlichen Beleg belastbar: Was der Index verspricht, kann der Dienst bereits ausliefern.

Sources