Zusammenfassung

  • Der IESG eröffnete am 28. August den Last Call für draft-ietf-sidrops-publication-server-bcp-10; der Datatracker nennt den 11. September als Ende der Prüfung und Best Current Practice als vorgesehenen Status.
  • Der Entwurf verwendet MUST, SHOULD und RECOMMENDED nach BCP 14, sagt aber unmittelbar dazu, dass sie betriebliche Wichtigkeit betonen und keine formalen Implementierungsanforderungen sind.
  • Ein späterer BCP wäre eine überprüfte IETF-Praxis, jedoch weder Zertifikat noch Nachweis dafür, dass ein bestimmter Betreiber eine Maßnahme umgesetzt oder in einem Vorfall eingehalten hat.
  • Betreiber sollten deshalb einen versionierten Umsetzungsbeleg führen: Dokumentabschnitt, Architektur, Status, Ausnahme, Messdefinition und -fenster, Wiederherstellung, RRDP-Session-Reset, Benachrichtigung und Resynchronisierung.
  • Die vorliegenden Quellen erlauben kein Konformitätsurteil über einen RIR, NIR, eine CA, einen Publikationsdienst oder ein CDN.

Das Dokument regelt Übergänge, nicht nur Server

Eine Zertifizierungsstelle erzeugt signiertes RPKI-Material. Eine Publikations-Engine nimmt Änderungen über das in RFC 8181 beschriebene Verfahren entgegen. Öffentliche RRDP- und rsync-Repositorien verteilen den daraus entstandenen Zustand. Relying Parties rufen ihn ab und validieren ihn; Netzbetreiber entscheiden anschließend über die lokale Verwendung. An jedem Übergang kann der beobachtbare Zustand vom vorherigen abweichen, ohne dass die Signatur des Objekts falsch sein muss.

Ein korrekt signierter ROA kann noch nicht öffentlich sichtbar sein. Eine Engine kann eine Änderung angenommen haben, während ein Leseknoten noch den alten Bestand ausliefert. Eine Sicherung kann einen konsistenten, aber älteren Zustand wiederherstellen. Eine RRDP-Benachrichtigung kann sichtbar werden, bevor Snapshot oder Deltas, auf die sie verweist, überall verfügbar sind. „Signiert“ und „aktuell publiziert“ sind deshalb verschiedene Aussagen.

Version 10 von Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services sammelt Betriebswissen zu genau diesen Übergängen. Der Entwurf behandelt Funktionstrennung, Verfügbarkeit, Datenverlust und Wiederherstellung, Abgleich zwischen Publisher und Repository, DNS- und Routing-Abhängigkeiten, IPv4 und IPv6, CDN-Caching, Lastverteilung und konsistente Sichten. Er führt kein neues Objektformat ein; er ordnet mehr als ein Jahrzehnt Betriebserfahrung.

Das macht den Entwurf für Governance relevant. Je mehr Institutionen an einer Kette beteiligt sind, desto weniger kann ein einziges grünes Feld erklären, welche Instanz welchen Zustand tatsächlich kontrolliert hat.

Die Fußnote zu MUST ist kein Kleingedrucktes

RFC 2119 gibt den bekannten Schlüsselwörtern ihre normative Stärke. RFC 8174 stellt klar, dass die besondere BCP-14-Bedeutung für die großgeschriebenen Formen gilt. Abschnitt 2.1 des Publikationsentwurfs verweist auf diese Regeln und fügt dann eine außergewöhnlich wichtige Einordnung hinzu: Die Wörter sollen die betriebliche Bedeutung betonen, sind aber nicht als formale Implementierungsanforderungen verlangt.

Wer nur den zweiten Satz liest, nimmt dem MUST seine Dringlichkeit. Wer nur den ersten liest, erfindet einen Konformitätsrahmen, den der Text nicht schafft. Beides verfehlt den Entwurf. Die Praxis soll mit größter Ernsthaftigkeit behandelt werden; das Dokument stellt aber weder eine Lizenzbedingung noch eine Auditmeinung oder Gewährleistung für einen konkreten Dienst aus.

Auch ein späterer BCP-Status bleibt innerhalb dieser Grenze. RFC 7841 beschreibt die Kategorien und Herkunftshinweise der RFC-Reihe. Ein BCP signalisiert Prüfung und Konsens des IETF-Streams und ist damit mehr als ein beliebiger Blogbeitrag. Doch diese Provenienz beantwortet nicht, welche Infrastruktur geprüft wurde, wann die Messung stattfand, wie Ausnahmen behandelt wurden oder was bei der letzten Wiederherstellung geschah.

Konsens autorisiert die Referenz. Umsetzungsdaten autorisieren die Aussage über einen Betreiber.

Drei Oberflächen brauchen drei Nenner

Der Entwurf verlangt hohe Verfügbarkeit sowohl für den öffentlichen Repository-Inhalt als auch für die Publikations-Engine. Die beiden Ausfälle haben unterschiedliche Folgen. Fallen RRDP oder rsync aus, können Relying Parties den aktuellen Zustand nicht regulär beziehen. Fällt die Engine aus, kann eine CA neue Ausstellungen und Widerrufe nicht verteilen. Dauert die Störung an, können Manifeste, Widerrufslisten und signierte Objekte veralten.

