VPN Virtuelle Private Netzwerke

Transkript

1 Manfred Lipp VPN Virtuelle Private Netzwerke Aufbau und Sicherheit ADDISON-WESLEY An imprint of Pearson Education München Boston San Francisco Harlow, England Don Mills, Ontario Sydney Mexico City Madrid Amsterdam

2 Tunneling Tunneling ist die Basis praktisch aller VPNs. Mit Hilfe dieser Technologie kann man Pakete eines Netzwerkprotokolls in Pakete eines anderen Netzwerkprotokolls einkapseln und über dieses Netzwerk übertragen. Auf diese Weise kann man zum Beispiel X- Pakete durch ein -Netzwerk transportieren. Eine andere, speziell für -Netze interessante Anwendung ist das Verstecken von privaten, nicht registrierten Netzwerk- und Hostadressen, indem man in tunnelt. Auf diese Weise kann man seine privaten Netze über das Internet miteinander verbinden. Man kapselt hierzu die -Pakete mit privaten Adressen in Pakete mit offiziell registrierten -Adressen ein und transportiert diese durch das Internet zur Gegenstelle, welche die originalen Pakete wieder auspackt. Übertragungsstrecke Tunnel- Endpunkt Tunneling-Protokoll Tunnel- Endpunkt L-3 Encapsulation L-3 Protocol L-3 Decapsulation L-3 Abbildung 3.1: Das Prinzip aller Tunneling-Protokolle Es gibt eine ganze Reihe von Tunneling-Protokollen, von denen jedoch drei eine besondere Rolle spielen: das Layer 2 Tunneling Protocol (L2TP), das -Security Protocol (Sec) im Tunnel-Modus und Multi Protocol Label Switching (MPLS). Diese drei Protokolle sind standardisiert, und sie verdrängen zunehmend alle anderen Tunneling-Protokolle in Neuinstallationen. SSL, obwohl immer öfter in VPN eingesetzt, ist kein Tunneling-Protokoll. Hier müssen zu SSL externe Komponenten die Einkapselung von UDP-, TCP- oder -Paketen vornehmen. In Abbildung 3.1 ist das Prinzip des Tunnelings veranschaulicht. Die Netzwerkpakete (Layer 3) werden in andere Netzwerkpakete mit einem neuen Layer-3- eingekapselt (Encapsulation), und es wird ein Tunnel- eingefügt. An diesem, der zwischen dem neuen Layer-3- und der Nutzlast angeordnet sein muss, erkennt der Empfänger, dass es sich um ein Paket des betreffenden Tunneling-Protokolls handelt. Er wertet den aus, entpackt das originale Paket (Decapsulation) und transportiert es weiter. Zwischen dem Sender und dem Empfänger, den so genannten Tunnelendpunkten, die durch die Netzwerkadressen des neuen Layer-3-s festgelegt sind, besteht eine Tunnelverbindung.

3 In manchen Fällen ist es nicht notwendig, im -Protokoll einen speziellen Tunnel- einzufügen, denn gemäß dem Standard benutzt man das Protokollfeld des -s, um anzuzeigen, welches Protokoll auf den folgt. Üblicherweise ist dies TCP (mit Protokollnummer 6) oder UDP (mit Protokollnummer 17). Wenn jedoch die Nummer 4 () in diesem Feld enthalten ist, weiß die Gegenstelle, dass ein -Paket folgt, also ein vollständiges Paket eingekapselt wurde. Auf diese Weise kann man -in--tunneling extrem effizient ohne einen zusätzlichen verwenden. Die Tunnelendpunkte können in der Regel sowohl normalen Netzwerkverkehr als auch Tunnelpakete verarbeiten. Wie ein Paket zu behandeln ist, erkennt der Empfänger am Tunnel- oder an der -Protokollnummer. Der Sender nimmt eine Einkapselung aufgrund der Verarbeitungsstrategie einer höheren Protokollschicht vor. Dabei kann es sich um eine Sicherheitsstrategie handeln oder um interne Tabellen mit Kennzeichnungen, aus denen hervorgeht, welche Pakete normal zu transportieren sind und welche getunnelt werden müssen. Es gibt allerdings eine Ausnahme: Security-Gateways werden aus Sicherheitsgründen manchmal so konfiguriert, dass sie ausschließlich Tunneling- Protokolle terminieren und keine anderen Protokolle wie zum Beispiel SNMP, FTP usw. 3.1 Tunneling-Modelle In Abhängigkeit davon, wo die Tunnel beginnen und enden, kann man drei verschiedene, so genannte Tunneling-Modelle unterscheiden: das Ende-zu-Ende-Modell, das Provider-Enterprise-Modell und das Intra-Provider-Modell. In Abbildung 3.2 sehen Sie die drei Modelle im Vergleich Das Intra-Provider-Modell Das Intra-Provider-Modell zeichnet sich dadurch aus, dass die Tunnel bei den Service Providern beginnen und enden. Gegenüber den beiden anderen Modellen hat diese Variante einen entscheidenden Vorteil: Auf der Seite des n muss keine spezielle Hardoder Software installiert werden, er kann seine vorhandenen Systeme weiter benutzen und ist nicht in das Tunneling involviert. Die notwendigen Gateways werden von den Providern betrieben und stehen normalerweise auch in deren Räumen. Dieses Modell wird vorwiegend für Remote-Access-VPN verwendet, kann jedoch auch für Branch- Office-VPN eingesetzt werden. Das in einem der folgenden Abschnitte beschriebene MPLS ist ein typischer Vertreter dieser Kategorie und wird sehr oft zur Verbindung verschiedener Standorte eingesetzt Das Provider-Enterprise-Modell Beim Provider-Enterprise-Modell sind sowohl die Service Provider als auch die Endkunden in das Tunneling involviert. Die Tunnel beginnen im POP (Point of Presence) des Service Providers und enden im Gateway des n. Dieses Modell wird primär für Remote-Access-VPN eingesetzt, kann aber auch in Branch-Office-VPN Verwendung finden. In diesem Modell muss der eine spezielle Hard- oder Software als VPN- Gateway einsetzen. Die Client-Software kann ein beliebiges Einwählprogramm (Microsoft DFÜ-Netzwerk usw.) sein, da der Tunnel erst im POP des Providers beginnt.

