Zusammenfassung

  • ARINs angenommener Entwurf für RPKI Routing Intelligence zeigt Nutzern von ARIN Online beobachtete Routen, Validierungszustände und Warnungen, bevor sie eine ROA-Änderung bestätigen. Für API-Nutzer verweist der Entwurf dagegen ausdrücklich auf Werkzeuge Dritter.
  • Die heutige RPKI-REST-Schnittstelle kann ROAs in einer einheitlichen Transaktion anlegen, ändern und löschen sowie diese Schritte atomar mit ASPA-Änderungen verbinden. Der programmatische Weg ist damit ein folgenreicher Schreibkanal und keine bloße Lesehilfe.
  • Die angemessene Antwort wäre eine optionale, maschinenlesbare Vorabprüfung nach demselben Beratungsmodell wie die Webansicht. Sie muss Quellen, Alter und Grenzen offenlegen, ohne zur Sperre, zum globalen BGP-Orakel oder zum Ersatz lokaler Routingpolitik zu werden.

Die Schutzfunktion sitzt vor dem Klick

Eine ROA-Änderung wirkt auf wenige Felder reduziert: Präfix, Origin-AS und maximale Präfixlänge. Ihre Bedeutung entsteht jedoch erst im Verhältnis zu tatsächlich angekündigten Routen und zu den validierten ROA-Payloads, die eine Relying Party gerade kennt. Ein Tippfehler bei der maximalen Länge kann deshalb technisch korrekt angenommen und trotzdem betrieblich unerwünscht sein. Ebenso kann eine bewusst vorbereitete Migration aus einer einzelnen Momentaufnahme verdächtig aussehen, obwohl sie Teil einer richtigen Reihenfolge ist.

ARIN hat genau für diesen Zwischenraum eine sinnvolle Pause vorgesehen. In der Konsultation 2024.1 wurde ein neues Dashboard beschrieben, das BGP-Ankündigungen für die Ressourcen eines Kunden, den aktuellen RPKI-Status, mögliche Abweichungen und Hinweise zur Korrektur zeigt. Vor der Bestätigung soll der Nutzer erkennen können, ob eine geplante Autorisierung eine beobachtete Route voraussichtlich Valid, Invalid oder NotFound erscheinen lässt. Das Ergebnis der Konsultation nahm den Vorschlag an und hielt zugleich fest, dass API-Nutzer Werkzeuge Dritter benötigen würden, um diese Informationen zu sammeln.

Diese Trennlinie ist bemerkenswert, weil die API keineswegs nur zuschaut. ARINs aktuelle Dokumentation erlaubt, mehrere ROAs in einer einheitlichen Transaktion anzulegen, zu verändern oder zu entfernen. ROA- und ASPA-Operationen können in derselben atomaren Einheit stehen: Entweder alle Änderungen gelingen oder keine. Wer diesen Weg nutzt, kann also genau jene Konfigurationsänderungen in wiederholbarer Form ausführen, für die der Webnutzer eine neue Warnfläche erhalten soll.

Daraus folgt kein behaupteter Zwischenfall. Die ausgewerteten öffentlichen Quellen belegen weder einen durch ARINs API verursachten Routingausfall noch einen schädlichen ROA-Fehler eines bestimmten Kunden. Der Befund ist enger: ARIN plant eine erstinstanzliche Auswirkungsanzeige für die menschliche Oberfläche, während der programmatische Schreiber die vergleichbare Evidenz außerhalb der Registry zusammensetzen muss.

Das beste Argument für Web zuerst

Für diese Priorität gibt es eine solide Verteidigung. Viele Nutzer des gehosteten RPKI dürften Änderungen gelegentlich in ARIN Online vornehmen. Eine visuelle Tabelle kann beobachtete Präfixe, Origin-AS, den jetzigen Validierungszustand und einen erwarteten Zustand ohne neues API-Schema nebeneinanderstellen. Sie lässt sich erklären, testen und schrittweise verbessern. Betreiber, die ihre ROAs automatisieren, verfügen dagegen häufig bereits über einen Validator, RIPEstat, Route Views, eigene BGP-Feeds oder kommerzielle Überwachung.

Vor allem ist die Warnung eine Beobachtung, kein allwissendes Urteil. Auf der ARIN-56-Sitzung wurden RIPE RIS und Route Views als vorgesehene Quellen genannt; die Daten wurden als relativ aktuelle Momentaufnahme beschrieben. RIPE RIS dokumentiert seine Route Collectors und die Bereitstellung von MRT-Daten. RouteViews dokumentiert eine API über die von seinem eigenen Beobachtungsnetz erfassten Informationen. Beide Systeme sind wertvoll, aber ihre Sicht ergibt sich aus konkreten Collectors, Peers und Zeitpunkten.

