WO2008037685A2 - Verfahren zur optimierung der nsis-signalisierung bei mobike-basierenden mobilen anwendungen - Google Patents

Verfahren zur optimierung der nsis-signalisierung bei mobike-basierenden mobilen anwendungen Download PDF

Info

Publication number
WO2008037685A2
WO2008037685A2 PCT/EP2007/060088 EP2007060088W WO2008037685A2 WO 2008037685 A2 WO2008037685 A2 WO 2008037685A2 EP 2007060088 W EP2007060088 W EP 2007060088W WO 2008037685 A2 WO2008037685 A2 WO 2008037685A2
Authority
WO
WIPO (PCT)
Prior art keywords
address
nsis
vpn
signaling
mri
Prior art date
Application number
PCT/EP2007/060088
Other languages
English (en)
French (fr)
Other versions
WO2008037685A3 (de
Inventor
Andreas Pashalidis
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to PL07820495T priority Critical patent/PL2070285T3/pl
Priority to US12/311,439 priority patent/US8396971B2/en
Priority to KR1020097008611A priority patent/KR101062604B1/ko
Priority to CN2007800362852A priority patent/CN101523847B/zh
Priority to DE502007002769T priority patent/DE502007002769D1/de
Priority to EP07820495A priority patent/EP2070285B1/de
Priority to AT07820495T priority patent/ATE456895T1/de
Priority to JP2009529680A priority patent/JP4801201B2/ja
Publication of WO2008037685A2 publication Critical patent/WO2008037685A2/de
Publication of WO2008037685A3 publication Critical patent/WO2008037685A3/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/087—Mobility data transfer for preserving data network PoA address despite hand-offs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the invention relates to a method for reducing the signaling overhead of a mobile node, the Minim ⁇ least maintains an active Next Steps In Signaling signaling session and a MOBIKE connection to a vir- tual-Private Network (VPN) - Gateway has, and its point of attachment to the Internet, according to the Oberbeg ⁇ reef of claim 1.
  • VPN vir- tual-Private Network
  • the NSIS nodes marked NF for NSIS forwarders are those NSIS nodes whose states must be updated after the MK's movement. This results in the fol ⁇ constricting problems: The signaling for the update must be initiated. This in itself already represents an overhead.
  • a fifth method step E an address space relating to the IP address of the MK is inserted into the MRI object. This can be done, for example, by specifying the IP address of the MK and a prefix.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Optical Communication System (AREA)
  • Position Fixing By Use Of Radio Waves (AREA)
  • Radio Relay Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

Es wird ein Verfahren beschrieben zur Verringerung des Signalisierungs-Overheads eines Mobilen Knotens, der mindestens eine aktive Next-Steps-In-Signaling-Signalisierungs-Session unterhält sowie eine MOBIKE Verbindung mit einem Virtuellen-Privaten-Netzwerk (VPN) -Gateway hat, und der seinen Anknüpfungspunkt an das Internet wechselt, welches die Verfahrensschritte: Einfügen mindestens der IP-Adresse des VPN-Gateways und/oder eines mit dem Subnetz des VPN-Gateways übereinstimmenden Adressraums in ein in der NSIS-Signalisierungs-Nachricht enthaltenes Routing-Information (Message Routing Information; MRI) -Objekt; Festlegung eines Werts für einen Sicherheits-Parameter-Index (Security Parameter Index; SPI); Einfügen des SPI-Werts in das MRI-Objekt; Setzen des S-Flags im MRI-Objekt, sowie Einfügen eines sich auf die IP-Adresse des MK beziehenden Adressraums in das MRI Objekt, umfasst.

Description

Beschreibung
Verfahren zur Optimierung der NSIS-Signalisierung bei MOBIKE- basierenden mobilen Anwendungen
Die Erfindung betrifft ein Verfahren zur Verringerung des Signalisierungs-Overheads eines Mobilen Knotens, der mindes¬ tens eine aktive Next-Steps-In-Signaling-Signalisierungs- Session unterhält sowie eine MOBIKE Verbindung mit einem Vir- tuellen-Privaten-Netzwerk (VPN) -Gateway hat, und der seinen Anknüpfungspunkt an das Internet wechselt, gemäß dem Oberbeg¬ riff des Anspruchs 1.
Ein Virtuelles Privates Netz (VPN) ist ein Computernetz, das zum Transport privater Daten ein öffentliches Netz, bei¬ spielsweise das Internet nutzt. Teilnehmer eines VPN können Daten wie in einem internen lokalen Netzwerk (Local Area Network; LAN) austauschen. Die einzelnen Teilnehmer selbst müssen hierzu nicht direkt verbunden sein. Die Verbindung über das öffentliche Netz wird üblicherweise verschlüsselt. Eine Verbindung eines Teilnehmers, welcher einen so genannten VPN- Client nutzt, mit seinem Heimatnetz, welches einen so genannten VPN-Server zur Verfügung stellt, wird über einen Tunnel zwischen dem VPN-Client und dem VPN-Server ermöglicht. Meist wird der Tunnel dabei gesichert, aber auch ein ungesicherter Klartexttunnel kann dazu genutzt werden, einen VPN-Client mit einem VPN Server zu verbinden.
Ein VPN kann u.a. dazu dienen, Mitarbeitern außerhalb einer Organisation oder eines Unternehmens Zugriff auf das interne Netz zu geben. Dabei baut der Computer des Mitarbeiters eine VPN-Verbindung zu einem VPN-Gateway des Unternehmens auf. Über diese Verbindung ist es dem Mitarbeiter nun möglich, so zu arbeiten, als ob er im lokalen Netz des Unternehmens wäre.
Um eine sichere Übertragung von Daten in VPNs ermöglichen zu können, werden spezielle Protokolle benötigt. Eine Gruppe von solchen Protokollen ist zusammenfassend unter IP-security (IPsec) bekannt. Dazu gehört unter anderem das Internet Key Exchange Version 2 (IKEv2) Protokoll. Es ist dafür verant¬ wortlich, die Schlüssel zu erzeugen, die von den kryp- tographischen Mechanismen auch anderer Protokolle benötigt werden. Eine unter Verwendung von IPsec aufgebauter Tunnel für eine VPN-Verbindung wird auch als IPsec-Tunnel bezeichnet. Das Mobile-Internet-Key-Exchange-Protokoll (MOBIKE- Protokoll) erweitert das in IPsec enthaltene IKEv2, indem es dem VPN-Client ermöglicht, seinen Anknüpfungspunkt an das
Netzwerk zu wechseln, ohne dass der dadurch erfolgte Wechsel seiner Internet-Protokoll (IP) -Adresse dazu führt, dass sei¬ ne VPN-Session erneut aufgebaut werden muss.
In einem typischen VPN-Szenario tauschen ein VPN-Client und ein VPN-Gateway Daten über einen IPsec-Tunnel aus. Wenn der VPN-Client ein Mobiler Knoten (MK) , beispielsweise ein Lap¬ top, ein Palmtop, ein Personal Digital Assistent (PDA) oder dergleichen ist, und wenn dieser seinen Anknüpfungspunkt zum Internet ändert, ändert sich auch seine IP-Adresse. Wie die¬ ser Adresswechsel im VPN-Szenario effektiv gehandhabt wird, ist im MOBIKE-Protokoll spezifiziert. Wenn der MK eine Next- Steps-In-Signaling (NSIS) -Signalisierungs-Session für diesen Tunnel initiiert hat, dann muss bei einem Wechsel des Anknüp- fungspunktes der Zustand aller NSIS-fähigen Knoten, die ent¬ lang des Pfades des Tunnels an der Signalisierung teilnehmen aktualisiert werden, um dem Wechsel der IP-Adresse des MK folgen zu können. Dieser Prozess stellt einen Overhead dar, der umso größer wird, umso öfter der MK seinen Anknüpfungs- punkt wechselt. Eine zusätzliche Verschwendung von Ressourcen kann darüber hinaus auftreten, wenn die oben benannten NSIS Knoten Ressourcen für den Datenstrom des IPsec-Tunnels reserviert haben. Solche Ressourcenreservierungen, wie etwa Übertragungsgeschwindigkeit, Bandbreite und dergleichen, werden beispielsweise dann reserviert, wenn es sich bei der Signali¬ sierung um eine Quality of Service (QoS) -Signalisierung, beispielsweise um das von der NSIS-Arbeitsgruppe erstellte QoS-NSLP (Quality of Service NSIS Signaling Layer Protocol) handelt. Die oben benannte Verschwendung tritt deshalb auf weil im Zeitraum zwischen dem Adresswechsel und der oben benannten Zustandsaktualisierung, die reservierten Ressourcen weder dem Datenstrom des IPsec-Tunnels, noch an anderer Stel- Ie zur Verfügung stehen. Das bedeutet ebenso, dass der Datenstrom bis zum erfolgten Aktualisieren aller NSIS-Knoten entlang des Pfades die für ihn reservierte Ressourcen nicht be¬ anspruchen kann. Dies wiederum bedeutet dass Anfangs zugesag¬ te QoS-Garantien nicht eingehalten werden. Dem Benutzer wird dies dadurch bewusst indem sich z.B. die Übertragungsge¬ schwindigkeit deutlich verschlechtert.
Aus dem Stand der Technik sind keine Lösungen bekannt, welche eine Optimierung der NSIS-Signalisierung bei wechselndem An- knüpfungspunkt des MK in MOBIKE-Umgebungen ermöglichen. Die Arbeitsberichte der NSIS-Arbeitsgruppe beschreiben lediglich die grundsätzlichen Methoden, wie die NSIS-Signalisierungs- Protokolle in mobilen Szenarios anzuwenden sind. Diese Metho¬ den fordern, dass der MK immer Signalisierungs-Nachrichten sendet, wenn sich seine IP-Adresse ändert. Aufgabe dieser Nachrichten ist, die Zustände der an der Signalisierungs- Session beteiligten NSIS-Knoten mit der aktuellen IP-Adresse des MK zu aktualisieren.
Eine Aufgabe der Erfindung ist es deshalb, ein Verfahren anzugeben, welches die oben genannten Verzögerungen und die damit verbundene Verschwendung von Ressourcen unterbindet.
Diese Aufgabe wird durch ein Verfahren nach Anspruch 1 ge- löst. Vorteilhafte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen und der nachfolgenden Beschreibung.
Das erfindungsgemäße Verfahren zur Verringerung des Signali- sierungs-Overheads bzw. zur Verringerung der Resourcen- verschwendung, die auftreten kann, wenn ein Mobiler Knoten, der mindestens eine aktive Next-Steps-In-Signaling- Signalisierungs-Session unterhält, und der eine MOBIKE Ver- bindung mit einem VPN Gateway hat, seinen Anknüpfungspunkt an das Internet wechselt, umfasst die Verfahrensschritte:
Einfügen der IP-Adresse des VPN-Gateways und/oder eines mit dem Subnetz des VPN-Gateways übereinstimmenden Ad- ressraums in ein nach dem General Internet Signaling
Transport (GIST) -Protokoll in der NSIS-Signalisierungs-
Nachricht enthaltenes Message-Routing-Information (MRI)
-Objekt
Festlegung eines Werts für einen Sicherheits-Parameter- Index (Security Parameter Index; SPI),
Einfügen des SPI-Werts in das MRI-Objekt,
Setzen des in GIST definierten S-Flags im MRI-Objekt, sowie
Einfügen eines sich auf die IP-Adresse des MK beziehen- den Adressraums in das MRI-Objekt.
Der sich auf die IP-Adresse des MK beziehende Adressraum wird durch Angabe einer IP-Adresse des MK und eines Präfix angege¬ ben. Der Präfix gibt an, welcher Teil der IP-Adresse des MKs sich ändern kann, ohne dass die IP-Adresse des MKs den zuge¬ hörigen Adressraum verlässt. Dem GIST Standard nach benutzen die an der Signalisierungssession teilnehmenden NSIS-Knoten den IP-Adressbereich, der durch das die IP-Adresse des MK und den Präfix umfassende Paar definiert wird, um die dem Daten- ström des IPsec-Tunnels angehörenden Pakete zu identifizie¬ ren. Genauer gehören Datenpakete dem Datenstrom an, wenn die im IP-Header angegebene IP-Adresse des MK im diesem Adressbe¬ reich liegt. Wenn sich nun die IP-Adresse des MK innerhalb diesen Adressbereichs ändert, muss auch keine Aktualisierung der Zustände der NSIS-Knoten entlang des Pfades des IPsec- Tunnels mehr erfolgen. Dadurch wird der Overhead und die e- ventuell anfallende Ressourcenverschwendung wirkungsvoll ver¬ ringert bzw. vermieden. Der Datenstrom zwischen dem MK und dem MOBIKE Server kann ohne Verzögerungen weiterfliesen.
Eine vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht vor, dass im MRI-Objekt ein Adressraum für die IP- Adresse des MK angegeben wird, der die unter Berücksichtigung der üblichen Bewegung des MKs zu erwartenden möglichen IP- Adressen für den MK umfasst. Dabei ist denkbar, dass die Be¬ wegungen des MKs überwacht, und die dem MK während seiner Be¬ wegung zugeteilten IP-Adressen gespeichert werden, um hieraus ein bevorzugtes Bewegungsprofil und einen Adressraum abzulei¬ ten, der die dem MK innerhalb seines ermittelten bevorzugten Bewegungsraumes zugeteilten IP-Adressen umfasst.
Gemäß einer vorteilhaften Ausgestaltung der Erfindung ist vorgesehen, dass der MK vorzugsweise nur eine einzige IP-
Adresse für das VPN-Gateway im MRI-Objekt angibt und den Ad¬ ressraum für die eigene IP-Adresse so weit wie möglich ein¬ schränkt. Dies ist dann sinnvoll, wenn sich der MK gegenwärtig nur innerhalb des zu seiner momentanen IP-Adresse gehö- renden, seinem Zugangsnetz zugeordneten Adressraums bewegt. Ein solcher Fall tritt häufig in Netzwerken großer Unternehmen oder Organisationen auf, innerhalb denen sich die MKs frei bewegen können. Adressräume können durch Angabe einer innerhalb des Adressraums liegenden IP-Adresse und einem Be- reich, um den eine neue IP-Adresse von der vorgegebenen IP- Adresse abweichen kann angegeben werden. Indem der MK den Adressraum, innerhalb dem seine IP-Adresse liegt, so weit wie möglich einschränkt, wird die Wahrscheinlichkeit verringert, dass Kollisionen auftreten.
Bei allen oben angegebenen Ausführungsformen des erfindungsgemäßen Verfahrens ist denkbar, dass der SPI-Wert durch das VPN-Gateway derart festgelegt wird, dass Kollisionen zwischen verschiedenen IPsec-Tuneln, die zwischen unterschiedlichen MKs und dem selben VPN-Gateway bestehen, vermieden werden. Das VPN-Gateway ist in der Lage, SPI-Werte so festzulegen, dass innerhalb des VPNs nicht dieselben SPI-Werte für mehrere unterschiedliche, nach dem MOBIKE-Standard aufgebaute, MK-zu- VPN IPsec-Tunnel vorkommen. In Anbetracht der Tatsache, dass der SPI-Wert 32 Stellen aufweist, entsprechend 232 möglichen verschiedenen SPI-Werten, genügt dies für die meisten Anwendungsfälle . Ebenso ist denkbar, dass der SPI-Wert zufällig ausgewählt, oder mittels einer geeigneten Funktion durch den NSIS- Session-Identifier oder anderer geeigneter Daten festgelegt wird. Die zufällige Festlegung ist sehr einfach und kosten- günstig umsetzbar und es ist sehr unwahrscheinlich, dass ein zufällig ausgewählter SPI-Wert für den VPN-nach-MK-Tunnel ei¬ nes MKs mit den SPI-Werten anderer MKs übereinstimmt.
Nachfolgend wird die Erfindung anhand der Zeichnungen näher erläutert. Dabei zeigen:
Fig. 1 eine schematische Darstellung eines über mehrere
NSIS-Knoten verlaufenden IPsec-Tunnels zwischen ei¬ nem MK und einem VPN-Gateway, sowie
Fig. 2 eine schematische Darstellung des Ablaufs eines er¬ findungsgemäßen Verfahrens .
In einem in Fig. 1 schematisch dargestellten Szenario in dem ein Mobiler Knoten MK, der a) eine IPsec Verbindung mit einem durch MOBIKE verwalteten VPN-Gateway VPNG hat, und b) an einer NSIS-Signalisierungs-Session teilnimmt, seine IP-Adresse ändert, wird der bereits in den entlang des Tunnel-Pfades liegenden NSIS-Knoten NF installierte Signali- sierungszustand ungültig und muss aktualisiert werden. In Fig. 1 deuten die mit IS gekennzeichneten Pfeile die mittels MOBIKE verwaltete IPsec Verbindung an. Der Pfeil P deutet an, dass sich der MK bewegt. Diese Bewegung bewirkt dass der MK anstelle seiner bisherigen IP-Adresse IPl eine neue IP- Adresse IP2 erhält, da sich sein Anknüpfungspunkt zum VPN- Gateway VPNG im Internet I ändert. Daraufhin muss das MOBIKE- Protokoll den Zustand am VPN-Gateway VPNG aktualisieren. Die mit NF, für NSIS-Forwarder, gekennzeichneten NSIS-Knoten sind diejenigen NSIS-Knoten, deren Zustände nach der Bewegung des MKs aktualisiert werden müssen. Hieraus ergeben sich die fol¬ genden Probleme: Die Signalisierung für das Aktualisieren muss initiiert werden. Dies stellt für sich allein bereits einen Overhead dar.
Der Datenstrom, also die Übertragung der Datenpakete entlang des IPsec-Tunnels, erfährt so lange nicht die durch die Signalisierung vorgesehene Behandlung, bis die Zustände aller NSIS-Knoten entlang des Pfades des Tunnels aktualisiert sind. Hierdurch wird die Leistungsfä¬ higkeit der Verbindung beeinträchtigt, und einem Anwen- der können sogar Kosten für Dienste entstehen, die er durch diese Verzögerung nicht oder nur eingeschränkt erhält.
Ressourcen müssen für nicht ständig vorhandene Signali- sierungs-Sessions so lange freigehalten werden, bis alle Zustände der NSIS-Knoten entlang des Pfades des Tunnels aktualisiert sind. Dies stellt eine Verschwendung von Ressourcen dar.
Die oben genannten Probleme werden durch ein in Fig. 2 sche- matisch in seinem Ablauf dargestelltes erfindungsgemäßes Ver¬ fahren zur Verringerung des Overheads einer NSIS- Signalisierungs-Nachricht eines MKs in einem VPN bei einem Wechsel des Anknüpfungspunktes des MKs an das VPN, wobei der MK mit einem VPN-Gateway über einen IPsec-Tunnel verbunden ist, dessen Pfad über mindestens einen NSIS-Knoten verläuft gelöst .
In einem ersten Verfahrensschritt A ist dabei vorgesehen, mindestens die IP-Adresse des VPN-Gateways und/oder eines mit dem Subnetz des VPN-Gateways übereinstimmenden Adressraums in ein in der NSIS-Signalisierungs-Nachricht enthaltenes MRI- Objekt einzufügen.
In einem zweiten Verfahrensschritt B wird ein SPI-Wert fest- gelegt.
In einem dritten Verfahrensschritt C wird der SPI-Wert in das MRI-Objekt der NSIS-Signalisierungs-Nachricht eingefügt. In einem vierten Verfahrensschritt D wird das S-Flag im MRI- Objekt gesetzt.
In einem fünften Verfahrensschritt E wird ein sich auf die IP-Addresse des MK beziehender Adressraum in das MRI Objekt eingefügt. Dies kann beispielsweise durch Angabe der IP- Adresse des MKs sowie eines Präfixes erfolgen.
Das im GIST-Protokoll vorgesehene MRI-Objekt erlaubt neben der Angabe einer einzigen IP-Adresse auch die Angabe eines Adressraums. Ein MK der seinen Anknüpfungspunkt innerhalb ei¬ nes bestimmten Zugangsnetzes wechselt, kann deshalb im MRI- Objekt beispielsweise durch ein Präfix auch einen Adressraum angeben, der den gesamten Adressraum des Zugangsnetzes um- fasst, über das der MK momentan angeschlossen ist, bzw. innerhalb dem der Anknüpfungspunkt des MK liegt. Ebenso kann ein MK, der zwischen verschiedenen Zugangsnetzen wechselt, auch den gesamten IP-Adressraum im MRI-Objekt angeben, inner- halb dem sich der MK üblicherweise bewegt.
Das VPN-Gateway hat demgegenüber in den meisten Fällen nur eine einzige IP-Adresse oder nur sehr wenige, zu einem einzi¬ gen IP-Subnetz gehörende IP-Adressen. Aus diesem Grund ist es in den meisten Fällen ausreichend, nur eine einzige IP- Adresse für das Gateway im MRI-Objekt anzugeben, oder wieder¬ um beispielsweise mittels eines Präfixes einen Adressraum an¬ zugeben, der mit dem Subnetz des Gateways übereinstimmt.
Die NSIS-Knoten entlang des Pfades des Tunnels verwenden in Verbindung mit anderen Header-Feldern den Sicherheits- Parameter-Index (Security Parameter Index; SPI), um den Da¬ tenverkehr zu identifizieren, auf den sich die Signalisie- rungs-Nachrichten beziehen. Damit dies funktioniert, sind die Signalisierungs-Nachrichten für den IPsec-Tunnel erfindungsgemäß so aufgebaut, dass sie das optionale SPI-FeId im pfad¬ gekoppelten (path-coupled) MRI-Objekt enthalten. Darüber hinaus muss das S-Flag für das MRI-Objekt gesetzt werden. Da die SPI-Werte nur 32 Bits lang sind, kann es vorkommen, dass derselbe SPI-Wert für die IPsec-Tunnel zwei verschiede¬ ner MKs auswählt wird. Hieraus entsteht eine Kollision, wenn die beiden MKs mit dem Selben VPN Gateway verbunden sind, und wenn sie denselben Adressraum bzw. die Selbe Präfix verwenden, also sich in demselben Adressraum bewegen. Solche Kollisionen sind unerwünscht, da diejenigen NSIS-Knoten, die in einem gemeinsamen Abschnitt der Pfade der beiden Tunnel lie- gen, nicht in der Lage sind, zwischen den zu unterschiedli¬ chen Tunneln gehörenden Datenpaketen zu unterscheiden. Grundsätzlich sind jedoch mehrere Methoden denkbar, mit denen das Auftreten solcher Kollisionen verhindert werden kann. Beispielhaft sind nachfolgend vier verschiedene Möglichkeiten aufgelistet:
Das VPN Gateway wählt nicht dieselben SPI-Werte für meh¬ rere unterschiedliche, nach dem MOBIKE-Standard aufge¬ baute MK-zu-VPN IPsec-Tunnel aus. In Anbetracht der Tat- sache, dass der SPI-Wert 32 Stellen aufweist, entspre¬ chend 232 möglichen verschiedenen SPI-Werten, sollte dies für die meisten Fälle als ausreichend erachtet wer¬ den . Die NSIS-Knoten sollen nicht nur mit dem SPI-Wert in den Datenpaketen abgeglichen werden, sondern auch mit dem im MRI-Objekt angegebenen IP-Adressbereich des MK. Diese Vorgehensweise stimmt im Wesentlichen mit dem standard¬ mäßigen Geist-Ablauf überein. Damit die oben angegebenen Maßnahmen nutzbringend sind, sollte der MK eine einzige IP-Adresse für das VPN Gate¬ way im MRI-Objekt angeben und den Adressraum für die eigene IP-Adresse so weit wie möglich einschränken. Dies ist dann sinnvoll, wenn der MK gegenwärtig beispielswei¬ se die Adresse 155.234.15.6 hat, und sich nur innerhalb des Subnetzes des 155.234 Klasse B Netzwerks bewegt. Ein solcher Fall tritt häufig in Netzwerken großer Unternehmen oder Organisationen auf, innerhalb denen die Mitarbeiter mit ihren als MK bezeichneten Geräten frei bewe- gen können. In obigem Beispiel gibt der MK seine momentane IP-Adresse zusammen mit einem Präfix von 16 im MRI- Objekt an.
Der MK wählt einen SPI-Wert für den VPN-nach-MK-Tunnel der nur sehr unwahrscheinlich mit den SPI-Werten anderer MKs übereinstimmt. Hierzu wird der SPI-Wert beispiels¬ weise zufällig ausgewählt, oder mittels einer geeigneten Funktion durch den NSIS-Session-Identifier bestimmt.
Die Erfindung ist insbesondere im Bereich der Herstellung und dem Vertrieb von mittels mobiler Endgeräte nutzbaren Virtuel¬ len Privaten Netzwerken sowie von Netzwerkkomponenten für solche Netzwerke gewerblich anwendbar.