4 Client POP Gateway ISDN Internet PSTN Carrier Service Provider Carrier Intra-Provider- Modell Provider-Enterprise- Modell Ende-zu-Ende-Modell Abbildung 3.2: Die drei grundsätzlichen Tunneling-Modelle Das Ende-zu-Ende-Modell Im Ende-zu-Ende-Modell werden die Tunnel ausschließlich vom n aufgebaut. Die Carrier und/oder Service Provider sind dabei gar nicht in das Tunneling involviert. Sie transportieren im Fall von -VPN ausschließlich -Pakete. Dass in diesen Paketen andere Pakete eingekapselt sind, können sie zwar erkennen (wenn sie das wollen), aber es hat keinen Einfluss auf den Transport der -Pakete. Applikation Applikation Applikations- Pakete Applikations- Pakete TCP SPX TCP SPX X X Applikations- Pakete L2TP- L2TP- Applikations- Pakete TCP SPX UDP UDP TCP SPX X X Layer-2 Layer-2 Layer-1 Layer-1 Übertragungsmedium Abbildung 3.3: Das Prinzip des Layer-2-Tunnelings, in dem Pakete der Schicht 2 eingekapselt werden

5 Üblicherweise stehen die Gateways zum Netzwerk eines Providers in den Räumen der Endkunden, sind deren Eigentum und werden auch von ihnen betrieben. Jedoch kann dieses Modell auch als so genannter Carrier Managed Service von einem Service Provider oder Carrier betrieben werden. Die Remote-Access-Clients wählen sich in die POPs der Service Provider ein, und eine spezielle VPN-Clientsoftware im Endgerät des n baut daraufhin einen Tunnel zu einem VPN-Gateway im nnetzwerk auf. Theoretisch kann man fast alle Tunneling-Protokolle in einem Ende-zu-Ende-Modell einsetzen, jedoch sind einige Protokolle besser dafür geeignet als andere. Im Ende-zu-Ende- Modell setzt man vorwiegend Sec im Tunnel-Modus und mittlerweile nur noch ganz selten das Point-to-Point Tunneling Protocol (PPTP) ein. Speziell in Microsoft-Umgebungen findet zunehmend das Layer 2 Tunneling Protocol (L2TP) in Verbindung mit Sec- Transport Verwendung. 3.2 Standardisierte Tunneling-Protokolle Man kann die Tunneling-Protokolle in drei verschiedene Klassen einteilen: die Layer-2- Tunneling-Protokolle, Layer-3-Tunneling-Protokolle und, etwas scherzhaft formuliert, Layer-2,5-Tunneling-Protokolle. Die Unterscheidung basiert auf der Schicht des OSIoder -Schichten-Modells, deren Pakete eingekapselt werden. Layer-2-Protokolle kapseln Pakete der Sicherungsschicht (Layer 2) in andere Pakete, meist solche der Schicht 3, ein. Layer-3-Protokolle kapseln Pakete der Netzwerkschicht (Layer 3) in andere Pakete der Netzwerkschicht ein. Eine Sonderform ist MPLS, das eine spezielle Zwischenschicht (den Layer Zweieinhalb, im Fachjargon Label genannt) zwischen Layer 2 und Layer 3 einfügt, um hiermit verschiedene virtuelle Pfade zu realisieren Layer-2-Protokolle In Abbildung 3.3 sehen Sie die Funktionsweise des Layer-2-Tunnelings. In diesem Beispiel werden -Rahmen (, Point-to-Point Protocol, ein Protokoll, um verschiedene Netzwerkprotokolle über eine Punkt-zu-Punkt-Verbindung zu transportieren) in - Pakete eingekapselt. In den -Rahmen können Pakete verschiedener anderer Netzwerkprotokolle wie, X, Vines-, NetBEUI usw. enthalten sein. In unserem Beispiel tunnelt das Layer 2 Tunneling Protocol (L2TP) und X. Beim Tunneling entsteht ein gewisser Overhead, denn außer dem L2TP- werden zusätzliche UDP-, - und - erzeugt. Bei großer Nutzdatenlänge fällt dieser Anteil allerdings nicht so sehr ins Gewicht. Der Vorteil von Layer-2-Tunneling-Protokollen ist der, dass eine Vielzahl von Netzwerkprotokollen getunnelt werden kann, ohne dass sich das Tunneling selbst darum kümmern muss, da dies bereits auf der -Ebene erfolgt ist.

6 Client ISDN PSTN L2TP- LAC Internet L2TP- LNS Carrier Service Provider Carrier L2TP-Tunnel L2TP UDP Abbildung 3.4: L2TP im Compulsary Mode (zwangsweises Tunneln), in dem vom Provider generell ein Tunnel zum nnetz aufgebaut wird Layer 2 Tunneling Protocol (L2TP) Das Layer 2 Tunneling Protocol, L2TP, wurde primär für den Einsatz im Provider-Enterprise-Modell entwickelt. Wie Sie in Abbildung 3.4 sehen, beginnt dabei der L2TP-Tunnel im Remote Access Concentrator (RAC) des Service Providers und endet in einem Gateway beim n. L2TP- LAC ISDN PSTN POP Internet L2TP- LNS Carrier Service Provider Carrier L2TP-Tunnel L2TP UDP Abbildung 3.5: L2TP im Voluntary Mode (freiwilliges Tunneln), in dem der Client entscheidet, ob ein Tunnel aufgebaut werden muss