Eine solche Sicht erfasst nicht jede private Ankündigung, nicht jeden bevorstehenden Traffic-Engineering-Schritt und nicht die Cache-Zeit jedes Relying-Party-Systems. Würde ARIN eine Transaktion aufgrund dieser Momentaufnahme blockieren, vermischte die Registry zwei verschiedene Autoritäten. ARIN kann prüfen, ob der authentifizierte Resource Holder über die zertifizierten Ressourcen verfügen darf. Ein Collector kann nur berichten, was bestimmte Beobachter zu bestimmten Zeiten gesehen haben.

Gerade deshalb sollte die Auswirkungsanalyse nicht zu einer härteren Schranke werden. Sie sollte transportierbar werden. Die Weboberfläche darf den Befund in Sätzen und Farben erklären; die API sollte denselben Typ von Evidenz in stabilen Feldern liefern können.

Vorhersage, Schreiben und Veröffentlichung sind verschiedene Vorgänge

Im Alltag werden mehrere Stufen gern unter dem Wort „Validierung“ zusammengezogen. Für eine belastbare Schnittstelle müssen sie getrennt bleiben.

Zuerst steht die Registry-Berechtigung: Darf dieses Konto ARIN anweisen, ein Objekt für diese Ressourcen auszustellen? Danach kommt eine Vorhersage: Wie würden bestimmte beobachtete Routen unter einer vorgeschlagenen Menge von ROA-Änderungen bewertet? Erst der nächste Schritt verändert die gehostete Konfiguration. Anschließend veröffentlicht ARIN die signierten Objekte im RPKI-Repository. Zuletzt laden Relying Parties diese Objekte nach ihren eigenen Zeitplänen, validieren sie und speisen das Ergebnis in ihre lokale Routingpolitik ein.

RFC 6811 definiert Valid, Invalid und NotFound aus dem Verhältnis zwischen Route und lokal verfügbaren validierten ROA-Payloads. RFC 7115 macht die betriebliche Lokalität deutlich: Router hängen von Validierungs-Caches ab, deren Synchronisierung die jeweiligen Betreiber steuern. Eine ARIN-Ansicht kann deshalb einen Zustand unter benannten Eingaben prognostizieren. Sie kann nicht garantieren, was jedes Netz im selben Moment sieht oder mit dem Ergebnis tut.

Auch ARINs eigene ROA-Dokumentation beschreibt Übergänge statt eines magischen Augenblicks. Die Webbedienung enthält einen Review-Schritt. Das Repository wird in kurzen Abständen aktualisiert, und Betreiber sollen mit einem Validator prüfen, ob ihre Ressourcen aktiv sind. Eine Entfernung kann in der ARIN-Datenbank sofort wirksam sein, während ihre Abbildung im öffentlichen Repository einem eigenen Zeitfenster folgt.

Eine Vorabprüfung der API darf daher nichts unbemerkt anlegen, freigeben oder veröffentlichen. Ihr Vertrag sollte schlicht lauten: exakter Transaktionsvorschlag hinein, begrenzte Auswirkungsanalyse heraus.

Wie eine kleine, ehrliche Vorabprüfung aussehen könnte

Der nützliche Mindestumfang beginnt mit einem Digest des Vorschlags. Eine atomare Anfrage kann ein ROA entfernen, zwei neue anlegen und zugleich eine ASPA-Konfiguration ändern. Wenn die Warnung nicht an genau diesen Inhalt gebunden ist, beschreibt sie nur eine ungefähre Absicht und nicht die später eingereichte Transaktion.

Hinzu gehört eine Kennung des verwendeten Ressourcenzustands. Die vorgeschlagenen Präfixe müssen gegen die Ressourcen geprüft werden, die ARIN zum betreffenden Zeitpunkt zertifizieren kann. Dafür genügt eine Version oder ein Hash; vertrauliche Kontodaten müssen nicht offengelegt werden.

Für die Routingbeobachtung braucht es Namen der Quellen, Zeitstempel pro Snapshot und eine explizite Frischebewertung. Pro betroffener Route sollten beobachtetes Präfix und Origin, heutiger Zustand, prognostizierter Zustand und ein stabiler Warncode erscheinen. Menschen benötigen eine verständliche Erklärung. Automatisierung benötigt zusätzlich eine Bedeutung, die nicht davon abhängt, wie ein Satz in einer Browseransicht formuliert wurde.

Schließlich braucht das Ergebnis ein Ablaufdatum. Eine vor zehn Minuten gewonnene Sicht ist keine dauerhafte Freigabe. Sind Quellen zu alt oder nicht erreichbar, sollte die Antwort „veraltet“ oder „nicht verfügbar“ sagen. Das Fehlen einer Beobachtung darf weder stillschweigend Erlaubnis noch Verbot bedeuten.

