BGP4

Dieser Artikel oder Abschnitt bedarf einer Überarbeitung. Näheres ist auf der Diskussionsseite angegeben. Hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

BGP im TCP/IP‑Protokollstapel:

Anwendung	BGP
Transport	TCP
Internet	IP (IPv4, IPv6)
Netzzugang	Ethernet	Token Bus	Token Ring	FDDI	…

Das Border Gateway Protocol ist das Routingprotokoll des Internets. Es beschreibt, wie Router untereinander die Verfügbarkeit von Verbindungswegen zwischen den Netzen autonomer Systeme („AS“) weitergeben.

BGP als Pfadvektorprotokoll

BGP ist ein Pfadvektorprotokoll (path vector protocol): Seine Funktionsweise ist stark an Distanzvektoralgorithmen und -protokollen wie z. B. Routing Information Protocol (RIP) angelehnt, jedoch wird dem dort vorkommenden Problem der Routingschleifen (Routingschleife bedeutet, dass ein IP-Paket auf seinem Weg durch das Internet ein- und dasselbe AS mehrmals passiert) effektiv vorgebeugt: Ein BGP-Router teilt beim Senden von Verfügbarkeitsinformationen („Updates“) dem Kommunikationspartner nicht nur mit, dass er einen bestimmten Abschnitt des Internet erreichen kann, sondern auch die komplette Liste aller AS(AS_PATH), die IP-Pakete bis zu diesem Abschnitt passieren müssen (sein eigenes AS steht dabei an erster, das Ziel-AS an letzter Stelle). Merkt der Kommunikationspartner nun, dass das AS, dem er selbst angehört, bereits in dieser Liste vorhanden ist, verwirft er dieses Update und vermeidet so, dass eine Routingschleife entsteht.

eBGP und iBGP

Die Stärke des Border Gateway Protocol liegt darin, verschiedene alternative Routing-Pfade in einer einzigen Routing-Tabelle zu vereinen. BGP, welches das derzeit einzige eingesetzte Exterior Gateway Protokoll ist, ist ein Protokoll für das Routing zwischen autonomen Systemen (AS); man spricht bei dieser Verwendung von external BGP (eBGP).

BGP kann jedoch auch innerhalb eines autonomen Systems angewendet werden. Typischerweise geschieht dies, um die „von außen“ (=via eBGP) gelernten Routen an die anderen Router des eigenen AS' zu propagieren; man spricht bei dieser Verwendung von internal BGP (iBGP). Beim Einsatz innerhalb eines autonomen Systems müssen BGP-Verbindungen („BGP-Sessions“) zwischen allen Routern des AS eingerichtet werden, so dass eine vollständige Vermaschung (full mesh) entsteht. Üblicherweise werden diese Verbindungen zwischen den Loopbackadressen der beteiligten Router eingerichtet, so dass ein darunterliegendes Interior Gateway Protocol (IGP) erforderlich ist. Enthält ein autonomes System n Router, so resultiert dies also in O(n²) BGP-Verbindungen. Aufgrund der hierdurch entstehenden Skalierungsprobleme wird bei größeren Netzwerken gerne ein sogenannter Route Reflector (RR) eingesetzt: Jeder eBGP-Router schickt seine via eBGP gelernten Routen via iBGP an einen bestimmten Router (den Routen-Reflektor), welcher sie sammelt und wiederum via iBGP an die anderen Router im AS verteilt. Da nun jeder BGP-sprechende Router nur noch eine BGP-Verbindung zum Route Reflector halten muss, fallen insgesamt nur noch O(n) Verbindungen an.

Da jeder BGP-Router über Routen-Informationen von anderen, insbesondere der benachbarten BGP-Routern verfügt, baut sich jeder BGP-Router eine Datenbank für die Routen zu allen erreichbaren autonomen Systemen auf. Die Größe der Tabelle mit den Routen-Informationen lag Ende 2005 bei ca. 170.000 Einträgen bei über 26.000 Autonomen Systemen.

Das BGP-Protokoll ist in RFC 1163 beschrieben. In der derzeit eingesetzten Version 4 ist es im RFC 4271 beschrieben. 1991 wurde im RFC 1269 die Border Gateway Protocol (Version 3) MIB veröffentlicht. Diese MIB ermöglicht das Management von Geräten mittels SNMP, die das BGP-Protokoll als autonomous System Routing Protocol unterstützen. Im Februar 1998 wurde das BGPv4 in RFC 2283 mit sog. Multiprotocol Extensions versehen, die aktuelle Version findet sich in RFC 4760. Damit ist BGPv4 nicht mehr rein IPv4-spezifisch, sondern unterstützt ebenso das Routing mit weiteren Protokollen der Vermittlungsschicht. U. a. ist so auch der Austausch von MPLS-Labels möglich, dies war Voraussetzung für den Einsatz von BGP/MPLS IP VPNs (RFC 4364).