7 Die Funktionalität der Tunnelendpunkte ist rollenbasierend, der Tunnel wird von einem LAC (L2TP Access Concentrator) aufgebaut, der im RAC des Providers implementiert ist. Das entgegengesetzte Ende des Tunnels bildet der LNS, der L2TP Network Server, der entweder auf Routern oder auf speziellen VPN-Gateways implementiert ist. Der RAC des Service Providers erkennt an bestimmten Kennzeichen eines eingehenden Rufs (angerufene Nummer, Benutzer-ID usw.), ob es sich um eine Verbindung in das Netzwerk des Providers handelt oder ob die Verbindung zu einem Endkunden getunnelt werden soll. Dieses Verhalten nennt man auch zwangsweises Tunneling (Compulsory Tunneling), da der Client nicht selbst entscheiden kann, ob ein Tunnel aufgebaut wird oder nicht. Im Provider-Enterprise-Modell muss das Equipment beim n eine L2TP-LNS-Funktionalität bieten. Das betreffende System muss aber nicht notwendigerweise dem n gehören und muss auch nicht von ihm verwaltet werden oft bieten die Service Provider komplette Lösungen an, inklusive VPN-Systemen, Konfiguration, Wartung und Betrieb. Leider sind in L2TP keinerlei Sicherheitsfunktionen wie verschlüsselung oder Paketauthentifizierung verfügbar. L2TP kann auch im Ende-zu-Ende-Modell eingesetzt werden. Zu diesem Zweck wird die LAC-Funktionalität vom Remote-Access-Konzentrator des Service Providers auf den Client verlagert. Dieser so genannte Virtual LAC auf dem Clientrechner baut den L2TP-Tunnel zum LNS auf, und die Carrier und Service Provider sind nicht mehr in das Tunneling involviert. Im Gegensatz zum zwangsweisen Tunneln nennt man dies freiwilliges Tunneln (Voluntary Tunneling). Ein Beispiel für eine solche Funktionalität finden Sie bei Windows 2000 Professional und Windows XP, das als VPN-Protokoll auch L2TP als virtuellen LAC implementiert hat. Das Layer 2 Tunneling Protocol ist aufgrund seiner wachsenden Bedeutung in Kapitel 8 ausführlich beschrieben. Applikation Applikation Applikations- Pakete Applikations- Pakete Applikations- Pakete TCP UDP TCP UDP Sec-AH- TCP UDP Sec-AH- Applikations- Pakete TCP UDP Layer-2 Layer-2 Layer-1 Layer-1 Übertragungsmedium Abbildung 3.6: Layer-3-Tunneling zeichnet sich dadurch aus, dass Pakete auf der Schicht 3 eingekapselt werden.

8 3.2.3 Layer-3-Protokolle Das Layer-3-Tunneling arbeitet eine Schicht höher als Layer-2-Protokolle. Hier werden Pakete der Netzwerkschicht in andere Pakete dieser Schicht eingekapselt, wie Sie in Abbildung 3.6 sehen. Der Paket-Overhead ist geringer als der von Layer-2-Protokollen. Allerdings muss der Tunneling-Prozess die von den höheren Schichten ankommenden Pakete analysieren und im Tunnel- vermerken, welche Art von Protokoll getunnelt wird. In dem Beispiel, das in Abbildung 3.6 zu sehen ist, wird Sec im Tunnel- Modus eingesetzt. Das gezeigte Sec-AH-Protokoll (vgl. Kapitel 7) fügt einen Sec- AH- ein. Andere Protokolle, zum Beispiel Sec-ESP, können neben dem auch einen Trailer in das zu erzeugende Paket einfügen Security (Sec) im Tunnel-Modus Sec im Tunnel-Modus dient meist als Basis für das Ende-zu-Ende-Modell. Alle beteiligten Systeme müssen mit einer entsprechenden Sec-Implementierung ausgerüstet sein. In Abbildung 3.7 sehen Sie am Beispiel eines Remote-Access-VPN die Funktionsweise. Die Sec-Tunnel beginnen und enden auf dem Endsystem des n, meist einem Rechner mit Sec-Client-Software und einem Sec-Gateway. Die Carrier und Service Provider sind nicht am Tunneling beteiligt und transportieren aus ihrer Sicht nur die -Pakete zwischen Client und Gateway. Das öffentliche Interface des Sec-Gateways hat eine feste, offiziell registrierte -Adresse. Auch der Client bekommt bei der Einwahl in den POP eines Service Providers eine offizielle -Adresse zugewiesen. Das private Interface des Gateways kann in einem nicht registrierten -Netzwerk liegen. Sec- Client ISDN PSTN POP Internet Sec- Gateway Carrier Service Provider Carrier Sec Tunnel Sec Sec Abbildung 3.7: Obwohl Tunneling nur eine seiner Optionen ist, ist Sec zum Inbegriff des Layer-3-Tunnelings geworden. Beim Client ist die Sache ein klein wenig komplexer. Er hat auch zwei -Adressen: zum einen die ihm vom Provider für die DFÜ-Verbindung (DFÜ, fernübertragung) zugewiesene, offizielle und zum anderen seine private -Adresse aus dem Adress-

