Zusammenfassung

  • ARIN führte Trust-Anchor-Constraints im April 2026 als geplante RPKI-Verbesserung auf. Das maßgebliche IETF-Dokument ist jedoch weiterhin ein aktiver Internet-Draft und kein Beleg für einen Produktivbetrieb.
  • Wirksam ist die lokale .constraints-Datei. Zwischen täglicher Registerstatistik und dieser Datei liegen Transferzustand, mögliche NRO-Signaturen, Übersetzung in Ressourcensätze, Paketfreigabe, Installation und Betreiberentscheidung.
  • Ein versionierter Verteilnachweis kann die Übergaben sichtbar machen, ohne dem NRO, ARIN oder einem Paketbetreuer die lokale Routing-Entscheidung zu übertragen.

Die sechs Monate nach dem richtigen Ergebnis

Eine Constraints-Liste kann im Moment ihrer Erstellung vollkommen richtig sein und beim Einsatz dennoch die falsche Zeit beschreiben. Der aktuelle IETF-Entwurf rät Betreuern, die solche Listen über Betriebssystem- oder Drittanbieterpakete verteilen, mit bis zu sechs Monaten Verzögerung bei Nutzeraktualisierungen zu rechnen. Das ist keine Messung tatsächlicher Installationen. Es ist eine Planungsannahme — und damit ein Hinweis darauf, wo die technische Wahrheit ihre Aktualität verlieren kann.

Nehmen wir einen Transfer zwischen zwei Regionalregistern. Der Quellbestand ändert sich, ein gemeinsamer Zustand wird berechnet, ein Compiler erzeugt neue Constraints und ein Paket erscheint. Ein Betreiber installiert es unmittelbar. Ein zweiter folgt einem monatlichen Wartungsfenster. Ein dritter bleibt in einem Long-Term-Support-Zweig. Alle können dasselbe Verfahren nutzen, ohne dieselbe Vertrauensgrenze zu verwenden.

Der neueste Zeitstempel auf einer ARIN-Webseite reicht daher nicht. Entscheidend ist, welche .constraints-Datei neben dem Trust Anchor liegt, welche Validatorversion sie liest und ob eine lokale Ausnahme sie verändert. Ein Betreiber kann eine ältere Fassung auch absichtlich als letzten bekannten guten Zustand festhalten. Der operative Beleg muss Quelle, Verarbeitung, Auslieferung, Installation und Entscheidung verbinden.

Der genaue Umfang der Ankündigung auf ARIN 57

Auf ARIN 57 im April 2026 nannte der Engineering Report Trust-Anchor-Constraints unter den geplanten öffentlichen Verbesserungen des RPKI-Dienstes. Der Zeitplan hing von laufender IETF-Standardisierung ab. Die folgende Folie ordnete die Zuarbeit der Number Resource Organization zu: Erweiterte Statistiken sollten den Bestand der einzelnen Register abbilden, erweiterte Transferprotokolle die Bewegungen zwischen RIRs. Deren Spezifikation war noch in Arbeit. Das Material sollte den IETF-Entwurf unterstützen; rpki-client enthielt bereits eine Implementierung.

Im Sitzungsprotokoll wurde die Idee als Liste der Netzwerkressourcen beschrieben, die innerhalb des jeweiligen Regionalregisters autorisiert sind — ähnlich einer Zugangskontrollliste im RPKI. Von Entwürfen und funktionierendem Code war die Rede. Daraus folgt ein ernsthaftes Engineering-Vorhaben. Nicht daraus folgen ein Einführungstermin, eine Zahl produktiver Installationen oder ein identischer Zustand bei allen relying parties.

Auch im September bleibt die Norm vorläufig. draft-ietf-sidrops-constraining-rpki-trust-anchors-01 trägt das Datum 9. August 2026 und wird im Datatracker als aktiver SIDROPS-Internet-Draft mit IESG-Status „I-D Exists“ geführt. Er ist kein RFC. Der NRO-Entwurf zur Konstruktion und Signatur eines Ressourcenverteilungszustands ist ebenfalls noch ein Entwurf. Früher Code kann die Standardisierung verbessern; er ersetzt keinen Deployment-Nachweis.

Die breite Wurzel war Absicht

Constraints sollen eine Fähigkeit einhegen, die 2017 aus Gründen der Verfügbarkeit bewusst breit gestaltet wurde. Im September jenes Jahres stellte ARIN in Abstimmung mit den anderen RIRs sein Trust-Anchor-Zertifikat auf eine All-Resources-Form um, in der Mitteilung als 0/0 verkürzt. Der TAL blieb unverändert. Ziel war es, bei vorübergehenden Inkonsistenzen während Inter-RIR-Transfers eine massive Invalidierung darunterliegender RPKI-Produkte zu vermeiden.

