Alternative Absicherung von BGP-Routen heftig diskutiert

BGP-Routen könnten nach einer neuen Methode auch durch Zusatzinformationen im Domain Name System abgesichert werden. Der neue Vorschlag trifft aber auch auf Kritik.

In Pocket speichern vorlesen Druckansicht 14 Kommentare lesen
Lesezeit: 3 Min.
Von
  • Monika Ermert

Die Internet Engineering Task Force (IETF) sucht bereits länger nach einer Möglichkeit, BGP-Routen gegen Verfälschungen wie etwa das Umbiegen auf andere Ziele abzusichern. Über das Border Gateway Protocol (BGP) signalisieren sich Router im Backbone, für welche Netze (autonome Systeme, AS) sie zuständig sind und welche anderen Netze sie erreichen können. Ein neuer Vorschlag dazu sorgte beim 83. Treffen der IETF in Paris für heftige Diskussionen, denn die Information über die Herkunft der Routen (Route Origin) soll nach dem neuen Vorschlag im mit Security Extensions erweiterten Domain Name System abgelegt werden, DNSSEC.

Die Idee stammt von einer Gruppe von DNS-Experten um Joe Gersch, CEO des DNSSEC-Anbieters Secure64 und Dan Massey vom Computer Science Departement der Colorado State University und beruht auf der Nutzung der mittels DNSSEC gesicherten reversen DNS-Zone in-addr.arpa. Dort sollen die Inhaber von IP-Adressblöcken (CIDR-Blöcken) mittels eines neuen RLOCK-Eintrags anzeigen, dass sie das neue Route-Origin-Verification-Verfahren (ROVER) unterstützen.

ROVER erlaubt die Prüfung der BGP-Announcements durch eine Abfrage in den in-addr.arpa hinterlegten Adressblöcken. Stimmen die BGP-Ankündigungen mit den hinterlegten "Secure Route Origin"(SRO)-Einträgen überein, dürfen die Routing-Verantwortlichen davon ausgehen, dass sie korrekt und vertrauenswürdig sind. Schlägt der Abgleich fehl oder wenn es trotz vorhandenem RLOCK-Hinweis keinen Eintrag gibt, muss man von einer Manipulation der Route ausgehen.

Gersch und Massey warben in Paris vor allem damit, dass man auf ein bestehendes und mittels DNSSEC abgesichertes System zurückgreifen könne. Die ISPs müssten sich nicht zusätzlich mit X509-Zertifikaten herumschlagen, die die von Routing-Experten entwickelte "Routing PKI"-Standardsuite erfordere (RPKI). Das Problem, dass in in-add.arpa normalerweise einzelne IP-Adressen (invers) eingetragen werden, nicht aber ganze Blöcke, haben sie durch einen Zusatz zum Standardvorschlag gelöst, der insbesondere eine Konvention zur Benennung der Blöcke vorsieht, die nicht ins 8-Bit-Raster des DNS passen.

Gersch und Massey beeilten sich aber auch, ihr System lediglich als Ergänzung für RPKI zu bezeichnen. Ein Vorteil sei aber, dass der ROVER-Check Miskonfigurationen aufdecken könne, erläuterte Gersch weiter. Rüdiger Volk, Routing-Experte der Deutschen Telekom, wandte ein, dass die DNS-Variante zur Absicherung der Routen vor allem für Verwirrung sorgen und die Implementierung des RPKI-Verfahrens torpedieren werde. Auch andere Teilnehmer warnten vor einer Spaltung in der Routingwelt: Wenn ROVER-Einträge fehlten, müsse bei RPKI nachgeschaut werden und umgekehrt.

Ein grundsätzliches Problem führte der Vorsitzende der DNS-Arbeitsgruppe bei der IETF, Peter Koch, ins Feld. Die Absicherung von IP-Routen über das DNS – das Namen in IP-Adressen übersetzt – sorge für eine gefährliche Abhängigkeit. Nach einem Zusammenbruch könne man damit praktisch nicht aus einer sicheren Quelle neu starten.

Siehe auch:

(rek)