9 bereich des nnetzes. Einige Sec-Implementierungen erfordern leider, dass der Client immer die gleiche offizielle -Adresse zugewiesen bekommt, wodurch diese damit faktisch zu einer statischen Adresse wird. Das ist den Internet Service Providern (ISP) ein Gräuel, da deren verfügbare Adressen immer mehr zur Neige gehen. Üblicherweise werden den Einwähl-Clients die -Adressen von den ISP dynamisch aus einem so genannten -Adress-Pool zugewiesen. Diese Pools haben in der Regel so viele Adressen, wie der Provider an gleichzeitigen physikalischen Verbindungen zur Verfügung stellen kann. Da sich aber nie alle n eines ISP gleichzeitig einwählen, haben die Provider ihre POPs in der Regel überbucht, sie haben also mehr n als Einwählports und damit auch weitaus weniger -Adressen als n. Falls nun pro Client eine feste -Adresse reserviert werden müsste, wären die Provider gezwungen, eine viel größere Anzahl von Adressen vorzuhalten, als wirklich zum Betrieb benötigt werden und das wird langsam zu einem Problem, da die Adressen für Version 4 weltweit immer knapper werden. Manche Provider sträuben sich daher gegen statische -Adressen für Remote-Access-Clients, oder sie verlangen entsprechende Gebühren, was dem eigentlichen Zweck eines VPN, Kosten zu senken, widerspräche. Also sollte bei der Auswahl der Sec-Client-Implementierung darauf geachtet werden, dass diese eine dynamische Zuweisung der offiziellen -Adressen unterstützt. Die private -Adresse kann bei guten Client-Implementierungen auch dynamisch durch den Tunnel vom Gateway zugewiesen werden. Hier ist vom Sec-Standard kein Verfahren festgeschrieben, es existieren lediglich standardisierte Funktionen, um herstellerspezifische Erweiterungen einzubinden. Manche Implementierungen unterstützen leider nur eine manuelle, statische Konfiguration der privaten Client--Adresse. Sec ist primär ein Sicherheitsprotokoll auf -Ebene; -Tunneling ist eine mögliche Option die allerdings in VPN fast immer eingesetzt wird. Die Sicherheitsfunktionen von Sec sind in Kapitel 5 ausführlich beschrieben. Die Einkapselung der privaten - Pakete Sec kann nur -Pakete tunneln erfolgt je nach Sicherheitsstufe durch einen Sec- oder einen Sec- und -Trailer. Ein Protokollfeld in den Sec- n gibt an, welches Protokoll im Sec-Paket eingekapselt ist. Dies sind im Tunnel- Modus ausschließlich -Pakete Multi Protocol Label Switching (MPLS) Obwohl nicht primär als Tunneling-Protokoll entwickelt, eignet sich MPLS hervorragend zum Aufbau von VPNs, und zwar von Layer-2-VPNs, da das Forwarding in einem MPLS-Netzwerk ausschließlich auf Schicht 2 und den dieser Ebene zugehörigen Tabellen stattfindet. 32 Bit Label Value CoS S Time to Live CoS = Class of Service S = Bottom of Stack Bit,1für den ersten (untersten) Label Abbildung 3.8: Der Namensgeber für MPLS, das Label

10 Multiprotokoll-Label-Switching (MPLS) ist genau genommen keine Technologie, mit der Endanwender bzw. Endkunden in direkte Berührung kommen. Aber aufgrund der Bedeutung im Carrier- und Service-Provider-Bereich und den Schnittstellen zu anderen Technologien (VPN, Ethernet over WAN, QoS usw.) ist an dieser Stelle eine kurze Beschreibung dieser Technologie durchaus sinnvoll. MPLS ist eine Technologie mit vielen Vätern, da sich in der Vergangenheit einige Unternehmen mit der exakt gleichen Zielsetzung, die auch MPLS zugrunde liegt, beschäftigt hatten und mit sehr ähnlichen Verfahren auf den Markt kamen natürlich ohne untereinander interoperabel zu sein. Diese Zielsetzung sah vor, eine möglichst optimale Verbindung von Routing und Switching zu erreichen und gleichzeitig Investitionen in bestehende Netze auf Basis von Frame Relay und ATM zu schützen. - MPLS-Label - Data - Trailer MAC- LLC- IEEE 802 MPLS-Label - Data MAC- Trailer ATM MPLS- Label VPI/VCI ATM - Data Frame Relay MPLS- Label DLCI Frame Relay - Data FR- Trailer Abbildung 3.9: Die MPLS-Labels können entweder zwischen Layer 2 und Layer 3 eingefügt werden, oder es werden verwandte Felder von Layer-2-Protokollen wie ATM oder Frame Relay benutzt. Die unterschiedlichen Ansätze von Routing und Switching werden in MPLS durch ein zweistufiges Konzept kombiniert, das folgende Eigenschaften aufweist: In MPLS werden Steuer- und Signalisierungsdaten ganz strikt von den Nutzdaten getrennt, man bezeichnet die beiden Bereiche als Forwarding- und Control-Komponente. Sie werden (fast) völlig unabhängig voneinander implementiert. So kann ein ATM-Switch, der ja bereits schon eine eigene Forwarding-Komponente besitzt, durch Hinzufügen der MPLS-Control-Funktionalität zu einem MPLS-Router werden. Der Weg durch ein Netzwerk wird nach wie vor durch klassisches Routing bestimmt. Zusätzlich sind weitreichende Möglichkeiten für Traffic Engineering gegeben. Signalisierungsprotokolle, an denen alle beteiligten Systeme teilnehmen, legen vorab fest, welchen Weg pakete nehmen, und konfigurieren diese Systeme hierfür.

11 Der Weg, den die pakete nehmen sollen, wird aufgrund lokaler Tabellen (LIB, Label Information Base) innerhalb der Systeme bestimmt. Dies kann sehr schnell geschehen und stellt somit praktisch die Switching-Komponente von MPLS dar. So genannte Labels, die in die Pakete beim Eintritt in ein MPLS-Netzwerk eingefügt und beim Verlassen wieder entfernt werden, dienen zur Forwarding-Entscheidung. VPN-A LER MPLS- Netzwerk LER VPN-B VPN-B LER LSR LSR LER VPN-A VPN-A LSR LSR VPN-B LER LER LSP-1 (VPN-A) LSP-2 (VPN-A) LSP-3 (VPN-B) LSP-4 (VPN-B) Abbildung 3.10: Ein typisches MPLS-VPN. Für den Endkunden ist MPLS meist nicht sichtbar, da es im Label Edge Router (LER) des Carriers beginnt. MPLS kann seine Labels auf verschiedene Art erzeugen und benutzen. So sind drei Varianten möglich, von denen insbesondere die beiden ersten heutzutage stark genutzt werden: Es wird ein eigener Protokoll- zwischen Schicht 2 und 3 erzeugt. Der Vorteil liegt hier in der Möglichkeit, mehr oder weniger unbegrenzt Labels ineinander verschachteln (Label Stacking) zu können. MPLS benutzt Felder von n verschiedener Layer-2-Protokolle, insbesondere Frame Relay oder ATM, da diese bereits den größten Teil der Netze von Carriern und Service Providern ausmachen. So kann in Frame Relay der DLCI und in ATM die VPI/ VCI-Kombination als MPLS-Label benutzt werden. Durch die limitierte Größe ist natürlich in diesem Fall das Label Stacking in seiner Verschachtelungstiefe eingeschränkt. Auch im Layer-3- können je nach Protokoll Labelinformationen eingetragen werden, so könnte man sich das Flow-Label-Feld des v6-protokolls durchaus für diesen Zweck vorstellen. Die Control-Komponente von MPLS erzeugt die Bindung der Labels an bestimmte Routen, Flüsse oder Multicast-Bäume. Auch die Verteilung der notwendigen Informationen an die jeweils beteiligten LSR fällt in den Funktionsumfang dieser Komponente und wird

