Die Resource Public Key Infrastructure (RPKI) spielt eine zentrale Rolle in der Sicherung des globalen Internet-Routings. Als hierarchisch strukturierte Zertifikatsinfrastruktur bindet die RPKI öffentliche Schlüssel an IP-Adressräume und Autonomous System Numbers (ASNs), wodurch eine verifizierbare Kontrolle über bestimmte Netzwerkressourcen ermöglicht wird. Mit der steigenden Bedeutung von Routing-Sicherheit gewinnt die Resilienz dieser Infrastruktur eine immer größere Relevanz. Es geht dabei um die Frage, wie die Betreiber die RPKI so gestalten, dass sie maximal verfügbar und performant bleibt, sowie robust gegenüber möglichen Störungen oder Angriffen ist. RPKI unterscheidet sich grundlegend von anderen essenziellen Internetinfrastrukturen wie dem Domain Name System (DNS).
Während DNS auf ein on-demand-Abfragemodell setzt, bei dem Anfragen für Namensauflösungen dynamisch durch eine Namensserver-Hierarchie geleitet werden, arbeitet die RPKI mit einem Pre-Provisioning-Verfahren. Netzwerkbetreiber laufen oder betreiben RPKI-Client-Instanzen, die regelmäßig die veröffentlichten RPKI-Objekte herunterladen, lokal zwischenspeichern und verifizieren. Die Ergebnisse werden in Form von Validierungsdaten oder Routenfiltern an BGP-Router weitergereicht, die so eingehende Routing-Updates überprüfen können. Dieses Vorgehen reduziert die Abhängigkeit von Echtzeitabfragen und erhöht die Fehlertoleranz, wenn beispielsweise kurzzeitige Verfügbarkeitsprobleme der RPKI-Publikationspunkte auftreten. Ein wichtiges Bindeglied in diesem Prozess sind die sogenannten Trust Anchor Locators (TALs).
Diese Objekte fungieren als Vertrauensanker, indem sie den Standort der selbstsignierten Root-Zertifikate der fünf Regional Internet Registries (RIRs) angeben. APNIC, ARIN, RIPE NCC, LACNIC und AFRINIC betreiben jeweils eine eigene RPKI-Hierarchie, welche die Vertrauensbasis bilden. Interessanterweise wird die Verfügbarkeit der TALs nicht durch inhaltsverteilende Netzwerke (Content Delivery Networks, CDN) oder Anycast-Lösungen abgesichert. Dennoch wird dies als unproblematisch beurteilt, da die TALs statische Konfigurationsdaten sind, die vor allem beim Start der RPKI-Clients geladen werden und selten verändert werden. Zudem werden sie von vielen linuxbasierten Distributionen als Paket mitgeliefert, was eine hohe Verteilung und Verfügbarkeit gewährleistet.
Anders gestaltet sich die Situation bei den RPKI-Publikationspunkten. Hier veröffentlichen RPKI-CA (Certification Authorities) ihre Zertifikate, Signaturen und Manifeste, die kontinuierlich von den Clients abgefragt werden. Aufgrund der Forderung nach hoher Verfügbarkeit und Schutz vor Ausfällen oder Angriffen setzen viele Betreiber inzwischen auf das Repository Delta Protocol (RRDP). Dieses auf HTTP basierende Protokoll ist wesentlich besser skalierbar als das ältere RSYNC-Protokoll, da es durch den Einsatz von Caches, CDNs und Anycast-Infrastrukturen eine verteilte und ausfallsichere Bereitstellung ermöglicht. Die Herausforderung bei der RPKI-Publikationsinfrastruktur liegt darin, die Daten zuverlässig und effizient an Millionen von RPKI-Clients weltweit auszuliefern.
Die Clients aktualisieren ihre lokalen Caches in regelmäßigen Intervallen – oft alle zehn Minuten – und müssen dabei auf eine konsistente und aktuelle Versionsbasis zugreifen. Dabei sind Latenz und Redundanz entscheidend, um Unterbrechungen eine möglichst geringe Auswirkung auf die Validierung von BGP-Routen zu haben. Ein markanter Unterschied zur DNS-Architektur besteht darin, dass die RPKI ihre Daten nicht ausführlich repliziert oder in einer echten Hierarchie abfragt, sondern die Clients selbst aktiv den aktuellen Stand abrufen und verifizieren. Dies impliziert, dass nicht unmittelbar auf Anfragen reagiert wird, sondern dass die Validierung durch eine Hintergundaufgabe realisiert wird. Die Tatsache, dass RPKI-Objekte eine explizite Gültigkeitsperiode haben, sorgt für eine gewisse Toleranz gegenüber kurzfristigen Ausfallsituationen, da abgelaufene Daten lediglich in den „Unknown“-Zustand übergehen, nicht aber als „Invalid“ eingestuft werden.
Das erlaubt es Netzwerken, trotz zeitweiliger Unzugänglichkeit von Publikationspunkten weiterhin mit reduziertem Risiko im globalen Routing teilzunehmen. Im Kontext von Resilienz stellt dies eine große Stärke der RPKI dar, denn es existiert keine enge Kopplung zwischen Echtzeit-Datenabruf und der Entscheidungslogik der Router. Eine vollständige Isolierung eines RPKI-Publikationspunkts oder gar einer gesamten Region würde zwar auf längere Sicht zu Datenverfall und eventuell zu vermehrtem „Unknown“-Routing führen, aber einen vollständigen Ausfall oder Manipulation des Routing-Sicherheitsmodells dadurch zu vermeiden. Ein weiterer Aspekt betrifft die geografische Lokalisierung und Serviceisolierung. Im DNS-Bereich gibt es Bestrebungen, Zugriffe durch geographische Nähe oder regionalen Autarkiebestrebungen robuster zu gestalten.
Im Fall der RPKI allerdings bieten solche Maßnahmen nur begrenzten Mehrwert. Sollte eine Region komplett von externen Publikationspunkten abgeschnitten sein, laufen lokale RPKI-Client-Caches aus und das Routing wechselt in einen „Unknown“-Zustand. Dies wird als betriebsicher eingestuft, da aus Sicherheitsgründen keine Routen aufgrund von fehlenden Aktualisierungen automatisch als ungültig gelten. Dies reduziert den Druck, lokale Kopien oder Vertrauensanker zu etablieren, und vermeidet unnötige Komplexität. Die Implementierung der RPKI wurde maßgeblich durch Einschränkungen geformt, die von Herstellern von BGP-Routern initiiert wurden.
Die RPKI sollte als Overlay funktionieren, ohne das BGP-Protokoll selbst ändern zu müssen. Daraus resultiert ein Modell, bei dem alle RPKI-Publisher ihre Daten an alle Clients pushen, diese aber selbst aktiv abgleichen. Dieses Fundament begrenzt die Skalierbarkeit, Latenz und Performance der Infrastruktur. Völlig neue Ansätze, etwa die Nutzung von BGP selbst zum Verteilen von RPKI-Credential-Informationen, werden diskutiert, sind aber bisher nicht umgesetzt. Sollte eine umfassendere Verbesserung von Skalierbarkeit und Resilienz angestrebt werden, bedarf es einer Neubewertung dieser Grundannahmen.
Trotzdem funktioniert die aktuelle Implementierung dank moderner Techniken wie RRDP, CDNs, Anycast und DNS-basierter Client-Steuerung sehr gut. Sie ermöglicht eine flächendeckende Verteilung der RPKI-Sicherheitsdaten mit hoher Verfügbarkeit und schützt die globale Routing-Infrastruktur wirksam gegen fehlerhafte oder böswillige Routing-Informationen. Resilienz in der RPKI-Infrastruktur ist also ein Zusammenspiel aus technischer Architektur, Protokolldesign und Operationalisierung. Die Unabhängigkeit von Echtzeit-Abfragen, gepaart mit periodischem Abgleich validierter Objekte, und der Einsatz modernster Verteilungstechnologien sind die Schlüssel zu einem robusten Netzwerk-Sicherheitsmechanismus. Während Herausforderungen bleiben, insbesondere in Bezug auf die maximale Skalierung und mehr Effizienz, hat das aktuelle System bereits heute seine Zuverlässigkeit und Sicherheit überzeugend unter Beweis gestellt.
In einer Welt, die zunehmend auf stabile und sichere Internetverbindungen angewiesen ist, ist die kontinuierliche Evaluierung und Verbesserung der Resilienz der RPKI ein wichtiger Baustein, um das Vertrauen in die globale Routing-Infrastruktur zu stärken und künftige Risiken zu minimieren. Betreiber, Hersteller und Forscher sind gemeinsam gefordert, den Entwicklungsprozess weiter voranzutreiben, um den steigenden Anforderungen einer dynamischen und wachsenden Internetlandschaft gerecht zu werden.
