1. Einleitung

1. Einleitung (Introduction)

In diesem Dokument wird eine Methode beschrieben, mit der ein Diensteanbieter (Service Provider, SP) sein IP-Backbone (backbone) nutzen kann, um für Kunden IP-Virtual Private Networks (VPN) bereitzustellen. Die Methode verwendet ein „Peer-Modell“ (peer model): Die Kunden-Edge-Router (Customer Edge-Router, CE-Router) senden ihre Routen (route) an die Provider-Edge-Router (Provider Edge-Router, PE-Router); der Routing-Algorithmus des Kunden sieht keinerlei „Overlay“ (overlay), und die CE-Router verschiedener Standorte sind nicht peer-zueinander. Das „IP“ in „IP-VPN“ bedeutet, dass der PE IP-Datagramme (datagram) vom CE empfängt, deren IP-Header (header) untersucht und entsprechend weiterleitet.

Die Routen jedes VPN erhalten eine MPLS-Etikette (label) (Multiprotocol Label Switching) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS]; wenn BGP (Border Gateway Protocol) [BGP, BGP-MP] eine VPN-Route verteilt, verteilt es gleichzeitig ein MPLS-Etikette für diese Route. Bevor ein Kunden-Datenpaket (packet) das Provider-Backbone durchquert, wird es mit einer MPLS-Etikette gekapselt, die der Route im Kunden-VPN entspricht, die am besten zur Zieladresse (destination address) des Pakets passt. Das MPLS-Paket wird dann weiter gekapselt (z. B. mit einer weiteren MPLS-Etikette oder einem IP- oder GRE-Tunnelkopf (tunnel header) [MPLS-in-IP-GRE]) und durch einen Tunnel (tunnel) zum richtigen PE-Router transportiert. Daher müssen die Core-Router des Backbones (Backbone-Core-Router, also P-Router) keine VPN-Routen kennen.

Das Hauptziel dieser Methode ist es, den Fall zu unterstützen, in dem ein Kunde IP-Backbone-Dienste von einem oder mehreren Diensteanbietern bezieht, mit denen er vertraglich verbunden ist. Der Kunde kann ein Unternehmen, eine Gruppe von Unternehmen, die ein Extranet benötigen, ein Internet Service Provider, ein Application Service Provider oder ein anderer VPN-Diensteanbieter sein, der dieselbe Methode nutzt, um seinen eigenen Kunden VPNs anzubieten, usw. Die Methode ermöglicht es dem Kunden, den Backbone-Dienst sehr einfach zu nutzen; für den Diensteanbieter bietet sie gute Skalierbarkeit und Flexibilität und erlaubt ihm, Mehrwert hinzuzufügen.

1.1. Virtual Private Networks (Virtual Private Networks)

Betrachten wir eine Gruppe von „Standorten“ (site), die mit einem gemeinsamen Netz verbunden sind, das wir „Backbone“ (backbone) nennen. Legen wir eine Richtlinie (policy) fest, die diese Standortmenge in Teilmengen unterteilt, mit der Regel, dass zwei Standorte nur dann über das Backbone eine IP-Verbindung (connectivity) herstellen dürfen, wenn beide demselben VPN angehören.

Diese Teilmengen sind die Virtual Private Networks (VPN). Zwei Standorte haben nur dann Konnektivität über das gemeinsame Backbone, wenn es ein VPN gibt, das beide enthält. Gehören zwei Standorte keinem gemeinsamen VPN an, haben sie über dieses Backbone keine Konnektivität.

Gehören alle Standorte eines VPN zum selben Unternehmen, kann das VPN als „Intranet“ betrachtet werden; gehören die Standorte verschiedenen Unternehmen an, ist es ein „Extranet“. Ein Standort kann mehreren VPN angehören, z. B. einem Intranet und mehreren Extranets. Im Allgemeinen trifft der Begriff „VPN“ in diesem Dokument keine Unterscheidung zwischen Intranet und Extranet.