12 über ein Label-Distribution-Protokoll (LDP) realisiert. Falls Routen über Protokolle wie OSPF oder BGP bestimmt werden, muss der LSR diese Protokolle verstehen und seine Label Information Base (LIB) mit Informationen aus deren Forwarding-Tabellen füllen. Label Edge Router (LER) -Adr - Label /16-30 Label Switch Router (LSR) In-Label -Out-Label Label Edge Router (LER) Label - Next Hop Initiales Label =30 Labelswap 30 -> 24 Label entfernen Applikationsdaten TCP UDP (Layer-3) Label (24) Layer-2 Layer-1 Applikationsdaten TCP UDP (Layer-3) Label (30) Layer-2 Layer-1 Applikationsdaten TCP UDP (Layer-3) Layer-2 Layer-1 Applikationsdaten TCP UDP (Layer-3) Layer-2 Layer-1 Abbildung 3.11: Das Austauschen der Labels MPLS-Systeme werden in zwei Kategorien eingeteilt, abhängig davon, an welcher Stelle eines MPLS-Netzwerks sie eingesetzt werden: Label Edge Router (LER) werden an den Grenzen von MPLS-Netzwerken eingesetzt. Sie versehen eingehende Pakete mit einem Label und entfernen Labels von ausgehenden Paketen. Sie können auch Prozesse zur Erzeugung eines Label Switched Path (LSP) einleiten, mit dem der Weg bestimmter Pakete durch ein MPLS-Netzwerk festgelegt wird. Label Switch Router (LSR) sind Systeme, die ankommende Pakete aufgrund existenter Label weiterleiten (Forwarding) und die Label dabei durch andere ersetzen (Label Switching). Die Tabellen, aufgrund derer dieses Forwarding und Label Switching durchgeführt wird, reflektieren die verschiedenen LSPs und müssen vorher durch geeignete Signalisierungsprotokolle festgelegt worden sein. Da in großen Netzen viele pakete eine identische Behandlung hinsichtlich ihres Weges durch das Netz oder ihrer Priorität erfahren sollen, hat man in MPLS ein wichtiges Konzept zur Verkehrsaggregation eingeführt, die so genannte Forwarding Equivalence Class (FEC). Aufgrund verschiedener Verkehrs- und Qualitätskennzeichen eingehender Pakete kann ein LER diese einer bestimmten FEC zuordnen, um damit zusammengehörende Pakete über einen einzigen LSP zu transportieren. Das Forwarding in einem LSR geschieht in der Regel ausschließlich aufgrund des Labels, höhere Protokolle werden nicht ausgewertet, auch nicht bei Routern, die gleichzeitig sowohl auf MPLS- als auch auf -Ebene arbeiten. Die Quality-of-Service-Thematik ist auch in MPLS ausreichend berücksichtigt worden. So erlaubt MPLS insbesondere auch die Konfiguration von Label-Bindungen, die nicht

13 mit dem zielbasierenden, z.b. durch Routing ermittelten, LSP übereinstimmen, beispielsweise um kritischen Verkehr durch breitbandige, verzögerungsfreie Verbindungen zu leiten. MPLS kann auch aufgrund von höheren Schichten Pakete klassifizieren, die drei Bits im Label mit dem Namen EXP (Experimentell, vgl. Abbildung 3.8) eignen sich zur Aufnahme von Class-of-Service-Informationen z.b. aus dem DSCP im -. Das oben erwähnte Konzept der FEC kann ebenfalls zur Aggregierung von Paketen der gleichen QoS-Klasse eingesetzt werden. Da in Carrier-Netzen teilweise andere Prämissen als in normalen nnetzen gelten, ist die Möglichkeit des Traffic Engineerings in MPLS sehr wichtig. Sie erlaubt dem Administrator, explizite Pfade festzulegen, um zum Beispiel QoS für bestimmte Klassen von Paketen zu garantieren oder Durchleitungsverträge mit anderen Providern umzusetzen, ohne mit dynamischem Routing in Konflikt zu kommen. MPLS ist eine reine Carrier- und Service-Provider-Technologie und wird auch von diesen zunehmend eingesetzt. Einzige Ausnahme sind sehr große Unternehmen mit großen, selbst betriebenen Netzen, also Firmen mit, hinsichtlich ihres Netzwerks, Carrier-ähnlichen Eigenschaften. Diese Unternehmen sind natürlich auch potenzielle MPLS-Anwender. An dieser Stelle ist es angebracht, ein paar Worte über die ziemlich sinnlose, weil falsche Diskussion zu verlieren, ob man besser Sec oder MPLS zum Aufbau von VPNs einsetzt. Da zeugt schon die Frage selbst von Inkompetenz, denn Sec ist ein Security-Protokoll, lediglich mit der Option versehen, über -in- Encapsulation (Layer-3-Tunnel) ein VPN aufzubauen. Sec als Ende-zu-Ende-Protokoll findet hauptsächlich im Enterprise-Bereich Anwendung. MPLS hingegen ist ein infrastruktur-unabhängiges Switching-Protokoll, mit dem man aufgrund seiner Funktionalität sehr flexibel Layer-2-VPNs aufbauen kann. MPLS ist eine Technologie, die praktisch ausschließlich von Carriern und Providern eingesetzt wird. Die Frage, wenn überhaupt, müsste richtig lauten: Soll man, wenn man MPLS einsetzt, zusätzlich noch Sec als Sicherheitsprotokoll verwenden oder nicht? Diese Frage ist aber nicht uninteressant, denn die meisten Unternehmen setzen ja selbst gar kein MPLS ein, sondern der Carrier, der seinen n ein damit aufgebautes VPN zur Verfügung stellt. Das hat aber noch nichts mit Sicherheit im eigentlichen Sinn (Vertraulichkeit, Integrität und Authentizität von ) zu tun, denn MPLS bietet hierfür keine Mittel, die muss der selbst oder sein Provider mittels zusätzlicher Dienste bereitstellen meist mit Sec. 3.3 Nichtstandardisierte Tunneling-Protokolle Neben den standardisierten Tunneling-Protokollen gibt es eine ganze Reihe anderer Protokolle, die jedoch niemals in Form eines verbindlichen Standards das Licht der Welt erblickt haben. Manche dieser Protokolle wurden zwar in Standardisierungsprozesse eingebracht, haben diese aber niemals vollständig durchlaufen oder existieren nur als informeller Standard. Das Point-to-Point Tunneling Protocol (PPTP) oder Layer 2 Forwarding (L2F) sind Beispiele hierfür. Andere Protokolle sind proprietär und werden nur innerhalb der Produktlinien bestimmter Hersteller verwendet, wie zum Beispiel der

