1. Introduction (Einleitung)

Dieses Dokument beschreibt eine Methode, mit der ein Dienstanbieter ein IP-Backbone verwenden kann, um IP Virtual Private Networks (VPNs) für seine Kunden bereitzustellen. Diese Methode verwendet ein "Peering-Modell", bei dem der Router am Kundenrand (CE-Router) dem Router am Anbieterand (PE-Router) seine Routen peer-to-peer mitteilt. Das Border Gateway Protocol (BGP) [BGP, BGP-MP] wird dann vom Dienstanbieter verwendet, um die Routen eines bestimmten VPNs zwischen den PE-Routern auszutauschen, die an dieses VPN angeschlossen sind. Dies geschieht in einer Weise, die sicherstellt, dass Routen von verschiedenen VPNs getrennt bleiben, selbst wenn zwei VPNs einen überlappenden Adressraum haben. PE-Router verteilen Routen von anderen CE-Routern in einem bestimmten VPN an die CE-Router in diesem VPN. CE-Router peeren nicht miteinander, sodass für den Routing-Algorithmus des VPNs kein "Overlay" sichtbar ist. Der Begriff "IP" in "IP VPN" wird verwendet, um anzuzeigen, dass der PE IP-Datagramme vom CE empfängt, deren IP-Header untersucht und sie entsprechend weiterleitet.

Jeder Route innerhalb eines VPNs wird ein Multiprotocol Label Switching (MPLS)-Label [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] zugewiesen; wenn BGP eine VPN-Route verteilt, verteilt es auch ein MPLS-Label für diese Route. Bevor ein Kundendatenpaket das Backbone des Dienstanbieters durchquert, wird es mit dem MPLS-Label gekapselt, das der VPN-Route des Kunden entspricht, die am besten zur Zieladresse des Pakets passt. Dieses MPLS-Paket wird dann weiter gekapselt (z. B. mit einem anderen MPLS-Label oder mit einem IP- oder Generic Routing Encapsulation (GRE)-Header [MPLS-in-IP-GRE]), damit es durch das Backbone zum entsprechenden PE-Router getunnelt werden kann. Auf diese Weise müssen die Core-Router des Backbones die VPN-Routen nicht kennen.

Das primäre Ziel dieser Methode ist die Unterstützung des Falls, in dem der Kunde IP-Backbone-Dienste von einem oder mehreren Dienstanbietern bezieht, mit denen er vertragliche Beziehungen unterhält. Der Kunde kann ein Unternehmen, eine Gruppe von Unternehmen, die ein Extranet benötigen, ein Internetdienstanbieter, ein Anwendungsdienstanbieter, ein anderer VPN-Dienstanbieter, der dieselbe Methode zur Bereitstellung von VPNs für seine eigenen Kunden verwendet, usw. sein. Diese Methode macht es für den Kunden sehr einfach, die Backbone-Dienste zu nutzen. Sie ist auch für den Dienstanbieter sehr skalierbar und flexibel und ermöglicht es dem Dienstanbieter, Mehrwert zu schaffen.

1.1. Virtual Private Networks (Virtuelle Private Netzwerke)

Betrachten wir eine Menge von "Standorten", die an ein gemeinsames Netzwerk angeschlossen sind, das wir "Backbone" nennen. Wenden wir nun einige Richtlinien an, um eine Reihe von Teilmengen dieser Sammlung zu erstellen, und geben wir die folgende Regel vor: Zwei Standorte haben eine IP-Konnektivität über dieses Backbone genau dann, wenn sie beide in mindestens einer dieser Teilmengen enthalten sind.

Bei diesen Teilmengen handelt es sich um Virtual Private Networks (VPNs). Zwei Standorte haben nur dann IP-Konnektivität über das gemeinsame Backbone, wenn es ein VPN gibt, das beide Standorte enthält. Zwei Standorte, die kein gemeinsames VPN haben, haben keine Konnektivität über dieses Backbone.

Wenn alle Standorte in einem VPN demselben Unternehmen gehören, kann das VPN als "Intranet" des Unternehmens betrachtet werden. Gehören die verschiedenen Standorte in einem VPN verschiedenen Unternehmen, kann das VPN als "Extranet" betrachtet werden. Ein Standort kann in mehr als einem VPN sein; z. B. in einem Intranet und mehreren Extranets. Im Allgemeinen werden wir bei der Verwendung des Begriffs "VPN" nicht zwischen Intranets und Extranets unterscheiden.

