RPKI für Einsteiger: So schützen Sie Ihre IP-Blöcke vor BGP-Hijacking

Ein autonomes System am anderen Ende der Welt kündigt Ihr Subnetz einfach als sein eigenes an, und je nachdem, wie weit sich diese Ankündigung verbreitet, wird Ihr Traffic umgeleitet – zu ihm. Solche Ereignisse heißen BGP-Hijacking und Route Leaks, und RPKI ist das System, das die Branche gebaut hat, um sie zu stoppen. Die meisten davon sind nicht einmal Angriffe: Die häufigste Ursache ist ein ehrlicher Fehler – ein Netzwerk kündigt ein Subnetz an, das es gar nicht hält.

Das ist keine Theorie. BGP-Hijacking hat YouTube weltweit für etwa zwei Stunden erheblich gestört, Amazons DNS-Traffic umgeleitet, um Nutzer auf eine Phishing-Seite zu schicken, die Kryptowallets leerte, und große Ausfälle in Cloud-Infrastrukturen verursacht. Die Angriffsfläche ist die Routing-Infrastruktur des Internets selbst, und das Standard-Vertrauensmodell, auf dem BGP seit 1989 läuft, bietet keinen kryptografischen Schutz dagegen.

RPKI – Resource Public Key Infrastructure – ist in der RIPE-Region seit 2011 einsetzbar, die Verbreitung bei großen Netzwerken hat sich seit 2020 deutlich beschleunigt, und Ihre erste ROA anzulegen dauert weniger als zehn Minuten, sobald Sie verstehen, was Sie tun. Wenn Sie IP-Blöcke besitzen, kaufen, verkaufen oder leasen, entscheidet RPKI heute direkt darüber, ob Ihre Adressen geroutet werden, wie sehr andere Netzwerke ihnen vertrauen und was sie wert sind.

Dieser Leitfaden erklärt in einfachen Worten, was RPKI ist, wie BGP-Hijacking funktioniert, wie Sie eine Route Origin Authorization für Ihr Subnetz anlegen, wie Sie empfangene Routen validieren und was sich ändert, wenn der Adressraum geleast statt gekauft ist. Durchgehend sprechen wir von IP-Eigentümern (Inhabern) und IP-Mietern – den beiden Seiten jedes Leasings.

Was ist RPKI?

RPKI steht für Resource Public Key Infrastructure. Es ist ein kryptografisches Rahmenwerk, mit dem IP-Eigentümer nachweisen können – überprüfbar, nicht nur behauptet –, dass ein bestimmtes autonomes System ein bestimmtes Subnetz in BGP originieren darf.

Es funktioniert als Vertrauenskette. IANA, die oberste Instanz für alle IP-Adressen, delegiert Blöcke an die fünf Regional Internet Registries: ARIN, RIPE NCC, APNIC, LACNIC und AFRINIC. Jede RIR stellt dem IP-Eigentümer, der einen Block hält, ein digitales Zertifikat aus. Dieses Zertifikat ist der kryptografische Nachweis der Inhaberschaft. Es lässt sich nicht fälschen, und jeder im Internet kann es prüfen.

Stellen Sie es sich wie ein Grundbuch vor. Das Grundbuch hindert niemanden physisch daran, zu behaupten, ihm gehöre ein Haus. Es erlaubt aber jedem Interessierten, den offiziellen Eintrag einzusehen und den echten Eigentümer zu erkennen. RPKI leistet dasselbe für IP-Blöcke.

Was ist eine ROA (Route Origin Authorization)?

Das Zertifikat allein bewirkt nicht viel. Nützlich ist, was der IP-Eigentümer damit erstellt: eine Route Origin Authorization, kurz ROA. Einfach gesagt besagt eine ROA: „Dieses Subnetz darf von diesem Netzwerk angekündigt werden, bis zu dieser Größe.“

Sie hält drei Dinge fest:

• das geschützte Subnetz (manchmal „Präfix“ genannt),

• die ASN, die es ankündigen darf, und

• die maximale Präfixlänge – den kleinsten, spezifischsten Teilblock, den diese ASN ankündigen darf.

