Security Considerations (Sicherheitsüberlegungen)
Security Considerations (Sicherheitsüberlegungen)
Eine BGP-Implementierung MUSS (MUST) den in RFC 2385 [RFC2385] spezifizierten Authentifizierungsmechanismus unterstützen. Die durch diesen Mechanismus bereitgestellte Authentifizierung kann pro Peer erfolgen.
BGP verwendet TCP für den zuverlässigen Transport seines Datenverkehrs 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 im RFC definierte Mechanismus keine Peer-Entity-Authentifizierung bietet, können diese Verbindungen bestimmten Formen von Replay-Angriffen ausgesetzt sein, die auf der TCP-Schicht nicht erkannt werden. Solche Angriffe könnten zur Lieferung (von TCP) von „defekten" oder „gefälschten" BGP-Nachrichten führen.
Der in RFC 2385 definierte Mechanismus erweitert die normale TCP-Prüfsumme um einen 16-Byte-Nachrichtenauthentifizierungscode (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 Zugang zum Schlüssel hat, nicht leicht berechnet werden können. Eine konforme Implementierung muss diesen Mechanismus unterstützen und muss es einem Netzwerkadministrator ermöglichen, ihn pro Peer zu aktivieren.
RFC 2385 spezifiziert kein Mittel zur Verwaltung (z.B. Generierung, Verteilung und Ersetzung) der Schlüssel, die zur Berechnung des MAC verwendet werden. RFC 3562 [RFC3562] (ein informatives Dokument) bietet einige Hinweise in diesem Bereich und liefert eine Begründung zur Unterstützung dieser Hinweise. Es wird angemerkt, dass für die Kommunikation mit jedem geschützten Peer ein unterschiedlicher Schlüssel verwendet werden sollte. Wenn derselbe Schlüssel für mehrere Peers verwendet wird, können die angebotenen Sicherheitsdienste beeinträchtigt werden, z.B. aufgrund eines erhöhten Kompromittierungsrisikos bei einem Router, der andere Router negativ beeinflusst.
Die für die MAC-Berechnung verwendeten Schlüssel sollten regelmäßig geändert werden, um die Auswirkungen einer Schlüsselkompromittierung oder eines erfolgreichen kryptoanalytischen Angriffs zu minimieren. RFC 3562 schlägt eine Kryptoperiode (das Intervall, während dessen ein Schlüssel eingesetzt wird) von höchstens 90 Tagen vor. Häufigere Schlüsselwechsel verringern die Wahrscheinlichkeit, dass Replay-Angriffe (wie oben beschrieben) durchführbar sind. Ohne einen Standardmechanismus für solche Änderungen in koordinierter Weise zwischen Peers kann jedoch nicht davon ausgegangen werden, dass BGP-4-Implementierungen, die diesem 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 spezifizierten Techniken zur Zufallszahlengenerierung bieten einen Leitfaden für die Generierung von Werten, die als Schlüssel verwendet werden könnten. RFC 2385 verlangt von Implementierungen, Schlüssel zu unterstützen, die „aus einer Zeichenkette von druckbarem ASCII von 80 Bytes oder weniger bestehen". RFC 3562 schlägt vor, dass in diesem Kontext verwendete Schlüssel 12 bis 24 Bytes an zufälligen (pseudo-zufälligen) Bits sein sollten. Dies ist ziemlich konsistent mit Vorschlägen für analoge MAC-Algorithmen, die typischerweise Schlüssel im Bereich von 16 bis 20 Bytes verwenden. Um am unteren Ende dieses Bereichs genügend zufällige Bits bereitzustellen, bemerkt RFC 3562 auch, dass eine typische ASCII-Textzeichenkette nahe an der Obergrenze für die in RFC 2385 spezifizierte Schlüssellänge liegen müsste.
Die Analyse der BGP-Schwachstellen wird in [RFC4272] diskutiert.