Eine zusammengezogene Prozentzahl verwischt diese Unterschiede. Ein sinnvoller Beleg trennt die publisherseitige Engine, RRDP und rsync. Er benennt Messfenster, Nenner, Ausnahmen und den verbleibenden Zeitraum bis zur Veraltung gültiger Daten. Die Antwort eines Endpunkts ist kein Nachweis dafür, dass das erwartete Objekt erschienen ist.

Der Entwurf empfiehlt, die Engine auf anderen Systemen als die öffentlich angefragten RRDP- und rsync-Dienste zu betreiben. Lese-Last soll den Änderungsweg nicht mitreißen. Ein öffentlicher Umsetzungsbeleg kann logische Trennung und Fehlerdomänen beschreiben, ohne IP-Adressen, Zugangsdaten oder sicherheitskritische Topologie offenzulegen.

Besonders aussagekräftig ist die empfohlene End-to-End-Messung: Ein neu ausgestelltes Objekt wird erwartet und sein Auftauchen über den öffentlichen Weg beobachtet. Dafür müssen Startsignal, Endbeobachtung, Objektklasse, Messpunkte, Zeitraum, Perzentile, Fehlschläge und Ausschlüsse definiert sein. Der Entwurf verweist auf eine Untersuchung mit 15 bis 95 Minuten Laufzeit im untersuchten Bestand. Das ist eine Beobachtung über diese Stichprobe, kein allgemeines Serviceziel.

Wiederherstellung erzeugt eine überprüfbare Ereigniskette

Wenn eine Wiederherstellung den Inhalt auf einen älteren Stand zurücksetzt, muss der Server laut Entwurf die RRDP-Session zurücksetzen. Betroffene Zertifizierungsstellen sollen benachrichtigt werden, damit sie eine vollständige Resynchronisierung beginnen können.

Ein belastbarer Vorfallbeleg verbindet mehrere Zeitpunkte: Einspielen der Sicherung, Alter des wiederhergestellten Zustands, Erkennen der Regression, neue Session-ID, Benachrichtigung der Publisher, Listenabgleich, vollständige Neupublikation und abschließender Vergleich mit der öffentlichen Sicht. Eine Uptime-Grafik kann diese Kette nachträglich nicht herstellen.

RFC 8181 erlaubt einer CA, den vom Server anerkannten Bestand per List-Abfrage zu ermitteln. Der Entwurf empfiehlt diesen Abgleich vor Änderungen. Zusammengehörige Änderungen sollen in einer Anfrage mit mehreren Elementen gebündelt werden, um inkonsistente Teilergebnisse zu vermeiden. Regelmäßiger Abgleich soll ohne Vereinbarung nicht häufiger als alle zehn Minuten erfolgen, weil dem Protokoll ausreichende Signale für Rate Limiting und Backoff fehlen.

Das sind protokollierbare Tatsachen. Sie verlangen keine Veröffentlichung privater Kundennamen oder Schlüssel. Nötig sind Umfang, Zeitpunkt, erklärter Zustand, Abschluss und die Instanz, die für die Aussage einsteht.

Serial und Manifest sind keine universellen Prüfzeichen

RRDP verwendet Session-ID und Serial, Deltas für einzelne Publikationsereignisse und einen Snapshot für den vollständigen aktuellen Bestand. Eine steigende Serial belegt spätere Revisionen in dieser Session. Sie belegt nicht allein, dass die beabsichtigte Menge des Publishers angenommen wurde, jeder Knoten hinter dem Load Balancer dieselben Dateien zeigte oder jede Relying Party die Änderung sah.

Deshalb verlangt der Entwurf, dass eine neue Notification-Datei nicht vor den referenzierten Snapshots und Deltas sichtbar wird. Mehrere Backends müssen konsistente Sichten liefern. Die Reihenfolge der Sichtbarkeit ist eine Korrektheitseigenschaft, kein bloßes Optimierungsdetail.

RFC 9286 liefert einen anderen, ebenfalls begrenzten Nachweis. Manifeste listen Dateinamen und Hashes und helfen, bestimmte Formen veralteter Ersetzung, unzulässiger Entfernung oder Veränderung auf dem Transportweg zu erkennen. Sie prüfen jedoch weder Wartungsankündigungen noch das Alter einer Sicherung, Dual-Stack-Erreichbarkeit, CDN-Regeln, Lasttests oder Publisher-Support.

Wer diese verschiedenen Aussagen pauschal unter BCP-konform zusammenfasst, verbirgt die Prüfgrenzen gerade dort, wo Transparenz nötig wäre.

Konsolidierung ist eine Betriebsempfehlung, kein Hoheitsrecht

Der Entwurf stellt fest, dass selbst betriebene Repositorien in der Praxis häufiger Verfügbarkeitsprobleme zeigen als Dienste größerer Spezialorganisationen. Viele Publikationspunkte erhöhen zudem die Arbeit der Relying Parties. Übergeordnete CAs sollen daher Publikation für untergeordnete CAs anbieten; diese sollen das Angebot nutzen. Steht es nicht zur Verfügung, ist ein verlässlicher Dritter oft besser als ein weiterer isolierter Dienst.

