RIPE unterrichtet jetzt die Verhinderung von Route Leaks. Warum das zählt.
Der Kurs „BGP Routing Security“ des RIPE NCC enthält jetzt Theorie zur Verhinderung und Erkennung von Route Leaks nach RFC 9234, dazu ein praktisches Labor zum Einrichten von BGP Roles und zum Erkunden von Only-To-Customer. 1
Wenn die RIR etwas in ihren Standardlehrplan aufnimmt, hat es den Weg vom experimentellen Vorschlag zur empfohlenen Betriebspraxis hinter sich.
Die Lücke, die RPKI lässt
Vergangene Woche haben wir darüber geschrieben, wo RPKI aufhört. Die wichtigste Grenze sei wiederholt: RPKI beseitigt keine Route Leaks.
Ein Route Leak ist kein gefälschter Ursprung. Der Ursprung ist legitim, und die ROA validiert einwandfrei. Das Problem ist die Weitergabe. Ein Netz empfängt eine Route von einem Peer oder Upstream und kündigt sie an einen anderen weiter an, wohin sie nie gehört hätte. Plötzlich bewirbt sich ein kleines regionales Netz als Weg zu großen Teilen des Internets – und der Verkehr folgt, weil BGP glaubt, was man ihm sagt.
Historisch haben Route Leaks einige der größten bekannten globalen Routing-Vorfälle verursacht, und fast immer waren es Versehen: ein fehlender Filter, eine Richtlinie auf der falschen Session, ein zwischen Nachbarn kopiertes Template.
RPKI sieht davon nichts, weil jede Ankündigung in der Kette einen gültigen Ursprung hat.
Roles und OTC, kurz gefasst
RFC 9234 nimmt das, was ohnehin alle informell wissen – diese Session ist mit einem Kunden, jene mit einem Upstream, jene mit einem Peer – und macht es im Protokoll ausdrücklich. 2
Sie konfigurieren für jede eBGP-Session eine Role: Provider, Customer, Route Server, Route Server Client oder Peer. Die Role-Capability wird in der OPEN-Nachricht ausgetauscht, sodass beide Seiten die Beziehung bestätigen und unvereinbare Konfigurationen ablehnen können. Sind die Rollen bekannt, erlaubt das Only-To-Customer-Attribut – ein optionales transitives Pfadattribut – Routern, Ankündigungen zu markieren und zu erkennen, die dorthin gewandert sind, wo die Geschäftsbeziehung sie nicht erlaubt. 2
Das Elegante daran ist, dass es eine Prüfung auf Protokollebene für etwas hinzufügt, das immer ein Filterproblem war. Klassische Leak-Verhinderung heißt, für jeden Nachbarn korrekte Präfixfilter zu pflegen – enorm aufwendig, fehleranfällig und dauerhaft veraltet. Roles und OTC erlauben konformen Routern, viele Leaks strukturell zu erkennen, aus der Beziehung selbst heraus, und verringern so die Abhängigkeit von nachbarspezifischen Präfixfiltern.
Verringern, nicht ersetzen. RFC 9234 tritt neben Ihre bestehenden Kontrollen und schafft sie nicht ab: IRR-basierte Filterung, RPKI-Ursprungsvalidierung, Max-Prefix-Limits und Bogon-Filterung wollen Sie weiterhin. Es nimmt Ihnen nur die Annahme, dass diese Filter das Einzige sind, was zwischen einer vertippten Richtlinie und einem Leak steht.
Und es lässt sich vergleichsweise leicht einführen: ein paar Zeilen je Session in BIRD, FRR oder JunOS – und es verhält sich gutmütig, wenn die Gegenstelle es nicht unterstützt.
Kontrolle, die wir den Kunden geben
Wir betreiben AS210464, und unsere Haltung ist: Kundinnen und Kunden sollen ihr Routing selbst steuern können, ohne ein Ticket zu öffnen.
Das beginnt mit RPKI-Validierung der Routen, die wir annehmen – Ursprungsvalidierung als Untergrenze. Es geht weiter mit einem vollständigen Satz BGP-Communities, der Ihnen leak-förmige Kontrollen direkt in Ihren eigenen Ankündigungen gibt: nicht an ein bestimmtes AS ankündigen, nicht an Kunden, nicht an direkte Peers, nicht an IXP-Peers, nicht an Route Server, nicht an Upstreams – dazu regionale Steuerung, ein- bis dreifaches Prepending, Local Preference für Backup-Routen und Remote-Triggered Blackholing, wenn ein Präfix an unserem Netzrand verworfen werden soll statt an Ihrem Server.
Diesen Satz an Communities gibt es, weil die Reichweite Ihrer Ankündigung Ihre Entscheidung sein sollte, ausgedrückt in der Ankündigung selbst – und nicht ein Filter, den bei uns jemand von Hand pflegt und irgendwann falsch setzt.
BGP-Sessions beginnen bei 5 €/Monat. Jede VM bringt ein geroutetes /48 an IPv6 mit; brauchen Sie Raum zum Ankündigen statt nur zum Benutzen, bringen Sie eigenen mit oder mieten ihn bei uns. Die Sessions peeren gegen lokale Gateway-Adressen, 10.0.0.1 und fd10::1, mit Multihop und TTL 255 auf Ihrer Seite. Was unsere Router tatsächlich sehen, prüfen Sie im Looking Glass aus Tirana, Skopje, Amsterdam oder Dublin – ohne Konto und ohne Vertriebsgespräch.
Drei Dinge, die einen Nachmittag wert sind
Wenn Sie BGP betreiben, setzen Sie zuerst Roles auf Ihre eBGP-Sessions – angefangen bei den Upstreams, wo ein Leak den größten Schaden anrichtet.
Prüfen Sie gleich bei der Gelegenheit Ihre ROAs. Betriebsfehler wie veraltete ROAs und zu großzügige maxLength-Werte gehören weiterhin zu den häufigsten Ursachen RPKI-ungültiger Ankündigungen – der wahrscheinlichste Routing-Vorfall in Ihrer Zukunft ist also nach wie vor einer, den Sie selbst verursachen.
Und belegen Sie den RIPE-Kurs, wenn Sie in der Region sind. Die Labore sind der schnellste Weg, mit Roles und OTC vertraut zu werden.
Route Leaks bleiben eines der wenigen Fehlerbilder im Internet, bei denen eine einzige falsch konfigurierte Session den Dienst von Netzen beeinträchtigen kann, die noch nie von Ihnen gehört haben. Die Lösung ist inzwischen standardisiert, sie wird gelehrt, und sie ist günstig. Viele Ausreden bleiben da nicht.