Mobilität in IPv6: Standards und Entwicklungstrends, Teil 3
MIPv6-Grenzen, -Performance-Probleme und -Optimierungsansätze
14.01.2008 | Autor / Redakteur: Thomas Schmidt und Matthias Wählisch / Ulrike Ostler
Die Kernkomponenten des Internet-Protokoll-Standards Version 6 für die mobile Kommunikation – Mobile IPv6 – sind nahezu definiert. Allerdings gibt es ein paar Probleme bezüglich der Performanz und der Sicherheit. Der letzte Teil der MIPv6-Trilogie diskutiert die Möglichkeiten und Entwicklungspfade für eine übergangslose und sichere Kommunikation auf Basis des neuen Standards.
Wechselt ein Mobile Node (MN) zwischen Netzwerken, wird eine komplexe Re-Konfigurationskette in Gang gesetzt, die für seine Nutzer und Anwendungen unbemerkt bleiben soll.
Zunächst muss ein Handover auf der physikalischen Schicht abgeschlossen werden, welches den MN während der L2-spezifischen Reassoziationszeit vom Kommunikationsnetz trennen kann. Hierauf folgen die Re-Konfiguration des lokalen IP-Stacks sowie Binding Updates (BUs) zum Home Agent (HA) und zu den Correspondent Nodes (CNs). Bis zur Vollendung dieser Übergangsphase muss der MN möglicherweise merkliche Verzögerungen und Qualitätseinbußen in Gestalt von Paketverlusten, Latenzen und erhöhtem Jitter hinnehmen.
Im Detail setzt sich der Handover-Prozess aus folgenden Teilschritten zusammen:
Wechsel auf der Sicherungsschicht (Link Layer Handoff)
Der Link Layer Handoff hängt davon ab, ob es sich um eine verbindungslose oder verbindungsorientierte Technologie handelt, der Knoten einfach oder mehrfach an Netzwerke gekoppelt ist sowie von den Besonderheiten der eingesetzten Protokolle. Die Unterbrechungszeiten bewegen sich zwischen 0 und mehreren hundert Millisekunden. Letzteres trifft beispielsweise für schlecht optimiertes 802.11-Equipment zu.
Schicht 3: Bewegungserkennung (Layer 3: Movement Detection)
Eine Bewegungserkennung auf der Netzwerkschicht kann auf aktive und passive Art und Weise erreicht werden. Passiv erkennt der MN ein neues Netzwerk durch die reguläre Präfixverbreitung der IPv6 Router. Link Layer Trigger des eigenen Netzwerk-Interfaces hingegen können den MN dazu veranlassen, mittels Router Solicitation ein gegebenenfalls verändertes Präfix von seinem Default Router zu erfahren.
Lokale Adresskonfiguration
Unmittelbar nach dem Erhalt eines neuen Netzwerkpräfixes kann der MN eine neue Care-of Adresse (CoA) in dem besuchten Netzwerk konfigurieren.
Duplicate Address Detection (DAD)
Eine autokonfigurierte IPv6 Adresse muss mithilfe der so genannten Duplicate Address Detection auf ihre Eindeutigkeit geprüft werden. Im Regelfall einer bereits eindeutig gewählten Adresse führt dies zu einem Timeout. Um hieraus entstehende störende Wartezeiten zu umgehen, wurde eine asynchrone DAD-Durchführung vorgeschlagen und weitgehend implementiert.
Bindung mit dem Home Agent
Das Binding Update mit dem Home Agent benötigt eine Bestätigung durch den HA und überdauert so Round Trip Time zwischen MN und HA.
Binding Update mit dem Correspondent Node
Das Binding Update mit dem CN initiiert die Return Routability Procedure. Diese schließt eine Round-Trip-Signalisierung zwischen MN und CN sowie MN und HA ein.
Während die ersten vier Schritte im lokalen Netz des MNs geschehen, hängen die BUs von Round-Trip-Zeiten zwischen den Teilnehmern ab. Unter der Annahme, dass Link Layer Trigger und asynchrones DAD zum Einsatz kommen, kann ein zustandsloses lokales MIPv6-Handover beeindruckend schnell erfolgen.
Werden in einer mobilitätsfreundlichen Umgebung die Timer MAX_RA_DELAY_TIME und MAX_RTR_SOLICITATION_DELAY auf dem Router und dem MN entsprechend angepasst, kann der erforderliche Router Discovery Handshake innerhalb einiger Millisekunden und die Re-Adressierungszeit in weniger als 10ms durchgeführt werden, ohne zusätzlichen Netzverkehr zu verursachen.
Zum Vergleich sei daran erinnert, dass der Takt des IEEE 802.11b Standards das Senden von 10 Paketen der Größe eines Router-Advertisements pro Sekunde erlaubt. Die zeitlichen Dimensionen der lokalen Handover-Schritte sind in der Grafik zu optimierten Handover-Zeiten dargestellt.
Die BU-Zeiten hingegen sind abhängig von den topologischen Gegebenheiten der beteiligten Netze und nicht durch MIPv6- oder Router-Konfigurationen zu beeinflussen. Das wohlbekannte „Zwei Chinesen in New York“ Szenario illustriert das Problem: Befinden sich zwei Kommunikationspartner in demselben Gastgebernetzwerk, ihre HAs jedoch hiervon weit entfernt, so kann die Handover-Qualität inakzeptabel werden.
Um topologischen Abhängigkeiten entgegenzuwirken, sind zusätzliche Protokollerweiterungen erforderlich.
Sicherheitsbeschränkungen
Die Sicherheitskomponenten des MIPv6 Basisprotokolls sind robust und ausreichend einfach. Den üblichen Sicherheitsstandards des statischen Internets entsprechend stellt Mobile IPv6 sicher, dass ein mobiler Knoten seine HoA für Bindings oder reguläre Kommunikation nur erfolgreich nutzen kann, wenn er entweder in seinem Heimatnetz ist oder durch einen HA in seinem Heimatnetz unterstützt wird.
Dennoch hat dieses Vorgehen einige Nacheile, die sich aus der Return Routability Procedure ergeben. Zunächst bleiben Binding Updates im lokalen Netz des CNs mittles Man-In-The-Middle Attacken angreifbar. Dort und möglicherweise in benachbarten Netzen nehmen die Home- und Care-Of-Test-Nachrichten den gleichen Weg.
Darüber hinaus erzeugt dieses Vorgehen mehrere Round-Trip-Nachrichten und bedingt damit unter Umständen erhebliche Verzögerungen, welche sich nicht durch einfache Protokolloptimierungen vermeiden lassen.
Schließlich kann für eine unidirektionale Datenverteilung, wie sie etwa bei IP Multicast genutzt wird, solcherlei Handshake Protokoll nicht verwendet werden.
Einem verbesserten Verfahren für ein gesichertes Binding Update der Kommunikationspartner kann demnach entscheidende Bedeutung beigemessen werden. Das ist ein durchaus schwieriges Problem, dem mit einem neuen Konzept der kryptographisch genierten Adressen beizukommen ist. Eine durchaus überzeugende Lösung wird im Artikel über MIPv6-Optimierungen vorgestellt (siehe: Zusatzinformationen)
Zusammenwirken mit Firewalls
Für den erfolgreichen Betrieb von MIPv6 müssen Netzwerkadministratoren Firewalls und ACLs für das Zusammenspiel mit MIPv6 anpassen. Socket-Parameter und Protokolltypen werden von Firewalls genutzt, um Verkehrsströme zu verbieten oder zu erlauben. Zustandsbehaftete Firewalls sind in der Lage, Regeln an von innen geöffnete Kanäle anzupassen.
Abhängig vom Szenario, also davon, ob sich MN, HA oder CNs hinter einer Firewall befinden, sind unterschiedliche Anforderungen zu erfüllen. Folgenden Kernthemen sind identifizierbar:
Probleme mit ESP-Filtern
Eines der Hauptprobleme von MIPv6 mit herkömmlichen Firewall-Regeln liegt in der strikten Filterung von ESP-Paketen. Da Binding Updates und Acknowledgements durch IPsec ESP geschützt werden, ist bei einer solchen Filterung weder eine Kommunikation zum HA noch zum CN möglich.
Hierbei sei darauf hingewiesen, dass Firewalls die CoA des MN à priori nicht kennen können und nicht in der Lage sind, verschlüsselte ESP Pakete zu inspizieren. Folglich muss eine minimale Erlaubnisregel das (eigene) Netzwerkpräfix und die ESP IP Payload Protokollnummer 50 enthalten. Die Erlaubnis für die Durchleitung von ESP Paketen ist eine Voraussetzung für die Routenoptimierung zum CN, da der MN einen geschützten Return Routability Test durchführt bevor er ein BU sendet.
Probleme mit zustandsbehafteten Firewalls
Auch nachdem der HA und die CNs ihre Binding Caches erfolgreich aktualisiert haben, können Firewalls die weitere Kommunikation verhindern.
Als einfaches Beispiel sei ein CN genannt, welcher eine Kommunikation mit einem MN hinter einer Firewall zu initiieren versucht. Da MIPv6 Signalisierungsnachrichten und der Datenverkehr entkoppelt voneinander die Firewall erreichen, etabliert ein BU keinen für normalen Datenverkehr weiterverwendbaren Weiterleitungszustand in der Firewall.
In diesem Beispiel kann folglich nur der MN eine Verbindung zum CN aufnehmen und dabei einen Weiterleitungszustand in der Firewall etablieren. Das gleiche Szenario gilt in umgekehrten Rollen sinngemäß.
Weiterhin muss eine Firewall in der Lage sein, CoA-Änderungen zu verarbeiten. Jedes vom MN gesendete Paket trägt die CoA als Quelladresse, entweder im äußeren Tunnel Header oder ausschließlich in routenoptimierten Datenströmen zum CN. Jeder in einer Firewall etablierte Zustand, welcher MN oder CN betrifft, wird ungültig, sobald der MN das Subnetz wechselt. Aus diesem Grund ist es notwendig, entweder Adressänderungen zu verfolgen oder die Korrespondenz des MN zu seiner permanenten HA mit zu berücksichtigen.
MIPv6-Optimierung
Das Leistungsverhalten von MIPv6-Handover ist stark topologieabhängig. Dieser Schwachstelle wurde in weiteren Forschungen und Entwicklungen zu begegnen versucht. Die IETF hat innerhalb ihrer Mobility Performance Optimisation Arbeitsgruppe zwei Kernvorschläge zur Verbesserung der Roaming Prozeduren erarbeitet:
HMIPv6: Verteilte Home Agent Proxis
Ein Konzept für die Repräsentation von Home Agents (HAs) mithilfe verteilter Proxies wurde innerhalb von „Hierarchical Mobile IPv6 (HMIPv6)“ standardisiert. Während sich der MN außerhalb seines Heimatnetzes befindet, registriert er sich bei einem nahe gelegenen Mobility Anchor Point (MAP) und kommuniziert über diesen (siehe: Abbildung zur Micro-Mobilität in „Zusatzinformationen“).
Im Sinne von HMIPv6 sind MAPs Bestandteile der regulären Infrastruktur. In diesem Micro Mobility Konzept ist der MN mit einer Regional Care-Of Adresse (RCoA) und einer Link Local CoA (LCoA) ausgestattet. Wenn der MN mit Correspondent Nodes (CNs) anderer Netze kommuniziert, wird seine RCoA als Quelladresse verwendet.
Dadurch werden seine Bewegungen innerhalb einer MAP-Domain gegenüber der Außenwelt verborgen. HMIPv6 reduziert somit die Anzahl der „sichtbaren“ Handovers. Wechselt der MN jedoch die MAP-Domain, sind reguläre Binding Updates (Bus) mit den CNs und dem HA erforderlich.
FMIPv6: Handover nach Vorsaussage
Der alternative Ansatz überlässt die Handover-Verhandlungen den Zugangsroutern, dem vorherigen (PAR) und neuen (NAR), und wurde in „Fast Handover for MIPv6“ (FMIPv6) eingeführt. FMIPv6 versucht, Netzwechsel vorherzusagen, konfiguriert und verifiziert eine voraussichtliche neue CoA vor dem eigentlichen Layer-2 Handover und leitet Datenflüsse bereits zur neuen CoA um, während sich der MN noch zu seinem neuen Zugangspunkt bewegt.
Wie in der Abbildung zu FMIPv6 gezeigt, teilt der MN seine Prognose zum Netzwechsel in einer Fast Binding Update (FBU) Nachricht dem PAR mit. Letzterer handelt die Übergabeparameter mit dem NAR in einem HI-Hack Dialog aus. Nach erfolgreicher Verhandlung sieht das Protokoll die Errichtung eines Tunnels zwischen PAR und NAR vor, durch welchen der MN unterbrechungsfrei und transparent unter Nutzung seiner vorhergehenden CoA (pCoA) kommunizieren kann.
Um eine solche Prognose zu ermöglichen, stützt sich FMIPv6 dabei auf Layer-2 Informationen und auf eine Layer2-to-Layer3 Topologiekarte. Konsequenterweise erfordert dieser Ansatz Layer-2-spezifische Erweiterungen. FMIPv6 zielt auf das vollständige Verstecken des Netzübergangs um den Preis zusätzlicher Layer-2 Intelligenz ab. Schlägt der Vorhersageversuch fehl, fällt FMIPv6 auf ein reaktives Handover zurück.
BUs werden asynchron nach einem Netzwechsel zum HA und den CNs gesendet. Dabei birgt eine konzeptionelle Ungewissheit folgendes funktionales Risiko: Da der Zeitpunkt des Netzwechsels auf dem Layer-2 nicht allgemeingültig vorhergesehen werden kann und auch Phänomene wie das „Flackern“ zwischen Netzen möglich sind, kann eine Umleitung des Netzwerkverkehrs fehlschlagen und Datenverluste hervorrufen, die jene des MIPv6 Standards übersteigen.
Beide Ansätze, HMIPv6 im Mikromobilitätsszenario und FMIPv6 für Layer-2 bekannte Zugriffsinfrastrukturen, lösen die topologische Abhängigkeit der HO-Performanz und sind für Echtzeitkommunikation verwendbar.
Verbesserte Routen-Optimierung für MIPv6
Die Routenoptimierung ermöglicht als Schlüsseltechnologie einerseits die überlegenen Leistungscharakteristiken von MIPv6, andererseits birgt sie inhärente Sicherheitsrisiken. Die Vermeidung derselben bürdet dem Protokoll komplexe, verlangsamende Operationen auf.
In seinem Kern liegt das Sicherheitsproblem für BUs bzw. Service-Zugriffe darin, dass der MN den rechtmäßigen Besitz seiner HoA und damit seine permanente Identität nachweisen muss. Idealerweise täte er dies innerhalb einer kritischen Nachricht selbst. Denn gelänge es dem MN, einen verlässlichen Beweis für die Echtheit seiner Identität in einer einzigen, selbstkonsistenten Update-Nachricht zu erbringen, könnte MIPv6 als sicheres Protokoll für übergangslose Netzwerkmobilität betrachtet werden.
Schlüsseltechnik: Kryptographische Adessen
Erfreulicherweise wurde zeitgleich mit der Entwicklung von MIPv6 eine neue Anwendung eines Public Key Verfahrens konzipiert: Kryptographisch erzeugte Identifikatoren. Die „ Cryptographically Generated Addresses“ (CGA), können als Knotenadressen (Link Local Node Identifier) in IPv6 genutzt werden.
Verwendet ein Sender seinen öffentlichen Schlüssel als (kryptographische) Quelladresse, kann er dieses Paket mit seinem privaten Schlüssel signieren und somit den Empfänger in einer einzigen, selbstkonsistenten Nachricht befähigen, den Paketinhalt sowie die Absenderadresse zu authentifizieren. Hierzu wird keine zusätzliche Sicherheitsinfrastruktur wie eine PKI benötigt. Durch Anwendung dieses Verfahrens auf die Home Adresse des mobilen Knotens konnte eine verbesserte Routen-Optimierung als Standard definiert werden (RFC 4866).
Im Detail arbeitet dieser Mechanismus wie folgt (siehe: Abbildung zum optimierten, sicheren Binding Update): Zu Beginn konfiguriert der MN seine lokale Adresse als die ersten 64 Bits des SHA1 Hash-Werts einer CGA-Datenstruktur, welche im Wesentlichen aus seinem öffentlichen Schlüssel besteht. Zusammen mit dem Heimatpräfix entsteht so die Heimatadresse.
Zur Übermittlung einer sensiblen Nachricht, zum Beispiel eines Binding Update, fügt der MN diese HoA nicht nur in den regulären Home Address Destination Options Header der Nachricht ein, sondern inkludiert auch seine CGA Parameter, in welchen das Netzwerkpräfix enthalten ist. Dazu kommt seine CGA Signatur, welche über die CGA Parameter und die verbleibenden Paketdaten gebildet wird. Der Empfänger einer solchen Nachricht ist nun in der Lage, sowohl die HoA des Senders zu authentifizieren als auch die Integrität der Daten zu verifizieren. Dieser Beweis ist kryptographisch stark.
Die kryptographische HoA spielt bei der verbesserten Routen-Optimierung nicht die Rolle der Quelladresse innerhalb des Basiskopfes der Pakete, sondern ist ein Parameter in einer Erweiterungsstruktur. Um einem Missbrauch mithilfe künstlich erzeugter, kryptographischer HoAs vorzubeugen, muss jeder CN anfänglich die Erreichbarkeit dieser Adresse sicherstellen.
Allerdings wird dieser Test nur einmal benötigt und kann asynchron vor einem tatsächlichen Netzwechsel durchgeführt werden. Nach dieser Anfangsverifikation ist der MN von jedem Ort in der Welt aus in der Lage, seine Identität kryptographisch stark zu beweisen und ein BU durchzuführen. BUs können wie ein Rucksack mit regulären Datenpaketen transportiert werden (Piggybacking). Dadurch kann die mobile Kommunikation unmittelbar fortgesetzt werden, nachdem die IP Konfiguration im lokalen Netzwerk abgeschlossen ist.
Multicast-Erweiterungen
Ein besonderer, ausschließlich im Internet verfügbarer Dienst liegt in global verteiltem, skalierbarem und serverlosem Multicasting auf der Netzwerkschicht. Das Internet bietet so eine effiziente Unterstützung für Gruppenkommunikation, welche ein integraler Bestandteil einer Vielzahl von Anwendungen ist.
Multicast ist in einer mobilen Umgebung von besonderer Relevanz, da drahtlose Bandbreite knapp ist, aber geteilt wird und darüber hinaus Anwendungen leichtgewichtig sein müssen, um auch unter knappen Ressourcen batteriegetriebener Endgeräte lauffähig zu sein. Doch behandelt MIPv6 Multicast-Mobilität lediglich in groben Zügen – einerseits als reine Remote Subscription im besuchten Fremdnetz oder durch bidirektionales Tunneln über den HA.
Remote Subscription, ein neuerliches Multicast Join nach jedem Handover also, beruht auf der dynamischen Anpassung des Multicast Routings an die Ortsveränderungen des Clients und operiert damit vergleichsweise langsam. Bidirektionales Tunneln erzeugt ineffizienten Overhead und Übertragungsverzögerungen durch trianguläres Weiterleiten.
Somit kann keiner dieser beiden Ansätze als geeignete Lösung für den großflächigen Einsatz, etwa für ein mobiles IPTV angesehen werden. Ein mobiler Multicast Service für ein künftiges Internet sollte nahezu optimales Routing zu berechenbaren und begrenzten Kosten erlauben. Es sollte Robustheit mit Service-Qualität verbinden und so für die Medienübertragung in Echtzeit geeignet sein.
Die Forschungen im Bereich Multicast Mobilität werden seit über 10 Jahren betrieben und zeigen das Bild eines schwierigen aber lösbaren Problems. Eine Standardisierung beginnt gerade in einem frühen, vorläufigen Stadium. Für eine weiterführende Einführung in dieses Problem wird auf den Internet Draft „Multicast Mobility in MIPv6: Problem Statement and Brief Survey“ verwiesen.
Hoffnung
Die Kernkomponenten in der technischen Entwicklung und Standardisierung für das künftige mobile Internet sind nahezu abgeschlossen. Eine ausreichende Anzahl von Implementierungen und experimentellen Erfahrungen existieren. Folglich ist der Zeitpunkt für die praktische Verbreitung dieser Systeme jetzt gekommen – auch wenn zu hoffen bleibt, dass die Vorteile und Potentiale dieser neuen Mobilitätslösungen Provider und Administratoren lokaler Domänen überzeugen, die traditionelle Skepsis gegenüber neuen, offenen Ende-zu-Ende Lösungen zugunsten neuer Services zurückzustellen.
Das Autoren-Duo
Thomas C. Schmidt arbeitet für die Hochschule für Angewandte Wissenschaften Hamburg (HAW) im Department Informatik.
Matthias Wählisch ist für das Berliner Spin-off Link-Lab tätig, das sich auf Next Generation Mobile Internet spezialisiert hat.
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2009960)