Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV

Prof. Dr. rer. nat. Otto Spaniol

Betreuung: Tim Seipold Lehrstuhl für Informatik IV, RWTH Aachen

Virtual Private Network (VPN)

Proseminar: Kommunikationsprotokolle 5

Dominik Schulte Matrikelnummer: 232503

Inhaltsverzeichnis: 1. Einleitung in die Thematik 1

1.1. Was ist ein VPN? 1 1.2. Begriffserläuterungen 2

2. VPN-Typen 3 2.1. Remote-Access-VPN 3 2.2. Branch-Office-VPN (Intranet) 3 2.3. Extranet-VPN 4 2.4. Tunneling-Modelle 5

2.4.1. Intra-Provider-Modell 5 2.4.2. Provider-Enterprise-Modell 5 2.4.3. Ende-zu-Ende-Modell 5

3. Anforderungen an VPNs 5 3.1. Sicherheit 6

3.1.1. Datenvertraulichkeit 6 3.1.2. Schlüsselmanagement 6 3.1.3. Authentifizierung 7 3.1.4. Integrität 7

3.2. Quality-of-Service (QoS) 8 3.2.1. Differentiated-Services (DiffServ) 8

4. VPN-Basistechnologien 9 4.1. Layer-2-Tunneling-Protokolle 10

4.1.1. Layer-2-Tunneling-Protocol (L2TP) 10 4.1.2. Point-to-Point-Tunneling-Protocol (PPTP) 15 4.1.3. Layer-2-Forwarding (L2F) 16

4.2. Layer-3-Tunneling-Protokolle 16 4.2.1. IP-Security (IPSec) 17

5. Zusammenfassung 24

___________________________________________________________________________ 1/24

1. Einleitung in die Thematik Mit dem Sprung in die Informationsgesellschaft sehen sich Unternehmen mit neuen Heraus-forderungen und Gelegenheiten in der Arbeitswelt und den Märkten konfrontiert. Die zuneh-mende Verflechtung von Unternehmen und die Globalisierung der Märkte lassen eine stei-gende Informationsdichte aufkommen, wodurch die Forderung nach professionellen Informa-tions- und Kommunikationstechnologien stetig wächst. Die Dezentralisierung von Geschäfts- und Produktionsprozessen fordert zudem eine Kooperation einer Vielzahl von Projektteil-nehmern an unterschiedlichen Standorten. Daher bedarf es des Aufbaus von Unternehmensnetze bzw. virtueller Netze, die lokale Netz-segmente an verschiedenen Standorten verbinden. Zur Realisierung dieser Unternehmensnet-ze werden sich heute unterschiedlichster Technologien bedient. Ein Begriff der im Zusam-menhang mit dem Internet immer mehr an Bedeutung gewinnt, ist der des Virtual-Private- Network (VPN). 1.1 Was ist ein VPN? Was ist ein VPN? Ein VPN ist ein privates Netzwerk, das Gebrauch von einer öffentlichen Telekommunikationsinfrastruktur macht und dabei Privatsphäre und Sicherheit durch Tunnel-protokolle und Sicherheitsverfahren bietet. Tunnel bezeichnet dabei eine Technologie, mit der es möglich ist, logische (virtuelle) Verbindungen zwischen Netzwerken über öffentliche Net-ze herzustellen. Im Gegensatz dazu stehen Systeme mit eigenen oder gemieteten Leitungen, die exklusiv von Unternehmen genutzt werden. Der Einsatz von VPNs hat dabei zum Ziel, die gleichen Fähigkeiten wie die Systeme mit gemieteten Leitungen zu niedrigeren Kosten bereit-zustellen. Gerade mit IP-VPNs lassen sich große Einsparungen erreichen. Dies sind virtuelle private Netzwerke, die das Internet als öffentliches Transportmedium verwenden. Tabelle 1.1 zeigt eine aktuelle Beispielrechnung von Cisco Systems, die die monatlichen Einsparungen bei Remote-Access-VPNs durch die Nutzung von IP-VPNs gegenüber Wählverbindungen über Telefonnetze aufführt. Um Telekommunikationskosten zu sparen, setzen daher immer mehr Unternehmen auf die vergleichbar günstigeren VPN-Lösungen. Wie aktuelle Studien von In-fonetics Research Inc. zeigen, werden die Ausgaben für VPN-Produkte und Dienstleistungen in Europa zwischen 2002 und 2006 von 5,4 Milliarden US Dollar auf 13,2 Milliarden US Dol-lar steigen. Die Integration von VPN-Gateways und Clients in bestehende LANs wird sich dabei laut Studie in den nächsten zwei Jahren verdoppeln und damit in Europa sogar über dem Wert in den USA und Kanada liegen, wo derzeit die Ausgaben für VPN Technologien welt-weit am höchsten sind [Inf02]. Der Schlüssel zur Kostensenkung ist die Konsolidierung auf eine einzige Infrastruktur mit gemeinsamen Standards. Einige bedeutende Technologien wurden aus diesem Grund bereits durch die IETF standardisiert, andere sollen es noch werden. Sie besitzen dadurch einen ho-hen Stellenwert auf dem VPN-Markt, der mittlerweile eine Vielzahl von Anbietern und Pro-dukten mit den unterschiedlichsten Technologien umfasst. Im Folgenden werden einige wichtige Technologien ausführlicher erläutert. Zuvor noch die verschiedenen Typen besprochen, auf die Anforderungen eingegangen und schließlich einige wichtige Protokolle diskutiert. Danach folgt eine Zusammenfassung.

___________________________________________________________________________ 2/24

Monatliche Einwählkosten Monatliche VPN Kosten

Remote-Benutzer mit 800 Verbindungen 3000 durchschnittliche Nutzung in Std./Woche/Arbeitnehmer

x 10

800 Nummer Kosten/Minute x $0.08 Min/Std. * Wochen/Monat (konstant) x 240

Einwählbenutzer insgesamt

3500

ISP Kosten x $20 $70,000 Broadband-Benutzer (Kabel, DSL)

500

ISP Kosten x $50 $25,000

Einwählkosten pro Monat insgesamt: $576,000.00 VPN monatlich insgesamt: $95,000.00

Monatliche Einsparungen: $481,000 Hardware / Kosten • 1 Cisco VPN 3060 Concentrator

Minimale Hardware-Kosten insgesamt: $40,000 Betrachtungszeitraum: 1 Monat

Tabelle 1.1: monatliche Einsparungen durch den Einsatz von IP-VPNs mit Software-Clients [Cis03a]

1.2 Begriffserläuterungen B2B Business-to-Business B2C Business-to-Customer GPRS General Packet Radio Services; eine paketorientierte Technologie

mit der sich IP-Pakete über GSM-Netze übertragen lassen GSM Global System for Mobile Communication; ein Mobilfunkstandard

der zweiten Generation IETF Internet Engineering Task Force, eine Internet Standardisierungs-

organisation ISDN Integrated Services Digital Network ISP Internet Service Provider LAN Local Area Network; lokales Netzwerk OSI-Schichtenmodell Referenzmodell für Rechnerarchitekturen auf Basis von sieben

Schichten POP Point of Presence, Zugangsknoten zum Internet PSTN Public Switched Telephone Network; das weltweite Telefonnetz Multicast IP-Kommunikationsmodus bei dem anstelle eines eine Gruppe von

Empfängern von einem Sender aus adressiert wird NAT Network Address Translation RAC Remote Access Concentrator S2M ISDN-Primärmultiplexanschluss mit 30 B-Kanälen je 64 Kbit/s V.110 Ein Übertragungsverfahren mit Bitratenadaption, das aus den 80er

Jahren, dem Anfangsstadium von ISDN, herrührt V.90 V.90 ist ein Standard (Protokoll) der ITU für die analoge Daten-

übertragung mit bis zu 56 Kbit/s über Modems WAN Wide Area Network; Weitverkehrsnetz TTL Time-to-Live

___________________________________________________________________________ 3/24

2. VPN-Typen Bei heutigen VPNs werden drei wesentliche Anwendungsfälle unterschieden, die sich aber nicht ausschließen und somit miteinander kombinieren lassen: Remote-Access-VPN, Branch-Office-VPN und Extranet-VPN. In allen Fällen können die VPNs von den Unternehmen selbst, einem ISP oder einem Netzanbieter betrieben werden. 2.1 Remote-Access-VPN Mit einem Remote-Access-VPN kann von entfernten Systemen auf das Intranet des Unter-nehmens zugegriffen werden. Außendienstmitarbeiter z.B. können sich mit ihrem Laptop über PSTN, ISDN oder auch per Mobiltelefon über GSM, GPRS in das Firmennetz einwählen und auf bestimmte Ressourcen und Applikationen zugreifen. Es gibt verschiedene Möglichkeiten solche Systeme zu realisieren. Früher wurden hierzu so genannte Remote Access Concentra-tor (RACs) eingesetzt, die eine Einwahl über öffentliche Telefonsysteme ermöglichen. Die Anbindung kann dabei über einfache ISDN-S0-Anschlüsse oder auch über S2M-Anschlüsse erfolgen, je nach Anzahl der benötigten Ports. S2M-Anschlüsse bestehen aus 30 Nutzdaten-kanälen und sind bei vielen anzubindenden Clients günstiger als entsprechende ISDN-Anschlüsse. Spezielle Router, die diese Primärmultiplexanschlüsse unterstützen, müssen dann für die jeweiligen Protokolle wie V.90, ISDN oder V.110 ausgelegt sein, um eine Einwahl-möglichkeit über die oben genannten Netze bereitzustellen. Solche Geräte sind in der Regel sehr teuer. Hinzu kommen die hohen Grundgebühren für die ISDN- oder S2M-Anschlüsse und die jeweiligen Verbindungsentgelte, die gerade bei Verbin-dungen ins Ausland oft sehr kostenintensiv sind. Deshalb steigen viele Unternehmen auf die günstigeren IP-VPNs um, die gerade die Kostensenkung in diesem Bereich zum Ziel haben. Benötigt wird hierzu ein VPN-Konzentrator, der wesentlich günstiger ist und auch die Ver-bindungsgebühren senkt. Ein Außendienstarbeiter oder Heimarbeiter braucht sich lediglich über einen ISP ins Internet einzuwählen und kann anschließend mit speziellen Software-Clients eine Verbindung zum VPN-Konzentrator herstellen. Es lassen sich beliebige Techno-logien für die Verbindung zum ISP einsetzen, z.B. Modems, ISDN oder auch DSL und Ka-belmodems, sodass auch günstige Breitbandanbindungen beispielsweise für Heimarbeiter zur Verfügung stehen. Der VPN-Konzentrator terminiert in diesem Fall nur logische Verbindungen (Tunnel). Proto-kolle die dafür häufig zum Einsatz kommen sind das Layer-2-Tunneling-Protocol (L2TP), das Layer-2-Forwarding-Protokoll (L2F), das Point-to-Point-Tunneling-Protocol (PPTP) oder das IP-Security-Protokoll (IPSec). In Kapitel 4 werden diese Protokolle genauer erläutert. 2.2 Branch-Office-VPN Branch-Office-VPN oder auch Intranet-VPN, Site-to-Site-VPN bezeichnet ein Netzwerk, das die Intranets verschiedener Standorte eines Unternehmens verbindet. An allen Standorten des Unternehmens kann so auf Datenbanken oder Dienste in der Unternehmenszentrale zugegrif-fen werden. Die verschiedenen Teilnetze verschmelzen zu einem einzigen großen Netzwerk. Natürlich sind solche Netze längst nichts Neues mehr. Einige teilweise schon recht alte Tech-nologien wie Frame-Relay oder ATM haben dies früher schon ermöglicht, sind jedoch im Vergleich zu den Branch-Office-VPNs recht teuer. Gerade wenn weit entfernte Standorte, möglicherweise sogar im Ausland, miteinander verbunden werden sollen, fallen schnell hohe Kosten und ein erheblich größerer Aufwand an, da oftmals viele verschiedene Netzbetreiber mit einbezogen werden müssen.

