IPSec und Remote Access VPN

IPSec funktioniert gut in Virtual Private Networks (VPNs) mit festen IP-Adressen (z. B. B2B oder Extranet). Beim Remote Access und beim Einsatz von privaten IP-Adressen (RFC 1597, [4]) weist IPSec jedoch erhebliche Mängel auf, die leider von Anbietern und Consultants sehr selten angesprochen werden, aber deren Kenntnis wichtig für Unternehmen ist, die in ein Remote-Access-VPN investieren wollen. Um die Probleme zu verstehen, ist ein tiefer Blick in die Protokollschichten und -abläufe notwendig.

Netzwerkprotokolle wie das Internet Protocol (IP) sind auf Ebene 3 (Layer 3) im OSI-Schichtenmodell definiert. Ein Layer-3-Protokoll benötigt jedoch auch die beiden tieferen Schichten, um die Datenpakete bis zum nächsten Vermittlungsknoten (Router) zu übertragen. Layer 2 und Layer 1 können wie ein LAN "verbindungslos" sein oder verbindungsorientiert arbeiten: In diesem Fall erfolgt die Einwahl beispielsweise via ISDN über das DFÜ-Netz zum Network Access Server (NAS) eines Providers. Nach dem Aufbau der ISDN-Verbindung wird das Layer-2-Protokoll PPP (Point-to-Point Protocol) verhandelt, erst danach kann ein Computer IP-Pakete zum Provider übermitteln.

Während einer PPP-Session werden bestimmte Attribute wie die IP-Adresse, DNS-Server und WINS-Server zwischen NAS und dem entfernten Rechner ausgetauscht. Eine dynamische IP-Adresse behält der Remote Client dabei nur so lange wie die PPP-Verbindung steht. Eine Layer-2-PPP-Verbindung ist multiprotokollfähig, es können neben IP auch andere Protokolle wie beispielsweise IPX oder ATLK (Appletalk) übermittelt werden. Des Weiteren enthält ein PPP-Verbindungsaufbau sicherheitsspezifische Abläufe wie Authentifizierung mit Benutzername/Passwort (PAP/CHAP) und einfache Verschlüsselung (Encryption Control Protocol, ECP) sowie weitere Features wie Datenkompression (Compression Control Protocol, CCP) oder Rückruf (Link Control Protocol, LCP).

Ein Beispielszenario für den Einsatz von PPP ist die Anbindung eines Filial-LAN an das Internet. Hierfür baut ein in der Filiale installierter IP-Router für den Versand seiner Pakete eine ISDN-Verbindung zum nächsten NAS auf, über die anschließend alle PPP-Verhandlungen erfolgen. Der Router erhält vom NAS (evtl. dynamisch) eine öffentliche IP-Adresse. Vom Internet aus ist nur diese Router-Adresse zu vermitteln.

Häufig arbeiten solche Anbindungen mit IP Network Address Translation (NAT, auch Maskieren genannt). Dieses Verfahren "spart" IP-Adressraum und bietet gleichzeitig einen gewissen Schutz gegen unerwünschte Verbindungen vom Internet ins LAN. Jeder Rechner im LAN besitzt seine eigene private IP-Adresse (üblicherweise gem. RFC 1597). Bei jedem von einem LAN-Rechner erzeugten Datenpaket wird vom Router die private Quelladresse gegen die öffentliche IP-Adresse ausgetauscht. Das Ergebnis: Alle LAN-Rechner erscheinen im Internet ausschließlich unter einer einzelnen öffentlichen IP-Adresse.

Remote Access VPN

Ein Remote Access VPN ist die Abbildung eines traditionellen Direkteinwahl-Remote-Access-Netzes auf ein öffentliches IP-Netz. Unternehmen, die ein solches VPN planen, stellen normalerweise die gleichen Anforderungen wie beim direkten Dial-in-Zugriff auf die Unternehmenszentrale. Im Wesentlichen geht es um folgende Punkte:

