Zusammenfassung

  • Seit Oktober 2023 benachrichtigt ARIN Admin-, Tech- und Routing-POCs, wenn ein ROA gelöscht wird. Im Juni 2024 stieg die zulässige Höchstzahl von ROA-Löschungen je Organisation von 20.000 auf 40.000.
  • ACSP 2025.6 verlangt einen Schalter, der sämtliche E-Mails eines Aufrufs zur Massenlöschung unterdrückt. ACSP 2026.6 hält fest, dass Anlegen und Ändern nicht alle POCs benachrichtigen.
  • Der Wunsch nach weniger E-Mail ist berechtigt. Dennoch können Anlegen, Ändern und Löschen jeweils die Berechtigungsgrundlage verändern, anhand derer Routen als Valid, Invalid oder NotFound eingeordnet werden.
  • Die kleinste belastbare Lösung ist eine dauerhafte Zusammenfassung je abgeschlossener Transaktion: handelnde Berechtigung, Zustand vorher und nachher, atomarer Ausgang, beobachtete Veröffentlichung und unabhängig erreichter Empfänger.

Eine Warnung mit gutem Grund und falscher Maßeinheit

Am 9. Oktober 2023 ergänzte ARIN in ARIN Online Benachrichtigungen an Admin-, Tech- und Routing-POCs, sobald eine Route Origin Authorization gelöscht wird. Die Entscheidung ist nachvollziehbar. Ein ROA ist kein gewöhnlicher Datenbankeintrag, sondern die signierte Aussage eines Präfixinhabers, dass ein bestimmtes Autonomes System diese Präfixe als Ursprung ankündigen darf.

RFC 8211 beschreibt, was eine Löschung am Veröffentlichungspunkt bewirken kann. Die überprüfbare Bindung zwischen Präfix und AS entfällt. Wenn kein anderes passendes ROA vorhanden ist, kann eine zuvor gedeckte Route zu NotFound werden. Bleibt ein deckendes ROA für ein anderes AS zurück, kann sie zu Invalid werden.

Das ist keine Ausfallmeldung. Validatoren übernehmen Zustände zu unterschiedlichen Zeiten, und jedes Netz entscheidet selbst, wie es mit Invalid umgeht. Der mögliche Zustandswechsel begründet aber eine unabhängige Beobachtung. Der API-Nutzer, ein Admin POC und die für Routing zuständige Bereitschaft müssen nicht dieselbe Person sein. Eine Meldung außerhalb der Sitzung des Handelnden kann einen Irrtum, einen kompromittierten Zugang oder eine unvollständige Übergabe sichtbar machen.

Der Wert liegt in dieser Trennung. Er liegt nicht darin, dieselbe Information für jedes Objekt zu vervielfachen.

ARINs Release-Verzeichnis vermerkt für den 3. Juni 2024 eine zweite Zahl: Die maximal zulässigen ROA-Löschungen für eine Organisation wurden von 20.000 auf 40.000 erhöht. Die Zahl belegt keinen Vorfall und auch keine einzelne Transaktion mit 40.000 Löschungen. Sie zeigt, für welche Größenordnung das Produkt ausgelegt ist.

Wenn jedes entfernte Objekt an jeden POC eine eigene E-Mail auslöst, wächst die Menge als Produkt aus Objekt- und Empfängerzahl. Beides sind Verwaltungsgrößen, keine Risikoklassen. Eine geplante Bereinigung kann tausende nahezu gleiche Nachrichten erzeugen. Eine einzige unbeabsichtigte Löschung kann wichtiger sein als der gesamte Stapel.

Damit wird aus vollständiger Zustellung nicht automatisch gute Beobachtbarkeit. Wer die Flut erwartet, richtet Filter ein oder liest den Inhalt nicht mehr.

Der berechtigte Wunsch nach einem Ruheknopf

ACSP 2025.6 wurde am 11. Juli 2025 eingereicht. Der Vorschlag schildert große IP-Verwalter mit langen POC-Listen, die ihre Kollegen vor einem großen E-Mail-Aufkommen warnen müssen. Belastet würden sowohl ARINs Mailserver als auch die Postfächer der Empfänger. Gewünscht ist ein optionales Flag für die API zur Massenlöschung. Standardmäßig bliebe das Verhalten unverändert; mit gesetztem Flag würde der Aufruf überhaupt keine E-Mails erzeugen.