Den Eigentümer eines Standorts nennen wir „Kunde“ (customer), den Eigentümer oder Betreiber des Backbones „Diensteanbieter“ (Service Provider, SP). Der Kunde erhält vom SP einen „VPN-Dienst“ (VPN service).

Ein Kunde kann ein einzelnes Unternehmen, eine Unternehmensgruppe, ein Internet Service Provider, ein Application Service Provider oder ein anderer SP sein, der seinen Kunden einen ähnlichen VPN-Dienst anbietet, usw.

Die Richtlinie, die bestimmt, ob eine Standortmenge ein VPN bildet, liegt beim Kunden. Manche Kunden wollen, dass diese Richtlinie vollständig vom SP umgesetzt wird; andere wollen die Verantwortung mit dem SP teilen. Dieses Dokument spezifiziert Mechanismen, mit denen solche Richtlinien umgesetzt werden können. Die beschriebenen Mechanismen sind allgemein genug, um sowohl vom SP allein als auch durch Zusammenarbeit von VPN-Kunde und SP unterstützt zu werden; der Schwerpunkt liegt jedoch meist auf dem ersten Fall.

Die hier erörterten Mechanismen ermöglichen ein weites Spektrum an Richtlinien. Innerhalb eines VPN kann z. B. jedem Standort eine direkte Route zu jedem anderen Standort erlaubt werden („Full Mesh“); oder der Verkehr (traffic) zwischen bestimmten Standortpaaren kann über einen dritten Standort geleitet werden. Dies ist nützlich, wenn der Verkehr zwischen einem Standortpaar über eine Firewall (firewall) an einem dritten Standort fließen soll.

In diesem Dokument beschränken wir die Diskussion auf den Fall, dass der Kunde ausdrücklich VPN-Dienste von einem SP oder einer Gruppe von SP bezieht, die sich auf die Bereitstellung des VPN geeinigt haben. Der Kunde kauft also nicht nur Internetzugang (Internet access) beim SP, und der VPN-Verkehr durchquert kein Netz (networks) zufällig verbundener SP.

Wir beschränken die Diskussion ferner auf den Fall, dass das Backbone dem Kunden einen IP-Dienst (nicht etwa einen Layer-2-Dienst (layer 2) wie Frame Relay, ATM, Ethernet, HDLC oder PPP) bietet. Der Kunde kann sich über einen dieser (oder andere) Layer-2-Dienste mit dem Backbone verbinden, aber dieser Layer-2-Dienst endet an der „Kante“ (edge) des Backbones, wo die IP-Datagramme des Kunden aus etwaiger Layer-2-Kapselung (encapsulation) extrahiert werden.

Im restlichen Teil dieser Einleitung legen wir zunächst einige Eigenschaften dar, die VPNs aufweisen sollten; der Rest des Dokuments spezifiziert eine Reihe einsetzbarer Mechanismen, um ein VPN-Modell (model) mit all diesen Eigenschaften bereitzustellen. Dieser Abschnitt führt auch einige in der restlichen Arbeit verwendete Fachbegriffe ein.

1.2. Customer Edge und Provider Edge (Customer Edge and Provider Edge)

Router (router) können auf vielfältige Weise miteinander oder mit Endsystemen (end system) verbunden sein: PPP-Verbindungen, ATM-Virtual Circuits (VC), Frame-Relay-VCs, Ethernet-Schnittstellen, VLANs (Virtual Local Area Network) über Ethernet, GRE-Tunnel, L2TP-Tunnel (Layer 2 Tunneling Protocol), IPsec-Tunnel usw. Wir verwenden den Begriff „Attachment Circuit“ (attachment circuit) als Oberbegriff für derartige Verbindungsmittel zu einem Router. Ein Attachment Circuit kann eine Verbindung sein, die üblicherweise als „Data Link“ (data link) angesehen wird, oder ein Tunnel; entscheidend ist, dass zwei Geräte über den Attachment Circuit Netzwerkschicht-Peers (network layer peer) werden können.

