Zusammenfassung

  • Die am 14. September 2026 gesicherte RRDP-Benachrichtigung von AFRINIC verwies auf 32 lückenlose Deltas von Seriennummer 96961 bis 96992.
  • Zwischen den öffentlichen Last-Modified-Zeitpunkten des ersten und letzten Deltas lagen 425 Minuten; daraus folgt kein garantiertes siebenstündiges Wiederherstellungsfenster.
  • RFC 8182 erlaubt die Delta-Nachführung nur mit der vollständigen fehlenden Kette. Fehlt ein erforderlicher Schritt oder wird er verworfen, verarbeitet die Relying Party den aktuellen Snapshot.
  • Ein öffentlicher Kontinuitätsbeleg sollte Serien, Zeit, Datenvolumen, Sitzungswechsel und getesteten Snapshot-Fallback verbinden, ohne Nutzer oder Mitgliederaktivität offenzulegen.

Wenn der letzte lokale Stand nicht mehr reicht

Nach einem Wartungsfenster kennt ein RPKI-Validator seinen letzten verarbeiteten Stand. Er hat die Adresse der RRDP-Benachrichtigung, eine Sitzungskennung und eine Seriennummer gespeichert. Aus dem neuen Notification File muss er ableiten, ob der Weg von damals bis heute noch vollständig vor ihm liegt.

Sind alle fehlenden Nummern referenziert, lädt er die Deltas, prüft Format und Hash und verarbeitet sie in Serienreihenfolge. Liegt sein lokaler Stand vor dem Anfang der veröffentlichten Kette oder scheitert eine notwendige Datei an Abruf oder Prüfung, darf der Validator die Lücke nicht überspringen. Er nimmt den aktuellen Snapshot, der den vollständigen Repository-Stand einer Sitzung und Version enthält.

Beide Zweige gehören zum normalen Protokoll. Trotzdem sind sie für den Betrieb nicht gleich: Einige Differenzen beanspruchen andere Bandbreite und Rechenzeit als der komplette Bestand. Wer Validatoren redundant auslegt oder Wartungszeiten festlegt, muss diese Kosten kennen, statt nur die Existenz eines Fallbacks vorauszusetzen.

Die festgehaltene Kette

Die um 16:49 UTC am 14. September erfasste AFRINIC-RRDP-Benachrichtigung nannte die Sitzung 8fe3109e-2561-4627-8850-83ab94b9bb91 und die aktuelle Seriennummer 96992. Ihre 32 Delta-Verweise bildeten nach Sortierung die vollständige Folge 96961 bis 96992.

Für die veränderliche Benachrichtigung galt max-age=60, ergänzt um eine stale-if-error-Regel. RFC 8182 empfiehlt höchstens eine Minute Cache-Zeit für genau diese Datei. Der beobachtete Wert entspricht der Empfehlung und ist kein festgestellter Mangel.

Die HTTP-Metadaten lieferten zwei weitere Zeitmarken. Das Delta 96961 trug 07:40:05 UTC als letzte Änderung, das Delta 96992 14:45:06 UTC. Dazwischen liegen 425 Minuten. Der referenzierte Snapshot befand sich auf derselben Herkunft rrdp.afrinic.net und beantwortete die begrenzte Prüfung mit HTTP 200.

Das ist ein belastbarer momentaner Befund. Er macht aus 32 Versionen aber keine Zusage von sieben Stunden und fünf Minuten.

Eine Versionszahl hat keine feste Dauer

Seriennummern folgen Veröffentlichungsereignissen. Zertifikate, CRLs, Manifeste, ROAs und andere Objekte ändern sich weder stündlich noch in gleich großen Paketen. Eine legitime Aktualisierungswelle kann die Kette schnell voranschieben; in einer ruhigen Phase deckt dieselbe Zahl mehr Zeit ab.

Hinzu kommt die Größenregel des Standards. Ein Repository muss ältere Deltas aus der Benachrichtigung entfernen, sobald deren Gesamtgröße zusammen mit allen neueren Deltas die Größe des Snapshots übersteigen würde. Der gewählte Anfang markiert also die Stelle, an der die inkrementelle Übertragung noch sinnvoller ist als der Gesamtbestand. Er ist kein in Tagen formulierter Aufbewahrungsvertrag.

Gerade weil diese Regel effizient ist, reicht die sichtbare Zahl für Planung nicht aus. Es fehlen Snapshot-Größe, Gesamtvolumen der vorgehaltenen Deltas, zeitliche Bewegung der ersten Seriennummer und ein gemessener Wiederanlauf. Eine Kette kann protokollgerecht sein und dennoch unterschiedliche betriebliche Reserven darstellen.

Ein Nachweis, der die Ebenen nicht vermischt

AFRINICs RPKI Certification Practice Statement erklärt die RRDP-Unterstützung und nennt die Notification-URL. Die CPS beschreibt die Praxis, die Live-Datei den aktuellen Zustand. Ein schmaler Kontinuitätsbeleg könnte daraus eine betriebliche Zeitreihe machen.

Er würde Beobachtungszeit, Sitzung, aktuelle und erste vorgehaltene Seriennummer, Anzahl und beobachtete Zeitspanne enthalten. Dazu kämen komprimierte und entpackte Snapshot-Bytes, die Summe der Delta-Bytes, jüngste Sitzungswechsel sowie begrenzte Tests, bei denen sowohl Delta-Replay als auch Snapshot-Fallback die Hashprüfung abgeschlossen haben.

Die Spalten dürfen nicht zu einem Ampelsignal verschmelzen. Eine erfolgreiche HTTPS-Antwort beweist nicht die Gültigkeit jedes signierten Objekts. Gültige RPKI-Daten schreiben einem Netzbetreiber keine BGP-Entscheidung vor. CDN-Auslieferung, Repository-Publikation, Validatorverarbeitung und Routingpolitik brauchen getrennte, zeitlich verbundene Nachweise.

Kein Störungsbefund

Aus der Aufnahme folgt weder, dass 32 Deltas zu wenig sind, noch dass AFRINIC RFC 8182 oder die CPS verletzt. Kein realer Validator wurde außerhalb der Kette beobachtet. Es gibt keinen Beleg für einen fehlgeschlagenen Snapshot, einen Hashfehler, eine beschädigte ROA, veraltete Routingdaten oder einen Mitgliederschaden. Die geprüften Endpunkte antworteten während der Erhebung.

Der Vorschlag betrifft die Übersetzung für Menschen. Die Software weiß, welche Protokollroute sie nehmen muss. Der Verantwortliche für Kontinuität sieht bislang nicht, wie viel Zeit und Last dieser Wechsel bedeutet. Ein datierter Beleg schafft diese Lesbarkeit, ohne eine neue feste Garantie zu erfinden.

Primärquellen