Protokollübersicht

Die direkten Verbindungen zwischen benachbarten Routern werden manuell angegeben. Router, welche miteinander über BGP Routinginformationen austauschen wollen, bauen zunächst eine TCP-Verbindung auf, über welche dann die BGP-Nachrichten gesendet werden. Diese Verbindung nennt man eine BGP-Session.

BGP verwendet vier verschiedene Arten von Nachrichten im Protokoll:

OPEN

Wird nur zu Beginn einer Verbindung gesendet und muss mit einem KEEPALIVE beantwortet werden. Bei der Open Nachricht werden die Parameter BGP-Version, AS-Nummer, Hold Timer, BGP Identifier sowie optionale Parameter mitgeschickt. Danach werden Routeninformationen zwischen den Routern ausgetauscht.

UPDATE

Teilt eine Pfadänderung mit. Es kann pro Nachricht ein Pfad hinzugefügt und mehrere Pfade entfernt werden. UPDATE-Nachrichten sind das Kernstück von BGP.

NOTIFICATION

Beendet eine Verbindung und gibt Fehler- bzw Statuscodes an. Alle Pfade, die über diese beendete Verbindung empfangen wurden, müssen nun gelöscht werden. Über ein BGP-Update würde dann verbreitet werden, dass diese Route nicht mehr verfügbar ist.

KEEPALIVE

Bestätigt die OPEN-Anfrage. Zur regelmäßigen Überprüfung, ob der verbundene Router noch online ist, oder ob die Verbindung unterbrochen ist und die Pfade über den verbundenen Router somit ungültig geworden sind. Die Router, welche gerade eine BGP Session aufgebaut haben, senden sich gegenseitig in regelmäßigen Abständen eine Keepalive Nachricht. Diese besteht nur aus dem Message Header. Im Attribut "Hold Time" einer BGP-Open Nachricht wird die maximale Zeit angegeben, in der ein BGP Router eine Keepalive Nachricht vom BGP-Partner der Session erwartet. Kommt innerhalb der Hold Time keine Keepalive Nachricht an, wird die BGP-Session mit einer Notification beendet.

Genauere Beschreibung

Kernstück von BGP ist die UPDATE-Nachricht. Mit Hilfe von UPDATEs teilen sich Router die Existenz neuer Routen (sog. Announcements) bzw. den Wegfall bestehender Routen (sog. Withdrawals) mit. Der Empfänger einer UPDATE-Nachricht entscheidet anhand seiner Routing-Policies, ob er sein Routing umstellt (und daraufhin selbst UPDATEs versenden muss), ob er das UPDATE einfach nur weiterleitet (z. B. via iBGP), oder ob er die Nachricht schlicht ignoriert.

Attribute

Eine Route in BGP hat mehrere Attribute; im Folgenden werden die wichtigsten erklärt.

• Der AS_PATH beschreibt, über welche autonomen Systeme das angegebene Ziel (ein CIDR-Präfix) erreicht werden kann. Die autonomen Systeme werden hierbei über ihre AS-Nummer (ASN) identifiziert. Im AS-Pfad darf zwar keine Schleife vorkommen; jedoch ist es erlaubt, dass sich ein AS mehrmals hintereinander einträgt und somit den AS-Pfad künstlich verlängert, um die Route zwar verfügbar, aber unattraktiv zu machen.
• Die IGP-Metrik beschreibt die Kosten durch das eigene Netzwerk, um den Austrittspunkt in das nächste AS auf dem AS-Pfad zu erreichen
• Der Multi-Exit Discriminator (MED) wird verwendet, um verschiedene parallele Verbindungen zum gleichen Nachbar-AS zu priorsieren, bevorzugt wird der jeweils kleinste Wert. Dieses Attribut wird zwischen eBGP-Peers verwendet.
• Communities sind Routing Tags, anhand welcher Updates bzw. übermittelte Prefixes zu anderen BGP Peers markiert werden können. Eine BGP Community ist ein 32 Bit Wert, der von anderen BGP Routern als Filterkriterium verwendet werden kann. Neben Standard-Communities können sog. extended Communities in der Notation "12345:12345" oder als Dezimalzahl frei verwendet werden.
• Local Preference legt durch den jeweils höheren Wert einen bevorzugten Pfad aus mehreren Pfade innerhalb des gleichen AS fest.
• Next Hop ist die Angabe der IP-Adresse des Next-Hop zu einem Prefix
• Weight ist ein lokales Attribut (proprietär).
• Origin gibt die Quelle eines Prefixes an: Internal, External oder Incomplete.

