Zusammenfassung

  • ARIN unterscheidet einfache IRR-Objekte aus Online oder XML REST von fortgeschrittenen Objekten aus RPSL REST oder der früheren IRR-email-Migration. Der Erzeugungsweg bestimmt die später zulässigen Verwaltungswege.
  • Ein migriertes Objekt darf in ARIN Online angesehen und gelöscht, dort aber nicht bearbeitet werden. Löschen und anschließendes Neuerzeugen machen aus der Änderung einen Wechsel in eine andere Herkunftsklasse.
  • Die aktuelle Übersicht und die Implementierungshinweise widersprechen sich bei RPSL-REST-Rechten für Online-Objekte. Ohne authentifizierten, ausreichend breiten Test ist das ein Dokumentationsbefund und keine Aussage über das Laufzeitverhalten.
  • Ein schmaler Umwandlungsbeleg könnte Vorher-Hash, Klasse, Berechtigungsversion, Rollenart, Kanal, Ergebnis und Nachfolger-Hash verbinden, ohne API-Schlüssel, Beschäftigtennamen oder private Netzdaten offenzulegen.

Eine Korrektur wird zur Entfernung

ARINs Nutzerleitfaden beschreibt einen ungewöhnlichen Bedienzustand. Ein aus dem alten IRR-email-System übernommenes Objekt erscheint in ARIN Online. Berechtigte können es aufrufen und entfernen. Zum Bearbeiten müssen sie dagegen REST verwenden. Wer es künftig über die Weboberfläche verwalten will, soll es laut Implementierungshinweisen löschen und neu anlegen. ARIN IRR User Guide

Für den Menschen ist das womöglich eine Korrektur an einem Attribut. Für das Register sind es zwei getrennte Zustandsänderungen. Zuerst verschwindet die bestehende Aussage, danach wird eine neue eingereicht. Selbst wenn Präfix, Ursprungs-AS und alle sichtbaren Felder identisch bleiben, stammt der Nachfolger nun aus Online. Die migrationsbedingte Klasse des Vorgängers ist nicht dieselbe.

Die untersuchten Quellen belegen keinen Verlust, keine falsche Filterung und keine Routingstörung. Es wurde weder ein Konto noch ein API-Schlüssel oder reales Objekt getestet. Auch NRTM und BGP wurden nicht beobachtet. Gegenstand ist die veröffentlichte Berechtigungsarchitektur, nicht ein Produktionsvorfall.

Gerade diese Begrenzung erlaubt eine faire Verteidigung. Ein Webformular kann möglicherweise nicht jede RPSL-Eigenschaft verlustfrei abbilden. Eine scheinbar lokale Bearbeitung könnte unsichtbare Attribute normalisieren oder entfernen. In diesem Fall ist die verweigerte Bearbeitung sicherer als eine nur teilweise treue Oberfläche.

Die angemessene Forderung lautet deshalb nicht, überall einen Editierknopf einzubauen. Der Betreiber sollte erkennen können, warum der Kanal ausgeschlossen ist, die kanonische Vorform sichern, den geplanten Nachfolger vorab validieren und die beiden Objektlinien nach der Umstellung nachvollziehbar verbinden.

Die Klasse bewertet den Verwaltungsweg, nicht die Route

ARINs aktuelle Übersicht nennt Online- oder XML-REST-Objekte „simple“. Sie dürfen dort erstellt, gelesen, bearbeitet und gelöscht werden; die Tabelle weist ihnen keine RPSL-REST-Rechte zu. „Advanced“ sind Objekte aus RPSL REST oder der IRR-email-Migration. Sie haben die vier Rechte in RPSL REST, keine in XML REST und in Online lediglich Lesen und Löschen. ARIN IRR-Übersicht

Die Begriffe sind keine Gütestufen. Ein advanced Objekt ist nicht automatisch näher am gegenwärtigen Routing. Ein simple Objekt muss keine einfache Policy ausdrücken. Klassifiziert werden Erzeugung, Darstellung und Validierung.

ARIN erklärt zugleich, dass Abfragen unabhängig von der Klasse RPSL ausgeben. Diese Trennung ist sachgerecht. Ein Nutzer soll lesen, was ein route-, route6-, aut-num-, as-set- oder route-set-Objekt behauptet. Er benötigt weder den API-Schlüssel noch die Eingabemaske des Maintainers. Für die Änderungsprüfung bleibt hingegen wichtig, welche Berechtigung und welcher Parser den Zustand erzeugt haben.

