Security Considerations (Sicherheitsüberlegungen)

Eine BGP-Implementierung muss (MUST) den in RFC 2385 [RFC2385] spezifizierten Authentifizierungsmechanismus unterstützen. Die durch diesen Mechanismus bereitgestellte Authentifizierung könnte auf Pro-Peer-Basis erfolgen.

BGP nutzt TCP für den zuverlässigen Transport seines Verkehrs zwischen Peer-Routern. Um verbindungsorientierte Integrität und Datenursprungsauthentifizierung auf Punkt-zu-Punkt-Basis bereitzustellen, spezifiziert BGP die Verwendung des in RFC 2385 definierten Mechanismus. Diese Dienste sollen aktive Abhörangriffe gegen die Inter-Router-TCP-Verbindungen erkennen und ablehnen. Ohne die Verwendung von Mechanismen, die diese Sicherheitsdienste bewirken, können Angreifer diese TCP-Verbindungen stören und/oder sich als legitimer Peer-Router ausgeben. Da der in der RFC definierte Mechanismus keine Peer-Entity-Authentifizierung bietet, können diese Verbindungen einigen Formen von Replay-Angriffen unterliegen, die auf der TCP-Schicht nicht erkannt werden. Solche Angriffe könnten zur Zustellung (von TCP) von "kaputten" oder "gefälschten" BGP-Nachrichten führen.

Der in RFC 2385 definierte Mechanismus erweitert die normale TCP-Prüfsumme um einen 16-Byte-Message-Authentication-Code (MAC), der über dieselben Daten wie die TCP-Prüfsumme berechnet wird. Dieser MAC basiert auf einer Einweg-Hash-Funktion (MD5) und der Verwendung eines geheimen Schlüssels. Der Schlüssel wird zwischen Peer-Routern geteilt und wird verwendet, um MAC-Werte zu generieren, die von einem Angreifer, der keinen Zugriff auf den Schlüssel hat, nicht leicht berechnet werden können. Eine konforme Implementierung muss (MUST) diesen Mechanismus unterstützen und muss (MUST) einem Netzwerkadministrator erlauben, ihn auf Pro-Peer-Basis zu aktivieren.

RFC 2385 spezifiziert keine Mittel zur Verwaltung (z.B. Generierung, Verteilung und Ersetzung) der Schlüssel, die zur Berechnung des MAC verwendet werden. RFC 3562 [RFC3562] (ein Informationsdokument) bietet einige Leitlinien in diesem Bereich und liefert Begründungen zur Unterstützung dieser Leitlinien. Es wird darauf hingewiesen, dass ein eindeutiger Schlüssel für die Kommunikation mit jedem geschützten Peer verwendet werden sollte. Wenn derselbe Schlüssel für mehrere Peers verwendet wird, können die angebotenen Sicherheitsdienste degradiert werden, z.B. aufgrund eines erhöhten Kompromittierungsrisikos bei einem Router, das sich nachteilig auf andere Router auswirkt.

Die für die MAC-Berechnung verwendeten Schlüssel sollten regelmäßig geändert werden, um die Auswirkungen einer Schlüsselkompromittierung oder eines erfolgreichen kryptanalytischen Angriffs zu minimieren. RFC 3562 schlägt eine Kryptoperiode (das Intervall, während dessen ein Schlüssel verwendet wird) von höchstens 90 Tagen vor. Häufigere Schlüsselwechsel verringern die Wahrscheinlichkeit, dass Replay-Angriffe (wie oben beschrieben) durchführbar sind. In Ermangelung eines Standardmechanismus zur Durchführung solcher Änderungen auf koordinierte Weise zwischen Peers kann man jedoch nicht davon ausgehen, dass BGP-4-Implementierungen, die dieser RFC entsprechen, häufige Schlüsselwechsel unterstützen.

Offensichtlich sollte jeder Schlüssel auch so gewählt werden, dass er für einen Angreifer schwer zu erraten ist. Die in RFC 1750 für die Zufallszahlengenerierung spezifizierten Techniken bieten einen Leitfaden für die Generierung von Werten, die als Schlüssel verwendet werden könnten. RFC 2385 fordert Implementierungen auf, Schlüssel zu unterstützen, die "aus einer Zeichenkette druckbarer ASCII von 80 Bytes oder weniger bestehen". RFC 3562 schlägt vor, dass Schlüssel, die in diesem Kontext verwendet werden, 12 bis 24 Bytes an zufälligen (pseudo-zufälligen) Bits sein sollten. Dies steht ziemlich im Einklang mit Vorschlägen für analoge MAC-Algorithmen, die typischerweise Schlüssel im Bereich von 16 bis 20 Bytes verwenden. Um genügend zufällige Bits am unteren Ende dieses Bereichs bereitzustellen, beobachtet RFC 3562 auch, dass eine typische ASCII-Textzeichenkette nahe der Obergrenze für die in RFC 2385 spezifizierte Schlüssellänge liegen müsste.

Die Analyse der BGP-Schwachstellen wird in [RFC4272] diskutiert.