Eine Route Origin Authorization ist eine digital signierte RPKI Ein Record, der identifiziert, welche ASN berechtigt ist, ein IP-Präfix in BGP zu originiieren. Er wird von der Organisation erstellt, die die relevanten Internet-Nummernressourcen hält, oder im Namen dieser Organisation. Ein ROA enthält normalerweise drei wesentliche Elemente: das IP-Präfix, die autorisierte Ursprungs-Autonome Systemnummer (ASN) und die maximale Präfixlänge, die die ASN ankündigen darf. Zum Beispiel kann eine Organisation das IPv4-Präfix 203.0.113.0/24 kontrollieren und AS64500 verwenden, um es anzukündigen. Ein entsprechender ROA kann AS64500 autorisieren, dieses /24-Präfix zu originiieren. Einfach ausgedrückt übermittelt der Record folgende Anweisung an das Routing-Ökosystem: „Diese ASN ist berechtigt, dieses Präfix anzukündigen.“ Netzwerke, die RPKI-Validierung durchführen, können den Record dann mit dem vergleichen, was sie in BGP beobachten. Ein ROA überträgt nicht den Besitz eines IP-Adressblocks. Er ersetzt keinen Vertrag, keinen Registry-Eintrag, keinen Allokationsrecord oder keine IPv4-Transfervereinbarung. Er veröffentlicht lediglich eine Berechtigung in Bezug auf den Ursprung einer Route. Die rechtliche Kontrolle und die Routing-Berechtigung sind miteinander verbunden, aber sie sind nicht dasselbe. ROAs können sowohl für IPv4- als auch für IPv6-Ressourcen erstellt werden. Das Format ist ähnlich, obwohl die Präfixlängen und das operative Design unterschiedlich sein können. IPv4-Netzwerke arbeiten oft mit Präfixen wie /24, während IPv6-Netzwerke häufig Aggregate wie /32, /36, /48 oder andere Längen ankündigen, die ihrer Allokation und ihrem Routing-Plan entsprechen.
Warum wird eine ROA benötigt?
Ohne ein ROA (Route Origin Authorization) haben andere Netzwerke keine RPKI-basierte Autorisierung, um zu bestätigen, dass eine BGP-Origin-ASN die Ankündigung eines Prefixes erlaubt. Die Route kann dennoch legitim sein, führt jedoch bei der RPKI-Validierung in der Regel zu einem „Not Found“-Ergebnis, da keine passende Autorisierung vorliegt. Ein „Not Found“-Ergebnis ist nicht automatisch ein Routingproblem. Viele gültige Routen im Internet besitzen keine ROAs. Wenn eine Organisation jedoch eine korrekte ROA veröffentlicht, liefert sie anderen Netzwerken ein stärkeres Signal, das verwendet werden kann, um die erwartete Origin von einer unbefugten oder falsch konfigurierten Origin zu unterscheiden. Eine ROA wird insbesondere dann nützlich, wenn ein Prefix wertvoll, geschäftskritisch oder weit verbreitet angekündigt wird. Ein Unternehmen kann seinen eigenen Adressraum für öffentliche Dienste nutzen, eine Cloud-Plattform kann Kundeninfrastruktur ankündigen oder ein Hosting-Anbieter kann große Adressbereiche aus mehreren Standorten werben. In solchen Fällen kann eine falsche Origin viele Benutzer und Dienste beeinträchtigen. ROAs unterstützen auch beim Incident Response. Wenn ein Prefix plötzlich von einer unerwarteten ASN auftaucht, kann ein Netzwerkoperator den RPKI-Status prüfen und schnell feststellen, ob die Ankündigung mit der vom Ressourceninhaber veröffentlichten Absicht kollidiert. Dies erklärt nicht jedes Detail des Vorfalls, bietet aber einen wichtigen Ausgangspunkt für die Untersuchung. Für Organisationen, die mehrere Upstream-Provider nutzen, kann eine ROA eine konsistente Autorisierung unabhängig davon bereitstellen, welcher Provider die Route trägt. Der Provider kann sich ändern, während die Origin-ASN gleich bleibt. In diesem Fall muss die ROA in der Regel nicht geändert werden, nur weil sich der Transitpfad geändert hat.
Wie funktioniert ein ROA mit BGP?
BGP verteilt Routenankündigungen zwischen autonomen Systemen. Eine Routenankündigung umfasst in der Regel ein IP-Präfix und eine Ursprungs-ASN (Autonomous System Number) sowie weitere Pfad- und Policy-Informationen. Die Ursprungs-ASN ist das autonome System, das behauptet, die Quelle der Route zu sein. Die RPKI-Validierung arbeitet parallel zu BGP. Ein Validator ruft signierte Autorisierungsdaten aus dem RPKI-System ab und überprüft, ob die Datensätze authentisch und aktuell sind. Anschließend erstellt er einen validierten Datensatz, der von Routern, Route-Servern oder Routing-Policy-Systemen verwendet werden kann. Wenn ein Netzwerk eine BGP-Ankündigung empfängt, vergleicht es das angekündigte Präfix und die Ursprungs-ASN mit den validierten ROA-Daten (Route Origin Authorizations). Dabei ergeben sich drei primäre Ergebnisse: Die Ankündigung kann als „Valid“ (Gültig), „Invalid“ (Ungültig) oder „Not Found“ (Nicht gefunden) eingestuft werden. Ein Ergebnis „Valid“ bedeutet, dass die Ankündigung von einer ROA abgedeckt ist und die Ursprungs-ASN autorisiert ist. Ein Ergebnis „Invalid“ bedeutet, dass eine relevante ROA existiert, die Ankündigung jedoch im Widerspruch dazu steht. Ein Ergebnis „Not Found“ bedeutet, dass keine zutreffende ROA gefunden wurde. Das empfangende Netzwerk entscheidet selbst, wie es mit diesen Ergebnissen umgeht. Einige Betreiber lehnen ungültige Routen ab. Andere weisen ihnen eine geringere Priorität zu, generieren Warnmeldungen oder wenden je nach Quelle unterschiedliche Policies an. Es gibt keine einheitliche, universelle Policy für jedes Netzwerk, doch viele Provider behandeln ungültige Ankündigungen als schwerwiegendes Problem der Routing-Sicherheit. Wichtig ist, dass die ROA nicht direkt das globale Internet steuert. Sie veröffentlicht lediglich Autorisierungsinformationen. Die praktische Wirkung hängt davon ab, ob andere Netzwerke diese Informationen abrufen, validieren und in ihren Routing-Entscheidungen verwenden.
Die drei Hauptbestandteile einer ROA
Der erste Teil eines ROA ist das autorisierte IP-Präfix, das den Adressbereich identifiziert, der vom Origin-ASN angekündigt werden darf. Für IPv4 könnte ein Präfix beispielsweise 198.51.100.0/24 lauten; für IPv6 wäre es möglicherweise 2001:db8:1234::/48. Das Präfix muss einem Ressourcenbestand entsprechen, den die Organisation durch das relevante Registry oder die entsprechende Sponsoring-Beziehung verwalten darf. Das Präfix sollte genau eingegeben werden, da ein Tippfehler, eine falsche Netzwerkgrenze oder eine falsche Präfixlänge dazu führen kann, dass der ROA unwirksam wird oder einen anderen Bereich als den intendierten autorisiert.
Der zweite Teil ist die Ursprungs-ASN, die autorisiert ist, das Präfix zu originiert, und die mit der ASN übereinstimmt, die als Ursprung der BGP-Ankündigung erscheint. Wenn ein Unternehmen einen Adressblock besitzt, ihn jedoch über die ASN eines Transitproviders ankündigt, hängt die korrekte Ursprungs-ASN vom tatsächlichen Routing-Design ab. Die ASN in der ROA sollte normalerweise diejenige sein, die die Route originiert, und nicht einfach die ASN des Upstream-Carriers. Diese Unterscheidung ist wichtig, da ein Transitprovider eine Route transportieren kann, ohne deren Ursprung zu sein; wenn die ASN des Kunden das Präfix originiert und der Provider es lediglich weiterleitet, ist in der Regel die ASN des Kunden der Wert, der autorisiert werden muss.
Der dritte Teil ist die maximale Präfixlänge, oft als maxLength bezeichnet, die definiert, wie spezifisch eine Ankündigung sein darf, während sie dennoch vom ROA abgedeckt wird. Angenommen, ein ROA autorisiert 198.51.100.0/24 mit einer maximalen Länge von /24: Die autorisierte ASN darf das exakte /24 ankündigen, hat jedoch keine Berechtigung, kleinere Sub-Präfixe wie /25 oder /26 anzukündigen. Wenn dasselbe Präfix mit einer maximalen Länge von /26 autorisiert wird, können Ankündigungen für /24, /25 und /26 je nach genauer Route und Validierungsregeln als abgedeckt betrachtet werden. Dies bietet Flexibilität, ermöglicht aber auch spezifischere Ankündigungen. Die maximale Länge sollte daher den tatsächlichen Routing-Plan widerspiegeln, da eine zu kurze Einstellung dazu führen kann, dass legitime spezifischere Routen als ungültig markiert werden, während eine zu lange Einstellung Ankündigungen autorisieren könnte, die die Organisation niemals genehmigen wollte.
Warum ist maxLength wichtig?
Die maximale Präfixlänge ist eine der wichtigsten und am häufigsten missverstandenen ROA-Einstellungen, die das Maß an Spezifität steuert, das die autorisierte ASN bei der Ankündigung der Ressource verwenden darf. Viele Netzwerkbetreiber kündigen ein aggregiertes Präfix an, um das Wachstum des Routing-Tabellsens zu reduzieren; beispielsweise kann eine Organisation ein /20 halten, es jedoch als einzelnes Aggregat ankündigen. In einigen Fällen muss die Organisation möglicherweise auch kleinere Präfixe für Traffic Engineering, regionale Konnektivität oder Diensttrennung ankündigen. Wenn die ROA nur das Aggregat abdeckt, während das Netzwerk spezifischere Routen ankündigt, können diese Routen als ungültig (Invalid) eingestuft werden. Die BGP-Ankündigung kann aus Sicht der Organisation technisch korrekt sein, entspricht jedoch nicht der im RPKI veröffentlichten Autorisierung. Andererseits kann die Autorisierung jeder möglichen spezifischeren Route die Präzision der Richtlinie schwächen, da ein /20, das mit einer extrem breiten maximalen Länge autorisiert wurde, einem viel kleineren Subpräfix ermöglicht, als autorisiert zu erscheinen, selbst wenn es außerhalb des beabsichtigten Designs liegt. Ein praktischer Ansatz besteht darin, nur die Präfixlängen zu autorisieren, die das Netzwerk basierend auf seinem Adressierungsplan, den Anforderungen des Providers, dem Failover-Design und der Traffic-Engineering-Strategie tatsächlich zur Ankündigung erwartet. Änderungen an der maximalen Länge sollten sorgfältig getestet werden, wobei zu bestätigen ist, dass alle Produktionsankündigungen das erwartete Validierungsergebnis liefern, bevor strikte Filterung angewendet wird.
ROAs for IPv4 and IPv6
ROAs können sowohl für IPv4- als auch für IPv6-Netzwerke erstellt werden, und das zugrunde liegende Sicherheitsprinzip ist dasselbe: die Verknüpfung eines Präfixes mit einer autorisierten Ursprungs-ASN. Der Hauptunterschied im Betrieb liegt in der Adressstruktur. IPv4-Ressourcen sind knapp und werden häufig in relativ kleinen Präfixen angekündigt, wobei /24 eine übliche Mindestgröße für Ankündigungen im öffentlichen Internet darstellt. IPv6-Netzwerke erhalten im Allgemeinen größere Zuweisungen und können diese in Site-, Dienst- oder geografische Segmente unterteilen, wobei ein Aggregatpräfix angekündigt wird, während mehrere interne Präfixe verwendet werden. Die ROA muss mit den öffentlich angekündigten Präfixen übereinstimmen. IPv6-Betreiber sollten nicht davon ausgehen, dass ein großer Adressraum Routing-Risiken ausschließt, da eine unbefugte IPv6-Ankündigung weiterhin Erreichbarkeitsprobleme, Traffic-Umleitung oder inkonsistentes globales Routing verursachen kann. RPKI bietet IPv6-Betreibern dieselbe Möglichkeit zur Veröffentlichung von Ursprungsberechtigungen wie IPv4-Betreibern. Bevor IPv6-ROAs erstellt werden, sollte das Netzwerkteam dokumentieren, welche Aggregatpräfixe angekündigt werden sollen, ob mehrspezifische Ankündigungen erwartet werden und welche ASN sie originated, um Datensätze zu vermeiden, die entweder zu restriktiv oder unnötig breit gefasst sind.
Wann sollten Sie eine ROA erstellen?
Ein ROA sollte erstellt werden, bevor ein Prefix in der Produktion angekündigt wird, wenn der Ressourceninhaber einen klaren Routing-Plan hat, der den validierenden Netzwerken Zeit gibt, die Informationen abzurufen, bevor die Route allgemein sichtbar wird. Organisationen sollten auch ROAs überprüfen, wenn sie eine neue Zuteilung erhalten, einen IPv4-Block erwerben, einen Adressentransfer abschließen, den Ursprungs-ASN ändern oder mit der Nutzung einer neuen IPv6-Zuteilung beginnen, da diese Ereignisse die Beziehung zwischen dem Prefix und dem originierenden Netzwerk verändern. Ein Provider-Migration ist ein weiterer häufiger Auslöser: Wenn die Organisation denselben Ursprungs-ASN beibehält und nur den Upstream-Carrier wechselt, kann das ROA gültig bleiben; wenn die Migration den Ursprungs-ASN ändert, muss der Datensatz vor oder gleichzeitig mit der Routing-Änderung aktualisiert werden. ROAs sollten bei Fusionen, Übernahmen, Datacenter-Verschiebungen, Änderungen der ASN-Sponsoring und großen Netzwerkrestrukturierungen überprüft werden, um sicherzustellen, dass die öffentliche Autorisierung mit der operativen Realität übereinstimmt. Eine regelmäßige Überprüfung ist auch dann sinnvoll, wenn keine bekannten Änderungen stattgefunden haben, da die Netzwerkdokumentation veraltet, sich die Verantwortlichkeiten des Personals ändern und alte Autorisierungen lange nach dem Ersatz des ursprünglichen Routing-Designs aktiv bleiben können.
Häufige Konfigurationsfehler bei ROA
Einer der häufigsten Fehler ist die Eingabe einer falschen Ursprungs-ASN, was auftritt, wenn Ingenieure die Kunden-ASN mit der ASN des Transit-Anbieters verwechseln oder wenn nach einer Migration eine alte ASN in der Konfiguration verbleibt. Ein weiterer häufiger Fehler besteht darin, die ROA nach einem IPv4-Transfer nicht zu aktualisieren: Der neue Inhaber kündigt das Präfix von seiner eigenen ASN aus an, während die alte Autorisierung weiterhin auf den vorherigen Ursprung verweist, wodurch die Route ungültig wird. Eine falsche maximale Länge führt zu ähnlichen Problemen, wenn eine Organisation nur ein /24 autorisiert, später jedoch zur Traffic-Steuerung ein /25 ankündigt. Einige Organisationen erstellen mehrere sich überschneidende ROAs, ohne ihren Zweck zu dokumentieren; obwohl sie in bestimmten Designs gültig sind, können sie unerwartete Ergebnisse liefern und die Fehlersuche erschweren. Das Nichtentfernen veralteter Datensätze ermöglicht es einer ASN, ein Präfix lange nach einer Änderung des Netzwerkdesigns zu originieren. Schließlich aktivieren einige Organisationen die strenge Ablehnung ungültiger Routen, ohne zuvor ihre eigenen Ankündigungen zu testen; Produktionspräfixe, maximale Längen und Ursprungs-ASNs müssen stets überprüft werden, bevor automatisierte Filterungen eingesetzt werden.
ROA and IPv4 Transfer Planning
IPv4-Übertragungen erfordern besondere Aufmerksamkeit, da der administrative Inhaber, die Sponsoring-Vereinbarung und der Routing-Ursprung zu verschiedenen Zeitpunkten des Prozesses wechseln können. Vor einer Übertragung sollte der aktuelle Inhaber bestehende ROAs dokumentieren und bestätigen, welche ASN das Präfix derzeit originiert, während der Käufer die beabsichtigte Ursprungsinformation vorbereitet und mit Transit-Anbietern koordiniert. Während des Übergangs müssen beide Parteien einen klaren Plan für die Aktualisierung oder den Ersatz von Autorisierungsdatensätzen haben: Das zu lange aktive Halten der vorherigen ROA autorisiert den alten Ursprung nach der Übertragung, während das zu frühe Entfernen dazu führt, dass die bestehende Route ungültig wird, bevor die neue Route bereitsteht. Der genaue Prozess hängt vom Registry, dem Ressourcentyp, der Übertragungsvereinbarung und dem Betriebsdesign ab, wodurch RPKI neben der Registry-Verifizierung, Vertragsprüfung, BGP-Ankündigungen, Route-Objekten, Reverse-DNS und Reputationsscreening zu einem wesentlichen Checklistenpunkt wird. Ein öffentlicher Bereitschafts-Checker hilft dabei, den aktuellen Ursprungs-ASN, den RPKI-Status, die Registry-Informationen und die BGP-Sichtbarkeit eines Präfixes für technische Vortests zu identifizieren, bestätigt jedoch nicht den rechtlichen Eigentumsstatus oder garantiert die Übertragungsfähigkeit.
ROA- und ASN-Änderungen
Eine ASN-Änderung hat direkten Einfluss auf die RPKI-Validierung. Wenn ein Prefix, das zuvor von AS64500 angekündigt wurde, nun von AS64510 angekündigt wird, muss die ROA den neuen Ursprung autorisieren, bevor die BGP-Ankündigung als „Gültig“ akzeptiert werden kann. Dies ist insbesondere dann wichtig, wenn eine Organisation von einer anbieterverwalteten ASN zu ihrer eigenen ASN wechselt oder ihre Sponsoring-LIR-Vereinbarung ändert, wodurch die Registry-Beziehung und die Routing-Autorisierung gemeinsam überprüft werden müssen. Eine sorgfältig geplante Übergangsphase kann beinhalten, vorübergehend sowohl den alten als auch den neuen Ursprung zu autorisieren, um einen kontrollierten Migrationszeitraum zu schaffen, vorausgesetzt, dies wird dokumentiert und die veraltete Autorisierung wird nach Abschluss entfernt. Das Netzwerkteam sollte die Reihenfolge der Operationen testen, bevor Produktionsänderungen vorgenommen werden, und sicherstellen, dass die neue Autorisierung veröffentlicht und validiert wird, bevor die neue BGP-Route angekündigt wird.
Wie überprüfen Sie, ob ein ROA funktioniert?
Die erste Überprüfung besteht darin, zu bestätigen, dass die ROA das beabsichtigte Präfix, die Ursprungs-ASN und die maximale Präfixlänge über das relevante RIR-Portal, die Schnittstelle des fördernden LIR oder das RPKI-Verwaltungssystem enthält. Als Nächstes wird die Autorisierung mit der tatsächlichen BGP-Ankündigung verglichen, wobei überprüft wird, ob die angekündigte Präfixlänge abgedeckt ist und die Ursprungs-ASN mit der in der ROA übereinstimmt. Ein externer RPKI-Validator kann dann den öffentlichen Status bestätigen, wobei eine korrekt konfigurierte Ankündigung als „Valid“ (Gültig) zurückgegeben wird. Wenn das Ergebnis „Invalid“ (Ungültig) lautet, sollten zunächst die Ursprungs-ASN und die Präfixlänge überprüft werden; bei „Not Found“ (Nicht gefunden) ist sicherzustellen, dass die ROA veröffentlicht wurde und die Validator-Zeit hatten, sie abzurufen. Ergebnisse werden nicht sofort aktualisiert, da Repositories, Validator und Routing-Systeme auf Aktualisierungsintervallen basieren, was kurze Verzögerungen während der Propagierung normal macht. Der Vergleich mehrerer öffentlicher Quellen – einschließlich Registry-Daten, Validator-Ergebnissen und aktuellen BGP-Beobachtungen – vermeidet die Abhängigkeit von zwischengespeicherten Informationen und liefert ein vollständiges Bild.
Was passiert, wenn eine ROA ungültig ist?
Wenn eine BGP-Ankündigung mit einem vorhandenen ROA in Konflikt steht, klassifizieren RPKI-Validatoren sie als ungültig. Die Route wird nicht automatisch aus dem globalen Internet entfernt, aber Netzwerke, die RPKI-basierte Richtlinien durchsetzen, können sie ablehnen oder ihr eine geringere Priorität zuweisen. Die betrieblichen Auswirkungen hängen vom Umfang der Durchsetzung ab: Einige Netzwerke filtern streng, während andere den Status zur Überwachung nutzen, was bedeutet, dass eine ungültige Route in Teilen des Internets weiterhin sichtbar sein kann, während sie über andere Teile unerreichbar wird. Wenn eine legitime Route ungültig wird, sollte die Organisation dies als dringliches Konfigurationsproblem behandeln und Überprüfungen der Ursprungs-ASN, der angekündigten Präfixlänge und der maximalen ROA-Länge priorisieren. Die Route sollte nicht als bösartig angesehen werden, da die meisten ungültigen Ergebnisse auf routinemäßige Fehler wie unvollständige Migrationen, veraltete Einträge, falsche Provider-Details oder versehentliche Ankündigungen von mehr-spezifischen Präfixen zurückzuführen sind. Nach der Korrektur benötigen die Systeme Zeit zum Aktualisieren, und das Netzwerkteam sollte die Route überwachen, bis sie sich an allen Beobachtungspunkten stabilisiert hat.
Wie sollten Organisationen ROAs verwalten?
Das ROA-Management erfordert einen klar definierten Verantwortlichen, sei es das Netzwerkengineering-Team, das Sicherheitsteam, der fördernde LIR (Local Internet Registry), ein Managed Service Provider oder eine andere Gruppe, die für Internet-Nummernressourcen zuständig ist. Die Organisation sollte ein Verzeichnis pflegen, das jedes Präfix, den Ursprungs-ASN, die maximale Länge, Ankündigungsstandorte und verantwortliche Ansprechpartner detailliert auflistet, um Änderungenüberprüfungen und Incident-Responses zu vereinfachen. ROA-Änderungen müssen in standardisierte Netzwerkänderungsverfahren integriert werden, wobei RPKI als explizite Anforderung bei ASN-Migrationen, Providerwechseln, IPv4-Übertragungen oder IPv6-Bereitstellungen zu berücksichtigen ist. Monitoring und Alerting sollten für Invalid-Ergebnisse, unerwartete Ursprünge, entfernte Autorisierungen oder Veränderungen der BGP-Sichtbarkeit konfiguriert sein. Entscheidend ist, dass Organisationen übermäßig breite Autorisierungen vermeiden: präzise ROAs bleiben leichter verständlich, einfacher zu überprüfen und weit weniger anfällig dafür, unbeabsichtigte Ankündigungen zuzulassen.
Häufig gestellte Fragen
Ist ein ROA dasselbe wie ein IP-Eigentumsdokument?
Nein. Eine ROA ist eine Routing-Autorisierung, die angibt, welche ASN ein Prefix im BGP-originieren darf. Sie ersetzt keine Registry-Einträge, Verträge, Übertragungsdokumente oder rechtliche Eigentumsnachweise.
Kann ein Präfix mehr als eine ROA haben?
Ja. Mehrere ROAs können angemessen sein, wenn ein Prefix absichtlich von mehr als einer ASN originiert wird oder wenn eine kontrollierte Migration eine temporäre Autorisierung für mehrere Origins erfordert, wobei sich überschneidende Einträge sorgfältig dokumentiert werden sollten.
Kündigt eine ROA mein Präfix im BGP an?
Nein. Das Erstellen eines ROA führt nicht zu einer BGP-Ankündigung; das Netzwerk muss weiterhin BGP über seine Router und Upstream-Provider konfigurieren.
Muss ein Transitanbieter im ROA aufgeführt sein?
In der Regel sollte die ROA das ASN identifizieren, das den Route originirt. Ein Provider, der nur die Route transportiert, ist nicht unbedingt das Origin-ASN, und der korrekte Wert hängt von der tatsächlichen Routing-Architektur ab.
Wie lange dauert es, bis ein ROA sichtbar wird?
Der Zeitpunkt hängt vom RIR-System, dem Publikationsrepository, den Aktualisierungsintervallen des Validators und dem Caching ab. Updates sind oft relativ schnell sichtbar, aber Produktionsänderungen sollten ausreichend Zeit für die Validierung ermöglichen.
Sollte jedes IPv4- und IPv6-Präfix eine ROA haben?
Es wird dringend empfohlen, genaue ROAs für in BGP angekündigte Prefixes zu veröffentlichen. Die Organisation sollte zunächst ihr Routing-Design bestätigen, damit die Autorisierung keine legitimen Ankündigungen versehentlich ungültig macht.
Kann ein ROA gegen jeden BGP-Angriff schützen?
Nein. Eine ROA unterstützt primär die Ursprungsvalidierung. Sie validiert nicht jeden Teil des BGP-Pfads, verhindert nicht alle Route-Leaks, verschlüsselt keinen Traffic oder garantiert, dass der Traffic einen sicheren physischen Pfad folgt.
Eine Route Origin Authorization (ROA) ist ein zentraler Bestandteil von RPKI und stellt eine kryptografisch signierte Beziehung zwischen einem IP-Präfix und der ASN her, die autorisiert ist, dieses Präfix im BGP zu originierten. Der Eintrag enthält normalerweise das Präfix, die Ursprungs-ASN sowie eine maximale Präfixlänge – jedes dieser Elemente spielt eine entscheidende Rolle bei der Identifizierung der Ressource, der Genehmigung des Origins und der Definition, wie spezifisch die Ankündigung sein darf. Genaue ROAs helfen Netzwerken, nicht autorisierte oder falsch konfigurierte Ankündigungen zu identifizieren, was insbesondere bei IPv4-Übertragungen, ASN-Änderungen, Provider-Migrationen, IPv6-Bereitstellungen und dem Betrieb multi-homed Netzwerke von großer Bedeutung ist. Gleichzeitig ist eine ROA weder ein Nachweis für den rechtlichen Besitz noch eine eigenständige Lösung für die Routing-Sicherheit; sie funktioniert am besten in Kombination mit genauen Registry-Einträgen, disziplinierten BGP-Konfigurationen, IRR-Daten, Routenüberwachung und dokumentierten Änderungsprozessen. Für jede Organisation, die öffentlichen IPv4- oder IPv6-Adressraum ankündigt, gilt die einfache praktische Regel: Veröffentlichen Sie nur die Origins, die Sie tatsächlich nutzen möchten, autorisieren Sie nur die Präfixlängen, die Sie tatsächlich ankündigen werden, und überprüfen Sie die Einträge bei jeder Netzwerkänderung. Dies hält die RPKI-Daten mit der realen Routing-Umgebung in Einklang und reduziert die Wahrscheinlichkeit, dass eine legitime Route als ungültig eingestuft wird.