Die ROA wird mit einer Schlüsselkette signiert, die auf die Regional Internet Registry zurückgeht – bei IP-Eigentümern in Europa und im Nahen Osten das RIPE NCC –, die als kryptografischer Vertrauensanker dient. Einmal veröffentlicht, ist eine ROA für alle sichtbar: Jeder Betreiber kann sie herunterladen und damit entscheiden, ob er einer Route vertraut. Für technisch genaue Leser: Das aktuelle ROA-Format ist in RFC 9582 definiert, veröffentlicht 2024.

RPKI-Validierungszustände: Valid, Invalid, NotFound

Empfängt ein Router eine BGP-Routenankündigung, prüft die RPKI-Validierung sie gegen die veröffentlichten ROAs. Das Ergebnis ist einer von drei Zuständen.

Die praktische Konsequenz ist unmissverständlich: Ein Invalid-Ergebnis führt dazu, dass jedes Netzwerk, das RPKI durchsetzt, Ihren Traffic verwirft. Eine falsche ROA ist schlimmer als gar keine.

Wie Router RPKI nutzen: Validatoren und ROV

Router erledigen die aufwendige Kryptografie nicht selbst. Ein Betreiber betreibt eine Software namens Validator (auch „Relying Party“-Software). Der Validator lädt alle ROAs aller fünf RIRs herunter, prüft alle Signaturen und erstellt eine bereinigte, verifizierte Liste.

Der Router verbindet sich dann über ein einfaches Protokoll namens RTR – RPKI-to-Router – mit dem Validator und ruft diese verifizierte Liste ab. Ab dann kann er jede eingehende Route als Valid, Invalid oder NotFound kennzeichnen und entsprechend handeln. Diese Prüfung von Routen gegen ROAs heißt Route Origin Validation, kurz ROV.

RPKI hat also zwei Hälften, und beide müssen stattfinden:

1. IP-Eigentümer signieren ihre Subnetze, indem sie ROAs anlegen.

2. Netzwerkbetreiber validieren eingehende Routen per ROV.

Eine ROA schützt Sie nur, wenn andere Netzwerke validieren. Validierung hilft nur, wenn IP-Eigentümer ROAs angelegt haben. Das System wird stärker, je mehr mitmachen.

RPKI schützt gezielt vor Hijacking des Routen-Origins – wenn ein Angreifer Ihr Subnetz fälschlich aus einer nicht autorisierten ASN originiert. Es schützt nicht vor Route Leaks, bei denen eine legitime ASN Routen weiterverteilt, die sie nicht weitergeben sollte. Was dafür entwickelt wird, behandeln wir am Ende dieses Leitfadens.

Wie BGP-Hijacking funktioniert

BGP – das Border Gateway Protocol – ist das Routing-Protokoll, das autonome Systeme im Internet verbindet. Jedes autonome System arbeitet unter einer ASN, und über BGP tauschen diese Netzwerke aus, welche Subnetze sie über welche Pfade erreichen können.

Die Grundannahme von BGP ist, dass teilnehmende Netzwerke die Wahrheit sagen. Es gibt keinen eingebauten kryptografischen Mechanismus, der prüft, ob die ASN, die ein Subnetz ankündigt, dazu tatsächlich berechtigt ist. Kündigt AS64496 an, dass es 203.0.113.0/24 erreichen kann, haben die Router des Internets keinen eigenen Weg zu prüfen, ob AS64496 diesen Adressraum tatsächlich hält.

BGP-Hijacking nutzt diese Lücke aus. Ein bösartiges – oder falsch konfiguriertes – autonomes System kündigt ein Subnetz an, das ihm nicht gehört. Verbreitet sich die Ankündigung und wird von nachgelagerten Routern akzeptiert, wird Traffic für dieses Subnetz zum Hijacker umgeleitet.

Es gibt zwei verbreitete Varianten:

Exact-Prefix-Hijacking. Der Angreifer kündigt dasselbe Subnetz an wie der legitime Inhaber – etwa 203.0.113.0/24. Die BGP-Routenauswahl hängt dann von der Länge des AS-Pfads und lokalen Routing-Policies ab. Je nach Netzwerktopologie setzt sich der Angriff gegen die legitime Ankündigung durch oder nicht.