14 Altavista Tunnel, der Bay Dial VPN Service (Bay-DVS) oder das Ascend Tunnel Management Protocol (ATMP). Manche dieser proprietären Protokolle schmücken sich zwar mit RFC-Nummern, allerdings sind diese nur informeller Natur und repräsentieren keinen verbindlichen Internetstandard Layer 2 Forwarding (L2F) Das Layer 2 Forwarding ist ein Layer-2-Tunneling-Protokoll, das hauptsächlich von der Firma Cisco zum Einsatz im Provider-Enterprise-Modell entwickelt wurde. Es gibt praktisch keine Client-Implementierungen, sondern nur Software-Module für Remote- Access-Konzentratoren und Router. L2F ist sehr eng mit L2TP verwandt, viele L2TP-Network-Server können auch als Endpunkt für einen L2F-Tunnel dienen. L2F bietet keine Sicherheitsdienste wie verschlüsselung oder starke Authentifizierung, kann aber, wie auch L2TP und PPTP, verschiedene Netzwerkprotokolle tunneln Point-to-Point Tunneling Protocol Das Point-to-Point Tunneling Protocol wurde von einer Reihe von Firmen entwickelt, die zu diesem Zweck das so genannte PPTP-Forum gründeten. Der Software-Riese Microsoft war, neben Unternehmen wie Ascend Communications, 3Com und anderen, maßgeblich an der Entwicklung beteiligt und hat seine PPTP-Client-Software in alle seine Betriebssysteme integriert bzw. für ältere Systeme wie Windows 95 Updates auf den Markt gebracht. PPTP kann sowohl als Basis für das Ende-zu-Ende-Modell dienen als auch durch Implementierungen in Remote-Access-Konzentratoren im Provider-Enterprise-Modell eingesetzt werden. PPTP hat einen dem L2TP ähnlichen Aufbau. Für den Steuerungskanal verwendet PPTP jedoch das TCP-Protokoll. Als Layer-2-Protokoll kapselt PPTP -Rahmen mit einem modifizierten GRE- ein. PPTP bietet auch einige Sicherheitsfunktionen wie verschlüsselung (MPPE, Microsoft Point-to-Point Encryption) und Benutzerauthentifizierung, die allerdings bei weitem nicht die Stärke von Sec aufweisen. Insbesondere die Ableitung des Schlüssels, mit dem die verschlüsselt werden, aus dem Benutzerkennwort war in der Vergangenheit Zielscheibe einiger erfolgreicher Angriffe. Der Schlüssel des eingesetzten RC4- Protokolls st zwar, je nach der Version von PPTP, entweder 40 oder 128 Bit lang aber er wird aus einem Hashwert des Benutzerpassworts erzeugt. Also muss ein Brute-Force- Angriff (vgl. Kapitel 4) nicht alle 240 oder 2128 möglichen Schlüssel testen, sondern braucht praktisch nur einen Wörterbuchangriff auf das Benutzerpasswort durchzuführen. Microsoft hat mit einem Update auf die erfolgreichen Angriffe reagiert und eine neue, sicherere Authentifizierung namens MS-CHAPv2 implementiert. Aus Kompatibilitätsgründen kann das neue Verfahren beim Verbindungsaufbau jedoch durch die alte Version ersetzt werden, was eine nicht unbeträchtliche Angriffsfläche bildet. In jedem Fall basiert die Sicherheit der Verschlüsselung in PPTP auf der Sicherheit des Benutzerpassworts und das ist vielen Anwendern ein zu hohes Sicherheitsrisiko. Viele gute Sicherheitsstrategien legen darüber hinaus auch gewisse Verfahren und Richtlinien zur Schlüsselerzeugung und -verwaltung fest, so dass der Einsatz von PPTP oft schon an dieser Hürde scheitert.

15 Auch Microsoft hat sich von seinem Problemprotokoll PPTP verabschiedet. Seit Windows 2000 werden verschiedene Tunneling-Protokolle nach wie vor auch noch PPTP angeboten, jedoch wird für neue Installationen die modernere und sicherere Variante L2TP/Sec (siehe Kapitel 8) empfohlen. In Provider-Enterprise-Modellen setzen die Service Provider zunehmend auf L2TP, so dass auch hier PPTP immer weiter verdrängt wird. Übertragungsstrecke Tunneling-Protokoll A Tunneling-Protokoll B L-3 L-3 L-3 L-3 L-3 L-3 A A A A L-3 L-3 L-3 L-3 B B L-3 L-3 Abbildung 3.12: Man kann auch Tunneling-Protokolle ineinander verschachteln. 3.4 Verschachtelte Tunneling-Protokolle Manchmal bietet ein Tunneling-Protokoll allein nicht alle Funktionen, auf die man großen Wert legt. Die in diesem Kapitel besprochenen Layer-2-Tunneling-Protokolle können verschiedene Netzwerkprotokolle wie, X usw. tunneln, zeichnen sich aber nicht gerade durch gute Sicherheitsfunktionen aus. Sec auf der anderen Seite hat hervorragende Sicherheitsfunktionen, kann aber nur tunneln. Was liegt also näher, als zwei verschiedene Tunneling-Protokolle miteinander zu kombinieren. Das kann man auch tun, indem man Tunnel ineinander verschachtelt. Wie dies prinzipiell funktioniert, sehen Sie in Abbildung Beim Verschachteln von Tunneln ist es wichtig, dass sich die Tunnel, wie Sie in der Abbildung sehen, nicht überlappen die Tunnel müssen vollständig ineinander enthalten sein. Man kann grundsätzlich sowohl Protokolle gleichen als auch verschiedenen Typs ineinander verschachteln. Tunneling-Protokoll A Tunneling-Protokoll B Übertragungsstrecke Abbildung 3.13: Das geht nicht, verschiedene Protokolle müssen sich immer vollständig umschließen.

