Nicht erst seitdem Pakistan Telekom (AS17557) im Jahr 2008 durch einen Konfigurationsfehler im eigenenen Netz bei YouTube weltweit für zwei Stunden die Lichter ausgeknipst hat, gibt es BGP Prefix Hijacks. Schon im April 1997 hat MAI Network Services (AS7007) eindrucksvoll bewiesen, wie man mit dem Announcement von BGP more specific Prefixes das Internet aus dem Tritt bringen kann.
Um zu verstehen, was in beiden Fällen passiert ist, muss man wissen, dass eine more specific Route (falls vorhanden und akzeptiert) unabhängig von allen anderen Metriken, die das globale BGP Routing mit sich bringt, ausnahmslos immer die bevorzugte Route ist. So kann es passieren, dass unabsichtlich oder auch vorsätzlich durch das Announcement einer more specific Route durch ein fremdes Netz Datenverkehr zu eben diesem Netz umgeleitet wird statt zu dem richtigen Empfänger geroutet wird. Man spricht dann von Prefix Hijacks, also vom Entführen des Prefixes.
In beiden oben zitierten Fällen wurden unabsichtlich more specific Routes erzeugt und wegen fehlenden oder unzureichenden BGP Filtern über das gesamte Internet verteilt. Es gibt jedoch auch Fälle, bei denen vorsätzlich solche more specific Routen propagiert werden, um Datenströme abzugreifen.
Im Jahr 2006 hat die Internet Engineering Task Force (IETF) damit begonnen, mit einem Architekturpaper die Grundlage für eine Resource Public Key Infrastructure (RPKI) zu schaffen. Nachdem diese Technologie mittlerweile eine gewisse Reife erreicht hat, haben wir uns dazu entschieden, diese auch im next layer Netz umzusetzen. Diese Architektur ermöglicht es uns heute, zu überprüfen, ob ein BGP Prefix von einem Netz Announced werden darf oder nicht.
Konkret enthalten Route Origin Authorizations (ROA) das originierende Autonomous System (AS), den Prefix und die zulässigen Prefixlängen. Diese ROAs werden von den Regional Internet Registries (RIR) oder Local Internet Registries (LIR) Digital signiert. Eine RPKI Validator Software, wie sie auch next layer eingesetzt, kann diese Digitalen Signaturen der ROAs überprüfen und liefert die validierten Daten (Prefix, Prefixlängen, Origin AS) mittels RPKI-RTR an die Router aus. Unsere Router können damit Routen, die sie via BGP erhalten, gegen diese Daten prüfen. Das Resultat der Überprüfung kann Folgendes ergeben:
- UNKNOWN: Es wurde kein ROA gefunden, das mit der Route (auch nur teilweise) überlappt.
- VALID: Es wurde ein ROA gefunden, das der Route entspricht (Origin AS, erlaubte Prefixlängen korrekt)
- INVALID: Es wurde ein ROA gefunden, aber das Origin AS oder die Prefixlänge der Route entsprechen nicht der im ROA signierten Daten.
Das Ergebnis dieser Überprüfung kann auf den Routern zu spezieller Behandlung der Routen führen. Als best-practice hat sich etabliert, INVALID Routes nicht zu akzeptieren. Wir haben uns dazu entschieden, nach einer mehrmonatigen Übergangsfrist bis Mitte Februar, diese best-practice umzusetzen und ab dann keine INVALID Routen mehr zu akzeptieren. In den beiden Anfangs beschriebenen Fällen der Prefix Hijacks würden wir, sofern die eigentlichen Announcements mit einem ROA versehen sind, einen solchen Hijack als INVALID Route erkennen und diese Route nicht mehr akzeptieren.
Prefixes, die sich bei der Validation als UNKNOWN herausstellen, wurden von ihrem Resource-Owner im Allgemeinen noch nicht mit einem ROA versehen und werden weiterhin von den Routern akzeptiert. Da über solche Prefixes keine Aussage getroffen werden kann, profitieren diese auch nicht von RPKI.
RIRs wie RIPE ermöglichen ihren Members, mit ganz wenigen Klicks ROAs für die eigenen IP-Resourcen zu erstellen und damit von RPKI für die eignen Resourcen zu profitieren. Im RIPE LIR Portal gibt es dazu unter „Resources“ einen eigenen Menüpunkt „RPKI Dashboard“. Man muss dazu kein RPKI Experte sein. Das ist auch der Grund, wieso in den letzten zwei Jahren gerade in der RIPE Region die Anzahl der ROAs und damit die Verbreitung von RPKI signifikant zugenommen hat und hier insgesamt knapp unter 70 000 IP Prefixes durch ROAs abgesichert sind.
ROAs zu erstellen ist unabhängig von der Umsetzung der Validierungsinfrastuktur – wie oben beschrieben – oft der erste einfache Schritt Richtung RPKI. Wir unterstützen unsere Kunden dabei im Sinne einer stabileren Internet Routing Architektur diesen Schritt zu setzen.
Wenden Sie sich diesbezüglich einfach an unsere Technik.