More-Specific-Hijacking. Der Angreifer kündigt ein spezifischeres Präfix an – 203.0.113.0/25 –, abgeleitet aus dem Block des Opfers. Da BGP spezifischere Routen immer bevorzugt, ist diese Variante aus Sicht des Angreifers zuverlässiger. Traffic für das gekaperte /25 wird überall dort zum Angreifer geroutet, wo die spezifischere Ankündigung akzeptiert wird.

Die Folgen sind unterschiedlich. Manchmal lässt der Hijacker den Traffic einfach ins Leere laufen – ein Ausfall für das Opfer. Bei gezielteren Angriffen wird Traffic abgefangen, inspiziert oder verändert und weitergeleitet – der Hijack bleibt für Endnutzer unsichtbar, während passive Überwachung oder aktive Manipulation unterwegs möglich ist.

Fehlkonfigurationen machen einen nennenswerten Anteil der BGP-Hijacking-Vorfälle aus. Ein Netzwerk-Engineer macht einen Fehler in einer Routenankündigung, und das Ergebnis sieht von außen genauso aus wie ein absichtlicher Angriff. Die Wirkung ist unabhängig von der Absicht dieselbe.

Der Vorfall bei Pakistan Telecom 2008 – eine falsch konfigurierte spezifischere /24-Ankündigung aus YouTubes /22 verbreitete sich über PCCW weltweit und störte den Zugriff auf YouTube etwa zwei Stunden lang erheblich – ist das meistzitierte Beispiel. Der Angriff auf den DNS-Dienst Amazon Route 53 im Jahr 2018, bei dem DNS-Anfragen für myetherwallet.com gekapert und Nutzer auf eine vom Angreifer kontrollierte Phishing-Seite umgeleitet wurden, die bei eingeloggten Nutzern rund $150,000 in Ethereum abzog, ist ein gezielteres. Keiner der beiden hätte gegen ein korrekt RPKI-validiertes Subnetz mit Verwerfen ungültiger Routen Erfolg gehabt.

Warum RPKI 2026 wichtig ist

Lange war RPKI optional und kaum genutzt. Das hat sich geändert.

Seit Mai 2024 verwerfen alle bis auf einen der größten Transit-freien (Tier-1-)Provider des Internets RPKI-ungültige Routen – ein Meilenstein, den MANRS und der RPKI Monitor des NIST bestätigt haben. Bei diesem Durchsetzungsgrad verbreitet sich eine RPKI-ungültige Ankündigung nur noch halb bis ein Drittel so weit wie eine Route ohne RPKI-Abdeckung.

Auf der Seite der Signierung beziffert der NIST RPKI Monitor die ROA-Abdeckung der globalen Routing-Tabelle auf rund 54 % der IPv4- und IPv6-Subnetze, Kentik schätzt, dass heute rund 74 % des Internet-Traffics an abgedeckte Ziele gehen, und APNIC bezifferte die weltweite durchschnittliche Abdeckung auf der APRICOT 2026 auf etwa 60 %.

Die Durchsetzung konzentriert sich noch auf die großen Carrier, und die Verbreitung bei Tier-2- und regionalen Netzwerken ist ungleichmäßig. Die Richtung ist aber klar, und sie hat drei Folgen für alle, die mit IP-Blöcken arbeiten:

Mehr Provider verlangen ROAs. Immer mehr Upstream-Provider und Internet Exchanges akzeptieren Ihre Ankündigungen nicht – und machen zunehmend keine Geschäfte mehr mit Ihnen –, wenn Ihre Subnetze nicht korrekt signiert sind.

Die Cloud verlangt es. Wenn Sie Ihren eigenen IP-Block zu AWS, Google Cloud oder Azure bringen, ist eine korrekte ROA, die die ASN des Cloud-Anbieters autorisiert, Pflicht. Keine ROA, kein Service.