Grundlage der VPNs sind gesicherte "Tunnel" durch das unsichere Netz, entweder auf der Sicherungs- oder Vermittlungsschicht (Layer-2- oder -3-Tunneling-VPNs). Etabliert wird ein Tunnel dadurch, dass jedem erzeugten Datenpaket ein extra IP-Header und ein oder mehrere spezifische Header vorangestellt werden [5]. Der Tunnel beginnt dort, wo der extra IP-Header hinzugefügt wird und endet, wo er wieder entfernt wird. Da Authentifizierung und Verschlüsselung komplett innerhalb des Tunnels ablaufen, spielen die Tunnelendpunkte eine sehr wichtige Rolle. Abhängig vom Tunnelendpunkt spricht man von Site-to-Site-VPN, End-to-Site-VPN und End-to-End-VPN. Ein Beispiel für Site-to-Site-VPN ist ein Tunnel zwischen einem Filial-Router und einem VPN-Gateway in der Zentrale.

Tunneling-Verfahren

Bei einem End-to-Site-VPN wird entweder ein Tunnel zwischen einem Einzelplatz-PC und einem VPN-Gateway oder einem Client in einem Filialnetz und dem zentralen VPN-Gateway aufgebaut. Dabei ist es nicht erforderlich, dass der Filial-Router VPN-fähig ist. Das End-to-End-VPN funktioniert im Grunde genauso wie ein End-to-Site-VPN, nur dass das VPN-Gateway erst im Applikations-Server integriert ist. Dadurch ist die gesamte Stecke vom Client-PC bis zur zentralen Applikation gesichert.

Unternehmen gehen zunehmend dazu über, die Tunnel nicht im Filial-Router enden zu lassen, sondern in den einzelnen LAN-Workstations. Der Vorteil: Eine persönliche Authentifizierung der Teilnehmer und die Verschlüsselung der Unternehmensdaten auch innerhalb des Filialnetzes. Am Remote-Access-Markt zeichnet sich daher zunehmend eine Entwicklung von Site-to-Site- hin zu End-to-Site-VPNs ab.

Layer 2 VPN

Zu den bekanntesten Layer-2-Verfahren gehören Layer-2-Forwarding (L2F), Layer-2-Tunneling-Protocol (L2TP) und Point-to-Point-Tunneling-Protocol (PPTP). Ein Layer-2-Tunnel stellt ein "virtuelles Kabel" über jede IP-Plattform dar und lässt sich über jede IP-Struktur hinweg aufbauen. Dabei ist es unerheblich, ob die installierten Router zwischen Client und VPN-Gateway IP-NAT einsetzen. Wie schon erwähnt ist ein Layer-2-Tunnel multiprotokollfähig. Folglich besteht bei einem Layer-2-VPN die Möglichkeit, über ein öffentliches Netz, das nur IP vermittelt, mit der Unternehmenszentrale über beliebige Netzwerkprotokolle zu kommunizieren. Der Tunnelaufbau bei einem Layer-2-VPN wird realisiert durch einen extra IP-Header, einen UDP- oder TCP-Header und einen verfahrensspezifischen Header. Der Overhead pro Paket ist dabei abhäng vom eingesetzten Verfahren und liegt bei ungefähr 40 Bytes.

Wie hervorragend die Eigenschaften der Layer-2-Tunneling-Verfahren für Remote Access auch sein mögen. Sie gewährleisten nur eine teilweise Datenintegrität und eine relativ schwache Authentifizierung (per CHAP/PAP). Weiter fehlen wesentliche Sicherheitsfunktionen wie Verschlüsselung, Unterstützung digitaler Zertifikate und ein leistungsfähiges Schlüsselmanagement. Eine Möglichkeit, Security-Mechanismen und Layer-2-VPN-Tunneling zu vereinen, bietet sich mit der Erweiterung des Point-to-Point-Protokolls. Man unterscheidet hier zwei Ansätze:

In beiden Fällen wird für die Erweiterung das SSL-v3.0-Handshake-Protokoll eingesetzt (Secure Sockets Layer, zunehmend bezeichnet als Transport Layer Security, TLS). Dieses Verfahren ist in dem von Microsoft eingereichten Experimental RFC 2716 PPP EAP TLS Authentication Protocol beschrieben. Es unterstützt die Anwendung von Zertifikaten, was starke Authentifizierung und sicheren Schlüsselaustausch ermöglicht – das VPN ist somit "PKI enabled". Nach Ablauf der SSL-Verhandlung wird alles verschlüsselt, was über die PPP-Verbindung läuft: die Netzwerkprotokolle IP/IPX und auch der letzte Teil der PPP-Verhandlung, in dem die Zuweisung der privaten IP-Adresse, des DNS- und/oder WINS-Servers an den Client erfolgt.