Claims

Patentansprüche
1. Verfahren zur Verringerung des Signalisierungs-Overheads eines Mobilen Knotens (MK) , der mindestens eine aktive Next- Steps-In-Signaling (NSIS) -Signalisierungs-Session unterhält sowie eine MOBIKE Verbindung mit einem Virtuellen-Privaten- Netzwerk (VPN) -Gateway hat, und der seinen Anknüpfungspunkt an das Internet wechselt, gekennzeichnet durch die Verfahrensschritte:
Einfügen mindestens der IP-Adresse des VPN-Gateways und/oder eines mit dem Subnetz des VPN-Gateways übereinstimmenden Adressraums in ein in der NSIS- Signalisierungs-Nachricht enthaltenes Routing- Information (Message Routing Information; MRI) -Objekt, Festlegung eines Werts für einen Sicherheits-Parameter- Index (Security Parameter Index; SPI), Einfügen des SPI-Werts in das MRI-Objekt, sowie - Setzen des S-Flags im MRI-Objekt, sowie
Einfügen eines sich auf die IP-Adresse des MK beziehen¬ den Adressraums in das MRI Objekt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zusätzlich im MRI-Objekt ein Adressraum für die IP- Adresse des MK angegeben wird, der die unter Berücksichtigung der üblichen Bewegung des MKs zu erwartenden möglichen IP- Adressen für den MK umfasst.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der MK den Adressraum für die eigene IP-Adresse so weit wie möglich einschränkt.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der SPI-Wert durch das VPN-Gateway so festgelegt wird, dass Kollisionen zwischen IPsec-Tunneln, die zwischen unterschiedlichen MKs und demselben VPN-Gateway bestehen, vermieden werden.
5. Verfahren nach einem Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der SPI-Wert zufällig ausgewählt, oder mittels einer ge¬ eigneten Funktion durch den NSIS-Session-Identifier festge- legt wird.
PCT/EP2007/060088 2006-09-28 2007-09-24 Verfahren zur optimierung der nsis-signalisierung bei mobike-basierenden mobilen anwendungen WO2008037685A2 (de)

