Zusammenfassung

  • Laut aktuellem ARIN-Leitfaden darf ein ROA einen optionalen Namen tragen; für ARIN Online ist dagegen nur die Suche nach Präfix oder ASN dokumentiert.
  • ACSP-Vorschlag 2024.14 verlangte eine Namenssuche. ARIN nannte sie im August 2024 nützlich, stellte sie zur Priorisierung in die RPKI-Verbesserungsliste und führt sie weiterhin als Open.
  • Die RPKI-REST-Schnittstelle verarbeitet den Namen beim Anlegen und bei der Ausgabe. Berechtigte Teams können daher die Organisationsliste abrufen und lokal filtern.
  • Der Name sollte ein privater, veränderlicher Index bleiben. Änderungen müssen über einen stabilen ROA-Handle sowie Präfix und ASN bestätigt werden.

Ein Merkmal zum Wiedererkennen, aber nicht zum Wiederfinden

Präfix, maximale Länge und Origin AS sagen, was autorisiert wird. Der Name erfüllt eine andere Aufgabe. Er kann einen Kunden, eine Migration oder ein Projekt bezeichnen und damit mehrere technische Koordinaten unter einem betrieblichen Zweck zusammenfassen.

ARINs Leitfaden zu Route Origin Authorizations führt diesen optionalen Namen ausdrücklich auf. Im Abschnitt über ARIN Online heißt es dann, die ROAs einer Organisation ließen sich nach einem bestimmten Präfix oder ASN durchsuchen. Der Name taucht als Suchschlüssel nicht auf. Seine Eingabe ist Teil des Produkts, seine Wiederverwendung in der dokumentierten Oberfläche nicht.

Genau dort setzt ACSP 2024.14 an. Der am 23. August 2024 eingereichte Vorschlag fordert, ROAs einer Organisation zusätzlich nach Namen zu suchen, damit sich alle Datensätze eines Kunden oder Projekts auffinden lassen. ARIN antwortete am 28. August, eine solche Funktion würde die bestehenden Suchmöglichkeiten sinnvoll erweitern. Sie werde in die Liste der RPKI-Verbesserungen aufgenommen, müsse noch priorisiert werden und der Vorschlag bleibe bis zu Entwicklung und Bereitstellung offen.

Die für diesen Beitrag gesicherten Seiten zeigen den Eintrag weiterhin als Open. Daraus folgt weder ein verfehlter Termin — ARIN nannte keinen — noch der sichere Nachweis, dass keine neue oder undokumentierte Funktion in einem authentifizierten Konto existiert. Für diese Recherche wurde kein Konto verwendet. Belegt ist allein die öffentlich sichtbare Differenz zwischen dem gespeicherten Namensfeld und den beschriebenen Suchschlüsseln.

Der API-Umweg ist eine ernsthafte Alternative

Die stärkste Verteidigung liefert die REST-Dokumentation. Im Beispiel für die ROA-Erstellung steht ein name-Element. Die ROA Spec Payload gibt den Namen zurück. Der Listenabruf ist auf die Kennung einer Organisation zugeschnitten. Ein berechtigtes Team kann deshalb alle Datensätze abrufen und die Namen im eigenen Werkzeug filtern.

Das kann völlig ausreichen. Präfix und ASN sind die eigentlichen Koordinaten der Autorisierung. Sie sind eindeutiger als ein Projektkürzel und zwingen vor einer Änderung zur technischen Kontrolle. Wer den Bestand bereits per API automatisiert, braucht womöglich keinen weiteren Web-Filter.

Auch Vertraulichkeit spricht für Zurückhaltung. Namen können Kunden, interne Programme oder sensible Standorte verraten. Eine Suche außerhalb der authentifizierten Organisation wäre fehl am Platz. Innerhalb des Kontos stellen unscharfe Treffer Fragen nach Groß- und Kleinschreibung, Unicode-Normalisierung, Dubletten und Umbenennungen. Präfix- und ASN-Suche ist nicht allein deshalb mangelhaft, weil sie diese Semantik meidet.

