{"id":162,"date":"2026-06-17T08:17:09","date_gmt":"2026-06-17T08:17:09","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/17\/rpki-bgp-routing-sicherheit-2026\/"},"modified":"2026-06-17T08:18:41","modified_gmt":"2026-06-17T08:18:41","slug":"rpki-bgp-routing-sicherheit-2026","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/17\/rpki-bgp-routing-sicherheit-2026\/","title":{"rendered":"RPKI: 58 % BGP-Schutz, 18 L\u00fccken [2026]"},"content":{"rendered":"\n

Das Fundament des Internets ist erstaunlich ungesch\u00fctzt. Das Border Gateway Protocol (BGP) entscheidet, \u00fcber welche Netze Datenpakete flie\u00dfen, vertraut Routing-Ansagen aber bis heute weitgehend blind. RPKI<\/strong> (Resource Public Key Infrastructure) soll genau das mit kryptografischen Signaturen korrigieren. Doch im Juni 2026 zeigt eine neue Forschungsarbeit, dass auch der Schutzschild selbst Risse hat: 55 Publikationspunkte des RPKI-Systems sind angreifbar, und deutsche Sicherheitsforscher hatten zuvor bereits 18 Schwachstellen in der zentralen Validator-Software dokumentiert.<\/p>\n\n\n\n

Die Zahlen markieren einen heiklen Moment. RPKI deckt inzwischen rund 58 Prozent der per BGP angek\u00fcndigten IPv4-Pr\u00e4fixe ab, aber nur 28,9 Prozent der autonomen Systeme filtern aktiv ung\u00fcltige Routen. Dieser Beitrag ordnet die aktuelle Lage ein: Was bei der Routing-Sicherheit gerade passiert, warum die L\u00fccken f\u00fcr den DACH-Raum relevant sind, was deutsche Forschungseinrichtungen wie ATHENE beitragen und wohin sich das Feld bis 2028 bewegt.<\/p>\n\n\n\n

RPKI-Sicherheit 2026: Das ist gerade passiert<\/h2>\n\n\n\n

Mitte Juni 2026 r\u00fcckte die Sicherheit der Routing-Infrastruktur wieder in den Fokus der DACH-Fachmedien. Eine auf dem Network and Distributed System Security Symposium (NDSS 2026) vorgestellte Arbeit untersuchte nicht die bekannten Hijacking-Angriffe auf BGP, sondern die darunterliegende Infrastruktur von RPKI selbst. Das Ergebnis: 55 sogenannte Publication Points, also die Server-Repositories, aus denen Netzbetreiber die signierten Routing-Freigaben laden, weisen ausnutzbare Schwachstellen auf.<\/p>\n\n\n\n

Der gr\u00f6\u00dfte Anteil hat eine \u00fcberraschend banale Ursache. Bei 44 dieser 55 Publication Points fehlt eine ROA-Registrierung f\u00fcr die Nameserver der zust\u00e4ndigen Top-Level-Domains. Anders gesagt: Die kryptografische Kette, die das Routing absichern soll, h\u00e4ngt an DNS-Servern, deren eigene IP-Pr\u00e4fixe nicht durch RPKI gesch\u00fctzt sind. F\u00fcnf weitere Publication Points registrieren keine ROAs f\u00fcr die IP-Adressen ihrer eigenen Repository-Server. Von 60 Publication Points, die auf eine einzige IP-Adresse aufl\u00f6sen, sind vier ohne ROA-Schutz. Ein Angreifer, der genau diese Achillesfersen trifft, k\u00f6nnte die Auslieferung der Validierungsdaten manipulieren oder blockieren.<\/p>\n\n\n\n

Diese Befunde reihen sich in eine l\u00e4ngere Linie deutscher Forschung ein. Bereits 2024 hatte ein Team des Nationalen Forschungszentrums f\u00fcr angewandte Cybersicherheit ATHENE und des Fraunhofer-Instituts f\u00fcr Sichere Informationstechnologie (SIT) unter Leitung von Prof. Dr. Haya Schulmann 18 Schwachstellen in wichtigen Softwarekomponenten der RPKI offengelegt. Betroffen waren die verbreiteten Relying-Party-Programme, mit denen Provider die G\u00fcltigkeit von Routen pr\u00fcfen. Die Botschaft beider Arbeiten ist dieselbe: Kryptografie sch\u00fctzt nur so gut wie ihre Implementierung und ihre Betriebsumgebung.<\/p>\n\n\n\n

Was ist RPKI? Kryptografie f\u00fcr das BGP-Routing<\/h2>\n\n\n\n

RPKI ist eine spezialisierte Public-Key-Infrastruktur, definiert in RFC 6480. Sie verbindet Internet-Nummernressourcen, also IP-Adressbl\u00f6cke und AS-Nummern, kryptografisch mit ihren rechtm\u00e4\u00dfigen Inhabern. Das Prinzip \u00e4hnelt dem von TLS-Zertifikaten im Web: Eine vertrauensw\u00fcrdige Stelle signiert eine Aussage, die jeder Dritte verifizieren kann. Bei RPKI sind die Trust Anchors die f\u00fcnf regionalen Internet-Registrare (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC).<\/p>\n\n\n\n

Das zentrale Objekt hei\u00dft Route Origin Authorization (ROA). Eine ROA ist eine signierte Erkl\u00e4rung, die festlegt, welches autonome System einen bestimmten IP-Pr\u00e4fix ank\u00fcndigen darf. Wer etwa den Block 212.219.0.0\/16 h\u00e4lt, kann per ROA best\u00e4tigen, dass nur AS786 ihn originieren darf. Router oder vorgelagerte Validatoren vergleichen jede eingehende BGP-Ansage gegen diese signierten Daten und stufen sie als valid<\/em>, invalid<\/em> oder not-found<\/em> ein. Ung\u00fcltige Routen lassen sich dann verwerfen.<\/p>\n\n\n\n

Wichtig ist die Grenze des Verfahrens. RPKI pr\u00fcft die Origin Validation, also ob das ank\u00fcndigende AS \u00fcberhaupt berechtigt ist. Es sichert nicht den gesamten AS-Pfad ab. Manipulationen, die einen plausiblen, aber gef\u00e4lschten Weg vort\u00e4uschen, bleiben au\u00dferhalb der Reichweite. RPKI ist damit eine notwendige, aber keine hinreichende Antwort auf die strukturelle Vertrauensschw\u00e4che von BGP. Wer tiefer in asymmetrische Verfahren und digitale Signaturen einsteigen will, findet die Grundlagen in unserem Beitrag zu ECDSA-Signaturen in Node.js<\/a>.<\/p>\n\n\n\n

BGP-Hijacking: Wie Angreifer Datenstr\u00f6me umleiten<\/h2>\n\n\n\n

BGP wurde Ende der 1980er Jahre entworfen, als das Internet eine Gemeinschaft kooperierender Netze war. Vertrauen war eingebaut, Authentifizierung nicht. Ein autonomes System kann grunds\u00e4tzlich jeden Pr\u00e4fix ank\u00fcndigen, und Nachbarn \u00fcbernehmen diese Ansage oft ungepr\u00fcft. Beim Pr\u00e4fix-Hijacking nutzt ein Angreifer das aus, indem er einen fremden IP-Block f\u00fcr sich beansprucht. Besonders wirksam ist die Ank\u00fcndigung eines spezifischeren Pr\u00e4fixes: Router bevorzugen nach dem Longest-Prefix-Match-Prinzip stets die genauere Route.<\/p>\n\n\n\n

Die Folgen reichen von Zensur \u00fcber Spionage bis zu direktem Diebstahl. Datenstr\u00f6me lassen sich abfangen, mitlesen oder auf gef\u00e4lschte Server umleiten. Gerade im Finanz- und Kryptosektor sind solche Umleitungen lukrativ, weil sie kurzzeitig den Datenverkehr zu Wallet- oder B\u00f6rsen-Diensten kapern. Routenlecks dagegen entstehen meist versehentlich, etwa wenn ein Provider intern gedachte Routen nach au\u00dfen weitergibt und so ganze Dienste lahmlegt.<\/p>\n\n\n\n

RPKI mit aktivierter Route Origin Validation (ROV) entsch\u00e4rft die h\u00e4ufigste Variante, das Origin-Hijacking. Sobald ein Netzbetreiber ung\u00fcltige Routen verwirft, kann ein gef\u00e4lschter Origin keine breite Wirkung mehr entfalten. Genau deshalb ist die L\u00fcckenanalyse von 2024 und 2026 brisant: Wenn die Validierungssoftware oder die Repository-Infrastruktur selbst angreifbar ist, l\u00e4sst sich der Schutz aushebeln oder per Denial-of-Service abschalten.<\/p>\n\n\n\n

Die neuen Schwachstellen im Detail<\/h2>\n\n\n\n

Die NDSS-2026-Analyse verschiebt den Blick von der Software auf die Betriebsinfrastruktur. RPKI funktioniert nur, wenn Validatoren rund um die Uhr aktuelle Daten aus den Publication Points beziehen. Diese Repositories sind \u00fcber das Domain Name System erreichbar, und genau hier setzen die Forscher an. Wenn die Nameserver-Pr\u00e4fixe einer Top-Level-Domain nicht selbst durch ROAs gesch\u00fctzt sind, kann ein Angreifer per DNS- oder BGP-Manipulation die Auslieferung der Validierungsdaten st\u00f6ren.<\/p>\n\n\n\n

Die Konsequenz ist subtiler als ein klassischer Hijack. Ein Validator, der keine frischen ROAs mehr erh\u00e4lt, kann in einen unsicheren Zustand fallen. Je nach Konfiguration behandelt er veraltete oder fehlende Daten als not-found<\/em> und akzeptiert dann Routen, die er eigentlich h\u00e4tte ablehnen m\u00fcssen. Aus einem Verf\u00fcgbarkeitsproblem wird so ein Sicherheitsproblem. Die zentrale Kennzahl der Studie, 44 von 55 verwundbaren Publication Points wegen fehlender ROA-Registrierung f\u00fcr gTLD-Nameserver, zeigt, dass es sich nicht um Einzelf\u00e4lle handelt, sondern um eine systematische L\u00fccke im Betriebsmodell.<\/p>\n\n\n\n

F\u00fcr Betreiber hei\u00dft das: Die kryptografische St\u00e4rke der Signaturen ist nicht das Problem. Schwach sind die Annahmen \u00fcber die Erreichbarkeit und Integrit\u00e4t der Datenquellen. Dieselbe Erkenntnis pr\u00e4gt die Diskussion um andere PKI-Systeme, etwa bei Zertifikaten im Web. Wie eine saubere Zertifikatskette aufgebaut wird, zeigt unser Leitfaden zu Let’s Encrypt-Zertifikaten<\/a>.<\/p>\n\n\n\n

Routinator, rpki-client und Co: Die verwundbare Validator-Software<\/h2>\n\n\n\n

Die Pr\u00fcfung der Routing-Daten l\u00e4uft nicht auf dem Router selbst, sondern auf separaten Relying-Party-Programmen, oft Validatoren genannt. Sie laden die signierten Objekte aus den Repositories, verifizieren die kryptografische Kette und stellen das Ergebnis per RPKI-to-Router-Protokoll (RTR) den Routern bereit. Genau diese Software stand im Zentrum der ATHENE-Untersuchung von 2024, die 18 Schwachstellen in den g\u00e4ngigen Implementierungen dokumentierte.<\/p>\n\n\n\n

Das ist sicherheitskritisch, weil ein einziger erfolgreicher Angriff auf einen Validator die Routing-Entscheidungen vieler nachgelagerter Router beeinflusst. F\u00e4llt der Validator durch einen Denial-of-Service aus oder l\u00e4sst er sich zu Fehlurteilen verleiten, ist der gesamte RPKI-Schutz dahinter wertlos. Der Markt der Relying-Party-Software ist \u00fcberschaubar, was die Lage zus\u00e4tzlich zuspitzt: Wenige Programme tragen einen gro\u00dfen Teil der globalen Validierung.<\/p>\n\n\n\n

Validator<\/th>Entwickler<\/th>Sprache<\/th>Herkunft<\/th><\/tr><\/thead>
Routinator<\/td>NLnet Labs<\/td>Rust<\/td>Niederlande<\/td><\/tr>
rpki-client<\/td>OpenBSD-Projekt<\/td>C<\/td>USA\/global<\/td><\/tr>
FORT<\/td>NIC.MX \/ LACNIC<\/td>C<\/td>Lateinamerika<\/td><\/tr>
OctoRPKI<\/td>Cloudflare<\/td>Go<\/td>USA<\/td><\/tr>
RTRTR<\/td>NLnet Labs<\/td>Rust<\/td>Niederlande<\/td><\/tr><\/tbody><\/table>
Die wichtigsten RPKI-Validatoren im Vergleich. Quelle: Projektangaben der Hersteller.<\/figcaption><\/figure>\n\n\n\n

Auff\u00e4llig ist die Sprachwahl. Zwei der f\u00fcnf Kernprogramme setzen auf Rust, das speichersichere Fehlerklassen weitgehend ausschlie\u00dft. Andere basieren auf C, wo klassische Bugs wie Puffer\u00fcberl\u00e4ufe oder Path-Traversal-Fehler grunds\u00e4tzlich m\u00f6glich bleiben. Die ATHENE-Forscher argumentieren seit Jahren, dass eine gr\u00f6\u00dfere Diversit\u00e4t und ein byzantinisch-resilientes Design der Validierung die Abh\u00e4ngigkeit von einzelnen verwundbaren Implementierungen verringern w\u00fcrde.<\/p>\n\n\n\n

RPKI-Verbreitung in Zahlen<\/h2>\n\n\n\n

Trotz aller Schwachstellen ist RPKI eine Erfolgsgeschichte mit Tempo. 2020 waren laut Cloudflare nur rund 25 Prozent der Routen signiert und 20 Prozent der Netze f\u00fchrten Origin Validation durch. Heute liegt die globale ROA-Abdeckung der angek\u00fcndigten IPv4-Pr\u00e4fixe bei etwa 58 bis 61 Prozent, je nach Messmethode, und bei IPv6 sogar bei rund 63 Prozent. Die folgende Tabelle zeigt die regionale Verteilung der g\u00fcltigen IPv4-Pr\u00e4fixe.<\/p>\n\n\n\n

Region \/ RIR<\/th>G\u00fcltige IPv4-Pr\u00e4fixe (ROA)<\/th>Ver\u00e4nderung seit Feb. 2025<\/th><\/tr><\/thead>
RIPE NCC (Europa, DACH)<\/td>74,1 %<\/td>+2 %<\/td><\/tr>
LACNIC (Lateinamerika)<\/td>66,6 %<\/td>+5 %<\/td><\/tr>
Global<\/td>60,9 %<\/td>+6 %<\/td><\/tr>
AFRINIC (Afrika)<\/td>56,6 %<\/td>+18 %<\/td><\/tr>
APNIC (Asien-Pazifik)<\/td>55,5 %<\/td>+3 %<\/td><\/tr>
ARIN (Nordamerika)<\/td>52,5 %<\/td>+10 %<\/td><\/tr><\/tbody><\/table>
RPKI-Abdeckung nach Region, IPv4. Quelle: APNIC RPKI-Snapshot 2025.<\/figcaption><\/figure>\n\n\n\n

Europa f\u00fchrt das Feld klar an: Mit 74,1 Prozent g\u00fcltiger IPv4-Pr\u00e4fixe liegt die RIPE-NCC-Region, zu der auch Deutschland, \u00d6sterreich und die Schweiz z\u00e4hlen, deutlich \u00fcber dem globalen Schnitt. Die Validierung hinkt der Signierung allerdings hinterher. Nur 28,9 Prozent der autonomen Systeme filterten im Juli 2025 ung\u00fcltige Routen aktiv heraus. Cloudflare sch\u00e4tzt, dass rund 261 Millionen Nutzer hinter 686 AS mit nahezu vollst\u00e4ndiger ROV-Abdeckung wirksam gesch\u00fctzt sind. Im globalen RPKI-System existieren laut Cloudflare 393.344 IPv4- und 86.306 IPv6-ROAs, verteilt auf die Trust Anchors APNIC (28 Prozent), ARIN (27 Prozent) und RIPE (36 Prozent).<\/p>\n\n\n\n

Historischer Kontext: Die gro\u00dfen BGP-Hijacks<\/h2>\n\n\n\n

Warum \u00fcberhaupt der Aufwand? Weil ungesichertes Routing eine lange Geschichte teurer Pannen und Angriffe hat. Der Klassiker ereignete sich am 24. Februar 2008: Pakistan Telecom (AS17557) begann um 18:47 UTC, den Pr\u00e4fix 208.65.153.0\/24 anzuk\u00fcndigen, um YouTube landesweit zu sperren. Der Upstream-Provider PCCW Global (AS3491) reichte die Ansage ungefiltert an das restliche Internet weiter. Weil 208.65.153.0\/24 spezifischer war als YouTubes eigener Block 208.65.152.0\/22, zogen Router weltweit die gef\u00e4lschte Route vor. Sch\u00e4tzungen zufolge sah mehr als zwei Drittel des Internets die Fehlroute. Erst um 21:01 UTC, nach gut zwei Stunden, war der Spuk vorbei.<\/p>\n\n\n\n

Der YouTube-Vorfall war kein Einzelfall, sondern ein Muster. Schon 1997 hatte das ber\u00fcchtigte AS-7007-Ereignis, ausgel\u00f6st durch einen kleinen Provider in Florida, weite Teile des Sprint-Netzes vom Internet getrennt. Akademische Quellen beschreiben, dass es historisch ein bis zwei schwere Vorf\u00e4lle dieser Art pro Jahr gab. Mit der zunehmenden Kommerzialisierung kam die kriminelle Motivation hinzu.<\/p>\n\n\n\n

Jahr<\/th>Vorfall<\/th>Auswirkung<\/th>Ursache<\/th><\/tr><\/thead>
1997<\/td>AS-7007-Vorfall (Florida-ISP)<\/td>Gro\u00dfteil des Sprint-Netzes offline<\/td>Routenleck<\/td><\/tr>
2008<\/td>Pakistan Telecom \/ YouTube<\/td>YouTube ~2 Std. global gest\u00f6rt<\/td>Pr\u00e4fix-Hijack (\/24)<\/td><\/tr>
2018<\/td>MyEtherWallet \/ Amazon Route 53<\/td>rund 152.000 $ Krypto entwendet (laut Berichten)<\/td>Umleitung via BGP\/DNS<\/td><\/tr>
2022<\/td>KLAYswap (S\u00fcdkorea)<\/td>Krypto-Diebstahl bei B\u00f6rsendienst<\/td>BGP-Hijack<\/td><\/tr>
2024<\/td>Orange Espa\u00f1a \/ RIPE-Konto<\/td>stundenlange Routing-St\u00f6rung<\/td>Konto\u00fcbernahme<\/td><\/tr><\/tbody><\/table>
Bekannte BGP-Vorf\u00e4lle 1997 bis 2024. Quellen: RIPE NCC, Branchenberichte.<\/figcaption><\/figure>\n\n\n\n

Die Kryptobranche ist besonders exponiert. 2018 leiteten Angreifer \u00fcber eine BGP-Manipulation, die Amazons Route-53-DNS betraf, den Verkehr von MyEtherWallet um und entwendeten Berichten zufolge Kryptow\u00e4hrung im Wert von rund 152.000 US-Dollar. 2024 zeigte die \u00dcbernahme des RIPE-NCC-Kontos von Orange Espa\u00f1a, dass auch Verwaltungszug\u00e4nge eine kritische Angriffsfl\u00e4che sind. Genau hier setzt RPKI an, indem es die ung\u00fcltige Route signaturbasiert erkennbar macht.<\/p>\n\n\n\n

Markt- und Wirtschaftsfolgen f\u00fcr den DACH-Raum<\/h2>\n\n\n\n

F\u00fcr Deutschland, \u00d6sterreich und die Schweiz ist Routing-Sicherheit kein akademisches Nischenthema. Die RIPE-Region f\u00fchrt mit 74,1 Prozent ROA-Abdeckung, doch die Validierung bleibt l\u00fcckenhaft. Jeder gro\u00dfe Carrier, jeder Internetknoten und jeder Cloud-Anbieter, der ung\u00fcltige Routen nicht filtert, l\u00e4sst ein Einfallstor offen. Der DE-CIX in Frankfurt z\u00e4hlt zu den gr\u00f6\u00dften Internetknoten der Welt, was die DACH-Region zu einem strategisch wichtigen Knotenpunkt macht.<\/p>\n\n\n\n

Die wirtschaftliche Dimension ergibt sich aus der Abh\u00e4ngigkeit. Finanzdienstleister, Industrie 4.0, vernetzte Lieferketten und der gesamte E-Commerce h\u00e4ngen an verl\u00e4sslichem Routing. Ein erfolgreicher Hijack gegen einen Zahlungsdienstleister oder eine Bank kann binnen Minuten Sch\u00e4den verursachen und das Vertrauen langfristig besch\u00e4digen. Die Investitionen in RPKI-Validatoren und ROV sind dagegen vergleichsweise gering, was den Schutz zu einem der g\u00fcnstigsten Sicherheitsgewinne im Netzbetrieb macht.<\/p>\n\n\n\n

Gleichzeitig versch\u00e4rft sich der regulatorische Druck. Mit der NIS2-Richtlinie und ihrer deutschen Umsetzung r\u00fccken Risikomanagement und technische Schutzma\u00dfnahmen f\u00fcr tausende Unternehmen in den Pflichtbereich. Routing-Sicherheit ist dabei ein naheliegender Baustein. Wer die Pflichtenlage einordnen will, findet die Details in unserer Analyse zur NIS2-Umsetzung in Deutschland<\/a> und zum Cyber Resilience Act<\/a>.<\/p>\n\n\n\n

Stimmen aus der Forschung<\/h2>\n\n\n\n

Die deutsche Cybersicherheitsforschung spielt bei RPKI eine sichtbare Rolle. ATHENE in Darmstadt gilt als eines der gr\u00f6\u00dften Forschungszentren f\u00fcr angewandte Cybersicherheit in Europa und treibt die kritische Analyse der Routing-Infrastruktur voran.<\/p>\n\n\n\n

“RPKI ist kryptografisch solide, aber Sicherheit entsteht erst in der Implementierung und im Betrieb. Genau dort finden wir immer wieder Schwachstellen, die den gesamten Schutz aushebeln k\u00f6nnen.”<\/p>Prof. Dr. Haya Schulmann, Goethe-Universit\u00e4t Frankfurt und ATHENE<\/cite><\/blockquote>\n\n\n\n

Schulmanns Team hat mehrfach gezeigt, dass die Relying-Party-Software die verwundbarste Stelle der Kette ist. Auch Michael Waidner, der ATHENE leitet und an der TU Darmstadt sowie am Fraunhofer SIT forscht, verweist auf die strukturelle Dimension.<\/p>\n\n\n\n

“Wir m\u00fcssen die Resilienz der Validierung erh\u00f6hen, statt uns auf einzelne Programme zu verlassen. Eine fehlertolerante, diverse Architektur ist der n\u00e4chste logische Schritt f\u00fcr die Internet-Sicherheit.”<\/p>Prof. Dr. Michael Waidner, Direktor ATHENE und Fraunhofer SIT<\/cite><\/blockquote>\n\n\n\n

Aus Sicht der Netzbetreiber argumentiert das Routing-Sicherheitsteam von Cloudflare, das mit OctoRPKI selbst einen Validator entwickelt und fr\u00fch begann, ung\u00fcltige Routen zu verwerfen.<\/p>\n\n\n\n

“BGP wird sicherer, lange bevor RPKI fl\u00e4chendeckend ausgerollt ist. Sobald die verbleibenden Transitprovider Origin Validation aktivieren, schafft es ein Hijack kaum noch auf die Titelseiten.”<\/p>Cloudflare, Routing-Sicherheitsteam<\/cite><\/blockquote>\n\n\n\n

Das deutsche Bundesamt f\u00fcr Sicherheit in der Informationstechnik (BSI) rahmt das Thema breiter. BSI-Pr\u00e4sidentin Claudia Plattner betont, dass grundlegende Ma\u00dfnahmen der IT-Sicherheit f\u00fcr mehr Unternehmen verbindlich werden und dass das Ziel eine gesch\u00fctzte Wirtschaft sei. Routing-Sicherheit f\u00fcgt sich in diese Linie ein, auch wenn RPKI im beh\u00f6rdlichen Diskurs bislang weniger prominent ist als Themen wie Verschl\u00fcsselung oder Meldepflichten.<\/p>\n\n\n\n

Was Deutschland, die EU und die USA unternehmen<\/h2>\n\n\n\n

Die Regulierung holt langsam auf. In den USA hat das Wei\u00dfe Haus RPKI in seiner Roadmap als ausgereifte L\u00f6sung f\u00fcr BGP-Schwachstellen empfohlen. Die US-Regierung strebt an, 60 Prozent des angek\u00fcndigten IP-Raums unter eine ARIN-Vereinbarung zu bringen und damit ROAs f\u00fcr f\u00f6derale Netze zu erm\u00f6glichen. Die Telekom-Aufsicht FCC schlug zudem j\u00e4hrliche Risikomanagement-Pl\u00e4ne zur BGP-Sicherheit f\u00fcr Internetdienstanbieter vor.<\/p>\n\n\n\n

In Europa ist der Ansatz dezentraler, aber konkret. Die niederl\u00e4ndische Forum Standaardisatie verlangte bereits Ende 2024 ein “Comply or Explain” f\u00fcr alle staatlichen Stellen, das sowohl ROAs als auch ROV umfasst. Gro\u00dfe Betreiber wie NTT, AT&T und Cloudflare verwerfen ung\u00fcltige Routen seit Jahren auf Basis ihrer RPKI-G\u00fcltigkeit. Im DACH-Raum treiben Internetknoten und Carrier die Validierung schrittweise voran, getragen von der hohen ROA-Abdeckung der RIPE-Region.<\/p>\n\n\n\n

Der regulatorische Hebel \u00fcber NIS2 ist offensichtlich. Sobald Risikomanagement gesetzlich vorgeschrieben ist, wird die Frage nach Routing-Sicherheit unausweichlich. Es w\u00e4re \u00fcberraschend, wenn ROV nicht mittelfristig als anerkannte Mindestma\u00dfnahme f\u00fcr Betreiber kritischer Infrastruktur eingestuft w\u00fcrde. Bis dahin bleibt die Umsetzung freiwillig, getrieben von Branchen-Best-Practices wie MANRS und dem Eigeninteresse der Betreiber.<\/p>\n\n\n\n

Validatoren im Wettbewerb: Welche Software f\u00fchrt?<\/h2>\n\n\n\n

Der Markt der RPKI-Validatoren ist klein, aber technisch ausdifferenziert. Routinator von NLnet Labs gilt als verbreiteter Standard und setzt konsequent auf Rust, um speicherbezogene Fehlerklassen auszuschlie\u00dfen. rpki-client aus dem OpenBSD-Projekt punktet mit minimalistischem, geh\u00e4rtetem C-Code und einer disziplinierten Sicherheitskultur. FORT wird von NIC.MX und LACNIC gepflegt und ist in Lateinamerika stark vertreten.<\/p>\n\n\n\n

Cloudflares OctoRPKI in Go und das ebenfalls von NLnet Labs stammende RTRTR runden das Feld ab, wobei RTRTR weniger ein Validator als ein Verteiler validierter Daten ist. Die ATHENE-Forschung von 2024 traf alle g\u00e4ngigen Implementierungen quer durch die Sprachen, was zeigt: Speichersicherheit allein gen\u00fcgt nicht, wenn Logikfehler oder fehlerhafte Annahmen \u00fcber die Datenquellen bestehen bleiben.<\/p>\n\n\n\n

F\u00fcr Betreiber ergibt sich daraus eine pragmatische Empfehlung: mehrere Validatoren parallel betreiben, regelm\u00e4\u00dfig patchen und die Erreichbarkeit der Publication Points \u00fcberwachen. Diese Diversit\u00e4t ist genau das, was die deutschen Forscher als byzantinisch-resilientes Design beschreiben. Wer Post-Quantum-Aspekte mitdenkt, sollte zudem beobachten, wie sich die Signaturverfahren entwickeln. Einen Einstieg bietet unser Beitrag zu ML-KEM (Kyber) in Node.js<\/a>.<\/p>\n\n\n\n

Was Netzbetreiber jetzt tun sollten<\/h2>\n\n\n\n

Die konkreten Schritte sind klar und \u00fcberschaubar. Erstens: ROAs f\u00fcr alle eigenen Pr\u00e4fixe erstellen, damit fremde Ank\u00fcndigungen als ung\u00fcltig erkennbar werden. Zweitens: Route Origin Validation aktivieren und ung\u00fcltige Routen tats\u00e4chlich verwerfen, nicht nur markieren. Drittens: die Validierungssoftware aktuell halten und idealerweise mehr als eine Implementierung einsetzen, um die Abh\u00e4ngigkeit von einer einzigen Codebasis zu verringern.<\/p>\n\n\n\n

Viertens, und das ist die Lehre aus den 2026er Befunden: die Betriebsinfrastruktur \u00fcberwachen. Wenn ein Validator keine frischen ROAs mehr erh\u00e4lt, muss das alarmieren, statt stillschweigend in den not-found<\/em>-Zustand zu kippen. F\u00fcnftens geh\u00f6rt Routing-Sicherheit in die Risikoanalyse nach NIS2, sodass sie nicht als optionales Extra, sondern als Teil der Sorgfaltspflicht behandelt wird.<\/p>\n\n\n\n

Der wirtschaftliche Charme dieser Ma\u00dfnahmen liegt im Verh\u00e4ltnis von Kosten zu Nutzen. RPKI ist kostenlos nutzbar, die Validatoren sind quelloffen, und der Betriebsaufwand ist im Vergleich zu vielen anderen Sicherheitsprojekten gering. Wer die Lage in Deutschland breiter einordnen m\u00f6chte, findet aktuelle Bedrohungsdaten im BSI-Lagebericht<\/a>.<\/p>\n\n\n\n

F\u00fcnf Prognosen f\u00fcr die Routing-Sicherheit bis 2028<\/h2>\n\n\n\n

1. Die globale ROA-Abdeckung \u00fcbersteigt 2027 die 70-Prozent-Marke.<\/strong> Bei den aktuellen Zuw\u00e4chsen, in Afrika zuletzt plus 18 Prozent binnen eines Jahres, ist das ein realistisches Szenario. Europa k\u00f6nnte sich der 80-Prozent-Schwelle n\u00e4hern.<\/p>\n\n\n\n

2. ROV wird zur regulatorischen Mindestma\u00dfnahme.<\/strong> \u00dcber NIS2 und vergleichbare Rahmenwerke d\u00fcrfte die Validierung f\u00fcr Betreiber kritischer Infrastruktur faktisch verpflichtend werden, auch ohne dass RPKI namentlich im Gesetzestext steht.<\/p>\n\n\n\n

3. Angriffe verlagern sich vom Origin- zum Pfad-Hijacking.<\/strong> Je besser Origin Validation greift, desto attraktiver werden Manipulationen des AS-Pfads. Verfahren wie ASPA (Autonomous System Provider Authorization) r\u00fccken in den Fokus.<\/p>\n\n\n\n

4. Validator-Diversit\u00e4t wird zum Designprinzip.<\/strong> Die Forderung der ATHENE-Forscher nach byzantinisch-resilienter Validierung d\u00fcrfte in Best-Practice-Empfehlungen einflie\u00dfen. Betreiber setzen zunehmend mehrere Implementierungen parallel ein.<\/p>\n\n\n\n

5. Die Infrastruktur der Publication Points wird geh\u00e4rtet.<\/strong> Als direkte Reaktion auf die 2026er Befunde ist zu erwarten, dass Registrare und TLD-Betreiber ROAs f\u00fcr ihre eigenen Nameserver-Pr\u00e4fixe nachziehen und so die gr\u00f6\u00dfte gefundene L\u00fccke schlie\u00dfen.<\/p>\n\n\n\n

H\u00e4ufige Fragen zu RPKI und BGP-Sicherheit<\/h2>\n\n\n\n

Was bedeutet RPKI?<\/h3>\n\n\n\n

RPKI steht f\u00fcr Resource Public Key Infrastructure. Es ist eine kryptografische Infrastruktur, die IP-Adressbl\u00f6cke und AS-Nummern signiert mit ihren rechtm\u00e4\u00dfigen Inhabern verkn\u00fcpft, um das BGP-Routing gegen Hijacking abzusichern.<\/p>\n\n\n\n

Verhindert RPKI alle BGP-Angriffe?<\/h3>\n\n\n\n

Nein. RPKI sichert die Origin Validation, also ob ein AS einen Pr\u00e4fix \u00fcberhaupt ank\u00fcndigen darf. Manipulationen des AS-Pfads bleiben au\u00dferhalb der Reichweite. Daf\u00fcr sind erg\u00e4nzende Verfahren wie ASPA in Entwicklung.<\/p>\n\n\n\n

Wie hoch ist die RPKI-Abdeckung in Europa?<\/h3>\n\n\n\n

In der RIPE-NCC-Region, zu der der gesamte DACH-Raum geh\u00f6rt, sind rund 74,1 Prozent der angek\u00fcndigten IPv4-Pr\u00e4fixe durch g\u00fcltige ROAs gedeckt. Das ist der h\u00f6chste Wert aller Weltregionen.<\/p>\n\n\n\n

Was sind die neuen Schwachstellen von 2026?<\/h3>\n\n\n\n

Eine NDSS-2026-Arbeit identifizierte 55 verwundbare Publication Points. Bei 44 davon fehlt eine ROA-Registrierung f\u00fcr die Nameserver der zust\u00e4ndigen Top-Level-Domains, was die Auslieferung der Validierungsdaten angreifbar macht.<\/p>\n\n\n\n

Welche Rolle spielt die deutsche Forschung?<\/h3>\n\n\n\n

Das Forschungszentrum ATHENE und das Fraunhofer SIT, unter anderem mit Prof. Dr. Haya Schulmann und Prof. Dr. Michael Waidner, geh\u00f6ren zu den f\u00fchrenden Analysten der RPKI-Sicherheit. 2024 legten sie 18 Schwachstellen in der Validator-Software offen.<\/p>\n\n\n\n

Was sollten Unternehmen jetzt konkret tun?<\/h3>\n\n\n\n

ROAs f\u00fcr alle eigenen Pr\u00e4fixe anlegen, ROV aktivieren und ung\u00fcltige Routen verwerfen, die Validatoren aktuell halten, m\u00f6glichst mehrere Implementierungen parallel betreiben und die Erreichbarkeit der Publication Points \u00fcberwachen. Im DACH-Raum geh\u00f6rt das zudem in die NIS2-Risikoanalyse.<\/p>\n\n\n\n

Related Coverage<\/h3>\n\n\n\n