Zusammenfassung

  • Nach ARINs Datenbankleitfaden kann ein Resource Tech POC direkt für eine Ressource zuständig sein; der Routing POC verantwortet RPKI- und IRR-Informationen dagegen auf Organisationsebene.
  • Der am 20. August 2026 eingereichte Vorschlag 2026.10 verlangt, dass Ressourcenkontakte nur für ihre verknüpften Ressourcen handeln dürfen.
  • Öffentlich ist bisher lediglich Confirmed vermerkt. Es fehlen ARINs Bewertung, ein Termin und ein Berechtigungskonzept; die behaupteten Verzögerungen sind nicht vermessen.
  • Eine belastbare Lösung muss Präfixe, Objektklassen und einzelne Handlungen begrenzen sowie Erteilung, Laufzeit, Widerruf, besondere Freigaben und den genutzten Berechtigungsweg protokollieren.

Die Ressource ist fein genug erfasst, die Handlung noch nicht

ARIN beschreibt technische Kontakte nicht als austauschbare Bezeichnungen. Der Organizational Tech POC verwaltet eine Org ID und deren Ressourcen. Ein optionaler Resource Tech POC kann unmittelbar an einen Adressblock, eine Zuteilung oder eine ASN geknüpft werden. Er darf Ressourcennamen und öffentliche Kommentare ändern, weitere Ressourcenkontakte zuordnen und je nach Objekt Nameserver oder DS-Einträge pflegen.

Beim Routing POC wechselt die Ebene. Dieser ist für IRR und RPKI-Zertifizierungsinformationen der Organisation zuständig. Ein Konzern mit mehreren Netzen kann daher eine Person sichtbar für einen bestimmten Block einsetzen, ohne ihr den operativen Zugang zu den dazugehörigen Routing-Sicherheitsobjekten zu geben.

Die aktuellen Werkzeuge folgen der Org ID. Im Web wählt der Nutzer Manage RPKI für eine Organisation. Die REST-Transaktion zum Erstellen und Löschen von ROAs läuft über /rest/rpki/ORGHANDLE. Mehrere ROA- und ASPA-Änderungen können dabei atomar gebündelt werden. Auch die IRR-API benennt die Organisation als Maintainer und verwendet deren Admin-, Tech- oder Routing-POCs.

Eine solche Zentralisierung hat einen vernünftigen Zweck. Wer nur einen Block betreut, soll nicht versehentlich andere Präfixe der Organisation verändern. Sie erzeugt aber einen Übergabepunkt, wenn die alltägliche Betriebsverantwortung bereits ressourcenweise verteilt ist.

Confirmed ist ein Eingangsbeleg

Nathanael Jean-Francois begründet den Vorschlag damit, dass Ressourcentechniker für ROA-Erstellung und -Löschung den organisatorischen Routing POC einschalten müssen. Diese Abhängigkeit könne die Störungsbehebung und Bereitstellung neuer Dienste verzögern.

Die Veröffentlichung enthält dafür keine Fallzahlen, Wartezeiten, betroffenen Präfixe oder Routing-Auswirkungen. Die Aussagen sind die Begründung des Einreichers, keine Feststellung ARINs. Unter Tracking Information steht noch keine Antwort. Angegeben sind nur der 20. August, kein Zeitrahmen und der Status Confirmed.

Der ACSP-Prozess trennt die Schritte ausdrücklich. ARIN bestätigt den Eingang eines gültigen Vorschlags sofort. Erst danach bewertet das Personal ihn innerhalb von zehn Arbeitstagen. Später kann der Antrag geschlossen, an Board oder Advisory Council verwiesen, als umsetzbar eingestuft oder zur Konsultation gestellt werden. Eine Eingangsbestätigung ersetzt keine dieser Entscheidungen.

Damit wurde bislang weder ein Recht freigeschaltet noch ein Produktplan zugesagt. Diese Grenze verhindert, dass Betreiber in einem Notfall auf eine nur veröffentlichte, aber nicht vorhandene Berechtigung vertrauen.

Ein enger Auftrag braucht eine enge Capability

Die naheliegende Abkürzung wäre, jedem Resource Tech POC sämtliche Routing-Poc-Rechte für die Org ID zu geben. Das würde den menschlichen Umweg verkürzen, aber den möglichen Schaden auf alle Ressourcen ausweiten.

Die bestehende Ressourcenzuordnung enthält gerade die gegenteilige Information: Dieser Kontakt ist für dieses Objekt zuständig. Sie rechtfertigt nicht automatisch den Zugriff auf andere Präfixe, ASNs, ASPAs oder die globale IRR-Auto-Manager-Einstellung.

Eine delegierte Capability sollte deshalb konkrete NET handles oder Präfixbereiche nennen. ROA, ASPA und IRR müssen getrennt sein; ebenso Erstellen, Ändern und Löschen. Zu speichern sind der erteilende Kontakt und dessen Rolle, Beginn und Ablauf, Widerruf und Notfallsperre. Massenlöschungen oder Reichweitenerweiterungen können eine zweite Freigabe erfordern, ohne jede Routineänderung auszubremsen.

Auch die Randfälle müssen deterministisch sein. Eine Berechtigung für ein Child-Präfix öffnet nicht den Parent. Beim Wechsel der Org ID verfallen alte Gewährungen. API-Schlüssel erhalten nie mehr als das aktuell wirksame Recht ihres Kontos. Enthält ein Batch auch nur ein unzulässiges Objekt, muss die gesamte Transaktion scheitern statt einen Teilzustand zu hinterlassen.

ARINs ROA-Änderungsprotokoll erfasst bereits Zeitpunkt, Vorgang, Web- oder API-Quelle, Origin AS, Präfix, maximale Länge und Nutzer. Für ressourcenbezogene Delegation fehlt die Autoritätsquelle: Welche zu diesem Zeitpunkt aktive Gewährung erlaubte genau diesem Nutzer genau diese Änderung?

Die Beweisgrenze bleibt eng

Die Quellen belegen keinen durch ARIN verursachten Routing-Vorfall und keine konkrete verspätete ROA-Korrektur. Sie zählen weder betroffene Organisationen noch Resource Tech POCs. Sie zeigen auch nicht, dass jeder dieser Kontakte allein löschen können sollte.

Ein sichtbarer POC-Eintrag ist zudem noch keine vollständige Authentisierung. Kontoverknüpfung, Vertragsabdeckung, RPKI-Berechtigung, Zertifikatszustand und interne Freigaben bleiben Teil der Kette.

Die Nachricht lautet daher nicht, ARIN habe ein Problem anerkannt oder eine Lösung beschlossen. ARIN hat einen Antrag registriert, der zwei bereits dokumentierte Ebenen gegeneinander hält: technische Verantwortung je Ressource und Routing-Sicherheitsmacht je Organisation. Eine belastbare Antwort muss beide Ebenen verbinden, ohne die kleinere zu verschlucken.

Quellen