___________________________________________________________________________ 4/24

Bei Branch-Office-VPNs ergibt sich keines dieser Probleme, da lediglich ein Internetan-schluss bei einem ISP und ein Firewall-System bzw. Router benötigt wird. Eine zusätzliche Client-Software erübrigt sich, wenn der Tunnel zwischen den Firewall-Systemen aufgebaut wird. Sie sind dann für die vollständige Verwaltung der Tunnelverbindung zuständig. Daten werden also von den Clients bis zur Firewall ungesichert übertragen und von da an durch den Tunnel geschützt. 2.3 Extranet-VPN Ein Extranet-VPN baut auf den beiden anderen VPN-Typen auf. Es beinhaltet jedoch die Ein-beziehung von Partnern, Lieferanten und Kunden in das Unternehmensnetz. Diesen wird ein zeitlich begrenzter und limitierter Zugang zum Unternehmensnetz gewährt. Auch wird norma-lerweise nur von einem Extranet gesprochen, wenn Internettechnologie im Unternehmensnetz verwendet wird [Det01]. Mit solchen Netzen sind einige Vorteile verbunden. Ein Extranet begünstigt Bestellvorgänge, Verkauf, Kundenservice und Projektmanagement und ermöglicht insgesamt eine größere zeit-liche Effizienz der Geschäftsprozesse. Es hilft auf diese Weise, Einsparungen zu erzielen und bietet somit eine attraktive Kommunikationsplattform für die heutige B2B- und B2C-Kommunikation. Nachteile, die sich jedoch ergeben, sind Probleme bei der Netzwerkadmi-nistration und die schwierige Integration von Anwendungen. Auch ist ein aufwendigerer Zugriffsschutz nötig, da häufig mehrere Netze von verschiedenen Netzbetreibern zur Verbin-dungsherstellung miteinbezogen werden müssen. Für das letztere werden in der Regel ent-sprechend konfigurierte Firewalls eingesetzt. Sie sind zuständig für die Zugriffsbeschränkung und die Filterung der Pakete. Alles Weitere wird vom VPN-Gateway übernommen.

Abbildung 2.1: Einsatzgebiete von VPNs (Remote-Access-VPN, Branch-Office-VPN, Extranet-VPN)

___________________________________________________________________________ 5/24

2.4 Tunneling-Modelle Zusätzlich zu den genannten Anwendungsfällen wird bei VPN-Verbindungen zwischen Tun-neling-Modellen unterschieden. Je nachdem in welchem Maße der ISP in die Verwaltung des VPNs miteinbezogen werden soll, wird hier differenziert. Es zeichnen sich dabei drei Modelle ab: das Intra-Provider-Modell, Provider-Enterprise-Modell und das Ende-zu-Ende-Modell. 2.4.1 Intra-Provider-Modell Bei diesem Modell beginnen und enden die Tunnel an den POPs des ISPs. Er ist für die Ver-waltung der Tunnelverbindung zuständig. Dies hat den Vorteil, dass keine zusätzliche Soft-ware für die Clients benötig wird. Bei einer großen Anzahl einzuwählender Clients ist daher der Konfigurationsaufwand wesentlich geringer. Es ist auch kein eigenes VPN-Gateway auf Seiten des Kunden erforderlich. Dem Kunden obliegt lediglich das VPN-Management, wie z.B. die Benutzerverwaltung. Die Systemkonfiguration übernimmt vollständig der ISP. Gege-benenfalls kann natürlich auch das VPN-Management vom ISP durchgeführt werden. Dann aber wäre ein größeres Vertrauen in den ISP nötig und auch die Abhängigkeit von ihm nähme zu, was einen Wechsel wiederum erschweren würde. 2.4.2 Provider-Enterprise-Modell Im Provider-Enterprise-Modell endet der Tunnel erst am VPN-Gateway des Kunden. Die Clients wählen sich nach wie vor am POP des ISPs ein, von wo aus die Tunnelverbindung aufgebaut wird. Dieses Modell wird hauptsächlich für Remote-Access-VPNs verwendet. 2.4.3. Ende-zu-Ende-Modell Die Tunnelverbindung wird bei diesem Modell auf den Systemen des Kunden aufgebaut. Er benutzt eine spezielle Client-Software, mit der sich die Clients am VPN-Gateway einwählen. Der ISP stellt lediglich die Internetverbindung. Für die Sicherheit, Wahl der Tunnelprotokolle, etc. ist der Kunde zuständig. Der gesamte Datenverkehr bleibt dann für den ISP verborgen. Er kann nur an dem besonderen Aufbau der IP-Pakete erkennen, dass eine Tunnelverbindung über seine Leitungen hergestellt wurde.

3. Anforderungen an VPNs Im vorherigen Kapitel wurden die Anwendungsfälle für VPNs besprochen. Solche VPNs nut-zen meist das Internet als öffentliche Kommunikationsinfrastruktur. Es ergeben sich dabei jedoch einige Probleme, die aus den Anforderungen, die Unternehmen üblicherweise an Netzwerkverbindungen über öffentliche Netze stellen, resultieren. Ein Problem, das viele Un-ternehmen in der Vergangenheit davon abhielt, auf die günstigeren VPNs umzusteigen, war die mangelnde Sicherheit solcher Systeme. Denn in den seltensten Fällen sollten die Daten bei der Übertragung über solche Netzwerke von anderen mitgelesen werden können. Zu denken sei z.B. an die Übermittlung von Kreditinformationen oder Personendaten. Allerdings hat sich das mittlerweile geändert. Es gibt längst standardisierte Verfahren, die die notwendige Sicherheit bieten. Dennoch gibt es nach wie vor Probleme, die teils erst durch den steigenden Kommunikationsbedarf von Unternehmen mit Partner oder Außenstellen entstan-

___________________________________________________________________________ 1 Standard des US-amerikanischen National Bureau of Standards (NBS), 1977 verabschiedet 2 Standard des US-amerikanischen National Institute of Standards and Technology (NIST), 2001 verabschiedet

6/24

den sind. Der Trend geht dahin, dass WANs nicht nur zur reinen Datenübertragung, sondern auch zum Übertragen von Sprache oder Video genutzt werden. Allgemein wird dieser Vor-gang, das Zusammenführen von getrennten Netzen zu einem einzigen, als Konvergenz be-zeichnet [Cis03b]. Das erfordert natürlich höhere Bandbreiten sowie geringe Verzögerungs-zeiten. In einem Netz, das nach dem Best-Effort-Prinzip arbeitet, wie das Internet, ist das al-lerdings nicht ohne weiteres umzusetzen. Es gibt allerdings einige Verfahren zur Gewährleis-tung von Quality-of-Service in IP-VPNs, wovon eins im Anschluss näher erläutert werden wird. Doch zunächst sollen die wichtigsten Anforderungen an die Sicherheit besprochen wer-den. 3.1 Sicherheit Um eine sichere VPN-Verbindung herzustellen, müssen die VPN-Systeme gleich mehrere Anforderungen abdecken. Dies sind: • Vertraulichkeitsschutz der Daten • Sicherheit beim Schlüsselaustausch • Authentifizierung der Kommunikationspartner • Integritätsüberprüfung der ankommenden Daten 3.1.1 Datenvertraulichkeit Um zu verhindern, dass Daten bei ihrem Transport über das Internet von Angreifern mit ge-eigneten Abhörmaßnahmen mitgelesen werden können, müssen die Datenpakete verschlüsselt werden. Dazu gibt es mehrere Verfahren, die die Verschlüsselung auf unterschiedlichen Schichten des OSI-Schichtenmodells durchführen. Auch hier wird bevorzugt auf standardi-sierte Verfahren zurückgegriffen. Ein beliebtes Protokoll, das auf Ebene 3 betrieben wird und sich in das IP-Protokoll integriert, ist IPSec. Es unterstützt verschiedene Algorithmen und Schlüssellängen zur Datenverschlüsselung. Aufgrund der Geschwindigkeit werden in der Pra-xis meist symmetrische Verfahren (Sender und Empfänger benötigen den gleichen Schlüssel zum Ver- und Entschlüsseln) verwendet. Der Data-Encryption-Standard (DES)1 mit einer Schlüssellänge von 56 Bit ist ein solches Verfahren und muss dabei immer implementiert werden, um eine gegenseitige Verständigung der beteiligten Systeme immer zu gewährleisten. Jedoch werden bevorzugt auch andere Algorithmen eingesetzt wie z.B. Tiple-DES mit 168 Bit Schlüssellänge oder als neueres Verfahren der Advanced-Encryption-Standard (AES)2 mit einer Schlüssellänge von 128 Bit aufwärts, da der Zeitaufwand bei einem Brute-Force-Angriff (alle Schlüsselvarianten werden ausprobiert) zur Ermittlung eines DES-Schlüssels mit 56-Bit mit teueren Parallelrechnern bereits auf wenige Stunden oder gar Minuten reduziert werden kann [Lip01]. Soll zusätzlich ein Ausspionieren des Netzwerkes wie z.B. die IP-Adressen, verwendete Portnummern oder Protokolle verhindert werden, ist es erforderlich, Tunneling-Verfahren einzusetzen (s. Kapitel 2). 3.1.2 Schlüsselmanagement Symmetrische Verschlüsselungsverfahren benötigen zur Ver- und Entschlüsselung einen ge-meinsamen Schlüssel, der bei einer VPN-Verbindung beiden Kommunikationspartnern be-kannt sein muss. Dieser kann manuell ausgetauscht werden z.B. per Post oder durch ein Tref-fen. Wenn es sich allerdings um viele Personen handelt, die sich an weit voneinander entfern-ten Orten befinden oder gar nicht vorher kennen, ist dies bereits problematisch. Natürlich dür-fen die Schlüssel auf keinen Fall über das Internet übertragen werden, denn sonst könnte je-mand mitlesen.

_________________________________________________________________________________________________________________

