Seminar Rechnernetze - Sommersemester 1999

Seminar Rechnernetze - Sommersemester 1999
Schriftliche Ausarbeitung zum Seminarvortrag:
„Virtual Private Networks – Teil 1“
von
Kristian Raič
Virtual Private Networks – Teil 1
Kapitel 1: Einleitung
Die wirtschaftliche Bedeutung von Rechnernetzen nimmt immer mehr zu. Einer großer Anteil
der Kommunikation, sei es innerhalb von Bürogebäuden, zwischen den (möglicherweise
weltweit verteilten) Niederlassungen eines Unternehmens, zwischen dem Unternehmen und
den Kunden oder zwischen Außendienstmitarbeitern und dem Unternehmen, wird über
Computernetzwerke abgewickelt.
Dabei werden in vielen Fällen Daten übertragen, deren Geheimhaltung erwünscht ist, weil
dritte durch Kenntnis dieser Daten dem Unternehmen oder seinen Kunden Schaden zufügen
könnten. Beispielsweise könnte ein Betrüger Interesse an den Kontodaten eines Kunden, der
das Homebanking-Angebot seiner Bank nutzt, haben, oder eine Firma an den Entwürfen des
neusten Produkts eines Mitbewerbers.
Unternehmen, die öffentliche Netze wie das Internet zur internen Kommunikation benutzen,
werden s leicht zu Opfern von Wirtschaftsspionage. Da durch Wirtschaftsspionage erhebliche
Schäden entstehen können, besteht Bedarf nach Lösungen, die die Sicherheit und
Vertraulichkeit des Datenverkehrs sicherstellen.
Nun könnte eine Firma natürlich zwischen ihren Bürogebäuden eigene Standleitungen
verlegen oder anmieten. Dieser Lösungsansatz ist, abgesehen von den sehr hohen Kosten,
praktikabel für das Verbinden von mehreren Firmenstandorten. Für die Kommunikation
zwischen Unternehmen und Kunden oder Unternehmen und Außendienstmitarbeitern ist dies
allerdings keine Lösung, da unter Umständen die ganze Welt mit Leitungen zu versehen wäre.
Ein Ansatz, um dieses Problem zu lösen, sind die sogenannten Virtual Private Networks (bzw.
Virtuelle Private Netzwerke oder kurz VPNs). Der Begriff der „Virtual Private Network“ ist
sehr weit gefaßt. Es gibt keinen festen Standard für VPNs und daher existieren viele
unterschiedliche Möglichkeiten, ein solches Netzwerk aufzubauen. Daher sind auch
zahlreiche Produkte auf dem Markt, die als Virtual Private Network bezeichnet werden.
Alle diese Ansätze haben eine Grundidee, die durch die Worte „Virtual“ und „Private“
ausgedrückt wird, gemeinsam:
Private
Der Begriff „private“ soll in erster Linie ausdrücken, daß das Netzwerk nicht öffentlich ist,
d.h. daß niemand außer den unmittelbar Beteiligten Kenntnisse über den Inhalt der
Kommunikation erlangen kann. Auch das Wissen darüber, daß Kommunikation stattfindet
und wer daran beteiligt ist, soll nicht jedem zugänglich sein.
Oft bedeutet „privat“ auch, daß das Routing- und Adressing-System sich von dem des
zugrundeliegenden öffentlichen Netzwerks unterscheidet. Bei einem auf dem Internet
basierenden Virtuellen Privaten Netzwerk würde das bedeuten, daß die VPN-Adressen von
Rechnern innerhalb des VPNs sich von ihren (Internet-) IP-Adressen unterscheiden. Der
Vorteil dabei ist, daß beim Zusammenschluß mehrerer Netze zu einem VPN das Auftreten
doppelt vorkommende Host-IDs umgangen werden kann.
Virtual
Laut Duden Fremdwörterbuch bedeutet „virtuell“ folgendes:
nicht echt, nicht in Wirklichkeit vorhanden, aber echt erscheinend, dem Auge, den
Sinnen vortäuschend; virtuelle Realität: vom Computer simulierte Wirklichkeit,
2
Virtual Private Networks – Teil 1
künstliche Welt, in die man sich mithilfe der entsprechenden technischen Ausrüstung
scheinbar hineinversetzen kann.
Ein Virtuelles Privates Netzwerk ist also nicht wirklich ein eigenes, zu anderen Netzwerken
völlig disjunktes Netz. Die Abschottung gegenüber anderen Netzen erfolgt vielmehr durch
den Einsatz von Verschlüsselung und/oder Tunneling.
Der Grund dafür, daß nicht „einfach“ ein eigenes Netzwerk aufgebaut wird, sind die Kosten:
Der Preis für die Verlegung einer Datenleitung ist typischerweise sehr hoch, wogegen der
Aufpreis für eine höhere Bandbreite der Leitung relativ gering ist. Daher ist es
wirtschaftlicher, wenige Netzwerke mit hoher Bandbreite aufzubauen, die sich viele
Teilnehmer teilen, als viele Netzwerke mit geringer Bandbreite zu konstruieren, die jeweils
von nur einem Teilnehmer genutzt werden.
Ein solches Netzwerk, dessen Bandbreite sich viele teilen, ist natürlich das Internet, auf dem
auch die meisten VPN Lösungen aufbauen.
Doch auch auf nicht-öffentlichen Netzen ist der Einsatz von VPN-Techniken sinnvoll, da die
bloße Tatsache, daß eine Leitung von sonst niemand zur Kommunikation genutzt wird, nicht
garantiert, daß sich auch niemand Zugang zu der Leitung verschaffen kann. So werden VPNs
auch basierend auf dedizierten Standleitungen oder auch innerhalb von Local Area Networks
(z.B. wenn nur eine Abteilung einer Firma mit geheimen Daten arbeitet) eingesetzt.
Standort A
Standort A
Internet
eigene Leitung
Standort B
Ein nicht-virtuelles privates Netzwerk
gesicherte
Verbindung
Standort B
Ein virtuelles privates Netzwerk
Überblick über diese Ausarbeitung
Nach dieser Einführung in das Thema VPN werden in Kapitel 2 zunächst die verschiedenen Varianten von
VPNs vorgestellt.
Kapitel 3 erläutert das sogenannte „Controlled Route Leaking“, das eine Interessante Alternative ist zu den
meisten anderen VPN-Ansätzen, die mit Verschlüsselung arbeiten.
In Kapitel 4 wird dann das Transport Layer Security Protocol (TLS) vorgestellt, daß einen kommenden Standard
für VPNs bilden könnte.
Kapitel 5 beschreibt schließlich auf ATM basierende Virtual Private Networks.
3
Virtual Private Networks – Teil 1
Kapitel 2: VPN-Varianten
Je nachdem, für welchen Zweck es verwendet werden soll, bietet sich eine andere
Netzwerkschicht als Grundlage für das VPN an. Die dafür in Frage kommenden Schichten
des ISO/OSI-Referenzmodells sind die Anwendungsebene (Ebene 7), die Transportebene
(Ebene 4), die Netzwerkebene (Ebene 3) und die Verbindungsebene (Ebene 2).
Anwendungsebene
(Application Layer)
Transportebene
(Transport Layer)
Netzwerkebene
(Network Layer)
Leitungs- und Sicherungsebene
(Data Link Layer)
Die Ebenen, auf denen VPNs arbeiten
VPNs auf Anwendungsebene
Beruht ein Virtual Private Network auf der Anwendungsebene, so ist es Aufgabe der
eingesetzten Software, die zu übertragenden Daten zu sichern. Dieser Lösungsansatz ist
sinnvoll, wenn das VPN nur für bestimmte Zwecke, wie z.B. den Versand von Email
eingesetzt werden soll. In diesem Fall gibt es die Möglichkeit, die Email durch den Client mit
Verfahren wie PGP (Pretty Good Privacy) , S/MIME (Secure Multipurpose Mail Extensions),
PEM (Privacy Enhanced Mail) oder durch den Mailserver zu verschlüsseln.
Ein anderes Beispiel für VPNs auf Anwendungsebene sind Internet-Shopping (bzw.
Electronic Commerce) Angebote, die SSL (Secure Sockets Layer) benutzen, um die
Kommunikation zwischen Webbrowser und der
Software des Anbieters zu verschlüsseln.
Der Nachteil der von dieser Art von VPNs ist, daß
Sichergestellt werden muß, daß alle Anwender die
richtige Software einsetzen und diese auch richtig
konfiguriert haben. Außerdem sind VPNs auf
Anwendungsebene auf die Verwendungszwecke
beschränkt, für die entsprechende Software
vorhanden ist. Der Aufwand für die Konfiguration
und Installation der Software steigt mit der Zahl
der Aufgaben, für die das VPN verwendet wird.
Anwendungen
Nur bestimme Inhalte (z.B. Email)
werden verschlüsselt
Transport (UDP/TCP)
Arbeitet wie bei unsicheren Netzen
Netzwerk (IP)
Arbeitet wie bei unsicheren Netzen
Verbindung
Arbeitet wie bei unsicheren Netzen
Soll das Virtual Private Network für viele
verschiedene Zwecke eingesetzt werden, wie z.B.
VPN auf Anwendungsebene
Email,
Datenbankanwendungen,
VideoConferencing etc., so ist es sinnvoller, auf
Transportebene, Netzwerkebene oder Verbindungsebene zu arbeiten.
4
Virtual Private Networks – Teil 1
Der Vorteil, wenn auf Anwendungsebene gearbeitet wird, ist, daß keine Änderungen am
Netzwerk, insbesondere an der Konfiguration von Routern und Firewalls, vorgenommen
werden müssen.
VPNs auf Transportebene
Ein VPN, das auf der Transportebene arbeitet, verschlüsselt meist die Protokolle TCP und
UDP. Der Vorteil dieser Vorgehensweise ist, daß die Verschlüsselung völlig Transparent für
darüberliegende Protokolle wie HTTP ist. Deshalb ist weder spezielle „VPN-taugliche“
Client-Software notwendig, noch besteht die Gefahr, daß User durch falsche Bedienung bzw.
Konfiguration der Software das VPN, sei es absichtlich oder unbeabsichtigt, umgehen.
Anwendungen
Keine Verschlüsselung
Transport (UDP/TCP)
Alle TCP- und UDP-Pakete
werden verschlüsselt. ICMP wird
nicht verschlüsselt.
Netzwerk (IP)
Arbeitet wie bei unsicheren Netzen
Verbindung
Arbeitet wie bei unsicheren Netzen
Ein Nachteil ist, daß diese Lösungen nur die
Protokolle TCP und UDP sichern, weshalb
weiterhin ungesicherter Datenverkehr über ICMP
(Internet Control Message Protocol) erfolgen kann.
Außerdem sind Änderungen am Betriebssystem der
ans Netzwerk angeschlossenen Workstations
notwendig, damit die Verschlüsselung von TCP
bzw. UDP funktioniert.
Bisher gab es hierfür keinen Standard, weshalb
bestehende
VPN-Produkte,
die
in
die
Transportebene
eingreifen,
proprietäre
Algorithmen verwenden, und somit nicht zu
Produkten anderer Hersteller kompatibel sind.
Ein kommender Standard für VPNs auf
Transportebene könnte das Transport Layer
Security Protocol (TLS) sein. Im Januar 1999
wurde von der IETF (Internet Engineering Taskforce) im RFC (Request For Comment) 2246
der Entwurf für das Transport Layer Security Protokoll (TLS) in der Version 1.0 vorgelegt.
Dieses Protokoll soll auf der Transportebene basierende Sicherung der Kommunikation zur
Verfügung stellen und insbesondere das Abhören und Manipulieren des Datenverkehrs und
das Fälschen von Nachrichten verhindern. Kapitel 4 geht weiter auf TLS ein.
VPN auf Transportebene
VPNs auf Netzwerkebene
Die meisten VPN-Implementationen auf Basis der Netzwerkebene arbeiten mit
Verschlüsselung. Da der Datenstrom auf der Ebene von IP verschlüsselt wird, ist der
Datenverkehr über alle darüber liegenden Protokolle (HTTP, FTP, TCP, UDP, ICMP usw.)
auch gesichert (Andere Netzwerkprotokolle können natürlich auch verschlüsselt werden; da
IP aber das gängigste ist, wird hier nur darauf eingegangen). Der Standard für
Verschlüsselung von IP ist mittlerweile IPSec. Dieser (noch nicht ganz fertiggestellte)
Standard wurde auch in die kommende Version von IP, IPv6 aufgenommen.
Die Vorteile von IPSec sind die Standardisierung und damit die Kompatibilität zwischen
verschiedenen Implementierungen und die Tatsache, daß die Verschlüsselung vollkommen
transparent ist und keiner zusätzlichen Konfiguration oder Installation von Software beim
Anwender Bedarf. Ein Nachteil ist aber, daß bestehende Router und Firewalls umgestellt
werden müssen, da mit IPSec neue Protokoll-IDs eingeführt werden, die von alten Geräten
nicht „verstanden“ werden.
5
Virtual Private Networks – Teil 1
Ein anderer Ansatz, um Virtual Private Networks
auf Netzwerkprotokoll-Ebene zu realisieren, ist das
sogenannte „Controlled Route Leaking“. Dieses
Verfahren, daß ganz ohne Verschlüsselung
auskommt, wird in Kapitel 3 ausführlich vorgestellt.
Anwendungen
Keine Verschlüsselung
Transport (UDP/TCP)
Keine Verschlüsselung
Netzwerk (IP)
Verschlüsselt entweder alle IPPakete, oder strukturiert das Netz
(z.B. mit Controlled Route
Leaking)
Verbindung
Arbeitet wie bei unsicheren Netzen
VPN auf Netzwerkebene
VPNs auf Verbindungsebene
VPNs, die in die Verbindungsebene eingreifen, basieren meist auf Tunneling. Die Protokolle,
die hierfür eingesetzt werden, heißen L2TP (Layer 2 Tunneling Protocol), PPTP (Point to
Point Tunneling Protocol) und L2F (Layer 2 Forwarding). Dabei ist L2TP das Ergebnis der
Verschmelzung von PPTP von Microsoft und L2F
von Cisco unter Mitwirkung von Ascend und
Anwendungen
3Com, wobei die beiden älteren Protokolle auch
Keine Verschlüsselung
noch eingesetzt werden.
Transport (UDP/TCP)
Keine Verschlüsselung
Netzwerk (IP)
Keine Verschlüsselung
Verbindung
Durch Tunneling werden Punkt zu
Punkt Verbindungen zwischen den
beteiligten Rechnern aufgebaut
VPN auf Verbindungsebene
Beim Tunneling werden im Router am
Ausgangspunkt der Daten die Pakete aller
Protokolle in Pakete des Tunneling-Protokolls
„gepackt“, und im Router am Zielpunkt der Daten
wieder „ausgepackt“. Der Vorteil dabei ist, daß
Tunneling
mit
allen
Netzwerkprotokollen
funktioniert (neben TCP/IP also auch IPX,
NetBEUI, AppleTalk usw.)
Eine andere Möglichkeit ist, ATM zu verwenden,
um Punkt-zu-Punkt-Verbindungen
aufzubauen.
Wie dies funktioniert, wird in Kapitel 5
beschrieben.
Andere Unterscheidungsmerkmale von Virtual Private Networks
Neben der Ebene des OSI-Modells, auf der das VPN basiert, stellt die Struktur des Virtual
Private Network ein weiters Unterscheidungsmerkmal dar. Die drei Typen von VPNs sind
dabei End-to-End, Site-to-Site und Site-to-End.
End to End
Ein End to End VPN besteht aus zwei oder mehr Rechnern, zwischen denen der Datenverkehr
verschlüsselt wird. Da die Verschlüsselung auf diesen Rechnern erfolgt, müssen dort auch die
VPN-Produkte installiert sein.
End to End VPNs arbeiten also entweder auf der Anwendungs- oder Transportebene.
6
Virtual Private Networks – Teil 1
Ein End to End Virtual Private Network kann beispielsweise aus dem Rechner eines
Bankkunden und dem Rechner der Bank bestehen. Die Kommunikation zwischen beiden
Rechnern könnte dabei auf Anwendungsebene (durch eine spezielle Homebanking-Software)
erfolgen.
verschlüsselte Leitung
Ein Site to Site Virtual Private Network
Site to Site
Bei einem Site to Site VPN wird der gesamte Datenverkehr zwischen kompletten Netzwerken
gesichert. Dies geschieht dabei am sinnvollsten auf der Netzwerkebene.
Diese Art von VPN ist typisch, wenn zwei Standorte einer Firma miteinander verbunden
werden sollen. Dabei wird an jedem Standort ein VPN-Gateway installiert, mit dem alle
Rechner des jeweiligen Standortes verbunden sind.
verschlüsselte Leitung
Gateway 1
Gateway 2
Standort 1
Standort 2
Ein Site to Site Virtual Private Network
Site to End
Bei einem Site to End VPN ist ein einzelner Rechner über eine gesicherte Leitung mit einen
gesamten Netzwerk verbunden.
Das typische Szenario für ein Site to End VPN ist, daß der Rechner eines
Außendienstmitarbeiters mit dem Netzwerk seiner Firma verbunden ist. Hierbei macht es
Sinn, Tunneling zu verwenden, so daß der Mitarbeiter sich mit seinem Notebook eine
7
Virtual Private Networks – Teil 1
Verbindung zum Internet aufbaut, und die Daten dann durch den „Tunnel“ zur Firma und
zurück gelangen. Das Tunneling erfolgt dabei wahlweise auf dem Rechner des
Außendienstmitarbeiters oder bei dem Internet Service Provider, über den er sich der Zugang
zum Internet verschafft hat.
Tunneling
Tunneling
ISP ohne VPN Service
Notebook des
Außendienstmitarbeiters
Internet
VPN Gateway
Netzwerk der Firma
ISP mit VPN Service
kein Tunneling
Tunneling
Zwei Beispiele für End to Site Virtual Private Networks
Peer to Peer und Overlay Virtual Private Networks
Außerdem werden Virtuelle Private Netzwerke entweder dem Peer-to-Peer- oder dem
Overlay-Modell zugeteilt.
Im Peer-to-Peer Modell erfolgt die Berechnung des Pfades, den die Datenpakete nehmen, von
Hop zu Hop. Dabei stellt jeder Hop ein „Peer“ (Gleichgestellten) des nächsten Hops dar. Ein
Beispiel für das Peer to Peer Modell sind die „traditionell“ gerouteten Netze, bei denen
Router, die jeweils einen Hop voneinander entfernt sind als adjazent betrachtet werden.
Beim Overlay-Modell werden auf dem Link-Layer basierend direkte Verbindungen
hergestellt, so daß die Stationen im Netz jeweils einen Hop der Verbindungsebene
voneinander entfernt sind. Beispiele für Overlay-Nezte sind ATM, Frame Relay und
Tunneling.
Skalierbarkeit
Beim Overlay-Modell kommt es zu Problemen, wenn viele „Peers“ vorhanden sind. Da alle nur einen Layer-3Hop voneinander entfernt sein sollen, müssen sehr viele einzelne Verbindungen aufgebaut werden.
8
Virtual Private Networks – Teil 1
Router
Switch
Ein Overlay-Netzwerk
Die Router sind jeweils einen Hop
voneinander entfernt, da die Switches
direkte Verbindungen herstellen.
Ein Peer-to-Peer Netzwerk
Die Router sind jeweils mit einen
anderen Router adjazent. Die
Entfernung von einem zum anderen
kann aber mehr als ein Hop sein.
9
Virtual Private Networks – Teil 1
Kapitel 3: Controlled Route Leaking
In diesem Kapitel wird das sogenannte Controlled Route Leaking (wird oft auch als Route
Filtering bezeichnet) vorgestellt. Dieses Verfahren ist eine interessante Alternative zu den
meisten anderen Arten, ein Virtual Private Network aufzubauen, da es auf Verschlüsselung
verzichtet und statt dessen das Netz umstrukturiert. Controlled Route Leaking arbeitet also
auf der Netzwerkebene.
Controlled Route Leaking verwendet keine Verschlüsselung, sondern setzt auf kontrollierte
Verbreitung von Routing-Informationen, so daß nur bestimmte Netzwerke eine Route zu
bestimmten anderen Netzwerken erhalten können. Die so gebildeten VPNs werden auch als
„Community of Interest“ bezeichnet.
Beim Controlled Route Leaking kann man von einem Peer to Peer Modell sprechen, da die
Pakete von einem Router zum nächsten weitergegeben werden, und keine
Direktverbindungen bestehen.
Im Internet ist es üblich eine Route von einem Netz zum anderen über beliebige anderen
Netze gehen kann. Beim Controlled Route Leaking wird aber sichergestellt, daß die Route nur
über bestimmte andere Netze verläuft. Die Routing-Informationen werden so gefiltert, daß
nur die zum VPN gehörenden Netze Kenntnis über Routen zu anderen Netzen des selben
VPN haben können.
a
b
Router
c
Netzwerk
d
e
Ein Virtual Private Network auf Basis von Controlled Route Leaking
Die eingerahmten Netze bilden das VPN. In den Routern b, d und e werden die Routen so gefiltert, daß
die Teilnetze des VPN nur Routen zu den anderen Teilnetzen des VPN erhalten.
Das Netzwerk wird dadurch „privat“, daß kein Rechner innerhalb des VPN auf Pakete, die
von außerhalb des VPN stammen, antworten kann, weil er keine Route zu einem Rechner, der
nicht Teil des VPN ist, erhält.
Diese Vorgehensweise ist anfällig für Fehlkonfigurationen. Besonders wenn das VPN nicht
vom ISP des zugrundeliegenden Netzwerks, sondern vom Kunden selbst konfiguriert wird,
treten oft Fehler auf, durch die Pakete doch nach außen gelangen können.
10
Virtual Private Networks – Teil 1
Beim Controlled Route Leaking wird vorausgesetzt, daß alle Netze, die auf der gemeinsamen
Netzstruktur aufbauen, auch ein gemeinsames Routing-System haben. Das bedeutet, daß
keine Adresse in mehreren Netzen, insbesondere nicht in mehreren VPNs, gleichzeitig
auftreten darf, da es sonst zu Kollisionen kommen würde.
Soll ein VPN Daten mit anderen Netzen austauschen können, wird ein Austauschpunkt
benötigt, zu dem alle Pakete geroutet werden, die nach Außen gerichtet sind, oder die von
Außen in das VPN gesendet werden. Die Pakete werden an diesem Austauschpunkt darauf
geprüft, ob sie passieren dürfen, und dann entweder verworfen oder weitergeleitet. Um den
Austausch mit anderen Netzen zu ermöglichen, wird Network Address Translation benötigt.
Bei der Network Address Translation werden externe Adressen in interne übersetzt und
umgekehrt.
Obwohl Controlled Route Leaking eine sehr interessante Alternative zu den anderen VPNLösungen ist, und ein ganz anderes Konzept darstellt, muß leider gesagt werden, daß es
relativ schwierig zu administrieren, inflexibel und auch relativ unsicher ist. Trotz des Filtern
der Routen kann es vorkommen, daß mehrere Virtual Private Networks sich die gleichen
physikalischen Leitungen teilen. Zudem ist der Aufwand für diesen Lösungsweg recht hoch,
was besonders zutrifft, wenn viele VPN auf der selben Netzinfrastruktur erstellt werden
sollen.
Eine besserer Ansatz, der nach dem gleichen Prinzip funktioniert ist das Border Gateway
Protocol, daß weniger anfällig für fehlerhaft Konfiguration und besser skalierbar als das
Controlled Route Leaking ist.
Doch genauso wie das Controlled Route Leaking hat das Border Gateway Protocol den
Nachteil, daß Datenverkehr von mehreren VPNs unverschlüsselt über die selben
physikalischen Leitungen geht und daher nicht wirklich geschützt ist. Durch den Gebrauch
von Verschlüsselung, wie z.B. beim Transport Layer Security Protocol (TLS), kann
wesentlich höhere Sicherheit erreicht werden.
11
Virtual Private Networks – Teil 1
Kapitel 4: Transport Layer Security (TLS)
Das Transport Layer Security Protocol basiert auf dem Secure Sockets Layer Protocol (SSL),
daß von Netscape entwickelt wurde, und der Private Communication Technology von
Microsoft. Im RFC 2246 vom Januar wurde von der IETF der Entwurf von TLS 1.0
vorgelegt. TLS dürfte in Zukunft ein sehr wichtiger Standard für Virtual Private Networks auf
Ebenen der Transportschicht werden. Dafür spricht allein schon die Tatsache, daß Microsoft
und Netscape, die zusammen einen Marktanteil von über 90% bei Webbrowsern haben,
diesen Standard in Zukunft unterstützen wollen.
Da TLS innerhalb des Transport-Layer arbeitet, werden TCP und alle darüber liegenden
Protokolle, wie z.B. HTTP verschlüsselt.
Durch die Tatsache, daß TLS auf dem schon recht weit verbreiteten SSL basiert, ist
gewährleistet, daß die Kosten für die Umstellung auf dieses neue Protokoll relativ gering sind.
Daher ist auch zu erwarten, daß TLS breite Unterstützung in der Industrie finden wird. Es
kommen weder neue Hardwareanforderungen noch Änderungen in der Infrastruktur hinzu.
Gerade dies ist ein Vorteil von VPNs auf Transportebene. Die Kosten für Virtual Private
Networks auf Anwendungsebene oder auf Netzwerkebene dürften deutlich höher ausfallen, da
im ersten Fall der Entwicklungsaufwand für neue Software höher ist, und im letzteren Fall
Änderungen an der Netzinfrastruktur notwendig sind.
Das TLS-Modell
Das TLS-Protokoll läßt sich in zwei Teilprotokolle unterteilen: Das TLS Handshake Protocol
und das TLS Record Protocol.
TLS Handshake Protokoll
Das TLS Handshake-Protokoll besteht wiederum aus drei Subprotokollen: Handshake,
ChangeCipherSpec und Alert.
Das Handshake-Protokoll ist für das „Negotiating“ zuständig. Dabei werden folgende
Parameter vereinbart:

