Von A nach B

von Benjamin Pfister

Onlinedienste bestimmen nicht nur unser Leben, sie bilden auch eine Existenzgrundlage von Unternehmen. Da kommt den zugrundeliegenden Protokollen eine immer größere Bedeutung zu, auch wenn diese oft schon etliche Jahre auf dem Buckel haben. In diesem Beitrag werfen wir einen Blick auf die Funktionsweise von BGP, das Paketen den Weg im Internet weist – samt dessen Schwächen und Möglichkeiten zur Absicherung.

Das Internet besteht aus einem Zusammenschluss unterschiedlicher autonomer Systeme (AS) – also von Netzwerken und Systemen unter jeweils einer administrativen Kontrolle, etwa eines bestimmten Providers. Für diesen Zusammenschluss verfügen diese AS über offiziell registrierte Nummern, sogenannte "Autonomous System Numbers" (ASN). Die Erreichbarkeit zwischen den autonomen Systemen gewährleistet wiederum das Border Gateway Protocol (BGP) in der aktuellen Version BGP-4. Es ist auf die Bewältigung großer Mengen an Routinginformation bei hoher Stabilität ausgelegt und optimiert.

Neben Providern müssen sich auch große Unternehmens- und Behördenkunden mit BGP auseinandersetzen, falls sie ein sogenanntes Multi-Homing einsetzen oder anstreben. Darunter ist die Anbindung des eigenen autonomen Systems an mehrere Provider zu verstehen. Zudem kommt in einigen Netzen auch BGP im internen Netz zur Anwendung. Es stellt zudem die Basis für Multiprotocol Label Switching (MPLS) in WAN-Strukturen dar, kann aber auch für Ethernet Virtual Private Network (EVPN) oder in Kombination mit VXLAN in Rechenzentrumsnetzen zur Anwendung kommen.

BGP beherrscht derweil noch wesentlich mehr Funktionen als nur die Verteilung von IP-Präfixen. So verfügt das Protokoll über vielfältige Optionen zur richtlinienbasierten Wegwahl.

Grundlagen

Im Gegensatz zu den unterschiedlichen "Interior Gateway Routing"-Protokollen (IGP) wie RIP, OSPF oder EIGRP für interne Netze stellt BGP das einzige sogenannte "Exterior Gateway Protocol" (EGP) dar. Als solches baut es auf dem Path-Vector-Prinzip auf, das Ähnlichkeiten zu Distance-Vector-IGPs besitzt. Der Austausch von Routen innerhalb eines autonomen Systems findet über IGPs statt. Diese sind auf schnelle Konvergenzzeiten optimiert, um den hohen Anforderungen an geringe Downtimes gerecht zu werden. Dies kann durch Optimierungen bis in den Bereich von Millisekunden gehen. Dabei müssen jedoch auch geringere Mengen an Routen verarbeitet werden.

BGP ist multiprotokollfähig, unterstützt also beispielsweise IPv4 und IPv6. In diesem Fall kommen Erweiterungen des Protokolls zum Einsatz, weshalb auch die Rede von "Multi-Protocol BGP4" (MP-BGP4) ist. Dabei kann BGP unterschiedliche Arten von Informationen und Kontexten über sogenannte "Address Families", wie beispielsweise für IPv4 und IPv6, verarbeiten und separieren. Eine volle BGP-Tabelle im Internet für IPv4 enthält Stand 2023 nach Informationen der regionalen Internet-Registry ARIN etwa 940.000 Präfixe und für IPv6 172.400 Präfixe. Die Router müssen also über einen entsprechend großen physischen Speicher verfügen.

Anwendung von ASNs

Wie bereits dargestellt, benötigt ein Netzwerkbetreiber für den Austausch von Routen-Informationen eine ASN. Öffentliche ASNs vergeben sogenannte Regional Internet Registries (RIRs). Für Europa übernimmt diese Aufgabe das Réseaux IP Européens Network Coordination Centre (RIPE NCC).