Es beeinflusst den Wert eines Subnetzes. Ein Block mit sauberen, korrekten RPKI-Einträgen ist schneller einsatzbereit und genießt mehr Vertrauen. Für IP-Eigentümer, die ungenutzten IPv4-Adressraum monetarisieren möchten, und für Käufer, die vor dem Kauf von IPv4-Blöcken Due Diligence betreiben, gehört der RPKI-Status heute neben Missbrauchshistorie und Reputation zur Standardprüfung.

RPKI einrichten: für IP-Eigentümer

Vor dem Start wählen Sie zwischen zwei Modellen:

Hosted RPKI – Ihre RIR betreibt das kryptografische System für Sie, und Sie legen ROAs an, indem Sie sich in ihr Portal einloggen (RIPE NCC Portal, ARIN Online, MyAPNIC usw.). Das ist für fast alle die richtige Wahl.

Delegated RPKI – Sie betreiben Ihre eigene Zertifizierungsstelle, etwa mit der Software Krill. Das passt nur für große Betreiber mit hohem Automatisierungsbedarf.

Die folgende Anleitung beschreibt Hosted RPKI in der RIPE-Region. Sie brauchen eine aktive RIPE NCC Mitgliedschaft (LIR-Status), und das Subnetz muss unter Ihrem Ressourcenzertifikat in der RIPE-Datenbank registriert sein.

1. Im RIPE NCC Portal anmelden. Öffnen Sie my.ripe.net und melden Sie sich mit Ihren LIR-Zugangsdaten an. Gehen Sie in Ihrem Dashboard zum RPKI-Bereich.

2. Ihr Ressourcenzertifikat finden. Es listet die IP-Blöcke, die Ihrer Organisation zugewiesen oder zugeteilt sind. Bestätigen Sie, dass das Subnetz, das Sie schützen möchten, dort erscheint, bevor Sie fortfahren.

3. ROA anlegen. Wählen Sie das Subnetz, geben Sie die ASN ein, die es ankündigen wird, und legen Sie die maximale Präfixlänge fest.

4. Maximale Länge sorgfältig setzen. Das ist der folgenreichste Parameter, und von hier stammt fast jeder selbst verursachte Ausfall bei RPKI. Die Regel: genau Ihren tatsächlichen Ankündigungen entsprechend, nicht großzügiger. Zu eng gesetzt, werden Ihre eigenen spezifischeren Ankündigungen Invalid. Zu weit gesetzt, lassen Sie eine Lücke, die ein Angreifer nutzen kann – einen spezifischeren Teilblock, der die Validierung trotzdem besteht. Beide Fehlerbilder behandelt der nächste Abschnitt.

5. Veröffentlichen und prüfen. Beim RIPE NCC erreichen ROAs Relying Parties unter normalen Bedingungen typischerweise innerhalb von 15–30 Minuten nach der Veröffentlichung. Auswirkungen auf die Datenebene folgen etwa im selben Zeitraum; einzelne Validator-Implementierungen können länger brauchen. Bestätigen Sie auf bgp.tools, dass die ROA als Valid zurückgegeben wird, bevor Sie die Konfiguration als abgeschlossen betrachten.

Eine ausführliche Anleitung mit Screenshots und Erklärungen zu jedem Feld finden Sie in unserem Leitfaden zur ROA-Erstellung im Help Center →

Häufige Fehler

Max-Length zu eng: auf den ganzen Block gesetzt, obwohl Sie Teilblöcke ankündigen. Halten Sie ein /22 und planen, es als vier /24 anzukündigen, muss die maximale Länge Ihrer ROA /24 sein – nicht /22. Eine ROA für ein /22 mit maxLength /22 markiert jede /24-Teilankündigung als Invalid, selbst aus Ihrer eigenen ASN. Der IP-Eigentümer macht damit versehentlich seine eigenen Routen ungültig.

Max-Length zu weit: weiter gesetzt als alles, was Sie tatsächlich ankündigen. Das Spiegelbild, und genauso schädlich. Halten Sie ein /22, kündigen es als ein einziges /22 an und setzen maxLength „zur Sicherheit“ auf /24, haben Sie einen Angreifer autorisiert, ein /24 aus Ihrem Block anzukündigen – und es wird als Valid validiert. Jeder Spielraum im Feld maxLength ist Spielraum, den Sie einem Hijacker überlassen.