Priority Applications (8)

Application Number Priority Date Filing Date Title
PL07820495T PL2070285T3 (pl) 2006-09-28 2007-09-24 Sposób optymalizacji sygnalizacji nsis w zastosowaniach mobilnych opartych na mobike
US12/311,439 US8396971B2 (en) 2006-09-28 2007-09-24 Method for optimizing NSIS signaling in MOBIKE-based mobile applications
KR1020097008611A KR101062604B1 (ko) 2006-09-28 2007-09-24 Ｍｏｂｉｋｅ-기반 모바일 애플리케이션에서 ｎｓｉｓ 시그널링을 최적화하는 방법
CN2007800362852A CN101523847B (zh) 2006-09-28 2007-09-24 用于在基于mobike的移动应用中优化nsis信令的方法
DE502007002769T DE502007002769D1 (de) 2006-09-28 2007-09-24 Verfahren zur optimierung der nsis-signalisierung bei mobike-basierenden mobilen anwendungen
EP07820495A EP2070285B1 (de) 2006-09-28 2007-09-24 Verfahren zur optimierung der nsis-signalisierung bei mobike-basierenden mobilen anwendungen
AT07820495T ATE456895T1 (de) 2006-09-28 2007-09-24 Verfahren zur optimierung der nsis-signalisierung bei mobike-basierenden mobilen anwendungen
JP2009529680A JP4801201B2 (ja) 2006-09-28 2007-09-24 Ｍｏｂｉｋｅベースのモバイルアプリケーションにおけるｎｓｉｓシグナリングの最適化方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102006046023.5 2006-09-28
DE102006046023A DE102006046023B3 (de) 2006-09-28 2006-09-28 Verfahren zur Optimierung der NSIS-Signalisierung bei MOBIKE-basierenden mobilen Anwendungen