Für eine redundant aufgebaute Internetanbindung über mehr als einen Carrier (Multi-Homing) braucht es eine offizielle ASN-Zuweisung durch die RIR. Zudem bedarf es der Zuweisung eines vom Provider unabhängigen IP-Adressblocks. Dazu kommen sogenannte PI- (Provider Independent) oder PA- (Provider Aggregatable) Adressblöcke zum Einsatz. Dieser Prozess ist durch die Knappheit an öffentlichen IPv4-Adressen allerdings schwierig geworden. Bei kleineren Kunden erfolgt im Normalfall eine Zuweisung durch den Provider. Wenn das Unternehmen oder die Behörde über ein eigenes AS und öffentliche Adressblöcke verfügt, übernimmt es die Rolle der lokalen Internet-Registries (LIR).

AS-Nummern sind klassisch 16 Bit lang und die Darstellung findet dezimal statt (ASPlain). Neuere AS-Nummern nutzen 32 Bit und die Darstellung erfolgt mit einem Punkt getrennt. Das zugehörige Format nennt sich ASDot [1]. Die Darstellung der AS-Nummer 6541 in ASPlain wechselt also in der ASDot-Schreibweise in 0.6541.

Routenwahl und Attribute

Das BGP nutzt unterschiedliche Arten von Attributen, um die Wahl der passenden Route zu beeinflussen. Wir unterscheiden dabei zwischen transitiven und nicht-transitiven sowie normalen und Pfadattributen. Sobald von BGP die Rede ist, geht es schnell um sogenannte Peerings. Dahinter verbirgt sich die Nachbarschaftsverbindung zwischen BGP-Routern und folglich der autonomen Systeme. Doch suchen BGP-Router ihre Nachbarn nicht einfach nach Aktivierung per Multicast, wie dies in den meisten Fällen beim Interior-Gateway-Protocol (IGP) innerhalb eines AS der Fall ist.

Bei BGP muss der Administrator auf dem Router die Nachbarn explizit mit IPAdresse und dem entfernten autonomen System im jeweiligen Routing-Prozess hinterlegen. Auf dem Peer-Router muss dies entsprechend umgekehrt geschehen. Soll also Router A in AS 64496 und IPAdresse 192.0.2.1 mit Router B im AS 64500 und IP-Adresse 192.0.2.2 peeren, muss Router A den Nachbarn 192.0.2.2 mit AS 64500 hinterlegt haben und Router B den Peer 192.0.2.1 mit AS 64496. Stimmen die gegenüberliegenden Konfigurationen nicht überein, kommt es auch nicht zu einem Peering.

Ablauf der Kommunikation

Prinzipiell wird zwischen externen und internen BGP-Peerings unterschieden. Interne BGP-Peerings (iBGP) finden innerhalb des gleichen autonomen Systems statt, beispielsweise um Präfixe zwischen zwei BGP-Routern auszutauschen, die jeweils an unterschiedliche Carrier angebunden sind. Externe BGP-Peerings (eBGP) finden zwischen unterschiedlichen autonomen Systemen statt, wie in unserem vorherigen Beispiel.

Die beiden BGP-Arten unterscheiden sich jedoch in der Umsetzung. Dies ist beispielsweise an der Multihop-Funktion erkennbar, bei der die Time to Live (TTL) aus dem IP-Header beeinflusst wird. Bei iBGPs können per Default mehrere Hops zum Peer bestehen. Bei eBGP muss der Admin dies explizit konfigurieren, um zu erreichen, dass Peers sich in unterschiedlichen Subnetzen befinden dürfen. Die TTL wird in einem solchen Fall angehoben, um den Peer zu erreichen.

Auch das Handling der Next-Hop-IPAdresse unterscheidet sich. Bei eBGP überträgt der Router immer die IP-Adresse der ausgehenden Schnittstelle als Next-Hop in den Erreichbarkeitsinformationen und der empfangende Router ersetzt diese bei Weiterverteilung durch seine ausgehende IP-Adresse der genutzten Schnittstelle. Bei iBGP wird diese bei Weiterleitung unverändert übernommen. Diese Adresse muss jedoch für den Ziel-Peer auch erreichbar sein. Ansonsten könnte der Admin den sogenannten Next-Hop-Self-Parameter konfigurieren, um das gleiche Verhalten wie bei eBGP zu erreichen.

