13. Sicherheitsüberlegungen

13. Sicherheitsüberlegungen (Security Considerations)

13.1. Data Plane (Data Plane)

Mit „Sicherheit im Data Plane“ (data plane) meinen wir den Schutz gegen folgende Möglichkeiten:

• Pakete (packet) aus dem Inneren eines VPN gelangen an einen Standort außerhalb dieses VPN auf eine Weise, die nicht der Richtlinie (policy) dieses VPN entspricht.

• Pakete von außerhalb eines VPN gelangen in einen Standort dieses VPN auf eine Weise, die nicht der Richtlinie dieses VPN entspricht.

Unter folgenden Bedingungen:

1. ein Backbone-Router (backbone router) auf einer bestimmten Data-Link-Verbindung (data link) kein markiertes Paket annimmt, es sei denn, es ist sichergestellt, dass diese Data-Link-Verbindung nur mit vertrauenswürdigen (trusted) Systemen verbunden ist, oder es ist sichergestellt, dass solche Pakete das Backbone verlassen, bevor der IP-Header (IP header) oder ein tieferes Label im Stapel untersucht wird, und

2. mit Label versehene VPN-IPv4-Routen nicht von nicht vertrauenswürdigen oder unzuverlässigen Routing-Peers (routing peer) akzeptiert werden, und

3. kein erfolgreicher Angriff (attack) auf den Control Plane (control plane) geführt wurde,

bietet die von dieser Architektur gebotene Data-Plane-Sicherheit im Wesentlichen dieselbe wie sie Frame-Relay- oder ATM-Backbones für VPN bieten. Sind die Geräte unter SP-Kontrolle korrekt konfiguriert, gelangen Daten weder unberechtigt in ein VPN noch aus einem VPN heraus.

Die Bedingung 1 lässt sich präziser fassen. Ein von einem bestimmten Nachbarn (neighbor) empfangenes markiertes Paket sollte verworfen (discard) werden, es sei denn, eine der beiden folgenden Bedingungen trifft zu:

• das oberste Label (top label) des Pakets hat einen Labelwert, den das empfangende System diesem Nachbarn zugewiesen hat, oder

• das oberste Label des Pakets hat einen Labelwert, den das empfangende System einem System jenseits dieses Nachbarn zugewiesen hat (d. h. wenn bekannt ist, dass der Pfad vom System, dem das Label zugewiesen wurde, zum empfangenden System über diesen Nachbarn verlaufen kann).

Die Bedingung 2 ist im Fall von Inter-Provider-VPN (siehe Abschnitt 10) am wichtigsten. Für Inter-Provider-VPN nach Verfahren b) aus Abschnitt 10 ist Bedingung 2 leicht zu prüfen. (Die Sicherheitsfrage bei Nutzung von Verfahren c) aus Abschnitt 10 bleibt weiterer Untersuchung vorbehalten.)

Es ist erwähnenswert, dass die Nutzung von MPLS das Bereitstellen der Data-Plane-Sicherheit viel einfacher macht als der Versuch, eine IP-Tunnel-Form anstelle des äußeren MPLS-Labels zu nutzen. Es ist einfach, einen Grenzrouter so zu konfigurieren, dass er ein markiertes Paket ablehnt, sofern nicht die erste der obigen Bedingungen zutrifft. Einen Router so zu konfigurieren, dass er ein IP-getunneltes Paket ablehnt, dessen Zieladresse die eines PE-Routers ist, ist hingegen recht schwierig; zwar nicht unmöglich, aber es hat sowohl administrative als auch performancebezogene Auswirkungen.

MPLS-in-IP- und MPLS-in-GRE-Tunnel sind in [MPLS-in-IP-GRE] spezifiziert. Werden solche Tunnel zur Übertragung von VPN-Paketen genutzt, müssen die in Abschnitt 8 jenes Dokuments beschriebenen Sicherheitsüberlegungen vollständig verstanden werden. Jede BGP/MPLS-IP-VPN-Implementierung, die VPN-Pakete wie dort beschrieben tunneln lässt, MUSS eine nutzbare IPsec-Implementierung enthalten. Ist der Tunnel nicht durch IPsec geschützt, ist die in Abschnitt 8.2 jenes Dokuments beschriebene IP-Adressfilterung an den Grenzroutern das einzige Mittel, um sicherzustellen, dass ein Paket, das an einem bestimmten Egress-PE aus dem Tunnel austritt, tatsächlich von der richtigen Tunnelkopfknoten eingefügt wurde (also keine gefälschte Quelladresse — spoofed source address — hat). Da Grenzrouter häufig nur Quelladressen filtern, kann die Paketfilterung wirkungslos sein, es sei denn, der Egress-PE kann die IP-Quelladresse jedes empfangenen getunnelten Pakets prüfen und mit einer Liste gültiger Tunnelkopfadressen vergleichen. Jede Implementierung, die MPLS-in-IP und/oder MPLS-in-GRE ohne IPsec zulässt, MUSS dem Egress-PE erlauben, die IP-Quelladresse jedes empfangenen getunnelten Pakets auf diese Weise zu validieren.

Im Fall, dass mehrere CE-Router über eine LAN-Schnittstelle mit einem PE-Router verbunden sind, muss zur Sicherstellung angemessener Sicherheit eine der beiden folgenden Bedingungen erfüllt sein:

1. Alle CE-Router im LAN gehören zum selben VPN, oder

2. ein vertrauenswürdiger und sicherer LAN-Switch teilt das LAN in mehrere VLANs, von denen jedes nur die Systeme eines einzigen VPN enthält; in diesem Fall wird der Switch das passende VLAN-Tag (tag) an jedes Paket anfügen, bevor er es an den PE-Router weiterleitet.

Kryptografische Privatsphäre (cryptographic privacy) wird weder von dieser Architektur noch von Frame-Relay- oder ATM-VPN geboten. Diese Architekturen sind alle mit der Nutzung von Kryptografie (cryptography) auf CE-CE-Basis kompatibel, falls gewünscht.

Die Nutzung von Kryptografie auf PE-PE-Basis bleibt weiterer Untersuchung vorbehalten.

13.2. Control Plane (Control Plane)

Die Data-Plane-Sicherheit des vorigen Abschnitts hängt von der Control-Plane-Sicherheit ab. Zur Sicherstellung dürfen weder BGP- noch LDP-Verbindungen mit nicht vertrauenswürdigen Peers aufgebaut werden. Die MD5-Authentisierungsoption von TCP/IP [TCP-MD5] sollte mit beiden Protokollen genutzt werden. Das Routing-Protokoll innerhalb des SP-Netzes sollte ähnlich abgesichert werden.

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

Wird die physische Sicherheit dieser Geräte kompromittiert, kann auch die Data-Plane-Sicherheit kompromittiert werden.

Die üblichen Maßnahmen sind zu ergreifen, um sicherzustellen, dass IP-Verkehr aus dem öffentlichen Internet nicht genutzt werden kann, um die Konfiguration dieser Geräte zu ändern oder Denial-of-Service-Angriffe (Denial of Service) gegen sie zu führen.