-
Die
vorliegende Erfindung bezieht sich allgemein auf ein drahtloses
Internet. Insbesondere bezieht sich die vorliegende Erfindung auf
ein Verfahren und eine Vorrichtung zur Ermöglichung eines mobilen Knotens
(MN), um unter Verwendung einer mobilen Internet-Protokoll(IP)-Adresse auf ein virtuelles privates
Netzwerk (Virtual Private Netwerk – VPN) zuzugreifen.
-
Ein
herkömmliches
Internet, bei dem Hosts fest mit einem verdrahteten Netzwerk verbunden sind,
hat sich in jüngster
Zeit entwickelt, um MNs bei dem Roaming zwischen Netzwerken in der
Umgebung zu unterstützen,
in der ein verdrahtetes Netzwerk mit einem drahtlosen Netzwerk zusammenarbeitet.
Ein Protokoll, das entwickelt wurde, um die Mobilität der MNs über das
Internet zu unterstützen ist
das mobile IP. Das mobile IP ermöglicht
einem MN, die Kommunikation mit einem korrespondierenden Knoten
(CN) selbst dann aufrechtzuerhalten, wenn er seinen Zugangspunkt
(Access Point – AP) der
Verbindung mit dem Internet verändert.
-
Für mobile
Internet-Dienste wird ein mobiles Kommunikationsnetzwerk so konfiguriert,
dass es einen Home Agent (HA) umfasst, der sich innerhalb des Heimatnetzes
eines MN befindet, für
das Empfangen eines Pakets anstelle der MN und, um das Paket zu
einem fremden Netzwerk zu senden, wo sich der MN nun befindet, sowie
einen Foreign Agent (FA) für
das Empfangen des Pakets von dem HA für den MN in dem fremden Netzwerk.
-
Der
MN weist eine eindeutige lokale IP-Adresse auf, die den MN in dem
Heimatnetz als Home-of-Adresse (HoA) identifiziert. Da sich das
MB aus dem Heimatnetz heraus bewegt und mit dem fremden Netzwerk
verbindet, bezieht es eine Weiterleitungsadresse, durch die das
Heimatnetz ein Paket an das fremde Netzwerk weiterleitet, die Care-of-Adresse
(COA), und meldet dem HA die CoA. Dieses Verfahren wird Registrierung
genannt. Sobald der MN die CoA registriert, unterstützt der
HA die Mobilität
des MN durch Binding-Updates. Nachdem er ermittelt hat, dass er
außerhalb
des Heimatnetzes ist, sendet der MN die CoA unter Verwendung einer
Sicherheitsverbindung (Security Association – SA), die zwischen dem MN
und dem HA aufgebaut wird, zu dem HA.
-
Die
Erzeugung und Integrierung von Netzwerkumgebungen, die auf verschiedene
Arten entwickelt werden, fügen
einem integrierten Netz ebenso wie der existierenden verdrahteten
Umgebung Sicherheitsrisiken hinzu-. Eines der erforderlichen Dienstszenarien
ist die Verbindung der MNs mit einem VPN. In diesem Szenario muss
dem MN gestattet werden, während
des Roamings innerhalb des internen Netzwerks des VPN weiter zu
kommunizieren, oder sich zu einem externen Netzwerk zu bewegen. Zu
diesem Zweck arbeitet eine VPN-Technologie
mit einer Mobile-IP-Technologie zusammen.
-
Um
auf das VPN in einem fremden Netzwerk zuzugreifen, führt der
MN eine Mobile-IP-Registrierung
für fortlaufende
Kommunikationen über
das VPN durch. Der MN baut zunächst
unter Verwendung einer lokalen IP-Adresse, die von dem fremden Netzwerk
zugewiesen wird, einen IPsec-Tunnel mit einem VPN-Gateway auf, und
führt dann
unter Verwendung einer IP-Adresse, die in dem IPsec-Tunnel verwendet wird,
eine Mobile-IP-Registrierung
innerhalb des VPN durch, Co-located CoA (Co-CoA).
-
In
dem IPsec-Tunnel-Aufbauverfahren mit dem VPN-Gateway, weist das
VPN-Gateway oder ein anderer VPN-Knoten, zum Beispiel ein Dynamic Host
Configuration Protocoi(DHCP)-Server dem MN eine IP-Adresse (d. h.
Co-CoA) zu, die in dem VPN verwendet werden soll. Nach dem Empfang
einer Agent Advertisement-Nachricht von dem VPN-Gateway, nach dem Aufbau des IPsec-Tunnels
mit dem VPN-Gateway, meldet der MN die Co-CoA bei dem HA an. Der
MN wird von dem HA während
der Mobile-IP-Registrierung einer HoA dynamisch zugewiesen, und
ist dann in der Lage, unter Verwendung der HoA mit einem anderen
MN innerhalb des VPN zu kommunizieren.
-
Wie
oben beschrieben, unterstützt
die herkömmliche
VPN-Mobile-Zusammenarbeit-Technologie
die Mobilität
des MN unter Verwendung der Mobile-IP innerhalb des VPN. Ein unverkennbarer
Mangel bei der Zusammenarbeit-Technologie besteht jedoch darin,
dass drei IP-Adressen für
jeden MN erforderlich sind, nämlich
eine lokale IP-Adresse, die in dem fremden Netzwerk verwendet wird,
die Co-CoA, die verwendet wird, um den IPsec-Tunnel zwischen dem MN
und dem VPN-Gateway zu erzeugen, und die HoA des MN. Da ein Paket,
das den IPsec-Tunnel durchläuft,
zusätzlich
in einem Mobile-IP-Tunnel-Header gekapselt wird, ist der Paketübertragungs-Overhead
zwischen dem MN und dem VPN-Gateway groß.
-
Ein
Dokument mit dem Titel „Diameter
Mobile IPv6 Application" beschreibt,
dass mobile Knoten nach dem Mobile-IPv6-Standard sich in Netzwerke ihres
Heimat-Dienst-Providers ebenso einwählen können wie in andere Netzwerke.
Das Roaming in fremden Netzwerken wird als Ergebnis des Dienst-Niveaus
und der Roaming-Vereinbarungen, die zwischen den Betreibern bestehen,
ermöglicht. Eines
der Schlüsselprotokolle,
das die Aktivierung dieser Art von Roaming-Mechanismus gestattet,
ist Diameter. Es wird eine verbesserte Protokollübersicht bereitgestellt, die
beschreibt, dass der verbesserte Modus eine dynamische Home-Agent-Zuweisung
in dem besuchten Netzwerk und eine dynamische Heimatadressen-Zuweisung ermöglicht.
In dem verbesserten Modus sind alle Funktionalitäten (Schlüsselverteilung, Optimierung
des Binding-Updates, dynamische Home-Agent-Zuweisung im Heimatnetz)
eines Basisknotens vorhanden, aber der Home Agent kann zusätzlich in
dem besuchten Netzwerk zugewiesen werden, und die Heimatadresse kann
entweder in der Heimat-Domain
oder der besuchten Domain dynamisch zugewiesen werden. Wenn der
mobile Knoten keine Heimatadresse aufweist und eine anfordert, kann
der mobile Knoten außerdem
einige MIP-Eigenschaftsdaten beinhalten, wobei das für die Mobilknoten-Heimatadresse
erforderliche Flag auf eins eingestellt ist. Der Home Agent wird
dann durch einen AAA-Server
zugewiesen, und das Binding-Update wird durch den AAA-Server im Auftrag
des mobilen Knotens zu einem Home Agent gesendet. Während der
mobile Knoten authentifiziert und autorisiert wird, wenn der mobile
Knoten schon eine Heimatadresse und einen Home Agent aufweist, kann
er ein Home-Binding-Update zusammen mit der Anforderung senden,
um autorisiert und authentifiziert zu werden, um sicher über den
Zugangs-Link und zwischen den besuchten Netzen und dem Heimatnetz
herum zu laufen. Der mobile Knoten kann mit einem AAA-Client zusammenarbeiten,
um die Authentifizierung/Autorisierung und optional die mobilen
IP-Abläufe
durchzuführen.
Deshalb kann der AAA-Client Authentifizierungsfunktionen und optional mobile
IP-Funktionen durchführen.
Wenn ein AAA-Home-Server
akzeptiert, dass die Home Agents den besuchten Domains zugewiesen
werden, findet ein Nachrichtenaustausch statt, wobei der AAA-Home-Server
eine HOR-Nachricht ohne Adress-AVPs zu einem AAA-Besucher-Server
sendet. Dort kann der AAA-Besucher einem mobilen Knoten eine Heimat-IP
zuweisen und informiert den Home Agent durch das Hinzufügen einer
Mobilknotenadress-AVP in der HOR-Nachricht, oder er lässt den
Home Agent die Heimatadresse durch das Nichtbereitstellen einer Mobilknotenadress-AVP
in der HOR-Nachricht
zuweisen. Der AAA-Home-Server ist durch die HOR-Nachricht, die von
dem AAA-Besucher-Server gesendet
wird, über
die zugewiesene Heimat-IP-Adresse (enthalten in der Mobilknotenadress-AVP)
und die Home Agent-Adresse (enthalten in der Home Agent-Adress-AVP) informiert.
-
Ein
Dokument mit dem Titel „Mobile
IPv6 Using Gateway Home Agent" schlägt einen
Mechanismus vor, der VPN und mobile IP-Funktionen kombiniert. Dieser
Mechanismus verwendet eine hierarchische HA-Architektur und beinhaltet
einen HA mit GW-Funktionen, der Gateway-Home-Agent (GHA) genannt
wird. Um eine Neuaushandlung zu vermeiden, muss ein VPN GW eine
Mobilknoten(MN)-Heimatadresse (HoA) anstelle seiner Care-of-Adresse (CoA)
für IPsec-Endpunkte
verwenden, was erfordert, dass das VPN GW mobile IP-Funktionen aufweisen
muss, weil es die HoA-Option verstehen muss. Ein VPN GW mit einer
mobilen IP CN-Funktion kann IPsec mit der Heimatadresse eines mobilen Knotens
einrichten, aber der mobile Knoten muss zwei Einding-Updates senden,
eines für
das VPN GW und eines für
den Home Agent. Der Mechanismus verwendet eine Home-Agent-Architektur
und beinhaltet einen Home Agent mit Gateway-Funktionen, der Gateway-Home-Agent
(GHA) genannt wird. Die Beziehung zwischen dem Gateway-Home-Agent und
einem Home Agent ist fast dieselbe wie die zwischen einem Foreign
Agent und einem Home Agent in einem mobilen IPv4.
-
Die
vorliegende Erfindung ist darauf ausgerichtet wenigstens die oben
erwähnten
Probleme und/oder Nachteile zu lösen
und mindestens die nachstehend beschriebenen Vorteile zu bieten.
-
Dementsprechend
ist es das Ziel der vorliegenden Erfindung ein verbessertes Verfahren
und eine verbesserte Vorrichtung bereitzustellen, die einem MN gestatten
eine FA-CoA anstelle einer Co-CoA zu verwenden, während er
eine mobile IP in einem virtuellen privaten Netzwerk verwendet.
-
Dieses
Ziel wird durch den Gegenstand der Hauptansprüche erreicht.
-
Bevorzugte
Ausführungsformen
werden durch die Unteransprüche
definiert.
-
Ein
Gesichtspunkt der vorliegenden Erfindung ist es, ein Verfahren und
eine Vorrichtung zur Verhinderung einer Überdeckung zwischen einem IPsec-Tunnel,
der für
ein VPN konfigu riert ist, und einem IP-in-IP-Tunnel, der für eine mobile
IP konfiguriert ist, bereitzustellen, während eine mobile IP in dem
VPN verwendet wird.
-
Das
Obige wird durch die Bereitstellung eines Kommunikationsverfahrens
und einer Kommunikationsvorrichtung erreicht, welche die IP-Adresse eines
Gateway für
einen MN in einem VPN nach den Hauptansprüchen 1 und 17 verwenden.
-
Nach
einem beispielhaften Gesichtspunkt der vorliegenden Erfindung überträgt der MN
in einem Verfahren der Zuweisung einer HoA zu einem MN in einem
VPN eine Authentifizierungs-Anforderungsnachricht zu einem Gateway
des VPN, die eine Zuweisung einer HoA anfordert. Das Gateway bezieht
die HoA, die von einem HA, die den MN im Auftrag des MN verwaltet,
zugewiesen wird, und überträgt eine
Authentifizierungs-Antwortnachricht, welche die zugewiesene HoA
umfasst, an den MN. Der MN kommuniziert unter Verwendung der HoA
durch das Gateway mit einem CN.
-
Nach
einem weiteren beispielhaften Gesichtspunkt der vorliegenden Erfindung
befinden sich, zur Zuweisung einer HoA zu einem MN in einem VPN,
ein HA und ein FA in dem VPN. Ein Gateway empfängt eine Authentifizierungs-Anforderungsnachricht,
welche die Zuweisung einer HoA von dem MN, der auf das VPN zugreifen
möchte,
für die
Verwendung in dem VPN anfordert, bezieht die HoA, die von dem HA
im Auftrag des MN zugewiesen wird, und überträgt eine Authentifizierungs-Antwortnachricht,
welche die zugewiesene HoA umfasst, an den MN, so dass der MN unter
Verwendung der HoA mit einem CN kommuniziert.
-
Nach
einem weiteren beispielhaften Gesichtspunkt der vorliegenden Erfindung überträgt der MN
eine Authentifizierungs-Anforderungsnachricht, die eine Zuweisung
einer HoA anfordert, an ein Gateway des VPN, sobald eine HoA in
einem MN in einem VPN zugewiesen wird. Der MN empfängt von
dem Gateway eine Authentifizierungs-Antwortnachricht, welche eine
durch einen HA, der den MN verwaltet, zugewiesene HoA für den MN
umfasst. Der MN kommuniziert unter Verwendung der HoA durch das Gateway
mit einem CN.
-
Nach
noch einem weiteren beispielhaften Gesichtspunkt der vorliegenden
Erfindung, empfängt das
Gateway von dem MN eine Authentifizierungs-Anforderungsnachricht,
die eine Zuweisung einer HoA anfordert, sobald eine HoA für einen
MN in einem Gateway eines VPN zugewiesen wird. Das Gateway bezieht
die HoA für
die Verwendung in dem VPN von einem HA, der den MN im Auftrag des
MN verwaltet. Das Gateway überträgt eine
Authentifizierungs-Antwortnachricht, welche die zugewiesene HoA
für den
MN beinhaltet, und leitet die Kommunikationen zwischen dem MN und
einem CN unter Verwendung der HoA weiter.
-
Die
vorliegende Erfindung wird durch die folgende ausführliche
Beschreibung der beispielhaften Ausführungsformen der vorliegenden
Erfindung deutlicher, wenn sie zusammen mit den beiliegenden Zeichnungen
betrachtet wird, in denen gleiche Bezugszeichen so verstanden werden,
dass sie sich auf gleiche Bauteile, Komponenten und Strukturen beziehen,
wobei Folgendes gilt:
-
1 stellt
die Konfiguration eines VPN nach einer beispielhaften Ausführungsform
der vorliegenden Erfindung dar;
-
2 ist
ein Diagramm, das einen Signalfluss für einen MN-Anfangszugang zu
dem VPN nach einer beispielhaften Ausführungsform der vorliegenden
Erfindung darstellt;
-
3 ist
ein Ablaufdiagramm, das die Funktionsweise eines MN nach einer beispielhaften
Ausführungsform
der vorliegenden Erfindung darstellt;
-
4 ist
ein Ablaufdiagramm, das die Funktionsweise eines VPN GW, das als
ein MN-Proxy und ein
FA dient, nach einer beispielhaften Ausführungsform der vorliegenden
Erfindung darstellt;
-
5 ist
ein Ablaufdiagramm, das die Funktionsweise eines AAA-Servers nach
einer beispielhaften Ausführungsform
der vorliegenden Erfindung darstellt;
-
6 stellt
eine Netzwerkkonfiguration dar, in der ein 3G RAN mit einem WLAN
nach einer ersten beispielhaften Implementierung einer Ausführungsform
der vorliegenden Erfindung zusammenarbeitet;
-
7 ist
ein Diagramm, das einen Signalfluss für einen MN, der durch ein WLAN
auf ein Kernnetz (CN) zugreift, nach einer zweiten beispielhaften Implementierung
einer Ausführungsform
der vorliegenden Erfindung darstellt;
-
8 ist
ein Ablaufdiagramm, das die Funktionsweise eines PDG, das sowohl
als ein MN-Proxy als
auch als ein FA arbeitet, nach der zweiten beispielhaften Implementierung
einer Ausführungsform der
vorliegenden Erfindung darstellt; und
-
9 ist
ein Ablaufdiagramm, das die Funktionsweise eines GGSN, der als ein
HA arbeitet, nach der zweiten beispielhaften Implementierung einer Ausführungsform
der vorliegenden Erfindung darstellt.
-
Bestimmte
beispielhafte Ausführungsformen der
vorliegenden Erfindung werden hierin nachstehend mit Bezug auf die
beiliegenden Zeichnungen beschrieben. In der folgenden Beschreibung
werden wohlbekannte Funktionen und Konstruktionen der Klarheit und
Kompaktheit wegen weggelassen.
-
Eine
beispielhafte Eigenschaft der vorliegenden Erfindung, wie sie nachstehend
beschrieben wird, ist, dass ein MN eine Foreign Agent-Care-of-Adresse
(FA-CoA) anstelle einer Co-CoA
in einer Mobile-IP-Registrierung für einen HA verwendet. Die FA-CoA
bezieht sich auf eine IP-Adresse eines VPN-Gateway. Zu diesem Zweck
verwendet der MN eine HoA als seine IP-Adresse innerhalb eines IPsec-Tunnels,
den der MN mit dem VPN-Gateway aufgebaut hat. Der MN wird jedoch
der HoA durch die Mobile-IP-Registrierung nicht zugewiesen, bis
der IPsec-Tunnel erzeugt wird. Während
der Erzeugung des IPsec-Tunnels führt in diesem Zusammenhang das
VPN-Gateway im Auftrag des MN die Mobile-IP-Registrierung durch
und bezieht die HoA des MN von dem HA des MN nach einer beispielhaften Implementierung
einer Ausführungsform
der vorliegenden Erfindung.
-
Die
Konfiguration und Funktionsweise eines Netzwerks nach einer beispielhaften
Ausführungsform
der vorliegenden Erfindung wird mit Bezug auf 1 beschrieben.
-
Bezüglich 1 besteht
ein VPN 101 aus einer Vielzahl von Teilnetzen 102a und 102b in
einem Intranet und einem Teilnetz 102c für einen
MN 107 in einem (nicht gezeigten) externen Netzwerk, zum
Beispiel einem drahtlosen lokalen Netzwerk (WLAN). Ein VPN-Gateway
(GW) 105 befindet sich als eine Komponente des VPN 101 in
dem Teilnetz 102c. Die Teilnetze 102a, 102b und 102c dienen
getrennt als ein Heimatnetz und ein fremdes Netzwerk. Ein HA 103 befindet
sich in dem Heimatnetz und ein FA 104 befindet sich in
dem fremden Netzwerk. Das Teilnetz 102c ist immer ein fremdes
Netzwerk in Mobile-IP, und das VPN GW 105 arbeitet als
ein FA.
-
Das
VPN 101 beinhaltet ferner einen Authentifizierungs-, Autorisierungs-
und Abrechnungs-(AAA)-Server 104 für die Verwendung
von Mobile-IP in dem VPN 101. Sicherheitskanäle 108a, 108b und 108c werden
zwischen dem AAA-Server 106 und dem HA 103, zwischen
dem AAA-Server 106 und dem FA 104 und zwischen
dem AAA-Server 106 und dem VPN GW 105 aufgebaut.
Der AAA-Server 106 authentifiziert Knoten, die auf das
VPN 101 zugreifen möchten.
Er authentifiziert ebenfalls eine Mobile IP-Registrierungsanforderung,
die eine Mobile-AAA-Authentifizierungserweiterung beinhaltet und erzeugt
eine Zufallszahl (RAND) und einen gemeinsam benutzten geheimen Schlüssel, der
notwendig ist, um eine Mobility Security Association (MSA) zu erzeugen.
-
Der
MN 107 wird einer HoA als eine IP-Adresse für die Verwendung
in dem VPN 101 dynamisch zugewiesen. Während er anfänglich auf
das VPN 101 von dem Heimatnetz in dem Intranet zugreift,
wird der MN 107 von dem HA 103 oder einem (nicht
gezeigten) DHCP-Server
einer IP-Adresse zugewiesen. In dem Fall, in dem der MN 107 anfänglich von
einem fremden Netzwerk in dem Intranet auf das VPN 101 zugreift,
wird er durch die dynamische Adressenzuweisung des Mobile-IP einer
IP-Adresse zugewiesen.
-
Wenn
der MN 107 anfänglich
außerhalb
des Intranets auf das VPN 101 zugreift, kann ihm einer IP-Adresse
zugewiesen werden, um über
das VPN GW 105 während
der Erzeugung eines IPsec-Tunnels mit dem VPN GW 105 von
dem HA 103 als eine HoA verwendet zu werden. Sobald der
MN 107 sich außerhalb
des Intranets befindet, führt
das VPN GW 105 im Auftrag des MN 107 unter Verwendung
einer FA-CoA eine Mobile-IP-Registrierung durch. Die FA-CoA ist
die IP-Adresse des VPN GW 105. Auf diese Weise wird der
MN 107 von dem externen Netzwerk keiner zusätzlichen
IP-Adresse zugewiesen, während
er sich in dem externen Netzwerk befindet. Deshalb wird die unnötige Verwendung
einer IP-Adresse vermieden.
-
Wie
oben dargelegt, führt
das VPN GW 105 im Auftrag des MN 107 eine Mobile-IP-Registrierung durch,
wird als eine HoA für
den MN 107 von dem HA 103 dynamisch zugewiesen
und stellt die HoA für
den MN 107 bereit, sobald der IPsec-Tunnel zwischen dem
MN 107 und dem VPN GW 105 erzeugt wird. Deshalb
wird der IPsec-Tunnel abgeschlos sen. Da das VPN GW 105 die
Mobile-IP-Registrierung anstelle des MN 107 durchführt, wird
es ein VPN GW/MN-Proxy genannt.
-
Eine
MSA zwischen dem MN 107 und dem HA 103 wird zur
Authentifizierung einer Mobile-IP-Registrierungsnachricht
verwendet. Wenn die MSA zwischen dem MN 107 und dem HA 103 nicht existiert,
wird die MSA während
der Mobile-IP-Registrierung erzeugt. Um das zu tun, beinhaltet die
Mobile-IP-Registrierungs-Anforderungsnachricht, die an den AAA-Server 106 übertragen
wird, eine Mobile-Home Key Generation Nonce-Anforderungserweiterung
und eine Mobile-AAA-Authentifizierungs-Erweiterung.
-
Um
eine Mobile-AAA-Authentifizierungs-Erweiterung zu erzeugen, wird
ein AAA-SA-Setup zwischen dem MN 107 und dem AAA-Server 106 verwendet.
Die AAA SA besteht aus einem Sicherheitsparameterindex (Security
Parameter Index – SPI), der
die AAA SA identifiziert, einem AAA-Schlüssel, der ein gemeinsam genutzter
geheimer Schlüssel zwischen
zwei Einheiten ist, welche die AAA SA gemeinsam benutzen, und anderen
Sicherheitsparametern. Um eine Mobile-IP-Registrierung um Auftrag des
MN 107 durchzuführen,
muss das VPN GW 105 Kenntnis von den Inhalten der AAA SA
erhalten, insbesondere des AAA-Schlüssels und
des SPI, um die Mobile-AAA-Authentifizierungs-Erweiterung zu erzeugen.
-
Während üblicherweise
eine oder mehrere AAA SAs zwischen dem MN 107 und dem AAA-Server 106 in
einem Mobile-IP existieren, wird die AAA SA in der folgenden Weise
dynamisch zugewiesen, so dass das VPN GW 105 den AAA-Schlüssel und den
SPI der AAA SA nach einer beispielhaften Ausführungsform der vorliegenden
Erfindung beziehen kann.
-
In
dem Vorgang des Zugreifens auf das VPN 101 durch den MN 107 und
der Authentifizierung des MN 107 durch den AAA-Server 106 wird
die AAA SA dynamisch zwischen dem MN 107 und dem AAA-Server 106 erzeugt.
in der AAA SA wird der AAA-Schlüssel
auf einen Master Session Key (MSK) eingestellt, der während der
auf dem Extensible Authentication Protocol (EAP) basierenden Authentifizierung
erzeugt wird, und andere Sicherheitsparameter werden auf vorbestimmte
Werte eingestellt. Insbesondere wird der SPI der AAA SA auf einen
Wert eingestellt, der dem VPN GW 105 bekannt ist.
-
Da
das VPN GW 105 den MSK von dem AAA-Server 106 während der
Authentifizierung des MN 107 durch das EAP in dem AAA-Server 106 empfängt, erhält er eventuell
den AAA- Schlüssel der
AAA SA. Das VPN GW 105 führt unter Verwendung einer Mobile-AAA-Authentifizierungs-Erweiterung,
die mit dem AAA-Schlüssel
und dem bekannten SPI der AAA SA erzeugt wird, die Mobile-IP-Registrierung
im Auftrag des MN 107 durch.
-
Die
folgende Beschreibung ist eine beispielhafte Implementierung, wobei
eine Internet-Schlüssel-Austauschversion
(Internet Key Exchange Version 2 – IKEv2) bei der Erzeugung
eines IPsec-Tunnels verwendet wird, und das EPA wird für die gegenseitige
Authentifizierung von IKEv2 verwendet.
-
2 ist
ein Diagramm, das einen Signalfluss für einen MN-Anfangszugang zu
dem VPN nach einer beispielhaften Ausführungsform der vorliegenden
Erfindung darstellt. In dem dargestellten Fall von 2 dient
der MN 107 als ein Initiator für die Initialisierung eines
IKE und das VPN GW 105 dient als ein Antwortsender.
-
Bezüglich 2 überträgt der MN 107 in Schritt 201 eine
IKE_SA_INIT-Anforderungsnachricht
an das VPN GW 105 und empfängt in Schritt 202 die
IKE_SA_INIT-Antwortnachricht
von dem VPN GW 105, wodurch er eine IKE SA mit dem VPN GW 105 aushandelt.
In Schritt 203 überträgt der MN 107 eine
IKE_AUTH-Anforderungsnachricht an das VPN GW 105.
-
Durch
Ausschließen
von AUTH-Nutzdaten von der IKE_AUTH-Anforderungsnachricht, schlägt der MN 107 dem
EAP die gegenseitige Authentifizierung vor und beginnt gleichzeitig
die erste Nachfolger-SA mit dem VPN GW 105 auszuhandeln.
Eine ID des Initiators (IDi), die in der IKE_AUTH-Anforderungsnachricht
enthalten ist, wird auf einen Netzwerk-Zugangsidentifikator (Network Access
Identifier – NAI)
des MN 107 eingestellt. Der NAI, der eine Standardsyntax
aufweisen kann, die durch Anforderung nach Kommentaren (Request
For Comments – RFC) 2486 definiert
wird, wird dem MN 107 eindeutig zugewiesen.
-
Der
MN 107 fordert außerdem
eine Zuweisung einer IP-Adresse für die Verwendung innerhalb des
VPN 101 für
das VPN GW 105 an, indem die Konfigurations-Nutzdaten (Configuration
payload – CP)
vor den SA-Nutzdaten in der IKE_AUTH-Anforderungsnachricht eingeschlossen
werden. In dem Fall, in dem der MN 107 mit dem IKE mit
einem Sicherheits-Gateway
wie dem VPN GW 105 fortfährt, sind die CP-Nutzdaten
in der IKE_AUTH-Anforderungsnachricht
für den
MN 107 enthalten, um eine IP-Adresse, die in dem VPN 101 verwendet
werden soll, von dem externen Netzwerk durch das VPN GW 105 anzufordern.
Die CP-Nutzdaten werden in Schritt 203 auf null eingestellt.
-
Sobald
entschieden wird, dass die IKE_AUTH-Anforderungsnachricht EAP eine
gegenseitige Authentifizierung vorschlägt, meldet das VPN GW 105 dem
MN 107 in Schritt 204 den Start der EAP-Authentifizierung
durch das Übertragen
einer EAP-Anforderungsnachricht. In Schritt 205 authentifiziert
der AAA-Server 106 den MN 107 durch Routing des
VPN GW 105. Wenn die Authentifizierung erfolgreich ist, überträgt der AAA-Server 106 eine EAP-Erfolgsnachricht
an das VPN GW 105, um dem MN 107 in Schritt 206 die
erfolgreiche Authentifizierung zu melden. Das VPN GW 105 leitet
die EAP-Erfolgsnachricht in Schritt 207 weiter an den MN 107.
In Schritt 208 erzeugen der MN 107 und der AAA-Server 106 unter
Verwendung des MSK, der während der
Authentifizierung von Schritt 205 erzeugt wird, eine AAA
SA. Wenn die AAA SA bereits existiert, aktualisieren sie die AAA
SA. Die AAA SA-Erzeugung
in dem AAA-Server 106 findet vor der Übertragung der EAP-Erfolgsnachricht
in Schritt 206 statt.
-
In
Schritt 209 erzeugt der MN 107 unter Verwendung
des MSK AUTH-Nutzdaten und überträgt eine
IKE_AUTH-Nachricht, welche die AUTH-Nutzdaten beinhaltet, an das
VPN GW 105. Nach Empfang der IKE_AUTH-Nachricht, prüft das VPN
GW 105, ob der MN 107 die Zuweisung einer IP-Adresse angefordert
hat, indem in Schritt 203 die CP-Nutzdaten in dem IKE_AUTH-Anforderungsnachricht
enthalten sind. Wenn der MN 107 keine Zuweisung einer IP-Adresse
angefordert hat, überträgt das VPN
GW 105 eine IKE_AUTH-Antwortnachricht unmittelbar an den
MN 107, wodurch die gegenseitige Authentifizierung und
die Nachfolger-SA-Aushandlung
abgeschlossen sind.
-
Wenn
andererseits der MN 107 die Zuweisung einer IP-Adresse
angefordert hat, erzeugt das VPN GW 105 eine Mobile-IP-Registrierungs-Anforderungsnachricht
und überträgt sie durch
ein AAA-Protokoll an den AAA-Server 106, um in Schritt 210 eine
Mobile-IP-Registrierung
im Auftrag von MN 107 durchzuführen. Die Mobile IP-Registrierungs-Anforderungsachricht
beinhaltet eine NAI-Erweiterung, eine Mobile-Home Key Generation
Nonce-Anforderungserweiterung und eine Mobile-AAA-Authentifizierungserweiterung,
um eine dynamische Zuweisung einer HoA und die Erzeugung einer MSA
mit dem HA 103 anzufordern, das heißt, eine Mobile-Home MSA. In
der Mobile-IP-Registrierungs-Anforderungsnachricht
wird eine HoA auf 0.0.0.0 eingestellt, und eine CoA wird auf die
IP- Adresse (d. h.,
FA-CoA) des VPN GW 105 eingestellt. Die NAI-Erweiterung wird
durch die IDi der IKE_AUTH-Anforderungsnachricht, die in Schritt 203 empfangen
wird, erzeugt, und die Mobile-AAA-Authentifizierungserweiterung
wird durch einen AAA-Schlüssel
erzeugt, der in Schritt 205 erzeugt wird, das heißt, durch
einen MSK und einen bekannten SPI. Verfahren, die zur Erzeugung der
Erweiterungen verwendet werden können,
sind Fachleuten bekannt, und deren Beschreibungen werden der Kompaktheit
wegen weggelassen.
-
Nach
Empfang der Mobile-IP-Registrerungs-Anforderungsnachricht von dem
VPN GW 105 authentifiziert der AAA-Server 106 in
Schritt 211 die Mobile-IP-Registrierungs-Anforderungsnachricht durch
Prüfen
der Mobile-AAA-Authentifizierungserweiterung, die in der Nachricht
enthalten ist. Wenn die Authentifizierung erfolgreich ist, wählt der AAA-Server 106 eine
RAND und erzeugt unter Verwendung der RAND einen gemeinsam verwendeten geheimen
Schlüssel
für eine
Mobile-Hume MSA. In Schritt 212 überträgt der AAA-Server 106 durch
dass AAA-Protokoll die Mobile-IP-Registrierungs-Anforderungsnachricht,
die RAND und den gemeinsam verwendeten geheimen Schlüssel an
den HA 103 des MN 107.
-
Der
HA 103 weist dem MN 107 eine HoA dynamisch zu,
erzeugt eine Mobile-Home MSA und erzeugt eine Mobile-IP-Registrierungs-Antwortnachricht,
welche die HoA enthält.
in Schritt 213 überträgt der HA 103 die
Mobile-IP-Registrerungs-Antwortnachricht durch das AAA-Protokoll
an den AAA-Server 106. Der AAA-Server 106 leitet
in Schritt 214 die Mobile-IP-Registrierungs-Antwortnachricht durch das
AAA-Protokoll an das VPN GW 105 weiter. Das VPN GW 105 bezieht
die HoA des MN 107 von der Mobile-IP-Registrierungs-Antwortnachricht
und bewahrt die Mobile-IP-Registrerungs-Antwortnachricht für eine vorbestimmte
Zeitspanne auf.
-
in
Schritt 215 beendet das VPN GW 105 die gegenseitige
Authentifizierung und die Nachfolger-SA-Aushandlung durch Übertragen
einer IKE_AUTH-Antwortnachricht an den MN 107. Die IKE_AUTH-Antwortnachricht
beinhaltet die CP-Nutzdaten und die Verkehr-Auswahl-Nutzdaten (Traffic Selection
Payloads – TSs)
des Initiators und des Antwortsenders. Die TSs (TSi und TSr) werden
verwendet, um Pakete zu identifizieren, die durch den IPsec-Tunnel
laufen können.
Sobald die CP-Nutzdaten verwendet werden, werden die TSs gemäß den CP-Nutzdaten
bestimmt. Das VPN GW 105 meldet dem MN 107 eine
IP-Adresse, die
innerhalb des IPsec-Tunnels verwendet werden soll, indem es die HoA
in den CP-Nutzdaten auf die IKE_AUTH-Antwortnachricht einstellt.
-
Nach
Schritt 215 wurde der MN 107 mit dem VPN 101 verbunden.
Um die Mobilität
des MN 107 zu unterstützen,
fordert das VPN GW 105 in Schritt 216 den MN 107 auf,
eine Mobile-IP-Registrierung
durch Übertragen
einer Agent Advertisement-Nachricht durchzuführen. In Schritt 217 überträgt der MN 107 eine
Mobile-IP-Registrierungs-Anforderungsnachricht an das VPN GW 105.
Das VPN GW 105 überträgt die aufbewahrte
Mobile-IP-Registrierungs-Antwortnachricht
in Schritt 219 an den MN. Deshalb erzeugt der MN 107 die
MSA mit dem HA 103 und weist seine HoA auf, durch welche
er in dem VPN 101 kommuniziert.
-
Nun
wird eine Beschreibung der Funktionsweisen des MN, des VPN GW und
des AAA-Servers nach
einer exemplarischen Ausführungsform
der vorliegenden Erfindung gegeben.
-
3 ist
ein Ablaufdiagramm, das die Funktionsweise des MN nach einer exemplarischen
Ausführungsform
der vorliegenden Erfindung darstellt.
-
Bezüglich 3 ist
Schritt 301 ein früher
Zustand der Erzeugung eines IPsec-Tunnels zwischen dem MN und dem
VPN GW. Der MN überträgt eine IKE_SA_INIT-Anforderungsnachricht
an das VPN GW und empfängt
eine IKE_SA_INIT-Antwortnachricht von dem VPN GW, wodurch in Schritt 301 eine IKE
SA ausgehandelt wird. In Schritt 302 entscheidet der MN,
ob er schon eine HoA aufweist. Bei einem anfänglichen Zugang zu dem VPN
weist der MN keine HoA auf. Sobald sich der MN von dem Intranet
zu einem externen Netzwerk bewegt oder sich zwischen externen Netzwerken
bewegt, weist der MN im Gegensatz dazu schon eine HoA auf.
-
Bei
dem Vorhandensein einer HoA, beginnt der MN eine Nachfolger-SA-Aushandlung
und schlägt
EAP eine gegenseitige Authentifizierung vor, indem in Schritt 303 eine
IKE_AUTH-Anforderungsnachricht
ohne AUTH-Nutzdaten an das VPN GW übertragen wird. In der IKE_AUTH-Anforderungsnachricht
enthält
eine IDi den NAI des MN. In Schritt 305 wird der MN durch
den AAA-Server EAP-authentifiziert. Wenn die Authentifizierung erfolgreich
ist, erzeugt/aktualisiert der MN in Schritt 307 unter Verwendung
des MSK, der während
der Authentifizierung erzeugt wird, eine AAA SA zwischen dem MN
und dem AAA-Server. Der MN überträgt eine IKE_AUTH-Nachricht,
die AUTH-Nutzdaten enthält, die
unter Verwendung des MSK erzeugt werden, an das VPN GW und empfängt eine
IKE_AUTH-Antwortnachricht von dem VPN GW, wodurch die gegenseitige
Authentifizierung und die Nachfolger-SA-Aushandlung in Schritt 309 beendet
wird.
-
Bei
dem Fehlen der HoA in Schritt 302, fordert der MN andererseits
gleichzeitig die Zuweisung einer IP-Adresse als eine HoA innerhalb
eines IPsec-Tunnels an, beginnt die Nachfolger-SA-Aushandlung und
schlägt
dem EAP eine gegenseitige Authentifizierung für das VPN GW vor, indem in Schritt 304 eine
IKE_AUTH-Anforderungsnachricht mit CP-Nutzdaten aber ohne AUTH-Nutzdaten übertragen
wird. In Schritt 306 wird der MN durch den AAA-Server EAP-authentifiziert.
Der MN erzeugt/aktualisiert in Schritt 308 unter Verwendung
des MSK, der während
der Authentifizierung erzeugt wird, eine AAA SA zwischen dem MN
und dem AAA-Server. Der MN überträgt eine
IKE_AUTH-Nachricht, die AUTH-Nutzdaten enthält, die unter Verwendung des MSK
erzeugt werden, an das VPN GW und empfängt eine IKE_AUTH-Antwortnachricht
von dem VPN GW, wodurch die IP-Adresse für die Verwendung innerhalb
des IPsec-Tunnels bezogen wird und die gegenseitige Authentifizierung
und die Nachfolger-SA-Aushandlung in Schritt 310 beendet
wird.
-
Nach
Schritt 309 oder Schritt 310 ist der MN nun in
der Lage in dem VPN zu kommunizieren. Zur Unterstützung der
Mobilität
des MN in dem VPN, muss der MN eine Mobile-IP-Registrierung durchführen. Dazu empfangt der MN
in Schritt 311 eine Agent Advertisement-Nachricht von dem VPN GW und überträgt in Schritt 312 eine
Mobile IP-Registrierungs-Anforderungsnachricht
an den HA. Für
das Senden der Mobile IP-Registrierungs-Anforderungsnachricht erzeugt der MN
unter Verwendung einer Mobile IP NAI-Erweiterung, einer Mobile-Home
Key Generation Nonce-Anforderungserweiterung und einer Mobile-AAA-Authentifizierungs-Erweiterung
eine Mobile-Home MSA. Die Mobile-AAA-Authentifizierungs-Erweiterung wird
unter Verwendung einer AAA SA, die in Schritt 307 oder
Schritt 308 erzeugt wird, erzeugt. Nach Empfang einer Mobile-IP-Registrierungs-Antwortnachricht
kann der MN das VPN in Schritt 313 verwenden, wobei seine
Mobilität
unterstützt
wird.
-
4 ist
ein Ablaufdiagramm, das die Funktionsweise des VPN GW nach einer
beispielhaften Ausführungsform
der vorliegenden Erfindung darstellt.
-
Bezüglich 4 handelt
das VPN GW eine IKE SA mit dem MN aus, indem in Schritt 401 eine IKE_SA_INIT-Anforderungsnachricht
von dem MN empfangen wird und eine IKE_SA_INIT-Antwortnachricht
an den MN übertragen
wird. Nach Empfang der IKE_SA_INIT-Anforderungsnachricht ohne AUTH-Nutzdaten
von dem MN, unterstützt
das VPN GW den AAA-Server dabei, den MN in Schritt 402 zu EAP-authentifizieren,
der als eine Front und ein Authentifikator des AAA-Servers arbeitet.
Wenn die Authentifizierung er folgreich ist, empfängt das VPN GW einen MSK, der
sich aus der EAP-Authentifizierung von dem AAA-Server ergibt, und
vervollständigt
die Vorbereitung für
die gegenseitige Authentifizierung mit dem MN.
-
In
Schritt 403 empfängt
das VPN GW AUTH-Informationen von dem MN und authentifiziert den
MN unter Verwendung der AUTH-Informationen. Das VPN GW entscheidet
in Schritt 404, ob der MN die Zuweisung einer IP-Adresse
als eine HoA angefordert hat. Die Entscheidung wird durchgeführt, indem
geprüft
wird, ob die IKE_AUTH-Anforderungsnachricht, die von dem MN empfangen
wird, CP-Nutzdaten beinhaltet. Wenn der MN die Zuweisung einer IP-Adresse
angefordert hat, führt
das VPN GW im Auftrag der MN eine Mobile-IP-Registrierung durch, um in Schritt 405 eine
Nachfolger-SA-Aushandlung abzuschließen und eine IP-Adresse für den MN
bereitzustellen. Deshalb überträgt das VPN
GW eine Mobile-IP-Registrierungs-Anforderungsnachricht
durch den AAA-Server an den HA. Die Mobile-IP-Registrierungs-Anforderungsnachricht
beinhaltet eine NAI-Erweiterung, eine Mobile-Home Key Generation
Nonce-Anforderungserweiterung und eine Mobile-AAA-Authentifizierungs-Erweiterung. Der
NAI des MN, der in der NAI-Erweiterung festgelegt wird, ist die
IDi der IKE_AUTH-Anforderungsnachricht. Die Mobile-AAA-Authentifizierungs-Erweiterung
wird unter Verwendung des MSK, der von dem AAA-Server empfangen
wird, und eines bekannten SPI erzeugt.
-
Nach
Empfang einer Mobile-IP-Registrierungs-Antwortnachricht von dem
HA, liest das VPN GW eine HoA, die durch den HA dem MN zugewiesen
wird, und bewahrt die HoA in Schritt 406 für eine vorbestimmte
Zeitspanne auf. In Schritt 407 vervollständigt das
VPN GW die gegenseitige Authentifizierung, indem AUTH-Nutzdaten
an den MN übertragen werden.
In einer beispielhaften Implementierung beinhaltet das VPN GW Nachfolger-SA-Informationen und
die HoA des MN in einer IKE_AUTH-Antwortnachricht. Deshalb stellt
das VPN GW die HoA für den
MN bereit und schließt
die Nachfolger-SA-Aushandlung ab.
-
Um
den MN zu veranlassen, eine Mobile-IP-Registrierung durchzuführen, überträgt das VPN
GW eine Agent Advertisement-Nachricht an den MN und erwartet in
Schritt 409 den Empfang einer Mobile-IP-Registrierungs-Anforderungsnachricht
von dem MN. Nach Empfang der Mobile-IP-Registrierungs-Anforderungsnachricht
von der MN in Schritt 411, überträgt das VPN GW die aufbewahrte Mobile-IP-Registrierungs-Antwortnachricht
in Schritt 413 an den MN.
-
Deshalb
ist der MN nun in der Lage innerhalb des VPN zu kommunizieren, wobei
seine Mobilität unterstützt wird.
Die Kommunikationen werden dann durch das VPN GW unter Verwendung
der HoA zwischen dem MN und einem CN durchgeführt.
-
Wenn
der MN in Schritt 404 keine IP-Adresse angefordert hat,
authentifiziert das VPN GW den MN gegenseitig und schließt die Nachfolger-SA-Aushandlung
ab, indem in Schritt 408 die IKE_AUTH-Anforderungsnachricht
und die IKE_AUTH-Antwortnachricht mit dem MN ausgetauscht werden.
Um den MN zu veranlassen, eine Mobile-IP-Registrierung durchzuführen, überträgt das VPN
GW die Agent Advertisement-Nachricht in Schritt 410 an
den MN. Nach Empfang der Mobile-IP-Registrierungs-Anforderungsnachricht
von dem MN, leitet das VPN GW die empfangene Nachricht in Schritt 412 an
den HA weiter. Das VPN GW empfängt
einer Mobile-IP-Registrierungs-Antwortnachricht von dem HA und leitet sie
in Schritt 414 zu dem MN weiter. Deshalb ist der MN nun
in der Lage innerhalb des VPN zu kommunizieren, wobei seine Mobilität unterstützt wird.
Das VPN GW übermittelt
dann unter Verwendung der HoA Kommunikationen zwischen dem MN und
einem CN.
-
Nach
der Authentifizierung des MN erzeugt der AAA-Server nach einer beispielhaften
Ausführungsform
der vorliegenden Erfindung eine AAA SA mit dem MN oder er aktualisiert
eine bestehende AAA SA unter Verwendung des MSK, der während der
Authentifizierung erzeugt wird. Diese Funktionsweise des AAA-Servers
wird mit Bezug auf 5 beschrieben.
-
Bezüglich 5 EAP-authentifiziert
der AAA-Server in Schritt 501 den MN. Wenn die Authentifizierung
erfolgreich ist, erhält
der AAA-Server einen MSK, den er gemeinsam mit dem MN verwendet.
In Schritt 502 erzeugt der AAA-Server eine AAA SA mit dem
MN, oder er aktualisiert eine bestehende AAA SA unter Verwendung
des MSK.
-
Eine
weitere beispielhafte Ausführungsform der
vorliegenden Erfindung, die nachstehend beschrieben wird, kann den
Steuerungs-Overhead von der Verwendung der Mobile IP in dem VPN
weiter reduzieren. In dieser beispielhaften Ausführungsform kann die Mobilität des MN
selbst dann unterstützt werden,
wenn der MN keine Mobile-IP-Registrierung durchführt. Sobald er anfänglich auf
das VPN in dem Intranet zugreift, oder durch das VPN GW wird der MN
einer IP-Adresse zugewiesen. Trotz des Roamings in dem VPN, kann
der MN unter Verwendung der IP-Adresse innerhalb des VPN kommunizieren. Die
Mobile IP regelt, dass der HA des MN das Mobility Binding des MN
durch die Mobile-IP-Registrierung der MN immer dann aktualisieren
soll, wenn sich der MN bewegt. Nach einer weiteren beispielhaften Ausführungsform
der vorliegenden Erfindung übernehmen
das VPN GW und der HA die Führung
des Mobility Einding-Updates.
-
Sobald
sich der MN zu einem Heimatnetz in dem Intranet bewegt, aktualisiert
der HA des MN das Mobility Binding des MN, während das Heimatnetz den Zugang
des MN zu dem Netzwerk autorisiert. Wenn sich der MN aus dem Netzwerk
heraus bewegt, führt
das VPN GW im Auftrag des MN eine Mobile-IP-Registrierung durch
während
ein IPsec-Tunnel zwischen dem MN und dem VPN GW erzeugt wird. Diese
Mobilitätsunterstützung ist
nur in dem Zustand verfügbar,
in dem sich der MN die gesamte Zeit, während er in dem Intranet bleibt,
in dem Heimatnetz befindet.
-
Eine
beispielhafte Implementierung der oben bezeichneten weiteren beispielhaften
Ausführungsform
der vorliegenden Erfindung wird im Zusammenhang mit dem Zusammenarbeiten
zwischen einem drahtlosen Netzzugang (Radio Access Network – RAN) des
universellen mobilen Telekommunikationssystems (Universal Mobile
Telecommunication Service – UMTS)
der dritten Generation (3G) oder dem Code-Multiplex mit Mehrfachzugriff
(Code Division Multiple Access 2000 – CDMA2000) und einem WLAN
folgendermaßen
beschrieben.
-
6 stellt
eine Netzwerkkonfiguration dar, in der ein 3G RAN mit einem WLAN
nach der beispielhaften Implementierung der oben erwähnten weiteren
Ausführungsform
der vorliegenden Erfindung zusammenarbeitet.
-
Bezüglich 6 ist
ein 3G CN 401 eine Art von VPN. Ein MN 607 greift
durch einen terrestrischen drahtlosen UMTS-Netzzugang (UMTS Terrestrial
Radio Access – UTRAN) 609a oder
durch ein WLAN 609c auf das CN 601 zu.
-
Bei
dem Zugriff durch den UTRAN 609a ist der MN 607 durch
einen Serving GPRS Support Node (SGSN) 609b mit einem Gateway
General Packet Radio Service Node (GGSN) 603 verbunden. Ein
Teilnetz 602a, zu dem der GGSN 603 gehört, ist ein
Heimatnetz für
den MN 607. In dem Teilnetz 602a arbeitet der
GGSN 603 als ein HA, oder es kann ein getrennter HA besorgt
werden.
-
Wenn
durch das WLAN 609c zugegriffen wird, ist der MN 607 durch
ein WLAN Access Gateway (WAG) 609d mit einem Packet Data
Gateway (PDG) 605 verbunden. Ein Teilnetz 602b,
zu dem das PDG 605 gehört,
ist ein fremdes Netzwerk. Das PDG 605 kann als ein FA in
dem Teilnetz 602b dienen. Für eine Verbindung zwischen
dem MN 607 und dem PDG 605 wird ein IPsec-Tunnel
zwischen ihnen aufgebaut. Vom Standpunkt des MN ist das Zugreifen auf
das CN 601 durch das WLAN 609c äquivalent
zu dem Zugreifen auf das VPN.
-
Der
MN 607 kann eine Zugangstechnik zwischen dem Zugang über WLAN
und dem Zugang über
UTRAN abhängig
von den Situationen verändern.
Das PDG 605a, das sowohl als MN-Proxy als auch als FA (somit
PDG/MN-Proxy/FA) dient, oder der GGSN 603a, der als der
HA (somit GGSN/HA) dient, übernimmt
die Aufgabe der Unterstützung
der Mobilität
des MN 607. Sobald der MN 607 durch das UTRAN 609a oder
durch das WLAN 609c und das PDG 605 auf das CN 601 zugreift,
kann es mit dem CN 601 kommunizieren, wobei seine Mobilität unterstützt wird.
Nach einer beispielhaften Implementierung gibt es keine Notwendigkeit
für einen
zusätzlichen
Mobile-IP-Registrierungsvorgang, nachdem der MN 607 seine
Zugangstechnik für
das Zugreifen auf das CN 601 verändert. Das PDG/MN-Proxy/FA
605 (kurz PDG) und der GGSN/HA 603 (kurz GGSN) führen den
Mobile-IP-Registrierungsvorgang
durch.
-
7 ist
ein Diagramm, das einen Signalfluss für einen MN, der durch ein WLAN
auf ein 3G CN zugreift, nach einer zweiten beispielhaften Implementierung
einer Ausführungsform
der vorliegenden Erfindung darstellt. Sobald der MN 607 mit
dem WLAN verbunden ist, das mit dem 3G CN zusammenarbeitet, und
einen geeigneten PDG 605 ermittelt, baut er einen IPsec-Tunnel
mit dem PDG 605 auf und versucht auf das 3G-Netzwerk zuzugreifen.
-
Bezüglich 7 überträgt der MN 607 in Schritt 701 eine
IKE_SA_INIT-Anforderungsnachricht
an das PDG 605 und empfängt
in Schritt 702 eine IKE_SA_INIT-Antwortnachricht von dem PDG 605,
wodurch eine IKE SA mit dem PDG 605 ausgehandelt wird.
In Schritt 703 überträgt der MN 607 eine IKE_AUTH-Anforderungsnachricht
an das PDG 605. Durch Ausschließen von AUTH-Nutzdaten von
der IKE_AUTH-Anforderungsnachricht,
schlägt
der MN 607 EAP eine gegenseitige Authentifizierung vor
und beginnt gleichzeitig, die erste Nachfolger-SA mit das PDG 605 auszuhandeln.
Eine IDA, die in der IKE_AUTH-Anforderungsnachricht enthalten ist,
wird auf den NAI des MN 607 eingestellt.
-
In
dem Fall, in dem der MN 607 anfänglich auf den 3G CN 601 zugreift,
beinhaltet er CP-Nutzdaten,
die in der IKE_AUTH-Anforderungsnachricht auf null eingestellt sind,
wodurch er eine Zuweisung einer IP-Adresse anfordert, die in dem
3G CN 601 verwendet werden soll. Wenn im Gegensatz dazu
der MN 607 mit dem 3G CN 601 verbunden war und
nun ein Handover ist, weist er schon eine IP-Adresse auf und schließt deshalb
die CP-Nutzdaten von der IKE_AUTH-Anforderungsnachricht aus.
-
Nach
Empfang der IKE_AUTH-Anforderungsnachricht meldet das PDG 605 dem
MN 607 den Beginn der EAP-Authentifizierung, indem in Schritt 704 eine
EAP-Anforderungsnachricht übertragen
wird. In Schritt 705 authentifiziert ein AAA-Server 606 den
MN 607 durch Routing des PDG 605. Wenn die Authentifizierung
erfolgreich ist, erzeugt der AAA-Server 606 eine AAA SA
oder aktualisiert unter Verwendung eines MSK, der während der
Authentifizierung erzeugt wird, in Schritt 706 eine bestehende AAA
SA. In Schritt 707 überträgt der AAA-Server 606 eine
EAP-Erfolgsnachricht an das PDG 605, um dem MN 607 die
erfolgreiche Authentifizierung zu melden. Das PDG 605 leitet
in Schritt 708 die EAP-Erfolgsnachricht
an den MN 607 weiter.
-
In
Schritt 709 erzeugt der MN 607 unter Verwendung
des MSK AUTH-Nutzdaten und überträgt eine
IKE_AUTH-Nachricht, welche die AUTH-Nutzdaten enthält, an das
PDG 605. Nach Empfang der IKE_AUTH-Nachricht, erzeugt das
PDG 605 eine Mobile-IP-Registrierungs-Anforderungsnachricht und überträgt sie durch
ein AAA-Protokoll zu dem AAA-Server 606, um in Schritt 710 im
Auftrag des MN 607 eine Mobile-IP-Registrierung durchzuführen.
-
Die
Mobile-IP-Registrierungs-Anforderungsnachricht beinhaltet eine NAI-Erweiterung,
eine Mobile-Home Key Generation Nonce-Anforderungserweiterung und
eine Mobile-AAA-Authentifizierungserweiterung.
Obwohl die Mobile-Home Key Generation Nonce-Anforderungserweiterung für die Erzeugung
einer MSA verwendet wird, die zwischen dem MN 607 und dem
HA des MN 607 gemeinsam verwendet wird, wird die Mobile-Home
MSA nicht benötigt,
weil die Mobile IP-Registrierungs-Anforderung unter Verwendung der
AAA SA in dieser Ausführungsform
der vorliegenden Erfindung jederzeit authentifiziert wird. Deshalb
ist die MSA in einer beispielhaften Implementierung von Mobile-IP
keine Notwendigkeit, die Mobile-IP-Registrierungs-Anforderungsnachricht
muss die Mobile-Home Key Generation Nonce-Anforderungserweiterung
nicht aufweisen. Nach einer beispielhaften Implementierung ist der
Betrieb der MSA in dem AAA-Server 606 und dem GGSN 603 nicht
erforderlich.
-
In
der Mobile-IP-Registrierungs-Anforderungsnachricht wird eine CoA
auf eine IP-Adresse des PDG 605 eingestellt. Wenn der MN 607 in
Schritt 703 die Zuweisung einer IP-Adresse angefordert
hat, wird eine HoA in der Mobile-IP-Registrierungs-Anforderungsnachricht
auf 0.0.0.0 eingestellt, so dass die HoA durch das GGSN 603 in
der Mobile-IP-Registrierung dem MN 607 dynamisch zugewiesen
wird. Wenn der MN 607 in Schritt 703 andererseits
keine Zuweisung einer IP-Adresse angefordert hat, wird die HoA auf
die IP-Adresse des MN 607 innerhalb des IPsec-Tunnels in
der Mobile-IP-Registrierungs-Anforderungsnachricht eingestellt.
Das PDG 605 hat Kenntnis von dem NAI des MN 607 und
dem SPI der AAA SA, die durch den AAA-Server 606 erzeugt
wird. Da das PDG 605 den AAA-Schlüssel der AAA SA in Schritt 705 bezieht,
erzeugt er unter Verwendung des NAI, des SPI und des AAA-Schlüssels die
Mobile-IP-Registrierungs-Anforderungsnachricht.
-
Nach
Empfang der Mobile-IP-Registrierungs-Anforderungsnachricht von dem
PDG 605 authentifiziert der AAA-Server 606 die
Mobile-IP-Registrierungs-Anforderungsnachricht, indem er in Schritt 711 die
Mobile-AAA-Authentifizierungserweiterung prüft, die in der Nachricht enthalten
ist. Wenn die Authentifizierung erfolgreich ist, wählt der
AAA-Server 606 eine RAND und erzeugt unter Verwendung der RAND
einen gemeinsam benutzten geheimen Schlüssel. In Schritt 712 überträgt der AAA-Server 606 die
Mobile-IP-Registrierungs-Anforderungsnachricht,
die RAND und den gemeinsam benutzten geheimen Schlüssel durch
das AAA-Protokoll an das GGSN 603.
-
Das
GGSN 603 erzeugt eine Mobile-Home MSA für den MN 607 und erzeugt
eine Mobile-IP-Registrierungs-Antwortnachricht.
In Schritt 713 überträgt das GGSN 603 die
Mobile-IP-Registrierungs-Antwortnachricht
durch das AAA-Protokoll an den AAA-Server 606. Wenn die
Mobile-IP-Registrierungs-Anforderungsnachricht eine dynamische Zuweisung
einer HoA für
den MN 607 anfordert, weist das GGSN 603 dem MN 607 eine
IP-Adresse zu und erzeugt die Mobile-IP-Registrierungs-Antwortnachricht
mit der zugewiesenen IP-Adresse, welche die HoA des MN 607 ist.
Der AAA-Server 606 leitet in Schritt 714 die Mobile-IP-Registrierungs-Antwortnachricht
durch das AAA-Protokoll weiter an das PDG 605. Das PDG 605 bezieht
die HoA des MN 607 von der Mobile-IP-Registrierungs-Antwortnachricht.
-
In
Schritt 715 beendet das PDG 605 die gegenseitige
Authentifizierung und die Nachfolger-SA-Aushandlung, indem eine IKE_AUTH-Antwortnachricht
an den MN 607 übertragen
wird. Die IKE_AUTH-Antwortnachricht beinhaltet die CP-Nutzdaten
mit der HoA, den TSi und den TSr. Nach einer beispielhaften Implementierung
kann der MN 607 unter Verwendung der HoA ungeachtet der
Zugangstechniken in dem 3G CN 601 kommunizieren.
-
Beispielhafte
Funktionsweisen des PDG, des GGSN und des AAA-Servers nach einer
beispielhaften Ausführungsform
der vorliegenden Erfindung sehen folgendermaßen aus. Der MN arbeitet in
derselben Weise, wie in 3 dargestellt, mit der Ausnahme,
dass der MN keine AAA SA nach der EAP-Authentifizierung erzeugt
und keinen Mobile-IP-Registrierungsvorgang
nach dem Empfang einer IKE_AUTH-Antwortnachricht von dem PDG 605 durchführt.
-
8 ist
ein Ablaufdiagramm, das die Funktionsweise eines PDG nach einer
beispielhaften Implementierung einer Ausführungsform der vorliegenden
Erfindung darstellt.
-
Bezüglich 8 handelt
das PDG eine IKE SA mit dem MN aus, indem er in Schritt 801 eine IKE_SA_INIT-Anforderungsnachricht
von dem MN empfangt und eine IKE_SA_INIT-Antwortnachricht an den MN überträgt. Nach
dem Empfang einer IKE_SA_INIT-Anforderungsnachricht
ohne AUTH-Nutzdaten von dem MN, unterstützt das PDG den AAA-Server um in Schritt 802 den
MN zu EAP-authentifizieren. Wenn die Authentifizierung erfolgreich
ist, empfängt
das PDG einen MSK, der sich aus der EAP-Authentifizierung von dem
AAA-Server ergibt, und vervollständigt
die Vorbereitung für
die gegenseitige Authentifizierung mit dem MN.
-
Im
Schritt 803 empfängt
das PDG AUTH-Informationen von dem MN und authentifiziert den MN unter
Verwendung der AUTH-Informationen. Das PDG entscheidet in Schritt 804,
ob der MN eine Zuweisung einer IP-Adresse angefordert hat. Die Entscheidung
wird durchgeführt,
indem geprüft
wird, ob die IKE_AUTH-Anforderungsnachricht, die von dem MN empfangen
wird, CP-Nutzdaten beinhaltet. Wenn der MN die Zuweisung einer IP-Adresse
angefordert hat, führt
das PDG im Auftrag des MN in Schritt 805 eine Mobile-IP-Registrierung
durch. Deshalb überträgt das PDG
eine Mobile-IP-Registrierungs-Anforderungsnachricht durch den AAA-Server
an das GGSN. Die Mobile-IP-Registrierungs-Anforderungsnachricht
beinhaltet eine NAI-Erweiterung und eine Mobile-AAA-Authentifizierungserweiterung.
Eine HoA wird auf 0.0.0.0 eingestellt, und eine CoA wird auf die
IP-Adresse des PDG in der Mobile-IP-Registrierungs-Anforderungsnachricht
eingestellt.
-
Das
PDG prüft
in Schritt 802 den NAI des MN von der IDi der IKE_AUTH-Anforderungsnachricht, die
von dem MN empfangen wird, und erzeugt die Mobile-AAA-Authentifizierungserweiterung
unter Verwendung des MSK, der von dem AAA-Server in Schritt 802 empfangen
wird. Das PDG leitet die Mobile-I P-Registrierungs-Anforderungsnachricht
an das GGSN weiter.
-
Nach
Empfang einer Mobile-IP-Registrierungs-Antwortnachricht von dem
GGSN liest das PDG eine HoA, die in Schritt 807 durch das
GGSN für den
MN zugewiesen wird. In Schritt 808 vervollständigt das
PDG die gegenseitige Authentifizierung, idem es AUTH-Nutzdaten an
den MN überträgt. Um genauer
zu sein, beinhaltet das PDG Nachfolger-SA-Informationen und die HoA des MN in
einer IKE_AUTH-Antwortnachricht. Nach einer beispielhaften Implementierung
stellt das PDG die HoA für
den MN bereit und beendet die Nachfolger-SA-Aushandlung.
-
Wenn
der MN in Schritt 804 keine Zuweisung einer IP-Adresse
anfordert, braucht das PDG keine HoA des MN zu empfangen, die von
dem GGSN dynamisch zugewiesen wird. Er führt im Auftrag des MN nur eine
Mobile-IP-Registrierung durch. Deshalb überträgt das PDG im Auftrag des MN
in Schritt 806 eine Mobile-IP-Registrierungs-Anforderungsnachricht.
Die HoA des MN wird auf die IP-Adresse des MN eingestellt, die innerhalb
des IPsec-Tunnels verwendet wird, der in Schritt 802 in
der Mobile-IP-Registrierungs-Anforderungsnachricht erzeugt wird. Nach
der Mobile-IP-Registrierung schließt das PDG die gegenseitige
Authentifizierung und die Nachfolger-SA-Aushandlung gleichzeitig
ab, indem er in Schritt 809 eine IKE_AUTH-Anforderungsnachricht und
eine IKE_AUTH-Antwortnachricht mit dem MN austauscht.
-
Nachdem
die Aushandlung beendet ist, ist der MN in der Lage innerhalb des
3G CN zu kommunizieren, wobei seine Mobilität unterstützt wird.
-
9 ist
ein Ablaufdiagramm, das die Funktionsweise des GGSN nach einer beispielhaften
Implementierung einer Ausführungsform
der vorliegenden Erfindung darstellt. Das GGSN ändert selbst das Mobility Binding
des MN während
der MN autorisiert ist, durch das UTRAN auf das 3G CN zuzugreifen. Das
Mobility Binding, das bei Mobile-IP verwendet wird, kann Informationen über eine
Mapping-Beziehung zwischen der HoA des MN, die in dem HA aufbewahrt
wird, und der CoA, welche die aktuelle Position des MN anzeigt,
beinhalten.
-
Bezüglich 9 empfängt das
GGSN in Schritt 901 eine Create PDP Context-Anforderungsnachricht
für den
MN von dem SGSN und entscheidet, ob in Schritt 902 schon
ein Mobility Binding für den
MN existiert. Bei dem Vorhandensein eines Mobility Binding aktualisiert
das GGSN das Mobility Binding des MN, unter Beachtung, dass der
MN in Schritt 903 schon auf das CN zugegriffen hat und
einer HoA zugewiesen wurde. In Schritt 904 überträgt das GGSN
eine Create PDP Context-Anforderungsnachricht mit einer HoA des
MN, die als PDP-Adresse festgelegt ist, an das SGSN.
-
Bei
dem Nichtvorhandensein des Mobility Binding weist das GGSN andererseits
dem MN eine IP-Adresse zu, um zu bestimmen, dass der MN anfänglich auf
das CN zugreifen soll, und überträgt in Schritt 905 eine
Create PDP Context-Anforderungsnachricht mit der IP des MN, die
als PDP-Adresse festgelegt ist, an das SGSN.
-
Obwohl
nicht in 9 gezeigt, tauscht das GGSN
Informationen aus, die erforderlich sind, um das Mobility Binding
des MN mit dem HA zu aktualisieren, wenn der HA des MN sich von
dem GGSN unterscheidet.
-
Der
AAA-Server arbeitet in derselben Weise wie in 5 dargestellt,
und deshalb wird seine Beschreibung nicht überflüssigerweise bereitgestellt.
-
Nach
einer bestimmten beispielhaften Ausführungsform der vorliegenden
Erfindung kann, wie oben beschrieben, die Mobilität eines
MN unter Verwendung von Mobile-IP in einem VPN mit lediglich zwei
IP-Adressen, die dem MN zugewiesen werden, unterstützt werden,
und ein zusätzlicher
Mobile IP-Tunnel muss innerhalb eines IPsec-Tunnels zwischen dem
MN und einem VPN GW nicht erforderlich sein. Deshalb wird ein Paketübertragungs-Overhead reduziert.
In einer weiteren beispielhaften Ausführungsform kann die vorliegende
Erfindung die Notwendigkeit weiterer Arbeitsabläufe zur Unterstützung der
Mobilität
vermeiden, mit Ausnahme der Verbindung zu dem VPN in dem MN. Deshalb
kann der Zugangsvorgang und der Protokollstapel des MN vereinfacht
werden.
-
Während die
Erfindung mit Bezug auf bestimmte beispielhafte Ausführungsformen
davon gezeigt und beschrieben wurde, versteht es sich für Fachleute,
dass verschiedene Änderungen
in Form und Details darin durchgeführt werden können, ohne von
dem Geltungsbereich der Erfindung abzuweichen, wie er in den beigefügten Ansprüchen definiert wird.