So funktioniert die Resource Public Key Infrastructure
Verfolgen Sie eine RPKI-Autorisierung vom Adressinhaber bis zum Router und erfahren Sie, warum Lu Heng für einen verlässlichen Dienst mit austauschbarer Verwaltung eintritt.
Verifikation braucht gepflegte Nachweise: Zertifikate, Berechtigungen und Veröffentlichungssysteme müssen auch dann zusammenpassen, wenn sich Netzwerke verändern.
Sie verlagern einen Dienst in ein neues Netzwerk. Die Server funktionieren einwandfrei, die Adressen haben sich nicht geändert, und doch können manche Besucher den Dienst nicht mehr erreichen. Eine mögliche Ursache ist überraschend unscheinbar: Die Routing-Einträge des Internets autorisieren noch immer das alte Netzwerk, diese Adressen anzukündigen.
RPKI macht aus dieser Berechtigung etwas, das andere Netzwerke überprüfen können. Hier erfahren Sie, wie sie vom Adressinhaber zum Router gelangt – und warum Lu Heng dafür eintritt, dass der Betrieb dieser Infrastruktur niemals davon abhängen darf, eine bestimmte Verwaltungsinstanz an der Macht zu halten. Einen kürzeren Einstieg bietet der Beitrag darüber, was RPKI schützt.
1. Feststellen, wer Autorisierungen für die Adressen erteilen darf
Eine Gruppe von IP-Adressen wird als Präfix bezeichnet. Ein Netzwerk, das dieses Präfix ankündigt, identifiziert sich durch die Nummer seines autonomen Systems, kurz ASN. RPKI, die Resource Public Key Infrastructure, nutzt Zertifikate, um festzustellen, wer Autorisierungen für bestimmte Adressbereiche ausstellen darf.
Diese Zertifikate bilden eine Kette, die bis zu einer vertrauenswürdigen Wurzelinstanz zurückreicht. Die Hierarchie folgt der Zuteilung von Internet-Nummernressourcen, wie sie in RFC 6480 beschrieben ist. Sie liefert Nachweise über Ressourcen innerhalb dieses Systems; sie verleiht einer Zertifizierungsstelle kein politisches Mandat über die Menschen, die das Internet nutzen.
2. Eine signierte Berechtigung veröffentlichen
Der Adressinhaber veröffentlicht eine Route Origin Authorisation, kurz ROA. Ihre Aussage ist klar umrissen: Diese ASN darf dieses Präfix als Ursprung ankündigen. Ursprung zu sein bedeutet, das Netzwerk am Anfang der angekündigten Route zu sein – nicht jedes Netzwerk, das den Datenverkehr anschließend transportiert.
Eine ROA kann außerdem eine maximale Präfixlänge festlegen: also, wie weit der Adressbereich in kleinere, separat angekündigte Bereiche aufgeteilt werden darf. Ohne diese optionale Angabe erlaubt sie nur die angegebene Präfixlänge. So wird verhindert, dass aus einer „Berechtigung für diesen Bereich“ stillschweigend eine Berechtigung für jede denkbare Unterteilung wird. RFC 9582 definiert den signierten Datensatz.
3. Veröffentlichte Datensätze in geprüfte Daten überführen
Die signierten Datensätze werden in Veröffentlichungsrepositorys bereitgestellt. Validierungssoftware sammelt sie und prüft die Zertifikatskette, die Signaturen, die Ablauf- und Widerrufsinformationen sowie die Manifeste, die die veröffentlichten Objekte beschreiben. Eine lesbare Datei allein reicht nicht aus: Auch die zugehörigen Nachweise müssen die Validierung bestehen.
Der Validator erzeugt nutzbare Autorisierungsdaten, häufig als Validated ROA Payloads oder VRPs bezeichnet. Sie enthalten das Präfix, die erlaubte Ursprungs-ASN und die maximale Länge. Router erhalten die Ergebnisse von einem vertrauenswürdigen Cache über das in RFC 8210 beschriebene RPKI-to-Router-Protokoll. Sie fragen nicht jedes Mal bei einer Registry um Erlaubnis, wenn jemand eine Seite öffnet.
4. Die Route mit der Berechtigung abgleichen
BGP ist das Protokoll, über das Netzwerke Routen ankündigen. Ein empfangender Router gleicht Präfix und Ursprungs-ASN einer Route mit den validierten Autorisierungen ab. Das ist die Route Origin Validation, kurz ROV.
Valid: Eine Autorisierung, die das Präfix abdeckt, erlaubt sowohl den Ursprung als auch die Präfixlänge. Invalid: Es gibt Autorisierungen, die das Präfix abdecken, aber keine erlaubt diese Kombination. NotFound: Keine Autorisierung deckt das Präfix ab. Das sind Ergebnisse eines Abgleichs, keine Urteile über die Absichten eines Beteiligten. Der Betreiber entscheidet, wie er sie in seiner Routing-Richtlinie verwendet. Siehe RFC 6811.
Zurück zum Umzug des Dienstes: Ist noch die alte ASN autorisiert, die neue aber nicht, kann die neue Ankündigung als Invalid eingestuft werden. Netzwerke, die Invalid-Routen filtern, können sie zurückweisen. Die Lösung besteht darin, die Änderung der Autorisierung mit dem Umzug abzustimmen, einschließlich eines möglichen Zeitraums, in dem beide Netzwerke eine Berechtigung benötigen. Einwandfrei funktionierende Server allein garantieren keine Erreichbarkeit. RFC 7115 behandelt betriebliche Vorsichtsmaßnahmen.
5. Die gesamte Kette funktionsfähig halten
Die Ursprungsvalidierung hilft, falsche Angaben zum Routenursprung zurückzuweisen. Sie überprüft nicht jede Zwischenstation, verschlüsselt keinen Datenverkehr und erkennt nicht jedes Route Leak. Bei einem Route Leak kann der autorisierte Ursprung erhalten bleiben. Weitere Schutzmaßnahmen für das Routing bleiben notwendig.
Auch die Nachweise müssen gepflegt werden. Zertifikate laufen ab; Berechtigungen und Veröffentlichungsdaten ändern sich. Das Entfernen einer ROA muss nicht sofort einen Ausfall verursachen: Das spätere Validierungsergebnis hängt von anderen verfügbaren Datensätzen ab, die Folgen für das Routing von der lokalen Richtlinie. RFC 8211 untersucht, wie sich Fehler oder schädliche Handlungen von Zertifizierungsstellen und Repository-Betreibern auf das System auswirken können.
Lu Hengs Vorschlag: den Dienst erhalten, die Verwaltungsinstanz ersetzen
In Notiz 70 stellt Lu Heng einen vertrauten Schluss infrage: Weil ein Registrierungsdienst unverzichtbar ist, müsse auch sein gegenwärtiger Betreiber unersetzlich sein. Netzwerke brauchen korrekte Einträge und funktionierende Sicherheit. Daraus entsteht kein dauerhaftes Recht einer Institution, diese zu kontrollieren.
Sein Gegenvorschlag macht Kontinuität zu einer Eigenschaft des Systems: unabhängig prüfbare Einträge, eine erprobte Übergabe an einen qualifizierten Nachfolger und eine Möglichkeit, die Verwaltung zu verlagern, ohne Netzwerke zu einem Adresswechsel zu zwingen. Er erkennt ausdrücklich an, dass sich RPKI nicht durch das Kopieren eines Verzeichnisses übertragen lässt. Schlüssel, Zertifikate, Veröffentlichung und Vertrauen müssen während des gesamten Übergangs zusammenpassen.
Das ist eine Gestaltungsanforderung, für die er eintritt, keine Behauptung, eine solche Portabilität sei bereits überall verfügbar. Sie berücksichtigt beide Seiten des Problems: Ein unachtsamer Austausch könnte die Verifikation stören; ein unersetzlicher Gatekeeper kann diese Abhängigkeit in Macht verwandeln. Die Verlässlichkeit des Dienstes und die Austauschbarkeit seiner Verwaltungsinstanz müssen gemeinsam gestaltet werden.
Warum diese Fähigkeit vor einer Krise schaffen?
Wenn ein Streit die Zertifikatskette erreicht, kann er Menschen weit über die streitenden Parteien hinaus betreffen. Die Kunden haben sich den Konflikt nicht ausgesucht, tragen aber möglicherweise die Kosten unterbrochener Verbindungen. Ein Nachfolgeverfahren, das erst während eines Ausfalls improvisiert wird, kommt bereits zu spät, um sie vor dieser Unsicherheit zu schützen.
Lu Heng plädiert dafür, Kontinuität und das Recht auf einen Ausstieg im Voraus abzusichern und zu verhindern, dass Verwaltungsstreitigkeiten zur Waffe gegen funktionierende Netzwerke werden. Seine vollständige Argumentation finden Sie in Notiz 70: Das Register schützen, nicht den Gatekeeper.