Layer-2-Tunneling mit den beschriebenen Sicherheitsmechanismen ermöglicht den Aufbau eines Remote Access VPN, das jede Infrastruktur unterstützt. Bereits vorhandene Netzwerkkomponenten lassen sich problemlos nutzen. Es ist unerheblich, ob ein Client den Tunnel über einen Provider, einen Branch-Office-Router, einen NAS in der Zentrale oder direkt zum VPN-Gateway in der Firmenzentrale aufbaut. Der Remote-User erhält für die PPP-Session immer dieselben Attribute: IP-Adresse, Datenkompression, DNS-Adresse usw.

Layer 3 VPN – IPSec

Ein Layer-3-VPN ist nicht multiprotokollfähig, sondern bezieht sich immer auf ein bestimmtes Netzwerkprotokoll – im Falle von IPSec auf IP. Mit den IPSec RFCs 2401–2409 lässt sich ein VPN mit vorgegebener Sicherheit für das IP-Protokoll realisieren. Es steht ein komplettes Rahmenwerk zur Verfügung, das sowohl (Layer-3-)Tunneling als auch alle notwendigen Sicherheitsmechanismen wie starke Authentifizierung, Schlüsselaustausch und Verschlüsselung umfasst. Ziel dieses VPN-Standards ist Herstellerunabhängigkeit.

Jede Kommunikationskomponente, die IPSec unterstützt, verfügt über ein IPSec-Modul. Mithilfe dieses Moduls wird jedes Datenpaket gegenüber einer Security Policy Database (SPD) geprüft. Die SPD besteht aus Einträgen, in denen unter anderem die Sicherheitsmerkmale beschrieben sind. Die SPD-Entries enthalten einen zusätzlichen Filterteil (Selector), der sich aus IP-Adressen, UDP- und TCP-Ports sowie IP-Header-spezifischen Einträgen zusammensetzt. Stimmt ein Datenpaket mit dem Selector eines SPD-Eintrags überein, wird die weitere Vorgehensweise damit überprüft. Je nach Ergebnis wird das Paket entweder durchgelassen (permit), gestoppt (deny) oder es werden bestimmte Security-Merkmale appliziert (IPSec-Processing).

Bei Übereinstimmung eines Datenpaketes mit einem SPD-Eintrag wird überprüft, ob bereits eine Security Association (SA) für diesen SPD-Eintrag existiert. Die SA bestimmt, welches Security-Protokoll verwendet werden soll: Encapsulating Security Payload (ESP) oder Authentication Header (AH). ESP unterstützt die Verschlüsselung und Authentifizierung des IP-Paketes, AH ermöglicht nur seine Authentifizierung. Eine weitere Aufgabe der SA ist, den Modus des Security-Protokolls festzulegen: Tunnel-Mode oder Transport-Mode. Im Tunnel-Mode wird der gesamte Frame verschlüsselt, das Datenpaket bekommt einen neuen Header. Quelle und Ziel sind so versteckt und nur die Tunnelendpunkte sind erkennbar. Im Transport-Mode wird der Frame-Inhalt verschlüsselt, der ursprüngliche IP-Header aber beibehalten; Quell- und Zieladresse bleiben ungeschützt. Für Remote Access und End-to-Site-VPNs kommt nur der ESP-Tunnel-Mode in Frage.

Nach dem Versand eines IP-Datenpakets vom IP-Stack zum IPSec-Modul findet dort das IPSec-Processing des Orginal-Headers (IP1) mit seinen Nutzdaten statt (Payload, PL). Das Ergebnis hänget vom Modus und Security-Protokoll ab: Der Transport-Mode dient zur Rechner-zu-Rechner-Kommunikation, der Tunnel-Mode für den Betrieb über ein VPN-Gateway. Der IP2-Header ermöglicht den Datentransport vom Client via Internet zu einem Gateway. Das VPN-Gateway entfernt den IP2-Header, entschlüsselt und sendet das Paket weiter ins Unternehmensnetz.

Darüber hinaus legt die SA den Algorithmus für die Authentifizierung, die Verschlüsselungsmethode (nur bei ESP) und den verwendeten Schlüssel fest. Die Gegenstelle muss daher über dieselbe SA verfügen. Wenn eine IPSec-SA für einen bestimmten SPD-Eintrag nicht vorliegt, muss sie mit der Gegenstelle ausgehandelt werden. In so einem Fall kommt die zweite große Komponente einer IPSec-Implementation zum Einsatz: das Internet-KeyExchange-Protokoll (IKE).

