Summary

  • Eine RPKI Relying Party erzeugt aus verteilten Repositories, konfigurierten Trust Anchors, Synchronisation, Validierungsregeln und lokaler Kontrolle eine zeitgebundene lokale Sicht, kein universelles Urteil.
  • draft-su-sidrops-rpki-rp-requirements-00 schlägt stabile Cache-Exporte, verständliche Ablehnungsdiagnosen und historische Zustände für Vergleich, Replay und spätere Analyse vor.
  • Daniel Kade empfiehlt einen Validierungszustandsbeleg, der Ausführung, Eingaben und Lücken, Cache-Digest, lokale Änderungen, Router-Auslieferung und Aufbewahrung verbindet. Er ist redaktionelle Leitlinie, keine IETF-Vorgabe.

Das Ergebnis ist weiter vom Ursprung entfernt, als die Ampel zeigt

Zwischen einem signierten RPKI-Objekt und einer Routingentscheidung liegen mehrere eigenständige Schritte. Publikationsstellen stellen Zertifikate, CRLs, Manifeste und Objekte bereit. RP-Software wählt Trust Anchors, entdeckt Repositories, synchronisiert Daten, prüft Profile und Pfade und erzeugt einen lokalen validierten Cache. Ein Betreiber kann SLURM-Filter oder lokale Assertions anwenden. Ein gesondertes RPKI-to-Router-Protokoll liefert daraus Payloads an Router, deren Richtlinien erst über die Nutzung entscheiden.

Eine gültige Signatur beweist nicht die Erreichbarkeit aller Repositories. Ein aktuelles Manifest beschreibt den aktuellen Bestand einer Publikationsstelle, nicht die Vollständigkeit des globalen Abrufs. Die Übergabe eines Payloads beweist weder Installation noch Präferenz einer Route.

Auch die Cache-Seriennummer ist keine globale Versionsnummer. RFC 8210 bindet sie an Protokollversion und Session ID; zwischen Caches ist sie nicht vergleichbar und nach einem Reset muss sie nicht fortbestehen. Ein einzelner Zahlenwert kann deshalb keine historische Sicht identifizieren.

Die verantwortbare Aussage lautet nicht „RPKI war grün“, sondern: Diese RP-Ausführung hat unter dieser Konfiguration und zu diesem Zeitpunkt aus beobachteten Quellen, Fehlern und lokalen Transformationen genau diesen Zustand für einen bestimmten Verbraucherkreis erzeugt.

Der Entwurf erweitert RFC 8897 um Betriebsnachweise

Der individuelle Internet-Draft vom 12. Juni 2026 soll RFC 8897 als Sammelreferenz aktualisieren. Er verweist auf neuere Regeln für Trust-Anchor-Nachfolger, RRDP Same-Origin und Desynchronisationsbehebung, Manifeste, ROAs, ASPAs, RSCs, TAKs, Zertifikate, CRLs, Cache-Verteilung und lokale Kontrolle.

Sein Status bleibt begrenzt. Datatracker weist keine Working-Group-Annahme, keinen RFC-Stream, zuständigen AD oder Telechat aus. Der Dokumentkopf nennt Informational als beabsichtigten Status und ein Update von RFC 8897 nur im Fall der Genehmigung. Verweise auf aktive SIDROPS-Entwürfe sind provisorisch. Daraus folgt weder IETF-Konsens noch eine Implementierung.

Neu ist besonders Abschnitt 7. RP-Software soll validierte Zustände stabil und maschinenlesbar exportieren. Sie soll Status und Diagnose liefern, damit Repository-, Synchronisations-, Parsing- und Validierungsfehler sowie Objektablehnungen verständlich werden. Sie soll frühere Ausgaben oder gleichwertige Audit-Datensätze für Vergleich, Replay und spätere Analyse bewahren.

Der Export zeigt, was enthalten war. Die Diagnose erklärt, was fehlte. Die Historie zeigt, wann sich die Grenze verschob. Erst zusammen bilden sie einen belastbaren Betriebsnachweis.

Ein erfolgreicher Refresh kann eine frühere Lücke verdecken

RRDP hat eigene Sitzungen, Deltas, Snapshots und Wiederherstellungswege. RFC 9674 verlangt Same-Origin-Prüfungen; RFC 9697 beschreibt Erkennung und Behebung einer Desynchronisation. Ein RP kann auf einen Snapshot oder einen anderen Mechanismus zurückfallen. Der endgültige Payload verrät diesen Weg nicht.

Manifestfehler sind ebenso entscheidend: fehlend, ungültig, stale, gelistete Datei nicht abrufbar, Hash falsch oder am falschen Publikationspunkt. Der Entwurf verlangt in diesen Fällen eine fehlgeschlagene Abholung nach den referenzierten Regeln. Für den Widerrufsstatus wird die relevante CRL mit gültigem aktuellem Manifest verbunden.