Das ist ein Betriebsargument für Konsolidierung. Es verleiht keinem RIR, NIR oder kommerziellen Anbieter eine exklusive politische Zuständigkeit. Der Entwurf erkennt auch an, dass kleine, wenig veränderliche Repositorien mit überschaubarer Infrastruktur hoch verfügbar sein können, und beschreibt verschiedene Publikationswege für nachgelagerte CAs.

Der Umsetzungsbeleg muss die Wahl erhalten. Er benennt das Modell — Eigenbetrieb, Parent-Service, Drittanbieter oder Proxy — und wendet nur passende Maßnahmen an. Nicht anwendbar ist mit einer begrenzten Begründung legitim. Ein leeres Feld ist es nicht, weil es Leser zur günstigsten Annahme verleitet.

Der versionierte Umsetzungsbeleg

Der erste Teil klärt die Identität: Betreiber, Dienst, Architektur, öffentliche Repository-Kennungen, betroffene Kundengruppe sowie genaue Entwurfs- oder RFC-Version. Die Aussage „folgt dem IETF-BCP“ wird mit jeder Revision unklarer, wenn die Version fehlt.

Im zweiten Teil steht ein Maßnahmenregister. Jeder wesentliche Abschnitt erhält einen stabilen Eintrag und einen Status: umgesetzt, nicht anwendbar, geplant, Ausnahme oder unbekannt. Dazu gehören Erklärungsbefugnis, Prüfdatum und begrenzte Begründung. Eine Korrektur hängt eine neue Version an, statt den alten Stand zu löschen.

Der dritte Teil definiert Messungen. Eine Publikationslaufzeit nennt Objektklasse, Beginn, Ende, Beobachtungspunkte, Zeitraum, Perzentile, Ausfälle und Ausschlüsse. Verfügbarkeit wird für Engine, RRDP und rsync getrennt. CDN-Frische nennt Cache-Regel und tatsächliche Probe. Die Konsistenz von Load-Balancer-Knoten braucht einen sicheren Test, der Differenzen findet, ohne eine Angriffsanleitung zu veröffentlichen.

Der vierte Teil erfasst Änderung und Erholung: Wartung, Regression, RRDP-Reset, Benachrichtigung, Resynchronisierungsauftrag, Abschluss und offene Differenzen. Der fünfte begrenzt die Aussage. Er unterscheidet Betreibererklärung, unabhängige Messung, vertragliches Audit und Vorfallprüfung und nennt Systeme sowie Zeitraum.

Ein solcher Beleg ist weniger verkaufsstark als ein Häkchen. Dafür kann jede Zeile geprüft und angefochten werden. Ein Häkchen beendet die Frage zu früh.

Was heute nicht behauptet werden kann

Der Last Call beweist weder Annahme noch unveränderte Veröffentlichung. Der IESG kann Kommentare erhalten, Überarbeitungen anfordern, eine spätere Fassung bewerten oder die Veröffentlichung ablehnen. Eine RFC- oder BCP-Nummer existiert noch nicht.

Die Zugehörigkeiten der Autoren — darunter RIPE NCC, ARIN, APNIC und BSD — sind keine Auditstichprobe dieser Organisationen. Aus Autorenschaft folgt nicht, dass jede Empfehlung umgesetzt ist. Der Entwurf nennt auch keinen Betreiber, der bei einer Wiederherstellung versagt oder inkonsistenten Inhalt ausgeliefert hätte.

Keine Quelle sagt, ein BCP verdränge Vertrag, Beschaffungsvorgabe, Regulierer, Gerichtsbeschluss oder lokale Routing-Policy. RFC 8181 beschreibt den Publikationsaustausch, RFC 8182 die Repository-Verteilung und RFC 9286 Manifeste. Diese Dokumente definieren wichtige technische Zustände; sie machen aus einem Titel keinen Leistungsnachweis.

Die belastbare Schlussfolgerung ist enger: Die IETF prüft einen detaillierten Kandidaten für den Betrieb von Publikationsdiensten. Wird er BCP, gewinnt die Referenz an Gewicht. Ob und wie ein bestimmter Betreiber die Abschnitte umsetzt, bleibt eine eigenständige Beweisfrage.

Quellen

  1. IESG — Last Call zum Entwurf über RPKI-Publikationsdienste
  2. IETF Datatracker — Dokumenteintrag des BCP-Entwurfs
  3. IETF Datatracker — Entwurfsversion 10
  4. RFC 2119 — Schlüsselwörter für Anforderungsstufen
  5. RFC 8174 — Klarstellung zu Groß- und Kleinschreibung
  6. RFC 7841 — RFC-Streams, Kategorien und Textbausteine
  7. RFC 8181 — RPKI-Publikationsprotokoll
  8. RFC 8182 — RPKI Repository Delta Protocol
  9. RFC 9286 — RPKI-Manifeste
  10. RFC 7115 — Betrieb RPKI-basierter Herkunftsvalidierung