Virtual Private Network (VPN)

Rheinisch-Westfälische Technische Hochschule Aachen
Lehrstuhl für Informatik IV
Prof. Dr. rer. nat. Otto Spaniol
Virtual Private Network (VPN)
Proseminar: Kommunikationsprotokolle
5
Dominik Schulte
Matrikelnummer: 232503
Betreuung: Tim Seipold
Lehrstuhl für Informatik IV, RWTH Aachen
Inhaltsverzeichnis:
1.
Einleitung in die Thematik
1.1.
1.2.
2.
Was ist ein VPN?
Begriffserläuterungen
VPN-Typen
2.1.
2.2.
2.3.
2.4.
Remote-Access-VPN
Branch-Office-VPN (Intranet)
Extranet-VPN
Tunneling-Modelle
2.4.1.
Intra-Provider-Modell
2.4.2.
Provider-Enterprise-Modell
2.4.3.
Ende-zu-Ende-Modell
3. Anforderungen an VPNs
3.1.
Sicherheit
3.1.1.
Datenvertraulichkeit
3.1.2.
Schlüsselmanagement
3.1.3.
Authentifizierung
3.1.4.
Integrität
3.2.
Quality-of-Service (QoS)
3.2.1.
Differentiated-Services (DiffServ)
4.
VPN-Basistechnologien
4.1.
Layer-2-Tunneling-Protokolle
4.1.1.
Layer-2-Tunneling-Protocol (L2TP)
4.1.2.
Point-to-Point-Tunneling-Protocol (PPTP)
4.1.3.
Layer-2-Forwarding (L2F)
4.2.
Layer-3-Tunneling-Protokolle
4.2.1.
IP-Security (IPSec)
5. Zusammenfassung
1
1
2
3
3
3
4
5
5
5
5
5
6
6
6
7
7
8
8
9
10
10
15
16
16
17
24
1. Einleitung in die Thematik
Mit dem Sprung in die Informationsgesellschaft sehen sich Unternehmen mit neuen Herausforderungen und Gelegenheiten in der Arbeitswelt und den Märkten konfrontiert. Die zunehmende Verflechtung von Unternehmen und die Globalisierung der Märkte lassen eine steigende Informationsdichte aufkommen, wodurch die Forderung nach professionellen Informations- und Kommunikationstechnologien stetig wächst. Die Dezentralisierung von Geschäftsund Produktionsprozessen fordert zudem eine Kooperation einer Vielzahl von Projektteilnehmern an unterschiedlichen Standorten.
Daher bedarf es des Aufbaus von Unternehmensnetze bzw. virtueller Netze, die lokale Netzsegmente an verschiedenen Standorten verbinden. Zur Realisierung dieser Unternehmensnetze werden sich heute unterschiedlichster Technologien bedient. Ein Begriff der im Zusammenhang mit dem Internet immer mehr an Bedeutung gewinnt, ist der des Virtual-PrivateNetwork (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 Tunnelprotokolle und Sicherheitsverfahren bietet. Tunnel bezeichnet dabei eine Technologie, mit der
es möglich ist, logische (virtuelle) Verbindungen zwischen Netzwerken über öffentliche Netze 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 bereitzustellen.
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 Infonetics 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 Dollar 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 weltweit 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 hohen Stellenwert auf dem VPN-Markt, der mittlerweile eine Vielzahl von Anbietern und Produkten 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.
___________________________________________________________________________
1/24
Monatliche Einwählkosten
Remote-Benutzer mit 800 Verbindungen
durchschnittliche Nutzung in
Std./Woche/Arbeitnehmer
800 Nummer Kosten/Minute
Min/Std. * Wochen/Monat (konstant)
Monatliche VPN Kosten
x
3000
10
x
x
$0.08
240
Einwählkosten pro Monat insgesamt: $576,000.00
Einwählbenutzer
insgesamt
ISP Kosten
BroadbandBenutzer (Kabel,
DSL)
ISP Kosten
3500
x $20
$70,000
500
x $50
$25,000
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
B2C
GPRS
GSM
IETF
ISDN
ISP
LAN
OSI-Schichtenmodell
POP
PSTN
Multicast
NAT
RAC
S2M
V.110
V.90
WAN
TTL
Business-to-Business
Business-to-Customer
General Packet Radio Services; eine paketorientierte Technologie
mit der sich IP-Pakete über GSM-Netze übertragen lassen
Global System for Mobile Communication; ein Mobilfunkstandard
der zweiten Generation
Internet Engineering Task Force, eine Internet Standardisierungsorganisation
Integrated Services Digital Network
Internet Service Provider
Local Area Network; lokales Netzwerk
Referenzmodell für Rechnerarchitekturen auf Basis von sieben
Schichten
Point of Presence, Zugangsknoten zum Internet
Public Switched Telephone Network; das weltweite Telefonnetz
IP-Kommunikationsmodus bei dem anstelle eines eine Gruppe von
Empfängern von einem Sender aus adressiert wird
Network Address Translation
Remote Access Concentrator
ISDN-Primärmultiplexanschluss mit 30 B-Kanälen je 64 Kbit/s
Ein Übertragungsverfahren mit Bitratenadaption, das aus den 80er
Jahren, dem Anfangsstadium von ISDN, herrührt
V.90 ist ein Standard (Protokoll) der ITU für die analoge Datenübertragung mit bis zu 56 Kbit/s über Modems
Wide Area Network; Weitverkehrsnetz
Time-to-Live
___________________________________________________________________________
2/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, BranchOffice-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 Unternehmens 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 Concentrator (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 Nutzdatenkanälen und sind bei vielen anzubindenden Clients günstiger als entsprechende ISDNAnschlü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 Einwahlmö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 Verbindungen 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 Verbindungsgebühren senkt. Ein Außendienstarbeiter oder Heimarbeiter braucht sich lediglich
über einen ISP ins Internet einzuwählen und kann anschließend mit speziellen SoftwareClients eine Verbindung zum VPN-Konzentrator herstellen. Es lassen sich beliebige Technologien für die Verbindung zum ISP einsetzen, z.B. Modems, ISDN oder auch DSL und Kabelmodems, sodass auch günstige Breitbandanbindungen beispielsweise für Heimarbeiter zur
Verfügung stehen.
Der VPN-Konzentrator terminiert in diesem Fall nur logische Verbindungen (Tunnel). Protokolle 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 zugegriffen 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 Technologien 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.
___________________________________________________________________________
3/24
Bei Branch-Office-VPNs ergibt sich keines dieser Probleme, da lediglich ein Internetanschluss 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 Einbeziehung von Partnern, Lieferanten und Kunden in das Unternehmensnetz. Diesen wird ein
zeitlich begrenzter und limitierter Zugang zum Unternehmensnetz gewährt. Auch wird normalerweise 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 zeitliche Effizienz der Geschäftsprozesse. Es hilft auf diese Weise, Einsparungen zu erzielen und
bietet somit eine attraktive Kommunikationsplattform für die heutige B2B- und B2CKommunikation. Nachteile, die sich jedoch ergeben, sind Probleme bei der Netzwerkadministration und die schwierige Integration von Anwendungen. Auch ist ein aufwendigerer
Zugriffsschutz nötig, da häufig mehrere Netze von verschiedenen Netzbetreibern zur Verbindungsherstellung miteinbezogen werden müssen. Für das letztere werden in der Regel entsprechend 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)
___________________________________________________________________________
4/24
2.4 Tunneling-Modelle
Zusätzlich zu den genannten Anwendungsfällen wird bei VPN-Verbindungen zwischen Tunneling-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 Verwaltung der Tunnelverbindung zuständig. Dies hat den Vorteil, dass keine zusätzliche Software 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. Gegebenenfalls 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 nutzen 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 Unternehmen 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-
___________________________________________________________________________
5/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 Vorgang, das Zusammenführen von getrennten Netzen zu einem einzigen, als Konvergenz bezeichnet [Cis03b]. Das erfordert natürlich höhere Bandbreiten sowie geringe Verzögerungszeiten. In einem Netz, das nach dem Best-Effort-Prinzip arbeitet, wie das Internet, ist das allerdings nicht ohne weiteres umzusetzen. Es gibt allerdings einige Verfahren zur Gewährleistung 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 werden.
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 geeigneten 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 standardisierte 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 Praxis 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, TunnelingVerfahren einzusetzen (s. Kapitel 2).
3.1.2 Schlüsselmanagement
Symmetrische Verschlüsselungsverfahren benötigen zur Ver- und Entschlüsselung einen gemeinsamen Schlüssel, der bei einer VPN-Verbindung beiden Kommunikationspartnern bekannt sein muss. Dieser kann manuell ausgetauscht werden z.B. per Post oder durch ein Treffen. Wenn es sich allerdings um viele Personen handelt, die sich an weit voneinander entfernten Orten befinden oder gar nicht vorher kennen, ist dies bereits problematisch. Natürlich dürfen die Schlüssel auf keinen Fall über das Internet übertragen werden, denn sonst könnte jemand mitlesen.
___________________________________________________________________________
1
2
Standard des US-amerikanischen National Bureau of Standards (NBS), 1977 verabschiedet
Standard des US-amerikanischen National Institute of Standards and Technology (NIST), 2001 verabschiedet
6/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 bezeichnet. 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 richtige 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 erstgenannte Ü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 Benutzerauthentifizierung. Dies können einfache Passwortverfahren, Verfahren mit Tokenkarten oder auch Verfahren mit digitalen Zertifikaten sein, die auf den zuvor genannten asymmetrischen Verschlüsselungsverfahren basieren. Die Paketauthentifizierungsverfahren greifen aus Gründen
der Geschwindigkeit hautsächlich auf symmetrische Verschlüsselungsverfahren oder so genannte 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 deren Berechnung können Hashfunktionen wie MD5 oder SHA genutzt werden. Der IPSecStandard schreibt unter anderem die Verwendung dieser Funktionen als obligatorische Verfahren 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 genannten 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 erlangt. 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_________________________________________________________________________________________________________________
7/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 gewö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 Videokonferenzen, 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 sicherlich 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 Bandbreite zu und ist dadurch besonders für Multimediaanwendungen aber auch für die Übertragung 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 Zustellung von Paketen verfahren. Das heißt alle Pakete werden gleich behandelt und eine Unterscheidung nach Priorität findet nicht statt. Erreichen mehr Pakete einen Router als er verarbeiten 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ückgegriffen 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 Hardund 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 weiterzuleiten. Der Vorteil dieses Verfahren liegt darin, dass nur geringe Ressourcen bei den Vermittlungssystemen 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 BestEffort-Verfahren behandelt. Im schlimmsten Fall befinden sich alle Pakete in der höchsten
_________________________________________________________________________________________________________________
3
Bezeichnet das Verhältnis von korrekt übertragenen und zerstörten oder verlorenen Datenpaketen
8/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 Praxis 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 PHBDefinition gilt dabei nach [RFC2475] für eine DiffServ-Domäne. Diese bezeichnet ein Netzwerk 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 Klassifizierung 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 Typeof-Service (TOS)-Feld, das von vornherein für zukünftige Entwicklungen Speicherplatz reservieren 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 DSCodepoint ist 000000. Er bezeichnet Pakete, die nach dem Best-Effort-Verfahren weitergeleitet 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 PHBKlassen 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 klassifizieren.
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 Einkapselung der Pakete, die z.B. beim Verlassen des Intranets eines Unternehmens vorgenommen 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 Weiterleitung 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 Kernstück einer VPN-Verbindung. Er dient dazu, Pakete eines Netzwerkprotokolls in neue Pakete
__________________________________________________________________________
9/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 Empfängeradresse verborgen bleiben, wenn der Tunnel nicht direkt von den Client-Systemen ausgeht.
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 umfangreiche 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 Internetverbindungen eines ISP beispielsweise verwenden weltweit fast ausschließlich PPP. Es lassen
sich damit mehrere Protokolle kapseln und über eine serielle Leitung übertragen. Zu den Eigenschaften 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 Protokolle. Es liegen zwar RFCs der IETF für diese Protokolle vor, sie spezifizieren jedoch keinen 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 abwä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.
__________________________________________________________________________
10/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: Steuerungspakete und Datenpakete. Ein Tunnel existiert, sobald eine Steuerungsverbindung hergestellt
wurde. In diesem Tunnel können dann mehrere logische PPP-Verbindungen existieren, unabhängig davon welche Netzwerkprotokolle sie kapseln. Auch sind mehrere Tunnel in einer
Verbindung möglich, die jeweils ihre eigene Steuerungsverbindung besitzen. Anhand entsprechender Felder im L2TP-Header werden die Pakete den Tunneln und PPP-Verbindungen zugeteilt 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 folgendermaß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änzung 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-connectionreply (SCCRQ). Nachdem vom LNS die Nachricht Start-control-connection-connected
(SCCCN) dem LAC mit einer Zero-length-body (ZLB)-Nachricht bestätigt wurde, existiert
__________________________________________________________________________
11/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 Herstellerkennung 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 Authentifizierung 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öglich ist, eine PPP-Verbindung aufzubauen.
Soll umgekehrt eine Session vom LNS aus aufgebaut werden, sendet dieser einen Qutgoingcall-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 Netzwerksteuerungsprotokolle (zur Übertragung von IP, IPX,…) fest (s. [RFC-1661]). Diese Aushandlungen können über den Tunnel direkt zwischen Client und LNS erfolgen. Nach Abschluss dieses Prozesses 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 zwischen LAC und Client beendet wird. Der Tunnel wird mit einer Stop-control-connectionnotification (StopCCN)-Nachricht, die der LAC an den LNS sendet und anschließender ZLBNachricht beendet.
In Abbildung 4.3 ist der Verbindungsaufbau in Form einer Time-Sequence-Chart dargestellt.
Der Sessionaufbau erfolgt vom LAC zum LNS.
__________________________________________________________________________
12/24
Abbildung 4.3: Der L2TP-Verbindungsaufbau
Kapselung
Wie zu erkennen ist, werden mehrere Header gesetzt bevor die eigentlichen Datenpakete folgen. Abbildung 4.4 soll dies für beide Fälle verdeutlichen. Zunächst zum Provider__________________________________________________________________________
13/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 entsprechende L2TP-Header kapseln, die wiederum per PPP und IP/UDP an den RAC gesendet werden.
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 weiterleiten 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 Übertragungsmedium 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 Sicherheitsanforderungen, 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 Anwendungsschicht 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__________________________________________________________________________
14/24
protokoll bietet es jedoch umfangreiche Funktionen zur Absicherung einer IP-Verbindung.
Durch die hauptsächliche Nutzung des Internets als Übertragungsmedium für die L2TPVerbindung können beide Protokolle daraus profitieren. Das Ergebnis ist eine sichere Tunnelverbindung, ü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 Paketaufbau. Im Provider-Enterprise-Modell werden die IP-Pakete zwischen LAC und LNS zusätzlich 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 IPSecPakete 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. Problematisch 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 IPSecVerbindungen. Das ist in der Tat nicht unmöglich, Systeme mit einer entsprechenden Rechenleistung haben allerdings ihren Preis. Hier gilt es abzuwägen, welche Anforderungen ein solches Netz wirklich zu erfüllen hat. Dennoch stellt IPSec in Kombination mit L2TP eine elegante 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
__________________________________________________________________________________________
15/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 Steuerungsverbindung 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-EncapsulationProtokoll 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 RC4Algorithmus 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 MSCHAP5 ausgetauscht wird, das den Schlüssel aus einem Hashwert des Benutzerpasswort berechnet. 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 erhebliche 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 geeignetes 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. Softwareimplementierungen sind daher sehr selten vorzufinden. L2TP-Router oder VPNKonzentratoren 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 PPPHeader entfallen. Ein erstes Protokoll dieser Ebene ist das GRE-Protokoll. Es wurde im Zusammenhand 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 Sicherheitsfunktionen nur noch selten benutzt.
Ein anderes Protokoll auf das jedoch gerade wegen seiner hohen Sicherheit vorwiegend zurü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 Internetprotokoll stellt durch die heutige Kommerzialisierung des Internets und den sich daraus
ergebenden Anforderungen an die Kommunikationssicherheit, längst keine ausreichenden
__________________________________________________________________________
4
GRE ist eine erste Standardisierung für Tunnelverfahren durch die IETF ([RFC-1701], [RFC-1702])
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. [RFC1055])
5
16/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 Kapitel 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 TunnelingModellen Intra-Provider, Provider-Enterprise und Ende-zu-Ende zum Schutz einer VPNVerbindung 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 Entwicklungen im Bereich der Kryptographie offen steht. Auf Grund der Geschwindigkeit werden derzeit 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 Verbindungsaufbau 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) auszuhandeln und ist unabhängig von Schlüsselaustausch-, Schlüsselerstellungs- und Authentifizierungsverfahren. IKE hingegen definiert eine Implementierung eines Schlüsselaustauschverfahrens, für das das ISAKMP und die Schlüsselaustauschprotokolle SKEME und Oakley als
Grundlage dienten. Es legt fest, wie Sicherheitsassoziazionen ausgehandelt, die Authentifizierung durchgeführt und die Schlüssel erstellt werden müssen. ISAKMP und IKE sind in [RFC2408] 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 ISAKMPMeldungen 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 ausgetauscht wurden, speichert IPSec sie in der Security-Association-Database (SAD). Diese
arbeitet mit der Security-Policy-Database (SPD) zusammen, die Richtlinien für den IPSecVerkehr 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 Datenverkehr 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
__________________________________________________________________________
17/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 daher 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 IPSecProtokoll-Header gespeichert ist, die Quell- und Zieladresse und das verwendete IPSecProtokoll (Authentication-Header (AH) oder Encapsulating-Security-Payload (ESP)) identifiziert. 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 Parametern, 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 EncapsulatingSecurity-Payload-Protokoll.
Authentication-Header (AH)
Das Authentication-Header-Protokoll ist in [RFC-2402] spezifiziert. Zu den Funktionen zählen 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 gleiche 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ähler dient. Sie wird benutzt, um ein Replay von Paketen zu verhindern. Laut Spezifikation muss auf Senderseite die Anti-Replay-Funktion immer aktiv sein, während sie auf
Empfängerseite optional aktiviert werden kann
__________________________________________________________________________
18/24
¾ Authentication-Data: dieses Feld enthält die Authentifizierungsdaten, die auch mit
Integrity-Check-Value (ICV) bezeichnet werden. In IPv4 muss der Wert ein Vielfaches 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 ausgetauscht 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 Berechnung ausgenommen werden und werden deswegen auf 0 gesetzt. Darunter fällt z.B. das TTLFeld. 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 verhindern (Anti-Replay). Ein spezielles, 32 Bit langes Zählerfeld in den SAs dient dazu, eine fortlaufende 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 Protokolle 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 OptionsFeld des IP-Headers und vor dem Transport-Schicht-Protokoll (z.B. TCP oder UDP) eingefü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 Endpunkten nach der IPSec-Verarbeitung direkt die Verarbeitung der höheren Protokolle folgt.
__________________________________________________________________________
19/24
Tunnelmodus: Der Tunnelmodus kann in allen drei Szenarien Intra-Provider, ProviderEnterprise 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 Tunnelmodus 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 Zielnetzwerks 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 TOSFeld 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 Pakets befindet.
Probleme mit der Authentifizierung gibt es, wenn sich die beiden Endpunkte einer IPSecKommunikation 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 jedoch 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.
__________________________________________________________________________
20/24
Encapsulating-Security-Payload (ESP)
Das Encapsulating-Security-Payload7-Protokoll bietet ergänzend zu den Sicherheitsfunktionen 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ünftig 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ähler dient. Sie wird benutzt, um ein Replay von Paketen zu verhindern. Laut Spezifikation 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üsselungsverfahren 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
__________________________________________________________________________
7
ESP ist in [RFC-2406] spezifiziert
21/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 Header und einem Trailer umschlossen. Die Verschlüsselung chiffriert alles vom Initialisierungsvektor (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 ESPTrailer. 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 Authentifizierung 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 beachten ist allerdings, dass daraus eine geringere Sicherheit auf dem Übertragungsweg vom Sender 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 zusä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 IPSecGateways und eine Kopie des TOS-Feldes des ursprünglichen Headers erhält. Der Tunnelmodus ist sicherer als der Transportmodus, da die Verschlüsselung vom ursprünglichen IPHeader 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 IPHeader vor dem ESP-Header von der Authentifizierung und der Verschlüsselung ausgenommen. 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
__________________________________________________________________________
22/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 beschriebenen Layer-2- und Layer-3-Tunneling-Protokolle in tabellarischer Form auf.
Eigenschaften
Protokolltyp
Standardisiert
Paketauthentifizierung
Schutz der Paketintegrität
Benutzerauthentifizierung
Datenverschlüsselung
Anti-Replay
Schlüsselmanagement
Multiprotokollfähig
QoS-Signalisierung
Unterstützung von NAT
Unterstützung von Multicast
L2TP
Layer-2
Ja
Nein
Nein
Ja
Nein
Nein
Nein
Ja
Nein
Ja
Ja
PPTP
Layer-2
Nein
Nein
Nein
Ja
Ja
Nein
Nein
Ja
Nein
Ja
Ja
L2F
Layer-2
Nein
Nein
Nein
Ja
Nein
Nein
Nein
Ja
Nein
Ja
Ja
IPSec
Layer-3
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
eingeschränkt
Nein
Abbildung 4.13: Vergleich der wichtigsten Eigenschaften der Tunneling-Protokolle
__________________________________________________________________________
23/24
5. Zusammenfassung
Den Marktanalysen zufolge wird der VPN-Technologie ein großes Wachstum für die nächsten 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 Kommunikationsnetze 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 „RemoteAccess“, „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 Verwendung aber in künftigen Anwendungen zunehmen könnte. Auch im Bereich Quality-of-Service
haben sich noch nicht vergleichbare Dienste mit geeigneten Management- und AccoutingFunktionen wie bei ATM oder Frame-Relay durchsetzen können.
__________________________________________________________________________
24/24
Literaturverzeichnis
[Bal99]
[Böh02]
[Cis03a]
[Cis03b]
[Cis03c]
[Dav02]
[Det01]
[Gün98]
[Inf02]
[Lip01]
[RFC-1055]
[RFC-1661]
[RFC-1700]
[RFC-1701]
[RFC-1702]
[RFC-2401]
[RFC-2402]
[RFC-2403]
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-P002-1.0.pdf, Rev. 2003-02-25
Böhmer, Wolfgang (Hg.): VPN – Virtual private networks, Die reale
Welt der virtuellen Netze, München u.a., Hanser, 2002
Cisco Systems: ROI Calculator, 2003,
http://www.cisco.com/global/DE/solutions/ent/avvid_solutions/
tdm_roi_calculator_home.shtml, Rev. 2003-03-16
Cisco Systems: Wer ist Cisco Systems, 2003,
http://www.cisco.com/global/DE/whois_home.shtml, Rev. 2003-0224
Cisco Systems: Die Zukunft spricht IP, 2003,
http://info.cisco.de/cebit2003/allgemein.htm Rev. 2003-02-24,
Rev. 2003-02-24
Davis, Carlton R. (Hg.): IPSec, Tunneling im Internet, Bonn u.a.,
mitp, 2002
Detken, Kai-Oliver, Evren Eren (Hg.): Extranet, VPN-Technik zum
Aufbau sicherer Unternehmensnetze, München u.a., AddisonWesley, 2001
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
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.ht
m, Rev. 2003-03-16
Lipp, Manfred (Hg.): VPN - Virtuelle Private Netzwerke, Aufbau und
Sicherheit, München u.a., Addison-Wesley, 2001
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
IETF Network Working Group: The Point-to-Point Protocol (PPP),
1994, http://www.ietf.org/rfc/rfc1661.txt?number=1661, Rev.
2003-03-27
IETF Network Working Group: ASSIGNED NUMBERS, 1994,
http://www.ietf.org/rfc/rfc1700.txt?number=1700, Rev. 2003-0327
IETF Network Working Group: Generic Routing Encapsulation (GRE),
1994, http://www.ietf.org/rfc/rfc1701.txt?number=1701, Rev.
2003-03-27
IETF Network Working Group: Generic Routing Encapsulation over
IPv4 networks, 1994,
http://www.ietf.org/rfc/rfc1702.txt?number=1702, Rev. 2003-0327
IETF Network Working Group: Security Architecture for the Internet
Protocol, 1998, http://www.ietf.org/rfc/rfc2401.txt?number=2401,
Rev. 2003-03-27
IETF Network Working Group: IP Authentication Header, 1998,
http://www.ietf.org/rfc/rfc2402.txt?number=2402, Rev. 2003-0327
IETF Network Working Group: The Use of HMAC-MD5-96 within ESP
and AH, 1998, http://www.ietf.org/rfc/rfc2403.txt?number=2403,
[RFC-2404]
[RFC-2405]
[RFC-2406]
[RFC-2407]
[RFC-2408]
[RFC-2409]
[RFC-2410]
[RFC-2411]
[RFC-2412]
[RFC-2451]
[RFC-2474]
[RFC-2475]
[RFC-2598]
[RFC-2661]
[RFC-3193]
[Sco99]
Rev. 2003-03-27
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-0327
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-0327
IETF Network Working Group: IP Encapsulating Security Payload
(ESP), 1998, http://www.ietf.org/rfc/rfc2406.txt?number=2406,
Rev. 2003-03-27
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-0327
IETF Network Working Group: Internet Security Association and Key
Management Protocol (ISAKMP), 1998,
http://www.ietf.org/rfc/rfc2408.txt?number=2408, Rev. 2003-0327
IETF Network Working Group: The Internet Key Exchange (IKE),
1998, http://www.ietf.org/rfc/rfc2409.txt?number=2409, Rev.
2003-03-27
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-0327
IETF Network Working Group: IP Security Document Roadmap,
1998, http://www.ietf.org/rfc/rfc2411.txt?number=2411, Rev.
2003-03-27
IETF Network Working Group: The OAKLEY Key Determination
Protocol, 1998, http://www.ietf.org/rfc/rfc2412.txt?number=2412,
Rev. 2003-03-27
IETF Network Working Group: The ESP CBC-Mode Cipher
Algorithms, 1998,
http://www.ietf.org/rfc/rfc2451.txt?number=2451, Rev. 2003-0327
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-0327
IETF Network Working Group: An Architecture for Differentiated
Services, 1998, http://www.ietf.org/rfc/rfc2475.txt?number=2475,
Rev. 2003-03-27
IETF Network Working Group: An Expedited Forwarding PHB, 1999,
http://www.ietf.org/rfc/rfc2598.txt?number=2598, Rev. 2003-0327
IETF Network Working Group: Layer Two Tunneling Protocol "L2TP",
1999, http://www.ietf.org/rfc/rfc2661.txt?number=2661, Rev.
2003-03-27
IETF Network Working Group: Securing L2TP using IPsec, 2001,
http://www.ietf.org/rfc/rfc3193.txt?number=3193, Rev. 2003-0327
Scott, Charlie, Paul Wolfe und Mike Erwin (Hg.): Virtuelle Private
Netzwerke, Köln u.a., O’Reilly, 1999