7/24

Eine Lösung waren erstmals die so genannten asymmetrischen Verschlüsselungsverfahren. Dabei werden zur Ver- und Entschlüsselung unterschiedliche Schlüssel angewandt. Der Schlüssel für die Verschlüsselung kann somit jedem bekannt sein, da die Daten mit ihm nicht wieder entschlüsselt werden können. Dieser wird daher auch als öffentlicher Schlüssel be-zeichnet. Der private Schlüssel hingegen darf nur dem Empfänger bekannt sein, der damit in der Lage ist, die Daten wieder zu entschlüsseln. Solche Verfahren sind relativ neu in der Kryptologie. 1976 brachten Diffie, Hellman und Merkle erstmals ein Verfahren heraus, das Diffie-Hellman-Merkle-Verfahren mit dem es möglich war einen Schlüssel auf diese Weise zu chiffrieren. Ein Jahr später mit dem RSA-Verfahren von Rivest, Shamir und Adleman war es dann auch möglich, Daten zu ver- und entschlüsseln. 3.1.3 Authentifizierung Um nur berechtigten Personen den Zugriff auf das Intranet über eine VPN-Verbindung zu gewähren, muss sichergestellt werden, dass der andere Kommunikationspartner auch der rich-tige ist und nicht ein unberechtigter Dritter. Dazu sind genau genommen zwei Überprüfungen notwendig, zwischen denen unterschieden werden muss. Zum einen muss verifiziert werden, dass die erhaltenen Pakete auch tatsächlich von dem am VPN-System angemeldeten Benutzer stammen und zum anderem die Identität des Benutzers nachgewiesen werden. Ohne die erst-genannte Überprüfung wäre es möglich, dass ein Dritter Pakete abfängt, eigene Pakete erstellt und sie anschließend mit gefälschter Absenderadresse an das VPN-System weiterleitet. Das VPN-System würde die Manipulation nicht erkennen können. Heutige VPN-Systeme unterstützen in der Regel mehrere Verfahren zur Benutzerauthentifi-zierung. Dies können einfache Passwortverfahren, Verfahren mit Tokenkarten oder auch Ver-fahren mit digitalen Zertifikaten sein, die auf den zuvor genannten asymmetrischen Ver-schlüsselungsverfahren basieren. Die Paketauthentifizierungsverfahren greifen aus Gründen der Geschwindigkeit hautsächlich auf symmetrische Verschlüsselungsverfahren oder so ge-nannte Pre-shared-secrets zurück. 3.1.4 Integrität Daran schließt sich die Integritätsprüfung an, die kontrolliert, ob die Pakete auf der Strecke vom Sender zum Empfänger verändert worden sind. Üblicherweise werden dazu Prüfsummen von dem Datenanteil des Pakets erstellt und anschließend mit in das Paket eingefügt. Für de-ren Berechnung können Hashfunktionen wie MD5 oder SHA genutzt werden. Der IPSec-Standard schreibt unter anderem die Verwendung dieser Funktionen als obligatorische Ver-fahren vor. Es ist jedoch zu beachten, dass einfache Prüfsummenverfahren nicht vor Manipulationen von Paketen schützen. Ein Angreifer könnte Pakete abfangen, sie manipulieren, deren Prüfsumme neu berechnen und sie anschließend an den Empfänger schicken. Der Empfänger würde dann bei einer erneuten Berechnung der Prüfsumme nicht bemerken, dass in Wirklichkeit eine Ver-änderung stattgefunden hat. Anders sieht das aus, wenn die Prüfsummen mit einem so ge-nannten Key-Hashing-Verfahren erstellt wurden. Dabei wird der Hashwert nicht nur aus der Nachricht selbst, sondern zusätzlich aus einem Schlüssel, der sowohl dem Sender als auch dem Empfänger bekannt sein muss, erstellt. Darüber hinaus, sollte das VPN-Gateway vor Angriffen sicher sein. Es gibt eine Vielzahl von Angriffsmöglichkeiten. Auf jeden Fall muss das Gateway vor Angriffen aus dem Internet Schutz bieten z.B. davor, dass ein Unbefugter über das Gateway Zugriff auf das Intranet er-langt. Es sollten aber auch Maßnahmen ergriffen werden, das Gateway vor internen Angriffen zu schützen. Dies kann erreicht werden, indem das Gateway z.B. in einer sicheren Umgebung betreiben wird, zu der nur autorisiertes Personal Zugang hat. Zu bedenken sind aber auch An-

_________________________________________________________________________________________________________________

3 Bezeichnet das Verhältnis von korrekt übertragenen und zerstörten oder verlorenen Datenpaketen 8/24

griffe aus dem eigenen Intranet. So etwas kommt durchaus nicht selten vor und darf daher bei dem Aufbau geeigneter Sicherheitssysteme nicht unbeachtet bleiben. 3.2 Quality-of-Service (QoS) Unter Quality-of-Service wird allgemein die Zusicherung einer bestimmten Qualität für einen Datenfluss oder eine Verbindung verstanden. Die einzelnen Charakteristika werden für ge-wöhnlich anhand technischer Aspekte festgemacht. Jedoch gibt es große Unterschiede bei den einzelnen Konzepten, da der Begriff QoS keine spezifizierte Definition besitzt. Motiviert wurde die Einführung eines solchen Dienstes durch die Forderung, Anwendungen mit unterschiedlichen Anforderungen im selben Netz zu betreiben. Diese Anforderungen sind vor allem eine feste Bandbreite, Verzögerungszeit (Delay) sowie deren Variation (Jitter) und die mittlere Fehlerrate3. Typische Anwendungen sind IP-Telefonie [Cis03c] oder Videokonfe-renzen, die zunehmend in LANs und VPNs zusammen mit Applikationen für reine Daten-übertragung betrieben werden. Sie reagieren sehr empfindlich bei auftretendem Delay oder Jitter im Gegensatz zu einer Dateiübertragung per FTP oder dem Versenden von E-Mail, wo es lediglich darauf ankommt, dass die Fehlerrate möglichst gering ist. Um nun gleichzeitig eine optimale Auslastung der Netze zu gewährleisten, muss eine Einteilung der Anwendungen in bestimmte Klassen erfolgen, die gemäß den Anforderungen verarbeitet werden. Würde den Teilnehmern in einem Netz lediglich bestimmte Bandbreiten zugewiesen werden, könnte die Kapazität schnell erschöpft sein, ohne dass eine vollständige Ausnutzung stattfindet, da si-cherlich nicht immer alle Anwender die gesamte ihnen zur Verfügung stehende Kapazität benötigen. Bei ATM ist QoS von Anfang an vorgesehen worden. Es wurde ursprünglich für Sprach- und Videoübertragungen entwickelt und besitzt eine geringe Verzögerungszeit, so gut wie keinen Jitter und die mittlere Fehlerrate liegt bei fast null. Darüber hinaus lässt es eine hohe Band-breite zu und ist dadurch besonders für Multimediaanwendungen aber auch für die Übertra-gung von Daten geeignet. VPNs als Alternative zu Standardfestverbindungen sollen natürlich ähnliche Charakteristika aufweisen. Doch im Internet wird gewöhnlich nach dem Best-Effort-Prinzip bei der Zustel-lung von Paketen verfahren. Das heißt alle Pakete werden gleich behandelt und eine Unter-scheidung nach Priorität findet nicht statt. Erreichen mehr Pakete einen Router als er verarbei-ten kann, entstehen Verzögerungen bei der Weiterleitung oder die Pakete werden verworfen. Zur Nutzung von QoS im Internet, muss zurzeit noch auf lokale Dienstleistungen zurückge-griffen werden, falls solche Angebote überhaupt existieren. Eine globale Lösung gibt es nicht. Es gibt zwar bereits Standards der IETF für QoS im Internet, die dafür erforderliche Hard- und Softwareumstellung wird jedoch noch einige Zeit in Anspruch nehmen. Das folgende Kapitel beschäftigt sich mit dem Diffenrentiated Services (DiffServ)-Verfahren, das durch die IETF in den RFCs [2474], [2475] und [2598] spezifiziert wurde. 3.2.1 Differentiated Services (DiffServ) Das DiffServ-Verfahren baut auf dem Class-of-Service (CoS)-Prinzip auf. Dabei werden die zu versendenden Pakete in unterschiedliche Klassen unterteilt, entsprechend gekennzeichnet und gemäß ihrer zugeordneten Priorität im Netz weitergeleitet. In den Routern muss dazu eine geeignete Strategie implementiert sein, die einzelnen Pakete nach ihren Klassen weiterzulei-ten. Der Vorteil dieses Verfahren liegt darin, dass nur geringe Ressourcen bei den Vermitt-lungssystemen beansprucht werden. Das heißt, es muss nicht erst eine Signalisierung an die verwendeten Router stattfinden, um eine gewisse Dienstgüte auf dem Übertragungsweg zu nutzen. Ein Nachteil der sich daraus ergibt, ist natürlich, dass dadurch auch kein tatsächlicher QoS mehr vorhanden ist. Innerhalb der Klassen werden die Pakete wieder nach dem Best-Effort-Verfahren behandelt. Im schlimmsten Fall befinden sich alle Pakete in der höchsten

__________________________________________________________________________ 9/24