16 Nehmen wir einmal als Beispiel aus der Praxis ein Remote-Access-VPN, um den Sinn und den Einsatz der Verschachtelung von Tunneling-Protokollen zu erläutern. Sec ist ein Sicherheitsprotokoll, das man gern im Ende-zu-Ende-Modell einsetzt, um die gewünschte Sicherheitsfunktionalität möglichst auf der ganzen Übertragungsstrecke zwischen Client und VPN-Gateway zur Verfügung zu haben. Dabei gibt es aber möglicherweise ein Problem: Das Ende-zu-Ende-Modell bedeutet immer, dass der Client freiwillig tunnelt. Ein Benutzer könnte somit aber auf seinem Firmen-PC seinen Dialer manuell starten und sich zum ISP verbinden, ohne seinen Sec-Client zu benutzen. Das kann unter Umständen von einer Sicherheitsstrategie verboten sein. Mit dem Provider-Enterprise-Modell, zum Beispiel mit L2TP als Tunneling-Protokoll, wäre das nicht möglich, denn hier erfolgt ein zwangsweises Tunneling. Der Remote- Access-Konzentrator beim Service Provider kann z.b. aufgrund der angerufenen Nummer (also der Einwahlnummer des ISP, die der Dialer anrufen muss) entscheiden, ob und wohin ein Tunnel aufgebaut werden muss. Der Client kann dies nicht mehr beeinflussen. Allerdings ist L2TP kein Sicherheitsprotokoll. Die Lösung ist eine Verschachtelung von Sec und L2TP. In Abbildung Abbildung 3.14 sehen Sie, wie dies realisiert wird: Sec wird im Ende-zu-Ende-Modell betrieben und garantiert so die geforderte Sicherheit. Mit L2TP im Provider-Enterprise-Modell wird garantiert, dass, sobald sich der Client beim Provider einwählt, er zwangsweise mit L2TP bis zum LNS im nnetzwerk getunnelt wird. Diese Lösung hat allerdings auch ihren Preis in Form eines zusätzlichen Protokoll-Overheads in den paketen. Sec- Client ISDN PSTN L2TP- LAC Internet L2TP- LNS Sec- Gateway Carrier Service Provider Carrier Sec-Tunnel L2TP-Tunnel Sec Sec L2TP UDP Sec Abbildung 3.14: Eine Verschachtelung von L2TP und Sec

17 Im Zusammenhang mit verschachtelten Tunneling-Protokollen fällt fälschlicherweise auch oft der Begriff L2TP über Sec oder Sec secured L2TP oder kurz L2TP/ Sec. Hierbei handelt es sich jedoch nicht um eine Verschachtelung von Tunneling-Protokollen, da Sec hierbei nicht im Tunnel-, sondern im Transport-Modus arbeitet. Hier hat man die Vielfalt der Protokolle, die L2TP tunneln kann, mit der Sicherheit von Sec kombiniert. L2TP wird dabei zum Tunneln benutzt, und die erzeugten UDP/-Pakete werden mit Sec im Transport-Modus verschlüsselt und authentifiziert. Diese Kombination ist in Kapitel 8 ausführlich beschrieben. Sie wird auch seit Windows 2000 von Microsoft unterstützt. 3.5 Welches Protokoll für welchen Zweck? Diese Frage ist eigentlich gar nicht so kompliziert, da verschiedene Protokolle für bestimmte Funktionen von vornherein ausscheiden. Wenn Sie zum Beispiel X über ein -Netzwerk transportieren müssen, scheidet Sec an diesem Punkt bereits aus. Die Gegenüberstellung im folgenden Abschnitt soll die Protokolle nicht wertend miteinander vergleichen, denn sie wurden teilweise mit völlig unterschiedlichen Zielsetzungen und Einsatzszenarien entwickelt. In Tabelle 3.1 sind die vier wichtigsten Tunneling-Protokolle Sec, L2TP, PPTP und MPLS gegenübergestellt. Hier soll aber wie gesagt kein Vergleich im Sinne von gut oder schlecht stattfinden, sondern ein Vergleich der wichtigsten Funktionen der Protokolle. Hier können Sie anhand eines Pflichtenhefts oder Anforderungskatalogs schnell ein geeignetes Protokoll finden oder eine Kombination von zwei Protokollen. Sec L2TP PPTP MPLS Ja Ja Nein Ja Paketauthentifizierung Ja Nein Nein Nein Benutzerauthentifizierung Ja Ja Ja Nein verschlüsselung Ja Nein Ja Nein Schlüsselmanagement Ja Nein Nein Nein QoS-Signalisierung Ja Nein Nein Ja -Tunneling Ja Ja Ja Ja X-Tunneling Nein Ja Ja Ja Primäres Modell Ende-zu-Ende Provider- Enterprise Ende-zu-Ende Intra- Provider Tabelle 3.1: Die wichtigsten Tunneling-Protokolle im Vergleich. Die Anzahl der Ja oder Nein ist keine Wertung, da die Protokolle sehr unterschiedliche Ausrichtungen haben.

