Einfacher VPN-Tunnelbau dank IKEv2
Seite 3: MOBIKE macht mobil
MOBIKE macht mobil
Da die IPSec- und IKE-Standards ursprünglich zur Kopplung von Netzen erdacht wurden, weisen sie erhebliche Schwächen im mobilen Bereich auf. Das Mobility and Multihoming Protocol (MOBIKE) verspricht als IKEv2-Erweiterung eine große Flexibilität beim Aufrechterhalten von IPSec-Verbindungen in mobilen Anwendungen respektive Geräten [4]. Nicht nur der dynamische Wechsel der eigenen IP-Adresse, wie er von vielen ADSL-Providern periodisch erzwungen wird, wird problemlos abgewickelt. Auch der fliegende Wechsel von einem Netzwerk-Interface zu einem anderen ist möglich, falls verschiedene Medien wie WLAN, GPRS oder UMTS den Weg ins Internet anbieten. Ob ein Peer MOBIKE-Fähigkeiten besitzt, signalisiert er im IKE_AUTH-Request (MOBIKE_SUPPORTED Notification) wobei er präventiv auf den UDP-Port 4500 für NAT-Traversal wechselt, unabhängig davon, ob wirklich eine NAT-Situation besteht.
Merkt nun ein Initiator, dass sich seine IP-Adresse oder sein aktives Netzwerk-Interface geändert hat, so sendet er mit seiner neuen IP-Adresse in einer INFORMATIONAL-Meldung eine UPDATE_SA_ADDRESSES-Nachricht an die Gegenseite, wobei alle ausgehandelten IKE_SA-Parameter inklusive der Kryptoschlüssel und Authentifizierungsinformationen beibehalten werden. Die andere Seite quittiert diese Meldung und ändert die IPSec-SA auf die neue IP-Adresse des Initiators um. Besitzen beide Seiten über Multi-Homing mehrere Netzwerkschnittstellen, so machen sie diese über ADDITIONAL_IP4_ADDRESS oder ADDITIONAL_IP6_ADDRESS-Nachrichten gegenseitig bekannt. Es steht in der Verantwortung des Initiators herauszufinden, welche der n x m möglichen Adresskombinationen eine funktionierende Verbindung ergibt.
Ein spezielles Szenario, welches aber weiterhin auch bei MOBIKE explizit ausgeklammert wird, ist der Double-NAT-Fall, bei dem beide VPN-Endpunkte hinter einem NAT-Router stecken und ohne die Vermittlungsdienste eines sogenannten Mediation-Servers keine Verbindung aufbauen können. Dieser Speziallfall soll durch einen zusätzlichen Internet Draft abgedeckt werden, der zurzeit im Rahmen des strongSwan-Projekts am Institut für Internet-Technologien und Anwendungen der Hochschule für Technik Rapperswil verfasst wird.
Warten auf Godot
Seit der IKEv2-RFC 4306 im Dezember 2005 verabschiedet wurde, sind 18 Monate vergangen und alle namhaften VPN-Hersteller haben eine IKEv2-Implementierung in der Pipeline. Im März 2007 fand in Orlando, Florida, der dritte IKEv2-Interoperabilitäts-Workshop statt, an dem Alcatel-Lucent, Certicom, Check Point, Cisco Systems, Furukawa, Ixia, Juniper Networks, Nokia, Reef Point Systems, SafeNet, Secure Computing Corporation, SonicWALL und das Open-Source-Projekt strongSwan ihre IKEv2-Produkte untereinander mit Erfolg testeten. In der Open-Source-Community tut sich zudem Weiteres: Die IKE-Daemons ikev2, OpenIKEv2 und racoon2 sind unter Linux beziehungsweise BSD bereits verfügbar. StrongSwan bietet dabei nach Einschätzung des Autors, der das Projekt als Professor an der Hochschule für Technik Rapperswil betreut, den größten Funktionsumfang. Unter anderem unterstützt es seit Version 4.1.4 MOBIKE-Grundfunktionen [5].
Die ersten praktischen IKEv2-Anwendungen sind seit Mitte dieses Jahres etwa bei T-Mobile USA für den HotSpot@Home-Dienst erfolgreich im Einsatz. Die neueste Handy-Generation von Samsung und Nokia kann im Einzugsbereich eines Wireless-LAN anstatt über das GSM- oder UMTS-Mobilfunknetz zu einem reduzierten Tarif über das Internet telefonieren (Unlicensed Mobile Access, UMA). Der dazugehörige 3GPP-Standard TS 33.234 schreibt vor, dass über das WLAN und die Internetverbindung vom Handy zu einem Security-Gateway des Mobilfunknetzbetreibers eine sichere Verbindung mittels IKEv2 aufgebaut werden muss. Vom Gateway wird dann das Gespräch in das normale Telekommunikationsnetz eingespeist. Der Benutzer authentifiziert sich mit seiner SIM-Karte über das IKEv2-Protokoll EAP-SIM oder EAP-AKA, während das Security-Gateway des Providers ein Zertifikat sendet. Das ganze erfordert keine zusätzliche Konfiguration vom Anwender auf dem Handy oder seinem Router und geschieht völlig transparent.
Es bleibt abzuwarten, ob IKEv2 in der Praxis auch bei stationären Anwendungen mehr Akzeptanz als IKEv1 findet. Leider sind IKEv1 und IKEv2 nicht miteinander interoperabel, sodass Anwender sich auf ein Protokoll festlegen müssen. Die neuen, besseren Funktionen von IKEv2 sollten aber die Wahl zwischen den beiden Protokollen einfach machen. Man darf gespannt auf die kommende IKEv2-Produktgeneration sein.
Mit Version 2 sind zwar die leidigen Probleme beseitigt, allerdings lässt auch der RFC 4306 einigen Spielraum für (Miss-)Interpretationen, die bei der Implementierung der Hersteller zu Inkompatibilitäten führen können. Der RFC 4718 "IKEv2 Clarifications and Implementation Guidelines" beschreibt die Details von IKEv2 erheblich genauer. Paul Hoffman vom VPNC Konsortium hat die beiden RFCs in einem Draft zusammengefasst, der zukünftig RFC 4306 ersetzen soll.
Eine genauere Beschreibung des Verbindungsaufbaus bei IKEv2 ist auf der folgenden Seite zu finden: IKEv2-Protokoll im Detail.
Literatur
[1] Niels Ferguson, Bruce Schneier, A Cryptographic Analysis of IPSec
[2] Daniel Bachfeld, Andreas Steffen, VPN Knigge
[3] Charlie Kaufman, Internet Key Exchange (IKEv2) Protocol, RFC 4306
[4] Pasi Eronen, IKEv2 Mobility and Multihoming Protocol (MOBIKE), RFC 4555
