Warum Netzbetreiber eine Route Origin Authorization (ROA) benötigen
Eine ROA legt fest, welches Netz als Ursprung einer Route auftreten darf. Wie Sie sie vorbereiten, ihre Wirkung prüfen und Netze wechseln, ohne einen signierten Eintrag mit garantierter Zustellung gleichzusetzen.
Eine Ursprungsautorisierung verknüpft einen Adressblock mit einem Netz, das ihn ankündigen darf. Sie garantiert nicht den gesamten Übertragungsweg.
Ihre Adressen haben sich nicht geändert, aber Sie möchten sie von einem anderen Netz ankündigen lassen. Die neue Verbindung steht bereit. Wird der Rest des Internets die Route akzeptieren? Eine Route Origin Authorization, kurz ROA, gehört zu den Einträgen, die vor dem Wechsel stimmen müssen.
Mit ihr kann ein Adressinhaber festlegen, welches autonome System als Ursprung von Routen für ein Präfix – einen Block von IP-Adressen – auftreten darf. Diese Erklärung liefert anderen Netzen einen überprüfbaren Nachweis. Sie kündigt weder die Route an noch befördert sie Pakete oder garantiert, dass jeder Anbieter die Route akzeptiert.
Mit der beabsichtigten Ankündigung beginnen
Ein autonomes System ist ein Netz mit eigenen Routing-Richtlinien, das durch eine ASN identifiziert wird. Die Ursprungs-ASN ist die Nummer, die als Ausgangspunkt der angekündigten Route erscheint. Das autonome System am Ursprung wird nicht unbedingt von der Organisation betrieben, die als Adressinhaberin eingetragen ist.
Ermitteln Sie vor der Veröffentlichung einer Autorisierung das Präfix, seine vorgesehene Ursprungs-ASN und alle spezifischeren Präfixe, die Sie tatsächlich ankündigen möchten. Das ROA-Format in RFC 9582 verknüpft eine ASN mit Präfixen und deren zulässigen maximalen Längen. Ein längeres Präfix beschreibt einen kleineren Adressblock.
Die Freigabe eines bestimmten /24 ist beispielsweise etwas anderes als die Freigabe jedes kleineren Blocks innerhalb dieses Bereichs. Ein unnötig großzügig gewählter maxLength-Wert gewährt mehr Spielraum, als die aktuelle Ankündigung benötigt. RFC 9319 erläutert, warum Betreiber diese Autorisierung präzise begrenzen sollten.
Veröffentlichen und Prüfen sind getrennte Aufgaben
Ein Inhaber veröffentlicht signiertes Autorisierungsmaterial über seine RPKI-Infrastruktur. Die Validierungssoftware eines empfangenden Netzes prüft dieses Material und erzeugt eine Menge validierter Datensätze. Seine Router können anhand dieser Datensätze die Ursprünge eingehender Routen vergleichen. Der Betreiber konfiguriert, wie sich das Ergebnis auf das Routing auswirkt.
Ein passender Ursprung und eine zulässige Präfixlänge ergeben Valid. Liegen Autorisierungsdaten vor, deren Adressbereiche das angekündigte Präfix umfassen, aber kein Eintrag erlaubt die Kombination aus Ursprung und Präfixlänge, ergibt sich Invalid. Liegt keine Autorisierung vor, deren Adressbereich das angekündigte Präfix umfasst, ergibt sich NotFound. Diese drei Zustände unterscheiden einen fehlenden Eintrag von einem widersprüchlichen. Eine ROA in einem Repository blockiert für sich genommen nicht überall eine falsche Ankündigung.
Die Änderung in der richtigen Reihenfolge durchführen
Wenn ein Adressblock zu einem anderen Ursprung wechseln soll, bereiten Sie die erforderliche Autorisierung vor, bevor Sie sich auf die neue Ankündigung verlassen. Werden während eines Übergangs absichtlich beide Ursprünge genutzt, müssen die Autorisierungen diesen Plan abbilden. Beobachten Sie, welche Daten bei Validatoren und empfangenden Netzen ankommen, und bestätigen Sie anschließend die tatsächlichen Routen und die Erreichbarkeit. Entfernen Sie überholte Berechtigungen, sobald sie nicht mehr benötigt werden.
Es gibt keinen universellen Zeitpunkt, zu dem alle Router einen neuen Eintrag sehen. Die RPKI-Veröffentlichung, die Validierung und die Aktualisierung der Router haben jeweils eigene Zeitabläufe; eine kürzere DNS-TTL steuert diese nicht. RFC 7115 behandelt die betrieblichen Unterschiede zwischen Caches und Aktualisierungen.
Testen Sie fehlerhafte Ursprünge und Präfixlängen in einer isolierten Laborumgebung. Überwachen Sie im Produktivbetrieb die vorgesehenen Routen, die Validierungsdaten, den Zustand der Sitzungen und die Richtlinien Ihrer Anbieter. Redundante Validatoren helfen bei einzelnen Ausfällen, doch ihre Datenquellen, ihre Software und ihre Konfiguration können weiterhin gemeinsame Abhängigkeiten aufweisen.
Die übrigen Prüfungen beibehalten
Die Ursprungsvalidierung authentifiziert nicht den gesamten AS-Pfad, verhindert nicht jedes Route Leak und verschlüsselt keinen Nutzerdatenverkehr. Präfixfilter, Routing-Beziehungen und andere betriebliche Schutzmaßnahmen bleiben wichtig. Wenn eine Route ausfällt, untersuchen Sie die genaue Abweichung und die Richtlinien des empfangenden Netzes; weder der Verzicht auf jede Validierung noch die Annahme, jede Route mit dem Status Invalid sei ein Angriff, ist eine fundierte Diagnose.
Sicherheit sollte den Menschen dienen, die das Netz betreiben
Lu Heng argumentiert in Notiz 28, dass unverzichtbare Registerführung nicht zur Bestrafung nach eigenem Ermessen werden darf. Eine nützliche signierte Autorisierung ist eine technische Aussage; sie ist kein unbegrenztes Mandat für die Institution, die die damit verbundenen Register führt.
In Notiz 64 fordert er lokal überprüfbare gemeinsame Regeln, portable Koordinationsdaten und die Wahlfreiheit der Teilnehmer bei künftigen Änderungen. Für Netzbetreiber geht es dabei um Kontinuität: Sie sollten wissen, von welchen Einträgen ihr Dienst abhängt, wer diese ändern kann und wie korrekte Nachweise nutzbar bleiben könnten, wenn eine koordinierende Stelle ausfällt.
Lesen Sie anschließend, warum sich die Ursprungs-ASN eines IPv4-Präfixes ändert, um eine Routing-Änderung von einem Wechsel des Inhabers zu unterscheiden.