ARIN nannte die Funktion am 23. Juli vorteilhaft und kündigte eine Priorisierung im Entwicklungsplan an. Zum Zeitpunkt des Quellenabzugs stand die Seite weiterhin auf Open, bis zur Implementierung. Daraus folgt weder, dass der Schalter bereits verfügbar ist, noch wie eine spätere Umsetzung genau aussehen wird.

Die operative Diagnose ist stark. Tausende Einzelmails sind keine tausend unabhängigen Kontrollen, wenn alle aus einer autorisierten Wartung stammen. Eine einzige verständliche Zusammenfassung kann mehr Aufmerksamkeit erzeugen als ein vollständiger Stapel.

Die vorgeschlagene vollständige Unterdrückung hat jedoch eine andere Folge. Sie kann den letzten Hinweis beseitigen, der die Sitzung des ausführenden Kontos verlässt. Zwischen „alles senden“ und „nichts senden“ fehlt die Ebene der Transaktion.

Auch ein neues ROA kann eine Route auf Invalid stellen

ACSP 2026.6 machte diese Lücke am 23. April 2026 ausdrücklich. Dem Vorschlag zufolge erhalten alle POCs bei einer ROA-Entfernung eine ARIN- und E-Mail-Benachrichtigung, nicht aber beim Anlegen oder Ändern. Gefordert wurden optionale Einstellungen für alle drei Vorgänge, möglicherweise ergänzt um einen globalen Kontostandard.

ARIN fasste die Erweiterung am 27. April mit weiteren ausstehenden ROA-Benachrichtigungen zusammen, gab sie in die interne Priorisierung und Implementierungsplanung und schloss den Vorschlag. Closed bezeichnet den Status im ACSP-Verfahren. Es ist kein Nachweis einer produktiven Funktion.

Die Erweiterung ist technisch begründet. Ein neu angelegtes, deckendes ROA kann eine Ankündigung eines anderen Ursprungs-AS von NotFound zu Invalid verändern. Dasselbe gilt für eine spezifischere Route jenseits des erlaubten maxLength. Eine Änderung kann den Präfixbereich verengen, ein anderes AS autorisieren oder die maximale Länge verschieben.

Ein Add ist deshalb nicht bloß zusätzliche Sicherheit, und ein Delete nicht automatisch ein Reichweitenverlust. Materialität ergibt sich aus dem Vergleich der wirksamen Kombinationen aus Präfix, Origin AS und maxLength vor und nach dem Vorgang.

Die API kennt den Zusammenhang bereits

ARINs RESTful-API-Leitfaden für RPKI beschreibt einen einheitlichen, organisationsbezogenen Aufruf zum Anlegen, Ändern und Löschen von ROAs. ASPA-Änderungen lassen sich in dieselbe Transaktion aufnehmen; alle Bestandteile sind gemeinsam erfolgreich oder scheitern gemeinsam. Der Payload enthält eine Liste zu löschender und eine Liste anzulegender ROAs.

Die Atomarität schützt vor halben Ersetzungen. Ein altes ROA soll nicht verschwinden, wenn das vorgesehene neue Objekt nicht angelegt werden kann. Zugleich ist die Transaktion der natürliche Nachweisgegenstand: ARIN kennt den gemeinsamen Einreicher, die zusammengehörige Absicht und das Gesamtergebnis.

Eine Meldung je Objekt löst diesen Zusammenhang wieder auf. Ein völliges Abschalten lässt ihn nur im Konto des Handelnden zurück. Eine Transaktionszusammenfassung kann beides vermeiden.

Das Change Log ist ein ernst zu nehmender Bestand

Seit September 2025 verfügt ARIN Online über ein ROA Change Log. Nach der aktuellen Dokumentation deckt es 365 Tage ab. Es zeigt Zeitstempel, Added oder Removed, die Quelle Web User, API User oder ARIN System, Origin AS, Präfix, maxLength und den Namen des ausführenden ARIN-Online-Nutzers. Mehr als 100 Einträge werden seitenweise angezeigt. Eine vollständige CSV-Datei kann per Ticket angefordert und später heruntergeladen werden.

