{"id":1102,"date":"2026-09-09T02:25:09","date_gmt":"2026-09-09T02:25:09","guid":{"rendered":"https:\/\/junglelabs.uk\/"},"modified":"2026-09-09T02:25:09","modified_gmt":"2026-09-09T02:25:09","slug":"what-is-a-roa-in-rpki","status":"publish","type":"post","link":"https:\/\/junglelabs.uk\/de\/what-is-a-roa-in-rpki\/","title":{"rendered":"Was ist ein ROA im RPKI? Wie Route Origin Authorization funktioniert"},"content":{"rendered":"

Eine Route Origin Authorization ist eine digital signierte RPKI<\/a> Ein Record, der identifiziert, welche ASN berechtigt ist, ein IP-Pr\u00e4fix in BGP zu originiieren. Er wird von der Organisation erstellt, die die relevanten Internet-Nummernressourcen h\u00e4lt, oder im Namen dieser Organisation. Ein ROA enth\u00e4lt normalerweise drei wesentliche Elemente: das IP-Pr\u00e4fix, die autorisierte Ursprungs-Autonome Systemnummer (ASN) und die maximale Pr\u00e4fixl\u00e4nge, die die ASN ank\u00fcndigen darf. Zum Beispiel kann eine Organisation das IPv4-Pr\u00e4fix 203.0.113.0\/24 kontrollieren und AS64500 verwenden, um es anzuk\u00fcndigen. Ein entsprechender ROA kann AS64500 autorisieren, dieses \/24-Pr\u00e4fix zu originiieren. Einfach ausgedr\u00fcckt \u00fcbermittelt der Record folgende Anweisung an das Routing-\u00d6kosystem: \u201eDiese ASN ist berechtigt, dieses Pr\u00e4fix anzuk\u00fcndigen.\u201c Netzwerke, die RPKI-Validierung durchf\u00fchren, k\u00f6nnen den Record dann mit dem vergleichen, was sie in BGP beobachten. Ein ROA \u00fcbertr\u00e4gt nicht den Besitz eines IP-Adressblocks. Er ersetzt keinen Vertrag, keinen Registry-Eintrag, keinen Allokationsrecord oder keine IPv4-Transfervereinbarung. Er ver\u00f6ffentlicht 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\u00f6nnen sowohl f\u00fcr IPv4- als auch f\u00fcr IPv6-Ressourcen erstellt werden. Das Format ist \u00e4hnlich, obwohl die Pr\u00e4fixl\u00e4ngen und das operative Design unterschiedlich sein k\u00f6nnen. IPv4-Netzwerke arbeiten oft mit Pr\u00e4fixen wie \/24, w\u00e4hrend IPv6-Netzwerke h\u00e4ufig Aggregate wie \/32, \/36, \/48 oder andere L\u00e4ngen ank\u00fcndigen, die ihrer Allokation und ihrem Routing-Plan entsprechen.<\/p>\n\n\n\n

Warum wird eine ROA ben\u00f6tigt?<\/h2>\n\n\n\n

Ohne ein ROA (Route Origin Authorization) haben andere Netzwerke keine RPKI-basierte Autorisierung, um zu best\u00e4tigen, dass eine BGP-Origin-ASN die Ank\u00fcndigung eines Prefixes erlaubt. Die Route kann dennoch legitim sein, f\u00fchrt jedoch bei der RPKI-Validierung in der Regel zu einem \u201eNot Found\u201c-Ergebnis, da keine passende Autorisierung vorliegt. Ein \u201eNot Found\u201c-Ergebnis ist nicht automatisch ein Routingproblem. Viele g\u00fcltige Routen im Internet besitzen keine ROAs. Wenn eine Organisation jedoch eine korrekte ROA ver\u00f6ffentlicht, liefert sie anderen Netzwerken ein st\u00e4rkeres Signal, das verwendet werden kann, um die erwartete Origin von einer unbefugten oder falsch konfigurierten Origin zu unterscheiden. Eine ROA wird insbesondere dann n\u00fctzlich, wenn ein Prefix wertvoll, gesch\u00e4ftskritisch oder weit verbreitet angek\u00fcndigt wird. Ein Unternehmen kann seinen eigenen Adressraum f\u00fcr \u00f6ffentliche Dienste nutzen, eine Cloud-Plattform kann Kundeninfrastruktur ank\u00fcndigen oder ein Hosting-Anbieter kann gro\u00dfe Adressbereiche aus mehreren Standorten werben. In solchen F\u00e4llen kann eine falsche Origin viele Benutzer und Dienste beeintr\u00e4chtigen. ROAs unterst\u00fctzen auch beim Incident Response. Wenn ein Prefix pl\u00f6tzlich von einer unerwarteten ASN auftaucht, kann ein Netzwerkoperator den RPKI-Status pr\u00fcfen und schnell feststellen, ob die Ank\u00fcndigung mit der vom Ressourceninhaber ver\u00f6ffentlichten Absicht kollidiert. Dies erkl\u00e4rt nicht jedes Detail des Vorfalls, bietet aber einen wichtigen Ausgangspunkt f\u00fcr die Untersuchung. F\u00fcr Organisationen, die mehrere Upstream-Provider nutzen, kann eine ROA eine konsistente Autorisierung unabh\u00e4ngig davon bereitstellen, welcher Provider die Route tr\u00e4gt. Der Provider kann sich \u00e4ndern, w\u00e4hrend die Origin-ASN gleich bleibt. In diesem Fall muss die ROA in der Regel nicht ge\u00e4ndert werden, nur weil sich der Transitpfad ge\u00e4ndert hat.<\/p>\n\n\n\n

Wie funktioniert ein ROA mit BGP?<\/h2>\n\n\n\n

BGP verteilt Routenank\u00fcndigungen zwischen autonomen Systemen. Eine Routenank\u00fcndigung umfasst in der Regel ein IP-Pr\u00e4fix 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 \u00fcberpr\u00fcft, ob die Datens\u00e4tze authentisch und aktuell sind. Anschlie\u00dfend erstellt er einen validierten Datensatz, der von Routern, Route-Servern oder Routing-Policy-Systemen verwendet werden kann. Wenn ein Netzwerk eine BGP-Ank\u00fcndigung empf\u00e4ngt, vergleicht es das angek\u00fcndigte Pr\u00e4fix und die Ursprungs-ASN mit den validierten ROA-Daten (Route Origin Authorizations). Dabei ergeben sich drei prim\u00e4re Ergebnisse: Die Ank\u00fcndigung kann als \u201eValid\u201c (G\u00fcltig), \u201eInvalid\u201c (Ung\u00fcltig) oder \u201eNot Found\u201c (Nicht gefunden) eingestuft werden. Ein Ergebnis \u201eValid\u201c bedeutet, dass die Ank\u00fcndigung von einer ROA abgedeckt ist und die Ursprungs-ASN autorisiert ist. Ein Ergebnis \u201eInvalid\u201c bedeutet, dass eine relevante ROA existiert, die Ank\u00fcndigung jedoch im Widerspruch dazu steht. Ein Ergebnis \u201eNot Found\u201c bedeutet, dass keine zutreffende ROA gefunden wurde. Das empfangende Netzwerk entscheidet selbst, wie es mit diesen Ergebnissen umgeht. Einige Betreiber lehnen ung\u00fcltige Routen ab. Andere weisen ihnen eine geringere Priorit\u00e4t zu, generieren Warnmeldungen oder wenden je nach Quelle unterschiedliche Policies an. Es gibt keine einheitliche, universelle Policy f\u00fcr jedes Netzwerk, doch viele Provider behandeln ung\u00fcltige Ank\u00fcndigungen als schwerwiegendes Problem der Routing-Sicherheit. Wichtig ist, dass die ROA nicht direkt das globale Internet steuert. Sie ver\u00f6ffentlicht lediglich Autorisierungsinformationen. Die praktische Wirkung h\u00e4ngt davon ab, ob andere Netzwerke diese Informationen abrufen, validieren und in ihren Routing-Entscheidungen verwenden.<\/p>\n\n\n\n

Die drei Hauptbestandteile einer ROA<\/h2>\n\n\n\n

Der erste Teil eines ROA ist das autorisierte IP-Pr\u00e4fix, das den Adressbereich identifiziert, der vom Origin-ASN angek\u00fcndigt werden darf. F\u00fcr IPv4 k\u00f6nnte ein Pr\u00e4fix beispielsweise 198.51.100.0\/24 lauten; f\u00fcr IPv6 w\u00e4re es m\u00f6glicherweise 2001:db8:1234::\/48. Das Pr\u00e4fix muss einem Ressourcenbestand entsprechen, den die Organisation durch das relevante Registry oder die entsprechende Sponsoring-Beziehung verwalten darf. Das Pr\u00e4fix sollte genau eingegeben werden, da ein Tippfehler, eine falsche Netzwerkgrenze oder eine falsche Pr\u00e4fixl\u00e4nge dazu f\u00fchren kann, dass der ROA unwirksam wird oder einen anderen Bereich als den intendierten autorisiert.<\/p>\n\n\n\n

Der zweite Teil ist die Ursprungs-ASN, die autorisiert ist, das Pr\u00e4fix zu originiert, und die mit der ASN \u00fcbereinstimmt, die als Ursprung der BGP-Ank\u00fcndigung erscheint. Wenn ein Unternehmen einen Adressblock besitzt, ihn jedoch \u00fcber die ASN eines Transitproviders ank\u00fcndigt, h\u00e4ngt die korrekte Ursprungs-ASN vom tats\u00e4chlichen 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\u00e4fix originiert und der Provider es lediglich weiterleitet, ist in der Regel die ASN des Kunden der Wert, der autorisiert werden muss.<\/p>\n\n\n\n

Der dritte Teil ist die maximale Pr\u00e4fixl\u00e4nge, oft als maxLength bezeichnet, die definiert, wie spezifisch eine Ank\u00fcndigung sein darf, w\u00e4hrend sie dennoch vom ROA abgedeckt wird. Angenommen, ein ROA autorisiert 198.51.100.0\/24 mit einer maximalen L\u00e4nge von \/24: Die autorisierte ASN darf das exakte \/24 ank\u00fcndigen, hat jedoch keine Berechtigung, kleinere Sub-Pr\u00e4fixe wie \/25 oder \/26 anzuk\u00fcndigen. Wenn dasselbe Pr\u00e4fix mit einer maximalen L\u00e4nge von \/26 autorisiert wird, k\u00f6nnen Ank\u00fcndigungen f\u00fcr \/24, \/25 und \/26 je nach genauer Route und Validierungsregeln als abgedeckt betrachtet werden. Dies bietet Flexibilit\u00e4t, erm\u00f6glicht aber auch spezifischere Ank\u00fcndigungen. Die maximale L\u00e4nge sollte daher den tats\u00e4chlichen Routing-Plan widerspiegeln, da eine zu kurze Einstellung dazu f\u00fchren kann, dass legitime spezifischere Routen als ung\u00fcltig markiert werden, w\u00e4hrend eine zu lange Einstellung Ank\u00fcndigungen autorisieren k\u00f6nnte, die die Organisation niemals genehmigen wollte.<\/p>\n\n\n\n

Warum ist maxLength wichtig?<\/h2>\n\n\n\n

Die maximale Pr\u00e4fixl\u00e4nge ist eine der wichtigsten und am h\u00e4ufigsten missverstandenen ROA-Einstellungen, die das Ma\u00df an Spezifit\u00e4t steuert, das die autorisierte ASN bei der Ank\u00fcndigung der Ressource verwenden darf. Viele Netzwerkbetreiber k\u00fcndigen ein aggregiertes Pr\u00e4fix an, um das Wachstum des Routing-Tabellsens zu reduzieren; beispielsweise kann eine Organisation ein \/20 halten, es jedoch als einzelnes Aggregat ank\u00fcndigen. In einigen F\u00e4llen muss die Organisation m\u00f6glicherweise auch kleinere Pr\u00e4fixe f\u00fcr Traffic Engineering, regionale Konnektivit\u00e4t oder Diensttrennung ank\u00fcndigen. Wenn die ROA nur das Aggregat abdeckt, w\u00e4hrend das Netzwerk spezifischere Routen ank\u00fcndigt, k\u00f6nnen diese Routen als ung\u00fcltig (Invalid) eingestuft werden. Die BGP-Ank\u00fcndigung kann aus Sicht der Organisation technisch korrekt sein, entspricht jedoch nicht der im RPKI ver\u00f6ffentlichten Autorisierung. Andererseits kann die Autorisierung jeder m\u00f6glichen spezifischeren Route die Pr\u00e4zision der Richtlinie schw\u00e4chen, da ein \/20, das mit einer extrem breiten maximalen L\u00e4nge autorisiert wurde, einem viel kleineren Subpr\u00e4fix erm\u00f6glicht, als autorisiert zu erscheinen, selbst wenn es au\u00dferhalb des beabsichtigten Designs liegt. Ein praktischer Ansatz besteht darin, nur die Pr\u00e4fixl\u00e4ngen zu autorisieren, die das Netzwerk basierend auf seinem Adressierungsplan, den Anforderungen des Providers, dem Failover-Design und der Traffic-Engineering-Strategie tats\u00e4chlich zur Ank\u00fcndigung erwartet. \u00c4nderungen an der maximalen L\u00e4nge sollten sorgf\u00e4ltig getestet werden, wobei zu best\u00e4tigen ist, dass alle Produktionsank\u00fcndigungen das erwartete Validierungsergebnis liefern, bevor strikte Filterung angewendet wird.<\/p>\n\n\n\n

ROAs for IPv4 and IPv6<\/h2>\n\n\n\n

ROAs k\u00f6nnen sowohl f\u00fcr IPv4- als auch f\u00fcr IPv6-Netzwerke erstellt werden, und das zugrunde liegende Sicherheitsprinzip ist dasselbe: die Verkn\u00fcpfung eines Pr\u00e4fixes mit einer autorisierten Ursprungs-ASN. Der Hauptunterschied im Betrieb liegt in der Adressstruktur. IPv4-Ressourcen sind knapp und werden h\u00e4ufig in relativ kleinen Pr\u00e4fixen angek\u00fcndigt, wobei \/24 eine \u00fcbliche Mindestgr\u00f6\u00dfe f\u00fcr Ank\u00fcndigungen im \u00f6ffentlichen Internet darstellt. IPv6-Netzwerke erhalten im Allgemeinen gr\u00f6\u00dfere Zuweisungen und k\u00f6nnen diese in Site-, Dienst- oder geografische Segmente unterteilen, wobei ein Aggregatpr\u00e4fix angek\u00fcndigt wird, w\u00e4hrend mehrere interne Pr\u00e4fixe verwendet werden. Die ROA muss mit den \u00f6ffentlich angek\u00fcndigten Pr\u00e4fixen \u00fcbereinstimmen. IPv6-Betreiber sollten nicht davon ausgehen, dass ein gro\u00dfer Adressraum Routing-Risiken ausschlie\u00dft, da eine unbefugte IPv6-Ank\u00fcndigung weiterhin Erreichbarkeitsprobleme, Traffic-Umleitung oder inkonsistentes globales Routing verursachen kann. RPKI bietet IPv6-Betreibern dieselbe M\u00f6glichkeit zur Ver\u00f6ffentlichung von Ursprungsberechtigungen wie IPv4-Betreibern. Bevor IPv6-ROAs erstellt werden, sollte das Netzwerkteam dokumentieren, welche Aggregatpr\u00e4fixe angek\u00fcndigt werden sollen, ob mehrspezifische Ank\u00fcndigungen erwartet werden und welche ASN sie originated, um Datens\u00e4tze zu vermeiden, die entweder zu restriktiv oder unn\u00f6tig breit gefasst sind.<\/p>\n\n\n\n

Wann sollten Sie eine ROA erstellen?<\/strong><\/h2>\n\n\n\n

Ein ROA sollte erstellt werden, bevor ein Prefix in der Produktion angek\u00fcndigt 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 \u00fcberpr\u00fcfen, wenn sie eine neue Zuteilung erhalten, einen IPv4-Block erwerben, einen Adressentransfer abschlie\u00dfen, den Ursprungs-ASN \u00e4ndern oder mit der Nutzung einer neuen IPv6-Zuteilung beginnen, da diese Ereignisse die Beziehung zwischen dem Prefix und dem originierenden Netzwerk ver\u00e4ndern. Ein Provider-Migration ist ein weiterer h\u00e4ufiger Ausl\u00f6ser: Wenn die Organisation denselben Ursprungs-ASN beibeh\u00e4lt und nur den Upstream-Carrier wechselt, kann das ROA g\u00fcltig bleiben; wenn die Migration den Ursprungs-ASN \u00e4ndert, muss der Datensatz vor oder gleichzeitig mit der Routing-\u00c4nderung aktualisiert werden. ROAs sollten bei Fusionen, \u00dcbernahmen, Datacenter-Verschiebungen, \u00c4nderungen der ASN-Sponsoring und gro\u00dfen Netzwerkrestrukturierungen \u00fcberpr\u00fcft werden, um sicherzustellen, dass die \u00f6ffentliche Autorisierung mit der operativen Realit\u00e4t \u00fcbereinstimmt. Eine regelm\u00e4\u00dfige \u00dcberpr\u00fcfung ist auch dann sinnvoll, wenn keine bekannten \u00c4nderungen stattgefunden haben, da die Netzwerkdokumentation veraltet, sich die Verantwortlichkeiten des Personals \u00e4ndern und alte Autorisierungen lange nach dem Ersatz des urspr\u00fcnglichen Routing-Designs aktiv bleiben k\u00f6nnen.<\/p>\n\n\n\n

H\u00e4ufige Konfigurationsfehler bei ROA<\/h2>\n\n\n\n

Einer der h\u00e4ufigsten 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\u00e4ufiger Fehler besteht darin, die ROA nach einem IPv4-Transfer nicht zu aktualisieren: Der neue Inhaber k\u00fcndigt das Pr\u00e4fix von seiner eigenen ASN aus an, w\u00e4hrend die alte Autorisierung weiterhin auf den vorherigen Ursprung verweist, wodurch die Route ung\u00fcltig wird. Eine falsche maximale L\u00e4nge f\u00fchrt zu \u00e4hnlichen Problemen, wenn eine Organisation nur ein \/24 autorisiert, sp\u00e4ter jedoch zur Traffic-Steuerung ein \/25 ank\u00fcndigt. Einige Organisationen erstellen mehrere sich \u00fcberschneidende ROAs, ohne ihren Zweck zu dokumentieren; obwohl sie in bestimmten Designs g\u00fcltig sind, k\u00f6nnen sie unerwartete Ergebnisse liefern und die Fehlersuche erschweren. Das Nichtentfernen veralteter Datens\u00e4tze erm\u00f6glicht es einer ASN, ein Pr\u00e4fix lange nach einer \u00c4nderung des Netzwerkdesigns zu originieren. Schlie\u00dflich aktivieren einige Organisationen die strenge Ablehnung ung\u00fcltiger Routen, ohne zuvor ihre eigenen Ank\u00fcndigungen zu testen; Produktionspr\u00e4fixe, maximale L\u00e4ngen und Ursprungs-ASNs m\u00fcssen stets \u00fcberpr\u00fcft werden, bevor automatisierte Filterungen eingesetzt werden.<\/p>\n\n\n\n

ROA and IPv4 Transfer Planning<\/h2>\n\n\n\n

IPv4-\u00dcbertragungen erfordern besondere Aufmerksamkeit, da der administrative Inhaber, die Sponsoring-Vereinbarung und der Routing-Ursprung zu verschiedenen Zeitpunkten des Prozesses wechseln k\u00f6nnen. Vor einer \u00dcbertragung sollte der aktuelle Inhaber bestehende ROAs dokumentieren und best\u00e4tigen, welche ASN das Pr\u00e4fix derzeit originiert, w\u00e4hrend der K\u00e4ufer die beabsichtigte Ursprungsinformation vorbereitet und mit Transit-Anbietern koordiniert. W\u00e4hrend des \u00dcbergangs m\u00fcssen beide Parteien einen klaren Plan f\u00fcr die Aktualisierung oder den Ersatz von Autorisierungsdatens\u00e4tzen haben: Das zu lange aktive Halten der vorherigen ROA autorisiert den alten Ursprung nach der \u00dcbertragung, w\u00e4hrend das zu fr\u00fche Entfernen dazu f\u00fchrt, dass die bestehende Route ung\u00fcltig wird, bevor die neue Route bereitsteht. Der genaue Prozess h\u00e4ngt vom Registry, dem Ressourcentyp, der \u00dcbertragungsvereinbarung und dem Betriebsdesign ab, wodurch RPKI neben der Registry-Verifizierung, Vertragspr\u00fcfung, BGP-Ank\u00fcndigungen, Route-Objekten, Reverse-DNS und Reputationsscreening zu einem wesentlichen Checklistenpunkt wird. Ein \u00f6ffentlicher Bereitschafts-Checker hilft dabei, den aktuellen Ursprungs-ASN, den RPKI-Status, die Registry-Informationen und die BGP-Sichtbarkeit eines Pr\u00e4fixes f\u00fcr technische Vortests zu identifizieren, best\u00e4tigt jedoch nicht den rechtlichen Eigentumsstatus oder garantiert die \u00dcbertragungsf\u00e4higkeit.<\/p>\n\n\n\n

ROA- und ASN-\u00c4nderungen<\/h2>\n\n\n\n

Eine ASN-\u00c4nderung hat direkten Einfluss auf die RPKI-Validierung. Wenn ein Prefix, das zuvor von AS64500 angek\u00fcndigt wurde, nun von AS64510 angek\u00fcndigt wird, muss die ROA den neuen Ursprung autorisieren, bevor die BGP-Ank\u00fcndigung als \u201eG\u00fcltig\u201c 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 \u00e4ndert, wodurch die Registry-Beziehung und die Routing-Autorisierung gemeinsam \u00fcberpr\u00fcft werden m\u00fcssen. Eine sorgf\u00e4ltig geplante \u00dcbergangsphase kann beinhalten, vor\u00fcbergehend 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\u00e4nderungen vorgenommen werden, und sicherstellen, dass die neue Autorisierung ver\u00f6ffentlicht und validiert wird, bevor die neue BGP-Route angek\u00fcndigt wird.<\/p>\n\n\n\n

Wie \u00fcberpr\u00fcfen Sie, ob ein ROA funktioniert?<\/h2>\n\n\n\n

Die erste \u00dcberpr\u00fcfung besteht darin, zu best\u00e4tigen, dass die ROA das beabsichtigte Pr\u00e4fix, die Ursprungs-ASN und die maximale Pr\u00e4fixl\u00e4nge \u00fcber das relevante RIR-Portal, die Schnittstelle des f\u00f6rdernden LIR oder das RPKI-Verwaltungssystem enth\u00e4lt. Als N\u00e4chstes wird die Autorisierung mit der tats\u00e4chlichen BGP-Ank\u00fcndigung verglichen, wobei \u00fcberpr\u00fcft wird, ob die angek\u00fcndigte Pr\u00e4fixl\u00e4nge abgedeckt ist und die Ursprungs-ASN mit der in der ROA \u00fcbereinstimmt. Ein externer RPKI-Validator kann dann den \u00f6ffentlichen Status best\u00e4tigen, wobei eine korrekt konfigurierte Ank\u00fcndigung als \u201eValid\u201c (G\u00fcltig) zur\u00fcckgegeben wird. Wenn das Ergebnis \u201eInvalid\u201c (Ung\u00fcltig) lautet, sollten zun\u00e4chst die Ursprungs-ASN und die Pr\u00e4fixl\u00e4nge \u00fcberpr\u00fcft werden; bei \u201eNot Found\u201c (Nicht gefunden) ist sicherzustellen, dass die ROA ver\u00f6ffentlicht 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\u00f6gerungen w\u00e4hrend der Propagierung normal macht. Der Vergleich mehrerer \u00f6ffentlicher Quellen \u2013 einschlie\u00dflich Registry-Daten, Validator-Ergebnissen und aktuellen BGP-Beobachtungen \u2013 vermeidet die Abh\u00e4ngigkeit von zwischengespeicherten Informationen und liefert ein vollst\u00e4ndiges Bild.<\/p>\n\n\n\n

Was passiert, wenn eine ROA ung\u00fcltig ist?<\/h2>\n\n\n\n

Wenn eine BGP-Ank\u00fcndigung mit einem vorhandenen ROA in Konflikt steht, klassifizieren RPKI-Validatoren sie als ung\u00fcltig. Die Route wird nicht automatisch aus dem globalen Internet entfernt, aber Netzwerke, die RPKI-basierte Richtlinien durchsetzen, k\u00f6nnen sie ablehnen oder ihr eine geringere Priorit\u00e4t zuweisen. Die betrieblichen Auswirkungen h\u00e4ngen vom Umfang der Durchsetzung ab: Einige Netzwerke filtern streng, w\u00e4hrend andere den Status zur \u00dcberwachung nutzen, was bedeutet, dass eine ung\u00fcltige Route in Teilen des Internets weiterhin sichtbar sein kann, w\u00e4hrend sie \u00fcber andere Teile unerreichbar wird. Wenn eine legitime Route ung\u00fcltig wird, sollte die Organisation dies als dringliches Konfigurationsproblem behandeln und \u00dcberpr\u00fcfungen der Ursprungs-ASN, der angek\u00fcndigten Pr\u00e4fixl\u00e4nge und der maximalen ROA-L\u00e4nge priorisieren. Die Route sollte nicht als b\u00f6sartig angesehen werden, da die meisten ung\u00fcltigen Ergebnisse auf routinem\u00e4\u00dfige Fehler wie unvollst\u00e4ndige Migrationen, veraltete Eintr\u00e4ge, falsche Provider-Details oder versehentliche Ank\u00fcndigungen von mehr-spezifischen Pr\u00e4fixen zur\u00fcckzuf\u00fchren sind. Nach der Korrektur ben\u00f6tigen die Systeme Zeit zum Aktualisieren, und das Netzwerkteam sollte die Route \u00fcberwachen, bis sie sich an allen Beobachtungspunkten stabilisiert hat.<\/p>\n\n\n\n

Wie sollten Organisationen ROAs verwalten?<\/h2>\n\n\n\n

Das ROA-Management erfordert einen klar definierten Verantwortlichen, sei es das Netzwerkengineering-Team, das Sicherheitsteam, der f\u00f6rdernde LIR (Local Internet Registry), ein Managed Service Provider oder eine andere Gruppe, die f\u00fcr Internet-Nummernressourcen zust\u00e4ndig ist. Die Organisation sollte ein Verzeichnis pflegen, das jedes Pr\u00e4fix, den Ursprungs-ASN, die maximale L\u00e4nge, Ank\u00fcndigungsstandorte und verantwortliche Ansprechpartner detailliert auflistet, um \u00c4nderungen\u00fcberpr\u00fcfungen und Incident-Responses zu vereinfachen. ROA-\u00c4nderungen m\u00fcssen in standardisierte Netzwerk\u00e4nderungsverfahren integriert werden, wobei RPKI als explizite Anforderung bei ASN-Migrationen, Providerwechseln, IPv4-\u00dcbertragungen oder IPv6-Bereitstellungen zu ber\u00fccksichtigen ist. Monitoring und Alerting sollten f\u00fcr Invalid-Ergebnisse, unerwartete Urspr\u00fcnge, entfernte Autorisierungen oder Ver\u00e4nderungen der BGP-Sichtbarkeit konfiguriert sein. Entscheidend ist, dass Organisationen \u00fcberm\u00e4\u00dfig breite Autorisierungen vermeiden: pr\u00e4zise ROAs bleiben leichter verst\u00e4ndlich, einfacher zu \u00fcberpr\u00fcfen und weit weniger anf\u00e4llig daf\u00fcr, unbeabsichtigte Ank\u00fcndigungen zuzulassen.<\/p>\n\n\n\n

H\u00e4ufig gestellte Fragen<\/h2>\n\n\n\n

Ist ein ROA dasselbe wie ein IP-Eigentumsdokument?<\/strong> <\/p>\n\n\n\n

Nein. Eine ROA ist eine Routing-Autorisierung, die angibt, welche ASN ein Prefix im BGP-originieren darf. Sie ersetzt keine Registry-Eintr\u00e4ge, Vertr\u00e4ge, \u00dcbertragungsdokumente oder rechtliche Eigentumsnachweise.<\/p>\n\n\n\n

Kann ein Pr\u00e4fix mehr als eine ROA haben?<\/strong> <\/p>\n\n\n\n

Ja. Mehrere ROAs k\u00f6nnen angemessen sein, wenn ein Prefix absichtlich von mehr als einer ASN originiert wird oder wenn eine kontrollierte Migration eine tempor\u00e4re Autorisierung f\u00fcr mehrere Origins erfordert, wobei sich \u00fcberschneidende Eintr\u00e4ge sorgf\u00e4ltig dokumentiert werden sollten.<\/p>\n\n\n\n

K\u00fcndigt eine ROA mein Pr\u00e4fix im BGP an?<\/strong><\/p>\n\n\n\n

Nein. Das Erstellen eines ROA f\u00fchrt nicht zu einer BGP-Ank\u00fcndigung; das Netzwerk muss weiterhin BGP \u00fcber seine Router und Upstream-Provider konfigurieren.<\/p>\n\n\n\n

Muss ein Transitanbieter im ROA aufgef\u00fchrt sein?<\/strong><\/p>\n\n\n\n

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\u00e4ngt von der tats\u00e4chlichen Routing-Architektur ab.<\/p>\n\n\n\n

Wie lange dauert es, bis ein ROA sichtbar wird?<\/strong> <\/p>\n\n\n\n

Der Zeitpunkt h\u00e4ngt vom RIR-System, dem Publikationsrepository, den Aktualisierungsintervallen des Validators und dem Caching ab. Updates sind oft relativ schnell sichtbar, aber Produktions\u00e4nderungen sollten ausreichend Zeit f\u00fcr die Validierung erm\u00f6glichen.<\/p>\n\n\n\n

Sollte jedes IPv4- und IPv6-Pr\u00e4fix eine ROA haben?<\/strong><\/p>\n\n\n\n

Es wird dringend empfohlen, genaue ROAs f\u00fcr in BGP angek\u00fcndigte Prefixes zu ver\u00f6ffentlichen. Die Organisation sollte zun\u00e4chst ihr Routing-Design best\u00e4tigen, damit die Autorisierung keine legitimen Ank\u00fcndigungen versehentlich ung\u00fcltig macht.<\/p>\n\n\n\n

Kann ein ROA gegen jeden BGP-Angriff sch\u00fctzen?<\/strong> <\/p>\n\n\n\n

Nein. Eine ROA unterst\u00fctzt prim\u00e4r die Ursprungsvalidierung. Sie validiert nicht jeden Teil des BGP-Pfads, verhindert nicht alle Route-Leaks, verschl\u00fcsselt keinen Traffic oder garantiert, dass der Traffic einen sicheren physischen Pfad folgt.<\/p>\n\n\n\n

Eine Route Origin Authorization (ROA) ist ein zentraler Bestandteil von RPKI und stellt eine kryptografisch signierte Beziehung zwischen einem IP-Pr\u00e4fix und der ASN her, die autorisiert ist, dieses Pr\u00e4fix im BGP zu originierten. Der Eintrag enth\u00e4lt normalerweise das Pr\u00e4fix, die Ursprungs-ASN sowie eine maximale Pr\u00e4fixl\u00e4nge \u2013 jedes dieser Elemente spielt eine entscheidende Rolle bei der Identifizierung der Ressource, der Genehmigung des Origins und der Definition, wie spezifisch die Ank\u00fcndigung sein darf. Genaue ROAs helfen Netzwerken, nicht autorisierte oder falsch konfigurierte Ank\u00fcndigungen zu identifizieren, was insbesondere bei IPv4-\u00dcbertragungen, ASN-\u00c4nderungen, Provider-Migrationen, IPv6-Bereitstellungen und dem Betrieb multi-homed Netzwerke von gro\u00dfer Bedeutung ist. Gleichzeitig ist eine ROA weder ein Nachweis f\u00fcr den rechtlichen Besitz noch eine eigenst\u00e4ndige L\u00f6sung f\u00fcr die Routing-Sicherheit; sie funktioniert am besten in Kombination mit genauen Registry-Eintr\u00e4gen, disziplinierten BGP-Konfigurationen, IRR-Daten, Routen\u00fcberwachung und dokumentierten \u00c4nderungsprozessen. F\u00fcr jede Organisation, die \u00f6ffentlichen IPv4- oder IPv6-Adressraum ank\u00fcndigt, gilt die einfache praktische Regel: Ver\u00f6ffentlichen Sie nur die Origins, die Sie tats\u00e4chlich nutzen m\u00f6chten, autorisieren Sie nur die Pr\u00e4fixl\u00e4ngen, die Sie tats\u00e4chlich ank\u00fcndigen werden, und \u00fcberpr\u00fcfen Sie die Eintr\u00e4ge bei jeder Netzwerk\u00e4nderung. Dies h\u00e4lt die RPKI-Daten mit der realen Routing-Umgebung in Einklang und reduziert die Wahrscheinlichkeit, dass eine legitime Route als ung\u00fcltig eingestuft wird.<\/p>","protected":false},"excerpt":{"rendered":"

A Route Origin Authorization is a digitally signed RPKI record that identifies which ASN is allowed to originate an IP prefix in BGP. It is created by, or on behalf of, the organization that holds the relevant Internet number resource. A ROA normally contains three essential elements: the IP prefix, the authorized origin ASN, and […]<\/p>\n","protected":false},"author":1,"featured_media":1104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"What Is a ROA in RPKI? How Route Origin Authorization Works","_seopress_titles_desc":"Learn what a ROA is in RPKI, how it authorizes an ASN to announce an IPv4 or IPv6 prefix, why maxLength matters, and how to avoid common routing errors.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-1102","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article"],"_links":{"self":[{"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/posts\/1102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/comments?post=1102"}],"version-history":[{"count":2,"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/posts\/1102\/revisions"}],"predecessor-version":[{"id":1105,"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/posts\/1102\/revisions\/1105"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/media\/1104"}],"wp:attachment":[{"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/media?parent=1102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/categories?post=1102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/junglelabs.uk\/de\/wp-json\/wp\/v2\/tags?post=1102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}