BGP nutzt als Transportprotokoll das verbindungsorientierte TCP über Port 179. Dieser muss also auf dem Transportweg freigegeben sein. Beim Aufbau des Peerings durchläuft der Verbindungsaufbau unterschiedliche Phasen: Die Ruhephase beginnt mit dem Idle-Status, wobei in der Connect-Phase ein TCP-Drei-Wege-Handshake mit dem bekannten SYN, SYN/ACK, ACK zum Einsatz kommt. Falls dies erfolgreich war, geht es in der OpenSent-Phase an den Abgleich von BGP-Informationen, wie AS-Nummern und Authentifizierungsdaten. Danach folgt im normalen Verlauf die OpenConfirm-Phase, in der die Peers auf Keep-Alive-Nachrichten warten. Falls auch dies gelingt, steht die Established-Phase an, in der das Peering aufgebaut ist und die Router Erreichbarkeitsinformationen austauschen können.

Dieser Prozess verwendet auf den Routern jeweils die Schnittstelle, die laut Routingtabelle zur Ziel-IP-Adresse führt. Um Szenarien mit multiplen Pfaden abdecken zu können, ohne bei einem Pfadfehler ein sogenanntes Flapping (Ab- und Wiederaufbau der Verbindung) des BGP-Peerings zu riskieren, sollte in einem solchen Fall eine permanent erreichbare IP-Adresse als Quelle zum Einsatz kommen. Dazu kommen permanent aktive Loopback-Schnittstellen als sogenannte "Update Source" zum Einsatz. Es ist jedoch zu beachten, dass diese dann auch auf der Gegenstelle als Peer-Adresse hinterlegt und im Routing der Gegenstelle enthalten sind, um überhaupt das Peering aufbauen zu können.

Keine Schleifen drehen

Die Schleifenfreiheit stellt eine der Kernfunktionen eines jeden Routing-Protokolls dar. Diese basiert bei BGP auf dem sogenannten AS-Path, also einer Auflistung der bereits passierten Transit-AS. Jedes autonome System fügt seine ASN ausgehend bei einem eBGP-Peering hinzu. Eine AS-Nummer darf nur direkt hintereinander mehrfach vorkommen, jedoch nicht fragmentiert an unterschiedlichen Stellen. Kommt die ASN fragmentiert im AS-Path vor, verwirft BGP diesen potenziellen Pfad, da dies als Schleife erkannt wird. Die Möglichkeit der Verkettung der gleichen ASN bietet sich bei Pfadrichtlinien über ein sogenanntes AS-Path-Prepend an, um einen Pfad künstlich zu verlängern.

Da es bei iBGP nur eine ASN für alle beteiligten Router gibt, kann dieses Verfahren hier nicht zum Einsatz kommen. Um dem zu begegnen, verhalten sich iBGP und eBGP unterschiedlich bei der Weiterleitung von Erreichbarkeitsinformationen. Erhält ein iBGP-Peer eine Information, leitet er diese nur an eBGP-Peers, nicht jedoch an weitere iBGP-Peers weiter. eBGP-Peers wiederum reichen ankommende Erreichbarkeitsinformationen sowohl an eBGP- als auch an iBGP-Peers durch.

Das iBGP-Verhalten führt also zu einigen Design-Einschränkungen bei iBGP, denen sich mit mehreren Hilfsmitteln begegnen lässt. Im Normalfall bräuchte es bei iBGP eine Vollvermaschung aller Peers. Dies skaliert jedoch in größeren Umgebungen nicht. Als Abhilfe gibt es beispielsweise Confederations und Route-Reflektoren. Confederations bieten eine Aufteilung in Unterzonen. Geläufiger sind jedoch Route-Reflektoren. Bei empfangenen Erreichbarkeitsinformationen von iBGP-Peers leitet der Router diese an eBGP-Peers und Route-Reflektoren, die der Skalierung dienen, weiter; nicht jedoch an andere iBGP-Peers.

Bekanntgabe von Routen