Zur Verdeutlichung ein Beispiel einer Internetverbindung zwischen Remote Client und dem VPN-Gateway in der Firmenzentrale: Der Client hat einen SPD-Eintrag mit einem Selector, der ESP im Tunnel-Mode für IP-Pakete an die Firmenzentrale vorgibt. Der Client stellt zunächst eine Layer-2-PPP-Verbindung zum Provider her. Anschließend erhält das IPSec-Modul im Client ein IP-Paket mit der Zieladresse "Firmenzentrale". Es existiert zwar ein SPD-Eintrag für dieses IP-Paket, jedoch keine SA. Daher stellt das IPSec-Modul an das IKE-Modul die Anforderung, eine IPSec-SA mit der Gegenstelle – dem VPN-Gateway – auszuhandeln (dieser Vorgang wird als Phase-2-Verhandlung bezeichnet). Dabei bekommt das IKE-Modul auch die im SPD-Eintrag vorhandenen Security-Merkmale mitgeteilt. Voraussetzung für den Ablauf dieses Prozesses ist eine Kontrollverbindung zwischen Client und VPN-Gateway (die so genannte Phase-1-Verhandlung mit dem Ergebnis einer IKE-SA). Die Phase-1-Verhandlung übernimmt den gesamten Authentifizierungsvorgang vom Client zum VPN-Gateway und erzeugt gleichzeitig eine verschlüsselte Kontrollverbindung, über die anschließend die Phase-2-Verhandlung für die IPSec-SA abläuft.

Die IKE-Phase-1-Verhandlung ist ein Handshake, der den Austausch digitaler Zertifikate erlaubt und einen Schlüsselaustausch für die Kontrollverbindung vollzieht. Dieses Verfahren kann in zwei verschiedenen Hauptmodi erfolgen: dem Main Mode und dem Aggressive Mode. Im Main Mode (oder Identity-Protection-Mode) erfolgt ein Austausch von insgesamt sechs Nachrichten, wobei übertragene IDs oder Zertifikate verschlüsselt werden. Im Aggressive-Mode tauschen die Parteien hingegen nur drei Nachrichten aus und eventuell übertragene IDs und Zertifikate gehen im Klartext durchs Netz.

Unabhängig vom Verhandlungsmodus gibt es verschiedene bidirektionale Authentifizierungsmethoden, die beiden häufigsten sind:

Während einer IKE-Verhandlung mit Preshared Key und Main Mode, muss der Client vom VPN-Gateway anhand seiner IP-Adresse eindeutig identifizierbar sein. Denn der Preshared Key wird in die symmetrische Schlüsselberechnung mit einbezogen, die Verschlüsselung beginnt bereits vor der Übertragung von Merkmalen, die den Client identifizieren. Erfolgt nun die Einwahl eines Clients über einen Provider, ist seine IP-Adresse aufgrund der dynamischen Adresszuweisung zunächst unbekannt. Eine Möglichkeit, dieses Problem zu umgehen, ist der Aggressive Mode. Der Nachteil: Die Übertragung der IDs und/oder digitalen Zertifikate erfolgt im Klartext. Eine andere Methode ist, dass alle Clients denselben Preshared Key erhalten. Diese Vorgehensweise ist allerdings mit einer Schwächung der Authentifizierung verbunden.

Remote-Access-Probleme

Bei der Abbildung eines Dial-in-Remote-Access-Netzes auf ein IPSec-VPN ergeben sich letztlich folgende Probleme:

Zwischenzeitlich gibt es verschiedene Ansätze, um diese Mankos zu beseitigen und IPSec für Remote Access zu optimieren. Als Lösung für die Punkte 1 und 2 existiert der von Cisco eingereichte Draft Extended Authentication (XAUTH). Er bedingt jedoch eine Veränderung und Erweiterung des IKE-Protokolls. Um das in Punkt 4 dargestellte Problem zu lösen, gibt es einen Vorschlag (keinen Draft), der eine Art Polling beschreibt. Mithilfe dieses Verfahrens soll signalisiert werden, wenn eine SA nicht mehr aktiv ist. Polling wird allerdings zu einem Problem, wenn der Client im so genannten Shorthold-Mode arbeitet, da die PPP-Verbindung zum Provider immer bestehen bleibt. Für Punkt 5 gibt es einen neu eingereichten Draft NAT Traversal 28/2-2001 der Firma SSH. Im Prinzip geht es darum, jedes erzeugte IPSec-Paket zusätzlich in einen IP und UDP-Header zu verpacken, um so eine Kommunikation über Geräte zu ermöglichen, die IP-NAT-einsetzen.