Session Identifier: Eine vom Server erzeugte, beliebige Bytefolge, mit der die Session
identifiziert wird.

Peer Certificate: Ein Zertifikat nach dem X509-Standard, anhand dessen der Client oder
der Server identifiziert werden. Die Verwendung eines Peer Certificates ist nicht zwingen
vorgeschrieben.

Compression Method: Gibt den Algorithmus an, mit dem die Daten (vor der
Verschlüsselung) komprimiert werden sollen.

Cipher Spec: Gibt den Algorithmus an, mit dem die Daten verschlüsselt werden sollen.

Master Secret: Eine 48-Bit Zahl, die den Schlüssel für die symmetrische Verschlüsselung
zwischen Server und Client darstellt.

Is Resumable: Ein Flag, das angibt, ob die Session verwendet werden kann, um neue
Sessions zu starten.
Das ChangeCipherSpec-Protokoll wird benötigt, um dem Server und dem Client mitzuteilen,
daß die Verschlüsselungsstrategie gewechselt werden soll. Es besteht nur aus einer einzigen
12
Virtual Private Networks – Teil 1
Nachricht, die aus nur einem Byte besteht. Das ChangeCipherSpec-Protokoll wird während
des Handshake eingesetzt, nachdem die Parameter für die Session vereinbart wurden.
Das Alert-Protokoll wird verwendet, um während der Übertragung auftretende Fehler
anzuzeigen. Je nach schwere des Fehlers und der Sicherheitsrelevanz wird die Session nach
dem Erhalt einer Alert-Message sofort unterbrochen.
Ablauf des Handshake
Zuerst werden sogenannte „Hello Messages“ ausgetauscht: hierbei werden die Kompressionsund Verschlüsselungsalgorithmen vereinbart und Zufallszahlen ausgetauscht. Danach wird
ein „premaster Secret“ vereinbart. Dieser wird dann, nachdem sich beide Seiten mit
Zertifikaten identifiziert haben, benutzt, um den „Master Secret“ zu vereinbaren. Danach
werden Parameter für das Record-Protocol bestimmt. Abschließend prüfen dann beide Seiten,
ob der Handshake erfolgreich war, und ohne Einmischung dritter abgelaufen ist.
TLS Record-Protokoll
Das TLS Record-Protokoll sorgt für den Transport der Daten bzw. „Records“, für die
symmetrische Verschlüsselung der Daten und für die Authentifikation.
Die Authentizität der Empfangenen Nachrichten wird anhand von Hash-Codes, die beim
Versenden durch die Hash-Funktionen HMAC-MD5 und HMAC-SHA, unter Verwendung
des „Secrets“, berechnet werden. Wird die Message auf dem Weg zum Empfänger verändert,
so ändert sich mit sehr hoher Wahrscheinlichkeit auch der Wert des korrekten Hash-Codes.
Rechnet der Empfänger den Code nach, kann er recht sicher bestimmen, ob die Daten
verfälscht wurden.
Messages werden immer komprimiert, der Algorithmus, mit komprimiert wird, wenn nicht
explizit ein Algorithmus vereinbart wurde, ist aber als „CompressionMethod.null“, also keine
Kompression, definiert.
Das TLS-Message-Format
Das Record-Protocol gliedert alle Messages in vier Felder:
Content Type
der Verwendungszweck der Message
Protocol Version
die Version des Protokolls
Lenght
Länge des Records in Byte
Opaque Fragment
der eigentliche Inhalt der Message
Ein wichtiger Bestandteil des Record-Protokolls sind die „Connection State Information“. Hier werden folgende
Informationen verwaltet:
13
Virtual Private Networks – Teil 1