Nachdem das Peering steht, bedarf es eines Austauschs der Erreichbarkeitsinformationen. Dazu gibt es die Optionen "Originating" und "Redistributierung". Bei Originating konfiguriert der Admin ein bekanntzugebendes Netz in seinem AS. Der BGP-Router sucht in der Routing-Tabelle nach einem bekannten Pfad zu diesem Netz, der durch statische Routen oder dynamische Routing-Protokolle wie OSPF bekannt sein könnte. Falls dies erfolgreich ist, übergibt er diese Netze in die BGP-Tabelle.

Bei der Redistributierung, also Neuverteilung, gibt der Admin einen Quell- und einen Ziel-Routing-Prozess an, also beispielsweise von OSPF nach BGP. Auf dieser Basis überträgt der Router alle Pfade von einem in das andere Protokoll, also in diesem Fall in die BGP-Tabelle. Dies lässt sich jedoch über sogenannte Präfix-Listen einschränken. Möchte der Admin keine zu kleinen Routen announcen, kann er diese auch zu einer Summary-Route zusammenfassen.

Für die Wegwahl nutzt BGP, wie bereits erwähnt, sogenannte Attribute. Diese kann der Administrator über Route-Maps manipulieren. Die Tabelle "BGP-Attribute" listet diese in der abzuarbeitenden Reihenfolge und der jeweiligen Beschreibung auf.

Das Weight-Attribut nutzen nicht alle Hersteller und es ist auch nur auf einem Router lokal signifikant, um ausgehende Wegwahlen zu treffen. Eine höhere Weight für ein Peering wird hinsichtlich des Präfixes einer niedrigeren bevorzugt. Das Local-Preference-Attribut wird nur zwischen iBGP-Peers ausgetauscht. So kann innerhalb eines AS eine Präferenz für die ausgehende Wegwahl über einen bestimmten Peer fallen.

Das Locally-Originated-Attribut behandelt lokale Routen vor über BGP gelernten Routen. Erst im nächsten Schritt kommt es zur Prüfung der Länge des ASPath, also einer Auflistung der zu passierenden AS. Die Router bevorzugen kürzere Pfade. Kam es auf Basis der AS Path Length noch nicht zur Entscheidung, wird der Origin Code, also die Quelle des Präfix, herangezogen. Lokale Präfixe erhalten den Vorrang vor per EGP erlernten Präfixen, gefolgt von neu verteilten Pfaden.

Das Attribut Multi Exit Discriminator (MED) wird nur bei eBGP zwischen zwei ASN herangezogen. Sobald mehrere Peerings zum gleichen AS bestehen, kann ein Router den MED nutzen, um einen bevorzugten Pfad in Rückrichtung anzugeben. Im nächsten Schritt bevorzugt der Router den Pfad mit einer besseren Metrik zum BGP-Next-Hop im IGP. Dies ist der Grund, dass BGP noch ein IGP zugrundeliegt. Da BGP auf Stabilität ausgelegt ist, würde es als nächsten Pfadentscheidungsparameter ältere Einträge vor neueren bevorzugen. Falls auch dann noch keine Entscheidung gefallen ist, vergleicht der Router die Router-ID des Next-Hops und gibt kleineren numerischen Werten den Vorrang. Ähnliches kommt auch beim letzten "Tie Breaker" zum Einsatz. Eine niedrigere numerische IP-Adresse wird vor höheren als Pfad bevorzugt.

An den genannten Attributen lässt sich erkennen, dass mit BGP komplexe Richtlinien für die Wegwahl möglich sind. Dies macht das Protokoll jedoch nicht einfach im Handling.

Herausforderungen und Sicherheit

Die regionalen Internet-Registries (RIRs) stellen eine Datenbank bereit, in denen die AS-Betreiber ihre Richtlinien hinterlegen. Darin legen diese fest, wie sie Routen von und zu externen autonomen Systemen bekanntgeben beziehungsweise annehmen. Auf Basis der ausgehenden Richtlinie besteht die Möglichkeit, für Peering-Partner entsprechende eingehende Routen-Filter auf deren Seite des Peerings zu setzen. Dies sorgt für eine gewisse "Hygiene im BGP" und erschwert Präfix-Hijacking [2]. Zudem gibt jeder AS-Betreiber Kontaktdaten für technische Probleme oder Missbrauch an.

