Summary

  • Die RPKI-Management-API von RIPE NCC schließt Zertifizierungsstellen für gesponserte PI- und Legacy-Ressourcen ausdrücklich aus. Nicht-LIR-Organisationen dürfen ihre ROAs im Dashboard verwalten.
  • RPKI-Leiter Tim Bruijnzeels kündigte SSO-gebundene Schlüssel mit einem Jahr Laufzeit an, die Endnutzern den API-Zugang eröffnen sollen. Die Quartalsplanung nennt keinen Freischalttermin.

Ein ROA lässt sich per Maus pflegen. Wird dieselbe Änderung zum Teil eines Skripts, entscheidet bei RIPE NCC plötzlich eine andere Zugangsregel. Der Unterschied ist nicht technisch klein: Die API ist die Schnittstelle, über die wiederholbare Änderungen an einer Routing-Autorisierung möglich werden.

In der API-Dokumentation steht der Ausschluss ohne Umschweife. Zertifizierungsstellen für gesponserte PI- und Legacy-Ressourcen können die RPKI Management API nicht verwenden. Der bisherige Zugangsschlüssel wird mit Administratorrechten im LIR Portal erzeugt. Über die API lassen sich ROAs anlegen, beobachtete BGP-Ankündigungen für zertifizierten Adressraum abfragen und Warnungen einrichten. Ein ROA benennt den AS-Ursprung, der für ein Präfix autorisiert ist. Wer solche Einträge regelmäßig pflegt, hat einen konkreten Grund, die Änderung in ein kontrolliertes Verfahren einzubauen.

Die Zugangsübersicht beschreibt für das Dashboard eine breitere Nutzergruppe: Auch Organisationen ohne LIR-Status mit gesponserten Ressourcen können dort ROAs verwalten. Die RPKI-Seite nennt Endnutzer und betreuende LIRs als mögliche Antragsteller für PI-Zertifikate; Legacy-Inhaber können Zertifikate für Legacy-Endnutzerressourcen beantragen. Das Zertifikat ist erreichbar, der API-Pfad nicht. Der Mitgliedsstatus bestimmt damit derzeit, wer dieselbe Aufgabe automatisieren darf.

Auf der RIPE 93 legte RPKI-Leiter Tim Bruijnzeels die Schwäche des alten Schlüssels offen. Er sei im Wesentlichen ein gemeinsames Geheimnis ohne Ablaufdatum, werde im LIR Portal eingerichtet und stehe LIRs zur Verfügung. PI- und Legacy-Endnutzer mit betreuendem LIR erhalten keinen API-Zugang. Die Nachfolgearchitektur soll Schlüssel an SSO-Konten binden und ihre Laufzeit auf ein Jahr begrenzen. Bruijnzeels nannte ausdrücklich einen weiteren Nutzen: Endnutzer könnten damit endlich die API verwenden. Das ist eine Änderung des Berechtigtenkreises, keine bloße Modernisierung des Logins.

Der RPKI-Quartalsplan führt OIDC und neue API-Schlüssel als laufende Arbeit und sieht eine Schlüsselverwaltung im Dashboard vor. Der Plan für Business Applications bezeichnet den RPKI-Management-Schlüssel als letzten alten API-Schlüssel im LIR Portal. Die Funktion dort soll bis Jahresende auslaufen. Aus diesen Aussagen lässt sich ein Ziel für das alte Portal ablesen, aber kein Startdatum für den API-Zugriff einer gesponserten Zertifizierungsstelle.

Gerade diese Lücke ist der Prüfstein. Ein ablaufender Schlüssel ist sicherer zu verwalten als ein Geheimnis ohne Verfallsdatum. Eine neue Oberfläche kann seine Ausgabe vereinfachen. Der Ressourceninhaber braucht zusätzlich eine dokumentierte Berechtigung für genau seine Zertifizierungsstelle und eine akzeptierte API-Operation. Erst wenn ein PI- oder Legacy-Inhaber so einen ROA ändern kann, ist die angekündigte Zugangserweiterung tatsächlich angekommen. Bis dahin sind Schlüsselumzug und Zugangsöffnung zwei getrennte Projekte.