Einfacher VPN-Tunnelbau dank IKEv2
Version 2 des Internet-Key-Exchange-Protokolls verspricht, das Aufsetzen von VPNs einfacher, flexibler und weniger fehleranfällig zu machen. Insbesondere soll das Mobility and Multihoming Protocol Anbindungen mobiler Anwendungen zuverlässiger machen.
- Dr. Andreas Steffen
Der IPSec-Standard hat den Ruf, schwierig in der Konfiguration und im Betrieb zu sein. Schuld daran ist zum größten Teil die hohe Komplexität des Schlüsselaustausch-Protokolls IKE: Nicht selten scheitert der Verbindungsaufbau wegen minimaler Einstellungsunterschiede auf den Endgeräten - oftmals gerade dann, wenn sich Produkte unterschiedlicher Hersteller miteinander unterhalten sollen. Zudem lässt etwa die Fülle der kryptografischen Optionen beim Einrichten einer Verbindung einen Administrator verzweifeln, was unter Umständen zu unsicheren Konfigurationen führt, damit es überhaupt zu einer Verbindung kommt. In einer vielbeachteten Studie schrieben die Krypto-Gurus Niels Ferguson und Bruce Schneier dem IPSec-Standard aufgrund seiner Komplexität potenzielle Sicherheitsrisiken zu [1]. Auch die Authentifizierungsoptionen wirken kaum wie aus einem Guss und nicht zuletzt hadert das rudimentäre IKEv1 mit der weit verbreiteten Network Adress Translation (NAT), dynamischen IP-Adressen sowie mobilen Endgeräten. Deshalb sind viele Benutzer in den letzten Jahren zu SSL-basierten VPNs wie OpenVPN abgewandert, die sich wesentlich einfacher konfigurieren und betreiben lassen [2].
Jetzt will man es besser machen und hat dazu die IPSec- und IKE-Standards überarbeitet. IPSec wurde geringfügig erweitert, wobei die kryptografischen Änderungen den größten Teil ausmachen. Während in der ersten Version von IPSec die einfache DES-Verschlüsselung für den Tunnelmode ESP noch Pflicht war, so rät der neue RFC 4305 nun stark davon ab, einen nur 56 Bit langen Schlüssel einzusetzen - den schon fast jeder Fachmann mit ausreichendem Equipment über das Wochenende knacken kann. Der Standard-Algorithmus bleibt weiterhin die dreifache DES-Verschlüsselung mit einer nominellen Schlüssellänge von 168 Bit. Alternativ wird der Advanced Encryption Standard (AES) mit 128 Bit Schlüssellänge empfohlen. Besonders vorsichtige Anwender können die AES-Schlüssellänge optional auf 256 Bit erhöhen, müssen aber einen zusätzlichen Rechenaufwand von rund 40 Prozent in Kauf nehmen.
Der Hauptteil der Änderungen bezog sich auf IKE. Zunächst ist IKEv2 in einem einzigen RFC-Dokument (4306) zusammengefasst, statt über diverse RFCs als Framework verteilt zu sein [3]. Augenfällig bei IKEv2 ist der beschleunigte Verbindungsaufbau: Den klassischen Main/Aggressive Mode und den Quick Mode gibt es nicht mehr. Benötigte das Vorgängerprotokoll IKEv1 noch sechs Meldungen für den Main Mode und drei weitere für den Quick Mode, also zusammen neun Nachrichten, so reichen bei IKEv2 im Normalfall vier Meldungen aus, um eine IPSec-Verbindung aufzubauen (siehe auch Kasten). Damit kommt die Verbindung schneller zustande, inbesondere bei Störungen steht der Tunnel recht fix wieder. IKEv2 verzichtet zudem auf einen präventiven Cookie-Austausch, der Gateways vor Denial-of-Service-Attacken mit gespooften Adressen schützen soll, womit sich zwei weitere Meldungen einsparen lassen. Die Entscheidung gegen den Cookie-Austausch rührt aus der Erfahrung her, dass in den letzten Jahren kaum Probleme aufgrund von DoS-Angriffen gegen VPN-Gateways verzeichnet wurden.
Bei IKEv1 war die Verantwortlichkeit bei Paketverlusten nicht klar geregelt, sodass oftmals beide Seiten gleichzeitig ihre zuletzt gesendeten Meldungen wiederholten, was für Verwirrung bei den Peers sorgte und damit der Verbindungsstabilität abträglich war. Unter IKEv2 sind die Zuständigkeiten der Peers klarer geregelt: Es gibt nur Meldungspaare, die aus einem Request eines Initiators und einer quittierenden Antwort eines Responders bestehen. Dabei ist beim Ausbleiben einer Response allein der Initiator für die zeitlich gestaffelten Meldungswiederholungsversuche zuständig. Kommt keine IPSec-Verbindung zustande, sendet der Responder differenzierte Fehlermeldungen (Notify Payload) an den Absender, woran der Versuch gescheitert ist. Anders als unter IKEv1 ist damit eine leichtere Fehlersuche möglich.
Um auch über NAT-Router hinweg eine Verbindung aufbauen zu können, ist NAT-Traversal nun fester Bestandteil von IKEv2, wobei die Unterstützung dieser Option von den Endgeräten nicht mehr über ein Vendor-ID-Feld mitgeteilt wird. Vielmehr signalisieren die Peers bereits im ersten IKE_SA_INIT-Request, dass sie NAT-Traversal unterstützen. Dazu senden sie im Header einen NAT-Discovery-Hash mit. Stellen beide Peers dann eine NAT-Situation fest, wechseln sie automatisch auf den UDP-Port 4500, um darüber den weiteren IPSec-Verkehr mittels UDP-Encapsulation abzuwickeln.