Bei den genannten Lösungsansätzen handelt es sich teils um Vorschläge außerhalb des Internet-Standardisierungsverfahrens, die nicht alle von den IP Security Remote Access (IPSRA) und IPSec Working Groups der Internet Engineering Task Force (www.IETF.org) akzeptiert sind. Im von CISCO eingereichten XAUTH Draft heißt es beispielsweise: "The document has been published as informational as the IPSRA working group will not accept any protocol which extends ISAKMP or IKE. Furthermore, the IPSec working group refuses to accept any protocols that deal with remote access."

Der nach Meinung des Autors interessanteste Ansatz, um die in den Punkten 1 bis 5 aufgezeigten Probleme zu lösen, ist im Informational RFC 2888 IPSec over L2TP (Secure Remote Access with L2TP) beschrieben. Mit IPSec over L2TP werden keinerlei Veränderungen oder Erweiterungen der RFCs 2401–2409 notwendig, womit der Akzeptanz seitens der IPSec und IPSRA Working Groups nichts im Wege stehen dürfte. In der Praxis hieße das, zunächst einen Layer-2-Tunnel zwischen Remote Client und VPN Gateway aufzubauen. Anschließend läuft eine Standard-PPP-Verbindung (ohne zusätzliche Sicherheit wie PPP-EAP-TLS), über welche die IKE-Verhandlung und die IPSec-Datenpakete übertragen werden (Punkte 1–3). Trennt der Client seine Layer-2-Verbindung zum Provider, erfolgt automatisch der Tunnelabbau und die IPSec-SAs können gelöscht werden (Punkt 4). Mit Punkt 5 (IP-NAT) gibt es – wie bereits beschrieben – bei einem L2TP-Tunnel keine Probleme.

Der RFC 2888 hat jedoch auch Nachteile: der Overhead von L2TP- und zusätzlich IPSec-Headern, die Komplexität der doppelten Implementierung (Layer-2-Tunneling und IPSec) sowie das unverschlüsselte Versenden der privaten IP-Adressen, da IPSec erst nach dem Tunnelaufbau und der anschließenden PPP-Verhandlung greift. Die praktische Erfahrung mit IPSec over L2TP zeigt jedoch, dass sich der Overhead entweder durch PPP-Kompression oder IP-Kompression (IPCOMP) begrenzen lässt. Die Komplexität der Implementierung hängt von den Kenntnissen eines Herstellers hinsichtlich Layer-2-Technologie ab. Wie problematisch das unverschlüsselte Versenden der privaten IP-Adressen ist, hängt letztlich vom Sicherheitsbedürfnis des VPN-Betreibers ab.

Fazit

IPSec ist ein Standard mit ausgezeichneten Sicherheitsmechanismen, der ohne weiteres in bestimmten VPN-Szenarien funktioniert, in denen mit festen IP-Adressen gearbeitet wird. In diesen Fällen lassen sich durchaus auch VPN-Gateways verschiedener Hersteller einsetzen, wenn auch Probleme beim Einsatz von digitalen Zertifikaten auftreten können. Ohne Zweifel hat IPSec auch für Remote Access seine Berechtigung, wenn es allen Herstellern gelänge, sich auf ein einheitliches Verfahren zu einigen. Doch solange immer wieder neue Drafts eingereicht werden oder sogar mehrere konkurrierende Drafts und Vorschläge existieren, die das gleiche Problem zu lösen versuchen, kann man schwerlich von einem Standard sprechen.

Literatur

[1]: IETF IP Security Remote Access Working Group (ipsra), www.ietf.org/html.charters/ipsra-charter.html
[2]: IETF IP Security Protocol Working Group (ipsec), www.ietf.org/html.charters/ipsec-charter.html
[3]: IETF RFC Page, www.ietf.org/rfc.html
[4]: RFC 1597, Address Allocation for Private Internets, www.ietf.org/rfc/rfc1597.txt
[5]: Timo Rinne, Sicher kommunizieren mit IPSec, KES 2000/5, Seite 77

Management und Wissen

Virtual Private Networks