Mehrere Uhren wirken zugleich. Objekte besitzen Gültigkeitszeiten; Repository-Abrufe haben Beobachtungszeiten; Cache und Router nutzen Refresh-, Retry- und Expire-Intervalle. Zwei ehrliche Validatoren können deshalb zeitweise unterschiedliche Sichten liefern. Der spätere Erfolg ist kein Ersatz für die verlorene frühere Evidenz.

Lokale Kontrolle braucht ein sichtbares Präfix

SLURM erlaubt lokale Filter und Assertions. Ein ISP kann damit eine bekannte Störung überbrücken oder eine begrenzte Ausnahme formulieren. Verändert wird jedoch die lokale Ausgabe, nicht das global publizierte Objekt.

Bleibt die Transformation unsichtbar, wird eine Betreiberentscheidung dem Herausgeber oder Ressourceninhaber zugerechnet. Mit Policy-ID, Genehmigung, Wirkungszeit und Digest lässt sich die Ausnahme prüfen, befristen und zurücknehmen.

Zwei grüne Caches müssen daher nicht gleich sein. Softwarestand, Anchors, Synchronisationspfad, Fehlerbehandlung und SLURM können abweichen. Selbst identische Enddaten sind ohne gespeicherten Evidenzweg nicht zwingend reproduzierbar.

Aufbau eines Validierungszustandsbelegs

Der vorgeschlagene Beleg steht nicht im Entwurf. Daniel Kade verbindet darin vorhandene Nachweise, ohne Geheimnisse in eine zentrale Plattform zu übertragen.

Die Ausführungsidentität umfasst Produkt, Version, Profil, Konfigurations-Digest, aktivierte Objekttypen, Trust-Anchor-Satz und Uhrzustand. Die Beschaffung umfasst versuchte Publikationsstellen, Protokoll, letzten Erfolg, aktuellen Versuch, Fallback und Fehlerklasse.

Die Validierung erfasst Manifest- und CRL-Zustand, akzeptierte und abgelehnte Objekte nach Typ, Ablehnungsgründe, Anchor-Übergang, normatives Profil und kanonischen Cache-Digest. Lokale Kontrolle erhält einen eigenen Abschnitt mit Richtlinien-ID, Genehmigung, Gültigkeit und Transformations-Digest.

Für die Auslieferung braucht es RPKI-to-Router-Version, Session ID, Serial, Exportzeit, Consumer-Umfang und Lücken. Die Aufbewahrung verbindet Vorgängerzustand, Frist, verantwortliches System und spätere Korrektur.

Private Schlüssel, Zugangsdaten und unnötige Topologie gehören nicht hinein. Details können geschützt bleiben; Digest, Zeit und Ergebnisklasse erlauben dennoch unabhängigen Abgleich. Dezentralität der Validierung ist mit portabler Evidenz vereinbar.

Die Begrenzung ist eine Stärke

Der Beleg beweist nicht die materielle Richtigkeit jedes publizierten Objekts, keine Routerentscheidung und keine menschliche Begründung einer Ausnahme. Er erhebt einen Entwurf nicht zum Standard und entscheidet nicht automatisch zwischen Implementierungen.

Er bewahrt eine engere Behauptung: Welche lokale RPKI-Sicht wurde in einem bestimmten Intervall erzeugt und an welche Routing-Systeme angeboten? Diese Aussage reicht, um spätere Analysen von Erinnerung und Screenshots zu lösen.

Eine RP ist eine dauernd laufende Kontrollkomponente. Sie synchronisiert, scheitert, erholt sich, wird aktualisiert und erhält neue Konfiguration. Sobald ihr Output Routing-Sicherheit beeinflusst, gehören diese Übergänge zum Governance-Nachweis. Die Ampel darf grün bleiben; die Prüfspur muss dahinter erhalten bleiben.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification
  3. Lu Heng — Why BTW Media Exists
  4. RPKI-RP-Anforderungsentwurf, Revision 00
  5. Datatracker-Status
  6. Datatracker-Historie
  7. SIDROPS Working Group
  8. RFC 8897 — Anforderungen an RPKI Relying Parties
  9. RFC 6480 — Infrastruktur für sicheres Routing
  10. RFC 9286 — RPKI-Manifeste
  11. RFC 9674 — Same-Origin Policy für RRDP
  12. RFC 9697 — RRDP-Desynchronisation
  13. RFC 9691 — RPKI Trust Anchor Keys
  14. RFC 8416 — SLURM
  15. RFC 8210 — RPKI-to-Router-Protokoll v1
  16. RFC 9582 — Route Origin Authorizations
  17. RFC 9829 — RPKI-CRL-Number-Erweiterungen