Klasse und der Vorteil für die Teilnehmer bleibt aus. Dennoch werden DiffServ die besten Chancen eingeräumt, sich gegenüber den anderen Verfahren durchzusetzen, da Verfahren mit reservierten Ressourcen wie die Integrated Services (IntServ) oder solche, die Engpässe durch eine Überdimensionierung der benötigten Kapazität versuchen zu umgehen, in der Pra-xis meist zu große Anforderungen an die Hardware stellen, sodass aus Kostengründen auf deren Einsatz verzichtet werden muss. DiffServ verwendet das CoS Prinzip. Der Standard schreibt eine Einteilung in Klassen vor, denen ein bestimmtes Verhalten, das so genannte Per-Hop-Behaviour (PHB), zugeordnet wird. An den Knoten werden die Pakete nach dem definierten PHB weitergeleitet. Die PHB-Definition gilt dabei nach [RFC2475] für eine DiffServ-Domäne. Diese bezeichnet ein Netz-werk bestehend aus mehreren Knoten mit eindeutig festgelegten Grenzen, wie es von ISPs betrieben wird oder auch als Intranet innerhalb eines Unternehmens. Die Netzbetreiber sind dafür zuständig, Merkmale wie Verzögerungszeit, Jitter oder Fehlerrate je nach getroffenen Service-Level-Agreements (SLAs) mit dem jeweiligen PHB zu verbinden. Eine Klassifizie-rung der Pakete wird an den Grenzen des Netzwerks vorgenommen. Dafür ist ein spezieller Router oder auch eine Applikation zuständig, die die ausgehenden Pakete markiert. Solche Knoten werden als DS-Boundary-Nodes bezeichnet. Innere Knoten hingegen, die nur zur Weiterleitung dienen, als DS-Interior-Nodes. Nun unterstützt das IP-Protokoll aber kein QoS. Es gibt aber im IP-Header ein Feld das Type-of-Service (TOS)-Feld, das von vornherein für zukünftige Entwicklungen Speicherplatz re-servieren sollte. Dieses Feld wird von DiffServ genutzt. Die Länge beträgt 8 Bit. DiffServ beansprucht davon 6 Bit für den DS-Codepoint (DSCP). Die restlichen 2 Bit bleiben frei. In IPv6 wird hierfür das Traffic-Class-Oktett verwendet. [RFC2474] spezifiziert die Nutzung der Felder durch DiffServ. Die ersten 3 Bit bezeichnen dabei die Klasse, in der sich die Pakete befinden und die restlichen 3 die Bevorzugung innerhalb einer Klasse. Der Standard DS-Codepoint ist 000000. Er bezeichnet Pakete, die nach dem Best-Effort-Verfahren weitergelei-tet werden sollen. Ansonsten findet mit Hilfe einer Mapping-Tabelle die Abbildung eines DSCP auf ein PHB statt. Es können dabei durchaus mehrere DSCP auf ein PHB abgebildet werden. Pakete mit dem DS-Codepoint 11x000 müssen jedoch bevorzugt behandelt werden im Vergleich zu denen mit dem DS-Codepoint 000000. Wie schon erwähnt, müssen verschiedene DiffServ-Domänen nicht auf identische PHB-Klassen zurückgreifen. Außerdem sind die Weiterleitungsmechanismen in den lokalen Netzen oft sehr verschieden. Die DS-Boundary-Nodes müssen daher Pakete die das lokale Netzwerk verlassen, anhand des DSCP-Feldes und den Spezifikationen des anderen Netzes neu klassifi-zieren. In VPNs eignet sich besonders das IPSec-Protokoll zum kombinierten Einsatz mit DiffServ. Eine Neuklassifizierung, wie oben beschrieben, ist damit problemlos möglich, da bei der Ein-kapselung der Pakete, die z.B. beim Verlassen des Intranets eines Unternehmens vorgenom-men wird, das DSCP-Feld aus dem Header in den neuen Header übernommen wird oder aber ein neuer Wert in den neuen Header eingetragen werden kann, ohne dass sich der alte Wert im eingekapselten Paket ändert. Erreicht das IPSec-Paket das Zielnetzwerk, kann die Weiterlei-tung daher mit Hilfe des ursprünglichen DSCP-Wertes fortgesetzt werden. In Zusammenhang mit IPSec wird dies noch ausführlicher erläutert (s. Kapitel 4.2.1).

4. VPN-Basistechnologien In Kapitel 2 wurden bereits die Tunneling-Verfahren besprochen. Ein Tunnel bildet das Kern-stück einer VPN-Verbindung. Er dient dazu, Pakete eines Netzwerkprotokolls in neue Pakete

__________________________________________________________________________ 10/24

des gleichen oder eines anderen Protokolls zu kapseln (Encapsulation). Dadurch lassen sich z.B. IPX-Pakete über ein IP-Netz wie das Internet übertragen. Er bietet außerdem zusätzliche Sicherheit, da die ursprüngliche Absenderadresse eines Pakets und auch die tatsächliche Emp-fängeradresse verborgen bleiben, wenn der Tunnel nicht direkt von den Client-Systemen aus-geht. Gegenstand dieses Kapitels sollen die dafür verwendeten Tunnelprotokolle sein. Sie werden nach der Schicht des OSI-Schichten-Modells unterschieden, dessen Pakete sie einkapseln. In der Praxis haben sich PPTP, L2F und L2TP als Layer-2 und IPSec als Layer-3-Protokoll durchsetzen können. Davon werden jedoch L2TP und IPSec die größten Chancen eingeräumt, den Markt zu dominieren. Sie sind im Vergleich zu PPTP und L2F weitreichend von der IETF standardisiert worden und besitzen für die in Kapitel 3 genannten Anforderungen umfangrei-che Spezifikationen. In diesem Kapitel soll daher hauptsächlich auf diese Technologien eingegangen werden, es soll aber auch eine kurze Beschreibung von PPTP und L2F liefern. Zu nennen sind in diesem Zusammenhang auch noch Verfahren auf den Schichten 4 und 5 wie SSL/TSL und Socks V5, die im heutigen E-Business bevorzugt verwendet werden. SSL/TSL dient dazu eine sichere Verbindung zwischen einem Server und speziellen Anwendungen herzustellen. Socks V5 wird zum sicheren passieren einer Firewall eingesetzt. Sie sind eine Form eines VPNs nach der obigen Definition, benutzen allerdings kein Tunnelverfahren. Auf eine Erläuterung wird daher verzichtet. Genaueres hierzu findet sich in [Det01] und [Böh02]. 4.1 Layer-2-Tunneling-Protokolle Layer-2-Tunnelling-Verfahren haben den generellen Vorteil, dass sie Multiprotokollfähig sind. Das heißt, es lassen sich mehrere Protokolle kapseln z.B. IP, IPX oder NetBUI anstatt nur IP. Außerdem gibt es auch keine Probleme in Systemen, in denen eine NAT vorgenommen wird. Sie basieren vorwiegend auf dem Point-to-Point-Protokoll (PPP). PPP ist Industriestandard nach [RFC-1661] und wird in der Regel in Einwählumgebungen eingesetzt. Die Internetver-bindungen eines ISP beispielsweise verwenden weltweit fast ausschließlich PPP. Es lassen sich damit mehrere Protokolle kapseln und über eine serielle Leitung übertragen. Zu den Ei-genschaften zählen benutzerorientierte Authentifizierung, Kompression und Verfahren zum Aushandeln von Konfigurationsparametern für die Netzwerkprotokolle der Schicht 3. Die Tunneling-Protokolle machen sich diese Eigenschaften zu Nutze. 4.1.1 Layer 2-Tunneling-Protocol (L2TP) Das Layer-2-Tunneling-Protocol kombiniert die besten Eigenschaft von PPTP und L2F. PPTP wurde von Microsoft, U.S. Robotics, Ascend Communications, 3Com Corporation und ECI Telematics als gemeinsames Projekt entwickelt. Zeitgleich arbeitete Cisco zusammen mit Northern Telekom und Shiva an L2F. Bei beiden handelt es sich um nicht standardisierte Pro-tokolle. Es liegen zwar RFCs der IETF für diese Protokolle vor, sie spezifizieren jedoch kei-nen Standard. Zusammen mit der IETF einigten sich die an PPTP und L2F beteiligten Firmen auf L2TP als gemeinsamen Standard, der in [RFC-2661] spezifiziert wurde. L2TP ist ab-wärtskompatibel, allerdings stärker mit L2F verwandt. Anwendungsfälle Das Einsatzgebiet von L2TP ist vorrangig der Remote-Access im Provider-Enterprise-Modell oder Ende-zu-Ende-Modell. Ein Tunnel wird immer von einem L2TP-Access-Concentrator (LAC) zu einem L2TP-Network-Server (LNS) aufgebaut. Das können auf der einen Seite der RAC eines ISPs oder ein Client-Rechner mit entsprechender Software und auf der anderen Seite ein VPN-Konzentrator oder spezielle Router mit L2TP-Funktionalität sein. In Abbildung 4.1 sind die Anwendungsfälle dargestellt.

__________________________________________________________________________ 11/24

Abbildung 4.1: L2TP Remote-Access im Provider-Enterprise- und Ende-zu-Ende-Modell Verbindungseigenschaften Über eine L2TP-Verbindung werden zwei verschiedene Pakettypen übertragen: Steuerungs-pakete und Datenpakete. Ein Tunnel existiert, sobald eine Steuerungsverbindung hergestellt wurde. In diesem Tunnel können dann mehrere logische PPP-Verbindungen existieren, unab-hängig davon welche Netzwerkprotokolle sie kapseln. Auch sind mehrere Tunnel in einer Verbindung möglich, die jeweils ihre eigene Steuerungsverbindung besitzen. Anhand entspre-chender Felder im L2TP-Header werden die Pakete den Tunneln und PPP-Verbindungen zu-geteilt und durch ein spezielles Bit, dem T-Bit, das sich ganz am Anfang des Headers befindet, nach Steuerungs- (T=1) und Datenrahmen (T=0) unterschieden. Abbildung 4.2 zeigt die Komponenten einer L2TP-Verbindung. Dargestellt ist ein Tunnel mit drei logischen PPP-Verbindungen, die die Netzwerkprotokolle IP, IPX und NetBUI kapseln.

Abbildung 4.2: Die Komponenten einer L2TP-Verbindung Verbindungsaufbau Der Aufbau einer L2TP-Verbindung nach dem Provider-Enterprise-Modell läuft folgender-maßen ab. Der Client wählt sich mit entsprechender Software per PPP am RAC des ISPs ein. Mit Hilfe einer speziellen Nummer, die der Client zur Einwahl verwendet oder einer Ergän-zung des Benutzernamens, kann der RAC erkennen, ob die Verbindung zum LNS getunnelt werden soll oder eine Einwahl ins Netz des Providers stattzufinden hat. Angenommen, der Client möchte auf das Unternehmensnetz zugreifen. Der RAC konsultiert in diesem Fall seine Datenbank nach Einträgen über die Zieladresse und die Art des zu verwendenden Tunnels. Findet er die erforderlichen Informationen, sendet er einen Start-control-connection-request (SCCRQ) an den LNS. Der LNS antwortet dem LAC mit einem Start-control-connection-reply (SCCRQ). Nachdem vom LNS die Nachricht Start-control-connection-connected (SCCCN) dem LAC mit einer Zero-length-body (ZLB)-Nachricht bestätigt wurde, existiert

__________________________________________________________________________ 12/24

