Zusammenfassung

  • Beim Abschluss entfernt ARIN übertragene Ressourcen und zugehörige ROAs aus dem Zertifikat der Quelle; ROAs für verbleibende Ressourcen bleiben.
  • Das Zertifikat eines bereits registrierten Empfängers wird automatisch erweitert. Neue ROAs muss er selbst anlegen; ohne RPKI-Teilnahme muss er sich erst anmelden.

Bei einem Adresstransfer klingt „automatisch“ nach einer bequemen Übergabe: Der Registereintrag wechselt, das Zertifikat folgt, die Sache ist erledigt. ARINs RPKI-Regeln schneiden diesen Vorgang in zwei Teile. Die zertifizierten Ressourcen werden beim Transfer neu verteilt. Die neue Route Origin Authorization, kurz ROA, muss der Empfänger selbst anlegen. Ein Register kann die Adresse übertragen; es kann die geplante Netzarchitektur des Empfängers nicht erraten.

Der Ausgangspunkt ist ungewöhnlich klar. Sobald ARIN einen Transfer abschließt, verschwinden die übertragenen Ressourcen aus dem RPKI-Zertifikat der abgebenden Organisation. Die zugehörigen ROAs werden entfernt. Bleiben andere Ressourcen beim Abgeber, stellt ARIN dessen Zertifikat mit dem verbleibenden Bestand neu aus und erhält die dazugehörigen ROAs. Gehen alle vom Vertrag erfassten IP-Adressen und AS-Nummern fort, entfernt ARIN das bisherige Zertifikat ganz und löscht die entsprechenden ROAs aus dem Repository. Die alte Erlaubnis fährt also nicht als stilles Gepäck mit dem Adressblock weiter.

Auf der Empfängerseite läuft ein anderer Automat. Hat die Organisation bereits ein RPKI-Zertifikat bei ARIN, wird dessen Ressourcenliste um die neu erworbenen Adressen erweitert. ARIN beschreibt das als automatische Erneuerung. Die vorhandenen ROAs bleiben dabei, wie sie sind; die Erweiterung erzeugt keine neue ROA für die angekommenen Ressourcen. Wer bisher nicht an RPKI teilnimmt, muss sich anmelden. Der Transfer erledigt diese Anmeldung nicht.

Das ist mehr als eine Eigenheit des Formulars. Eine ROA nennt einen Präfix, die AS-Nummer seines erlaubten Ursprungs und die maximale Präfixlänge. Diese drei Angaben gehören zum Betrieb des Empfängers. ARIN kennt nach dem Transfer den neuen Ressourcenhalter, aber aus diesem Wissen folgt weder die richtige Origin-AS-Nummer noch die gewünschte Granularität von Ankündigungen. Würde das Register die neue ROA automatisch schreiben, müsste es diese Entscheidungen für den Betreiber treffen. Stattdessen schafft das Zertifikat die Befugnis; der Inhaber verwendet sie in einem zweiten Schritt.

An einem Übergabetag können deshalb drei beobachtbare Zustände auseinanderfallen: Die ROA des Abgebers ist weg, das Zertifikat eines bereits registrierten Empfängers umfasst den Block, die neue ROA des Empfängers fehlt noch. Wer nur die Zertifikatsansicht prüft, sieht einen echten Fortschritt und übersieht die fehlende Ursprungsfreigabe. Umgekehrt wäre es falsch, aus der Dokumentation ohne Messung einen konkreten Routingausfall abzuleiten. ARIN beschreibt hier den Ablauf, keinen benannten Vorfall.

Die Transferhinweise des Registers nennen zusätzlich IRR-Daten und Reverse DNS als Aufgaben. Beide zeigen, warum ein Ressourcenwechsel keine einzelne Zustandsänderung ist. Ein Vertrag, ein Zertifikat, eine ROA und betriebliche Daten haben unterschiedliche Verantwortliche und unterschiedliche Zeitpunkte. ARIN automatisiert die Umschreibung, die es anhand seines Registers belegen kann. Die Netzentscheidung verbleibt beim Empfänger. Gerade deshalb sollte der Kalender des Transfers nicht an der Zertifikatserweiterung enden.

Für eine konkrete Auswirkung bräuchte es einen datierten RPKI-Repository-Stand und eine zeitgleiche Beobachtung der Routenvalidierung. Für die Zuständigkeit genügt ARINs veröffentlichte Regel: Das neue Zertifikat kann von selbst ankommen; die neue ROA bestellt niemand automatisch dazu. Eine Übergabe mit zwei Uhren sollte auch mit zwei bestätigten Abschlusszeiten geführt werden.

ARIN