Max-Length als Pauschallösung auf /32 (bzw. /128 bei IPv6) setzen. Die extreme Variante desselben Fehlers. Sie autorisiert jede spezifischere Ankündigung bis hinunter zu einer einzelnen Host-Adresse – genau die Art von Hijacking, die RPKI verhindern soll.

Eine ROA anlegen und die Verbreitung nicht prüfen. Eine ROA, die im RIPE NCC Portal existiert, sich aber nicht an Relying Parties verbreitet hat, schützt nicht. Prüfen Sie nach dem Anlegen immer mit einem externen Tool, nicht nur mit der Bestätigung des Portals.

Eine einzige ROA für ein Subnetz, das aus mehreren ASNs angekündigt wird. Wird Ihr Subnetz aus mehr als einer ASN angekündigt – für Redundanz, für BYOIP bei einem Cloud-Anbieter oder bei Multihoming –, brauchen Sie für jede autorisierte ASN eine eigene ROA. Eine ROA deckt genau eine Kombination aus Subnetz und ASN ab.

Vergessen, ROAs bei einem Wechsel der ankündigenden ASN zu aktualisieren. Wenn Sie den Upstream-Provider wechseln, auf eine neue ASN migrieren oder ins BYOIP-Programm eines Cloud-Anbieters wechseln, muss die ROA aktualisiert werden, bevor die neue Ankündigung live geht. Eine ungültige Ankündigung aus Ihrer eigenen Infrastruktur ist ein Ausfall.

Eine ROA still ablaufen lassen. Automatisieren Sie Verlängerungen, wo Ihre RIR es erlaubt. Eine abgelaufene ROA scheitert nicht sanft – sie ändert Ihren Routing-Zustand, ohne dass jemand einen Router anfasst.

RPKI beim IPv4-Leasing: Wer legt die ROA an?

Hier geraten die meisten durcheinander, deshalb lohnt sich Genauigkeit.

Nur der IP-Eigentümer – die Partei, die die RIR als Inhaber des Blocks anerkennt – kann eine ROA anlegen oder ändern. Der IP-Mieter kann das nicht. ROAs werden vom Ressourceninhaber angelegt, nicht von dem, der den Adressraum gerade nutzt oder ankündigt. Wird ein Subnetz geleast, muss die ROA also die Origin-ASN des Mieters autorisieren – denn der Mieter kündigt den Block tatsächlich an.

Ein vertrauenswürdiger Anbieter oder Broker übernimmt diese Abstimmung als Teil des Leasings, zusammen mit LOA und Route-Objekt. Wenn Sie IPv4-Adressen leasen und das komplett Ihnen überlassen wird, werten Sie das als Warnsignal.

Bei IPbnb ist die ROA-Abstimmung Teil jedes Leasings: Der Inhaber veröffentlicht die ROA für die ASN des Mieters, bevor der Block übergeben wird, zusammen mit LOA und Route-Objekt. Das ersetzt nicht Ihre eigenen Prüfungen – Sie sollten den ROA-Status vor der Ankündigung trotzdem auf bgp.tools bestätigen –, nimmt aber das Rätselraten heraus.

Eine Feinheit: Kündigt der IP-Eigentümer in Ihrem Namen an – eine übliche Variante bei gehostetem oder verwaltetem Leasing –, deckt die ROA dessen ASN ab, und Sie müssen sie nicht direkt verwalten. Bestätigen Sie, dass das der Fall ist, bevor Sie davon ausgehen.

BYOIP bei Cloud-Anbietern fügt eine weitere Ebene hinzu. AWS, GCP und Azure haben beim Onboarding jeweils eigene RPKI- und LOA-Anforderungen. Fehler bei der Subnetzvalidierung – einschließlich eines RPKI-Status Invalid – können die Annahme durch den Cloud-Anbieter blockieren oder erheblich verzögern.

RPKI einrichten: für Netzwerkbetreiber

