DE602004007303T2 - Identifizierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten - Google Patents

Identifizierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten Download PDF

Info

Publication number
DE602004007303T2
DE602004007303T2 DE602004007303T DE602004007303T DE602004007303T2 DE 602004007303 T2 DE602004007303 T2 DE 602004007303T2 DE 602004007303 T DE602004007303 T DE 602004007303T DE 602004007303 T DE602004007303 T DE 602004007303T DE 602004007303 T2 DE602004007303 T2 DE 602004007303T2
Authority
DE
Germany
Prior art keywords
host
hip
identifier
gateway node
address
Prior art date
Legal status (The legal status 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 status listed.)
Expired - Lifetime
Application number
DE602004007303T
Other languages
English (en)
Other versions
DE602004007303D1 (de
Inventor
Petri Aulis Jokela
Pekka Nikander
Patrik Mikael Salmela
Jari Arkko
Jukka Ylitalo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE602004007303D1 publication Critical patent/DE602004007303D1/de
Application granted granted Critical
Publication of DE602004007303T2 publication Critical patent/DE602004007303T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • 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/04—Registration at HLR or HSS [Home Subscriber Server]
    • 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (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)
  • Conveying And Assembling Of Building Elements In Situ (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)
  • Mechanical Coupling Of Light Guides (AREA)
  • Computer And Data Communications (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft ein Verfahren des Verwendens des Host-Identitätsprotokolls (HIP) zum mindestens teilweisen Sichern von Kommunikationen zwischen zwei in unterschiedlichen jeweiligen Netzumgebungen betriebenen Hosts, wobei mindestens einer der beiden Hosts HIP-fähig ist.
  • 2. Beschreibung des Standes der Technik
  • Als das Internet ursprünglich eingerichtet worden ist, waren Hosts ortsfest und es gab ein implizites Vertrauen zwischen Benutzern abgesehen von dem Fehlen realer Sicherheits- oder Host-Identifikationsprotokollen, und diese Situation hat sich selbst bei der weiteren Aufnahme und Verwendung der Technologie fortgesetzt. Es gab kaum Bedarf zum Überlegen von Techniken zum Handhaben von Host-Mobilität, da Computer relativ sperrig und immobil waren.
  • Mit der Revolution der Telekommunikations- und Computerindustrie in den frühen 90ern wurden kleinere Kommunikationsausrüstungen und Computer in größerem Umfang verfügbar und die Erfindung des World-Wide-Web (weltweiten Netzes) und all der Dienste, die mit ihm einhergehen, machten das Internet schließlich für die Durchschnittsperson attraktiv. Die Kombination von zunehmender Benutzung der Netz- und Mobiltelekommunikationen führte zu dem Bedarf nach sicherem Mobilitätsmanagement im Internet.
  • Die zunehmende Anzahl an einbezogenen Parteien und die Geldwerten-Transaktionen, die für gewisse Dienste erforderlich waren, kreierten ebenfalls einen Bedarf nach hinzugefügter Anwendungsschicht-Sicherheit. Derzeit laufen die am häufigsten benutzten Verschlüsselungsprotokolle, beispielsweise SSL/TLS, innerhalb der oberen Netzwerkschichten, beispielsweise TCP.
  • Die oben erwähnten Mobilitätsmanagement- und Sicherheitsangelegenheiten berücksichtigend, sind der "Mobile-IP"-Standard (Mobiler Internet-Standard) (C. Perkins, "IP Mobility Support for IPv4", RFC 3220, IETF, 2002) und der Mobile-IPv6-Standard (mobiler Standard zum Internetprotokoll, Version 6) (D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", Internet Draft, work in Progress, draftietf-mobileip-ipv6-24.txt, IETF, 2003) eingeführt worden. Gemeinsam sind diese Spezifikationen geplant worden zum Bereitstellen von Mobilitätsunterstützung für das Internet der nächsten Generation. Sicherheitsarbeit in der Entwicklung und der Form von IPsec und zugehörige Aktivitäten wie verschiedene Schlüsselaustauschprotokolle, deren Ziel ist, Sicherheit in der IP-Schicht bereitzustellen. Jedoch hat die Erfahrung gezeigt, dass es weitgehend schwierig ist, kombinierte Sicherheit und Mobilität unter Verwendung der derzeitigen Standards zu erreichen.
  • Eine IP-Adresse beschreibt einen topologischen Ort eines Knotens im Netz. Die IP-Adresse wird verwendet zur Leitwegfestlegung (zum Routing) des Pakets von dem Knoten zu dem Ziel. Gleichzeitig wird die IP-Adresse auch verwendet zum Identifizieren des Knotens, zwei unterschiedliche Funktionen in einer Einheit bereitstellend. Dies gilt für eine Person, die, gefragt wer sie ist, mit ihrer Heimatadresse antwortet. Wenn auch Mobilität berücksichtigt wird, wird die Situation komplizierter: da IP-Adressen als Host-Identifizierer in diesem Schema agieren, brauchen sie nicht geändert zu werden; jedoch, da IP-Adressen auch topologische Orte beschreiben, müssen sie notwendigerweise geändert werden, wenn ein Host seinen Ort im Netz ändert. Klar gesagt, es ist unmöglich, gleichzeitig sowohl Stabilität als auch dynamische Änderungen zu erreichen.
  • In dem Fall von Mobile-IP (mobilem Internetprotokoll) ist die Lösung, einen festen Heimatort zu verwenden, der für den Knoten eine "Heimatadresse" bereitstellt. Die Heimatadresse identifiziert den Knoten und stellt auch einen stabilen Ort für ihn bereit, wenn er sich zuhause befindet. Die derzeitige Ortsinformation ist in der Form einer c/o-Adresse verfügbar, die zu Routing-Zwecken verwendet wird, wenn der Knoten sich nicht zuhause befindet.
  • Eine andere Lösung des Problems ist, die Identifikations- und Orts-Funktionen voneinander zu trennen und dies ist ein Ansatz, der in dem Host Identitätsprotokollvorschlag ("Host Identity Protocol (HIP) proposal") (R. Moskowitz, P. Nikander, P. Jakela, "Host Identity Protocol", Internet Draft, work in Progress, draft-moskowitz-hip-09.txt, IETF, 2004) herangezogen wird. HIP trennt die Orts- und Identiätsrollen der IP-Adressen durch Einführen eines neuen Namensraums, der Host-Identität (HI bzw. Host Identity). In HIP ist die Host-Identität im Grunde ein öffentlicher kryptographischer Schlüssel eines Öffentlich-Privat-Schlüsselpaars. Der öffentliche Schlüssel identifiziert die Partei, die nur die Kopie des privaten Schlüssels hält. Eine Host-Verarbeitung des privaten Schlüssels des Schlüsselpaars kann direkt bestätigen, dass sie den öffentlichen Schlüssel "besitzt", der verwendet wird, um sie im Netz zu identifizieren. Die Trennung stellt auch ein Mittel bereit, um in sicherer Weise Mobilität und Multi-Homing (Mehrfach-Heimatschaft) auf sichere Weise zu handhaben.
  • HIP wird nachstehend detaillierter diskutiert, aber ist nicht der einzige Vorschlag basierend auf der Idee der Orts- und Identitätstrennung. FARA (D. Clark, R. Graden, A. Fal, V. Pingali, "FARA: Reorganizing the Addressing Architecture", ACM SIGCOMM 2003 Workshops, August 25 & 27, 2009) ist ein verallgemeinertes Modell der Idee, die ein Rahmenwerk bereitstellt, von dem die tatsächliche Architektur hergeleitet werden kann. FARA könnte das HIP verwenden, wenn die Knoten-Identifikationen verifiziert sind, und folglich könnte HIP ein Teil einer speziellen FARA-Instanziierung sein. Der PeerNet-Vorschlag (J. Eriksson, M. Faloutsos, S. Krishnamurthy, "PeerNet: Pushing Peer-to-Peer Down the Stack", IPTPS '03, 20.–21. Februar 2003) diskutiert auch die Orts- und Identitätstrennung. Die Internet Indirection Infrastructure, I3 (I. Stoica, et al, "Internet Indirection Infrastructure", ACM SIGCOMM '02, 19.–23. August 2002) definiert auch eine Trennung zwischen der Identitäts- und Routing-Information.
  • Zudem ist das Adressieren in speziellen HIP-basierten Verbindungen zwischen gewöhnlichen und HIP-fähigen Knoten in L. Eggert, "Host Identity Protocol (HIP) Rendezvous Mechanisms", Internet Draft, draft-eggert-hip-rendezvous.txt, IETV, 2004, offenbart.
  • Das Host-Identitätsprotokoll führt eine Trennung zwischen der Orts- und Identitätsinformation bei der IP-Schicht ein. Zu der Trennung wird ein Protokoll definiert zum Verhandeln sicherer Zuordnungen (SAs bzw. Security Associations) HIP-fähiger Knoten.
  • Mit HIP hat jeder Host einige oder mehrere Identitäten, die Langzeit oder Kurzzeit sein können, die verwendet werden können, um ihn im Netz zu identifizieren. Mit HIP ist ein Identifizierer der öffentlichen Schlüssel eines Öffentlich-Privat-Schlüsselpaars. Wenn der Host den privaten Schlüssel besitzt, kann er belegen, dass er tatsächlich diese Identität "besitzt", die der öffentliche Schlüssel repräsentiert; dies ist ähnlich dem Zeigen einer "ID"- bzw. Identitätskarte (Ausweis).
  • Jeder Host kann Kurzzeitschlüssel erzeugen, die nur für eine kurze Zeit zu verwenden sind. Diese sind nützlich, wenn es nicht erforderlich ist für den Knoten, später bei derselben Identität identifiziert zu werden. Beispielsweise kann das Kaufen von Büchern von einem Buchladen ein Langzeit-Verhältnis sein während das einmalige Kontaktieren eines Servers zum Sammeln von Benutzerprofilen als Kurzzeitaktion betrachtet werden könnte. Im letzteren Fall kann eine Kurzzeit-Identität erstellt werden zum Vermeiden einer weiteren Verbreitung der Langzeit-Identität.
  • Die HIP-Host Identität (HI), die ein öffentlicher Schlüssel ist, kann recht lang sein und ist demnach nicht in allen Situationen praktikabe. In HIP wird die HI durch ein 128-Bit langes Host-Identitäts-Etikett (HIT bzw. Host Identity Tag) repräsentiert, das durch Zerhacken (hashing) der HI erzeugt wird. Demnach identifiziert das HIT eine HI. Da das HIT 128 Bit lang ist, kann es für IPv6-Anwendungen direkt verwendet werden, da es exakt dieselbe Länge hat wie die IPv6-Adressen.
  • Eine andere Darstellung der Host-Identitäten ist der Local-Scope-Identifier (LSI), welcher eine 32-Bit-Darstellung für die Host-Identität ist. Der Zweck der LSI ist es, die Verwendung von Host-Identitäten in existierenden Protokollen und APIs zu erleichtern. Beispielsweise kann, da die LSI von derselben Länge ist wie eine IPv4-Adresse, sie direkt für IPv4-Anwendungen verwendet werden. Obwohl ein Großteil des Restes dieser Beschreibung basierend auf der längeren HIT sein wird, wird es einzusehen sein, dass dieselben oder ähnlichen Überlegungen für die alternative LSI-Darstellung gültig sind.
  • Wenn HIP verwendet wird, sehen die oberen Schichten einschließlich der Anwendungen nicht länger die IP-Adresse. Stattdessen sehen sie die HIT als die "Adresse" des Ziel-Hosts. Die Ortsinformation ist bei einer neuen Schicht versteckt, die später zu beschreiben ist. Die IP-Adressen identifizieren nicht länger die Knoten, sie werden nur für das Routing der Pakete im Netz verwendet.
  • Anwendungen sind nicht üblicherweise an Ortsinformation interessiert, aber müssen die Identität ihrer Gegenüber (peers) kennen. Die Identität wird durch das HIT repräsentiert. Dies bedeutet, dass die IP-Adresse nur bei unteren Schichten von Wichtigkeit ist, wo das Routing betroffen ist. Die HITs, die die Anwendungen verwenden, müssen auf die entsprechenden IP-Adressen abgebildet werden, bevor irgendwelche Pakete den Host verlassten. Dies wird in einer neuen Host-Identitätsschicht (Host Identity Layer) erreicht, wie sie nachstehend beschrieben wird.
  • 1 der beiliegenden Zeichnungen stellt die verschiedenen Schichten in HIP dar, die die Standardtransportschicht 4 umfassen, die Netzwerkschicht 8 und die Vermittlungsschicht (link layer) 10, mit einem mit der Transportschicht 4 darunter kommunizierenden Prozess 2. Mit HIP ist eine neue Host-Identitätsschicht (Host Identity Layer) 6 zwischen der Transportschicht 4 und der Netzwerkschicht 8 eingefügt.
  • Lokal werden jede HI und ihr zugehöriges HIT auf die IP-Adressen des Knotens abgebildet. Wenn Pakete den Host verlassen, wird der korrekte Leitweg gewählt (mit welchen Mitteln auch immer) und entsprechende IP-Adressen werden in die Pakete als die Quellen- und Zieladressen eingegeben. Jedes von der oberen Schicht ankommende Paket enthält das HIT des Gegenübers (peer) als die Zieladresse. Das Abbilden zwischen dem HIT und der Ortsinformation kann bei der HI-Schicht 6 gefunden werden. Demnach wird die Zieladresse in die abgebildete IP-Adresse umgewandelt das Quellen-HIT wird in die Quellen-IP-Adresse umgewandelt.
  • Das Abbilden zwischen einer Peer-HIT und der IP-Adresse kann auf verschiedene Arten eingeholt werden, von denen eine von einem DNS-Server ist. Die Ortsinformation kann durch den Peer-Knoten jederzeit aktualisiert werden. Die Aktualisierungsprozedur wird in dem Mobilitäts-Management-Unterabschnitt detaillierter diskutiert werden.
  • HIP definiert einen Basisnachrichtenaustausch, der vier Nachrichten, einen Vier-Wege-Hand-Shake enthält, und er wird verwendet zum Erstellen einer Sicherheitszuordnung (SA) zwischen HIP-fähigen Hosts. Während des Nachrichtenaustauschs wird die Diffie-Hellman-Prozedur verwendet zum Erstellen eines Sitzungsschlüssels und zum Einrichten eines Paars von IPsec-Encapsulating-Security Payload- (ESP)Security-Associations (SAs) (d.h., IPsec-Einkapselungs-Sicherheits-Nutzlast-Sicherheitszuordnungen) zwischen den Knoten.
  • 2 der beiliegenden Zeichnungen stellt den Betriebsablauf des Vier-Wege-Hand-Shake dar. Die verhandelnden Parteien werden als der Initiator (der die Verbindung startet) und der Beantworter bezeichnet. Der Initiator beginnt die Verhandlung durch Senden des I1-Pakets, das die HITs der an der Verhandlung teilhabenden Knoten enthält. Das Ziel-HIT kann auch zu Null gemacht sein, wenn das HIT des Beantworters dem Initiator nicht bekannt ist.
  • Wenn der Beantworter das I1-Paket erhält, sendet er ein R1-Paket zurück, das ein durch den Initiator zu lösendes Rätsel enthält. Das Protokoll ist so entworfen, dass der Veranlasser den größten Teil der Berechnung vornehmen muss während des Rätsellösens. Dies liefert einen gewissen Schutz gegenüber DoS-Angriffen. Der R1 veranlasst auch die Diffie-Hellmann-Prozedur, die den öffentlichen Schlüssel des Beantworters gemeinsam mit den Diffie-Hellmann-Parametern enthält.
  • Sobald das R1-Paket empfangen worden ist, löst der Initiator das Rätsel und sendet ein Antwort-Cookie in einem I2-Paket gemeinsam mit einem IPsec-SPI-Wert und seinem verschlüsselten öffentlichen Schlüssel zu dem Beantworter. Der Beantworter verifiziert das Gelöstsein des Rätsels, authentifiziert den Initiator und erstellt die IPsec-ESP-SAs. Die abschließende R2-Nachricht enthält den SPI-Wert des Beantworters.
  • Die SAs zwischen den Hosts sind an die Host-Identitäten gebunden, die durch die HITs repräsentiert werden. Jedoch enthalten die Pakete, die in dem Netz wandern, nicht die tatsächlich HI-Information, sondern das ankommende Paket wird identifiziert und abgebildet auf die SA unter Verwendung des Sicherheitsparameterindexwerts bzw. SPI-Werts in dem IPsec- Header. 3 der beiliegenden Zeichnungen zeigt die logischen und tatsächlichen Paketstrukturen, wenn sie sich durch das Netz bewegen.
  • Vom Vorangehenden ist klar, dass ein Ändern der Ortsinformation in dem Paket keinerlei Probleme für die IPsec-Verarbeitung mit sich bringt. Das Paket ist noch korrekt unter Verwendung der SPI identifiziert. Wenn aus irgendeinem Grund das Paket zu einem falschen Ziel geroutet wird, ist der Empfänger nicht imstande, das Paket zu öffnen, da er nicht den korrekten Schlüssel hat.
  • Wenn ein abgehendes Paket bei der HI-Schicht von der oberen Schicht ankommt, wird das Ziel-HIT von dem IPsec-SADE verifiziert. Wenn eine auf das Paket auf dem HIT abbildbare SA gefunden wird, wird das Paket unter Verwendung des dem SA zugeordneten Sitzungsschlüssels verschlüsselt.
  • Das HIT kann nicht verwendet werden zum Routen des Pakets. Demnach müssen die Ziel- (und Quellen-)Adressen geändert werden, um die IP-Adressen der Knoten abzubilden. Diese Abbildungen werden wie zuvor erwähnt in der HI-Schicht gespeichert. Nachdem die Adressen geändert worden sind, kann das Paket zu dem Netz gesendet werden, wo es zu dem Ziel unter Verwendung der IP-Adresseninformation geroutet wird.
  • Bei dem empfangenden Host wird der SPI-Wert verwendet zum Finden der korrekten SA von dem IPsec-SADE. Wenn ein Eintrag gefunden wird, können IP-Adressen geändert werden in entsprechende HITs und das Paket kann unter Verwendung des Sitzungsschlüssels entschlüsselt werden.
  • Mobilität wird definiert als die Situation, in der ein Host sich bewegt während er seinen Kommunikationskontext aktiv hält, oder mit anderen Worten, der Host ändert einen topologischen Ort, der durch die IP-Adresse beschrieben wird, während er noch alle existierenden Bindungen aktiv beibehält. Die auf dem Host ablaufenden Prozesse sehen nicht die Mobilität mit Ausnahme der Möglichkeit, wenn die erfahrene Dienstequalität sich ändert.
  • Der Mobil-Host kann den Ort innerhalb eines Zugangsnetzes, zwischen unterschiedlichen Zugangstechnologien oder selbst zwischen unterschiedlichen IP-Adressbereichen, beispielsweise zwischen den IPv4- und IpvE-Netzen, wechseln. In HIP bemerkt die Anwendung die Änderung in der IP-Adressversion nicht. Die HI-Schicht versteckt die Änderung vollständig vor oberen Schichten. Sicherlich muss der Gleichberechtigten- bzw. Peer-Knoten imstande sein, die Ortsaktualisierung, die die IP-Version ändert, zu handhaben und die Pakete müssen routbar sein unter Verwendung einer kompatiblen Adresse. Wenn ein Knoten sowohl IPv4- als auch IPv6-Verbindbarkeit hat, kann er einen Proxy-Knoten verwenden, der die Adressenversions-Umwandlung vornimmt und die Verbindbarkeit anstelle des Knotens bereitstellt.
  • Multi-Homing (Mehrfach-Heimatschaft) bezeichnet eine Situation, in der ein Endpunkt einige parallele Kommunikationspfade hat, die er verwenden kann. Gewöhnlich ist Multi-Homing ein Ergebnis davon, dass der Host einige Netzschnittstellen (End-Host-Multi-Homing) hat oder bedingt durch ein Netz zwischen dem Host und dem Rest des Netzes mit redundanten Pfaden (Orts-Multi-Homing).
  • Mit HIP macht die Trennung zwischen der Orts- und Identitätsinformation es klar, dass die Paketidentifizierung und das Routing klar voneinander getrennt werden können. Der ein Paket empfangende Host identifiziert den Sender dadurch, dass er zuerst den korrekten Schlüssel erhält und dann das Paket entschlüsselt. Demnach sind die IP-Adressen, die in dem Paket sind, irrelevant.
  • Ein HIP-Mobilknoten (HMN) bzw. HIP Mobile Node), der sich im Netz bewegt, kann den Anbindungspunkt zu dem Internet konstant ändern. Wenn der Anbindungspunkt geändert wird, ändert sich auch die IP-Adresse. Diese geänderte Ortsinformation muss zu den Gleichberechtigten-Knoten bzw. Peer-Knoten gesendet werden, d.h. den HIP-Korrespondent-Knoten (HCN bzw. HIP Correspondent Node) und dies ist in 4 der beiliegenden Zeichnungen dargestellt. Dieselbe Adresse kann auch zu einem Weiterleitungs-Agent (FA) des HMN gesendet werden, so dass der HMN auch über einen stabileren Punkt erreicht werden kann. Das DNS-System ist zu langsam, um verwendet zu werden zum konstanten Ändern von Ortsinformation. Daher muss es eine stabilere Adresse geben, die verwendet werden kann zum Kontaktieren des HMN. Diese Adresse ist die durch den FA bereitgestellte Adresse.
  • Das HIP-Mobilitäts- und Multi-Homing-Protokoll (HIP Mobility and Multi-homing protocol (P. Nikander, U. Arkko, P. Jokela, "End-Host Mobility and Multihoming with Host Identity Protocol", Internet Draft, work in Progress, draft-nikanderhip-mm-00.txt, IETF, 2003) definiert ein Neuadressierpaket (REA-Paket), das die derzeitige IP-Adresse des HMN enthält. Wenn der HMN den Ort und die IP-Adresse ändert, erzeugt er ein REA-Paket, signiert das Paket mit dem privaten Schlüssel, der mit dem verwendeten HI übereinstimmt und sendet das Paket zu dem Peer-Knoten und zu dem FA.
  • Wenn der Peer-Knoten ein REA-Paket empfängt, muss er einen Adressenverifizierungsprozess für die IP-Adresse starten, die in dem REA-Paket eingeschlossen ist. Die Adressenverifzierung ist erforderlich zum Vermeiden des Akzeptierens falscher Aktualisierungen von dem HMN. Er sendet ein Adressenprüfpaket (AC- bzw. Address-Check-Paket) zu der Adresse, die in dem REA-Paket war. Wenn der HMN ein AC empfängt, das mit dem zuvor gesendeten REA übereinstimmt, antwortet er mit einem Adressenprüfantwortpaket (ACR-bzw. Address-Check-Reply-Paket). Nachdem der Peer-Knoten das ACR-Paket empfangen hat, ist die Adressenverifizierung abgeschlossen und er kann die IP-Adresse als die Ortsinformation des HMN hinzufügen.
  • Weil sich der HMN zwischen Netzen, die unterschiedliche IP-Adressenversionen verwenden, bewegen kann, kann die von dem HCN empfangene Adresse auch von einer unterschiedlichen Adressenfamilie sein als der vorangehenden Adresse.
  • Der HCN kann gegebenenfalls nur eine IP-Adressenversion unterstützen. In diesem Fall muss der HCN irgendeinen anderen Proxy-Knoten verwenden, der verwendet werden kann zum Routing von Paketen über das Netz mit der anderen IP-Adressenversion.
  • Ein Multi-Home-HIP-Knoten (HIP-Host mit Mehrfachheimatschaft) mit mehreren IP-Adressen auf unterschiedlichen mit unterschiedlichen Zugangsnetzen verbundenen Schnittstellen konfiguriert, hat viel mehr Möglichkeiten, den Verkehr in Richtung eines Peer-Knotens zu handhaben. Da er mehrere, seinen derzeitigen Ort in dem Netz präsentierende IP-Adressen hat, kann er wünschen, seinen Peer-Knoten alle jener Adressen mitzuteilen. Um dies vorzunehmen, erstellt der Multi-Home-HIP-Knoten ein REA-Paket, das alle Adressen enthält, die er imstande ist, in Richtung dieses speziellen Knotens zu verwenden. Dieser Satz von Adressen kann alle Adressen enthalten, die er hat, oder irgendeine Untergruppe jener Adressen. Wenn der Peer-Knoten das REA-Paket mit den mehreren Adressen empfängt, muss er eine Adressenverifizierung für jede jener Adressen ausführen, um möglicherweise falsche Aktualisierungen zu vermeiden.
  • Der HCN sendet einen Satz von AC-Paketen, die zu den in dem REA-Paket enthaltenen IP-Adressen bestimmt sind. Wenn der HMN jene ACs empfängt, antwortet er zu jeder von jenen mit ACRs. Der HCN kann aus den empfangenen ACR-Paketen bestimmen, welche der Adressen gültig sind.
  • Falsche oder nicht routbare Adressen in dem REA-Paket können entweder verursacht werden, weil der HMN ein tückischer Knoten ist, er einen Fehler in der Stapelimplementierung hat, oder der HMN sich innerhalb eines Netzes befinden kann, das private, nicht im Internet routbare Adressen verwendet.
  • Ein Multi-Home-HIP-Knoten ist imstande, alle verfügbaren Verbindungen zu nutzen, aber die effiziente Nutzung der Verbindungen erfordert ein Policy-System, das Kenntnis von den zugrundeliegenden Zugangsnetzen hat und ihre Verwendung steuern kann. Ein solches Policy-System kann unterschiedliche Arten von Informationen verwenden: Benutzervorlieben, Betreibervorlieben, Eingabe von den Netzverbindungen wie z.B. QoS (Dienstequalität) und so weiter.
  • Um den HIP-Austausch mit einem Mobilknoten zu starten, muss der Initiator-Knoten wissen, wie der Mobilknoten zu erreichen ist. Obwohl für diese Funktion Dynamik-DNS verwendet werden könnte zum unregelmäßigen Bewegen von Knoten, ist in dieser Weise eine Alternative zum Verwenden von DNS, das oben eingeführte Stück statischer Infrastruktur zu verwenden, den Weiterleitungs-Agent (Forwarding Agent, der auch als HIP-Rendezvous-Server bezeichnet wird). Statt des Registrierens seiner derzeit dynamischen Adresse bei dem DNS-Server registriert der Mobilknoten die Adresse bzw. Adressen seines Weiterleitungs-Agent bzw. seiner Weiterleitungs-Agents. Der Mobilknoten hält den Weiterleitungs-Agent bzw. die Weiterleitungs-Agents kontinuierlich aktualisiert in Bezug auf die derzeitige IP-Adresse bzw. -Adressen. Ein Weiterleitungs-Agent leitet einfach das Anfangs- bzw. Initial-HIP-Paket von einem Initiator zu dem Mobilknoten bei seinem derzeitigen Ort. Alle weiteren Pakete fließen zwischen dem Initiator und dem Mobilknoten. Es gibt typischerweise sehr wenig Aktivität auf einem Weiterleitungs-Agent, hauptsächlich Adressenaktualisierungen und Anfangs-HIP-Paketweiterleitung. Demnach kann ein Weiterleitungs-Agent eine große Zahl potentieller Mobilknoten unterstützen. Die Mobilknoten müssen dem Weiterleitungs-Agent vertrauen, um ihre HIP- und IP-Adressenabbildungen in geeigneter Weise aufrecht zu erhalten. Ein Weiterleitungs-Agent ..? für Knoten verwendet werden, die sich an einem festen Ort befinden, da es häufig der Fall ist, dass feste Knoten ihre IP-Adresse regelmäßig ändern, beispielsweise, wenn sie jedesmal zugewiesen wird, wenn eine Internetverbindung durch einen Diensteanbieter für diesen Knoten eingerichtet wird.
  • Der Weiterleitungs-Agent wird auch benötigt, wenn beide Knoten mobil sind und es vorkommt, dass sie sich gleichzeitig bewegen. In diesem Fall werden die HIP-Neuadressierungspakete sich einander im Netz begegnen und niemals den Peer-Knoten erreichen. Um diese Situation aufzulösen, sollte der Knoten sich an die Weiterleitungs-Agent-Adresse erinnern und das HIP-Neuadressierungspaket wieder zu dem Weiterleitungs-Agent schicken, wenn keine Antwort erhalten wird.
  • Der Mobilknoten hält seine Adresse aktuell auf dem Weiterleitungs-Agent durch Einrichten einer HIP-Zuordnung mit dem Weiterleitungs-Agent und Senden von HIP-Adresspaketen zu ihm. Ein Weiterleitungs-Agent wird zulassen, dass zwei Mobilsysteme ohne irgendwelche zusätzliche Infrastruktur (zusätzlich zu dem Weiterleitungs-Agent selbst) HIP einschließlich DNS verwenden, wenn sie ein Verfahren haben, das sich von einer DNS-Abfrage unterscheidet zum Erhalten der gegenseitigen HI und HIP.
  • In dem Fall von Altausrüstung kann ein Host gegebenenfalls nicht HIP-fähig sein und die einzige Option ist, Verbindungen zwischen Host unter Verwendung von HIP-Adressen zu identifizieren. Dies ist nicht sicher. Die Situation kann verbessert werden durch Anordnen eines HIP-Proxys zwischen dem HIP-fähigen Host und dem Host, der HIP nicht verwenden kann. Ein typisches Szenario würde ein kleines Firmen-LAN sein, bei dem die Client-Endgeräte nicht HIP-fähig sein. Verkehr wird zu entsprechenden Hosts (die HIP-fähig sind) über den HIP-Proxy geroutet.
  • Diese Anordnung ist in 5 der beiliegenden Zeichnungen dargestellt. In 5 ist ein Alt-Host 12 gezeigt, der mit einem HIP-fähigen Knoten 14 (mit Domain-Namen "hip.foo.com") über einen HIP-Proxy 16 kommuniziert. Der Alt-Host 12 greift auf den HIP-Proxy 16 über ein Zugangsnetz 18 zu, während der HIP-Proxy 16 auf den HIP-Knoten 14 über das Internetz 20 zugreift. Zum teilweise Sichern der Verbindung zwischen Alt-Host 12 und HIP-Knoten 14 verlaufen alle Kommunikationen zwischen dem HIP-Proxy 16 und dem HIP-Knoten 14 durch eine zwischen dem HIP-Proxy 16 und dem HIP-Knoten 14 eingerichtete Sicherheitszuordnung (Security Association) in ähnlicher Weise wie oben unter Bezugnahme auf 3 beschrieben.
  • Jedoch, selbst bevor die Sicherheitszuordnung 22, die in 2 gezeigt wird, eingerichtet werden kann zum Ermöglichen von Kommunikation zwischen dem Alt-Host 12 und dem HIP-Knoten 14, kommt ein Problem auf, wenn der Alt-Host 12 versucht, die IP-Adresse des HIP-Knotens 14 durch Senden einer Abfrage zu einem DNS-Server 24-1 (und wiederum dem DNS-Server 24-2) aufzulösen, wenn der HIP-Knoten 14 sich hinter einem Weiterleitungs-Agent 26 befindet, wie oben beschrieben. Der DNS-Server 24-1 wird das HIT des HIP-Knotens 14 gemeinsam mit der IP-Adresse des Weiterleitungs-Agent 26 zurückgeben. Da der Alt-Host 12 nicht HIP-fähig ist wird er das HIT nicht beachten und beginnen, Nachrichten zu dem Weiterleitungs-Agent 26 zu senden. Ohne das HIT wird der Weiterleitungs-Agent 26 nicht imstande sein, die Zieladresse dieser Nachrichten aufzulösen, da es höchstwahrscheinlich ist, dass einige HIP-Knoten denselben Weiterleitungs-Agent 26 verwenden. In ähnlicher Weise ist der HIP-Proxy 16, da der Alt-Host 12 das HIT mißachtet und nur die IP-Adresse des HIP-Knotens 14 verwendet, wenn er eine Verbindung veranlaßt, nicht imstande, die HIP-Verhandlung zwischen sich und dem HIP-Knoten 14 zu veranlassen, weil er das HIT des HIP-Knotens 14 nicht kennt. Diesem Problem wird in unserer gleichzeitig anhängigen PCT-Anmeldung Nr. PCT/EP04/050129 begegnet.
  • Andere technische Überlegungen ergeben sich auch beim Implementieren von HIP in Mobiltelekommunikationsnetzen der dritten Generation (3G), wo nicht alle Benutzerausrüstungen (UEs) in der 3G-Umgebung HIP-fähig sein. In diesem Umfeld ist das Universale Mobile Kommunikationssystem (UMTS bzw. Universal Mobile Telecommunications System) der 3G-Nachfolger des globalen Systems für mobile Kommunikationen (GSM). Der wichtigste Entwicklungsschritt von GSM in Richtung UMTS ist der allgemeine Paketfunkdienst (GPRS). GPRS führt Paket-Vermittlung in das GSM-Kernnetz ein und ermöglicht direkten Zugriff auf Paketdatennetze (PDNs). Dies befähigt eine Hoch-Datenraten-paketvermittelte Übertragung weit jenseits 64 kbps Grenze von ISDN durch das GSM-Kernnetz, was ein Erfordernis für UMTS-Datenübertragungsraten von bis zu 2 Mbps ist. GPRS ist eine Voraussetzung für die UMTS-Einführung.
  • Es ist wünschenswert, die Vorteile des oben beschriebenen Host-Identiätsprotokolls für Kommunikationen zwischen einem mit einer Netzumgebung wie z.B. UMTS oder GPRS betriebenen Host und einem HIP-fähigen Host, der innerhalb einer anderen Netzumgebung wie z.B. dem Internet arbeitet, bereitzustellen.
  • Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren des Verwendens des Host-Identiätsprotokolls (HIP) zum mindestens teilweisen Sichern von Kommunikationen zwischen einem ersten in einer ersten Netzumgebung betriebenen Host und einem zweiten HIP-fähigen Host, der in einer zweiten Netzumgebung betrieben wird, mit einem einen Übergang zwischen den beiden Umgebungen bildenden Gateway-Knoten, wobei das Verfahren umfasst: Zuordnen eines Identifizierers zu dem ersten Host, Speichern des Identifizierers bei dem Gateway-Knoten, und Senden des Identifizierers zum ersten Host; Verwenden des Identifizierers als Quellenadresse in einer nachfolgend von dem ersten Host zu dem Gateway-Knoten gesendeten Sitzungsveranlassungsnachricht, die eine Angabe hat, dass das Ziel der Naricht der zweite Host ist; und Verwenden des gespeicherten Identifzierers bei dem Gateway-Knoten zum Verhandeln einer HIP-Verbindung zu dem zweiten Host.
  • Der Identifizierer kann bei dem Gateway-Knoten erzeugt werden. Der Identifizierer kann ansprechend auf das Senden einer Kontext-Aktivierungsanfrage von dem ersten Host zum Gateway-Knoten erzeugt werden. Die Kontext- Aktivierungsanfrage kann eine Paketdatenprotokoll-(Packet Data Protocol- bzw. PDP-)-Kontext-Aktivierungsanfrage sein zum Aktivieren eines PDP-Kontexts, und der Identifizierer wird als PDP-Adresse in dem PDP-Kontext verwendet.
  • Der erste Host kann gegebenenfalls nicht HIP-fähig sein, in welchem Fall die sichere HIP-Verbindung zwischen dem Gateway-Knoten und dem zweiten Host verhandelt wird.
  • Alternativ kann der erste Host HIP-fähig sein, in welchem Fall die sichere HIP-Verbindung zwischen den ersten und zweiten Hosts verhandelt wird.
  • Der Identifizierer kann von derselben Länge sein wie eine Adresse in dem Adressierschema, das durch den ersten Host für Kommunikationen mit dem Gateway-Knoten verwendet wird. Beispielsweise kann das IP-Adressierschema derart verwendet werden, dass der Identifizierer als die Quellen-IP-Adresse in der Sitzungsveranlassungsnachricht verwendet wird. Der Identifizierer kann ein Nachschau-Identifizierer sein, der einem für den ersten Host erzeugten und diesem zugeordneten HIP-Identitäts-Etikett zugeordnet ist, es ermöglichend, dass das HIP-Identitäts-Etikett für den ersten Host bei dem Gateway-Knoten unter Verwendung des Nachschau-Identifizierers aufgespürt wird.
  • Alternativ kann der Identifizierer selbst ein HIP-Identitäts-Etikett sein.
  • Das HIP-Identitäts-Etikett kann in einem HIP-Header während einer Verhandlung der HIP-Verbindung zwischen dem Gateway und dem zweiten Host eingeschlossen sein.
  • Das HIP-Identitäts-Etikett kann ein Host-Identitäts-Etikett bzw. ein "Host Identity Tag" (HIT) sein oder ein Lokalbereichsidentifizierer bzw. "Local Scope Identifier" (LSI). Das HIP-Identitäts-Etikett kann von einem Schlüsselpaar erzeugt werden. Das Schlüsselpaar, welches im Gateway-Knoten gespeichert werden kann für die Verwendung während nachfolgender HIP-Kommunikationsvorgänge zwischen dem Gateway-Knoten und dem zweiten Host.
  • Der Identifizierer kann in Form einer IP-Adresse vorliegen.
  • Die erste Netzumgebung kann eine Mobilnetzumgebung sein. Die Mobilnetzumgebung kann eine 3G-Mobilumgebung sein wie z.B. eine UMTS-Mobilnetzumgebung. Die zweite Netzumgebung kann eine Internet-Netzumgebung sein.
  • Der Gateway-Knoten kann die Funktionalität eines HIP-Proxy bereitstellen. Der Gateway-Knoten kann ein Gateway-GPRS-Unterstützungsknoten (Gateway GPRS Support Node bzw. GGSN) sein.
  • Das Verfahren kann das Ersetzen des Identifizierers durch eine Adresse umfassen, die dem Gateway-Knoten als die Quellenadresse in einer nachfolgenden zu dem zweiten Host gesendeten Nachricht zugeordnet ist.
  • Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Kommunikationssystem bereitgestellt, das einen ersten, in einer ersten Netzumgebung arbeitenden Host, einen zweiten, Host-Identiätsprotokoll- bzw. Host-Identity-Protocol-(HIP)-fähigen, in einer zweiten Netzumgebung betriebenen Host, eine Einrichtung zum Zuordnen eines Identifizierers zu dem ersten Host, eine Einrichtung zum Speichern des Identifizierers bei dem Gateway-Knoten, eine Einrichtung zum Senden des Identifizierers zu dem ersten Host, eine Einrichtung zum Verwenden des Identifizierers als eine Quellenadresse in einer nachfolgend von dem ersten Host zu dem Gateway-Knoten gesendeten Nachricht, und eine Angabe umfasst, dass das Ziel der Nachricht der zweite Host ist, und eine Einrichtung zur Verwendung des gespeicherten Identifizierers bei dem Gateway-Knoten zum Verhandeln einer sicheren HIP-Verbindung zu dem zweiten Host.
  • Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein Verfahren bereitgestellt für das Verwenden des Host-Identitätsprotokolls (HIP) durch einen Gateway-Knoten bei mindestens teilweise sicheren Kommunikationsvorgängen zwischen einem ersten in einer ersten Netzumgebung betriebenen Host und einem zweiten, in einer zweiten Netzumgebung betriebenen, HIP-fähigen Host, wobei der Gateway-Knoten einen Übergang zwischen den beiden Umgebungen bildet und das Verfahren umfasst: das Zuordnen eines Identifizierers zu dem ersten Host, das Speichern des Identifizierers bei dem Gateway-Knoten und das Senden des Identifizierers zum ersten Host; das Empfangen einer nachfolgenden von dem ersten Host zu dem Gateway-Knoten gesendeten Sitzungseinladungsnachricht, wobei die Nachricht den Identifizierer als Quellenadresse hat und auch eine Angabe enthält, dass das Ziel der Nachricht der zweite Host ist; und das Verwenden des gespeicherten Identifizierers bei dem Gateway-Knoten zum Verhandeln einer HIP-Verbindung zu dem zweiten Host.
  • Gemäß einem vierten Aspekt der vorliegenden Erfindung wird eine Vorrichtung bereitgestellt zur Verwendung als Gateway-Knoten zwischen einem ersten, in einer ersten Netzumgebung betriebenen Host und einem zweiten, Host-Identitätsprotoko11-(HIP-)fähigen Host, der in einer zweiten Netzumgebung betrieben wird, umfassend: eine Einrichtung zum Zuordnen eines ersten Identifizierers zu dem ersten Host, eine Einrichtung zum Speichern des Identifizierers bei dem Gateway-Knoten, eine Einrichtung zum Senden des Identifizierers zum ersten Host, eine Einrichtung zum Empfangen einer nachfolgenden, von dem ersten Host zu dem Gateway-Knoten gesendeten Sitzungsveranlassungsnachricht, welche Nachricht den Identifizierer als eine Quellenadresse hat und auch eine Angabe enthält, dass das Ziel der Nachricht der zweite Host ist, und eine Einrichtung zum Verwenden des gespeicherten Identifizierers bei dem Gateway-Knoten zum Verhandeln einer HIP-Verbindung zu dem zweiten Host.
  • Gemäß einem fünften Aspekt der vorliegenden Erfindung wird ein Computerprogramm bereitgestellt, das, wenn es auf einem Gateway-Knoten abläuft, den Gateway-Knoten veranlasst, ein Verfahren gemäß dem dritten Aspekt der vorliegenden Erfindung auszuführen.
  • Gemäß einem sechsten Aspekt der vorliegenden Erfindung wird ein Computerprogramm bereitgestellt, welches wenn in einem Gateway-Knoten geladen, den Gateway-Knoten veranlasst, alle Merkmale einer Vorrichtung gemäß dem vierten Aspekt der vorliegenden Erfindung zu verursachen.
  • Das Computerprogramm kann auf einem Trägermedium getragen werden. Das Trägermedium kann beispielsweise ein Übertragungsmedium oder ein Speichermedium sein.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Es zeigt:
  • 1 zuvor besprochenen, die verschiedenen Schichten des Host Identity Protocol bzw. Host-Identitätsprotokolls;
  • 2 ebenfalls zuvor besprochen, den Betrieb des Vierwege-Hand-Shake in dem HIP-Protokoll;
  • 3 ebenfalls zuvor besprochen, die logischen und tatsächlichen Paketstrukturen in HIP;
  • 4 ebenfalls zuvor besprochen, ein Weiterreichen zwischen IPv6 und IPv4;
  • 5 ebenfalls zuvor besprochen, ein schematisches Diagramm des Gesamtnetzes, das für Kommunikationen zwischen einem Alt-Host und einem HIP-Modus über einen HIP-Proxy verwendet wird;
  • 6 ein Blockdiagramm von Elementen einer GPRS-/UMTS-Netzarchitektur, zu der Ausführungsformen der vorliegenden Erfindung hinzugefügt sind;
  • 7 ein Signaldiagramm eines Beispiels einer PDP-Kontextaktivierungsprozedur;
  • 8 ein Signaldiagramm eines Verfahrens gemäß einer ersten Ausführungsform der vorliegenden Erfindung;
  • 9 Die Endbenutzer-Adresseninformation in einer Ausführungsform der vorliegenden Erfindung unter Verwendung einer 128-Bit-Darstellung für den Identifizierer;
  • 10 die Endbenutzer-Adresseninformation in einer Ausführungsform der vorliegenden Erfindung unter Verwendung einer 32-Bit-Darstellung für den Identifizierer;
  • 11 die Inhalte der HIP- und IP-Header für gewisse, in der ersten Ausführungsform gesendete Nachrichten;
  • 12 ein Signaldiagramm eines Verfahrens gemäß einer zweiten Ausführungsform der vorliegenden Erfindung; und
  • 13 die Inhalte der HIP- und IP-Header für gewisse in der zweiten Ausführungsform gesendete Nachrichten.
  • Ausführungsformen der vorliegenden Erfindung werden innerhalb des Gesamtzusammenhangs der in 6 gezeigten GPRS-/UMTS-Netzarchitektur beschrieben. Die einer Ausführungsform der vorliegenden Erfindung zugrundeliegenden Prinzipien sind in gleicher weise anwendbar auf UMTS wie auch auf GPRS.
  • Wie oben erwähnt, ist GPRS als eine Erweiterung der existierenden GSM-Netzinfrastruktur mit dem Ziel des Bereitstellens eines verbindungslosen Paketdatendienstes entworfen worden.
  • GPRS führt eine Anzahl neuer funktionaler Elemente über GSM ein, die den Ende-zu-Ende-Transport von IP-basierten Paketdaten unterstützen, wie nachstehend beschrieben wird.
  • Das in 6 gezeigte Kommunikationssystem 100 umfasst eine Mobilstation (MS) 102 in Kommunikation mit einer Basis-Senderempfängerstation (BTS) 104, die wiederum mit einem Basisstationscontroller (BSC) 106 kommuniziert. Die BTS 104 und der BSC 106 bilden gemeinsam das Basisstations-Sub-System (BSS). Bei dem BSC 106 unterscheidet eine Paketsteuereinheit (PCU, vom englischsprachigen Ausdruck "Packet Control Unit", nicht dargestellt) zwischen schaltungsvermittelten Daten, die für ein Telefonnetz 110 bestimmt sind und paketvermittelten Daten, die für ein Paketdatennetz 120 bestimmt sind. Das Telefonnetz 110 kann beispielsweise ein öffentliches Wählvermittlungstelefonnetz (PSTN) sein oder ein Digital-Integriertdienstenetz (ISDN), während das Paketdatennetz beispielsweise ein öffentliches Paketdatenvermittlungsnetz sein kann, das Internet oder ein Firmen-LAN.
  • Schaltungsvermittelte Daten werden zu dem Telefonnetz 110 über ein mobiles Vermittlungszentrum (MSC) geroutet, das ein Besucherortsregister (VLR bzw. "Visitor Location Register") beinhaltet. Andererseits werden paketvermittelte Daten zu dem Paketdatennetz 120 über einen bedienenden GPRS-Unterstützungsknoten (SGSN bzw. Serving GPRS Support Node) 112 und einen Gateway-GPRS-Unterstützungsknoten (GGSN bzw. Gateway-GPRS-Support Node) 114 geroutet. Die MSC 108, SGSN 112 und GGSN 114 haben Zugriff auf ein Heimatortsregister (HLR bzw. "Home Location Register") 116, das eine Teilnehmerinformation, beispielsweise Dienste, Kontozustandsinformation, bevorzugt Teilnehmern zugeordnete IP-Adressen enthaltende Datenbank ist. In 6 ist ein Domain-Namenssystemserver (DNS-Server bzw. Domain Name System Server) 118 gezeigt als ein Netz, auf das das Paketdatennetz 120 zugreifen kann. Auch ist ein Host 122 mit dem Paketdatennetz 120 verbunden gezeigt.
  • Zwei neue Hauptkernnetzelemente werden mit GPRS gegenüber dem Standard-GSM-Netz eingefügt: der SGSN 112 und der GGSN 114. Der SGSN 112 überwacht den Zustand der Mobilstation 102 und verfolgt ihre Bewegungen innerhalb eines gegebenen geographischen Bereichs. Er ist auch zuständig für das Einrichten und Organisieren der Datenverbindungen zwischen dem Mobilbenutzer und dem Zielnetz. Wenn der Benutzer sich in ein Segment des Netzes bewegt, das durch einen abweichenden SGSN organisiert bzw. gemanagt wird, wird er ein Handoff (Rufweitergabe) zu dem neuen SGSN vornehmen.
  • Der GGSN 114 stellt den Anbringungspunkt zwischen der GPRS-Netzumgebung und der externen Paketdatennetzumgebung 120 bereit wie z.B. das Internet oder Firmen-Intranetz. Jedes externe Netz 120 hat einen einzigartigen Zugangspunktnamen (APN bzw. Acess Point Name) verliehen, der durch den Mobilbenutzer zum Einrichten der Verbindung zu dem erforderlichen Zielnetz verwendet wird. Weitere Information kann aus der technischen Spezifikation für GPRS und UMTS gefunden werden, die von http://www.3gpp.org verfügbar sind.
  • Bevor die Mobilstation 102 imstande ist, GPRS-Dienste zu verwenden, muss sie sich bei dem SGSN 112 des GPRS-Netzes unter Verwendung der GPRS-Anbringungsprozedur (Attach-Prozedur) registrieren. Während der Anbringungsprozedur prüft das Netz, ob der Benutzer authorisiert ist, kopiert das Benutzerprofil aus dem HLR 116 zu dem SGSN 112 und weist dem Benutzer eine temporäre Paketmobilteilnehmeridentität (P-TMSI) zu. Wo die Mobilstation 102 bereits mit einem SGSN 112 verbunden war, wird eine Aktualisierungsortsnachricht zu dem geeigneten HLR 116 gesendet, welches einen Ortsaktualisierungsprozess in Hinblick auf den neuen SGSN 112 vornimmt. Detailliertere Information in Bezug auf die GPRS-Anbringungs- bzw. Attach-Prozedur kann im Abschnitt 6.5 der GPRS-Technischen Spezifikation 3GPP TS 23.060 V6.3.0 (2003- 12) gefunden werden. Die Trennung von dem GPRS-Netz wird GPRS-Detach genannt. Sie kann durch die Mobilstation oder durch das Netz (SGSN 112 oder HLR 116) veranlasst werden.
  • Auf das Abschließen der Attach-Prozedur hin, ist das Netz imstande, die MS 102 (über nachfolgende Ortsaktualisierung) nach zu verfolgen und ist sich der Dienste und Netze bewußt, auf die der Benutzer Zugriff hat. An dieser Stelle ist der Benutzer jedoch nicht imstande, Daten zu oder von dem Paketdatennetz 120 zu senden bzw. zu empfangen. Zum Austausch von Datenpaketen mit dem Paketdatennetz 120 nach einem erfolgreichen GPRS-Attach muss ein Paketdatenprotokollkontext (PDP- bzw. Packet Data Protocol-Kontext) zuerst aktiviert werden.
  • In einem GPRS-System des Standes der Technik ohne das HIP-Protokoll muss eine Mobilstation, um Datenpakete mit einem externen Paketdatennetz nach erfolgreichem GPRS-Attach auszutauschen, eine oder mehrere Adressen in dem Paketdatennetz erlangen bzw. eine IP-Adresse in dem Fall, in dem das Paketdatennetz ein IP-Netz ist. Diese Adresse wird PDP-Adresse genannt. Für jede Sitzung wird ein PDP-Kontext erstellt, welcher die Charakteristika der Sitzung beschreibt. Er enthält den PDP-Typ (beispielsweise IPv4), die der Mobilstation zugewiesene PDP-Adresse, die angeforderte Dienstequalität (QOS) und die Adresse eines GGSN 114, der als der Zugangspunkt zu dem Paketdatennetz dient. Dieser Kontext wird in der Mobilstation 102, dem SGSN 112 und dem GGSN 114 gespeichert. Mit einem aktiven PDP-Kontext ist die Mobilstation 102 für das externe Paketdatennetz 120 "sichtbar" und ist imstande, Datenpakete zu senden und zu empfangen. Die Abbildung zwischen den beiden Adressen PDP und IMSI (International Mobile System Identifier) befähigt den GGSN 114, Datenpakete zwischen dem Paketdatennetz 120 und der Mobilstation 102 zu übertragen.
  • 7 zeigt ein Beispiel einer solchen PDP-Kontext-Aktivierungsprozedur. Im Schritt S1 wird eine PDP-Kontext- Aktivierungsanforderung von der MS 102 zu dem SGSN 112 gesendet. Im Schritt S2 werden die üblichen Sicherheitsfunktionen (beispielsweise Authentifizierung des Benutzers) vorgenommen. Wenn Zugang gewährt wird, wird der SGSN 112 eine PDP-Kontext-Erstellungsanforderung zu dem betroffenen GGSN 114 senden (Schritt S3). Der GGSN 114 erstellt einen neuen Eintrag in seiner PDP-Kontexttabelle, welche den GGSN 114 befähigt, Datenpakete zwischen dem SGSN 112 und dem externen Paketdatennetz 120 zu routen. Der GGSN 114 gibt dann im Schritt S4 eine PDP-Kontexterstellungs-Antwort zu dem SGSN 112 zurück, welche die zugewiesene PDP-Adresse, beispielsweise eine IPv4-Adresse enthält. Der SGSN 114 aktualisiert seine PDP-Kontexttabelle und bestätigt die Aktivierung des neuen PDP-Kontexts der MS 102 mit einer PDP-Kontext-Aktivierungsakzeptierungsnachricht im Schritt 55. Die GPRS-PDP-Kontext-Aktivierungsprozedur wird im Abschnitt 9.2.2 der oben erwähnten Technischen Spezifikation zu GPRS detailliert beschrieben und der beschriebene Nachrichtenaustausch (Tunnel Management Messages" bzw. "Tunnelorganisierungsnachrichten" bezeichnet) wird detaillierter im Abschnitt 7.3 der Technischen Spezifikation zu UMTS/GPRS, ETSI TS 129.060 V5.8.0(2003-12), beschrieben.
  • In der vorliegenden Ausführungsform der vorliegenden Erfindung gilt die oben beschriebene PDP-Kontext-Aktivierungsprozedur noch, aber wird modifiziert zum Ermöglichen von Kommunikationen zwischen der Mobilstation 102 in der GPRS-Netzumgebung und dem Host 122 in der Paketdatennetzumgebung 120, um mindestens teilweise gesichert zu sein unter Verwendung von HIP. Wie oben beschrieben ist zum Bereitstellen von HIP-Unterstützung für Knoten innerhalb eines Netzes ein HIP-Proxy erforderlich, um zumindest teilweise die Vorteile von HIP für Altendgeräte bereitzustellen, die innerhalb der Netzumgebung arbeiten. In dem Kontext der GPRS-Netzumgebung ist in der vorliegenden Ausführungsform der HIP-Proxy als Teil des GGSN 114 vorgesehen. Daher ist in der vorliegenden Ausführungsform der GGSN 114 der 6 ein GGSN-HIP-Proxy 114.
  • Die vorliegende Ausführungsform wird nun detaillierter unter Bezugnahme auf die 8 beschrieben, in der der Host 122 der 6 ein HIP-fähiger Host 122 ist und die Mobilstation 102 eine Alt-Mobilstation (nicht HIP-fähig) 102 ist.
  • 8 ist ein Signaldiagramm zum Zeigen eines Verfahrens, das die vorliegende Erfindung des Verwendens des Host-Identitätsprotokolls zum mindestens teilweisen Sichern von Kommunikationen zwischen einem ersten Host (der Alt-MS 102), die in einer ersten Netzumgebung (der GPRS-Netzumgebung) betrieben wird, und einem zweiten Host (dem HIP-Host 122), der in einer zweiten Netzumgebung (der Paketdatenvermittlungsnetzumgebung) betrieben wird, umsetzt. Der GGSN-HIP-Proxy 114 bildet einen Übergang zwischen den beiden Netzumgebungen.
  • Im Schritt T1 veranlasst die Alt-MS 102 eine PDP-Kontext-Aktivierungsprozedur. In der PDP-Kontext-Aktivierungsprozedur gemäß dieser Ausführungsform der vorliegenden Erfindung erzeugt der GGSN-HIP-Proxy 114 ein Schlüsselpaar (HI und geheimer Schlüssel) und ordnet es der Alt-MS 102 zu, das Schlüsselpaar in dem GGSN-HIP-Proxy 114 speichernd. Basierend auf dem öffentlichen Schlüssel (HI) wird ein Identifizierer erzeugt und der Alt-MS 102 zugeordnet, und dann der Alt-MS 102 als die in dem PDP-Kontext zu verwendende Adresse zugesendet. Dies unterscheidet sich von einer konventionellen PDP-Kontext-Aktivierungsprozedur, die oben beschrieben worden ist, wo eine IP-Adresse gewöhnlich zu der Mobilstation 102 als die PDP-Adresse zurückgegeben wird.
  • In dem Fall, in dem IPv6 bei der Alt-MS 102 verwendet wird, ist der der Alt-MS 102 zugeordnete Identifizierer ein Host-Identifizierer-Etikett bzw. Host-Identifier Tag (HIT), das oben beschrieben worden ist, welches von derselben Länge ist wie eine IPv6-Adresse, und wird hier als HIPMS(GGSN) bezeichnet. In dem Fall, in dem IPv4 bei der Alt-MS 102 verwendet wird, ist der Identifizierer ein Lokalbereichs- Identifizierer bzw. Local-Scope-Identifier (LSI), der oben beschrieben worden ist, welcher von derselben Länge ist wie eine IPv4-Adresse, und wird hier als LSIMS(GGSN) bezeichnet. Im vorangehenden Fall (IPv6) ist die Endbenutzeradresse in der PDP-Kontexterstellungsantwort in 9 illustriert während im letzteren Fall (IPv4) die Endbenutzeradresse in 10 gezeigt ist.
  • Der Identifizierer wird unabhängig von der Form durch die Alt-MS 102 in der Endbenutzeradresse empfangen und die MS 102 speichert die Identifizierer zur Benutzung als die Quellenadresse in einer nachfolgenden Sitzungsveranlassungsnachricht, wie später zu beschreiben ist. Es ist demnach wichtig, dass die Länge des Identifizierers identisch ist mit dem Quellenadressenfeld des durch die Alt-MS 102 verwendeten Adressierschemas.
  • Wenn die Alt-MS 102 nachfolgend wünscht, eine Verbindung mit dem HIP-Host 1022 einzurichten, wie durch Schritt T2 der 8 angegeben, sendet sie eine DNS-Abfrage zum Einholender IP-Adresse des HIP-Host 122. Die DNS-Abfrage wandert über den GGSN-HIP-Proxy 114 zu dem DNS-Server 118. Der DNS-Server 118 gibt die IP-Adresse des HIP-Host 122, IPHH, sowie das HIT für den HIP-Host 122, HITHH zurück, und diese Information wird bei dem GGSN-HIP-Proxy 114 gespeichert. HITHH wird zu der Alt-MS 102 gesendet und wird in einer nachfolgenden Sitzungsveranlassungsnachricht, die später zu beschreiben ist, als eine Zielangabe verwendet. Die Zielangabe wird in das Zieladressenfeld der Sitzungsveranlassungsnachricht eingefügt und daher ist es wichtig, dass die Zielangabe von derselben Länge ist wie das Zieladressenfeld der Sitzungsveranlassungsnachricht. Wenn die Alt-MS 102 nur IPv4-fähig ist, muss die Zielangabe, die zu der Alt-MS 102 zu senden ist als Reaktion auf ihre DNS-Abfrage daher von derselben Länge sein wie eine IPv4-Adresse. Der GGSN-HIP-Proxy 114 muss demnach eine LSI oder eine IPv4-Adresse oder irgendeine andere 32-Bit-Darstellung für den HIP-Host 122, die einzigartig ist innerhalb der Mobilnetzumgebung, zuweisen. Adressenübersetzung ist darauffolgend erforderlich bei dem GGSN-HIP-Proxy 114, welche durch den Fachmann leicht zu erzielen ist.
  • Im Schritt T3 wird eine Sitzungsveranlassungsnachricht von der Alt-MS 102 zu dem GGSN-HIP-Proxy 114 gesendet mit dem Quellenfeld im IP-Header auf den HITMS(GGSN) -Identifizierer eingestellt und dem Zielfeld eingestellt auf HITHH, wie in 11 angegeben. In dem Fall von IPv4-Adressierung wird die Zieladresse zu dem LSI des HIP-Host 122, LSIHH, festgelegt (oder die dem HIP-Host 122 zugeordnete LSI, wo IPv6-zu-IPv4-Übersetzung betrieben wird).
  • Auf den Empfang der Sitzungsveranlassungsnachricht hin bemerkt der GGSN-HIP-Proxy 114, dass er HIT (oder LSI) gespeichert hat, das/der mit dem Ziel-HIT (oder LSI) des empfangenen Pakets übereinstimmt, nachfolgend auf die oben im Schritt T2 beschriebene DNS-Abfrage. Daher weist der GGSN-HIP-Proxy 114, dass der betreffende Zielknoten HIP-fähig ist und dass Kommunikationen zwischen der Alt-MS 102 und dem HIP-Host 122 unter Verwendung des Host-Identitätsprotokolls zumindest teilweise gesichert sein können. In diesem Beispiel kann der GGSN-HIP-Proxy 114 keine Sicherheitszuordnung (Security Association) für eine Verbindung zwischen ihm und dem HIP-Host 122 finden, so dass er nachfolgend das oben unter Bezugnahme auf 2 beschriebene HIP-4-Wege-Hand-Shake zum Bilden einer "Security Association" zwischen dem GGSN-HIP-Proxy 114 und dem HIP-Host 122 durchführt. Das HIP-Hand-Shake ist in 8 bei Schritt T4 gezeigt.
  • Die I1- und R1-Paket-Header für das 4-Wege-HIP-Hand-Shake sind in 11 gezeigt. In dem HIP-Header für die I1- und R1-Pakete wird das Initiator-Feld auf HITMS(GGSN) eingestellt und das Beantworterfeld wird eingestellt auf HITHH. In dem IP-Header wird IPGGSN in dem Quellenfeld des I1-Pakets verwendet und dem Zielfeld des R1-Pakets, während IPHH in dem Zielfeld des I1-Pakets und in dem Quellenfeld des R1-Pakets verwendet wird.
  • Wenn die Sicherheitszuordnung (Security Association) zwischen dem GGSN-HIP-Proxy 114 und dem HIP-Host 122 eingerichtet worden ist, sendet im Schritt T5 der GGSN-HIP-Proxy 114 die Sitzungsveranlassungsnachricht (die von der Alt-MS 102 im Schritt T3 empfangen worden ist) zu dem HIP-Host 122 unter Verwendung der Sicherheitszuordnung. Im Schritt T6 wird eine Sitzungsveranlassungsbestätigung zu der Alt-MS 102 zurückgegeben.
  • Nachfolgende Kommunikationen zwischen der Alt-MS 102 und dem HIP-Host 122 können nun fortgesetzt werden mit Kommunikationen zwischen dem GGSN-HIP-Proxy 114 und dem HIP-Host 122 durch die HIP-Sicherheitszuordnung geschützt. Wenn der GGSN-HIP-Proxy 114 ein Paket von dem HIP-Host 122 empfängt, verarbeitet er es und sendet die Daten als reguläres IP-Paket zu der Alt-MS 102 basierend auf dem Ziel-HIT des Pakets, welches dasselbe ist wie das der Alt-MS 105 im Schritt T1 zugeordnete.
  • Wie oben beschrieben, werden während der HIP-Verhandlung zum Einrichten der Sicherheitszuordnung zwischen dem GGSN-HIP-Proxy 114 und dem HIP-Host 122 und während nachfolgender Kommunikationen zwischen der Alt-MS 102 und dem HIP-Host 122 über den GGSN-HIP-Proxy 114 das HITMS(GGSN) und das für die Alt-MS 102 erzeugte Schlüsselpaar verwendet statt dem HIT und dem Schlüsselpaar des GGSN-HIP-Proxy 114 selbst. Dies ist derart, dass eine separate Sicherheitszuordnung (oder ein Paar von Sicherheitszuordnungen) für jede mit dem HIP-Host 122 kommunizierende Alt-MS 102 erzeugt wird. Wenn das HIT und das Schlüsselpaar des GGSN-HIP-Proxy 114 verwendet würden und mehrere Mobilstationen mit demselben Host 122 kommunizieren würden würde die Kommunikation zwischen dem GGSN-HIP-Proxy 114 und dem HIP-Host 122 dieselbe Sicherheitszuordnung verwenden und es gäbe keinerlei Information, die verwendet werden könnte bei dem GGSN-HIP-Proxy 114 zum Separieren der Verbindungen zwischen unterschiedlichen Mobilstationen; alle kommenden Pakete von dem Peer würden dieselbe Ziel-IP- und SPI enthalten. Wenn es jedoch nur eine MS gäbe, die mit einem speziellen HIP-Host 122 redet, würde es möglich sein, das HIT und das Schlüsselpaar des GGSN-HIP-Proxy 114 zu verwenden.
  • In der oben beschriebenen Ausführungsform ist die Mobilstation 102 nicht HIP-fähig. Eine zweite Ausführungsform der vorliegenden Erfindung wird nun beschrieben, in der die Mobilstation 102 eine HIP-fähige Mobilstation 102 ist.
  • 12 ist ein Signaldiagramm zum Erläutern des Betriebs der zweiten Ausführungsform. Schritte T1 und T2 werden in einer Weise in Entsprechung zu den jeweiligen Schritten T1 und T2 der ersten Ausführungsform ausgeführt und daher wird eine weitere Beschreibung hier nicht eingeschlossen. Auf den Empfang des HIT von dem HIP-Host 122 bei der HIP-MS 102 hin, nämlich HITHH, erkennt die HIP-MS 102, dass der HIP-Host 122 HIP-fähig ist. Anders, als in der ersten Ausführungsform, kann in der zweiten Ausführungsform die HIP-Verhandlung, da sowohl die MS 102 als auch der Host 122 HIP-fähig sind, direkt zwischen der MS 102 und dem Host 122 ausgeführt werden. Der GGSN-HIP-Proxy 114 nimmt nicht an der eigentlichen HIP-Verhandlung teil sondern wird stattdessen Information über die HITs, IP-Adressen und SPIs erfassen. Im Schritt P3 wird der HIP-Hand-Shake durch das Senden von einem I1-Pakete von der HIP-MS 102 zu dem HIP-Host 122 über den GGSN-HIP-Proxy 114 veranlasst. In der zweiten Ausführungsform ist das I1-Pakete äquivalent anzusehen mit der Sitzungsveranlassungsnachricht der ersten Ausführungsform, die von der Alt-MS 102 zu dem GGSN-HIP-Proxy 114 im Schritt T3 gesendet worden ist.
  • Die HIP- und IP-Header des I1-Pakets, das von der HIP-MS 102 gesendet worden ist, werden in 13 oben gezeigt. Während der HIP-Verhandlung wird das Initiator-Feld des HIP-Headers auf das HIT der HIP-MS 102 (HITMS) eingestellt und nicht auf das durch den GGSN-HIP-Proxy 114 zugewiesene HIT (HITMS(GGSN)) Dies ist der Fall, weil in der zweiten Ausführungsform die HIP-fähige MS 102 selbst für die HIP-Verhandlungen und die Sicherheitszuordnungen zwischen ihr und dem HIP-Host 122 zuständig sein muss. Das durch den GGSN-HIP-Proxy 114 zugewiesene HITMS(GGSN)) kann nicht in Kommunikationen zwischen der HIP-MS 102 und dem HIP-Host 122 verwendet werden, weil die MS 102 keinen entsprechenden privaten Schlüssel hat und demnach keine Pakete unter Verwendung von HITMS(GGSN) signieren kann. Während der HIP-Verhandlungen im Schritt P3 ist das Beantworter-Feld des HIP-Headers auf das HIT des HIP-Hosts 122 (HITHH) eingestellt.
  • In dem I1-Paket, das von dem GGSN-HIP-Proxy 114 empfangen wird, wird das Quellenfeld des IP-Headers auf den Identifizierer eingestellt, der zuvor durch den GGSN-HIP-Proxy 114 zugewiesen worden ist, nämlich HITMS(GGSN), und das Zielfeld wird auf HITHH eingestellt, das der HIP-MS 102 nachfolgend auf die DNS-Abfrage im Schritt P2 gemeldet worden ist. Von dem I1-Paket kann der GGSN-HIP-Proxy 114 aus dem Quellenfeld des IP-Headers, der den Identifizierer HITMS(GGSN) enthält) bestimmen, welches Endgerät dieses Paket gesendet hat. Der GGSN-HIP-Proxy 114 nimmt eine geeignete Adressenübersetzung vor zum Ersetzen der Quellen-IP-Adresse durch die global routbare IP-Adresse des GGSN, IPGGSN, und ersetzt die Ziel-IP-Adresse durch die IP-Adresse des HIP-Hosts 122, IPHH. Abhängig von der Zieladresse wird das Paket zu dem HIP-Host 122 entweder direkt oder über einen Weiterleitungs-Agent des HIP-Hosts 122 geroutet.
  • Der HIP-Host 122 antwortet mit einem R1-Paket mit HIP- und IP-Headern, wie in 13 gezeigt. Die Header des R1-Pakets sind dieselben wie jene des I1-Pakets, das bei dem HIP-Host 122 empfangen worden ist, mit der Ausnahme, dass die Quellen- und Ziel-IP-Felder umgekehrt sind.
  • Wenn der GGSN-HIP-Proxy 114 das R1-Paket empfängt, verifiziert er den korrekten Empfänger unter Verwendung von HITMS in dem HIP-Header und spürt die korrekte Zieladresse auf, die Ziel-IP-Adresse, wie in 13 unten gezeigt, durch HITMS(GGSN) ersetzend.
  • Das I2-Paket enthält ähnliche Header-Information wie das I1-Paket. Das I2-Paket enthält auch den durch die HIP-MS 102 ausgewählten SPI-Wert. Der SPI-Wert wird bei dem GGSN-HIP-Proxy 114 gespeichert, hierdurch einen Verbindungseingang {HITMS(GGSN)), SPIHH→MS; HITHH} bildend. Diese Information ist erforderlich zum Liefern des kommenden Datenverkehrs zu der korrekten MS.
  • Von dem R2-Paket kann der GGSN-HIP-Proxy 114 den SPI-Wert lernen, den die MS verwenden wird in Richtung des HIP-Host 122, aber diese Information ist nicht erforderlich während der Kommunikation. Der SPI-Wert muss innerhalb des 3G-Netzes einzigartig sein. Demnach könnte der GGSN-HIP-Proxy 114 SPI-Übersetzung durchführen, wenn die I2/R2-Pakete über ihn gehen. Demnach würden die End-Hosts unterschiedliche SPI haben, die sie verwenden. Die HIP-MS 102 sendet den SPI zu dem HIP-Host 122 zur Verwendung in Paketen von dem HIP-Host 122 in Richtung der HIP-MS 102. Der GGSN-HIP-Proxy 114 erzeugt einen einzigartigen SPI, der nicht mit irgendeinem anderen SPI, die in Richtung des 3G-Netzes verwendet werden, überlappt und ersetzt ihn in dem Paket. Demnach führt der GGSN-HIP-Proxy 114 SPI-Abbildung durch, wenn Pakete fließen. In dem HIP bedeutet dies, dass der GGSN-HIP-Proxy 114 fähig sein muss, den SPI-Wert in I2- und R2-Paketen zu ändern. Derzeit gehört der SPI-Wert zu dem Bereich, der durch den Sender signiert ist, und daher würde ein Ändern des Wertes die Signatur zerstören. Eine Option würde sein, den SPI-Wert außerhalb der Signatur in I2- und R2-Paketen anzuordnen. Dies kann in zukünftigen HIP-Spezifikationen geändert werden. Der GGSN-HIP-Proxy 114 könnte einen Bereich von SPIs, die die HIP-MS 102 verwenden würde, zuordnen. Daher würden die SPI-Werte, die eine HIP-MS 102 verwenden könnte, durch den GGSN-HIP-Proxy 114 gesteuert würden, nicht überlappend auftreten. Dies würde das Einfügen eines Feldes in der Kontext-Aktivierungsprozedur erfordern, das die zulässigen SPIs enthält, die die HIP-MS 102 verwenden kann.
  • In der oben beschriebenen zweiten Ausführungsform wird Bezug genommen auf die Verwendung von HITS statt LSIs. Es wird trotzdem verstanden werden, dass jene beiden Darstellungen im Wesentlichen äquivalent sind und dass die LSI-Darstellung, wenn angemessen, verwendet werden kann.
  • Die obige Beschreibung der PDP-Kontext-Aktivierungsprozedur für die zweite Ausführungsform baut auf die in der ersten Ausführungsform beschriebene äquivalente Prozedur, in welcher der GGSN-HIP-Proxy 114 einen HIT- oder LSI-Identifizierer erzeugt, der der MS 102 zugeordnet ist, den Identifizierer in dem GGSN-HIP-Proxy 114 speichernd. Es wird verstanden werden, dass es in der zweiten Ausführungsform nicht erforderlich ist für das Einrichten von Kommunikationen zwischen der MS 102 und dem HIP-Host 122, dass der Identifizierer tatsächlich bei dem GGSN-HIP-Proxy 114 gespeichert wird. Beispielsweise Bezug nehmend auf 13 ist der Identifizierer HITMS(GGSN) als Quellen-IP-Feld des zu dem GGSN-HIP-Proxy 114 gesendeten I1-Pakets eingeschlossen und wird durch IPGGSN für das I1-Paket ersetzt, das zu dem HIP-Host 122 weitergeleitet wird; es gibt keinen Bedarf, das HITMS(GGSN), das in dem I1-Paket empfangen wird, auf irgendeinen bei dem GGSN-HIP-Proxy 114 gespeicherten Identifizierer abzubilden, um diese Ersetzungsoperation durchzuführen. Demnach wird der Identifizierer dem ersten Host zugeordnet und zu dem ersten Host gesendet und nachfolgend als eine Quellenadresse in einer Sitzungsveranlassungsnachricht, die von dem ersten Host zu dem Gateway-Knoten gesendet wird, verwendet, mit dem bei dem Gateway-Knoten in der Veranlassungsnachricht empfangenen Identifizierer zum Verhandeln einer sicheren HIP-Verbindung zu dem zweiten Host verwendet. In der ersten Ausführungsform ist es erforderlich, dass der Identifizierer gespeichert wird, so dass das zugeordnete Schlüsselpaar für die nachfolgende HIP-Verhandlung aufgespürt werden kann. Jedoch ist es in beiden Ausführungsformen nicht erforderlich, dass der Identifizierer bei dem GGSN-HIP-Proxy 114 selbst gespeichert wird, sondern er kann in einem Server oder einem anderen derartigen Speicher gespeichert werden, der in Kommunikation steht mit dem GGSN-HIP-Proxy 114. Es ist auch nicht erforderlich, dass der Identifizierer bei dem GGSN-HIP-Proxy 114 selbst erzeugt wird, da er entfernt von dem GGSN-HIP-Proxy 114 erzeugt werden kann und von dort geholt werden kann.
  • In den ersten und zweiten oben beschriebenen Ausführungsformen wurde nachfolgend auf die DNS-Abfrage im Schritt T2/P2 das HIPHH des HIP-Hosts 122 zu der MS 102 als Teil der DNS-Antwort zurückgegeben. Nachfolgend wurde HITHH als Ziel-IP-Adresse in der Sitzungsveranlassungsnachricht verwendet mit einer geeigneten Übersetzung von HITHH in IPHH bei dem GGSN-HIP-Proxy 114, bevor das I1-Paket zu dem HIP-Host 122 gesendet wurde. Es wird verstanden werden, dass die tatsächliche IP-Adresse, IPHH, auch zu dem MS 102 als Teil der DNS-Antwort zurückgegeben werden könnte, so dass IPHH direkt in dem Ziel-IP-Adressenfeld der Sitzungsveranlassungsnachricht verwendet werden könnte. In diesem Fall würde der GGSN-HIP-Proxy 114 bestimmen müssen, dass der Host 122 tatsächlich in gewisser Weise HIP-fähig ist, beispielsweise durch Bezugnahme auf die lokal gespeicherte Zuordnung zwischen HITHH und IPHH.
  • In der oben beschriebenen zweiten Ausführungsform wird eingesehen werden, dass die I1-Paketheaderübersetzung, die bei dem GGSN-HIP-Proxy 114 gebildet wird, in einem I1-Paket resultiert, das keinerlei HITMS(GGSN) enthält. Daher ist in der zweiten Ausführungsform das dem durch den GGSN-HIP-Proxy 114 erzeugten und der HIP-MS 102 zugeordneten Identifizierer zugrundeliegende Format nicht wichtig ist, da der Identifizierer bloß zum Identifizieren der HIP-MS 102 dient. Irgendeine Art von 128-Bit-Identifizierer könnte daher verwendet werden, wobei die Adressenabbildung in ähnlicher Weise ausgeführt würde. Es wird auch eingesehen werden, dass der GGSN-HIP-Proxy 114 nicht tatsächlich ein Schlüsselpaar erzeugen muss, um die HIP-MS 102 in der zweiten Ausführungsform zu repräsentieren, da HIT-ähnliche Bitmuster als ein Identifizierer genügen. In der ersten Ausführungsform wird der Identifizierer HITMS(GGSN) während der HIP-Verhandlung verwendet und muss demnach in der korrekten Form und mit einem zugeordneten Schlüsselpaar vorliegen. Jedoch muss selbst in der ersten Ausführungsform der Identifizierer HITMS(GGSN) nicht selbst zu der Alt-MS 102 gesendet werden; alles was nötig ist, ist dass irgendeine Art von Identifizierer, der in Bezug zu dem HITMS(GGSN) steht, zu der Alt-MS 102 gesendet wird und nachfolgend als Quellen-IP-Adresse in der Sitzungsveranlassungsnachricht verwendet wird. Dieser Identifizierer könnte dann bei dem GGSN-HIP-Proxy 114 mit HITMS(GGSN) verknüpft werden zur Verwendung in nachfolgender HIP-Verhandlung.
  • Es wird eingesehen werden, dass der Betrieb von einem oder mehreren von der MS 102, dem GGSN-HIP-Proxy 114 und dem HIP-Host 122 durch ein Programm gesteuert werden kann, das auf der Einrichtung abläuft. Ein solches Computerprogramm kann in einem computerlesbaren Medium gespeichert werden oder könnte beispielsweise in einem Signal verkörpert werden z.B. ein herunterladbares Datensignal, das von einer Internet-Webseite bereitgestellt wird. Die beiliegenden Ansprüche sind interpretierend als ein betriebenes Programm selbst oder eine Aufzeichnung auf einem Träger oder ein Signal oder irgendeine andere Form davon.
  • Ein Fachmann wird einsehen, dass Ausführungsformen der vorliegenden Erfindung nicht notwendigerweise auf irgendein spezielles Protokoll oder Adressierschema für die jeweiligen Schichten beschränkt ist, beispielsweise in der Transport- oder Netzwerkschicht, und funktionieren wird innerhalb des HIP-Systems unabhängig davon, welches Adressierungs- oder Transportprotokoll um dieses System herum verwendet wird.

Claims (30)

  1. Verfahren des Verwendens eines Host-Identitätsprotokoll bzw. Host-Identity-Protocol, HIP, zum zumindest teilweisen Sichern von Kommunikationsvorgängen zwischen einem ersten in einer ersten Netzumgebung betriebenen Host (102) und einem zweiten in einer zweiten Netzumgebung betriebenen HIP-fähigen Host (122), mit einem einen Übergang zwischen den beiden Umgebungen bildenden Gateway-Knoten (114), wobei das Verfahren umfasst: Zuordnen eines Identifizierers zu dem ersten Host, Speichern des Identifizierers bei dem Gateway-Knoten, und Senden des Identifizierers zum ersten Host; Verwenden des Identifizierers als Quellenadresse in einer nachfolgend von dem ersten Host zu dem Gateway-Knoten gesendeten Sitzungsveranlassungsnachricht, die eine Angabe hat, dass das Ziel der Nachricht der zweite Host ist; und Verwenden des gespeicherten Identifizierers bei dem Gateway-Knoten zum Verhandeln einer HIP-Verbindung zu dem zweiten Host.
  2. Verfahren nach Anspruch 1, wobei der Identifizierer bei dem Gateway-Knoten erzeugt wird.
  3. Verfahren nach Anspruch 2, wobei der Identifizierer ansprechend auf das Senden einer Kontext-Aktivierungsanfrage von dem ersten Host zum Gateway-Knoten erzeugt wird.
  4. Verfahren nach Anspruch 3, wobei die Kontext-Aktivierungsanfrage eine Paketdatenprotokoll- bzw. Packet-Data-Protocol-, PDP-Kontext-Aktivierungsanfrage ist zum Aktivieren eines PDP-Kontexts, und der Identifizierer als PDP-Adresse in dem PDP-Kontext verwendet wird.
  5. Verfahren nach einem der vorhergehenden Ansprüche, wobei der erste Host ein Nicht-HIP-fähiger ist und die sichere HIP-Verbindung zwischen dem Gateway-Knoten und dem zweiten Host verhandelt wird.
  6. Verfahren nach einem der Ansprüche 1 bis 4, wobei der erste Host HIP-fähig ist und die sichere HIP-Verbindung zwischen den ersten und zweiten Hosts verhandelt wird.
  7. Verfahren nach einem der vorherigen Ansprüche, wobei der Identifizierer von derselben Länge ist wie eine Adresse in dem Adressschema, das durch den ersten Host zur Kommunikation mit dem Gateway-Knoten verwendet wird.
  8. Verfahren nach Anspruch 7, wobei ein IP-Adressierungsschema verwendet wird und der Identifizierer als Quellen-IP-Adresse in der Sitzungsveranlassungsnachricht verwendet wird.
  9. Verfahren nach einem der vorangehenden Ansprüche, wobei der Identifizierer ein Nachschau-Identifizierer ist, der einem für den ersten Host erzeugten und diesem zugeordneten HIP-Identitäts-Etikett zugeordnet wird, für das HIP-Identitäts-Etikett für den Host ermöglichend, bei dem Gateway-Knoten unter Verwendung des Nachschau-Identifizierers aufgespürt zu werden.
  10. Verfahren nach einem der Ansprüche 1 bis 8, wobei der Identifizierer ein HIP-Identitäts-Etikett ist.
  11. Verfahren nach Anspruch 9 oder 10, wenn abhängig von Anspruch 5, wobei das HIP-Identitäts-Etikett während der Verhandlung der HIP-Verbindung zwischen dem Gateway-Knoten und dem zweiten Host in einem HIP-Header eingeschlossen ist.
  12. Verfahren nach Anspruch 9, 10 oder 11, wobei das HIP-Identitäts-Etikett ein Host-Identitäts-Etikett bzw. Host-Identity-Tag, HIT, ist oder ein Lokalbereichs-Identifizierer bzw. Local-Scope-Identifier, LSI.
  13. Verfahren nach einem der Ansprüche 9 bis 12, wobei das HIP-Identitäts-Etikett aus einem Schlüsselpaar erzeugt wird.
  14. Verfahren nach Anspruch 13, wenn von Anspruch 5 abhängig, wobei das in dem Gateway-Knoten gespeicherte Schlüsselpaar zur Verwendung während nachfolgender HIP-Kommunikationsvorgänge zwischen dem Gateway-Knoten und dem zweiten Host vorgesehen ist.
  15. Verfahren nach einem der Ansprüche 1 bis 9, wobei der Identifizierer die Form einer IP-Adresse hat.
  16. Verfahren nach einem der vorhergehenden Ansprüche, wobei die erste Netzumgebung eine Mobilnetzumgebung ist.
  17. Verfahren nach Anspruch 16, wobei die Mobilnetzumgebung eine 3G-Mobilumgebung bzw. eine Mobilnetzumgebung der dritten Generation ist.
  18. Verfahren nach Anspruch 17, wobei die Mobilnetzumgebung eine UMTS-Mobilnetzumgebung ist.
  19. Verfahren nach einem der vorhergehenden Ansprüche, wobei die zweite Netzumgebung eine Internet-Netzumgebung ist.
  20. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Gateway-Knoten die Funktionalität eines HIP-Proxy bereitstellt.
  21. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Gateway-Knoten ein Gateway-GPRS-Unterstützungsknoten bzw. Gateway-GPRS-Support-Node, GGSN, ist.
  22. Verfahren nach einem der vorhergehenden Ansprüche, das Ersetzen des Identifizierers durch eine dem Gateway-Knoten zugeordnete Adresse als Quellenadresse in einer nachfolgenden zu dem zweiten Host gesendeten Nachricht umfassend.
  23. Kommunikationssystem, einen ersten, in einer ersten Netzumgebung arbeitenden Host (102), einen zweiten, Host-Identitätsprotokoll- bzw. Host-Identity-Protocol-, HIP-fähigen, in einer zweiten Netzumgebung betriebenen Host (122) umfassend, einen ein Gateway zwischen den beiden Umgebungen bildenden Gateway-Knoten (114) umfassend, eine Einrichtung zum Zuordnen eines Identifizierers zu dem ersten Host, eine Einrichtung zum Speichern des Identifizierers bei dem Gateway-Knoten, eine Einrichtung zum Senden des Identifizierers zu dem ersten Host, eine Einrichtung zum Verwenden des Identifizierers als eine Quellenadresse in einer nachfolgend von dem erste Host zu dem Gateway-Knoten gesendeten Nachricht und mit einer Angabe, dass das Ziel der Nachricht der zweite Host ist, habenden Sitzungseinladungsnachricht, und eine Einrichtung zum Verwenden des gespeicherten Identifizierers bei dem Gateway-Knoten zum Verhandeln einer HIP-Verbindung zu dem zweiten Host.
  24. Verfahren zur Verwendung des Verwendens des Host-Identitäts-Protokolls bzw. Host-Identity-Protocol, HIP, durch einen Gateway-Knoten (114) bei mindestens teilweise sicheren Kommunikationsvorgängen zwischen einem ersten in einer ersten Netzumgebung betriebenen Host und einem zweiten, in einer zweiten Netzumgebung betriebenen, HIP-fähigen Host, wobei der Gateway-Knoten einen Übergang zwischen den beiden Umgebungen bildet, wobei das Verfahren umfasst: Zuordnen eines Identifizierers zu dem ersten Host, Speichern des Identifizierers bei dem Gateway-Knoten, und Senden des Identifizierers zum ersten Host; Empfangen einer nachfolgenden von dem ersten Host zu dem Gateway-Knoten gesendeten Sitzungseinladungsnachricht, wobei die Nachricht den Identifizierer als Quellenadresse hat und auch eine Angabe hat, dass das Ziel der Nachricht der zweite Host ist; und Verwenden des gespeicherten Identifizierers bei dem Gateway-Knoten zum Verhandeln einer HIP-Verbindung zu dem zweiten Host.
  25. Vorrichtung zur Verwendung als Gateway-Knoten (114) zwischen einem ersten, in einer ersten Netzumgebung betriebenen Host (102) und einem zweiten, Host-Identitätsprotokoll- bzw. Host-Identity-Protocol-, HIP-fähigen Host (122), der in einer zweiten Netzumgebung betrieben wird, umfassend: eine Einrichtung zum Zuordnen eines ersten Identifizierers zu dem ersten Host, eine Einrichtung zum Speichern des Identifizierers bei dem Gateway-Knoten, eine Einrichtung zum Senden des Identifizierers zum ersten Host, eine Einrichtung zum Empfangen einer nachfolgenden, von dem ersten Host zu dem Gateway-Knoten gesendeten Sitzungsveranlassungsnachricht, wobei die Nachricht den Identifizierer als eine Quellenadresse hat und auch eine Angabe hat, dass das Ziel der Nachricht der zweite Host ist, und eine Einrichtung zum Verwenden des gespeicherten Identifizierers bei dem Gateway-Knoten zum Verhandeln einer HIP-Verbindung zu dem zweiten Host.
  26. Ein Computerprogramm, welches, wenn es auf einem Gateway-Knoten läuft, den Gateway-Knoten veranlasst, ein Verfahren, wie es in Anspruch 24 beansprucht ist, auszuführen.
  27. Ein Computerprogramm, welches, wenn es in einen Gateway-Knoten geladen wird, den Gateway-Knoten veranlasst, alle Merkmale einer Vorrichtung, wie sie in Anspruch 25 beansprucht ist, einzubeziehen.
  28. Computerprogramm nach Anspruch 26 oder 27, auf einem Trägermedium getragen.
  29. Computerprogramm nach Anspruch 28, wobei das Trägermedium ein Übertragungsmedium ist.
  30. Computerprogramm nach Anspruch 28, wobei das Trägermedium ein Speichermedium ist.
DE602004007303T 2004-04-15 2004-04-15 Identifizierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten Expired - Lifetime DE602004007303T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2004/050533 WO2005101753A1 (en) 2004-04-15 2004-04-15 Identification method and apparatus for establishing host identity protocol (hip) connections between legacy and hip nodes

Publications (2)

Publication Number Publication Date
DE602004007303D1 DE602004007303D1 (de) 2007-08-09
DE602004007303T2 true DE602004007303T2 (de) 2008-03-13

Family

ID=34957366

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004007303T Expired - Lifetime DE602004007303T2 (de) 2004-04-15 2004-04-15 Identifizierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten

Country Status (8)

Country Link
US (1) US7873825B2 (de)
EP (1) EP1735963B1 (de)
CN (1) CN1939000B (de)
AT (1) ATE366018T1 (de)
CA (1) CA2559076A1 (de)
DE (1) DE602004007303T2 (de)
PL (1) PL1735963T3 (de)
WO (1) WO2005101753A1 (de)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8316438B1 (en) 2004-08-10 2012-11-20 Pure Networks Llc Network management providing network health information and lockdown security
US7925729B2 (en) 2004-12-07 2011-04-12 Cisco Technology, Inc. Network management
US7904712B2 (en) * 2004-08-10 2011-03-08 Cisco Technology, Inc. Service licensing and maintenance for networks
US8478849B2 (en) 2004-12-07 2013-07-02 Pure Networks LLC. Network administration tool
US7827252B2 (en) 2004-12-07 2010-11-02 Cisco Technology, Inc. Network device management
GB2426672B (en) * 2005-05-27 2009-12-16 Ericsson Telefon Ab L M Host identity protocol method and apparatus
EP1880525B1 (de) * 2005-06-17 2009-06-03 Telefonaktiebolaget LM Ericsson (publ) Verfahren und vorrichtung für das host-identitäts-protokoll
GB2442044B8 (en) * 2006-05-11 2011-02-23 Ericsson Telefon Ab L M Addressing and routing mechanism for web server clusters.
WO2008151672A1 (en) 2007-06-14 2008-12-18 Telefonaktiebolaget Lm Ericsson (Publ) Network-based local mobility management
CN101335747B (zh) * 2007-07-01 2012-10-03 华为技术有限公司 通信地址通知、探索及通信检测、恢复方法及其装置
US7853829B2 (en) * 2007-07-13 2010-12-14 Cisco Technology, Inc. Network advisor
US8700743B2 (en) * 2007-07-13 2014-04-15 Pure Networks Llc Network configuration device
US8014356B2 (en) * 2007-07-13 2011-09-06 Cisco Technology, Inc. Optimal-channel selection in a wireless network
US9491077B2 (en) 2007-07-13 2016-11-08 Cisco Technology, Inc. Network metric reporting system
US9026639B2 (en) 2007-07-13 2015-05-05 Pure Networks Llc Home network optimizing system
CN101350807B (zh) 2007-07-20 2012-04-04 华为技术有限公司 多地址空间移动网络架构、主机信息注册及数据发送方法
WO2009049663A1 (en) * 2007-10-15 2009-04-23 Telefonaktiebolaget Lm Ericsson (Publ) Provisioning mobility services to legacy terminals
WO2010088957A1 (en) * 2009-02-05 2010-08-12 Telefonaktiebolaget Lm Ericsson (Publ) Host identity protocol server address configuration
CN101827011B (zh) * 2009-03-04 2013-03-27 华为技术有限公司 一种主机通信的方法、***和设备
US8724515B2 (en) 2010-03-26 2014-05-13 Cisco Technology, Inc. Configuring a secure network
US8649297B2 (en) 2010-03-26 2014-02-11 Cisco Technology, Inc. System and method for simplifying secure network setup
CN102223353A (zh) * 2010-04-14 2011-10-19 华为技术有限公司 主机标识协议安全通道复用方法及装置
US10200325B2 (en) * 2010-04-30 2019-02-05 Shazzle Llc System and method of delivering confidential electronic files
CN102377829B (zh) * 2010-08-09 2015-11-25 中兴通讯股份有限公司 基于hip的通信方法、***及设备
CN102413098B (zh) * 2010-09-20 2016-07-06 中兴通讯股份有限公司 一种基于hip设备的数据传输方法及***
CN102714617B (zh) * 2010-10-29 2015-10-21 华为技术有限公司 连接建立方法、装置及通信***
US8683019B1 (en) * 2011-01-25 2014-03-25 Sprint Communications Company L.P. Enabling external access to a private-network host
US9021104B2 (en) * 2011-02-28 2015-04-28 Futurewei Technologies, Inc. System and method for mobility management in a wireless communications system
US9712566B2 (en) * 2012-02-10 2017-07-18 Empire Technology Development Llc Providing session identifiers
GB201410089D0 (en) * 2014-06-06 2014-07-23 Bae Systems Plc Secured network bridge
CN106603513A (zh) * 2016-11-30 2017-04-26 中国人民解放军理工大学 基于主机标识的资源访问控制方法以及***
US10893126B2 (en) * 2018-03-29 2021-01-12 Siemens Aktiengesellschaft Method and apparatus for protocol translation and exchange of selectable, contextualized data between a server using a next-generation protocol and a legacy server

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6101549A (en) * 1996-09-27 2000-08-08 Intel Corporation Proxy-based reservation of network resources
DE69737645T2 (de) * 1996-11-01 2007-11-22 Hitachi, Ltd. Kommunikationsverfahren zwischen einem IPv4-Endgerät und einem IPv6-Endgerät und IPv4-IPv6-Umwandlungsvorrichtung
US6061346A (en) * 1997-01-17 2000-05-09 Telefonaktiebolaget Lm Ericsson (Publ) Secure access method, and associated apparatus, for accessing a private IP network
US6973057B1 (en) * 1999-01-29 2005-12-06 Telefonaktiebolaget L M Ericsson (Publ) Public mobile data communications network
FR2804269A1 (fr) * 2000-01-06 2001-07-27 Avalon Passerelle de communicaton entre des elements heterogenes de protocoles differents et les membres specifiques d'une communaute en reseau
KR100442425B1 (ko) * 2000-11-15 2004-07-30 엘지전자 주식회사 이동통신 시스템에서 인터넷 아이피멀티캐스팅/브로드캐스팅 방법
KR100566703B1 (ko) * 2000-12-21 2006-04-03 닛뽕덴끼 가부시끼가이샤 로커 시스템, 로커 제어 방법, 제어 센터, 및 기록 매체
US7171453B2 (en) * 2001-04-19 2007-01-30 Hitachi, Ltd. Virtual private volume method and system
WO2003084184A1 (en) * 2002-03-27 2003-10-09 British Telecommunications Public Limited Company Tunnel broker management
US7346771B2 (en) * 2002-11-13 2008-03-18 Nokia Corporation Key distribution across networks
US7827313B2 (en) * 2004-02-13 2010-11-02 Telefonaktiebolaget Lm Ericsson (Publ) Addressing method and method and apparatus for establishing host identity protocol (HIP) connections between legacy and HIP nodes
GB2423448B (en) * 2005-02-18 2007-01-10 Ericsson Telefon Ab L M Host identity protocol method and apparatus

Also Published As

Publication number Publication date
CA2559076A1 (en) 2005-10-27
PL1735963T3 (pl) 2008-01-31
EP1735963B1 (de) 2007-06-27
WO2005101753A8 (en) 2006-05-18
DE602004007303D1 (de) 2007-08-09
ATE366018T1 (de) 2007-07-15
US7873825B2 (en) 2011-01-18
EP1735963A1 (de) 2006-12-27
CN1939000B (zh) 2011-01-12
CN1939000A (zh) 2007-03-28
US20070204150A1 (en) 2007-08-30
WO2005101753A1 (en) 2005-10-27

Similar Documents

Publication Publication Date Title
DE602004007303T2 (de) Identifizierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE10393628B4 (de) System und Verfahren zum Integrieren mobiler Vernetzung mit sicherheitsbasierten virtuellen privaten Netzwerksystemen (VPNS)
DE69831974T2 (de) Verfahren zur paketauthentifizierung in gegenwart von netzwerkadressübersetzungen und protokollumwandlungen
EP1943808B1 (de) Verfahren und server zum bereitstellen eines mobilitätsschlüssels
EP1271896B1 (de) Verfahren und System für mobile IP-Nodes in heterogenen Netzwerken
DE10297253T5 (de) Adressiermechanismus in Mobile-IP
DE60116736T2 (de) System und verfahren zur benutzung einer ip-addresse als identifizierung eines drahtlosen endgerätes
DE102006004868B4 (de) Verfahren und Server zum Bereitstellen eines Mobilitätsschlüssels
EP2025120B1 (de) Verfahren und system zum bereitstellen eines mobile ip schlüssels
EP1943856B1 (de) Verfahren und server zum bereitstellen eines mobilitätsschlüssels
EP1884102B1 (de) Hostidentitätsprotokollverfahren und gerät
EP2052517A1 (de) Verfahren und system zum bereitstellen eines zugangsspezifischen schlüssels
WO2007068613A1 (de) Verfahren zur übertragung von auf dem ethernet-übertragungsprotokoll basierenden datenpaketen zwischen zumindest einer mobilen kommunikationseinheit und einem kommunikationssystems
DE102006014350A1 (de) Verfahren und Server zum teilnehmerspezifischen Aktivieren eines netzbasierten Mobilitätsmanagements
EP2062400A1 (de) Verfahren und system zur adressierung und zum routing bei verschlüsselten kommunikationsbeziehungen
EP1266493B1 (de) Verfahren und anordnung zum übertragen eines datenpakets von einer ersten vermittlungseinheit an eine zweite vermittlungseinheit in einem datennetz
DE60222875T2 (de) Verfahren und system zur erkennung einer namenserveradresse
DE102006014594A1 (de) Verfahren zum Wiederherstellen einer mit IPsec kryptographisch gesicherten Verbindung
WO2004043014A2 (de) Verfahren zum übertragen von daten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition