13. Security Considerations (Sicherheitsüberlegungen)

13.1. Data Plane (Datenebene)

Mit Sicherheit in der "Datenebene" meinen wir den Schutz gegen folgende Möglichkeiten:

Pakete aus einem VPN werden an einen Standort außerhalb des VPN weitergeleitet, jedoch auf eine Weise, die nicht den Richtlinien des VPN entspricht.
Pakete von außerhalb eines VPN gelangen in einen Standort des VPN, jedoch auf eine Weise, die nicht den Richtlinien des VPN entspricht.

Unter der Voraussetzung, dass:

Backbone-Router gelabelte Pakete über eine bestimmte Datenverbindung nicht akzeptieren, es sei denn, es ist bekannt, dass diese Datenverbindung nur zu einem vertrauenswürdigen System führt, oder es sei denn, es ist bekannt, dass solche Pakete das Backbone verlassen, bevor der IP-Header oder irgendein niedrigeres Label im Stapel inspiziert wird, und
gelabelte VPN-IPv4-Routen nicht von nicht vertrauenswürdigen oder unzuverlässigen Routing-Peers akzeptiert werden,
die Steuerebene nicht durch einen Angriff kompromittiert wurde,

bietet diese Architektur Datenebenensicherheit, die praktisch identisch mit der ist, die Frame Relay- oder ATM-Backbones für VPNs bieten. Wenn die unter der Kontrolle des SP stehende Ausrüstung korrekt konfiguriert ist, werden keine Daten in ein VPN eintreten oder es verlassen, es sei denn, sie sind dazu berechtigt.

Bedingung 1 oben kann präziser formuliert werden. Gelabelte Pakete, die von einem bestimmten Nachbarn empfangen werden, müssen verworfen werden, es sei denn, eine der beiden folgenden Bedingungen ist erfüllt:

das Top-Label des Pakets hat einen Label-Wert, den das empfangende System an diesen Nachbarn verteilt hat, oder
das Top-Label des Pakets hat einen Label-Wert, den das empfangende System an ein System jenseits dieses Nachbarn verteilt hat (d. h. wenn bekannt ist, dass der Pfad von dem System, an das das Label verteilt wurde, zum empfangenden System über diesen Nachbarn führen kann).

Bedingung 2 oben ist am von Belang im Falle von Inter-Provider-VPNs (siehe Abschnitt 10). Bei Inter-Provider-VPNs, die gemäß Schema (b) von Abschnitt 10 aufgebaut sind, ist Bedingung 2 leicht zu überprüfen. (Sicherheitsprobleme bei der Verwendung von Schema (c) von Abschnitt 10 sind Gegenstand weiterer Studien.)

Es ist erwähnenswert, dass die Verwendung von MPLS die Bereitstellung von Datenebenensicherheit viel einfacher macht, als zu versuchen, irgendeine Form von IP-Tunneling anstelle des MPLS-Außenlabels zu verwenden. Es ist sehr einfach, einen Grenzrouter dazu zu bringen, gelabelte Pakete abzulehnen, es sei denn, die erste Bedingung oben trifft auf ihn zu. Es ist viel schwieriger, einen Router so zu konfigurieren, dass er IP-Pakete ablehnt, wenn es sich um IP-Tunnelpakete handelt, deren Ziel ein PE-Router ist; es ist sicherlich nicht unmöglich, dies zu tun, aber es hat sowohl administrative als auch Leistungsauswirkungen.

MPLS-in-IP- und MPLS-in-GRE-Tunnel sind in [MPLS-in-IP-GRE] spezifiziert. Wenn eine dieser Tunnelarten zum Transport von VPN-Paketen gewünscht wird, dann müssen die in Abschnitt 8 dieses Dokuments beschriebenen Sicherheitsüberlegungen vollständig verstanden werden. Jede BGP/MPLS IP VPN-Implementierung, die das Tunneln von VPN-Paketen wie in jenem Dokument beschrieben erlaubt, MUSS (MUST) eine Implementierung von IPsec enthalten, die wie darin beschrieben verwendet werden soll. Wenn der Tunnel nicht durch IPsec gesichert ist, dann sind die in Abschnitt 8.2 jenes Dokuments beschriebenen IP-Adressfilterungstechniken an Grenzroutern die einzige Möglichkeit sicherzustellen, dass ein Paket, das an einem bestimmten Ausgangs-PE aus einem Tunnel austritt, tatsächlich vom korrekten Tunnel-Kopfknoten (Head-Node) in den Tunnel gelegt wurde (d. h. dass das Paket keine gespoofte Quelladresse hat). Da Grenzrouter oft nur auf die Quelladresse filtern, kann die Paketfilterung unwirksam sein, es sei denn, der Ausgangs-PE kann die IP-Quelladresse aller Tunnelpakete, die er empfängt, inspizieren und sie mit einer Liste von IP-Adressen vergleichen, die gültige Tunnel-Kopfadressen sind. Jede Implementierung, die die Verwendung von MPLS-in-IP- und/oder MPLS-in-GRE-Tunneln ohne IPsec erlaubt, MUSS (MUST) es dem Ausgangs-PE ermöglichen, die IP-Quelladresse jedes Tunnelpakets, das er auf diese Weise empfängt, zu validieren. Wenn mehrere CE-Router über eine LAN-Schnittstelle an einen PE-Router angeschlossen sind, muss zur Gewährleistung einer angemessenen Sicherheit eine der folgenden Bedingungen erfüllt sein:

alle CE-Router im LAN gehören zum selben VPN, oder
ein vertrauenswürdiger und sicherer LAN-Switch partitioniert das LAN in mehrere VLANs, so dass jedes VLAN nur Systeme aus einem einzigen VPN enthält; in diesem Fall hängt der Switch das entsprechende VLAN-Tag an jedes Paket an, bevor er es an den PE-Router weiterleitet.

Diese Architektur bietet keine kryptografische Privatsphäre, genauso wenig wie Frame Relay- oder ATM-VPNs. All diese Architekturen sind mit der Verwendung von CE-CE-basierter Verschlüsselung kompatibel, wenn dies gewünscht wird.

Die Verwendung von PE-PE-basierter Verschlüsselung ist Gegenstand weiterer Studien.

13.2. Control Plane (Steuerebene)

Die Datenebenensicherheit des vorherigen Abschnitts hängt von der Steuerebenensicherheit ab. Um Sicherheit zu gewährleisten, sollten keine BGP- oder LDP-Verbindungen mit nicht vertrauenswürdigen Peers hergestellt werden. Beide Protokolle sollten die TCP/IP MD5-Authentifizierungsoption [TCP-MD5] verwenden. Routing-Protokolle innerhalb des SP-Netzwerks sollten auf ähnliche Weise gesichert werden.

13.3. Security of P and PE Devices (Sicherheit von P- und PE-Geräten)

Wenn die physische Sicherheit dieser Geräte kompromittiert wird, kann auch die Datenebenensicherheit kompromittiert werden.

Die üblichen Schritte sollten unternommen werden, um sicherzustellen, dass IP-Verkehr aus dem öffentlichen Internet nicht dazu verwendet werden kann, die Konfiguration dieser Geräte zu ändern oder einen Denial of Service-Angriff gegen sie zu starten.