RFC 2622 definiert die Routing Policy Specification Language als Sprache für Routing-Policy und IRR-Objekte. Sie strukturiert eine Registeraussage; sie misst nicht das aktuelle BGP. Ein syntaktisch korrektes Objekt belegt weder, dass die Route angekündigt wird, noch dass alle Netze sie akzeptieren oder für ihre Filter verwenden. RFC 2622

Die Herkunftsklasse ist damit Beweis über einen Registervorgang. Sie ist kein Ersatz für Beobachtung der Daten- oder Kontrollebene. Ein belastbarer Artikel muss diese beiden Wahrheiten nebeneinander halten.

Die Migrationsgrenze hat einen vernünftigen Zweck

Die Implementierungshinweise zeigen, dass die alte Mail-Welt nicht pauschal übernommen wurde. Migrierte Einträge wurden nach ARIN-Bezug und Validierung getrennt; ein Teil ging in den maßgeblichen Bestand, ein anderer nach ARIN-NONAUTH. Nach ARINs Darstellung bestanden die migrierten Objekte die strengere Validierung des neuen Systems und werden in der Oberfläche gekennzeichnet. Implementierungshinweise zu ARIN IRR Online

Das Kennzeichen bewahrt eine reale Herkunft. Eine erfolgreiche Migration macht ein altes Mailobjekt nicht rückwirkend zu einem Webobjekt. Die Information erklärt, warum zwei öffentlich ähnlich aussehende RPSL-Datensätze verschiedene Schreibwege haben.

Hinzu kommt ein unumkehrbarer Übergang: Sobald eine Organisation Web oder REST nutzt, wird ihr IRR-email-Änderungsweg dauerhaft abgeschaltet. Das kann konkurrierende Schreiber verhindern. Mail und API könnten unterschiedliche Zugangsdaten, Validatoren und Konfliktregeln verwenden. Mit dem Umstieg wird die aktive Kontrolle auf die moderne Oberfläche begrenzt.

Auch die Trennung der Kodierungen lässt sich verteidigen. XML, Formularfelder und RPSL haben nicht zwingend dieselbe Ausdrucksstärke oder Rundlaufstabilität. Kanalübergreifende Bearbeitung wäre nur dann sicher, wenn ARIN für alle unterstützten Objekttypen die semantische Gleichheit nachweisen kann.

Doch eine saubere Einbahnstraße braucht ein nachprüfbares Ende. Vor dem Löschen sollten Klasse, Sperrgrund und kanonisches Objekt sichtbar sein. Das Zielobjekt sollte validiert werden, bevor ein gültiger Zustand verschwindet. Nach der Annahme sollte eine Nachfolgerbeziehung zeigen, dass die Neuerzeugung zur beabsichtigten Umwandlung gehörte.

DELETE und POST erzeugen mehr Zwischenzustände als PUT

Der REST-Leitfaden unterscheidet GET, POST, PUT und DELETE. PUT verändert ein Objekt, DELETE entfernt es. RPSL- und XML-Nutzlasten unterliegen den jeweiligen Objektrechten. Auf Protokollebene bleiben Korrektur und Ersatz also unterschiedliche Handlungen, selbst wenn die Oberfläche beide als einen Arbeitsauftrag darstellt. ARIN IRR RESTful API

Eine Änderung am Platz lässt sich als Übergang eines dauerhaften Bezugs von einem kanonischen Hash zum nächsten festhalten. Die Folge aus Löschen und Erzeugen kann nach dem ersten Schritt enden. Der Nachfolger kann die Validierung verfehlen, verändert normalisiert werden oder erst später in einem Publikationsweg sichtbar werden.

Keiner dieser Fälle ist hier beobachtet. Die Quellen nennen weder Zahl und Anteil migrierter Objekte noch Umwandlungshäufigkeit, Laufzeiten oder NRTM-Serien eines Beispiels. Eine Lücke darf weder berechnet noch einem Filterkonsumenten zugeschrieben werden. Der Designunterschied bleibt dennoch: Zwei fehlbare Operationen benötigen eine andere Wiederherstellungs- und Nachweiskette als eine.

Manuelle Neuerfassung verschärft die Frage. Kommentare, Reihenfolgen oder Ausdrücke können sich ändern. Die aktuelle Validierung kann Korrekturen verlangen. Wird derselbe öffentliche Schlüssel wiederverwendet, sieht der Datensatz kontinuierlich aus, obwohl sich seine Klasse geändert hat. Bei einem neuen Schlüssel fehlt ohne Zusatzinformation die Nachfolgebeziehung.