eine Steuerungsverbindung zwischen LAC und LNS. Eine ZLB-Nachricht besteht nur aus dem L2TP-Header. Zusammen mit dem Tunnelaufbau kann eine Authentifizierung der Tunnelenden erfolgen. So genannte Attribute-Value-Pairs (AVPs), die dem L2TP-Header angehängt sind, dienen zum Austausch der Parameter. Das sind spezielle Header die neben einigen Flags, einer Hersteller-kennung nach [RFC-1700] und der Gesamtlänge des AVPs unter anderem ein Feld für den Bezeichner und den Wert, der variable sein kann, des Attributs besitzen. Es gibt eine Vielzahl solcher AVPs, die für die Verwaltung der Verbindung verwendet werden. Die Authentifizie-rung tauscht damit Challenge-, Response- und Accept-/Reject-Pakete aus ähnlich dem CHAP-Verfahren bei PPP, um beide Tunnelenden zu authentifizieren. Als nächstes wird eine Session innerhalb des Tunnels für die Übertragung der eigentlichen PPP-Pakete errichtet. Der LAC schickt einen Incoming-call-request (ICRQ) zusammen mit einer Sitzungsnummer an den LNS, dieser bestätigt mit einem Incoming-call-reply (ICRP). Der LAC antwortet mit einer Incomming-call-connected (ICCN)-Nachricht, die zusätzliche Parameter enthalten kann. Der LNS muss mit einer ZLB-Nachricht bestätigen, bevor es mög-lich ist, eine PPP-Verbindung aufzubauen. Soll umgekehrt eine Session vom LNS aus aufgebaut werden, sendet dieser einen Qutgoing-call-request (OCRQ) mit einer Sitzungsnummer an den LAC. Der LAC antwortet mit einem Outgoing-call-reply (OCRP), falls er die Anforderung akzeptiert und sendet anschließend einen Outgoing-call-connected (OCCN) zusammen mit einigen Parametern an den LNS, die der LNS mit einer ZLB-Nachricht bestätigt, wenn der Sessionaufbau beendet ist. Jetzt kann wiederum eine PPP-Verbindung hergestellt werden. Für eine PPP-Verbindung tauschen LAC und LNS Link-Control-Protocol (LCP)-Nachrichten aus. Sie legen Authentifizierungsverfahren, Datenkompression und Netzwerksteuerungs-protokolle (zur Übertragung von IP, IPX,…) fest (s. [RFC-1661]). Diese Aushandlungen kön-nen über den Tunnel direkt zwischen Client und LNS erfolgen. Nach Abschluss dieses Pro-zesses können nach der Benutzerauthentifizierung Daten über die PPP-Verbindung übertragen werden. Der Abbau des Tunnels folgt analog mit entsprechenden Steuerungspaketen. Zuerst werden die Sessions innerhalb des Tunnels abgebaut, ist keine Session mehr vorhanden, kann auch die Tunnelverbindung beendet werden. Erhält der LAC vom Client eine Clear-Call-Nachricht, sendet er zum Abbruch eine Call-Disconnect-Notify (CDN)-Nachricht, die Angaben über die Abbruchursache enthält, an den LNS. Nach Empfang der ZLB-Nachricht signalisiert der LAC dem Client den Sessionabbau mit einer Clear-Call-Nachricht, woraufhin die Verbindung zwi-schen LAC und Client beendet wird. Der Tunnel wird mit einer Stop-control-connection-notification (StopCCN)-Nachricht, die der LAC an den LNS sendet und anschließender ZLB-Nachricht beendet. In Abbildung 4.3 ist der Verbindungsaufbau in Form einer Time-Sequence-Chart dargestellt. Der Sessionaufbau erfolgt vom LAC zum LNS.

__________________________________________________________________________ 13/24

Abbildung 4.3: Der L2TP-Verbindungsaufbau Kapselung Wie zu erkennen ist, werden mehrere Header gesetzt bevor die eigentlichen Datenpakete fol-gen. Abbildung 4.4 soll dies für beide Fälle verdeutlichen. Zunächst zum Provider-

__________________________________________________________________________ 14/24

Enterprise-Modell. Der Client benutzt eine PPP-Verbindung, um IP-Pakete an den RAC des ISPs zu übertragen. Der RAC leitet diese Pakete durch den L2TP-Tunnel weiter an den LNS. Als Übertragungsmedium dient das Internet. Den PPP-Paketen wird daher ein L2TP-Header vorangestellt und dieser anschließend mit IP/UDP an den LNS übermittelt. Anders sieht es im Ende-zu-Ende-Modell aus. Hier beginnt der Tunnel bereits beim Client. Dieser muss daher die PPP-Pakete mit dem darin enthaltenen Netzwerkprotokoll in entspre-chende L2TP-Header kapseln, die wiederum per PPP und IP/UDP an den RAC gesendet wer-den.

Abbildung 4.4: Kapselung der verschiedenen Protokolle einer L2TP-Verbindung über das Internet Der RAC braucht dann nur den PPP-Header zu entfernen, um das Paket an den LNS weiter-leiten zu können. Eine Besonderheit, die L2TP besitzt, ist, dass die L2TP-Pakete nicht unbedingt über IP/UDP übertragen werden müssen. L2TP kann auch auf Protokollen niedrigerer Schichten wie ATM, Frame-Relay oder ISDN aufsetzen. Heutzutage wird jedoch vorwiegend IP als Übertra-gungsmedium verwendet, da es auch dem Internet zu Grunde liegt. Sicherheit Bei einer Übertragung über das Internet ist insbesondere auch die Sicherheit von L2TP zu betrachten. Eigentlich wäre hier von Unsicherheit zu sprechen, denn die Sicherheitsanforde-rungen, wie sie Kapitel 3 aufzeigt, werden von L2TP unzureichend erfüllt. Das liegt daran, dass L2TP ursprünglich auch nur ein reines Tunnelprotokoll sein sollte. Für eine Absicherung sind Protokolle auf den anderen Schichten zuständig, z.B. könnte SSL/TSL auf der Anwen-dungsschicht verwendet werden. Am häufigsten anzutreffen ist aber IPSec in Kombination mit L2TP. IPSec hat den Nachteil, dass es nur IP-Pakete kapseln kann. Als Sicherheits-

__________________________________________________________________________________________ 15/24

protokoll bietet es jedoch umfangreiche Funktionen zur Absicherung einer IP-Verbindung. Durch die hauptsächliche Nutzung des Internets als Übertragungsmedium für die L2TP-Verbindung können beide Protokolle daraus profitieren. Das Ergebnis ist eine sichere Tunnel-verbindung, über die es möglich ist, beliebige Protokolle zu transportieren. Die IETF hat eine Spezifikation hierfür herausgegeben und empfiehlt den Einsatz von IPSec zur Sicherung einer L2TP-Verbindung [RFC-3193]. Ausgehend von der in Abbildung 4.4 gezeigten Struktur ergibt sich daraus folgender Paket-aufbau. Im Provider-Enterprise-Modell werden die IP-Pakete zwischen LAC und LNS zusätz-lich von einem IPSec-Header und –Trailer umschlossen. Die Daten und die anderen Header sind dann verschlüsselt. Ein LNS, das diese Verbindung terminiert, muss zunächst die IPSec-Pakete entschlüsseln und danach die L2TP-Verarbeitung durchführen, bis die Daten an das Ziel weitergereicht werden können. Abbildung 4.5 zeigt die Kapselung mit dem zusätzlichen IPSec-Header und –Trailer.

Abbildung 4.5: Kapselung der verschiedenen Protokolle einer L2TP-Verbindung in Kombination mit IPSec Natürlich erfordert diese Verarbeitung einen wesentlich höheren Rechenaufwand. Problema-tisch wird es im Ende-zu-Ende-Modell. Angenommen 100 oder sogar 1000 Clients wollen sich am LNS anmelden und IPSec zur Verschlüsselung einsetzen. Dem VPN-Konzentrator obliegt dann die Verarbeitung von 1000 PPP-Sessions, L2TP-Tunnel und IPSec-Verbindungen. Das ist in der Tat nicht unmöglich, Systeme mit einer entsprechenden Rechen-leistung haben allerdings ihren Preis. Hier gilt es abzuwägen, welche Anforderungen ein sol-ches Netz wirklich zu erfüllen hat. Dennoch stellt IPSec in Kombination mit L2TP eine ele-gante Möglichkeit dar, eine sichere multiprotokollfähige Tunnelverbindung aufzubauen. Das hat auch Microsoft erkannt und IPSec bzw. L2TP fest in seine Betriebssysteme Windows 2000/XP integriert. L2TP-Verbindungen im Ende-zu-Ende-Modell lassen sich damit ohne größeren Konfigurationsaufbau schnell herstellen. Neben Microsoft gibt es eine ganze Reihe andere Hersteller, die L2TP und IPSec Software- und auch Hardwareprodukte verkaufen z.B. Cisco Systems, Ashley Laurent, Intel, Nokia, SSH Communications Security, um einige zu nennen. 4.1.2 Point-to-Point-Tunneling-Protocol (PPTP) Das Point-to-Point-Tunneling-Protocol erlangte seine Beliebtheit insbesondere dadurch, dass es in Microsofts Betriebssystem Windows NT 4.0 und später auch in Windows 2000 und

__________________________________________________________________________ 4 GRE ist eine erste Standardisierung für Tunnelverfahren durch die IETF ([RFC-1701], [RFC-1702]) 5 Eine von Microsoft weiterentwickelte Version von CHAP für den speziellen Einsatz unter Windows 6 SLIP ist für den Transport von Datenpaketen über serielle Punkt-zu-Punkt-Verbindungen zuständig (s. [RFC- 1055])

16/24

Windows XP integriert wurde. Es wird hauptsächlich im Ende-zu-Ende-Modell eingesetzt, kann aber auch im Provider-Enterprise-Modell verwendet werden. Die Tunnelenden bilden der PPTP-Network-Server (PNS) und der PPTP-Access-Concentrator (PAC), er bezeichnet den Client bzw. den POP eines ISPs. Ähnlich wie bei L2TP benutzt PPTP zwei separate Verbindungen, eine Steuerungs- und eine Tunnelverbindung. Im Gegensatz zu L2TP verlaufen diese jedoch getrennt. Die Steuerungs-verbindung verläuft über TCP. Dadurch ist sie im Provider-Enterprise-Modell sehr anfällig für Angriffe. Die PPP-Pakete werden in einer vereinfachten Form des Generic-Routing-Encapsulation-Protokoll der Version 2 (GRE V2)4 gekapselt. Dieses lässt nur IP als Übertragungsprotokoll zu. Vorteilhaft ist jedoch, dass die Datenpakete verschlüsselt werden können. Mittels der Microsoft Point-to-Point-Encryption (MPPE) werden die PPP-Pakete mit dem RC4-Algorithmus chiffriert. Oftmals in die Kritik geraten ist der Schlüssel, der zwar in den neueren Version 128 Bit anstatt nur 40 Bit lang ist, allerdings während der Authentifizierung mit MS-CHAP5 ausgetauscht wird, das den Schlüssel aus einem Hashwert des Benutzerpasswort be-rechnet. Mit Wöterbuchangriffen oder Brute-Force-Angriffen auf das Benutzerpasswort kann der Schlüssel relativ schnell ermittelt werden. Auch die neue Version MS-CHAPv2 weist er-hebliche Sicherheitsmängel auf. 4.1.3 Layer-2-Forwarding (L2F) Wie bereits oben erwähnt, besitzt das Layer-2-Forwarding-Protokoll die größere Ähnlichkeit mit L2TP. Es unterstützt im Gegensatz zu PPTP ebenfalls mehrere Tunnel und lässt sich über verschiedene Infrastrukturen übertragen. Eine Besonderheit gegenüber beiden Protokollen ist, dass anstelle von PPP auch das SLIP-Protokoll6 unterstützt wird. Dieses war ursprünglich in der Unix-Welt sehr verbreitet, wird aber heute durch PPP vom Markt verdrängt. Ähnlich wie L2TP verfügt L2F über keine Maßnahmen zur Sicherung der Datenübertragung. Es werden lediglich die Tunnelenden authentifiziert. Eine Paketauthentifizierung und ein ge-eignetes Schlüsselmanagement sind genau wie bei den anderen Protokollen nicht vorgesehen. Hier müssen wieder andere Verfahren wie IPSec für eine sichere Verbindung herangezogen werden. L2F wurde hauptsächlich für den Einsatz im Provider-Enterprise-Modell entwickelt. Soft-wareimplementierungen sind daher sehr selten vorzufinden. L2TP-Router oder VPN-Konzentratoren mit L2TP-Funktionalität unterstützen jedoch oftmals auch L2F. 4.2 Layer-3-Tunneling-Protokolle Bei Layer-3-Tunneling-Protokollen werden die Netzwerkprotokolle direkt gekapselt. Das hat den Vorteil, dass ein geringerer Paket-Overhead entsteht, da die zusätzlichen UDP- und PPP-Header entfallen. Ein erstes Protokoll dieser Ebene ist das GRE-Protokoll. Es wurde im Zu-sammenhand mit dem PPTP-Protokoll bereits angesprochen. Die IETF gab 1994 mit GRE erste Spezifikationen für Tunnelprotokolle heraus (s. [RFC-1701] und [RFC-1702]). Es diente oftmals als Vorbild für andere Protokolle und wird heute wegen seiner geringen Sicherheits-funktionen nur noch selten benutzt. Ein anderes Protokoll auf das jedoch gerade wegen seiner hohen Sicherheit vorwiegend zu-rückgegriffen wird und auch auf der Schicht 3 arbeitet, ist IPSec. Hauptziel von IPSec ist es, wie auch dem Namen schon zu entnehmen ist, den IP-Datenverkehr abzusichern. Das Inter-netprotokoll stellt durch die heutige Kommerzialisierung des Internets und den sich daraus ergebenden Anforderungen an die Kommunikationssicherheit, längst keine ausreichenden