Natürlich ist nicht jedem beliebigen Präfix aus jeder Quelle blind zu vertrauen. Getreu dem Motto "Vertrauen ist gut, Kontrolle ist besser" gilt es, die eingehenden Präfixe der Gegenstellen, im BGP-Kontext als Peers bezeichnet, zu prüfen [3]. Verteilt ein autonomes System Präfixe, die nicht seinem AS zugewiesen sind, ist dies ein Präfix-Hijacking. Ziel ist die Umleitung von Datenverkehr durch Manipulation der Wegwahl.

Das kann zum einen einer sogenannten Man-in-the-Middle-Attacke dienen, um Daten mitzulesen oder zu manipulieren. Zum anderen besteht jedoch auch die Möglichkeit eines Denial of Service (DoS), um die Erreichbarkeit von Diensten oder ganzer Netze zu stören. Nicht zuletzt besteht die Chance, dass es sich schlicht um eine Fehlkonfiguration handelt. Immer wieder gibt es Fälle von Präfix-Hijacking, was die Notwendigkeit von Gegenmaßnahmen verdeutlicht. Eingehende Filter für Route-Announcements lassen sich jedoch in dieser Größenordnung nicht sinnvoll oder nur in begrenztem Rahmen anwenden.

Signatur durch Public Keys

Die Internet Engineering Task Force (IETF) hat mit der Resource Public Key Infrastructure (RPKI) [4] einen möglichen Ansatz als Gegenmaßnahme entwickelt. Dabei handelt es sich um eine Attestierung, welche autonomen Systeme welche Präfixe announcen dürfen. Diese Attestierung basiert auf dem PKI-Framework X.509 der ITU-T. Für die Abbildung der Vertrauenskette und folglich der Attestierung nutzt RPKI die gleiche Hierarchie wie bei der IP-Adressvergabe. Somit bildet die IANA das Wurzelelement der PKI. Von dort geht es über die RIRs bis hin zu den lokalen Internet Registries.

Der Betrieb von RPKI kann in unterschiedlichen Zuständigkeitsmodellen erfolgen. Große Unternehmen oder Provider können eine lokale PKI einsetzen, auch als Delegated RPKI bezeichnet. Parallel gibt es die Option einer Hosted RPKI. Dabei findet der Betrieb der PKI auf Seiten der regionalen Internet-Registry statt. Im Fall von Europa ist dies RIPE NCC.

Jede LIR kann sich AS-Nummern und IP-Präfixe über ein Zertifikat attestieren lassen. Auf dieser Basis besteht die Möglichkeit, sogenannte Route Origin Authorizations (ROA) zu erstellen. Diese beinhalten das autorisierte ASN, das IPPräfix und die maximale Länge des Präfix. Somit hat ein potenzieller Angreifer nicht die Möglichkeit, dieses Präfix mit einer spezifischeren/höheren Präfixlänge zu announcen. Ein Router bevorzugt nämlich höhere Präfixlängen und ein Angreifer könnte dies ansonsten nutzen, um Datenverkehr für ein spezifischeres Präfix auf sich umzuleiten.

Die Zertifikate bieten die Option zur kryptografischen Prüfung der übersendeten Präfixe. Setzt der Admin keine maximale Präfixlänge, darf das AS nur das gesamte Präfix announcen und keine spezifischen Teile davon. E-Mail-Alarmierungen beim RIPE-NCC warnen vor unautorisierten Ankündigungen und Fehlkonfigurationen.

Die Gegenstelle muss jedoch auch die ROA-Informationen eingehender Präfixe validieren. Dieser Check kann zu den Ergebnissen "Not Found", "Unknown", "Valid" oder "Invalid" führen. Valid bedeutet, dass der Check des AS, des Präfix und der korrespondierenden Länge erfolgreich war, bei Invalid entsprechend fehlerhaft. Not Found beziehungsweise Unknown bedeutet, dass kein ROA gefunden wurde. Das RIPE NCC stellt Beispielskonfigurationen für Hersteller wie Cisco Systems und Juniper bereit. Nicht alle Plattformen von Routern unterstützen jedoch RPKI. Zusätzlich stellt natürlich eine mögliche Kompromittierung der Zertifizierungsstelle ein Risiko dar.

