Das Internet ist auf ein globales Routing-System angewiesen, das es Netzwerken, Rechenzentren, Cloud-Plattformen, Internetdienstanbietern und Unternehmen ermöglicht, Datenverkehr auszutauschen. Eines der wichtigsten Protokolle in diesem System ist das Border Gateway Protocol, allgemein bekannt als BGP. BGP ermöglicht es autonomen Systemen, anzukündigen, welche IP-Adressbereiche sie erreichen können. Ohne BGP könnte das moderne Internet nicht Millionen von Netzwerken über verschiedene Länder und Anbieter hinweg verbinden. Allerdings wurde BGP ursprünglich entwickelt, um Routing-Informationen hauptsächlich auf Basis von Vertrauen auszutauschen. Wenn ein Netzwerk eine IP-Präfix-Ankündigung sendet, können andere Netzwerke diese Ankündigung akzeptieren, ohne über starke kryptografische Methoden zu verfügen, die bestätigen, ob das ankündigende Netzwerk tatsächlich berechtigt ist, dieses Präfix zu verwenden. Dies führt zu einem Sicherheitsproblem. Eine falsche oder böswillige Routenankündigung kann den Datenverkehr umleiten, Dienste unterbrechen oder Daten unerwünschten Pfaden aussetzen.
RPKI wurde entwickelt, um die Sicherheit des Internet-Routings zu verbessern. Der Name steht für Resource Public Key Infrastructure. Es bietet eine Möglichkeit, Internet-Nummernressourcen, wie IPv4- und IPv6-Präfixe, mit der Autonomous System Number (ASN) zu verbinden, die autorisiert ist, diese zu originiert. Netzwerkbetreiber können dann diese Informationen nutzen, um festzustellen, ob eine BGP-Ankündigung mit der aufgezeichneten Autorisierung übereinstimmt.
Für Unternehmen, die ihr eigenes ASN betreiben, IP-Ressourcen verwalten, mehrere Upstream-Provider nutzen oder planen, IPv4- oder IPv6-Adressräume anzukündigen, wird das Verständnis von RPKI zunehmend wichtiger. RPKI ersetzt BGP nicht und löst nicht jedes Routing-Problem. Stattdessen bietet es eine zusätzliche Verifikationsschicht, die Netzwerken hilft, sicherere Routing-Entscheidungen zu treffen.
Was ist RPKI?
RPKI ist ein Sicherheitsframework, das digitale Zertifikate und kryptografische Datensätze verwendet, um die Beziehung zwischen einem IP-Adresspräfix und einem Ursprungs-ASN zu verifizieren. Ein IP-Präfix ist ein Block von Adressen, wie zum Beispiel ein IPv4 /24 or an IPv6 /48. Eine ASN identifiziert ein unabhängiges Netzwerk, das am BGP-Routing teilnimmt.
Die Grundidee ist einfach. Eine Organisation, die berechtigt ist, ein IP-Präfix zu verwenden, veröffentlicht eine signierte Erklärung, die angibt, welche ASN (Autonomous System Number) dieses Präfix im BGP (Border Gateway Protocol) originieren darf. Netzwerke, die BGP-Ankündigungen empfangen, können diese Ankündigung mit den veröffentlichten Informationen vergleichen. Wenn die Ankündigung übereinstimmt, kann sie als autorisiert behandelt werden. Wenn sie im Widerspruch zu den vorliegenden Informationen steht, kann die Ankündigung als verdächtig oder ungültig betrachtet werden.
Die zur Ausdruckung dieser Autorisierung verwendeten Aufzeichnungen werden allgemein als Route Origin Authorizations (ROAs) bezeichnet. Eine ROA identifiziert ein IP-Präfix, eine autorisierte Ursprungs-ASN und, falls zutreffend, die maximale Präfixlänge, die die ASN ankündigen darf. Obwohl ROAs ein wichtiger Bestandteil von RPKI sind, konzentriert sich dieser Artikel auf den umfassenderen Zweck von RPKI und darauf, wie er die Routing-Sicherheit verbessert.
RPKI wird im Allgemeinen über die Regionalen Internet-Registrierungsstellen betrieben, darunter RIPE NCC, ARIN, APNIC, LACNIC und AFRINIC. Je nach Region und Ressourcentyp kann der Ressourceninhaber oder die fördernde Organisation die entsprechenden Autorisierungsdatensätze über die Systeme der Registrierungsstelle erstellen und verwalten.
Warum benötigt BGP RPKI?
BGP wurde zu einer Zeit entwickelt, als das Internet noch kleiner war und die Anzahl der teilnehmenden Netzwerke begrenzt. Sein Hauptzweck bestand im Austausch von Erreichbarkeitsinformationen zwischen autonomen Systemen. BGP kann Pfade basierend auf Richtlinien, Pfadlänge, lokaler Präferenz und anderen Attributen auswählen, aber das Protokoll selbst überprüft nicht automatisch, ob eine ASN berechtigt ist, ein bestimmtes IP-Präfix zu originate.
Dies bedeutet, dass ein Konfigurationsfehler manchmal ähnlich wie eine bösartige Ankündigung aussehen kann. Wenn ein Netzwerk versehentlich ein Präfix ankündigt, das einer anderen Organisation gehört, können andere Netzwerke die Route zunächst akzeptieren. Die Folge kann sein, dass Datenverkehr an das falsche Ziel geleitet wird, Verbindungsprobleme auftreten oder das Routing instabil wird.
Ein bekanntes Beispiel ist ein Route Leak oder Prefix Hijack. Bei einem Hijack kündigt eine ASN einen Prefix an, den sie nicht kontrolliert oder von dem sie nicht die Ursprünge haben sollte. Die Ankündigung kann spezifischer sein als die legitime Route oder genügend Netzwerke erreichen, um den Traffic zu beeinflussen. Selbst wenn der Vorfall unbeabsichtigt ist, kann die operative Auswirkung erheblich sein.
RPKI unterstützt Netzwerkbetreiber, indem es eine externe Quelle für Autorisierungsinformationen bereitstellt. Anstatt sich ausschließlich auf den Inhalt einer BGP-Ankündigung zu verlassen, kann ein Router oder ein Routing-Sicherheitssystem prüfen, ob die Ursprungs-ASN vom Inhaber des Adressraums autorisiert wurde. Dies verhindert nicht jeden Routing-Zwischenfall, erleichtert jedoch die Identifizierung und Filterung einer wichtigen Klasse von Routing-Fehlern.
Wie funktioniert RPKI?
RPKI funktioniert über eine Vertrauenskette. Internet-Nummernressourcen werden von Regionalen Internetregistrierungsstellen verwaltet, und diese Registrierungsstellen bilden die Grundlage für die entsprechenden digitalen Zertifikate. Der Inhaber einer IP-Ressource kann einen Autorisierungseintrag erstellen, der angibt, welche ASN das Präfix originated darf.
Die signierten Datensätze werden in Repositorien gesammelt, die von Routing-Sicherheitssoftware abgerufen werden können. Ein Netzwerkbetreiber betreibt einen RPKI-Validator oder nutzt einen Dienst, der die Validierung für ihn durchführt. Der Validator lädt die verfügbaren Datensätze herunter, überprüft deren Signaturen, prüft, ob sie aktuell sind, und erzeugt einen validierten Datensatz.
Der validierte Datensatz wird anschließend mit der Routing-Infrastruktur des Netzwerks verbunden. Wenn eine BGP-Routeninformation empfangen wird, vergleicht der Router oder das Routing-Policy-System den angekündigten Prefix und die Ursprungs-ASN mit den validierten RPKI-Informationen. Das Ergebnis wird normalerweise als „Valid“, „Invalid“ oder „Not Found“ klassifiziert.
Dieser Prozess erfolgt unabhängig von der BGP-Sitzung selbst. BGP setzt den Austausch von Routing-Informationen fort, während RPKI zusätzliche Autorisierungsdaten bereitstellt, die in der Routing-Policy verwendet werden können. Ein Netzwerk kann entscheiden, wie es jedes Validierungsergebnis behandelt. Beispielsweise kann es ungültige Routen ablehnen, ihnen eine geringere Priorität zuweisen oder Warnungen zur weiteren Überprüfung generieren.
Der Prozess ist so konzipiert, dass er verteilt und skalierbar ist. Große Netzwerke können viele Tausend Präfixe validieren, ohne dass jede Organisation eine direkte Beziehung zu jedem anderen Netzwerk aufbauen muss. Dies ist wichtig, da das Internet eine enorme Anzahl unabhängiger Betreiber mit unterschiedlichen Richtlinien und technischen Umgebungen umfasst.
Was ist eine Route Origin Authorization?
Eine Route Origin Authorization (ROA) ist ein signierter Eintrag, der angibt, welche ASN berechtigt ist, ein bestimmtes IP-Präfix zu origo. Sie ist einer der sichtbarsten und praktischsten Teile der RPKI-Bereitstellung.
Zum Beispiel kann eine Organisation das IPv4-Präfix kontrollieren 192.0.2.0/24 und verwenden Sie ASN AS64500 um es bekannt zu geben. Die Organisation kann eine Berechtigung erstellen, die AS64500 entstehen 192.0.2.0/24Wenn ein anderes ASN später dasselbe Prefix ankündigt, können Netzwerke, die RPKI-Validierung durchführen, feststellen, dass der Ursprung nicht mit der Autorisierung übereinstimmt.
Die Autorisierung kann auch eine maximale Präfixlänge angeben. Dies ist wichtig, da ein Netzwerk möglicherweise das Ankündigen des genauen Aggregatpräfixes durch die Ursprungs-ASN zulassen möchte, nicht jedoch kleinerer, spezifischerer Präfixe. Eine sorgfältig ausgewählte maximale Länge kann das Risiko verringern, dass eine unerwartete Ankündigung als autorisiert behandelt wird.
Die ROA-Konfiguration erfordert Aufmerksamkeit, da ein falscher Eintrag eine legitime Route ungültig erscheinen lassen kann. Wenn eine Organisation ihren Transitanbieter wechselt, ein Präfix zu einer anderen ASN verschiebt, eine Ankündigung in spezifischere Präfixe aufteilt oder Ressourcen an einen anderen Inhaber überträgt, müssen die Autorisierungseinträge möglicherweise aktualisiert werden. Ein veralteter Eintrag kann selbst bei korrekter BGP-Konfiguration zu einem Ausfall führen.
Ein zukünftiger Artikel kann erklären, wie man ein ROA erstellt, wie man eine maximale Länge auswählt und wie man Autorisierungen während einer ASN- oder IP-Ressourcenmigration aktualisiert.
Was bedeuten „Gültig“, „Ungültig“ und „Nicht gefunden“?
Ein Valid-Ergebnis bedeutet, dass eine BGP-Ankündigung von einer anwendbaren RPKI-Autorisierung abgedeckt ist und dass die Ursprungs-ASN das Ankündigen des Präfixes erlaubt. Es zeigt in der Regel an, dass das angekündigte Präfix, die Präfixlänge und die Ursprungs-ASN mit der veröffentlichten Autorisierung übereinstimmen.
Ein ungültiges Ergebnis bedeutet, dass eine Autorisierung existiert, die BGP-Ankündigung jedoch nicht damit übereinstimmt. Dies kann geschehen, weil der Ursprungs-ASN nicht autorisiert ist, weil die Ankündigung spezifischer als die zulässige maximale Länge ist oder weil das Präfix mit einer Autorisierung für einen anderen Ursprung überlappt. Ungültige Routen erfordern sofortige Aufmerksamkeit, da sie einen Hijack, eine versehentliche Konfiguration oder eine unvollständige Migration darstellen können.
Ein „Not Found“-Ergebnis bedeutet, dass keine anwendbare Autorisierung für die Ankündigung gefunden wurde. Es bedeutet nicht automatisch, dass die Route bösartig oder falsch ist. Es bedeutet lediglich, dass RPKI den Ursprung anhand der aktuell veröffentlichten Datensätze nicht bestätigen kann. Viele legitime Routen bleiben als „Not Found“ markiert, weil der Ressourceninhaber keine Autorisierung erstellt hat.
Die Unterscheidung zwischen „Invalid“ (ungültig) und „Not Found“ (nicht gefunden) ist wichtig. „Invalid“ weist auf einen Konflikt mit bestehenden Autorisierungsdaten hin, während „Not Found“ das Fehlen von Autorisierungsdaten anzeigt. Netzbetreiber behandeln oft ungültige Routen ernster, doch ihre genaue Routing-Politik hängt von ihrer Risikotoleranz, den Serviceanforderungen und den Betriebsverfahren ab.
Why RPKI Matters for IPv4 Networks
Der IPv4-Adressraum ist begrenzt, und viele IPv4-Präfixe werden heute in komplexen Arrangements eingesetzt, die Anbieter, Rechenzentren, Cloud-Plattformen, Leasingunternehmen und Übertragungsgeschäfte umfassen. Diese Arrangements machen eine präzise Routing-Genauigkeit besonders wichtig.
Wenn ein IPv4-Präfix zwischen Organisationen übertragen oder verschoben wird, kann sich auch der BGP-Origin ändern. Wenn die Autorisierung des vorherigen Inhabers weiterhin aktiv ist und der neue Inhaber das Präfix von einer anderen ASN aus ankündigt, kann die Route zu RPKI Invalid werden. Dies ist einer der Gründe, warum RPKI-Planung in IPv4-Übertragungs- und Migrationsarbeiten einbezogen werden sollte.
Bevor eine Organisation ein IPv4-Präfix akzeptiert oder ankündigt, sollte sie bestätigen, welche Entität die Ressource kontrolliert, welche ASN erwartet wird, es zu originated, und ob die relevanten Autorisierungsdaten den geplanten Routing-Entwurf widerspiegeln. Die öffentlichen Registry-Einträge, BGP-Ankündigungen und RPKI-Informationen sollten gemeinsam überprüft werden. RPKI ist besonders nützlich, wenn ein Unternehmen mehrere Transitanbieter nutzt. Eine konsistente Ursprungsautorisation kann das Präfix unabhängig davon schützen, welcher Upstream-Anbieter die Route trägt. Dennoch muss die Organisation sicherstellen, dass alle Anbieter die korrekte ASN und Präfixlänge verwenden.
Unternehmen, die einen IPv4-Block bewerten, können auch öffentliche Tools nutzen, um aktuelle Registrierungsdaten, Informationen zum Ursprungs-ASN, den RPKI-Status und die BGP-Sichtbarkeit zu überprüfen. Diese Prüfungen ersetzen keine vertragliche Due-Diligence oder Reputationsscreening, können jedoch offensichtliche Routing-Inkonsistenzen vor einer Transaktion oder Implementierung aufdecken.
Why RPKI Matters for IPv6 Networks
IPv6-Netzwerke profitieren von denselben Validierungsprinzipien für den Ursprung wie IPv4-Netzwerke. IPv6-Präfixe werden über BGP angekündigt, und ein falscher Ursprung kann ähnliche Risiken verursachen, darunter Verkehrsunterbrechungen, Route-Leaks und unbefugte Ankündigungen.
IPv6-Implementierungen beinhalten häufig größere Adressblöcke und strukturiertere Adressierungspläne. Eine Organisation kann eine breite Zuteilung erhalten und ein Aggregat ankündigen, während sie kleinere interne Subnetze für Standorte, Rechenzentren oder Dienste verwendet. Die RPKI-Autorisierung sollte mit den Präfixen übereinstimmen, die tatsächlich für das öffentliche Routing vorgesehen sind.
Ein häufiger Fehler besteht darin, anzunehmen, dass IPv6-Routing automatisch sicherer ist, weil IPv6 über einen viel größeren Adressraum verfügt. Die Größe des Adressraums beseitigt nicht die Notwendigkeit, den Ursprung von Routen zu überprüfen. Wenn ein IPv6-Präfix von einer falschen ASN angekündigt wird und keine Autorisierung vorliegt, können andere Netzwerke die Ankündigung nur schwer von einer legitimen Route unterscheiden. Organisationen, die IPv6 einführen, sollten RPKI bereits in ihre initiale Routing-Planung aufnehmen, anstatt abzuwarten, bis das Netzwerk vollständig betriebsbereit ist. Dies erleichtert die Koordination des Adressplans, der ASN-Nutzung, der Upstream-Anbieter und der Autorisierungsdatensätze, bevor der Produktionsverkehr von der Ankündigung abhängt.
Was sind die Hauptvorteile von RPKI?
Der Hauptvorteil von RPKI besteht darin, dass es eine weithin anerkannte Methode zur Validierung des Ursprungs einer BGP-Routen bereitstellt. Dies gibt Netzwerkadministratoren eine stärkere Grundlage für die Filterung und Überwachung von Ankündigungen als alleinige BGP-Informationen.
RPKI kann das Risiko verringern, Routen zu akzeptieren, die eindeutig mit der vom Ressourceninhaber angegebenen Autorisierung unvereinbar sind. Es kann auch dazu beitragen, operative Fehler während Netzwerkmigrationen, Providerwechseln, Änderungen der ASN-Sponsoring-Verhältnisse sowie IPv4- oder IPv6-Ressourcenübertragungen zu identifizieren.
Für IP-Ressourceninhaber zeigt RPKI, dass die Organisation die Routing-Sicherheit ihres Adressraums aktiv verwaltet. Dies kann die Koordination mit Transit-Providern verbessern und Verwirrung reduzieren, wenn mehrere Parteien dieselbe Prefix ankündigen.
Für Transitanbieter und Hosting-Unternehmen kann die RPKI-Validierung Teil eines umfassenderen Routing-Sicherheitsprogramms werden. Anbieter können Validierungsergebnisse zusammen mit Prefix-Filtern, IRR-Daten, BGP-Monitoring und internen Routing-Richtlinien nutzen. Keine einzelne Datenquelle ist perfekt, aber die Kombination mehrerer Signale bietet eine bessere operative Transparenz.
RPKI verbessert auch die Incident Response. Wenn eine unerwartete BGP-Ankündigung erscheint, kann das Netzwerkteam schnell prüfen, ob der Ursprung autorisiert ist. Dies kann helfen, einen potenziellen Hijack von einer legitimen, aber nicht dokumentierten Routing-Änderung zu unterscheiden.
Was RPKI nicht leisten kann
RPKI ist wertvoll, stellt jedoch keinen vollständigen Ersatz für die Routing-Sicherheit dar. Es validiert die Beziehung zwischen einem Prefix und einem Ursprungs-ASN. Es beweist nicht, dass jeder Hop im BGP-Pfad vertrauenswürdig ist, und es garantiert auch nicht, dass der Verkehr den besten oder sichersten physischen Weg nimmt.
RPKI verschlüsselt keinen Anwendungsdatenverkehr. Es schützt keine Websitzungen, DNS-Abfragen, E-Mails oder private Daten vor Abhörangriffen. Für diese Zwecke sind weiterhin Verschlüsselungstechnologien wie TLS, VPNs und sichere Anwendungsprotokolle erforderlich.
RPKI verhindert auch nicht automatisch jede Weitergabe von Routen. Eine Route kann zwar vom korrekten ASN originär bereitgestellt werden, aber dennoch an Stellen weitergeleitet werden, an denen sie nicht erscheinen sollte. Die Ursprungsvalidierung kann eine solche Route als „Valid“ einstufen, da der Ursprung autorisiert ist, obwohl der übergeordnete Pfad operativ falsch ist.
RPKI beweist nicht allein den rechtlichen Eigentumsstatus. Einträge in Registern, Verträge, Übertragungsdokumente und die organisatorische Autorisierung bleiben wichtig. Ein „Valid“-Ergebnis zeigt an, dass die Route mit einer veröffentlichten Berechtigung übereinstimmt; es bestätigt jedoch nicht, dass alle kommerziellen oder rechtlichen Anforderungen erfüllt sind.
Schließlich funktioniert RPKI nur effektiv, wenn die Einträge gepflegt werden. Eine Organisation, die Autorisierungen erstellt und vergisst, diese nach einem Provider- oder ASN-Wechsel zu aktualisieren, kann ihre eigenen Routing-Ausfälle verursachen.
Wie kann ein Unternehmen mit der Nutzung von RPKI beginnen?
Der erste Schritt besteht darin, ein Verzeichnis aller IPv4- und IPv6-Präfixe zu erstellen, die die Organisation besitzt, pachtet, sponsert oder ankündigen wird. Für jedes Präfix sind der beabsichtigte Ursprungs-ASN, die ankündigenden Provider, die Präfixlänge sowie die aktuelle Sichtbarkeit im BGP zu dokumentieren.
Der nächste Schritt besteht darin, die Registry- und Ressourcen-Einträge zu bestätigen. Die Organisation sollte sicherstellen, dass der Adressraum mit dem richtigen Konto, der Organisation, dem fördernden LIR oder dem Ressourceninhaber verknüpft ist. Wenn die öffentlich zugänglichen Registrierungsdaten veraltet sind, sollten sie vor der Erstellung neuer Routing-Autorisierungen korrigiert werden. Nach Bestätigung des Ressourceninventars kann die Organisation die entsprechenden Autorisierungseinträge über ihre regionale Internet-Registry oder ihren fördernden Provider erstellen. Die Ursprungs-ASN und die maximale Präfixlänge sollten den tatsächlichen Routing-Plan widerspiegeln. Wenn mehrere ASNs rechtmäßig verwendet werden, sollte das Design sorgfältig dokumentiert werden, anstatt breite Autorisierungen ohne klaren Grund hinzuzufügen.
Die Organisation sollte die Datensätze anschließend mit einem RPKI-Validator oder einem etablierten Überwachungsdienst validieren. Es ist wichtig zu bestätigen, dass die beabsichtigten Ankündigungen ein „Valid“-Ergebnis zurückgeben, bevor strenge Filterrichtlinien für Kunden- oder Produktionsverkehr angewendet werden.
Das Deployment sollte als ein operativer Prozess betrachtet werden, nicht als einmalige Konfigurationsaufgabe. Änderungen an Upstream-Providern, ASN-Sponsoring, Prefix-Aggregation, Rechenzentrumsstandorten und IPv4-Transfervereinbarungen können sich alle auf RPKI-Datensätze auswirken. Überwachung und Änderungsmanagement sollten Teil des normalen Netzwerkworkflows sein.
Häufige Fehler bei der RPKI-Bereitstellung
Ein häufiger Fehler besteht darin, eine Autorisierung für die falsche Ursprungs-ASN zu erstellen. Dies geschieht oft während einer Anbietermigration, wenn die alte ASN weiterhin im Record enthalten ist, das Netzwerk jedoch bereits Ankündigungen von einer neuen ASN aus sendet.
Ein weiterer Fehler besteht darin, die maximale Präfixlänge falsch festzulegen. Wenn eine Organisation nur ein Aggregat autorisiert, aber einen spezifischeren Route ankündigt, kann die Ankündigung des spezifischeren Pfads ungültig werden. Wenn die maximale Länge zu weit gefasst wird, kann die Autorisierung Ankündigungen zulassen, die die Organisation nicht hätte erlauben wollen.
Veraltete Datensätze sind ebenfalls ein großes Problem. Eine Autorisierung, die vor einigen Jahren noch korrekt war, entspricht möglicherweise nicht mehr dem aktuellen Netzwerkdesign der Organisation. Regelmäßige Überprüfungen sind insbesondere nach einem IPv4-Transfer, einer Fusion, einem Wechsel des fördernden LIR oder einer ASN-Renummerierung besonders wichtig.
Einige Organisationen gehen auch davon aus, dass ein „Not Found“-Ergebnis bedeutet, dass eine Route abgelehnt werden sollte. In den meisten Fällen bedeutet „Not Found“, dass keine Autorisierung vorliegt. Dies sollte gemäß der Richtlinie und dem Risikomodell des Netzwerks behandelt werden, anstatt automatisch als böswillig eingestuft zu werden.
RPKI, IRR und BGP-Monitoring
RPKI ist ein Teil eines umfassenderen Ansatzes zur Routing-Sicherheit. IRR-Datenbanken enthalten Routing-Policy-Objekte, die von Netzwerk-Betreibern zur Generierung von Filtern verwendet werden können. Diese Objekte können beschreiben, welche ASN erwartet wird, ein Prefix zu originiert, aber sie verwenden ein anderes Vertrauens- und Validierungsmodell als RPKI.
Die BGP-Überwachung zeigt, was tatsächlich angekündigt wird und wo die Ankündigung sichtbar ist. Sie kann Routenänderungen, unerwartete Ursprünge, Pfadänderungen und Phasen der Instabilität aufdecken. RPKI zeigt an, ob der Ursprung autorisiert ist, liefert jedoch nicht die vollständige operative Historie einer Route.
Aus diesem Grund werden RPKI, IRR und BGP-Monitoring häufig gemeinsam eingesetzt. Eine umfassende Routing-Überprüfung kann den Registry-Eintrag, die erwartete ASN, das IRR-Objekt, die RPKI-Autorisierung und live BGP-Beobachtungen vergleichen. Wenn diese Quellen übereinstimmen, ist die Routing-Situation leichter zu verstehen. Wenn sie nicht übereinstimmen, sollte der Unterschied vor Abschluss einer Migration oder eines Transfers untersucht werden.
Wie sollte RPKI gewartet werden?
Die RPKI-Wartung sollte mit dem Netzwerk-Änderungsmanagement verknüpft sein. Wenn eine Organisation plant, ihre Ursprungs-ASN, ihren Upstream-Anbieter, die Präfixlänge oder den Ankündigungsstandort zu ändern, sollte sie vor der Änderung die erwarteten Auswirkungen auf die Autorisierungsdatensätze überprüfen.
Das Monitoring sollte das Netzwerkteam alarmieren, wenn ein erwarteter Prefix ungültig wird, eine Autorisierung entfernt wird oder ein zuvor unbekannter Origin auftritt. Alarme sind am nützlichsten, wenn sie den betroffenen Prefix, die AS-Nummer des Origins, den aktuellen Validierungsstatus und den Zeitpunkt der Änderung enthalten.
Organisationen sollten auch dokumentieren, wer für das Management von RPKI verantwortlich ist. In einigen Unternehmen übernimmt dies das Netzwerk-Engineering-Team, in anderen der fördernde LIR, der Managed-Service-Anbieter oder das Sicherheitsteam. Eine klare Zuständigkeit hilft, Verzögerungen bei Störfällen und Providerwechseln zu vermeiden.
Eine periodische Überprüfung kann monatlich, vierteljährlich oder bei jeder größeren Änderung der Routing-Konfiguration geplant werden. Die geeignete Häufigkeit hängt von der Größe und Komplexität des Netzwerks ab. Der wichtige Punkt ist, dass RPKI als lebendiger Bestandteil des Routersystems behandelt werden sollte.
Häufig gestellte Fragen zu RPKI
Ist RPKI erforderlich, um BGP zu verwenden?
Nein. Ein Netzwerk kann BGP verwenden, ohne RPKI-Autorisierungsdatensätze zu veröffentlichen. Allerdings wird RPKI zunehmend empfohlen, da es anderen Netzwerken eine Möglichkeit bietet, die Herkunft der von der Organisation angekündigten Routen zu validieren.
Verhindert RPKI einen BGP-Hijack?
RPKI verhindert nicht physisch, dass ein anderes Netzwerk eine unbefugte BGP-Ankündigung sendet. Es ermöglicht empfangenden Netzwerken, Ankündigungen zu identifizieren, die nicht mit den veröffentlichten Autorisierungen übereinstimmen. Die Netzwerke können diese Routen dann gemäß ihren Richtlinien ablehnen, herabstufen oder überwachen.
Ist RPKI nur für IPv4?
No. RPKI supports both IPv4 and IPv6 prefixes. The same basic origin validation concept applies to both address families.
Ist ein RPKI-„Not Found“-Ergebnis gefährlich?
Nicht unbedingt. „Not Found“ bedeutet, dass keine gültige Autorisierung gefunden wurde. Es beweist nicht, dass die Route falsch ist. Ressourceninhaber sollten jedoch genaue Autorisierungen veröffentlichen, damit andere Netzwerke ihre Ankündigungen validieren können.
Kann RPKI ein IRR-Route-Objekt ersetzen?
Nr. RPKI und IRR dienen unterschiedlichen Zwecken und werden häufig zusammen verwendet. Einige Anbieter nutzen beide Systeme beim Erstellen von Routing-Filtern und bei der Überprüfung von Ankündigungen.
Was passiert, wenn ein RPKI-Eintrag falsch ist?
Ein falscher Eintrag kann dazu führen, dass eine legitime BGP-Ankündigung als ungültig klassifiziert wird. Die Organisation sollte die Ursprungs-ASN, die Präfixlänge und die maximale Länge überprüfen und dann die Autorisierung aktualisieren, bevor sie strikte Routenfilterung anwendet.
RPKI is an important improvement to the security of Internet routing. It gives IP resource holders a way to publish cryptographic authorization for the ASNs that are allowed to originate their IPv4 and IPv6 prefixes. It also gives network operators a practical method for checking whether BGP announcements match that authorization.
Das Konzept ist einfach: Der Inhaber eines IP-Präfixes veröffentlicht den beabsichtigten Ursprung, und andere Netzwerke validieren die Ankündigung anhand dieser Informationen. Das Ergebnis kann helfen, autorisierte Routen, widersprüchliche Routen sowie Routen zu identifizieren, für die keine Autorisierung veröffentlicht wurde. RPKI ersetzt nicht sorgfältige Netzwerktechnik, Registry-Verwaltung, IRR-Einträge, BGP-Monitoring oder vertragliche Sorgfaltspflichtprüfung. Es garantiert auch nicht, dass jede Route sicher ist oder jeder Routing-Zwischenfall verhindert wird. Sein Wert liegt darin, dem Routing-Prozess ein zuverlässiges Autorisierungssignal hinzuzufügen.
Für Organisationen, die eine ASN, IPv4-Adressraum, IPv6-Adressraum oder mehrere Upstream-Provider verwalten, sollte RPKI in das normale Routing-Design integriert werden. Bevor ein Prefix angekündigt, Provider gewechselt, ein IPv4-Transfer abgeschlossen oder ein neues IPv6-Netzwerk bereitgestellt wird, sollten die Registry-Daten, die Ursprungs-ASN, die Autorisierungsdaten und der aktuelle BGP-Zustand gemeinsam überprüft werden. Dieser einfache Prozess kann vermeidbare Fehler verhindern und die allgemeine Zuverlässigkeit der Internetverbindung verbessern.