18 Mit der Auswahl eines oder mehrerer Tunneling-Protokolle treffen Sie eine wichtige Entscheidung während der Planung des VPN. In heutigen, modernen Netzwerken ist man bestrebt, möglichst auf Standards oder wenigstens auf De-facto-Standards zu setzen. Aus diesem Grund reduziert sich die Menge der zur Auswahl stehenden Tunneling-Protokolle ganz erheblich: Es bleiben die in Tabelle 3.1 beschriebenen Verfahren, aus denen man ein geeignetes Protokoll auswählen sollte. Leider gibt es dafür keine allgemein gültige Checkliste oder eine Art VPN-Kochbuch, denn es spielen einfach zu viele unternehmensspezifische Planungs- und Entscheidungskriterien eine Rolle. Es kann sich durchaus auch als sinnvoll zu erweisen, mehrere Protokolle miteinander zu kombinieren. So kann es sich einerseits aus Sicht der Infrastruktur durchaus als sinnvoll erweisen, von einem Provider oder Carrier seine Standorte per MPLS-VPN verbinden zu lassen, andererseits erfordern gesetzliche Vorgaben oder bestimmte Sicherheitsvorgaben die Verschlüsselung und Integritätssicherung der durch Sec. Die wichtigsten Faktoren zur Auswahl sind: Die Netzwerkprotokolle, die übertragen werden müssen Die Sicherheitsstrategie des Unternehmens Die eingesetzten Applikationen Benötigte Client-Unterstützung (Betriebssysteme) Der VPN-Typ Kompatibilitätsanforderungen Netzwerkprotokolle Dieser Faktor ist neben der Sicherheitsstrategie der am meisten ausschlaggebende. Unter Umständen sollten Sie auch Ihre mittel- und langfristige Netzwerkstrategie zurate ziehen, ob nicht vielleicht eine Protokollkonsolidierung stattfinden soll und nur noch übrig bleibt. Diese Tendenz ist im Augenblick bei fast allen Unternehmen zu beobachten; bei etlichen ist dieser Prozess auch schon abgeschlossen. Ein VPN ist in diesem Zusammenhang möglicherweise ein guter Punkt, um mit dieser Konsolidierung zu beginnen und nur noch zu tunneln. Jetzt werden Sie vielleicht einwenden, dass diese Überlegung nichts gebracht hat, denn alle vier Protokolle tunneln. Das ist richtig, aber es bleiben mehr Alternativen, um die nachfolgenden Kriterien erfüllen zu können. Sicherheitsstrategie Die Netzwerkabteilung eines Unternehmens ist in der Regel dafür verantwortlich, die Sicherheitsstrategie des Unternehmens im Netzwerkbereich zu implementieren. Im Fall von Internet-VPN entstehen dadurch oft ganz bestimmte Anforderungen an die Sicherheitsdienste, die ein geeignetes Tunneling-Protokoll zur Verfügung stellen muss. An diesem Punkt scheiden schon Protokolle wie MPLS und L2TP aus, es sei denn, sie werden mit entsprechenden Sicherheitsprotokollen kombiniert. Wenn die Anforderungen an die Sicherheit der übertragung sehr hoch sind, bleibt praktisch keine Alternative zu Sec. Müssen unbedingt auch andere Netzwerkprotokolle als getunnelt werden, kann man im Clientbereich L2TP/Sec und im Bereich von Standortverbindungen MPLS mit Sec auf -Ebene verwenden.

19 Applikationen Hier ist nicht von Interesse, welche Applikationen benutzt werden, sondern welche Anforderungen an Verzögerungszeiten und Bandbreite sie stellen. Es ist auch von Interesse, ob im privaten Netzwerk bereits Quality-of-Service-Dienste auf -Ebene eingesetzt werden und ob diese Informationen an den Service Provider gesendet werden sollen. Hier spielt in gewissem Maße auch schon die Auswahl der VPN-Systeme mit hinein, auf die in Kapitel 11 näher eingegangen wird. Client-Unterstützung Wenn, zum Beispiel in einem Remote-Access-VPN, ein Ende-zu-Ende-Modell eingesetzt wird, müssen für das entsprechende Betriebssystem auch Client-Implementierungen des auszuwählenden Tunneling-Protokolls existieren. Dies dürfte für L2F schon das Aus sein; hier muss man sich zwischen den restlichen drei Protokollen entscheiden. VPN-Typ Natürlich ist es auch wichtig, welcher VPN-Typ zum Einsatz kommt, ob man also ein Remote-Access-, ein Branch-Office- oder ein Extranet-VPN aufbauen will oder beliebige Kombinationen davon. Die Tunneling-Protokolle haben ihre spezifischen Schwerpunkte und sind für bestimmte Einsatzszenarien nicht geeignet. So bieten nur ganz wenige Service Provider im Augenblick ein Provider-Enterprise-Modell mit zwangsweisem Tunneling mit Sec an. Und Branch-Office-VPNs mit L2F fallen auch unter die Rubrik exotisch. Und im Extranet-Bereich macht sich ohnehin ein Protokoll breit, das selbst gar kein Tunneling unterstützt: SSL. Kompatibilität Insbesondere wenn das VPN auch Extranet-Dienste zur Verfügung stellen muss, ist die Kompatibilität ein ganz wesentliches Entscheidungskriterium. Denn dann muss ein Tunneling-Protokoll eingesetzt werden, das die Organisationen, die angebunden werden sollen, auch benutzen. Natürlich muss nicht notwendigerweise nur ein einziges Tunneling- Protokoll im VPN eingesetzt werden. Falls man aus bestimmten Gründen zum Beispiel sein VPN mit PPTP aufbaut, die externen Extranet-Systeme aber Sec einsetzen, kann man für diesen genau abzugrenzenden Bereich auch Sec einsetzen. Falls die Forderung nach Kompatibilität jedoch einer grundsätzlichen Strategie des Unternehmens entspringt mit dem Ziel, eine möglichst hohe Interoperabilität und Herstellerunabhängigkeit zu erzielen, sollte man standardisierte Protokolle wie Sec oder L2TP einsetzen.