Validierung mit BGPSec

RPKI allein stellt jedoch noch nicht das Ende der Absicherungsmöglichkeiten dar. Auf dem vorgenannten Protokoll baut zusätzlich noch BGPSec auf. Bei diesem Verfahren handelt es sich um eine Möglichkeit, eine Vertrauenskette zu bilden. Dabei signiert die Quelle des Routing-Präfix, der sogenannte "Originator", die entsprechenden Informationen über RPKI und alle weiteren Router des ASPath signieren entsprechend mit ihrem privaten Schlüssel. Somit autorisiert jedes autonome System den übertragenen Präfix im BGP-Update.

Jedoch birgt der Einsatz von RPKI und BGPSec auch Gefahren für die Verfügbarkeit. So müssen die Peers die von der PKI ausgestellten Zertifikate auch überprüfen. Dazu braucht es die Erreichbarkeit des NTP-Diensts für die Prüfung des Validitätszeitraums sowie von HTTP-basierenden Diensten wie OCSP und CRL, um einen möglichen Widerruf feststellen zu können. Dies setzt jedoch wiederum Routing-Informationen voraus, was zu einer Schleifenabhängigkeit führt. Eine Aggregation von Präfixen zur Verringerung der Anzahl an übertragenen Präfixen ist mit BGPSec nicht möglich. Zudem kann der PKI- dem AS-Betreiber die Souveränität entziehen, indem er Zertifikate zur Signatur von Präfixen widerruft oder eine Ausstellung verweigert.

Admins und Sicherheitsverantwortliche können statische Routen-Filter setzen, um eingehende und ausgehende Route-Announcements einzuschränken. Dies kann auf Basis der bereits genannten Daten aus der Routing-Richtlinie der zuständigen RIR geschehen. Diese sind jedoch nicht sonderlich flexibel. Es empfiehlt sich aber auf jeden Fall Routen-Filter zu setzen, die eingehend eigene Präfixe von externen Quellen blocken.

Standardrouten sollten Administratoren bei nahezu allen Peerings vermeiden, da dies auch nur bei Endkunden ohne Multi-Homing Sinn ergibt. Zudem sollten BGP-Router private IP-Adressbereiche bidirektional filtern, da andere Router diese ohnehin nicht im Internet routen. Dies kann über eingehende und ausgehende Route-Maps geschehen. Diese Route-Maps matchen meist auf sogenannte Präfix-Listen. Diese können auf eine Subnetzmaske und Präfix-Länge in den Erreichbarkeitsinformationen prüfen. Dazu geben sie die Anzahl der übereinstimmenden Bits an, wobei die Operanden "kleiner gleich" (le) und "größer gleich" (ge) zur Anwendung kommen.

Präfix-Listen bieten die Möglichkeit einer ein- und ausgehenden Bindung an den jeweiligen Peer. Auf dieser Basis können Admins ein- und ausgehende Präfix-Filter anwenden. Dadurch lässt sich die Verteilung der Präfixe vorfiltern. Etwas feiner in der Klassifizierung sind die sogenannten Route-Maps, die dazu AS-Path ACLs, Präfix-Listen oder Community-Tags verwenden. Auf dieser Basis können sie entsprechende BGP-Attribute anpassen. Die Route-Maps nutzen Sequenznummern zur sequenziellen Abarbeitung der "Klassifizierung" und "Anpassung". Sie bieten die Möglichkeit, BGP-Attribute, Next-Hop und Community-Tags über ein Set-Kommando zu verändern, sofern ein positives Match-Ergebnis besteht.