__________________________________________________________________________ 17/24

Sicherheitsfunktionen mehr bereit. Daher sind in das neue Internetprotokoll IPv6 oder wie es vorher bezeichnet wurde Next-Generation-Protocol (IPng) neben einer Unterstützung von QoS unter anderem auch entsprechende Sicherheitsfunktionen, bei denen es sich um IPSec handelt, integriert worden. Durch die langsame Verbreitung von IPv6, das inkompatibel zu IPv4 ist, wurden später als Zwischenlösung wichtige Erweiterungen wie Sicherheit auch auf IPv4 übertragen. Mittlerweile liegen für beide IP-Versionen Spezifikationen der IETF vor. IPSec stellt heute den Sicherheitsstandard für die IP-Kommunikation dar. Das folgende Kapi-tel wird sich näher damit beschäftigen. 4.2.1 IP-Security (IPSec) Das IP-Security-Protokoll wurde 1998 von der IETF in den RFCs [2401] bis [2412] und [2451] als Standard verabschiedet. Damit ermöglicht es eine sichere herstellerübergreifende Kommunikation auf Basis des IP-Protokolls. Darüber hinaus kann es in den drei Tunneling-Modellen Intra-Provider, Provider-Enterprise und Ende-zu-Ende zum Schutz einer VPN-Verbindung eingesetzt werden. Im Gegensatz zu den Layer-2-Tunneling-Verfahren ist mit IPSec nur IP-in-IP-Tunneling möglich. Zu den Hauptsicherheitsfunktionen zählen:

• Schutz der Paketintegrität • Paketauthentifizierung • Paketvertraulichkeit • Anti-Replay

IPSec arbeitet unabhängig von kryptographischen Verfahren, wodurch es neuen Entwicklun-gen im Bereich der Kryptographie offen steht. Auf Grund der Geschwindigkeit werden der-zeit symmetrische Verschlüsselungsverfahren eingesetzt, wie sie in Kapitel 3.1.1 erläutert werden. Ein Schlüsselmanagement für die dafür benötigten Schlüssel besitzt IPSec nicht. Es greift stattdessen auf das Internet-Key-Exchange (IKE)-Protokoll zurück, das für den Verbin-dungsaufbau und die Verteilung der benötigten Schlüssel zuständig ist. IKE ist ein Hybrid aus dem Internet-Security-Association-and-Key-Management-Protocol (ISAKMP), dem Oakley –Key-Determination-Protocol und dem Secure-Key-Exchange-Mechanism (SKEME). Das ISAKMP beschreibt ein Rahmensystem, um so genannte Security-Associations (SAs) auszu-handeln und ist unabhängig von Schlüsselaustausch-, Schlüsselerstellungs- und Authentifizie-rungsverfahren. IKE hingegen definiert eine Implementierung eines Schlüsselaustauschver-fahrens, für das das ISAKMP und die Schlüsselaustauschprotokolle SKEME und Oakley als Grundlage dienten. Es legt fest, wie Sicherheitsassoziazionen ausgehandelt, die Authentifizie-rung durchgeführt und die Schlüssel erstellt werden müssen. ISAKMP und IKE sind in [RFC-2408] und [RFC-2409] standardisiert. Der Nachrichtenaustausch wird nach Spezifikation über UDP-Port 500 vorgenommen. Es sind auch andere Protokolle oder Portnummern möglich, in heutigen Implementierungen wird jedoch überwiegend UDP-Port 500 für ISAKMP-Meldungen benutzt. Welche Verschlüsselungs-, Authentifizierungsverfahren und Schlüssel eine IPSec geschützte Verbindung benutzt, wird in den genannten SAs gespeichert. Nachdem die SAs mit IKE aus-getauscht wurden, speichert IPSec sie in der Security-Association-Database (SAD). Diese arbeitet mit der Security-Policy-Database (SPD) zusammen, die Richtlinien für den IPSec-Verkehr enthält, während in der SAD bzw. in den SAs die Parameter für eine Verbindung genannt werden. Beide arbeiten unidirektional, das heißt, für den ein- und ausgehenden Da-tenverkehr sind unterschiedliche Datenbanken notwendig. Die Einträge der SPD besitzen mehrere Selektoren wie Quell- und Zieladresse oder Transportschichtprotokoll, anhand derer die ein- und ausgehenden Pakete analysiert und entweder verworfen, direkt weiterverarbeitet oder zuerst durch IPSec verarbeitet werden. Im letzteren Fall verfügt ein Eintrag über einen Verweis auf eine SA, die die Parameter für die IPSec-Verarbeitung enthält. Die Verarbeitung

__________________________________________________________________________ 18/24

erfolgt in chronologischer Reihenfolge. Treffen die Selektoren eines Eintrags auf ein Paket zu, so wird der erste Eintrag für den dies gilt, auf das Paket angewandt. Die Einträge müssen da-her mit geeigneten Applikationen zuvor entsprechend konfiguriert werden. Anders sieht es bei der SAD aus, hier spielt die Reihenfolge der Einträge keine Rolle. Jeder SA-Eintrag wird eindeutig durch den Security-Parameter-Index (SPI), der im IPSec-Protokoll-Header gespeichert ist, die Quell- und Zieladresse und das verwendete IPSec-Protokoll (Authentication-Header (AH) oder Encapsulating-Security-Payload (ESP)) identifi-ziert. Ein Eintrag besteht aus mehreren Feldern z.B. der Lebensdauer der SA, die anzeigt, wann eine SA abläuft und ob eine SA beendet oder durch eine neue ersetzt werden soll. Trifft eine SA auf ein eingehendes Paket zu, wird es mit den in den Feldern gespeicherten Parame-tern, die später noch näher erläutert werden, verarbeitet. Ansonsten wird das Paket verworfen. Bei ausgehenden Paketen wird eine neue SA mit dem IKE-Verfahren erzeugt. IPSec definiert zwei Protokolle, das Authentication-Header-Protokoll und das Encapsulating-Security-Payload-Protokoll. Authentication-Header (AH) Das Authentication-Header-Protokoll ist in [RFC-2402] spezifiziert. Zu den Funktionen zäh-len Integritätsüberprüfung, Paketauthentifizierung und Schutz vor Replay-Angriffen. Eine Verschlüsselung der Datenpakete kann mit AH nicht durchgeführt werden. Jedoch wird eine verschlüsselte Prüfsumme in den Header eingefügt, die die Pakete authentifizieren soll. Dies geschieht mit Hilfe der in Kapitel 3.1.4 besprochenen Key-Hashing-Verfahren. Mit ihnen lassen sich Hashwerte errechnen, die keinem anderen Hashwert gleichen, ohne dass der glei-che Schlüssel zur Berechnung verwendet wurde. Abbildung 4.6 zeigt eine Darstellung des Headers.

Abbildung 4.6: Authentication-Header-Format

Next-Header: identifiziert die nächste Nutzlast nach dem AH gemäß [RFC-1700] Payload-Length: enthält die Länge des AH in 32 Bit Werten Reserved: ist für den künftigen Gebrauch reserviert Security-Parameter-Index (SPI): enthält einen 32 Bit Wert zur Identifikation der SA,

zu der das Paket gehört. Die Werte 1 bis 255 sind von der IANA für den künftigen Gebrauch reserviert worden

Sequence-Number: Sequence-Number ist ein 32 Bit Wert, der als fortlaufender Zäh-ler dient. Sie wird benutzt, um ein Replay von Paketen zu verhindern. Laut Spezifika-tion muss auf Senderseite die Anti-Replay-Funktion immer aktiv sein, während sie auf Empfängerseite optional aktiviert werden kann

__________________________________________________________________________ 19/24

Authentication-Data: dieses Feld enthält die Authentifizierungsdaten, die auch mit Integrity-Check-Value (ICV) bezeichnet werden. In IPv4 muss der Wert ein Vielfa-ches von 32, in IPv6 ein Vielfaches von 64 sein