Pfadauswahl

Sehr oft kommt es vor, dass ein Router zum selben Ziel verschiedene Routen mitgeteilt bekommt. Die Auswahl der Route, für welche er sich letztendlich entscheidet, ist als BGP Path Selection Process bekannt. Der Netzwerkbetreiber kann die Pfad Auswahl im Router durch die Wahl geeigneter Regeln im Router steuern und beeinflussen. Grundsätzlich läuft der BGP Path Selection Process jedoch immer nach folgenden Regeln ab:

1. Der Pfad mit dem größten Wert für "Weight" wird bevorzugt (proprietär).
2. Wenn der Wert für "Weight" identisch ist, wird der Wert mit der größten "local preference" bevorzugt.
3. Wenn die Werte für "local preference" gleich sind, wird der Pfad bevorzugt, der von BGP auf diesem Router generiert wurde.
4. Wenn kein Pfad auf diesem Router generiert wurde, bevorzuge den Pfad mit dem kürzesten AS_PATH Attribut.
5. Wenn alle AS_PATH die gleiche Länge haben, bevorzuge den niedrigsten Origin Typ (IGP ist niedriger als EGP, EGP ist niedriger als incomplete)
6. Wenn alle Origin Typen gleich sind, bevorzuge den Pfad mit dem niedrigsten MED Attribute.
7. Wenn alle Pfade die gleichen Wert für MED haben, bevorzuge externe Pfade über interne Pfade.
8. Wenn immer noch alle Pfade die gleiche Priorität haben, bevorzuge den Pfad zum nächstgelegenden IGP Nachbar.
9. Sollten alle Pfade gleich sein, bevorzuge den Pfad mit der niedrigsten IP Adresse des BGP Peers bezogen auf die Router-ID.

Schwächen von BGP

BGP weist prinzipbedingt eine Reihe von Schwächen auf, die in einer Minimalkonfiguration entstehen können. Die Schwächen werden jedoch in der Regel dadurch kompensiert, dass die Priorisierung von Pfaden Routing-Policies unterliegt, die der jeweilige Netzbetreiber steuert.

• keine Lastverteilung (load balancing) – es wird immer nur eine mögliche Route ausgewählt.
  Hierzu existieren jedoch proprietäre Erweiterungen, die Load-Sharing erlauben (maximum-prefix).
• Hop-Länge wird nicht berücksichtigt – nur die Anzahl der autonomen Systeme ist wichtig (abgesehen vom Attribut IGP-Metrik).
• Unterschiedliche Linkgeschwindigkeit wird nicht berücksichtigt – Routen werden hauptsächlich nach der Länge ausgewählt.
• Sicherheitsaspekte sind nur mangelhaft berücksichtigt;^[1][2][3] beispielsweise könnte ein Angreifer durch Spoofing Routen zwischen Providern ändern oder löschen.
  Es kann jedoch eine Authentifizierung mit einem zwischen den BGP-Peers individuell festgelegten Passwort (MD5-Hash) erfolgen.
• Route Flaps werden von Routen verursacht, welche über längere Zeiträume hinweg immer wieder hin- und herschwanken, annonciert und wieder zurückgezogen werden, etc.^[4][5]
• Update Bursts sind plötzlich auftretende große Mengen an UPDATE-Nachrichten, oft zu miteinander nicht näher korrelierten Zielen.^[6]

Quellen

1. ↑ Barry Raveendran Greene: BGPv4 Security Risk Assessment. http://www.cymru.com/Documents/barry2.pdf
2. ↑ Auflistung wissenschaftlicher Veröffentlichungen zum Thema BGP-Sicherheit
3. ↑ heise security online (27.08.2008): "Router lügen nicht - Was wenn doch?"
4. ↑ Zhenhai Duan, Jaideep Chandrashekar, Jeffrey Krasky, Kuai Xu, Zhi-Li Zhang, Damping BGP Route Flaps. Proc 23rd IEEE International Performance Computing and Communications Conference (IPCCC), 2004.
5. ↑ C. Labovitz, G. Malan, and F. Jahanian, Internet routing instability. IEEE/ACM Transactions on Networking, 6(5):515–528, 1998.
6. ↑ Ke Zhang, Amy Yen, Xiaoliang Zhao, Dan Massey, S. Felix Wu and Lixia Zhang, On Detection of Anomalous Routing Dynamics in BGP. In LNCS NETWORKING 2004, ISBN 978-3-540-21959-0

Weblinks

• A Border Gateway Protocol 4 (BGP-4), RFC 4271
• BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP), RFC 4456
• BGPlay is a Java application which displays animated graphs of the routing activity of a certain prefix within a specified time interval