Ihre eigenen Subnetze zu signieren schützt sie nur in dem Maß, in dem andere Netzwerke prüfen. Wenn Sie BGP betreiben – das gilt für die meisten IP-Mieter, die ihre eigenen Blöcke ankündigen –, sollten Sie ebenfalls validieren.

Einen RPKI-Validator wählen

Dann:

Installieren Sie mindestens zwei Validatoren. Verliert ein Router den Kontakt zu allen seinen Validatoren, wird jede Route still zu NotFound, und die Filterung endet. Ein zweiter Validator schützt davor.

Akzeptieren Sie den Vertrauensanker jeder RIR. Für ARIN müssen Sie dessen Relying Party Agreement zustimmen – ein separater Schritt gegenüber den anderen.

Verbinden Sie Ihre Router per RTR mit den Validatoren und setzen Sie die Richtlinie auf: Invalid verwerfen, Valid und NotFound akzeptieren. Verwerfen Sie NotFound nicht – ein großer Teil der Subnetze ist noch unsigniert, und das würde Sie von einem Großteil des Internets abschneiden.

Behandeln Sie RPKI als eine Ebene, nicht als gesamte Verteidigung. RPKI prüft, wer eine Route originiert, nicht den gesamten Pfad. Kombinieren Sie es mit Präfixfiltern, AS-Pfad-Filtern und Bogon-Filterung.

Tools zur BGP-Überwachung

Eine ROA anzulegen ist der erste Schritt. Laufendes Monitoring zeigt Ihnen, ob Ihr Subnetz korrekt angekündigt wird, ob nicht autorisierte Ankündigungen aufgetaucht sind und ob Ihre RPKI-Konfiguration wie erwartet funktioniert.

RIPEstat (stat.ripe.net) – das umfassendste kostenlose Tool für Betreiber in der RIPE-Region. BGP-Routing-Daten, Ankündigungen, AS-Pfad-Informationen und RPKI-Status für jedes Subnetz. Die Ansicht der Routing-Historie ist besonders nützlich, um auffällige Ankündigungen zu erkennen, die auftauchten und wieder verschwanden – so zeigen sich Hijacking-Vorfälle häufig. Kein Konto nötig.

bgp.tools – übersichtlich und schnell, für die Sichtbarkeit von Subnetzen, AS-Informationen und Routing-Daten. Der schnellste Weg zu prüfen, welche ASNs ein bestimmtes Subnetz von wo ankündigen, und zu bestätigen, dass eine neue ROA als Valid zurückgegeben wird.

Cloudflare RPKI Validator (rpki.cloudflare.com) – zeigt den aktuellen ROA-Zustand eines Subnetzes und welche ROAs es aus welchen Vertrauensankern abdecken. Nützlich vor dem Leasing oder Erwerb eines Blocks. Das Begleittool isbgpsafeyet.com zeigt, ob Ihre eigenen Upstreams ungültige Routen tatsächlich verwerfen.

Cloudflare Radar (radar.cloudflare.com) – breiteres Monitoring von BGP und Internetzustand mit Statistiken zur RPKI-Verbreitung und Erkennung von Routing-Anomalien. Pro Subnetz weniger nützlich, für das Gesamtbild umso mehr.

NIST RPKI Monitor – die Referenzquelle für Statistiken zu globaler RPKI-Abdeckung und Durchsetzung und ein Plausibilitätscheck, wo Ihre Subnetze im Vergleich zum Rest der Tabelle stehen.

Alarmierung im Stil von BGPalerter und BGPmon – Echtzeit-Monitoring, das meldet, wenn ein überwachtes Subnetz plötzlich aus einer neuen ASN angekündigt wird oder Ihre Ankündigungen und ROAs auseinanderlaufen. In Produktionsumgebungen reichen passive Tools nicht; Sie brauchen Alarmierung, die Anomalien binnen Minuten erkennt und nicht erst, wenn Sie eine Dienststörung bemerken.

Das minimal sinnvolle Setup: RIPEstat für Grundsichtbarkeit und Historie, bgp.tools zur Bestätigung des ROA-Status nach jeder Änderung und mindestens ein Alarmierungsmechanismus für unerwartete Ankündigungen.