Das Feld Authentication-Data speichert den mit dem Key-Hashing-Verfahren berechneten Wert, der auch als Integrity-Check-Value (ICV) bezeichnet wird. Zur Berechnung wird der gesamte IP-Header und ein geheimer Schlüssel als Eingangswert für eine Hashfunktion wie MD5 oder SHA benutzt. Der dafür verwendete Schlüssel muss zuvor mit einer SA ausge-tauscht werden. Die SA wird für alle weiteren Pakete in der SAD, solange bis sie beendet wird, gespeichert. Felder, die sich auf den Weg zum Ziel verändern, müssen von der Berech-nung ausgenommen werden und werden deswegen auf 0 gesetzt. Darunter fällt z.B. das TTL-Feld. Dieses Feld legt die Lebensdauer eines Pakets fest, wodurch verhindert werden soll, dass sich ein Paket unendlich lang durch ein Netzwerksegment bewegt. Jeder Router, den es passiert, verringert daher den Wert. Am Ziel wäre mit diesen Informationen keine korrekte Prüfsummenberechnung mehr möglich. In IPv6 entspricht diesem Feld das Hop-Limit-Feld. Es gibt noch weitere Felder, auf die hier nicht näher eingegangen werden soll. Wird am Ziel die gleiche Berechnung mit den entsprechenden Eingangswerten vorgenommen, ist erkennbar, ob sich das Paket auf dem Weg von der Quelle zum Ziel verändert hat. Auch kann kein Angreifer zusätzliche Pakete mit gefälschter Absenderadresse an das Ziel schicken, ohne dass dort bemerkt würde, dass die Pakete nicht von der ursprünglichen Quelle stammen. Mittels der Sequence-Number lässt sich zusätzlich ein Wiedereinspielen von Paketen verhin-dern (Anti-Replay). Ein spezielles, 32 Bit langes Zählerfeld in den SAs dient dazu, eine fort-laufende Nummer zu generieren. Es kann auch der Überlauf des Zählers überwacht werden, so dass für eine bestimmte SA weiterer Verkehr nicht mehr möglich ist. Eine Manipulation dieses Feldes würde wiederum bemerkt werden. Für den Transport der Pakete stellt AH zwei verschiedene Modi bereit: den Transport und den Tunnelmodus. Transportmodus: Der Transportmodus wird hauptsächlich dafür eingesetzt, die höheren Pro-tokolle bei der IP-Kommunikation zu schützen. Dies wird z.B. bei der Absicherung einer L2TP-Verbindung mit IPSec angewandt (s. L2TP). Der AH wird hierbei nach dem Options-Feld des IP-Headers und vor dem Transport-Schicht-Protokoll (z.B. TCP oder UDP) einge-fügt. In Abbildung 4.7 ist der Aufbau dargestellt.

Abbildung 4.7: Die Position des AH im Transportmodus Der Transportmodus kann nur im Ende-zu-Ende-Modell eingesetzt werden, da an den End-punkten nach der IPSec-Verarbeitung direkt die Verarbeitung der höheren Protokolle folgt.

__________________________________________________________________________ 20/24

Tunnelmodus: Der Tunnelmodus kann in allen drei Szenarien Intra-Provider, Provider-Enterprise und Ende-zu-Ende benutzt werden. Er wird daher meist zum Aufbau eines VPNs ohne die Zuhilfenahme anderer Tunneling-Protokolle verwendet. Der AH wird im Tunnelmo-dus vor dem ursprünglichen und nach einem neuen IP-Header eingefügt. Der neue IP-Header enthält die Angaben, die zum Versand des Pakets zum Sicherheits-Gateway des Zielnetz-werks erforderlich sind sowie eine Kopie des TOS-Felds des ursprünglichen IP-Headers (s. Kapitel 3.2.1). Abbildung 4.8 zeigt den Aufbau.

Abbildung 4.8: Die Position des AH im Tunnelmodus Der Paket-Overhead ist im Tunnelmodus aufgrund des zusätzlichen IP-Headers höher als im Transportmodus. AH authentifiziert im Tunnelmodus das gesamte Paket einschließlich des neuen IP-Headers. Sowohl im Tunnel- als auch im Transportmodus kann der AH zusammen mit dem in Kapitel 3.2.1 erläutertem DiffServ-Verfahren eingesetzt werden. Das von DiffServ verwendete TOS-Feld wird genau wie das TTL-Feld von der Berechnung des ICVs ausgenommen, sodass eine Neuklassifizierung der Pakete an den DS-Boundary-Nodes nicht das Verwerfen des Pakets zur Folge hätte. Im Tunnelmodus erhalten die neuen IP-Header eine Kopie des ursprünglichen TOS-Feldes. Damit können IP-Pakete auf der Verbindungsstrecke heterogene DiffServ-Domänen mit einer festgelegten QoS durchqueren und im Zielnetzwerk wieder mit dem ursprünglichen Wert des TOS-Feldes weitergeleitet werden, da sich dieser noch im IP-Header des eingekapselten Pa-kets befindet. Probleme mit der Authentifizierung gibt es, wenn sich die beiden Endpunkte einer IPSec-Kommunikation hinter einem NAT-Gateway oder einem Proxy befinden. Die Clients haben in diesem Fall beide private Adressen, die von Routern im Internet nicht geroutet werden können. Wollen beide dennoch miteinander kommunizieren, muss an dem NAT-Gateway oder dem Proxy die private Adresse eines Pakets durch die öffentliche des Gateways oder des Proxys ersetzt und anschließend die Prüfsumme neu berechnet werden. Dadurch stimmt je-doch die ICV des Pakets nicht mehr, da dessen Berechnung vorher stattgefunden hat und am Ziel wird das Paket aus diesem Grund verworfen. Als Lösung für den Tunnelmodus würde sich anbieten, den IPSec-Verkehr von den Clients auf die Gateways bzw. Proxys zu übertragen. Die Berechnung des ICVs würde dann erst nach der Modifizierung des IP-Pakets ausgeführt werden und das Ziel-Gateway wäre in Lage, den ICV zu verifizieren. Anders sieht es bei ESP aus. Dort ergeben sich diese Einschränkungen nicht, weil nicht das ganze Paket authentifiziert wird.

__________________________________________________________________________ 7 ESP ist in [RFC-2406] spezifiziert

21/24

Encapsulating-Security-Payload (ESP) Das Encapsulating-Security-Payload7-Protokoll bietet ergänzend zu den Sicherheitsfunktio-nen von AH einen Vertraulichkeitsschutz. Dazu wird ein Teil des Pakets verschlüsselt. Die Verschlüsselung benutzt symmetrische Verschlüsselungsverfahren wie DES oder AES zur Chiffrierung der Daten. DES ist zur Interoperabilität mit anderen IPSec-Implementierungen in der Spezifikation vorgeschrieben. Andere Algorithmen wie Triple-DES, AES, IDEA oder Blowfish können optional implementiert werden. Es ist anzunehmen, dass neben DES zukünf-tig ein anderes Verfahren z.B. AES in der Spezifikation als notwendiges Verfahren aufgeführt werden wird, da DES mit einem 56 Bit langem Schlüssel heute keine ausreichende Sicherheit mehr gewährleistet. Abbildung 4.9 zeigt eine Darstellung der ESP.

Abbildung 4.9: ESP-Format

Security-Parameter-Index (SPI): enthält einen 32 Bit Wert zur Identifikation der SA, zu der das Paket gehört. Die Werte 1 bis 255 sind von der IANA für den künftigen Gebrauch reserviert worden. Es entspricht dem SPI-Feld des AH

Sequence-Number: Sequence-Number ist ein 32 Bit Wert, der als fortlaufender Zäh-ler dient. Sie wird benutzt, um ein Replay von Paketen zu verhindern. Laut Spezifika-tion muss auf Senderseite die Anti-Replay-Funktion immer aktiv sein, während sie auf Empfängerseite optional aktiviert werden kann. Nach 232 Paketen muss eine neue SA ausgehandelt werden, da Sequenznummern innerhalb einer SA nicht doppelt auftreten dürfen

Payload-Data: Ein Feld variabler Länge, das bei aktiviertem Vertraulichkeitsschutz die verschlüsselten Daten enthält. Wird auf den Vertraulichkeitsschutz verzichtet, werden die Daten hierin unverschlüsselt gespeichert. Bei bestimmten Verschlüsse-lungsverfahren wird den Daten evt. ein Initialization-Vector (IV) vorangestellt. IVs werden bei Block-Verschlüsselern eingesetzt, um unterschiedliche Geheimtexte bei identischen Anfangs-Bytes zu erzeugen

Padding: enthält Fülldaten, die von Blockverschlüsselungsalgorithmen zum Auffüllen der Daten zu einem vollen Block benötigt werden. Auch werden die Fülldaten dafür benutzt, dass die Daten bis zur nächsten 4-Byte-Grenze reichen

Pad-Length: Ein 8 Bit langes Feld, das die Anzahl von Bytes der Fülldaten aus dem vorherigen Feld angibt

Next-Header: identifiziert die nächste Nutzlast nach dem ESP gemäß [RFC-1700] Authentication-Data: Ein Feld variabler Länge, das den ICV enthält. Er ist nur bei

aktivierter ESP-Authentifizierung enthalten

__________________________________________________________________________ 22/24

Genau wie bei AH gibt es für ESP zwei verschiedene Betriebsmodi: den Transportmodus und den Tunnelmodus. Transportmodus: Im Transportmodus werden die Protokolle höherer Ebene von einem Hea-der und einem Trailer umschlossen. Die Verschlüsselung chiffriert alles vom Initialisierungs-vektor (IV) bis zum ESP-Trailer. Ausgenommen sind die Felder SPI und Sequence-Number, die den ESP-Header bilden und das Feld Authentication-Data, das dem Trailer folgt. Anhand dieser Felder identifiziert der Empfänger vor der Entschlüsselung die SA und überprüft, ob das Paket erneut eingespielt (Anti-Replay) wurde und unverändert (Integritätsprüfung) ist. Die Entschlüsselung ist im Vergleich zu den anderen Funktionen sehr rechenaufwendig. Daher werden eintreffende Pakete in der genannten Reihenfolge verarbeitet, was einen gewissen Schutz vor Denial-of-Service (DoS)-Attacken durch Wiedereinspielen von Paketen bietet. Anders als bei dem AH authentifiziert die ESP nur die Felder vom ESP-Header bis zum ESP-Trailer. Der vorangestellte IP-Header bleibt ungesichert. Abbildung 4.10 zeigt die Position der ESP-Header und -Trailer und kennzeichnet die von der Verschlüsselung und Authentifi-zierung eingeschlossenen Bereiche.

Abbildung 4.10: Die Position der ESP im Transportmodus Da ESP den IP-Header von der Verschlüsselung und der Authentifizierung ausnimmt, erliegt ESP nicht den Einschränkungen, die sich bei einer NAT oder einem Proxy ergeben. Zu beach-ten ist allerdings, dass daraus eine geringere Sicherheit auf dem Übertragungsweg vom Sen-der zum Empfänger resultiert. Ein Paket, das nur dem ESP-Schutz unterliegt, lässt keine Ü-berprüfung einer Modifikation des IP-Headers mehr zu. In diesem Fall empfiehlt sich ein zu-sätzlicher Einsatz mit AH, das beliebig mit den ESP-Funktionen kombiniert werden kann. ESP kann dabei mit Verschlüsselung, mit Integritätsprüfung oder mit beiden, jedoch nie ohne eine dieser Funktionen betrieben werden. Wie der AH lässt sich auch die ESP mit DiffServ kombinieren. Da die ESP-Authentifizierung den IP-Header ausnimmt, würde eine Modifikation des TOS-Feldes nicht zum Verwerfen des Pakets am Ziel-Gateway führen. Tunnelmodus: Im Tunnelmodus schließen ESP-Header und ESP-Trailer auch den IP-Header mit ein. Vor dem ESP-Header wird ein neuer IP-Header eingefügt, der die Daten des IPSec-Gateways und eine Kopie des TOS-Feldes des ursprünglichen Headers erhält. Der Tunnelmo-dus ist sicherer als der Transportmodus, da die Verschlüsselung vom ursprünglichen IP-Header bis zum ESP-Trailer angewandt wird. Die Adressen des ursprünglichen und des neuen IP-Header können in diesem Fall verschieden sein, sodass ein Angreifer nicht mehr in der Lage wäre, Quell- und Zieladresse auszuspionieren. Wie im Transportmodus wird der IP-Header vor dem ESP-Header von der Authentifizierung und der Verschlüsselung ausgenom-men. Ansonsten würde ESP denselben Einschränkungen wie AH unterliegen. Findet die IPSec-Verarbeitung bei einer NAT oder einem Proxy auf dem Gateway statt, empfiehlt sich