Publications (2)

Publication Number Publication Date
WO2008037685A2 true WO2008037685A2 (de) 2008-04-03
WO2008037685A3 WO2008037685A3 (de) 2008-08-14

Family

ID=39185239

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/060088 WO2008037685A2 (de) 2006-09-28 2007-09-24 Verfahren zur optimierung der nsis-signalisierung bei mobike-basierenden mobilen anwendungen

Country Status (10)

Country Link
US (1) US8396971B2 (de)
EP (1) EP2070285B1 (de)
JP (1) JP4801201B2 (de)
KR (1) KR101062604B1 (de)
CN (1) CN101523847B (de)
AT (1) ATE456895T1 (de)
DE (2) DE102006046023B3 (de)
ES (1) ES2337626T3 (de)
PL (1) PL2070285T3 (de)
WO (1) WO2008037685A2 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8856387B2 (en) * 2008-04-24 2014-10-07 Qualcomm Incorporated Local IP access scheme
US10390277B2 (en) 2016-11-30 2019-08-20 Samsung Electronics Co., Ltd. MOBIKE aware LTE to Wi-Fi handoff optimization
CN113676493B (zh) * 2021-09-29 2022-10-11 网宿科技股份有限公司 一种基于mobike协议的通信方法及电子设备

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6839338B1 (en) * 2002-03-20 2005-01-04 Utstarcom Incorporated Method to provide dynamic internet protocol security policy service
US7453851B2 (en) * 2002-06-20 2008-11-18 Spyder Navigations L.L.C. QoS signaling for mobile IP
US7269173B2 (en) * 2002-06-26 2007-09-11 Intel Corporation Roaming in a communications network
EP1463257B1 (de) * 2003-03-27 2006-06-07 Motorola Inc. Kommunikation zwischen einem privatem Netzwerk und einem mobilem Endgerät
CN1886953A (zh) * 2003-11-28 2006-12-27 松下电器产业株式会社 通信切换方法、通信消息处理方法、利用计算机执行这些方法的程序、以及通信系统
US7457626B2 (en) * 2004-03-19 2008-11-25 Microsoft Corporation Virtual private network structure reuse for mobile computing devices
JP2006024982A (ja) 2004-07-06 2006-01-26 Keio Gijuku セキュリティ・アソシエーションの確立方法
US7933253B2 (en) * 2004-09-20 2011-04-26 Panasonic Corporation Return routability optimisation
WO2006059216A1 (en) * 2004-12-01 2006-06-08 Nokia Corporation Method and system for providing wireless data network interworking
US7792072B2 (en) * 2004-12-13 2010-09-07 Nokia Inc. Methods and systems for connecting mobile nodes to private networks
US7813319B2 (en) * 2005-02-04 2010-10-12 Toshiba America Research, Inc. Framework of media-independent pre-authentication

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DEVARAPALLI AZAIRE NETWORKS P ERONEN NOKIA V: "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE; draft-ietf-mip4-mobike-connectivity-01.txt " IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, Bd. mip4, Nr. 1, 13. Juni 2006 (2006-06-13), XP015045650 ISSN: 0000-0004 *
KIVINEN SAFENET T ET AL: "Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol; rfc4621.txt" IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1. August 2006 (2006-08-01), XP015047385 ISSN: 0000-0003 *
NEXT STEPS IN SIGNALING (NSIS) H CHENG J HUANG T SANDA T UE PANASONIC: "NSIS Flow ID and packet classification issues; draft-cheng-nsis-flowid-issues-02.txt" IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, Nr. 2, 24. Oktober 2005 (2005-10-24), XP015042098 ISSN: 0000-0004 *