Optional könnte ein Korrelationstoken den Digest der Analyse mit dem Digest einer späteren Schreiboperation verknüpfen. Es wäre kein Sicherheitszertifikat und dürfte nicht erforderlich sein. Sein Wert wäre bescheidener: In einer Nachprüfung ließe sich zeigen, welche Evidenz zu welcher noch widerrufbaren Entscheidung gehörte.

ARIN protokolliert den Kanal bereits nach der Änderung

Eine dafür nötige Denkfigur existiert bereits. ARINs ROA Change Log hält fest, ob eine Operation von einem Web User, API User oder ARIN System kam. Dazu werden Zeit, Operation, Origin-AS, Präfix, maximale Länge und die ändernde Identität aufgeführt. Dieses Protokoll beantwortet im Nachhinein, wer was über welchen Kanal geändert hat.

Es beantwortet nicht, was vor der Entscheidung sichtbar war. Das ist auch nicht seine Aufgabe. Ein Change Log belegt die Herkunft einer erfolgten Mutation; ein Preflight bewahrt die Eingaben einer Prognose, solange die Mutation noch optional war. Später lassen sich beide Digests verbinden, ohne die Prognose rückwirkend zum Urteil zu erklären.

ARIN hat Schnittstellenparität zudem schon ausdrücklich als Produktmerkmal behandelt. 2023 kündigte die Registry einen REST-Endpunkt an, der Verbesserungen des Web-Workflows für ROAs einschließlich automatischer Verlängerung auch programmatisch verfügbar machen sollte. Das ist kein Versprechen, Routing Intelligence ebenfalls über eine API anzubieten. Es zeigt aber, dass Parität benannt, entworfen und überprüft werden kann.

Was der öffentliche Zeitplan tatsächlich sagt

Beim Status ist Zurückhaltung nötig. ARIN berichtete im Oktober 2025, dass die Entwicklung am 30. September begonnen habe. Im April 2026 wurde Routing Intelligence weiterhin als nah bevorstehende beziehungsweise laufende Arbeit beschrieben. Das öffentliche Verzeichnis implementierter Funktionen bis zum Release vom 28. Juli 2026 kündigt die Funktion nicht an. Daraus lässt sich eine geplante oder kommende Fähigkeit ableiten, nicht jedoch beweisen, dass es keinen begrenzten Build, keinen internen Meilenstein und keinen späteren API-Entwurf gibt.

Auf ARIN 57 war außerdem allgemein von zusätzlichen API-Fähigkeiten die Rede. Öffentlich wurde diese Aussage nicht spezifisch mit Routing Intelligence verbunden. Ebenso wenig belegt der angenommene Entwurf eine endgültige Ablehnung von API-Parität. Die belastbare Aussage bleibt: Der konkrete veröffentlichte Entwurf ordnet die Auswirkungsansicht ARIN Online zu und verweist API-Nutzer auf Dritte.

Ein offener Community-Vorschlag für eine „Analyze“-Funktion und einen herunterladbaren CSV-Bericht berührt dasselbe Problem von einer anderen Seite. ARIN verwies auf die ähnliche Webfunktion in Arbeit und wollte den Bericht prüfen. Ein CSV kann menschliche Prüfung erleichtern. Er ist aber noch kein versionierter Anfrage-Antwort-Vertrag, der genau die Transaktion bewertet, die ein System anschließend absenden will.

Die Warnung muss ihre Grenzen zeigen

Die glaubwürdigste Ausführung wäre wertvoll, weil sie keine Gewissheit vortäuscht. Webansicht und API-Antwort sollten das Beobachtungsset benennen, Alter anzeigen und „Echtzeit“ nicht als pauschales Versprechen verwenden. Eine Route, die in ausgewählten Views fehlt, ist nicht automatisch im Internet abwesend. Ein prognostizierter RPKI-Zustand ist weder die Bestätigung der Repository-Veröffentlichung noch die Entscheidung eines nachgelagerten Netzes.

Dann können Mensch und Maschine dieselbe Evidenzklasse in verschiedener Form erhalten. Der Mensch liest eine Tabelle; die Automatisierung vergleicht strukturierte Ergebnisse mit eigener Absicht und eigenen Feeds, fordert bei Abweichungen einen Reviewer an und archiviert die Eingaben. ARIN bleibt Aussteller, der Resource Holder bleibt Entscheider, Collectors bleiben Beobachter und Netze behalten ihre Routingpolitik.

Das wäre keine monumentale Neuordnung. Es wäre eine kleine Schnittstelle an der Stelle, an der eine wiederholbare Änderung noch rückgängig gemacht werden kann. Gerade dort sollte der programmatische Schreiber nicht weniger nachvollziehbare Erstinstanz-Evidenz erhalten als der Mensch vor dem Klick.

Quellen