Der aktuelle SIDROPS-Entwurf hält fest, dass alle fünf RIR-Trust-Anchor-Zertifikate sämtliche IPv4-, IPv6- und ASN-Ressourcen aufführen. Das ist kein administrativer Anspruch jedes Registers auf das gesamte Internet. Die Breite hält die kryptografische Hierarchie stabil, wenn Register ihre Daten nicht gleichzeitig umstellen. Sie gibt einem Anchor allerdings technisch die Möglichkeit, auch außerhalb seines aktuellen Bestands auszustellen.

Eine lokale Constraint reduziert diesen Raum auf das, was der Betreiber unter diesem Anchor erwartet. Sie ist Least Privilege nach einer bewusst gewährten Kontinuitätsreserve. RFC 6480 überlässt jedem relying party die Wahl seiner Trust Anchors. RFC 8211 analysiert nachteilige Handlungen von Zertifizierungsstellen und Repository-Betreibern. Beides begründet keinen automatischen Übergang von ARINs Betriebsbericht in die Routing-Policy eines fremden Netzes.

Die Policy steht in der lokalen Datei

Der Entwurf definiert eine Constraint als lokale Vereinigung von IP-Präfixen oder -Bereichen sowie AS-Kennungen oder -Bereichen, deren Ausstellung der Betreiber unter einem Anchor erwartet. Die Syntax nutzt allow und deny. Verbote haben Vorrang, gleichartige Einträge dürfen sich nicht überlappen, die Reihenfolge ist ohne Bedeutung und nicht ausdrücklich erlaubte Ressourcen sind implizit verboten.

Geprüft wird am End-Entity-Zertifikat. Sind dessen Ressourcen nicht vollständig in der lokalen Constraint enthalten, soll der relying party die Verarbeitung beenden und das Zertifikat als ungültig behandeln. Betroffen sein können ROAs, ASPAs, RPKI Signed Checklists, BGPsec-Routerzertifikate und Geofeeds. Für Manifeste, Ghostbusters Records und signierte TALs mit vererbten Ressourcen gilt diese Prüfung nicht auf dieselbe Weise.

Das OpenBSD-Handbuch für rpki-client macht die Betriebsstelle greifbar. Eine .constraints-Datei kann denselben Basisnamen wie die zugehörige .tal-Datei tragen. Der TAL identifiziert den Anchor; die Constraint formuliert die lokale Erwartung an dessen Ressourcenumfang. Dateinachbarschaft ist keine gemeinsame Provenienz. Ohne Hash der geladenen Constraint lässt sich ein Wechsel von akzeptiert zu verworfen nicht verlässlich erklären.

In die Liste fließt außerdem Policy-Wissen. Der Entwurf verweist darauf, dass die ARIN-Community den Vorschlag ARIN-2019-4 für interregionale IPv6-Transfers aufgegeben hat. Von ARIN vergebene IPv6-Ressourcen sollten deshalb normalerweise nicht unter dem Anchor eines anderen RIR erscheinen. Private, zu Dokumentationszwecken vorgesehene und bestimmte reservierte Ressourcen gehören unter keinen RIR-Anchor. Der Compiler interpretiert Regeln; er kopiert nicht bloß eine Tabelle.

Täglich ist nur der Takt einer Quelle

ARIN aktualisiert seine Extended Delegation Statistics jeden Tag. Sie berichten IPv4-, IPv6- und ASN-Verteilungen im NRO-Format. ARIN weist ausdrücklich darauf hin, dass Reallocations und Reassignments fehlen. Die Zusammenführung regionaler Berichte kann Überschneidungen und Lücken zeigen, den Status übertragener Adressen kenntlich machen und die administrative Zuständigkeit für nicht vergebene Ressourcen benennen. Das ist eine starke Datenquelle, aber noch keine installierte Constraint.

Der tägliche Takt sagt nicht, wann jedes Ereignis entstand, wann der Compiler die Datei abholte, wann ein Paket gebaut oder wann es installiert wurde. Ein Bestandsbild beschreibt außerdem nicht automatisch den Weg zwischen zwei Beständen. ARIN 57 erwähnte erweiterte Transferlogs gerade deshalb zusätzlich; ihre Spezifikation befand sich noch in Arbeit.

Wechselt eine Constraint zu früh vollständig auf den Empfänger, kann sie Produkte verwerfen, die unter der Quelle noch legitim sind. Wechselt sie zu spät, bleibt eine überholte Erlaubnis bestehen. Das All-Resources-Zertifikat schützt die kryptografische Kontinuität. Eine Constraints-Datei ohne Zeit- und Phasenkontext kann dieselbe Verfügbarkeitslücke auf der lokalen Ebene neu öffnen.

