Die Rolle von RPKI bei der Stärkung der globalen Routing-Sicherheit

Gemeinsame Nachweise werden von einzelnen Netzen geprüft. Ihre Wirkung hängt von den empfangenen Daten und den angewandten Richtlinien ab.

Ein Routing-Fehler in einem Netz kann Menschen in großer Entfernung betreffen. Wenn sich ein falscher Ursprung verbreitet, kann eine funktionierende Website unerreichbar werden oder Datenverkehr an ein unbeabsichtigtes Ziel gelangen. RPKI ermöglicht es empfangenden Netzen, einen Teil einer Ankündigung zu prüfen, bevor sie sich darauf verlassen.

Ihr Nutzen entsteht durch eine Abfolge von Handlungen: Ein Inhaber veröffentlicht eine nutzbare Autorisierung, Software überprüft sie, und ein Betreiber wendet eine Routing-Richtlinie an. Wer diese Abfolge versteht, erkennt sowohl die Schutzwirkung als auch die Stellen, an denen sie versagen kann.

Was wird geprüft?

Netze tauschen über BGP Informationen zur Erreichbarkeit aus. Ein Präfix ist ein Block von IP-Adressen; eine ASN identifiziert ein autonomes System. Eine Route Origin Authorization, kurz ROA, gibt an, welcher ASN der Inhaber erlaubt, als Ursprung von Routen für bestimmte Präfixe aufzutreten.

Validierungssoftware prüft die signierten Datensätze und Zertifikate und stellt anschließend validierte Autorisierungsdaten bereit. Ein Router vergleicht den Ursprung und die Präfixlänge einer Route mit diesen Daten. Der Betreiber entscheidet, wie er mit dem Ergebnis umgeht. Diese Aufgabenteilung trennt die Veröffentlichung von Einträgen, die Validierung von Nachweisen und die Routing-Entscheidungen voneinander.

Drei Ergebnisse mit unterschiedlicher Bedeutung

• Valid: Mindestens eine Autorisierung, deren Adressbereich das Präfix umfasst, erlaubt den angekündigten Ursprung und die Präfixlänge.
• Invalid: Es liegen Autorisierungsdaten vor, deren Adressbereiche das angekündigte Präfix umfassen, doch kein Eintrag erlaubt diese Kombination.
• NotFound: Die verwendeten Daten enthalten keine Autorisierung, deren Adressbereich die Route umfasst.

Diese Regeln stammen aus RFC 6811. Insbesondere ist eine fehlende ROA, deren Adressbereich das angekündigte Präfix umfasst, nicht gleichbedeutend mit einer Route mit dem Status Invalid. Ebenso bedeutet Valid nicht, dass der gesamte angekündigte Pfad authentifiziert wurde.

Wo der Schutz greift

Wenn ein empfangendes Netz Ankündigungen mit dem Status Invalid zurückweist, kann ein widersprüchlicher Ursprung dort gestoppt werden, statt über dieses Netz weitergegeben zu werden. Die Wirkung hängt von den Autorisierungen, den verfügbaren Daten und den tatsächlich eingesetzten Richtlinien ab. Mehr ROAs zu veröffentlichen und mehr Netze zur Nutzung der Ursprungsvalidierung zu bewegen, sind miteinander verbundene, aber unterschiedliche Formen der Einführung.

RFC 8481 benennt die Rolle des Betreibers ausdrücklich: Die Zuweisung eines Validierungsstatus ist von der Reaktion darauf getrennt. Es gibt keinen einzelnen globalen Schalter, der alle Netze gleichzeitig derselben Richtlinie folgen lässt.

Eine unzulässig weitergegebene Route kann einen autorisierten Ursprung beibehalten. Auch ein gefälschter Pfad kann diesen Ursprungswert bewahren. Die Ursprungsvalidierung lässt daher wichtige Routing-Risiken bestehen; Betreiber benötigen weiterhin andere Schutzmaßnahmen und Einblick in die Ausbreitung von Routen.

Auch das Nachweissystem braucht Pflege

Eine Autorisierung, die die falsche ASN nennt oder eine beabsichtigte Präfixlänge ausschließt, kann dazu führen, dass eine legitime Routenankündigung als Invalid eingestuft wird. Probleme mit Repositories, Zertifikaten oder Validatoren können ebenfalls die Daten verändern, die Routern zur Verfügung stehen. Unterschiedliche Caches und Aktualisierungszeitpunkte führen dazu, dass verschiedene Netze nicht unbedingt gleichzeitig denselben Datenstand haben.

Zur praktischen Vorbereitung gehören präzise Autorisierungen, getestete Routing-Änderungen, überwachte Validatoren und ein dokumentiertes Vorgehen bei veralteten oder fehlenden Daten. Ein zweiter Validator ist nur insoweit hilfreich, wie er die Auswirkungen jener Ausfälle verringert, die Sie abfangen möchten. Er beseitigt nicht jede gemeinsame Abhängigkeit. RFC 7115 behandelt den Betrieb; RFC 8211 untersucht schädliche Handlungen im Veröffentlichungs- und Zertifizierungssystem der RPKI.

Schutz darf nicht zu dauerhafter Abhängigkeit werden

Dies ist auch eine Frage der institutionellen Gestaltung. Eine Stelle, die unverzichtbare Nachweise kontrolliert, kann Netze beeinflussen, die sie weder betreibt noch politisch vertritt. In Notiz 28 argumentiert Lu Heng, dass die Registry-Funktion auf die korrekte Verwaltung beschränkt bleiben muss, statt zu einem Zwangsmittel zu werden.

Seine Notiz 64 formuliert ein weitergehendes Gestaltungsziel: Gemeinsame Regeln sollten auf das Nötigste beschränkt und lokal überprüfbar sein, Einträge sollten portabel sein, und künftige Änderungen sollten von der freiwilligen Übernahme durch die Teilnehmer abhängen. Sicherheit und die Möglichkeit, eine versagende koordinierende Stelle zu ersetzen, müssen gemeinsam gestaltet werden.

Die Dringlichkeit ist konkret. Sobald Nutzer den Zugang verloren haben, wird die Klärung, wer einen erforderlichen Eintrag kontrolliert, zum Notfall. Gehen Sie diesen Abhängigkeiten nach, solange die Netze funktionieren. Lesen Sie anschließend, wie ein geänderter Eintrag dazu führen kann, dass eine Route zurückgewiesen wird.