Ein Supportticket oder Bildschirmfoto hilft den Beteiligten, ist aber kein dauerhaft prüfbarer Datensatz für spätere Maintainer oder Software. Eine Umwandlungskennung kann dagegen DELETE und POST zu einem Vorhaben verbinden und Erfolg, Ablehnung oder Korrektur jeweils als eigenes Ereignis erhalten.

Zwei aktuelle Seiten beantworten die RPSL-Frage verschieden

Die Übersichtstabelle weist simple Objekten keine RPSL-REST-Rechte zu. Die Implementierungshinweise sagen dagegen, dass in ARIN Online erzeugte Objekte per REST sowohl mit RPSL als auch XML angesehen, aktualisiert und gelöscht werden können. Die Seite nennt Aktualisierungen bis zum 17. Januar 2025.

Das ist ein sachlicher Widerspruch. Denkbar sind Unterschiede nach Version, Objekttyp oder Kontozustand; denkbar ist auch veraltete Dokumentation. Nichts davon ist belegt. Selbst ein erfolgreicher Test eines einzelnen route-Objekts würde nur diesen Fall beweisen.

Ein ARIN-Beitrag vom Februar 2021 ordnet die Einführung von REST und damals geplante Änderungen historisch ein. Heute liegt er im Vault, dessen Inhalte ARIN ausdrücklich als möglicherweise veraltet kennzeichnet. Er darf die aktuelle Berechtigungsfrage nicht entscheiden. ARIN Vault zur REST-Einführung

Abhilfe schafft eine einzige versionierte Matrix mit Gültigkeitsdatum: Klasse, Objekttyp, Operation, Kanal und Kodierung. Laufender Code ist die technische Wirklichkeit des beobachteten Falls; die Matrix ist das erklärte Unterstützungsversprechen. Weichen beide ab, muss der konkrete Request samt Response erhalten bleiben.

Bis ARIN die Texte angleicht oder ein klar abgegrenzter authentifizierter Test vorliegt, bleibt die Abweichung offen. Der Artikel behauptet weder, RPSL funktioniere für Online-Objekte, noch, es werde sicher abgewiesen.

Ein Herkunftsbeleg braucht keine Personenakte

Ein schmaler Beleg kann Objekttyp und öffentlichen Schlüssel, vorherige Klasse und Erzeugungsherkunft, Berechtigungsversion, kanonischen Vorher-Hash, Aktion, Rollenklasse, Kanal und Kodierung, Ergebnis, Nachher-Klasse und -Hash sowie die Verbindung zwischen Löschung und Neuerzeugung enthalten. Eine Publikationsbeobachtung oder NRTM-Serie kann ergänzt werden, wenn sie verlässlich bekannt ist.

API-Schlüssel, Namen einzelner Beschäftigter, interne Organisationsbeziehungen und private Topologie gehören nicht hinein. ARIN kann nur den Vorgang belegen, den es kontrolliert: Annahme, Ablehnung oder Entfernung einer Registeraussage über einen bestimmten Weg. Der Beleg sagt nicht, dass jeder Mirror synchronisiert, jeder Filter neu gebaut oder BGP dem Objekt gefolgt ist.

Der Nutzerleitfaden erlaubt Admin-, Tech- und Routing-POCs die IRR-Verwaltung, nicht aber Resource-POCs. Rollenberechtigung und Objektkanal sind zwei unabhängige Grenzen. Ein korrekt autorisierter Akteur kann wegen der Herkunft dennoch nicht in Online bearbeiten. Eine Prüfung sollte deshalb „wer“ und „in welcher Darstellung“ getrennt erfassen.

Die Quellen zeigen keinen schadhaften Datensatz. Sie zeigen, dass ARIN die Erzeugungsgeschichte als Teil künftiger Kontrolle bewahrt. Das kann die Integrität stärken. Sobald ein Werkzeugwechsel aber Löschen und Neubau verlangt, braucht dieselbe Integrität eine sichtbare Brücke zwischen den Zuständen.

Quellen

  1. ARIN: Internet Routing Registry – Übersicht
  2. ARIN: IRR User Guide
  3. ARIN: Implementierungshinweise zu IRR Online
  4. ARIN: IRR RESTful API
  5. ARIN Vault: historische REST-Einführung
  6. RFC 2622: Routing Policy Specification Language