RPKI vs. IRR-Filterung

IRR – Internet Routing Registry – ist das ältere System. Netzwerke registrieren Route-Objekte in IRR-Datenbanken (RIPEs IRR, RADB, ARINs IRR und andere), die beschreiben, welche ASN welches Subnetz ankündigen darf. Upstream-Provider und Peers bauen daraus Präfixfilter und akzeptieren nur Ankündigungen, die zu registrierten Route-Objekten passen.

Die strukturelle Schwäche des IRR: Es ist nicht kryptografisch gesichert. Jeder kann ein Route-Objekt für ein Subnetz registrieren, das ihm nicht gehört, und IRR-Datenbanken enthielten historisch viele veraltete, ungenaue oder betrügerische Daten. Die Filterung hängt vollständig von der Genauigkeit freiwillig gepflegter Registry-Daten ab.

RPKI ist kryptografisch gesichert. ROAs werden vom Ressourceninhaber mit Schlüsseln signiert, die auf die RIR zurückgehen, und eine ROA kann nur anlegen, wer das zugehörige Ressourcenzertifikat hält. Das macht RPKI als Quelle für Routing-Autorisierungen deutlich vertrauenswürdiger als IRR.

Das Verhältnis ist ergänzend, nicht konkurrierend. Viele Netzwerke nutzen beides: IRR-Route-Objekte für die Kompatibilität mit älteren Filterimplementierungen und RPKI-ROAs für die kryptografische Validierung, wo sie durchgesetzt wird. Beides zu pflegen ist nicht redundant – sie bedienen unterschiedliche Teile des Filter-Ökosystems.

Für Betreiber in der RIPE-Region lautet die praktische Empfehlung: zuerst RPKI-ROAs anlegen, dann IRR-Route-Objekte parallel pflegen – für Netzwerke, die nach IRR filtern, aber ROV noch nicht vollständig eingeführt haben. Übernehmen Sie ein Subnetz – per Leasing, Erwerb oder Transfer –, prüfen Sie im Rahmen der Due Diligence sowohl den RPKI-Status als auch die IRR-Registrierungen. Eine Inkonsistenz zwischen beiden (etwa eine gültige ROA, aber ein veraltetes IRR-Route-Objekt mit einer früheren ASN) verursacht Routing-Probleme, die schwer zu diagnostizieren sind.

Was als Nächstes kommt: ASPA

RPKI validiert den Origin einer Route, nicht den gesamten Pfad. Damit bleibt die Lücke der Route Leaks: Der Origin stimmt, aber der Traffic läuft durch Netzwerke, durch die er nicht laufen sollte.

Die aufkommende Antwort ist ASPA – Autonomous System Provider Authorization –, ein neues RPKI-Objekt, in dem ein Netzwerk eine Liste seiner zugelassenen Upstream-Provider signiert.

Ein Realitätscheck, denn hier zählt Genauigkeit: Stand 2026 wird ASPA bei der IETF noch finalisiert, ist noch kein veröffentlichter Standard, und der reale Einsatz ist sehr gering. Auch BGPsec, die ältere Antwort auf dasselbe Problem, hat keinen Produktiveinsatz. ASPA sollten Sie beobachten, nicht einführen. Vorerst schützen korrekte ROAs und aktive Validierung Ihre Subnetze.

RPKI-Checkliste für IP-Inhaber

1. Bestätigen, dass jedes Subnetz, das Sie halten, in Ihrem RIR-Portal unter Ihrem Ressourcenzertifikat erscheint.

2. Für jedes Subnetz eine ROA anlegen, mit Hosted RPKI, sofern kein konkreter Grund dagegen spricht.

3. Max-Length genau passend zu Ihren tatsächlichen Ankündigungen setzen – nie weiter, nie enger.

4. Für jede ASN, die das Subnetz ankündigen darf, eine eigene ROA anlegen (Redundanz, Multihoming, BYOIP).

5. Die Verbreitung extern auf bgp.tools oder RIPEstat prüfen – nicht nur in Ihrem RIR-Portal.