BGP-Communities [5] können Zusatzleistungsmerkmale bieten und somit eine wertvolle Ergänzung darstellen. Diese nutzen Nummern als Tags. Diese definieren wiederum ein erwartetes Verhalten. Somit lässt sich eine BGP-Richtlinie "fernsteuern". Es gibt dafür sowohl wellknown- als auch Custom-Communities. Die Verwendung muss zwischen den beteiligten Peers abgestimmt sein. Der Admin kann spezielle Tags in die Communities zu Präfixen hinterlegen und damit dem Peer quasi Steuerkommandos zur Behandlung des Datenverkehrs zu diesem Präfix mitteilen. Neben den genannten Filter- und Steuermöglichkeiten empfiehlt es sich, auch private AS-Nummern im AS-Path und zu lange AS-Paths zu filtern.

TCP-Session sichern

Nicht nur auf der eigentlichen Protokollebene von BGP gibt es Gefährdungen. Ein potenzieller Angreifer könnte durch massenhafte Pakete auf den BGP-Port die Control-Plane angreifen und folglich einen Denial of Service auslösen. So gilt es zunächst, die Kommunikationsbeziehungen für den Socket-Aufbau einzuschränken. Dazu können statuslose Paketfilter – sogenannte Access Control Lists (ACLs) – zum Einsatz kommen. Diese kann der Administrator eingehend anwenden, um den Zielport für BGP (TCP/179) nur von legitimierten Quell-IP-Adressen erreichbar zu machen.

Jedoch reicht dies allein noch nicht aus. Es gilt auch, die Authentizität und Integrität der Daten sicherzustellen. Ansonsten könnte ein Angreifer Blind Insertions, Replay-Attacken oder Reset-Attacken durchführen. Über Blind Insertions kann ein Angreifer versuchen, falsche Routing-Informationen oder ein Session-Reset, also eine Beendigung, mit einer gespooften IP-Adresse auf einen nicht per Authentifizierung gesicherten Router zu injizieren. Die große Herausforderung ist jedoch, dass die TCP-Sequenznummer zum erwarteten Segment passen muss, wozu sowohl Wissen über die aktuelle Session als auch ein korrektes Timing nötig sind. Falls es zu einem Session-Reset kommt, bedarf es eines komplett neuen Aufbaus und Erlernen von hunderttausenden Routing-Informationen und in Folge für diese Zeit zu einem Denial of Service.

Abhilfe kann die Authentifizierung über kryptografische Verfahren schaffen. Jedoch kommen bisher meist noch veraltete und inzwischen als unsicher geltende Verfahren wie MD5 zum Einsatz. Dabei liegt ein symmetrischer Schlüssel auf beiden Peers vor. Jedes TCP-Segment enthält einen zuvor kalkulierten Message Authentication Code (MAC). Der Empfänger prüft diesen vor Annahme auf Basis der Inhalte in TCP-Headern, den Inhaltsdaten und dem konfigurierten symmetrischen Schlüssel. Sollte die Kalkulation zu einem anderen Ergebnis als dem empfangenen Wert kommen, nimmt der empfangende Router dieses Segment nicht an.

Neben dem Fakt, dass MD5 aufgrund möglicher Kollisionen bereits seit Jahren als verwundbar gilt, würde bei diesem Verfahren ein Wechsel des Schlüssels zu einem Abbruch der TCP-Session führen. Folglich führt dies zu einer neuen BGP-Session und ebenfalls zu einem Neuerlernen der Routing-Informationen, was einige Zeit in Anspruch nimmt.

Als optimiertes Verfahren wurden die TCP Authentication Options (TCP-AO) entwickelt und in RFC5925 standardisiert. Dieses Verfahren ermöglicht einen Schlüsseltausch ohne Abbruch der TC-Pund in Folge der BGP-Session, was insbesondere langlebigen TCP-Sessions wie bei BGP zugutekommt. TCP-AO dienen nur der Prüfung der Authentizität des Absenders, es erfolgt keine Verschlüsselung der Nutzdaten wie bei TLS oder IPSec. Dazu bauen die TCP-AO auf Master Key Tuples (MKTs) auf. Die Verwaltung kann sowohl statisch als auch über einen Out-of-Band-Mechanismus erfolgen. Von den MKTs leiten sich dann die Verbindungsschlüssel (Traffic Keys) ab.

Schwarzes Loch