Der korrekte Zustand mit zwei Anchors

draft-nro-sidrops-ta-constraints-00 schlägt signierte Resource Distribution State-, Event- und Consensus-Objekte vor. Die anfänglichen Ressourcensätze der Teilnehmer sollen disjunkt sein. Ein Transfer gliedert sich in Einleitung, Annahme durch den Empfänger und Finalisierung durch die Quelle.

Nach der Annahme und vor der Finalisierung können beide Anchors als Inhaber der Ressource gelten. Diese vorübergehende Überschneidung lässt den Empfänger passende signierte Objekte bereitstellen, ohne eine Verfügbarkeitslücke zu erzeugen. Mit der Finalisierung wird er für die Constraint-Prüfung zum alleinigen Inhaber. Eine fehlerhafte Finalisierung wird nicht still aus der Geschichte gelöscht; ein kompensierender Transfer kann die Ressource zurückgeben.

Eine am Dienstag während der Annahme erzeugte Liste darf folglich beide Anchors zulassen. Eine am Donnerstag nach der Finalisierung erzeugte Liste sollte nur noch den Empfänger zulassen. Beide können für ihren Zeitpunkt korrekt sein. Erst Transferkennung und -phase, Quellhashes und Bauzeit erklären, warum sich zwei Pakete unterscheiden.

Ein signierter NRO-Zustand würde die Provenienz des Inputs verbessern. Er wäre dennoch keine verbindliche lokale Konfiguration. Der IETF-Entwurf nennt ihn als möglichen Input und betont, dass jeder relying party nach eigenen Kriterien und eigenem Zeitplan entscheidet. Die Register können gemeinsam einen administrativen Zustand belegen; sie übernehmen damit nicht die Routing-Policy jedes Netzes.

Ein Nachweis für jede Übergabe

Der Verteilnachweis beginnt mit Namen, Zeitstempeln und Hashes der Quelldateien. Dazu gehören Spezifikations- und Schemaversion, Compileridentität und ein Verweis auf einen reproduzierbaren Build. Wird ein signierter NRO-Zustand verwendet, nennt der Nachweis die Signaturinstanz und das Prüfergebnis.

Für jeden Anchor werden die IPv4-, IPv6- und ASN-Ressourcensätze getrennt gehasht. Bei einem Transfer stehen Kennung und Phase dabei, einschließlich des vorübergehenden Dual-Anchor-Fensters. Danach folgen Paketname, Version, Bauzeit und Distributionskanal. Installationszeit, Herkunft eines lokalen Overrides, Validatorimplementierung und Hash der tatsächlich geladenen Datei schließen den technischen Weg.

Schließlich muss Wirkung sichtbar werden: Wie viele Objekte wurden allein wegen der Constraint akzeptiert oder verworfen, getrennt nach Objektklasse? Welche Alterswarnung griff? Was war der letzte bekannte gute Zustand, welche Fallback- oder Rollback-Entscheidung wurde getestet? Wer traf die lokale Entscheidung und wann wurde sie wirksam? Aggregierte Zähler und Hashes beantworten das, ohne vertrauliche Routerkonfigurationen offenzulegen.

Der Nachweis verbessert auch die Zuschreibung. „ARIN hat dieses ROA verworfen“ kann falsch sein, wenn ein lokaler Validator auf Basis einer von Dritten kompilierten und verteilten Datei das EE-Zertifikat nicht weiterverarbeitet. Das Register liefert Evidenz, das NRO kann einen gemeinsamen Zustand signieren, ein Maintainer baut, ein Paket verteilt, der Validator prüft und der Betreiber entscheidet. Jede Handlung braucht ihr eigenes Subjekt.

Was noch nicht belegt ist

Die Quellen zeigen nicht, dass ARIN Constraints für relying parties produktiv ausgerollt hat, dass alle Validatoren dieselbe NRO-Liste verwenden oder dass ein veraltetes Paket einen Routing-Vorfall verursacht hat. Die sechs Monate sind eine Planungsannahme, kein gemessener Median. Die tägliche Statistik hat erklärte Auslassungen, und die auf ARIN 57 erwähnten Transferlogs waren noch in Spezifikation.

Auch führt ein während der RPKI-Validierung verworfenes Zertifikat nicht automatisch zum Rückzug einer Route. Der Validator erzeugt einen Zustand; wie der Betreiber ihn in lokale Routing-Policy übersetzt, bleibt dessen Entscheidung. Weitere gültige Objekte, Software und Konfiguration beeinflussen das Ergebnis. Der hier vorgeschlagene Nachweis ist eine Empfehlung dieser Analyse und keine bestehende Vorgabe von ARIN oder IETF.

Quellen