Wir bezeichnen den Eigentümer der Standorte als "Kunden". Den Eigentümer/Betreiber des Backbones bezeichnen wir als "Dienstanbieter" (Service Provider, SP). Der Kunde bezieht "VPN-Service" vom SP.

Der Kunde kann ein einzelnes Unternehmen, eine Gruppe von Unternehmen, ein Internetdienstanbieter, ein Anwendungsdienstanbieter, ein anderer SP, der seinen eigenen Kunden dieselbe Art von VPN-Service anbietet, usw. sein.

Die Richtlinien, die bestimmen, ob eine bestimmte Sammlung von Standorten ein VPN ist, sind die Richtlinien des Kunden. Einige Kunden möchten, dass der SP vollständig für die Umsetzung dieser Richtlinien verantwortlich ist. Andere Kunden möchten die Verantwortung für die Umsetzung dieser Richtlinien möglicherweise mit dem SP teilen. Dieses Dokument spezifiziert Mechanismen, die zur Umsetzung dieser Richtlinien verwendet werden können. Die von uns beschriebenen Mechanismen sind allgemein genug, um die Umsetzung dieser Richtlinien entweder durch den SP allein oder gemeinsam durch den VPN-Kunden und den SP zu ermöglichen. Der Großteil der Diskussion konzentriert sich jedoch auf den erstgenannten Fall.

Die in diesem Dokument beschriebenen Mechanismen ermöglichen die Umsetzung einer Vielzahl von Richtlinien. Beispielsweise kann innerhalb eines gegebenen VPN jedem Standort erlaubt werden, eine direkte Route zu jedem anderen Standort zu haben ("Full Mesh"). Alternativ kann erzwungen werden, dass der Verkehr zwischen bestimmten Paaren von Standorten über einen dritten Standort geleitet wird. Dies kann beispielsweise nützlich sein, wenn der Verkehr zwischen einem Paar von Standorten eine Firewall durchlaufen soll und sich die Firewall am dritten Standort befindet.

In diesem Dokument beschränken wir die Diskussion auf den Fall, dass der Kunde explizit VPN-Service von einem SP oder einer Gruppe von SPs kauft, die vereinbart haben, bei der Bereitstellung des VPN-Services zusammenzuarbeiten. Das heißt, der Kunde kauft nicht nur Internetzugang von einem SP, und der VPN-Verkehr passiert nicht eine beliebige Sammlung miteinander verbundener SP-Netzwerke.

Wir beschränken die Diskussion auch auf den Fall, dass das Backbone dem Kunden einen IP-Dienst bereitstellt, anstatt einen Layer-2-Dienst wie Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet, High Level Data Link Control (HDLC) oder Point-to-Point Protocol (PPP) bereitzustellen. Der Kunde kann sich über einen dieser Layer-2-Dienste (oder andere) mit dem Backbone verbinden, aber der Layer-2-Dienst endet am "Rand" des Backbones, wo die IP-Datagramme des Kunden aus jeder Layer-2-Kapselung entfernt werden.

Im Rest dieser Einleitung spezifizieren wir einige Eigenschaften, die VPNs besitzen sollten. Der Rest des Dokuments spezifiziert eine Reihe von Mechanismen, die eingesetzt werden können, um ein VPN-Modell bereitzustellen, das alle diese Eigenschaften besitzt. Dieser Abschnitt führt auch einige technische Begriffe ein, die im Rest des Dokuments verwendet werden.

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

Router können auf verschiedene Weise miteinander oder mit Endsystemen verbunden sein: PPP-Verbindungen, ATM Virtual Circuits (VCs), Frame Relay VCs, Ethernet-Schnittstellen, Virtual Local Area Networks (VLANs) auf Ethernet-Schnittstellen, GRE-Tunnel, Layer 2 Tunneling Protocol (L2TP)-Tunnel, IPsec-Tunnel usw. Wir verwenden den Begriff "Anschlussleitung" (Attachment Circuit), um jede Art der Anbindung an einen Router zu bezeichnen. Eine Anschlussleitung kann die Art von Verbindung sein, die normalerweise als "Data Link" betrachtet wird, oder es kann sich um einen Tunnel jeglicher Art handeln; was zählt, ist, dass zwei Geräte über die Anschlussleitung Netzwerk-Layer-Peers sein können.