6. Das IRR-Route-Objekt konsistent mit der ROA halten.

7. Alarmierung (BGPalerter o. Ä.) für Ankündigungen aus unerwarteten ASNs und für ROA-Abweichungen einrichten.

8. Verlängerungen automatisieren und ROAs vor jedem ASN-Wechsel aktualisieren – nicht danach.

Fazit

RPKI ist so wirksam, wie es verbreitet ist. Jeder IP-Eigentümer, der ROAs anlegt, und jedes Netzwerk, das ungültige Routen verwirft, macht das System für alle anderen robuster.

Es hat sich von „nice to have“ zu „wird erwartet“ entwickelt. Für IP-Eigentümer schützt eine korrekte ROA Ihre Subnetze vor Hijacks und hält sie vertrauenswürdig und wertvoll. Für IP-Mieter ist die Bestätigung, dass ein geleaster Block korrekt signiert ist, der Unterschied zwischen Adressen, die sauber geroutet werden, und Adressen, die verworfen werden. Die Einrichtung dauert Minuten. Die Sorgfalt gilt einem Detail: der richtigen maximalen Präfixlänge.

Wenn Sie IP-Blöcke besitzen oder leasen und nicht sicher sind, ob Ihre RPKI-Einträge korrekt sind, prüfen Sie das als Erstes. Der Rest des Internets prüft es zunehmend ohnehin für Sie.

FAQ

Was ist RPKI einfach erklärt?

RPKI (Resource Public Key Infrastructure) ist ein Weg, kryptografisch nachzuweisen, wer einen bestimmten IP-Block im Internet ankündigen darf. Jede Regional Internet Registry stellt dem Inhaber eines Blocks ein digitales Zertifikat aus, mit dem er Aussagen darüber signiert, wer diesen Adressraum routen darf. Stellen Sie es sich als Grundbuch für IP-Adressen vor: Es verhindert eine falsche Behauptung nicht physisch, lässt aber jeden den offiziellen Eintrag prüfen.

Was ist eine ROA (Route Origin Authorization)?

Eine ROA ist eine kleine, digital signierte Erklärung, die ein IP-Inhaber erstellt. Sie hält drei Dinge fest: das Subnetz, die ASN, die es ankündigen darf, und die maximale Präfixlänge, die diese ASN ankündigen darf. Einmal veröffentlicht, kann jedes Netzwerk sie herunterladen und damit entscheiden, ob es einer Route vertraut.

Kann ein IP-Mieter eine ROA für ein geleastes Subnetz anlegen?

Nein. Nur der IP-Eigentümer – die Partei, die die RIR als Inhaber des Blocks anerkennt – kann eine ROA anlegen oder ändern. Bei einem Leasing muss der Eigentümer eine ROA veröffentlichen, die die Origin-ASN des Mieters autorisiert, bevor der Mieter mit der Ankündigung beginnt. Ändert sich die ASN des Mieters oder endet das Leasing, aktualisiert oder entfernt der Eigentümer sie.

Was passiert, wenn eine Route RPKI-Invalid ist?

Eine ungültige Route wird von jedem Netzwerk verworfen, das RPKI durchsetzt, darunter alle bis auf einen der Tier-1-Transit-Provider des Internets. Praktisch heißt das, Ihr Traffic wird verworfen. Invalid weist entweder auf einen Hijack hin oder – häufiger – auf eine Fehlkonfiguration, meist eine maximale Länge, die nicht zu Ihren tatsächlichen Ankündigungen passt. Eine falsche ROA ist schlimmer als gar keine.

Verlangen AWS, Google Cloud und Azure RPKI für BYOIP?

Ja. Alle drei verlangen beim BYOIP-Onboarding eine korrekte ROA, die die ASN des Cloud-Anbieters autorisiert, zusammen mit einem Letter of Authorization. Ein Subnetz mit RPKI-Status Invalid wird abgelehnt oder erheblich verzögert. Wenn Sie den Adressraum leasen, muss der IP-Eigentümer die ROA anlegen, bevor Sie mit dem Onboarding beginnen.