__________________________________________________________________________ 23/24

auch hier ein kombinierter Einsatz mit AH. Abbildung 4.11 veranschaulicht die Position der ESP im Tunnelmodus und verdeutlicht die Verschlüsselungs- und Authentifizierungsbereiche. Abbildung 4.12 zeigt den zuletzt beschrieben Fall auf, bei dem ESP in Kombination mit AH im Tunnelmodus betrieben wird.

Abbildung 4.11: Die Position der ESP im Tunnelmodus

Abbildung 4.12: Die Position des AH und der ESP Abbildung 4.13 führt noch einmal zum Vergleich die wichtigsten Eigenschaften der beschrie-benen Layer-2- und Layer-3-Tunneling-Protokolle in tabellarischer Form auf.

Eigenschaften L2TP PPTP L2F IPSec Protokolltyp Layer-2 Layer-2 Layer-2 Layer-3 Standardisiert Ja Nein Nein Ja Paketauthentifizierung Nein Nein Nein Ja Schutz der Paketintegrität Nein Nein Nein Ja Benutzerauthentifizierung Ja Ja Ja Ja Datenverschlüsselung Nein Ja Nein Ja Anti-Replay Nein Nein Nein Ja Schlüsselmanagement Nein Nein Nein Ja Multiprotokollfähig Ja Ja Ja Nein QoS-Signalisierung Nein Nein Nein Ja Unterstützung von NAT Ja Ja Ja eingeschränktUnterstützung von Multicast Ja Ja Ja Nein

Abbildung 4.13: Vergleich der wichtigsten Eigenschaften der Tunneling-Protokolle

__________________________________________________________________________ 24/24

5. Zusammenfassung Den Marktanalysen zufolge wird der VPN-Technologie ein großes Wachstum für die nächs-ten Jahre eingeräumt. Mietleitungen wie ATM oder Frame-Relay sind nach wie vor sehr teuer. Die VPN-Technologie stellt eine flexible, skalierbare und kostengünstige Alternative in der Kommunikationstechnologie dar und ist die Antwort auf steigende Anforderungen an Kom-munikationsnetze mit deren Hilfe sich Unternehmen auf den heutigen schnelllebigen Märkten mit immer kürzeren Produktzyklen behaupten müssen. Es stellt sich nicht mehr die Frage, ob ein VPN relevant ist, sondern wie es umgesetzt werden soll. Mit L2TP und IPSec stehen leistungsfähige Technologien für die drei VPN-Typen „Remote-Access“, „Branch-Office“ und „Extranet“ zur Verfügung. Durch die Zusammenarbeit mit IPv6 ist IPSec bereits in die zukünftige Internettechnologie integriert und wird gerade auch mit dem Einzug der IP-Technologie in den Mobilfunk an Bedeutung gewinnen, da dort die Sicherheit auf der Luftschnittstelle eine wichtige Rolle spielen wird. In anderen Bereichen ist noch Entwicklungsarbeit zu leisten. Trotz Standardisierung ergeben sich bei der Interoperabilität von IPSec oftmals Schwierigkeiten. Das liegt unter anderem an der ernormen Komplexität des Standards, die das typische Ergebnis eines Komitees, bei der Entwicklung von IPSec ist. Zudem unterstützt IPSec bisher kein Multicast, dessen Verwen-dung aber in künftigen Anwendungen zunehmen könnte. Auch im Bereich Quality-of-Service haben sich noch nicht vergleichbare Dienste mit geeigneten Management- und Accouting-Funktionen wie bei ATM oder Frame-Relay durchsetzen können.

Literaturverzeichnis [Bal99] Balmer, R., F. Baumgartner, T. Braun, M. Günter, I. Khalil (Hg.):

Virtual Private Network and Quality of Service Management Implementation, 1999, http://www.iam.unibe.ch/~rvs/cati/Deliverables/CATI-IAM-IM-P-002-1.0.pdf, Rev. 2003-02-25

[Böh02] Böhmer, Wolfgang (Hg.): VPN – Virtual private networks, Die reale Welt der virtuellen Netze, München u.a., Hanser, 2002

[Cis03a] Cisco Systems: ROI Calculator, 2003, http://www.cisco.com/global/DE/solutions/ent/avvid_solutions/ tdm_roi_calculator_home.shtml, Rev. 2003-03-16

[Cis03b] Cisco Systems: Wer ist Cisco Systems, 2003, http://www.cisco.com/global/DE/whois_home.shtml, Rev. 2003-02-24

[Cis03c] Cisco Systems: Die Zukunft spricht IP, 2003, http://info.cisco.de/cebit2003/allgemein.htm Rev. 2003-02-24, Rev. 2003-02-24

[Dav02] Davis, Carlton R. (Hg.): IPSec, Tunneling im Internet, Bonn u.a., mitp, 2002

[Det01] Detken, Kai-Oliver, Evren Eren (Hg.): Extranet, VPN-Technik zum Aufbau sicherer Unternehmensnetze, München u.a., Addison-Wesley, 2001

[Gün98] Günter Manuel (Hg.): Virtual private networks over the internet, 1998, http://www.iam.unibe.ch/~mguenter/Reports/vpn.ps.gz, Rev. 2003-02-25

[Inf02] Infonetics Research, Inc.: European VPN Service and Product Expenditures Increase 150% by 2006, User Plans for VPN Products and Service: Infonetics Research, Inc., Europe, 2002, http://www.infonetics.com/resources/pressrelease_vseu_vpn_set.htm, Rev. 2003-03-16

[Lip01] Lipp, Manfred (Hg.): VPN - Virtuelle Private Netzwerke, Aufbau und Sicherheit, München u.a., Addison-Wesley, 2001

[RFC-1055] IETF Network Working Group: A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP, 1988, http://www.ietf.org/rfc/rfc1055.txt?number=1055, Rev. 2003-03-27

[RFC-1661] IETF Network Working Group: The Point-to-Point Protocol (PPP), 1994, http://www.ietf.org/rfc/rfc1661.txt?number=1661, Rev. 2003-03-27

[RFC-1700] IETF Network Working Group: ASSIGNED NUMBERS, 1994, http://www.ietf.org/rfc/rfc1700.txt?number=1700, Rev. 2003-03-27

[RFC-1701] IETF Network Working Group: Generic Routing Encapsulation (GRE), 1994, http://www.ietf.org/rfc/rfc1701.txt?number=1701, Rev. 2003-03-27

[RFC-1702] IETF Network Working Group: Generic Routing Encapsulation over IPv4 networks, 1994, http://www.ietf.org/rfc/rfc1702.txt?number=1702, Rev. 2003-03-27

[RFC-2401] IETF Network Working Group: Security Architecture for the Internet Protocol, 1998, http://www.ietf.org/rfc/rfc2401.txt?number=2401, Rev. 2003-03-27

[RFC-2402] IETF Network Working Group: IP Authentication Header, 1998, http://www.ietf.org/rfc/rfc2402.txt?number=2402, Rev. 2003-03-27

[RFC-2403] IETF Network Working Group: The Use of HMAC-MD5-96 within ESP and AH, 1998, http://www.ietf.org/rfc/rfc2403.txt?number=2403,

Rev. 2003-03-27 [RFC-2404] IETF Network Working Group: The Use of HMAC-SHA-1-96 within

ESP and AH, 1998, http://www.ietf.org/rfc/rfc2404.txt?number=2404, Rev. 2003-03-27

[RFC-2405] IETF Network Working Group: The ESP DES-CBC Cipher Algorithm With Explicit IV, 1998, http://www.ietf.org/rfc/rfc2405.txt?number=2405, Rev. 2003-03-27

[RFC-2406] IETF Network Working Group: IP Encapsulating Security Payload (ESP), 1998, http://www.ietf.org/rfc/rfc2406.txt?number=2406, Rev. 2003-03-27

[RFC-2407] IETF Network Working Group: The Internet IP Security Domain of Interpretation for ISAKMP, 1998, http://www.ietf.org/rfc/rfc2407.txt?number=2407, Rev. 2003-03-27

[RFC-2408] IETF Network Working Group: Internet Security Association and Key Management Protocol (ISAKMP), 1998, http://www.ietf.org/rfc/rfc2408.txt?number=2408, Rev. 2003-03-27

[RFC-2409] IETF Network Working Group: The Internet Key Exchange (IKE), 1998, http://www.ietf.org/rfc/rfc2409.txt?number=2409, Rev. 2003-03-27

[RFC-2410] IETF Network Working Group: The NULL Encryption Algorithm and Its Use With IPsec, 1998, http://www.ietf.org/rfc/rfc2410.txt?number=2410, Rev. 2003-03-27

[RFC-2411] IETF Network Working Group: IP Security Document Roadmap, 1998, http://www.ietf.org/rfc/rfc2411.txt?number=2411, Rev. 2003-03-27

[RFC-2412] IETF Network Working Group: The OAKLEY Key Determination Protocol, 1998, http://www.ietf.org/rfc/rfc2412.txt?number=2412, Rev. 2003-03-27

[RFC-2451] IETF Network Working Group: The ESP CBC-Mode Cipher Algorithms, 1998, http://www.ietf.org/rfc/rfc2451.txt?number=2451, Rev. 2003-03-27

[RFC-2474] IETF Network Working Group: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Header, 1998, http://www.ietf.org/rfc/rfc2474.txt?number=2474, Rev. 2003-03-27

[RFC-2475] IETF Network Working Group: An Architecture for Differentiated Services, 1998, http://www.ietf.org/rfc/rfc2475.txt?number=2475, Rev. 2003-03-27

[RFC-2598] IETF Network Working Group: An Expedited Forwarding PHB, 1999, http://www.ietf.org/rfc/rfc2598.txt?number=2598, Rev. 2003-03-27

[RFC-2661] IETF Network Working Group: Layer Two Tunneling Protocol "L2TP", 1999, http://www.ietf.org/rfc/rfc2661.txt?number=2661, Rev. 2003-03-27

[RFC-3193] IETF Network Working Group: Securing L2TP using IPsec, 2001, http://www.ietf.org/rfc/rfc3193.txt?number=3193, Rev. 2003-03-27

[Sco99] Scott, Charlie, Paul Wolfe und Mike Erwin (Hg.): Virtuelle Private Netzwerke, Köln u.a., O’Reilly, 1999