Jeder VPN-Standort muss ein oder mehrere Customer Edge (CE)-Geräte enthalten. Jedes CE-Gerät ist über eine Art von Anschlussleitung mit einem oder mehreren Provider Edge (PE)-Routern verbunden.

Router im SP-Netzwerk, die nicht mit CE-Geräten verbunden sind, werden als "P-Router" bezeichnet.

Die CE-Geräte können Hosts oder Router sein. Im typischen Fall enthält ein Standort einen oder mehrere Router, von denen einige an PE-Router angeschlossen sind. Die Router des Standorts, die sich mit den PE-Routern verbinden, sind die CE-Geräte oder "CE-Router". Nichts hindert jedoch einen Nicht-Router-Host daran, sich direkt mit einem PE-Router zu verbinden. In diesem Fall ist dieser Host ein CE-Gerät.

Manchmal ist das, was physisch an einen PE-Router angeschlossen ist, ein Layer-2-Switch. In diesem Fall sagen wir nicht, dass der Layer-2-Switch ein CE-Gerät ist. Vielmehr sind die CE-Geräte die Hosts und Router, die über den Layer-2-Switch mit dem PE-Router kommunizieren; die Layer-2-Infrastruktur ist transparent. Wenn die Layer-2-Infrastruktur einen Mehrpunktdienst bietet, können mehrere CE-Geräte über dieselbe Anschlussleitung an den PE-Router angeschlossen sein.

Die CE-Geräte sind logisch Teil des VPNs des Kunden. Die PE- und P-Router sind logisch Teil des SP-Netzwerks.

Die Anschlussleitung, über die ein Paket auf seinem Weg vom CE zum PE reist, wird als "eingehende Anschlussleitung" dieses Pakets bezeichnet, und dieser PE wird als "Eingangs-PE" des Pakets bezeichnet. Die Anschlussleitung, über die ein Paket auf seinem Weg vom PE zum CE reist, wird als "ausgehende Anschlussleitung" dieses Pakets bezeichnet, und dieser PE wird als "Ausgangs-PE" des Pakets bezeichnet.

Wenn ein PE-Router an ein CE-Gerät angeschlossen ist, das zu einem bestimmten VPN-Standort gehört, sagen wir, dass der PE-Router an dieses VPN angeschlossen ist. Ähnlich sagen wir, wenn ein PE-Router an ein CE-Gerät angeschlossen ist, das zu einem bestimmten Standort gehört, dass der PE-Router an diesen Standort angeschlossen ist.

Wenn das CE-Gerät ein Router ist, ist es ein Routing-Peer des PE, an den es angeschlossen ist, aber es ist kein Routing-Peer von CE-Routern an anderen Standorten. Router an verschiedenen Standorten tauschen Routing-Informationen nicht direkt miteinander aus; tatsächlich müssen sie einander nicht einmal kennen. Somit hat der Kunde kein Backbone oder "virtuelles Backbone" zu verwalten und muss sich nicht mit Inter-Site-Routing-Problemen befassen. Mit anderen Worten, im in diesem Dokument beschriebenen Schema ist ein VPN kein "Overlay" über dem SP-Netzwerk.

Im Hinblick auf die Verwaltung der Edge-Geräte wird eine klare Verwaltungsgrenze zwischen dem SP und seinem Kunden aufrechterhalten. Der Kunde benötigt keinen Zugriff auf die PE- oder P-Router zu Verwaltungszwecken, und der SP benötigt keinen Zugriff auf die CE-Geräte zu Verwaltungszwecken.

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

Wenn zwei VPNs keine gemeinsamen Standorte haben, können sie überlappende Adressräume haben. Das heißt, eine bestimmte Adresse kann im VPN V1 als Adresse von System S1 verwendet werden, aber im VPN V2 als Adresse eines völlig anderen Systems S2. Dies ist eine häufige Situation, wenn jedes VPN den privaten Adressraum RFC 1918 verwendet. Natürlich muss innerhalb jedes VPNs jede Adresse eindeutig sein.