Jeder VPN-Standort muss eines oder mehrere Customer-Edge-Geräte (Customer Edge, CE) enthalten. Jedes CE-Gerät ist über einen Attachment Circuit mit einem oder mehreren Provider-Edge-Routern (PE) verbunden.

Router im SP-Netz, die nicht mit CE-Geräten verbunden sind, heißen P-Router (P router).

Ein CE-Gerät kann ein Host (host) oder ein Router sein. Im typischen Fall enthält ein Standort mehrere Router, von denen einige mit PE-Routern verbunden sind. Der mit einem PE-Router verbundene Standort-Router ist das CE-Gerät bzw. der „CE-Router“. Nichts hindert jedoch einen Host ohne Routing-Funktion daran, direkt mit einem PE-Router verbunden zu sein — in diesem Fall ist der Host ein CE-Gerät.

Mitunter ist ein Layer-2-Switch (layer 2 switch) physisch mit dem PE-Router verbunden. In diesem Fall bezeichnen wir den Layer-2-Switch nicht als CE-Gerät; vielmehr sind die Hosts und Router, die über diesen Layer-2-Switch mit dem PE-Router kommunizieren, die CE-Geräte, wobei die Layer-2-Infrastruktur (infrastructure) transparent ist. Bietet die Layer-2-Infrastruktur einen Multipoint-Dienst (multipoint), können mehrere CE-Geräte über denselben Attachment Circuit mit dem PE-Router verbunden sein.

Die CE-Geräte gehören logisch zum VPN des Kunden; die PE- und P-Router gehören logisch zum Netz des SP.

Der Attachment Circuit, über den ein Paket vom CE zum PE gelangt, heißt „Ingress Attachment Circuit“ (ingress attachment circuit) dieses Pakets, und dieser PE ist der „Ingress PE“ (ingress PE); der Attachment Circuit vom PE zum CE heißt „Egress Attachment Circuit“ (egress attachment circuit), und dieser PE ist der „Egress PE“ (egress PE).

Wenn ein PE-Router mit einem CE-Gerät an einem Standort eines bestimmten VPN verbunden ist, sagen wir, dieser PE-Router sei „mit diesem VPN verbunden“; ebenso, wenn ein PE-Router mit einem CE-Gerät an einem bestimmten Standort verbunden ist, sei er „mit diesem Standort verbunden“.

Ist das CE-Gerät ein Router, ist es das Routing-Peer des (bzw. der) mit ihm verbundenen PE-Router, aber nicht der Routing-Peers der CE-Router anderer Standorte. Die Router verschiedener Standorte tauschen keine Routing-Informationen (routing information) direkt aus; tatsächlich müssen sie einander nicht einmal kennen. Der Kunde hat also weder ein zu verwaltendes Backbone noch ein „virtuelles Backbone“ (virtual backbone) und muss sich um kein Standort-übergreifendes Routing (inter-site routing) kümmern. Mit anderen Worten: Im hier beschriebenen Ansatz ist das VPN kein „Overlay“ (overlay) über das SP-Netz.

Hinsichtlich der Verwaltung der Edge-Geräte besteht eine klare Verwaltungsgrenze zwischen SP und Kunde. Der Kunde muss für Verwaltungszwecke nicht auf PE- oder P-Router zugreifen, und der SP muss für Verwaltungszwecke nicht auf CE-Geräte zugreifen.

1.3. VPNs mit überlappenden Adressräumen (VPNs with Overlapping Address Spaces)

Haben zwei VPN keine gemeinsamen Standorte, können ihre Adressräume (address space) überlappen. Das heißt, eine Adresse kann im VPN V1 als Adresse des Systems (system) S1 und im VPN V2 als Adresse eines völlig anderen Systems S2 dienen. Dies ist häufig der Fall, wenn jedes VPN den privaten Adressraum (private address space) gemäß RFC 1918 nutzt. Innerhalb jedes VPN muss selbstverständlich jede Adresse eindeutig sein.

Selbst wenn zwei VPN einen gemeinsamen Standort haben, können ihre Adressräume überlappen, solange keine Kommunikation zwischen den Systemen mit solchen Adressen und den Systemen am gemeinsamen Standort erforderlich ist.