Das ist substanzielle retrospektive Evidenz. Die geprüften Quellen zeigen nicht, dass dieses Protokoll falsch, durch gewöhnliche Nutzer veränderbar oder für Berechtigte unzugänglich wäre. Eine faire Analyse muss diese vorhandene Stärke an den Anfang stellen.

Protokoll und Push-Nachricht beantworten dennoch verschiedene Fragen. Das Protokoll wartet auf jemanden, der sich anmeldet und nachsieht. Die Benachrichtigung unterbricht einen getrennt verwalteten Empfänger und fordert zur Prüfung auf. Ist das ausführende Konto selbst Teil des Problems, ist diese Unabhängigkeit wichtig. Zerfällt die Nachricht in tausende Einzelteile, bleibt die Unabhängigkeit, aber der Zusammenhang geht verloren.

Ein dauerhafter Änderungsnachweis pro Transaktion

Für jede bestätigte Transaktion genügt ein zusammenhängender, geschützter Datensatz.

Feld Prüfbare Aussage
Transaktions-ID und Abschlusszeit Welcher Auftrag wann verbindlich wurde
Organisation und geschützte Akteursklasse Unter welcher Befugnis gehandelt wurde, ohne private Daten offenzulegen
Vorgangsmischung Anlegen, Ersetzen, Löschen sowie verbundene ROA-, ASPA- oder IRR-Schritte
Berechtigung vorher und nachher Welche Präfix-, Origin-AS- und maxLength-Bindungen sich änderten
Atomarer Ausgang Gesamterfolg, Gesamtfehler oder nicht bestätigter Zustand
Beobachtete Veröffentlichung Ob der neue Zustand im Repository gesehen wurde oder die Beobachtung aussteht
Unabhängiger Empfänger und Zustellung Welcher getrennte Sicherheitskanal die Zusammenfassung erhielt
Korrekturverweis Welcher spätere Vorgang die Änderung ersetzt oder zurücknimmt

Der Name des Mitarbeiters und interne Kontaktlisten müssen nicht öffentlich werden. Die öffentliche ROA-Berechtigung und das geschützte Organisationsprotokoll sind verschiedene Ebenen. ARIN kann einer unabhängig verwalteten Routing-Sicherheitsstelle eine begrenzte Zusammenfassung zustellen und persönliche Einzelheiten im geschützten Protokoll belassen.

Einstellungen bleiben sinnvoll. Ein POC kann Objektdetails wünschen, ein anderer nur eine E-Mail je Transaktion; ein NOC kann einen Webhook verwenden. Dringende Korrekturen dürfen nicht auf die Zustimmung sämtlicher Empfänger warten. Benachrichtigung ist keine Autorisierung, Empfangsbestätigung kein Vetorecht.

Der unverzichtbare Kern ist schmal: Eine Komfortoption darf redundante E-Mails abstellen, aber nicht zugleich den dauerhaften Nachweis und jedes unabhängig verwaltete Signal einer wesentlichen Änderung beseitigen.

Was die Unterlagen nicht belegen

Es gibt in den zitierten Quellen keinen Vorfall mit 40.000 Löschungen, kein kompromittiertes Konto, keine gescheiterte Benachrichtigung und keinen nachgewiesenen Routenausfall. ACSP 2025.6 wartet auf Umsetzung; die Schließung von 2026.6 belegt keine Auslieferung. Ein Mangel des Change Log ist nicht nachgewiesen. Auch schreibt ARIN den Netzen nicht vor, eine Invalid-Route abzulehnen.

Die belegte Aussage ist enger. ARIN besitzt eine atomare Transaktionsgrenze und ein detailliertes 365-Tage-Protokoll. Die aktive Warnung folgt aber vor allem der Löschung, während die öffentlichen Verbesserungswünsche zwischen mehr Konfiguration und völliger Mail-Unterdrückung stehen. Die Umstellung vom Objekt auf die Transaktion schließt diese Lücke, ohne ARIN zusätzliche Entscheidungsmacht über Routing zu geben.

Quellen