Sogar zwei VPNs, die gemeinsame Standorte haben, können überlappende Adressräume haben, solange keine Notwendigkeit besteht, dass Systeme mit solchen Adressen mit Systemen in den gemeinsamen Standorten kommunizieren.

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

Obwohl ein Standort in mehr als einem VPN sein kann, ist es nicht erforderlich, dass die Route zu einem bestimmten System an diesem Standort in allen VPNs dieselbe ist. Angenommen, wir haben ein Intranet bestehend aus den Standorten A, B und C, und ein Extranet bestehend aus A, B, C und einem "externen" Standort D. Angenommen, es gibt einen Server am Standort A, den wir für Clients von B, C oder D zugänglich machen möchten. Angenommen, es gibt auch eine Firewall am Standort B. Wir möchten, dass der gesamte Verkehr von D zum Server die Firewall passiert, damit eine Zugangskontrolle für den Extranet-Verkehr erzwungen werden kann. Wir möchten jedoch nicht, dass der Verkehr von C auf dem Weg zum Server die Firewall passiert, da es sich um Intranet-Verkehr handelt.

Es können zwei Routen zum Server eingerichtet werden. Eine Route wird von den Standorten B und C verwendet und führt den Verkehr direkt zum Standort A. Die zweite Route wird vom Standort D verwendet und führt den Verkehr zur Firewall am Standort B. Wenn die Firewall den Verkehr passieren lässt, sieht er dann wie Verkehr aus, der vom Standort B kommt, und folgt der Route zum Standort A.

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

Das SP-Backbone besteht aus den PE-Routern sowie anderen Routern ("P-Routern"), die nicht an CE-Geräte angeschlossen sind.

Wenn jeder Router im SP-Backbone Routing-Informationen für alle vom SP unterstützten VPNs unterhalten müsste, gäbe es gravierende Skalierbarkeitsprobleme; die Anzahl der unterstützbaren Standorte wäre durch die Menge an Routing-Informationen begrenzt, die ein einzelner Router halten könnte. Daher ist es wichtig, dass Routing-Informationen über ein bestimmtes VPN nur in den PE-Routern vorhanden sein müssen, die an dieses VPN angeschlossen sind. Insbesondere P-Router sollten überhaupt keine VPN-spezifischen Routing-Informationen benötigen. (Bei der Betrachtung von Multicast-Routing muss diese Bedingung möglicherweise leicht gelockert werden. Dies wird hier nicht weiter diskutiert, wird aber in [VPN-MCAST] untersucht.)

Genauso wie die VPN-Eigentümer kein Backbone oder "virtuelles Backbone" zu verwalten haben, verwaltet der SP selbst kein separates Backbone oder "virtuelles Backbone" für jedes VPN. Das Inter-Site-Routing im Backbone ist optimal (innerhalb der Einschränkungen der Richtlinien, die zur Bildung der VPNs verwendet werden) und wird nicht durch eine künstliche "virtuelle Topologie" von Tunneln eingeschränkt.

Abschnitt 10 diskutiert einige spezielle Probleme, die auftreten, wenn sich das Backbone über mehrere Dienstanbieter erstreckt.

1.6. Security (Sicherheit)

VPNs dieser Art, wie hier diskutiert, sollen ein Sicherheitsniveau bieten, das dem entspricht, das bei Verwendung eines Layer-2-Backbones (z. B. Frame Relay) erreicht werden kann, selbst wenn keine kryptografischen Sicherheitsmaßnahmen verwendet werden. Das heißt, in Ermangelung einer Fehlkonfiguration oder einer absichtlichen Verbindung verschiedener VPNs ist es für ein System in einem VPN unmöglich, Zugang zu einem System in einem anderen VPN zu erhalten. Natürlich verschlüsseln die hier beschriebenen Methoden die Daten nicht für die Vertraulichkeit und bieten auch keine Möglichkeit festzustellen, ob die Daten während der Übertragung verändert wurden. Wenn diese Funktionen gewünscht werden, müssen zusätzlich kryptografische Maßnahmen angewendet werden (siehe z. B. [MPLS/BGP-IPsec]). Sicherheit wird in Abschnitt 13 ausführlicher diskutiert.