1.4. VPNs mit unterschiedlichen Routen zum selben System (VPNs with Different Routes to the Same System)

Obwohl ein Standort mehreren VPN angehören kann, ist die Route zu einem bestimmten System an diesem Standort nicht in allen VPN notwendigerweise gleich. Angenommen, wir haben ein Intranet aus den Standorten A, B, C und ein Extranet aus A, B, C sowie einem „fremden“ (foreign) Standort D. Nehmen wir an, an Standort A steht ein Server (server), den Clients (client) von B, C oder D nutzen sollen. Nehmen wir ferner an, an Standort B steht eine Firewall. Wir wollen, dass der gesamte Verkehr von D zu diesem Server über die Firewall geleitet wird, um den Zugriff für Extranet-Verkehr zu steuern. Den Verkehr von C zu diesem Server wollen wir jedoch nicht über die Firewall leiten, da es sich um Intranet-Verkehr handelt.

Man kann zwei Routen für diesen Server konfigurieren. Eine Route wird von den Standorten B und C genutzt und leitet den Verkehr direkt zu Standort A; die zweite Route wird von Standort D genutzt und leitet den Verkehr stattdessen zur Firewall an Standort B. Lässt die Firewall den Verkehr passieren, erscheint er anschließend als vom Standort B stammend und wird entlang der Route zu Standort A weitergeleitet.

1.5. SP-Backbone-Router (SP Backbone Routers)

Das Backbone des SP besteht aus den PE-Routern sowie weiteren Routern, die nicht mit CE-Geräten verbunden sind (den „P-Routern“).

Müsste jeder Router im SP-Backbone die Routing-Informationen (routing information) aller vom SP unterstützten VPN halten, ergäbe sich ein ernstes Skalierbarkeitsproblem (scalability) — die Zahl unterstützter Standorte wäre durch die Menge an Routing-Informationen begrenzt, die ein einzelner Router speichern kann. Entscheidend ist daher, dass Routing-Informationen zu einem bestimmten VPN nur in den PE-Routern existieren, die mit diesem VPN verbunden sind. Insbesondere benötigen P-Router überhaupt keine „VPN-spezifischen“ Routing-Informationen. (Diese Bedingung muss möglicherweise für Multicast-Routing (multicast routing) gelockert werden; dies wird hier nicht weiter behandelt, findet sich aber in [VPN-MCAST].)

So wie der VPN-Eigentümer kein zu verwaltendes Backbone oder „virtuelles Backbone“ hat, muss auch der SP kein eigenes Backbone oder „virtuelles Backbone“ für jedes VPN verwalten. Das Standort-übergreifende Routing im Backbone ist optimal (im Rahmen der zum Aufbau des VPN genutzten Richtlinien) und wird durch keine künstliche Tunnel-„virtuelle Topologie“ (virtual topology) eingeschränkt.

Abschnitt 10 erörtert einige Besonderheiten, die auftreten, wenn sich das Backbone über mehrere Diensteanbieter erstreckt.

1.6. Sicherheit (Security)

Die hier beschriebenen VPN sind darauf ausgelegt, ein Sicherheitsniveau zu bieten, das dem mit einem Layer-2-Backbone (z. B. Frame Relay) erreichbaren entspricht, selbst ohne Verschlüsselungsmaßnahmen. Das heißt, sofern keine Fehlkonfiguration vorliegt und keine verschiedenen VPN bewusst miteinander verbunden werden, kann ein System in einem VPN nicht auf ein System in einem anderen VPN zugreifen. Die beschriebene Methode verschlüsselt die Daten natürlich nicht und bietet kein Mittel, um festzustellen, ob Daten auf dem Transport verändert wurden. Sind diese Fähigkeiten erforderlich, müssen zusätzlich Verschlüsselungsmaßnahmen angewendet werden. (Siehe z. B. [MPLS/BGP-IPsec].) Abschnitt 13 erörtert Sicherheit detaillierter.