Der Umweg bleibt jedoch etwas anderes als ein einheitlicher Produktvertrag. Dokumentiert ist der vollständige Organisationsabruf, kein serverseitiger Namensfilter. Jede Organisation verlegt die Regeln damit in ein Skript, eine Tabelle oder ein internes Verfahren. ARIN standardisiert die Speicherung des Namens, aber nicht seine Verwendung als Index.

Die Auswirkung ist nüchtern zu beschreiben. Es gibt hier keinen Beleg für einen Ausfall, eine falsche Autorisierung, ein Hijacking oder eine tatsächlich fehlerhafte Auswahl. Wenn ein Projekt mehrere Präfixe oder Origin-ASNs umfasst, soll der Name gerade die Verbindung ausdrücken, die in den Koordinaten fehlt. Ohne passende Suche muss ein Mitarbeiter die Koordinaten kennen, den gesamten Bestand durchsehen oder eine zweite Zuordnung pflegen. Das vergrößert die Auswahlfläche vor einer Änderung, nicht den kryptografischen Inhalt des ROA.

Verwaltungsname und signiertes Objekt sind verschiedene Beweismittel

Hinter dem Wort ROA stehen mehrere Zustände: der von ARIN verwaltete Datensatz, das nach RFC 6482 signierte Objekt, dessen Veröffentlichung im RPKI-Repository, die Sicht eines Validators, eine beobachtete BGP-Ankündigung und schließlich die Entscheidung eines Netzes, wie es den Validierungszustand verwendet.

Die Syntax RouteOriginAttestation enthält Version, AS-Kennung und IP-Adressblöcke. Einen beschreibenden Namen kennt sie nicht. ARIN weist zudem darauf hin, dass der aktive Zustand mit einem RPKI-Validator und dem Repository geprüft werden muss. Ein Treffer namens „Kundenmigration-West“ beweist daher weder Veröffentlichung noch Validator-Sicht, passende Ankündigung oder Akzeptanz durch ein Netz.

Diese Trennung ist die Voraussetzung für eine sichere Verbesserung. Der Name darf privat, organisationsgebunden und veränderlich bleiben. Ein technischer Handle muss den Datensatz dauerhaft identifizieren. Präfix und ASN müssen vor der Aktion sichtbar sein.

Namenssuche braucht Regeln und einen stabilen Handle

Zunächst muss der Geltungsbereich auf die authentifizierte Organisation beschränkt werden. Danach sind exakte, beginnende oder enthaltene Treffer, Groß- und Kleinschreibung, Unicode, leere Namen, Dubletten und frühere Namen festzulegen.

Jeder Treffer sollte neben dem Label einen stabilen ROA-Handle, Origin AS, Präfix, maximale Länge und Zustand ausgeben. Löschen oder Ändern darf erst nach Bestätigung des Handles und der Netzkoordinaten möglich sein. Der Name findet Kandidaten; er identifiziert das Ziel nicht endgültig.

Auch die Paginierung gehört zum Vertrag. Verändert sich der Bestand zwischen zwei Seiten, können Einträge fehlen oder doppelt erscheinen. Ein Snapshot und ein Cursor vermeiden das. Ein kleiner Abfragebeleg könnte Organisationsbereich, Hash der normalisierten Suchanfrage statt des sensiblen Textes, Abgleichsmodus, Snapshot-Zeit, Trefferzahl, zurückgegebene Handles und den nächsten Cursor festhalten.

Dieser Beleg wäre nicht öffentlich. Er soll nachvollziehbar machen, welche stabilen Objekte vor einer folgenreichen Änderung angezeigt wurden, ohne Kunden- oder Projektnamen offenzulegen. ACSP 2024.14 verlangt damit keine neue Form von Routing-Autorität. Es verlangt einen vollständigen Lebenszyklus für ein Verwaltungsfeld, das ARIN bereits annimmt und ausgibt.

Quellen