Seit einigen Jahren mehren sich Angriffe, die die Erreichbarkeit von Diensten einschränken oder komplett verhindern. Diese als Denial of Service oder im Fall von verteilten Quellen als Distributed Denial of Service bezeichneten Attacken können entweder auf Netzwerkebene oder Applikationsebene ansetzen. Netzwerkseitige DoS/DDoS-Attacken zielen auf die Überlastung von Netzwerkanbindungen ab. Eine weitere Bezeichnung für diese Art ist volumetrische Attacke. Angriffe auf Applikationsebene, also beispielsweise auf Webserver, machen sich Schwachstellen in Anwendungen oder spezifische Verhaltensweisen der Applikation zunutze, um diese auszuschalten. In beiden Varianten gilt es zunächst, das Verkehrsmuster zu erkennen und dann den Datenverkehr zu filtern, zu limitieren oder umzuleiten.

Da insbesondere volumetrische Attacken mit hohen Datenraten einhergehen, die die Anbindung von Unternehmen und Behörden nicht handhaben können, gilt es, diesen Datenverkehr bereits zuvor abzufangen. Ein denkbares Verfahren wäre das Blackholing [6] beim Provider, bei dem ein Router alle Pakete zu einem bestimmten Ziel über eine Null-Route verwirft.

So ließe sich dem Upstream-Provider über BGP mitteilen, dass dieser Pakete zu bestimmten Ziel-IP-Adressen verwerfen soll. Dies wird auch als Remotely-Triggered Black Hole Routing (RTBH) bezeichnet. Dabei sendet der Kunde einen /32-Präfix bei IPv4 oder /128 bei IPv6 mit der attackierten Ziel-IP-Adresse und der BGP-Community 666 an den Peer. Da Peers solche Host-Präfixe jedoch im Default nicht annehmen, bedarf es einer gezielten Abstimmung mit dem Provider. Zudem ist in diesem Fall die IP-Adresse nicht mehr erreichbar. Jedoch ist dann die Anbindung nicht mehr überlastet und andere Dienste sind nicht mehr beeinträchtigt.

Fazit

BGP ist auch im Jahr 2023 ein grundlegender Bestandteil des Internets. Die Hintergründe sind aber nicht vielen bekannt. Ausfälle des Routings etwa durch Fehlkonfigurationen oder Angriffe können allerdings zu enormen Auswirkungen führen, wenn auch dank der dezentralen Struktur des Internets nur in Teilbereichen. Aufgrund der stetig steigenden Abhängigkeit von Onlinediensten sollten Security-Verantwortliche ein Auge auf BGP werfen und sich mit den Möglichkeiten zu dessen Absicherung befassen.

Attribut	Beschreibung
Weight	Gültigkeit lokal auf einem Router zur Festlegung ausgehender Präferenz.
Local Preference	Gültigkeit innerhalb AS zur Festlegung ausgehender Präferenz.
Locally Originated	Lokale Routen vor gelernten.
AS Path Length	Menge an ASN im Transit
Origin Code	IGP-Quellen bevorzugt vor EGP-Quellen, was wiederum vor redistributierten Informationen zieht.
MED	Mitteilung an Nachbar-AS, Traffic für bestimmte Ziele über spezifizierten Link zu routen.
eBGP path over iBGP path	Pfade über ein anderes AS bevorzugt vor Pfaden innerhalb des AS.
Shortest IGP path to BGP next-hop	Pfad zum nächsten BGP-Router anhand der Informationen aus dem verwendeten IGP bevorzugt.
Oldest path	Ältere Pfade bevorzugt.
Router ID	Next Hop mit kleinster Router-ID bevorzugt.
Neighbor IP address	Next Hop mit kleinster IP-Adresse bevorzugt.

Attribut	Beschreibung
0.0.0.0/0	Nur Default-Route
0.0.0.0/0 ge 32	Alle Host-Routen
172.16.0.0/16 ge 24	Alle Subnetze im IP-Bereich 172.16.0.0/16 mit einer minimalen Präfixlänge von 24 Bit
192.168.0.0/24 ge 27 le 30	Alle Präfixe, die mit 192.0.0. beginnen und deren Präfix-Länge zwischen 27 und 30 liegt.

Routingprotokoll BGP