Compression State: Der verwendete Kompressionsalgorithmus und Zustand der Kompression
Cipher State: Der verwendete Verschlüsselungsalgorithmus, der Schlüssel etc.
MAC-Secret: Die Geheimzahl, die zur Überprüfung der Authentizität von Nachrichten verwendet wird.
Sequence Number: Eine Zahl (< 264-1), die inkrementiert wird, wenn ein Record gesendet oder empfangen
wird.
Verarbeitung von Records
Unkomprimierte Records dürfen nicht die Länge von 214 überschreiten. Records, die länger
sind, werden in mehrere Records unterteilt. Es können auch mehrere kleine Records vom
gleichen Typ zu einem Record verschmolzen werden. Die so erzeugten Records werden
anschließen komprimiert. Die maximale erlaubt Länge von komprimierten Records ist 214 +
1024 Bytes. Falls diese Länge überschritten wird, wird ein „fatal Error“ (ein Fehler, der zum
Beenden der Session führt) gemeldet. Nach der anschließenden Verschlüsselung ist die größte
erlaubte Länge für die Records 214 + 2048. Auf die Verschlüsselung folgt die Berechnung der
MAC-Prüfsumme. Nach diesen Schritten wird ein Record verschickt und die
Verarbeitungsschritte werden beim Empfänger in umgekehrter Reihenfolge wiederholt.
TLS vs. IPSec
Da ein Teil des Handshake verläuft ungesichert. An dieser Stelle könnte IPSec eingesetzt
werden, um noch höhere Sicherheit zu gewährleisten.
Ansonsten unterscheidet TLS und IPSec, Neben der Tatsache, daß TLS auf der
Transportebene arbeitet während IPSec in die Netzwerkebene eingreift, vor allem, daß IPSec
nur unidirektionale Verbindungen zur Verfügung stellt, während TLS-Verbindungen
bidirektional sind.
14
Virtual Private Networks – Teil 1
Kapitel 5: ATM-basierte Virtual Private Networks
Außer den bereits vorgestellten Varianten für Virtual Private Networks gibt es noch die
Möglichkeit, auf der Basis von ATM (Asynchronous Transfer Mode) zu arbeiten. ATM
kommt besonders deshalb in Frage, weil es Unterstützung für „Quality of Service“ (d.h. die
Garantie von Bandbreite, Verzögerungszeiten usw.) bietet. Außerdem unterstützt ATM die
Übertragung von Audio- und Videoinhalten, so daß „Multimedia VPNs“ aufgebaut werden
können, die Dienste wie sicheres Videoconferencing anbieten.
Bei VPNs auf ATM-Basis werden zwei Fälle unterschieden:
Im ersten Fall basiert das gesamte Netzwerk, bis hin zu den Endgeräten, auf ATM-Technik.
Im zweiten Fall wird ATM, ähnlich wie andere Protokolle der Verbindungsebene (z.B.
Ethernet, Token Ring, usw.) nur als Trägerdienst für Protokolle, die höheren Schichten
angehören, genutzt. Ein Beispiel für so ein Protokoll ist IP. In diesem Fall wird von „IP over
ATM gesprochen“. Die Kapselung von anderen Protokollen in ATM hat zum Ergebnis, daß
„virtuelle Verbindung“ zwischen 2 Routern entstehen. Die Entfernung zwischen den beiden
Routern beträgt dann nur einen Hop. Vorgehensweisen wie „IP over ATM“ haben der Vorteil,
daß die höheren Protokolle auch in den Genuß von „Quality of Service“ kommen.
Virtual Channel und Virtual Path
Im Zusammenhang mit Virtual Private Networks sind besonders die Felder „Virtual Channel
Identifier“ (VCI) und „Virtual Path Identifier“ (VPI) von Bedeutung. (Zur Erinnerung: ATMZellen sind 53 Byte lang; der Header hat eine Länge von 5 Byte).
Der Virtual Channel stellt bei ATM die kleinste logische Einheit, die zugeteilt werden kann,
dar. Ein Virtual Path ist im Prinzip ein Bündel von mehreren Virtual Channels. Weiterhin
können mehrere Virtual Paths zu einer Virtual Path Group (VPG) zusammengefaßt werden.
Virtual Channel
Virtual Path
Virtual Path Group
Zuteilung von Ressourcen
Bei dieser Zuteilung von VCs und VPs kommt es zu der Frage, wer die Verantwortung für die
Garantie von bestimmten Servicemerkmalen (Quality of Service) ist. Dabei ergeben sich dir
folgenden Möglichkeiten:
1. Der Provider ist verantwortlich für die Quality of Service.
2. Der Kunde muß sich selbst um die Quality of Service kümmern.
3. Der Kunde und der Provider einigen sich je nach Bedarf auf bestimmte
Leistungsmerkmale.
15
Virtual Private Networks – Teil 1
Am sinnvollsten ist dabei die Möglichkeit 2. Da die Qualitätsanforderungen des Kunden
variieren, kann er je nach Bedarf neue Verbindungen erzeugen. Außerdem kann der Kunde in
Situationen in denen die Gesamtbandbreite des Netzes nicht ausreicht, selbst bestimmen,
welche Anwendungen wichtiger sind, und die Daten der unwichtigeren Anwendungen
verwerfen.
Die Zuteilung der Ressourcen läuft dabei wie folgt ab:
Bei kurzfristigem Bedarf nach Bandbreite fordert der Kunde bei seinem Provider einen
Virtual Channel an, dessen Qualitätsmerkmale festgelegt werden. Benötigt der Kunde aber
langfristig mehrere Virtual Channels, erhält er einen Virtual Path vom Provider, für den die
Qualitätsmerkmale dauerhaft festgelegt werden. Innerhalb dieses Virtual Path kann der Kunde
dann selbständig Virtual Channels anlegen. Eine weitere Option bildet das zuteilen von
Virtual Path Groups.
Verwaltung
Der Preis für diese hohe Flexibilität ist aber ein erhöhter Verwaltungsaufwand. Die
Verwaltung läuft wie folgt ab:
Die sogenannten Controller sind verantwortlich für die Vergabe der Ressourcen. Bei ihnen
fordern die Anwendungen die benötigten Ressourcen an. Benötigt eine Anwendung z.B. einen
Virtual Channel, wendet sie sich an den Call-Controller.
Die Controller fragen wiederum beim Controller den nächsthöheren Ebene an. Der CallController wendet sich beispielsweise an den VPG-Controller.
Wenn ein Controller feststellt, daß der darunterliegende Controller an Grenzen seiner
Kapazität erreicht hat. Versucht er selbständig mehr Bandbreite für ihn zu erreichen.
Auf der obersten Ebene dieser Hierarchie würde der Controller dann beim Provider mehr
Bandbreite anfordern. Dieser Schritt läuft aber in den meisten Fällen nicht vollkommen
automatisch ab, da dem Kunden dadurch höhere Kosten entstehen.
VPN-Controller
ATM-Controller
Anfrage nach VPGKapazität
VPG-Controller
Anfrage nach VPKapazität
Call-Controller
Anfrage nach VCKapazität
Anwendung
Kunde
Provider
16
Virtual Private Networks – Teil 1
Verschlüsselung der Ebene von ATM
Damit ein ATM-Netzwerk auch ein Virtual Private Networks ist, bedarf es Verschlüsselung.
Zur Zeit existieren noch keine Standards für Verschlüsselung von ATM. Es existieren aber
schon einiger Ansätze, um verschlüsseltes ATM zu realisieren. Dabei ergeben sich folgenden
beiden Alternativen:
Verschlüsselung auf Ebene des Cellstream (Zellenstrom)
Bei der Verschlüsselung auf Ebene des „Cellstreams“ wird der gesamte Zellenstrom, der
durch das ATM-Netzwerk fließt, verschlüsselt.
Dabei wird noch danach unterschieden, ob die ganzen ATM-Zellen oder nur der „Payload“
(d.h. alles bis auf den Header) verschlüsselt wird. Aufgrund der Tatsache, daß verschlüsselte
Header in jedem ATM-Switch entschlüsselt werden müssen, ist die Verschlüsselung der
Header in den wenigsten Fällen sinnvoll.
Bei der Verschlüsselung auf der Ebene Zellenstroms werden alle Zellen mit dem gleichen
Schlüssel verschlüsselt, was ein Sicherheitsrisiko darstellen kann, wenn Zellen innerhalb
eines ATM-Netzes von verschiedenen Quellen stammen können.
Verschlüsselung auf Ebene Virtual Channel
Bei der Verschlüsselung auf der Ebene des Virtual Channel existiert für jedes Paar aus Virtual Path und Virtual
Channel ein eigener Schlüssel. Deshalb ist dieser Verfahren sicherer als die Verschlüsselung auf der Ebene der
Cellstream.
Bei der Verschlüsselung auf VC-Ebene wird nur der Payload der Zellen chiffriert
Probleme bei beiden Verfahren
Ein Problem, daß beide Methoden der ATM-Verschlüsselung gemeinsam haben, sind die
hohen Übertragungsraten im GBit/s-Bereich, die bei ATM auftreten. Da die Daten genauso
schnell Verschlüsselt werden müssen, wie sie übertragen werden, muß entweder sehr teure
Spezialhardware dafür verwendet werden, oder es müssen einfache, relativ unsichere
Verschlüsselungsalgorithmen verwendet werden.
Ein anderes Problem entsteht dadurch, daß ATM-Zellen sehr kurz sind. Da der Payload der
Zellen nur 48 Byte lang ist, können bestimmte Verschlüsselungsalgorithmen wie z.B. RSA
gar nicht verwendet werden.
Umsetzung in die Praxis
Beim Implementieren von verschlüsseltem ATM stellt sich die Frage, wo die Verschlüsselung stattfinden soll. In
Frage kommen dabei z.B. Switches, Endgeräte usw.
Die beste Lösung ist, in den Endgeräten des Netzes zu verschlüsseln. Zum einen gewährleistet
dies maximale Sicherheit, da keine unverschlüsselten Daten die Endgeräte verlassen. Dies
vereinfacht aber auch die Weiterleitung der Zellen, da, vorausgesetzt, daß nur der Payload
verschlüsselt wird, die Verschlüsselung für die ATM-Switches transparent ist.
Dabei wird ein neuer ATM Abstraction Layer definiert, der parallel zu den bereits
bestehenden ATM Abstraction Layers einen verschlüsselten Dienst zu Verfügung stellt.
Zukunft von ATM Virtual Private Networks
Obwohl Virtual Private Networks auf Basis von ATM durchaus praktikabel wären, scheint
die Zukunft ATM-basierten VPN zumindest fraglich.
17
Virtual Private Networks – Teil 1
Denn zum einen zeichnet es sich ab, daß sich ATM nicht bis zu den Endgeräten durchsetzen
wird, insbesondere weil die Akzeptanz von Gigabit-Ethernet relativ hoch zu sein scheint und
daher kein besonders großer Bedarf an ATM bis in die Endgeräte existiert.
ATM wird also wahrscheinlich ein Trägerdienst für andere Protokolle wie z.B. IP bleiben. Da
der Standard für verschlüsseltes IP, IPSec nun fast fertiggestellt ist und in IPv6 aufgenommen
wurde, wogegen noch kein Standard für verschlüsseltes ATM existiert, ist es sehr
wahrscheinlich, daß sich IPSec durchsetzten wird.
ATM Virtual Private Networks dürften also, wenn überhaupt, ein Nischenprodukt bleiben.
18
Virtual Private Networks – Teil 1
Kapitel 6: Abschließende Bemerkungen
In Zukunft ist zu erwarten, daß sich Virtuelle Private Netzwerke weiter durchsetzen werden.
Dabei werden wahrscheinlich vor allem IPSec, L2TP und TLS eine wichtige Rolle spielen, da
sie Standards darstellen, die eine breite Unterstützung in der Industrie finden.
Weiterhin bleibt anzumerken, daß auch Virtual Private Networks, trotz aller
Sicherheitsvorkehrungen, keinen vollkommenen Schutz der Daten darstellen, auf den man
sich blind verlassen könnte.
Insbesondere sind VPNs kein vollkommener Schutz gegen Wirtschaftsspionage, da diese
zahlreiche andere Wege kennt, um an vertraulich Daten zu gelangen. Auch schützten VPN
nicht davor, daß Mitarbeiter vertrauliche Daten, ob freiwillig oder unter Druck, weitergeben.
Literatur:







The Internet Protocol Journal Volume 1, Number 1,
The Internet Protocol Journal Volume 1, Number 2,
Securing ATM Networks, Shaw-Cheng Chuang, University of Cambridge, 1995.
ftp://ftp.cl.cam.ac.uk/public/papers/ATM/docs-95-10/12.ps.gz
Securing Classical IP over ATM Networs, Carsten Benecke, Uwe Ellermann, Universität Hamburg, Juli
1997, http://www.cert.dfn.de/eng/team/cb/eng_natm/eng_natm.html
Privatissimo, c’t Magazin 4/1999, Seite 190 ff.
A Comprehensive Guide to Virtual Private Networks, Volume I,
http://publib.boulder.ibm.com/pubs/pdfs/redbooks/sg245201.pdf
A Comprehensive Guide to Virtual Private Networks , Volume II
http://publib.boulder.ibm.com/pubs/pdfs/redbooks/sg245234.pdf
19