Also Published As

Publication number Publication date
WO2008037685A3 (de) 2008-08-14
EP2070285A2 (de) 2009-06-17
KR101062604B1 (ko) 2011-09-06
JP2010504714A (ja) 2010-02-12
ES2337626T3 (es) 2010-04-27
DE502007002769D1 (de) 2010-03-18
ATE456895T1 (de) 2010-02-15
PL2070285T3 (pl) 2010-07-30
EP2070285B1 (de) 2010-01-27
CN101523847A (zh) 2009-09-02
DE102006046023B3 (de) 2008-04-17
US8396971B2 (en) 2013-03-12
KR20090075840A (ko) 2009-07-09
JP4801201B2 (ja) 2011-10-26
US20090241181A1 (en) 2009-09-24
CN101523847B (zh) 2012-10-03

Similar Documents

Publication Publication Date Title
EP1602214B1 (de) Verfahren, system und speichermedium um kompatibilität zwischen IPsec und dynamischem routing herzustellen
DE69919569T2 (de) Verwaltung von verbindungsorientierten diensten über das internet-protokoll
DE69727930T2 (de) Zusammenfassung von verbindungen in vermittlungskommunikationsnetzen
EP2274935B1 (de) Verfahren und vorrichtung zum herstellen von zumindest einer erweiterung einer zuordnungsnachricht für wireless mesh netze
EP3477890B1 (de) Verfahren zum aufbau und betrieb eines dedizierten netzwerks in einem mobilfunknetzwerk und inter-operator blockchain netzwerk
WO2002087160A2 (de) Heterogenes mobilfunksystem
DE102006036107A1 (de) Verfahren zur Ermittlung einer Aufgabenerlaubnis
DE60211287T2 (de) Handhabung von Verbindungen, die zwischen Firewalls umziehen
EP1761081A1 (de) Kommunikationssystem, Vermittlungsknoten-Rechner und Verfahren zur Bestimmung eines Kontrollknotens
EP4327506A1 (de) Verwalten von schlüsseln für eine sichere kommunikation zwischen kommunikationsteilnehmern über einen getrennten kommunikationskanal
EP2070285B1 (de) Verfahren zur optimierung der nsis-signalisierung bei mobike-basierenden mobilen anwendungen
DE10231941A1 (de) Datenpaketstruktur für direkt adressiertes Multicast-Protokoll
DE10231958A1 (de) Direkt adressiertes Multicast-Protokoll
EP1249154A1 (de) Verfahren und vorrichtung zur zugangssteuerung eines kommunikationsnetzes
DE10017062A1 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE102011080676A1 (de) Konfiguration eines Kommunikationsnetzwerks
WO2012123001A1 (de) Verfahren zum aufbau einer kommunikationsverbindung
EP1992127B1 (de) Kommunikationssystem, rechner und verfahren zum ermitteln eines zu verwendenden kommunikationsprotokolls in einem kommunikationssystem
WO2005117339A1 (de) Verfahren zur erkennung einer notwendigerweise durchzuführenden konfiguration von bei durchführung eines dienstes beteiligten gebührenprozessen auf netzelementen in einem kommunikationsnetz
DE102005059827B4 (de) Verfahren zum Verwalten eines Zählerstandes in einem Kommunikationsnetz
EP1994676B1 (de) Verfahren zum erzeugen eines adressfeldes, verfahren und vorrichtung zur übertragung einer electronischen nachricht sowie datenpaket
EP1748619B1 (de) Verfahren zum Aufbau einer direkten, netzübergreifenden und abhörsicheren Kommunikationsverbindung
EP1696637B1 (de) Verfahren zur Reduktion von Datenpaketverlusten beim Aktualisieren einer Adresstabelle
EP1748618B1 (de) Verfahren zum Aufbau einer netzübergreifenden Kommunikationsverbindung zwischen zumindest zwei Kommunikationsnetzwerken
EP1903753A1 (de) Verfahren zur Erzeugung einer externen Internet-Protokoll-Adresse zur Verwendung als Zieladresse einer Reserve-External-Address-Nachricht

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780036285.2

Country of ref document: CN

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2007820495

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2009529680

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 12311439

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 1020097008611

Country of ref document: KR