Was ist RPKI? Ein Leitfaden zur Routingsicherheit für Einsteiger
Wie prüft RPKI Routenursprünge, was bedeuten die Ergebnisse und warum argumentiert Lu Heng, dass verlässliche Sicherheit auch Grenzen für die Macht von Registern braucht?
Zu prüfen, wer eine Route ankündigen darf, ähnelt der Prüfung, ob ein Zusteller die Erlaubnis hat, ein Viertel zu bedienen. Das garantiert nicht jeden Teil des Weges.
Eine Website kann einwandfrei funktionieren und trotzdem unerreichbar werden. Irgendwo zwischen ihrem Netz und ihren Besuchern kann ein anderes Netz die falsche Route ankündigen. Der Datenverkehr gelangt dann an einen Ort, an dem er nicht zugestellt werden kann, oder zu jemandem, der versucht, ihn abzufangen.
RPKI, kurz für Resource Public Key Infrastructure, hilft Netzen bei der Prüfung einer wichtigen Behauptung: Ist dieses Netz berechtigt, diese IP-Adressen anzukündigen? Wer diese Prüfung versteht, erkennt auch eine tiefergehende Frage. Wer kontrolliert die Einträge, auf denen die Prüfung beruht?
Mit der Behauptung beginnen, die ein Netz aufstellt
Das Internet ist ein Netz aus Netzen. BGP, das Border Gateway Protocol, ermöglicht ihnen den Austausch von Ankündigungen darüber, wie Gruppen von IP-Adressen erreicht werden. Eine solche Gruppe wird Präfix genannt. Jedes unabhängig betriebene Routingnetz wird durch eine autonome Systemnummer, kurz ASN, identifiziert.
Stellen Sie sich einen Lieferdienst vor, der ankündigt: „Wir können dieses Viertel beliefern.“ Andere Unternehmen brauchen eine Möglichkeit, diese Behauptung zu prüfen. Beim Routing kann eine falsche Ankündigung durch einen Tippfehler oder einen absichtlichen Hijack entstehen. BGP-Ankündigungen allein beweisen nicht, dass das als Routenursprung angegebene Netz die Erlaubnis hat, dieses Präfix anzukündigen.
Was RPKI, ROAs und Validierung jeweils tun
RPKI stellt einen Zertifikatsrahmen für Internetnummernressourcen bereit. Ein Inhaber von Adressen kann eine signierte Route Origin Authorisation, kurz ROA, veröffentlichen. Sie benennt eine ASN, die ein bestimmtes Präfix ankündigen darf, und legt, sofern angegeben, fest, wie eng dieser Adressbereich in Ankündigungen unterteilt werden darf. Die technische Definition steht in RFC 9582.
Das Veröffentlichen einer ROA und das Prüfen eingehender Routen sind getrennte Aufgaben. Validierungssoftware prüft Zertifikate und signierte Einträge und stellt die verifizierten Autorisierungsdaten anschließend Routern bereit. Router vergleichen Routenankündigungen mit diesen Daten; Betreiber wählen die darauf folgende Routingrichtlinie. Dieser Vergleich wird Route Origin Validation, kurz ROV, genannt. Der Betreiberleitfaden des RIPE NCC erklärt diese Aufgabenteilung.
Im Lieferbeispiel veröffentlicht eine Partei, wer das Viertel bedienen darf; andere Parteien prüfen diese Erlaubnis. Ein Zertifikat ist innerhalb dieses Systems ein Nachweis. Es beweist nicht, dass jede anschließende Lieferung sicher sein wird.
Drei Ergebnisse statt eines einfachen Ja oder Nein
Valid: Mindestens eine verifizierte Autorisierung deckt das angekündigte Präfix ab und erlaubt sowohl die angegebene Ursprungs-ASN als auch die Präfixlänge. Invalid: Es existieren Autorisierungen, die das Präfix abdecken, aber keine erlaubt diese Kombination. NotFound: In den Validierungsdaten gibt es keine Autorisierung, die das Präfix abdeckt.
NotFound bedeutet nicht, dass ein Angreifer entdeckt wurde. Invalid erklärt für sich genommen nicht, ob die Ursache ein Angriff oder ein Konfigurationsfehler ist. Diese Zustände beschreiben den Vergleich, wie in RFC 6811 definiert.
Was dieser Schutz aussagen kann und was nicht
Die Ursprungsvalidierung kann Netzen helfen, nicht autorisierte Ursprünge zurückzuweisen. Sie authentifiziert nicht jedes Netz entlang einer Route, verschlüsselt nicht die Verbindung eines Besuchers und garantiert nicht, dass eine Website verfügbar bleibt. Bei einem Route Leak kann ein autorisierter Ursprung erhalten bleiben und diese Prüfung bestehen. Filterung und Überwachung bleiben erforderlich; RPKI ist ein Teil der Routingsicherheit.
Für Betreiber beginnt eine sinnvolle Vorbereitung mit ihren tatsächlichen Ankündigungen: Welche Präfixe kündigen sie an, über welche ASNs und stimmen die veröffentlichten Autorisierungen damit überein? Diese Einträge und die Validatoren funktionsfähig zu halten, ist ebenso wichtig wie das Aktivieren einer Routereinstellung. RFC 7115 behandelt die betrieblichen Überlegungen.
Die Einträge selbst sind ein Machtpunkt
Die üblicherweise verwendete RPKI-Vertrauenskette folgt der Ressourcenvergabe, wobei regionale Internetregister an ihren Wurzeln stehen. Die Verifizierung hängt daher von mehr ab als von solider Mathematik: Sie hängt auch von den Zertifizierungsstellen und Veröffentlichungssystemen ab, die die Einträge bereitstellen.
Das Ändern oder Zurückziehen von Einträgen kann die Validierungsergebnisse verändern. Das bedeutet nicht automatisch eine Abschaltung des gesamten Internets; die Wirkung hängt von anderen verfügbaren Autorisierungen und den Routingrichtlinien der Betreiber ab. RFC 8211 untersucht nachteilige Handlungen und Fehler von Zertifizierungsstellen und Repository-Managern. Ein Sicherheitsmechanismus kann ein Risiko verringern und zugleich Abhängigkeiten schaffen, die geprüft werden sollten.
Lu Hengs Argument: Das Netz schützen und den Torwächter begrenzen
In Anmerkung 28, Warum Register niemals zu Vollstreckern werden dürfen zieht Lu Heng eine klare Grenze: Die Pflege des Adressbuchs darf nicht zu einer Macht werden, mit der seine Nutzer bestraft werden. Sein Einwand richtet sich gegen die von Administratoren beanspruchte Autorität, nicht gegen den Bedarf an korrekten Einträgen. Eine kleine, selbst ausgewählte Gruppe erhält kein Mandat über Netze auf mehreren Kontinenten, nur weil sie deren Koordinationsdienst betreibt.
Anmerkung 64 entwickelt seine vorgeschlagene Alternative: Gemeinsame Regeln sollten das für Eindeutigkeit und Sicherheit erforderliche Minimum abdecken, mit Nachweisen, die Teilnehmer selbst überprüfen können. Einträge und Nachweise sollten übertragbar sein; Betreiber sollten einen Dienstleister ersetzen können, ohne ihre Netzwerkidentität aufzugeben. Künftige Änderungen sollten durch ihren Nutzen Akzeptanz finden, statt durch dauerhafte administrative Kontrolle.
Das ist eine Richtung für den Wiederaufbau der Koordination und keine Behauptung, dass ein alternatives RPKI-System bereits überall eingesetzt wird. Es muss weiterhin kompatible Einträge und zuverlässige Verifizierung gewährleisten. Die anspruchsvolle Aufgabe besteht darin, beides zu erreichen: Schutz vor falschen Behauptungen und Schutz vor einer nicht rechenschaftspflichtigen Autorität über die Nachweise.
Warum die Frage vor einem Ausfall wichtig ist
Die Kunden eines Netzes sind täglich auf seine vertrauten Adressen angewiesen. Wenn es eine Abhängigkeit erst entdeckt, nachdem seine Einträge geändert wurden oder verschwunden sind, ist die Wiederherstellung bereits ein akutes Betriebsproblem. Lu Hengs Argument für eine Änderung beginnt hier: Kontinuität, unabhängige Verifizierung und die Möglichkeit zu gehen müssen in das System eingebaut werden, bevor sie in einem Streitfall benötigt werden.
Um dieses Argument von der Kritik bis zum Design weiterzuverfolgen, lesen Sie Lu Hengs Anmerkung 64 über minimale gemeinsame Regeln, lokale Entscheidungen und freiwillige Übernahme.