JP2007522744A - レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置 - Google Patents

レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置 Download PDF

Info

Publication number
JP2007522744A
JP2007522744A JP2006552476A JP2006552476A JP2007522744A JP 2007522744 A JP2007522744 A JP 2007522744A JP 2006552476 A JP2006552476 A JP 2006552476A JP 2006552476 A JP2006552476 A JP 2006552476A JP 2007522744 A JP2007522744 A JP 2007522744A
Authority
JP
Japan
Prior art keywords
hip
host
address
proxy
hit
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.)
Granted
Application number
JP2006552476A
Other languages
English (en)
Other versions
JP4579934B2 (ja
Inventor
パトリック サルメラ，
ヨルマ ウォール，
ペトリ ヨケラ，
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン（パブル）
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 テレフオンアクチーボラゲット エル エム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Publication of JP2007522744A publication Critical patent/JP2007522744A/ja
Application granted granted Critical
Publication of JP4579934B2 publication Critical patent/JP4579934B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

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
    • 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/0281—Proxies
    • 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
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • 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)
  • Cable Transmission Systems, Equalization Of Radio And Reduction Of Echo (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

ＨＩＰプロキシ（１６）を介して、ＨＩＰ使用可能でない第１ホスト（１２）と、ＨＩＰ使用可能である第２ホスト（１４）間の通信を少なくとも部分的に安全にする方法が提供される。この方法は、前記第２ホスト（１４）のＩＰアドレスを解決するために、前記第１ホスト（１２）からクエリーを送信し（Ａ）、前記クエリーに応じて、前記第２ホスト（１４）に関連付けられているＩＰアドレス（ＩＰfa）とＨＩＴ（ＨＩＴhip）を検索し（Ｂ，Ｃ）、前記第２ホスト（１４）に関連付けられている代替ＩＰアドレス（ＩＰres）を前記ＨＩＰプロキシ（１６）から返信し（Ｅ）、かつ前記ＨＩＰプロキシ（１６）で、前記代替ＩＰアドレス（ＩＰres）、前記検索されたＩＰアドレス（ＩＰfa）及び前記検索されたＨＩＴ（ＨＩＴhip）間のマッピングを保持し（Ｄ）、自身の宛先アドレスとして前記代替ＩＰアドレス（ＩＰres）を含む、前記第１ホスト（１２）からのセッション開始メッセージ（ＴＣＰ ＳＹＮ）の、前記ＨＩＰプロキシでの受信（Ｆ）において、前記ＨＩＰプロキシ（１６）と前記第２ホスト（１４）間の安全なＨＩＰ接続（２２）をネゴシエートするために前記マッピングを使用する。

Description

本発明の背景
１．本発明の分野
本発明は、ＨＩＰ使用可能でないホストと、ＨＩＰ使用可能である別のホスト間の通信を少なくとも部分的に安全する（at least securing communications）方法に関するものである。また、本発明は、そのような方法を使用する通信システム及びＨＩＰプロキシに関するものである。
２．従来技術の説明
インターネットが当初考案された時には、ホストの位置は固定されていて、かつ実際のセキュリティあるいはホスト識別プロトコルが欠落しているにも関わらず、ユーザ間には暗黙の信頼が存在していた。また、この状況は、技術が幅広く取り込まれかつ使用されても継続していた。ホストモビリティを取り扱うための技術を検討する必要性はあまりなかった。これは、コンピュータが比較的かさばるものであり、かつ固定されていたからである。
１９９０年初期における電気通信及びコンピュータ産業の革命に伴って、より小型の通信機器及びコンピュータがより幅広く利用可能となり、またワールドワイドウェブの発明をもたらした。また、それを用いて生み出されるあらゆるサービスは、最終的には、世間一般の人々にインターネットを魅力的なものにした。ネットワークと移動電気通信を組み合わせた使用の増加は、インターネットにおけるモビリティ管理を安全なものにするための必要性を生じさせた。
加入者の数の増加と、サービスに対して必要とされる金銭的な取引もまた、付加的なアプリケーションレベルのセキュリティの必要性を生じさせた。現在では、最も広く使用されている暗号プロトコル、例えば、ＳＳＬ／ＴＬＳは、上位ネットワークレイヤー、例えば、ＴＣＰ内で動作している。
上述のモビリティ管理及びセキュリティの問題を考慮して、モバイルＩＰ規格（シー．ペルキンス、「ＩＰｖ４用ＩＰモビリティサポート」、ＲＦＣ３２２０、ＩＥＴＦ、２００２年）とモバイルＩＰｖ６規格（ディー．ジョンソン、シー．ペルキンス、ジェイ．アルッコ、「ＩＰｖ６におけるモビリティサポート」、インターネットドラフト、策定中、draft-ietf-mobileip-ipv6-24.txt、ＩＥＴＦ、２００３年）が導入されている。これらの仕様とともに、次世代インターネット用のモビリティサポートを提供することが計画されている。セキュリティ機能は、ＩＰレイヤーでセキュリティを提供することを目的として、ＩＰｓｅｃと、それに関連するアクティビティ、例えば、様々なキー交換プロトコルとの形式で発達してきている。しかしながら、現在の規格を使用してセキュリティとモビリティとを組み合わせることはかなり難しいことが経験的に示されている。
ＩＰアドレスは、ネットワーク内のノードのトポロジー的な位置を記述している。このＩＰアドレスは、ソースノードから宛先へパケットを転送するために使用される。同時に、ＩＰアドレスは、１つのエンティティで２つの異なる機能を提供するノードを識別するために使用される。このことは、だれがいるかを問い合わせる場合に、自身のホームアドレスを用いて応答する人に似ている。モビリティも考慮される場合、この状況は、より複雑となる。これは、ＩＰアドレスが、このスキームにおけるホストアイデンティティとして動作するからである。これらは変更されてはならない。また、ＩＰアドレスはトポロジー的な位置も示しているので、これらは、ネットワーク内の自身の位置をホストが変更する場合には変更する必要がある。明らかなことは、安定的な変更と動的な変更の両方を同時に達成することは不可能なことである。
モバイルＩＰの場合、このソリューションは、ノードに対する「ホームアドレス」を提供する固定ホーム位置を使用することである。このホームアドレスは、ノードを識別し、かつノードがホームに存在する場合のノードに対する適切な位置を提供する。現在の位置情報は、気付けアドレスの形式で利用可能であり、これは、ノードがホームから離れる場合のルーティング（転送）目的のために使用される。
この問題に対する別のソリューションは、識別機能と位置機能とを互いに分離することである。これは、ホストアイデンティティプロトコル（ＨＩＰ）提案（アール．モスコビッツ、ピー．ニカンデル、ピー．ジョケラ、「ホストアイデンティティプロトコル」、インターネットドラフト、策定中、draft-moskowitz-hip-07.txt、ＩＥＴＦ、２００３年）で取り上げられている方法である。ＨＩＰは、新規の名前区間であるホストアイデンティティ（ＨＩ）を導入することによって、ＩＰアドレスの位置の役割とアデンティティの役割を分離している。ＨＩＰでは、ホストアイデンティティは、基本的には、パブリック−プライベートキーペアのパブリック暗号キーである。このパブリックキーは、プライベートキーのコピーだけを保持するパーティ（関係者（加入者））を識別する。このキーペアのプライベートキーを保有するホストは、それが、ネットワークで識別するために使用されるパブリックキーを「所有している」ことを直接証明することができる。この分離は、安全な（セキュアな）方法でモビリティ及びマルチホーミングを処理するための手段をも提供する。
ＨＩＰは以下で詳細に説明するが、ＨＩＰは、位置及びアイデンティティ分離の概念に基づく提案だけではない。ＦＡＲＡ（ディー．クラーク、アール．ブラデン、エイ．フォルク、ブイ．ピンガリ、「ＦＡＲＡ：アドレッシングアーキテクチャの再編成」、ＡＣＭ ＳＩＧＣＯＭＭ ２００３ ワークショップ、２００３年８月２５日、２７日）は、実際のアーキテクチャから導出することができるフレームワークを提供する概念の汎用化モデルである。ＦＡＲＡは、ノード識別が検証される場合にＨＩＰを使用することができ、結果として、ＨＩＰを、特定のＦＡＲＡインスタンス化（instantiation）の一部とすることができる。ピアーネットの提案（ジェイ．エリクソン、エム．ファロウツオス、エス．クリシュナムルティ、「ピアーネット：スタックのピアーツーピアダウンプッシュング」、ＩＰＴＰＳ’０３、２００３年２月２０−２１日）は、位置及びアイデンティティの分離について議論している。インターネットインダイレクションインフラストラクチャであるＩ3（アイ．ストイカ等、「インターネットインダイレクションインフラストラクチャ」、ＡＣＭ ＳＩＧＣＯＭＭ’０２、２００２年８月１９−２３日）も、アイデンティティとルーティング情報間の分離を定義している。
ホストアイデンティティプロトコルは、ＩＰレイヤーで位置及びアイデンティティ情報間の分離を導入している。この分離に加えて、ＨＩＰ使用可能ノード間でセキュリティアソシエーション（ＳＡ群）をネゴシエートするためのプロトコルが定義されている。
ＨＩＰを用いる場合、各ホストは、１つ以上のアイデンティティを持っていて、これは、長期間あるいは短期間のものとすることができ、ネットワーク内でそれを識別するために使用することができる。ＨＩＰを用いる場合、識別子は、パブリック−プライベートキーペアのパブリックキーとなる。ホストがプライベートキーを保有する場合、ホストは、パブリックキーが示すアイデンティティを実際に「所有する」ことを証明することができ、これは、ＩＤ−カードを提示することと同種のことである。
各ホストは、短期間用にのみ使用される短期間キーを生成することができる。これらは、同一のアイデンティティを後に識別することがノードに対して必要とされない場合に有用である。例えば、書店から本を購入する場合は長期間の関係としても良く、一方、ユーザプロファイルを収集するために１回だけサーバと接続する場合は短期間動作としてみなすことができる。後者の場合、短期間アイデンティティは、長期間アイデンティティがより広範囲に分散してしまうことを回避するために生成することができる。
パブリックキーであるＨＩＰホストアイデンティティ（ＨＩ）は、極めて長くなることがあるので、あらゆる状況において実用的であるとは言えない。ＨＩＰでは、ＨＩは、１２８ビット長のホストアイデンティティタグ（ＨＩＴ）で表現され、これは、それをハッシュ化することによってＨＩから生成される。つまり、ＨＩＴは、ＨＩを識別する。ＨＩＴは１２８ビット長であるので、これは、ＩＰｖ６アドレスとちょうど同一長となるので、直接ＩＰｖ６アプリケーション用に使用することができる。
ＨＩＰが使用される場合、アプリケーションを含む上位レイヤーは、ＩＰアドレスをそれ以上参照することはない。その代わり、これらは、宛先ホストの「アドレス」として、ＨＩＴを参照する。位置情報は、後述するように、新規のレイヤーに隠されている。ＩＰアドレスはこれ以上ノードを識別することはなく、これらは、ネットワーク内のパケットのルーティング用に使用されるだけである。
アプリケーションは、典型的には位置情報には関心がないが、それらの同位のアイデンティティを知る必要がある。このアイデンティティは、ＨＩＴによって表現される。これは、ＩＰアドレスだけが、ルーティングが関係する下位レイヤーにおいて重要性を持っていることを意味する。アプリケーションが使用するＨＩＴは、任意のパケットがホストから出力される前に、対応するＩＰアドレスにマッピングされなければならない。これは、後述するように、ホストアイデンティティレイヤー内で達成される。
図１はＨＩＰ内の様々なレイヤーを示していて、これらのレイヤーは、標準トランスポートレイヤー４、ネットワークレイヤー８及びリンクレイヤー１０を備え、プロセス２は、その下にあるトランスポートレイヤーと通信する。ＨＩＰを用いる場合、新規のホストアイデンティティレイヤー６が、トランスポートレイヤー４とネットワークレイヤー８との間に配置される。
局所的には、各ＨＩとそれに関係するＨＩＴは、ノードのＩＰアドレスにマッピングされる。パケットをホストから出力する場合には、正しいルートが選択され（何らかの手段によって）、かつ対応するＩＰアドレスはソースアドレス及び宛先アドレスとしてパケットに配置される。上位レイヤーから到達する各パケットは、宛先アドレスとして同位のＨＩＴを含んでいる。ＨＩＴと位置情報間のマッピングは、ＨＩレイヤー６で検出することができる。ここで、宛先アドレスは、マッピングされているＩＰアドレスへ変換され、ソースＨＩＴは、ソースＩＰアドレスに変換される。
同位（ピア）のＨＩＴとＩＰアドレス間のマッピングはいくつかの方法で検索することができ、その内の１つは、ＤＮＳサーバからによるものである。位置情報は、いつでも同位ノードによって更新することができる。この更新処理は、モビリティ管理のサブセクションで詳細に説明する。
ＨＩＰは、４つのメッセージを含む基本メッセージ交換と、４ウェイハンドシェイクを定義していて、これは、ＨＩＰ使用可能ホスト間のセキュリティアソシエーション（ＳＡ）を生成するために使用される。メッセージ交換中には、ディフィ−ヘルマン処理がセッションキーを生成し、かつノード間のＩＰＳｅｃカプセル化セキュリティペイロード（ＥＳＰ）セキュリティアソシエーション（ＳＡ群）のペアを確立するために使用される。
図２は、４ウェイハンドシェイクの動作を示している。ネゴシエートしているパーティ群は、接続を開始するインジケータと、それに対するレスポンダ（応答システム：Responder）がある。インジケータは、Ｉ１パケットを送信することによってネゴシエーションを開始する。このパケットは、ネゴシエーションに関係するノードのＨＩＴを含んでいる。レスポンダのＨＩＴがインジケータで示されていない場合、宛先ＨＩＴはゼロにされていても良い。
レスポンダがＩ１パケットを受信する場合、レスポンダは、インジケータで解決されるべき問題を含むＲ１パケットを返信する。問題解決中に、インジケータがほとんどの計算を実行しなければならないようにプロトコルは設計されている。これは、ＤｏＳ攻撃に対していくつかの保護を与える。Ｒ１は、デフィ−ヘルマン処理も開始し、これには、デフィ−ヘルマンパラメータを伴うレスポンダのパブリックキーを含んでいる。
Ｒ１パケットが受信されると、インジケータは問題を解決し、ＩＰＳｅｃＳＰＩ値と自身の暗号化パブリックキーとともにＩ２パケットで応答クッキーをレスポンダに送信する。レスポンダは、問題が解決されていることを検証し、インジケータを認証して、ＩＰｓｅｃ ＥＳＰ ＳＡ群を生成する。最終のＲ２メッセージは、レスポンダのＳＰＩ値を含んでいる。
ホスト間のＳＡ群は、ＨＩＴで表現されるホストアイデンティティにバインドされる。しかしながら、ネットワーク内を通過するパケットは、実際のＨＩ情報を含んでないが、ＩＰｓｅｃヘッダのセキュリティパラメータインデックス（ＳＰＩ）を使用して、到来パケットは識別され、かつ正しいＳＡにマッピングされる。図３は、パケットがネットワークを通過する場合の論理的かつ実際のパケット構造を示している。
上述のことから、パケット内の位置情報の変更はＩＰｓｅｃ処理に対して問題を生じないことは明らかである。パケットは、依然として、ＳＰＩを使用して正常に識別される。いくつかの理由によって、パケットが間違った宛先へ転送される場合、そのパケットは正しいキーを持っていないので、受信先ではそのパケットをオープンすることはできない。
発信パケットが上位レイヤーからＨＩレイヤーに到達すると、宛先ＨＩＴが、ＩＰｓｅｃ ＳＤＡＢから検証される。宛先ＨＩＴと一致するＳＡが検出される場合、そのパケットは、ＳＡに関連付けられているセッションキーを使用して暗号化される。
ＨＩＴは、パケットを転送するために使用することはできない。つまり、宛先（及びソース）アドレスは、ノードのＩＰアドレスと一致するように変更されなければならない。これらのマッピングは、上述のように、ＨＩレイヤーに記憶される。このアドレスが変更されると、パケットをネットワークに送信することができ、そのパケットは、ＩＰアドレス情報を使用して宛先へ転送される。
受信側ホストで、ＳＰＩ値は、ＩＰｓｅｃ ＳＡＤＢから正しいＳＡを検出するために使用される。エントリが検出される場合、ＩＰアドレスを対応するＨＩＴに変更することができ、また、セッションキーを使用して、パケットを解読することができる。
モビリティは、自身の通信状態をアクティブに維持しながらホストが移動する状況、あるいは換言すれば、既存のあらゆる接続をアクティブに維持しながら、ＩＰアドレスによって記述される自身のトポロジー的位置をホストが変更する状況とするために定義される。おそらくは経験しているサービスの品質を変更する場合以外は、ホスト上で動作中のプロセスはモビリティを確認しない。
モバイルホストは、異なるアクセス技術間、あるいは異なるＩＰアドレス領域間、例えば、ＩＰｖ４とＩＰｖ６ネットワーク間でさえも、１つのアクセスネットワーク内の位置を変更することができる。ＨＩＰでは、アプリケーションは、ＩＰアドレスバージョンにおける変更を通知しない。ＨＩレイヤーは、上位レイヤーからの変更を完全に隠蔽している。もちろん、同位ノードは、ＩＰバージョンを変更する位置更新を処理することが可能でなければならず、また、パケットは、いくつかの互換アドレスを使用して転送可能でなければならない。ノードがＩＰｖ４及びＩＰｖ６接続性の両方を持っていない場合、アドレスバージョン変更を実行するプロキシノードを使用して、ノードに代って接続性を提供しても良い。
マルチホーミング（Multi-homing）とは、自身が使用することができるいくつかの並列通信経路をエンドポイントが持っている状況を意味している。通常、マルチホーミングは、いくつかのネットワークインタフェース（エンドホストマルチホーミング）を有するホスト、あるいは、ホストと、冗長経路（サイトマルチホーミング）を有するネットワークの部分との間のネットワークによるものである。
ＨＩＰを用いると、位置情報と識別情報との分離は、パケット識別とルーティングとを明確に分離できることを明らかにする。パケットを受信するホストは、正しいキーをまず取得して、パケットを解読することによって送信側を識別する。つまり、パケット内に存在するＩＰアドレスは関与しない。
ネットワーク内を移動するＨＩＰモバイルノード（ＨＭＮ）は、インターネットの接続点を定期的に変更することができる。接続点が変更される場合、ＩＰアドレスを変更する。この変更された位置情報は同位ノード、即ち、ＨＩＰ対応ノード（ＨＣＮ）へ送信されなければならない。これについては、図４で示される。同一のアドレスは、ＨＭＮの転送エージェント（ＦＡ）へ送信しなければならない、そうすることで、ＨＭＮは、より適切な地点を介して到達することができる。ＤＮＳシステムは、位置情報を定期的に変更するために使用することには遅すぎる。それゆえ、ＨＭＮに接続するために使用することができるより適切なアドレスが存在しなければならない。このアドレスは、ＦＡによって提供されるアドレスである。
ＨＩＰモビリティとマルチホーミングプロトコル（ピー．ニカンデル、ジェイ．アルコッコ、ピー．ジョケラ、「ホストアイデンティティプロトコルを用いるエンドホストモビリティ及びマルチホーミング」、インターネットドラフト、策定中、draft-nikander-hip-mm-00.txt、ＩＥＴＦ、２００３年）は、ＨＭＮの現在のＩＰアドレスを含む再アドレス割当（ＲＥＡ）パケットを定義している。ＨＭＮが位置及びＩＰアドレスを変更する場合、これは、ＲＥＡパケットを生成し、使用されるＨＩに一致するプライベートキーを用いてパケットを署名し、同位ノードとＦＡへそのパケットを送信する。
同位ノードがＲＥＡパケットを受信すると、ＲＥＡパケットに含まれるＩＰアドレスに対するアドレス検証処理を開始しなければならない。アドレス検証は、ＨＭＮからの不正な更新を受け付けることを回避するために必要とされる。これは、アドレスチェック（ＡＣ）パケットを、ＲＥＡパケット内に存在するアドレスへ送信する。ＨＭＮが、先に送信されているＲＥＡにマッチするＡＣを受信すると、ＨＭＮは、アドレスチェックリプライ（ＡＣＲ）パケットで応答する。同位ノードがＡＣＲパケットを受信した後に、アドレス検証が完了し、かつＨＭＮの位置情報としてＩＰアドレスを追加することができる。
ＨＭＮは、異なるＩＰアドレスバージョンを使用するネットワーク間を移動することができるので、ＨＣＮによって受信されるアドレスも、従前のアドレス以外の異なるアドレスファミリーのものとすることができる。
ＨＣＮは１つのＩＰアドレスバージョンのみをサポートしても良い。この場合、ＨＣＮは、他のＩＰアドレスバージョンのネットワークを介してパケットを転送するために使用することができる、いくつかの他のプロキシノードを使用しなければならない。
異なるアクセスネットワークに接続される異なるインタフェース上に構成される複数のＩＰアドレスを有するマルチホーム化ＨＩＰホストは、同位ノードに向かうトラフィックを処理するための可能性をより一層持っている。このホストは、ネットワーク内の自身の現在の位置を示すＩＰアドレスを複数持っているので、これらのアドレスのすべてを自身の同位ノードへ通知しても良い。そうするためには、マルチホーム化ＨＩＰノードは、特定ノードに向けて使用することができるアドレスのすべてを含むＲＥＡパケットを生成する。このアドレスのセットは、それが有するすべてのアドレス、あるいはこれらのアドレスのいくつかのサブセットを含めることができる。複数のアドレスを伴うＲＥＡパケットを、同位ノードが受信する場合、それは、可能性のある不正な更新を回避するために、これらのアドレズのそれぞれに対してアドレス検証を行わなければならない。
ＨＣＮは、ＲＥＡパケットに含まれるＩＰアドレスに向けられているＡＣパケットのセットを送信する。ＨＭＮがこれらのＡＣを受信すると、ＨＭＮは、ＡＣＲで、これらのそれぞれに対して応答する。ＨＣＮは、受信したＡＣＲパケットから、どのアドレスが有効であるかを判定することができる。
ＲＥＡパケット内の不正なあるいは転送不可能アドレスが発生し得る。これは、ＨＭＮが不正なノードで、それがスタック実装に誤りを持たせているからである。あるいはＨＭＮが、インターネット内で転送不可能なプライベートアドレスを使用するネットワーク内に存在する場合があるからである。
マルチホーム化ＨＩＰノードは利用可能な接続のすべてを使用することができるが、接続の効率的な使用には、潜在的なアクセスネットワークの情報を有し、それらの使用を制御することができるポリシーシステムを必要とする。このようなポリシーシステムは、異なる種類の情報を使用することができる。これには、ユーザプリファレンス、オペレータプリファレンス、ＱｏＳのようなネットワーク接続からの入力及びその類がある。
モバイルノードを用いてＨＩＰ交換を開始するために、インジケータノードは、どのようにしてモバイルノードへ到達するかを知る必要がある。動的ＤＮＳは、不定期にノードを移動するためにこの機能を使用することができるが、代替として、この形態のＤＮＳを使用することは、上述のように導入された静的なインフラストラクチャの部分である、転送エージェント（ＨＩＰ連絡（rendezvous）サーバとも呼ばれる）を使用することである。ＤＮＳサーバを用いて自身の現在の動的アドレスを登録する代わりに、モバイルノードは、転送エージェント（群）のアドレス（群）を登録する。モバイルノードは、自身の現在のＩＰアドレス（群）で継続的に更新される転送エージェント（群）を維持する。転送エージェントは、単に、最初のＨＩＰパケットを、インジケータから、自身の現在の位置にあるモバイルノードへ転送する。インジケータとモバイルノード間で、続くパケットの全てが流される。転送エージェントの動作は通常はかなりわずかであり、これは、主に、アドレス更新と最初のＨＩＰパケット転送である。つまり、１つの転送エージェントは、潜在的な大量のモバイルノードをサポートすることができる。モバイルノードは、自身のＨＩＴとＩＰアドレスマッピングを適切に維持するために転送エージェントを信用しなければならない。転送エージェントは位置が固定されているノードに対してさえも使用することができる。これは、多くの場合、固定ノードは、自身のＩＰアドレスを頻繁に変更することができるからである。このことは、例えば、その固定ノードに対するサービスプロバイダによってインターネット接続がセットアップされる毎に、ＩＰアドレスが割り当てられる場合である。
ノードの両方が移動体であり、かつ同時に移動することが発生する場合にも、転送エージェントが必要とされる。この場合、ＨＩＰ再アドレスパケットがネットワーク内で互いに行き来するが、同位ノードには決して到達しない。この状況を解消するために、ノードは転送エージェントアドレスを記憶していなければならず、また、リプライが受信されない場合には、ＨＩＰ再アドレスパケットを転送エージェントに再送信しなければならない。
移動ノードは、転送エージェントとのＨＩＰアソシエーションを設定し、かつＨＩＰ再アドレスパケットを転送エージェントへ送信することによって、転送エージェントに現存する自身のアドレスを維持する。転送エージェントは、２つのモバイルシステムに、外部のインフラストラクチャ（加えて、転送エージェント自身）を使用することなく、ＨＩＰを使用することを許容することになる。この外部のインフラストラクチャは、その２つのモバイルシステムが他のＨＩとＨＩＴをそれぞれ取得するためのＤＮＳクエリー以外の方法を持っている場合のＤＮＳを含んでいる。
従来（レガシー）の機器では、ホストはＨＩＰを使用可能にすることができない場合があり、唯一の選択肢は、ＩＰアドレスを使用してホスト間の接続を識別することである。これは、安全ではない。この状況は、ＨＩＰ使用可能ホストとＨＩＰを使用できないホスト間にＨＩＰプロキシを配置することによって改善することができる。典型的な状況は、クライアント端末がＨＩＰを使用可能でない小企業のＬＡＮがある。トラフィックは、ＨＩＰプロキシを介して対応するホスト（ＨＩＰ使用可能である）へ転送される。
この構成は、図５に示される。図５では、レガシーホスト１２は、ＨＩＰプロキシ１６を介して、ＨＩＰ使用可能であるノード１４（ドメイン「hip.foo.com」を有する）と通信していることを示している。レガシーホスト１２は、アクセスネットワーク１８を介してＨＩＰプロキシ１６にアクセスする。一方で、ＨＩＰプロキシ１６は、インターネット２０を介してＨＩＰノード１４へアクセスする。レガシーホスト１２とＨＩＰノード１４間の接続を部分的に安全にするために、ＨＩＰプロキシ１６とＨＩＰノード１４間のすべての通信は、図３を参照して上述した方法と同様の方法で、ＨＩＰプロキシ１６とＨＩＰノード１４間でセットアップされているセキュリティアソシエーションが介在する。
しかしながら、レガシーホスト１２とＨＩＰノード１４間での通信を可能にするために、図５に示されるセキュリティアソシエーション２２をセットアップできる前には、ＨＩＰノード１４が上述の転送エージェント２６の配下に配置されている場合にクエリーをＤＮＳサーバ２４−１（及びその次のＤＮＳサーバ２４−２）へ送信することによって、レガシーホスト１２がＨＩＰノード１４のＩＰアドレスを解決するを試行する場合に問題が生じる。ＤＮＳサーバ２４−１は、転送エージェント２６のＩＰアドレスとともにＨＩＰノード１４へＨＩＴを返信する。レガシーホスト１２はＨＩＰを使用可能でないので、ＨＩＴを無視して、転送エージェント２６へのメッセージ送信を開始することになる。ＨＩＴがないと、転送エージェント２６は、これらのメッセージの宛先アドレスを解決することができなくなる。これは、いくつかのＨＩＰノードは同一の転送エージェント２６を使用している可能性がほとんどであるからである。同様に、レガシーホスト１２はＨＩＴを破棄して、かつ接続を開始する場合はＨＩＰノード１４のＩＰアドレスだけを使用するので、ＨＩＰプロキシ１６は自身とＨＩＰノード１４間のＨＩＰネゴシエーションを開始することができない。これは、ＨＩＰプロキシ１６がＨＩＰノード１４のＨＩＴを知らないからである。
このように、上述の問題を回避するＨＩＰプロキシを介して、ＨＩＰ使用可能でない第１ホストとＨＩＰ使用可能である第２ホスト間の通信を少なくとも部分的に安全にする方法を提供することが必要とされている。
本発明の要約
本発明の第１の構成に従えば、ＨＩＰプロキシを介して、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間の通信を少なくとも部分的に安全にする方法が提供される。この方法は、前記第２ホストのＩＰアドレスを解決するために、前記第１ホストからクエリーを送信し、前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴを検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを前記ＨＩＰプロキシから返信し、かつ前記ＨＩＰプロキシで、前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの、前記ＨＩＰプロキシでの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する。
この方法は、前記セッション開始メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記検索されたＩＰアドレスと前記検索されたＨＩＴを参照し、該検索されたＩＰアドレスと該検索されたＨＩＴを使用してＨＩＰネゴシエーションを実行して、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴとともにレスポンダを検索して識別し、かつインジケータを検索して識別することを含んでも良い。
前記検索されたＩＰアドレスは、前記第２ホストによって使用される転送エージェントのＩＰアドレスであっても良く、更に、前記ＨＩＰプロキシと前記第２ホスト間の前記ＨＩＰネゴシエーションを、最初にＨＩＰネゴシエーションパケットを前記転送エージェットへ送信することによって開始することを含んでも良い。
この方法は、更に、前記ＨＩＰネゴシエーション中に、前記ＨＩＰプロキシで前記第２ホストの実際のＩＰアドレスの受信を行い、前記実際のＩＰアドレスを前記ＨＩＰプロキシで保持されるマッピングに含めることを含んでも良い。前記検索されたＩＰアドレスは、前記ＨＩＰプロキシでの受信に続く前記実際のＩＰアドレスによって、前記マッピングにおいて置換されても良い。
前記検索されたＩＰアドレスは、前記第２ホストの実際のＩＰアドレスであっても良い。
この方法は、更に、前記安全なＨＩＰ接続が確立した後に前記ＨＩＰプロキシで受信される、自身の宛先アドレスとして前記代替ＩＰアドレスを含む発信メッセージに対して、前記マッピングを使用して、前記発信メッセージを前記安全なＨＩＰ接続を介して前記第２ホストへ転送することを含んでも良い。このことは、前記発信メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記実際のＩＰアドレスと前記検索されたＨＩＴを参照し、前記実際のＩＰアドレスと前記検索されたＨＩＴを使用して前記発信メッセージを前記第２ホストへ転送して、前記発信メッセージの宛先を検索して識別し、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴを使用して前記発信メッセージのソースを検索して識別することを含んでも良い。
この方法は、更に、前記安全なＨＩＰ接続を介して、前記セッション開始メッセージを前記ＨＩＰプロキシから前記第２ホストへ転送することによって、前記第１ホスト及び前記第２ホスト間の通信の確立を完了し、前記安全なＨＩＰ接続を介して、前記第２ホストから前記ＨＩＰプロキシへセッション応答確認メッセージでリプライし、前記セッション応答確認メッセージを前記第１ホストへ転送することを含んでも良い。前記セッション応答確認メッセージは、ＴＣＰ ＡＣＫメッセージであっても良い。
前記セッション開始メッセージは、ＴＣＰ ＳＹＮメッセージであっても良い。
この方法は、更に、前記確立された安全なＨＩＰ接続を介して、前記第２ホストから前記プロキシで受信される着信メッセージに対して、前記ＨＩＰプロキシのＮＡＴ機能を使用して、前記着信メッセージを適切な宛先ホストへ転送することを含んでも良い。
前記クエリーは、ＤＮＳクエリーであっても良い。前記ＨＩＰプロキシは、前記第１ホストから前記ＤＮＳクエリーを捕捉しても良い。前記ＨＩＰプロキシは、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索することを実行しても良い。
前記ＨＩＰプロキシは、外部ＤＮＳサーバから、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索しても良い。あるいは、前記ＨＩＰプロキシは、内部ＤＮＳサーバから、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索しても良い。
本発明の第２の構成に従えば、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホストと、ＨＩＰプロキシを備える通信システムが提供される。前記第１ホストは、前記第２ホストのＩＰアドレスを解決するためのクエリーを送信する手段を備える。前記ＨＩＰプロキシは、前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴを検索する手段と、前記第２ホストに関連付けられている代替ＩＰアドレスを返信する手段と、前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段とを備える。
本発明の第３の構成に従えば、ＨＩＰプロキシによって、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用する方法が提供される。この方法は、前記第２ホストのＩＰアドレスを解決するために、前記第１ホストからクエリーを受信し、前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴを検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用することを含んでいる。
本発明の第４の構成に従えば、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用するためのＨＩＰプロキシが提供される。このＨＩＰプロキシは、前記第２ホストのＩＰアドレスを解決するために、前記第１ホストからクエリーを受信する手段と、前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴを検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段とを備えている。
本発明の第５の構成に従えば、ＨＩＰプロキシ上で動作する場合に、前記ＨＩＰプロキシに本発明の第３の構成に従う方法を実行させるオペレーティングプログラムが提供される。
本発明の第６の構成に従えば、ＨＩＰプロキシ内にロードされる場合に、前記ＨＩＰプロキシが本発明の第４の構成に従うＨＩＰプロキシを実現させるオペレーティングプログラムが提供される。
前記オペレーティングプログラムは、搬送媒体上で搬送されても良く、この搬送媒体は、送信媒体あるいは記憶媒体であっても良い。
実施形態の詳細説明
本発明の実施形態は、図５を参照して説明されるシステムの汎用フレームワーク内で説明される。本発明の実施形態は、ＨＩＰを使用可能でないレガシーホスト１２と、ＨＩＰプロキシ１６を介してＨＩＰを使用可能であるＨＩＰホスト１４間の通信を少なくとも部分的に安全にする方法を提供する。本発明の実施形態の動作は、図６のメッセージ交換図を参照して説明される。図６に示されるステップ群は、図８から図１２で詳細に説明される。一方、図７は、ＴＣＰ、ＵＤＰ（ユーザデータグラムプロトコル）、ＥＳＰ及びＨＩＰで使用されるパケット構造のより詳細な構成を示している。
レガシーホスト１２が、自身とＨＩＰホスト１４間で通信を開始したいという状況を想定する。レガシーホスト１２は、「hip.foo.com」とする、ＨＩＰホスト１４のドメイン名を知っていて、かつ第１ステップ（図６及び図８では「Ａ」で示されている）として、レガシーホスト１２は、ＨＩＰホスト１４のＩＰアドレスを解決するために、自身の通常のＤＮＳサーバへ、ドメインネームシステム（ＤＮＳ）クエリーを送信する。但し、ＤＮＳサーバで直接受信する代わりに、本発明の実施形態では、ＤＮＳクエリーはＨＩＰプロキシ１６によって捕捉され、ＨＩＰプロキシ１６自身は、ＤＮＳクエリーをＤＮＳサーバ２４−１に送信する（これは、図６及び図８では「Ｂ」で示されている）。
このＤＮＳクエリーの応答では、ＤＮＳサーバ２４−１は、「foo.com」のＤＮＳサーバ２４−２と通信して、ＨＩＰホスト１４に関連付けられているＩＰアドレスとＨＩＴを検索する（図６及び図９では「Ｃ」で示されている）。この例では、ＨＩＰホスト１４は、上述したように「ホームアドレス」として、転送エージェント（ＦＡ）２６を使用しているので、ＤＮＳクエリーによって検索されるＩＰアドレスとＨＩＴは、転送エージェント２６のＩＰアドレスである３ｆｆｅ：２００：：１（ＩＰfa）とＨＩＰホスト１４のＨＩＴとなる。ここでは、ＨＩＰホスト１４のＨＩＴをＨＩＴhipと参照する。ここで、第１サーバから情報が検出されると、追加のＤＮＳサーバを使用する必要がなくなるので、ＤＮＳサーバがＩＰアドレスを解決するために必要とされる場合が常にでないことに注意すべきである。
ＨＩＰプロキシは、ＤＮＳクエリーを送信した最初のホストがＨＩＰ使用可能でないことを知っているので、ＨＩＰプロキシ１６は、ＤＮＳ情報｛ＨＩＴhip、ＩＰfa｝を返信しない。代わりに、ＨＩＰプロキシ１６は、代替ＩＰドレスＩＰresを生成する。これは、例えば、３ｆｆｅ：４０１：：５である。ＨＩＰプロキシ１６は、ＤＮＳサーバ２４から検索されるＨＩＴ、ＤＮＳサーバ２４から検索されるＩＰアドレス、ＨＩＰプロキシ１６によって生成される代替ＩＰアドレスとのマッピング｛ＨＩＴhip；ＩＰfa；ＩＰres｝を保持する。このマッピングは、以下で説明する次の通信のルーティングを処理するために必要とされる。代替ＩＰアドレスＩＰresの生成と、マッピングの保持は、図６及び９では「Ｄ」で示されている。
この間では、ＨＩＰプロキシ１６は、代替ＩＰアドレスＩＰresを用いて、レガシーホスト１２へＤＮＳ応答を送信する。これは、図６及び図９では「Ｅ」で示されている。代替ＩＰアドレスＩＰresは、すべての次の通信用に、宛先アドレスとしてレガシーホスト１２によって使用されることになり、これは、ＨＩＰホスト１４へ送信される。
レガシーホスト１２がＨＩＰホスト１４との接続を開始する準備をしている場合、自身の宛先アドレスとして、代替ＩＰアドレスＩＰresを有するセッション開始メッセージＴＣＰ ＳＹＮを送信し、これは、図６及び図１０では「Ｆ」で示されている。代替ＩＰアドレスＩＰresはＨＩＰプロキシ１６によって生成され、かつマッピングＭで保持されているので、ＨＩＰプロキシ１６は、レガシーホスト１２からのその開始メッセージの宛先アドレスを認識し（図１０では「Ｆ．１」で示されている）、また、レガシーホスト１２とＨＩＰホスト１４間の通信をセットアップし、かつ処理するための責任があると想定する。
ＨＩＰプロキシ１６は、次に、マッピングＭを使用して、ＨＩＰプロキシ１６とＨＩＰホスト１４間のセキュア（安全な）ＨＩＰ接続（セキュリティアソシエーション）をネゴシエートする。ＨＩＰプロキシ１６とＨＩＰホスト１４間で実行されるネゴシエーションは、上述の図２を参照して説明される４ウェイハンドシェイクにかなり類似していて、本例では、インジケータはＨＩＰプロキシ１６であり、レスポンダはＨＩＰホスト１４である。ＨＩＰネゴシエーションの開始は、図６及び図１０では「Ｇ」で示されている。本明細書で使用されている用語「セキュリティアソシエーション」は、２つのホスト間で生成されるセキュリティアソシエーションのペアが生成される場合を含むものと解釈されるべきであることに注意すべきである。このペアの１つは一方向におけるトラフィックを扱うセキュリティアソシエーションであり、もう１つはもう一方向におけるトラフィックを扱うセキュリティアソシエーションである。論理的には、２つのホスト間は１つのＳＡパイプとなっているが、物理的には、２つのＳＡが存在することになる。
マッピングＭを使用して、ＨＩＰプロキシ１６は、Ｉ１パケットがＩＰアドレスＩＰfaへ送信されるべきであるかを判定する。ここで、ＩＰアドレスＩＰfaは、ＨＩＰホスト１４によって使用される転送エージェント２６のＩＰアドレスである。Ｉ１パケットは、ネゴシエーションに関係するノードのＨＩＴ、即ち、ＨＩＴhipとＨＩＴproxyを含んでいる。このマッピングは、図６及び図１０では「Ｈ」で示されている。Ｉ１パケットが転送エージェント２６によって受信される場合、それは、ＨＩＴhipから実際のＩＰアドレスＩＰhipへのマッピングを実行し、かつその受信したＩ１パケットをＩＰhipで指定されるＨＩＰホスト１４への転送する自身の機能を実行する。
以下のＨＩＰホスト１４でのＩ１パケットの受信に続いて、４ウェイハンドシェイクネゴシエーションの残りの部分が、図２を参照して上述したように、Ｒ１、Ｉ２及びＲ２パケットの送信によって形成される。このネゴシエーションが完了すると、ＨＩＰプロキシ１６とＨＩＰホスト１４間のセキュリティアソシエーション２２が確立される。これは、図６及び図１０では「Ｉ」で示されている。
ここで、セキュリティアソシエーション２２がセットアップされると、ＨＩＰプロキシ１６は、ＴＣＰ ＳＹＮ開始メッセージをＨＩＰホスト１４へ送信することによってこれを継続する。実行されるマッピングとネットワークアドレス解決（ＮＡＴ）機能を図１１の下部で詳細に説明する。これは、図１１において「Ｉ．１」で示されている。ＨＩＰホスト１４は、ＨＩＰプロキシ１６のＩＰアドレスで指定されるＴＣＰ ＡＣＫで応答する。ここでは、これは、本例では、３ｆｆｅ：３００：：１である。これらの２つのステップは、図６及び図１１では「Ｊ」で示されている。そして、ＨＩＰプロキシ１６は、自身のＩＰアドレスである３ｆｆｅ：４００：：５０のレガシーホスト１２へＴＣＰ ＡＣＫメッセージを返信し、ＴＣＰ開始処理を完了する。これは、図６及び図１２では「Ｋ」で示されている。図６及び図１１で「Ｊ」で示されている、ＨＩＰホスト１４からＨＩＰプロキシ１６へのＴＣＰ ＡＣＫメッセージは、自身の宛先ＩＰアドレスとして、ＨＩＰプロキシ１６のＩＰアドレスを含んでいるが、レガシーホスト１２のＩＰアドレスは含んでいないことに注意されたい。ＨＩＰプロキシ１６が、ＴＣＰ ＡＣＫメッセージを正しいレガシーホスト１２へどのようにして送信するかを続けて知るかについての方法を説明する。
１つのセキュリティアソシエーション２２だけが、ＨＩＰプロキシ１６とＨＩＰノード１４間でセットアップされると、このセキュリティアソシエーション２２は、同一のＨＩＰホスト１４と通信する複数のレガシーホストによって使用されることになる。上述のマッピングＭはセキュリティアソシエーションに関連付けられていて、レガシーホスト１２のような特定のレガシーホストに関連付けられていない。セキュリティアソシエーション２２とそれに関連付けられているマッピングＭは複数のレガシーホストで使用されなければならないので、マッピングＭは特定のレガシーホストに関連する情報、例えば、セキュリティアソシエーション２２のセットアップを最初に担当するレガシーホストのＩＰアドレスのような情報を含むことができない。代わりに、ＨＩＰプロキシ内のネットワークアドレス解決（ＮＡＴ）機能は、正しいレガシーホストのＩＰアドレスへのパケットのマッピングを取り扱う。
この目的のために、通常のＮＡＴ機能に対しては、上位レイヤーポート番号が使用される。ＨＩＰプロキシ１６を介するＨＩＰホスト１４とレガシーホスト１２間のトラフィックに対して、ＨＩＰホスト１４からＩＰパケットがＨＩＰプロキシ１６に到達する場合のソースアドレスは当初のＨＩＰホスト１４のＩＰアドレスとなる。代替ＩＰアドレスＩＰhipは、セキュリティアソシエーション２２に関連付けられているマッピングＭから検索され、そして、ＩＰパケットのソースアドレスとして置換される。次に、ＩＰパケットはＨＩＰプロキシ１６のＮＡＴ機能に渡され、ソースＩＰアドレスとポート番号を使用して、ＮＡＴ機能はそのＩＰパケットが送信されるべき実際のレガシーホスト１２を確認する。このＮＡＴ機能は、アドレスマッピングのために、そのＩＰアドレスとそのポート番号の両方を使用する。このポート番号は単独で使用することができない。これは、２つのレガシーホストは、同一のソースポート番号を使用し得るからである。また、標準化ＮＡＴ機能はポートマッピングを実行する。これは、それ以外は、２つのホストが同一の外部ノードとの通信に対して同一のソースポート番号を使用する場合にはアドレス解決は機能しないからである。ＮＡＴマッピングを実行する場合、プロトコルも参照される。これは、ＵＤＰとＴＣＰは同一のポート番号を使用することができるからである。
例として、２つのレガシーホストＬＨ１とＬＨ２に対し、ポート１００００を監視する外部ＨＩＰホスト１４との通信を示す。
ＬＨ１： source port(ソースホ゜ート)5000, dst port(宛先ホ゜ート)10000, src(ソース)IP IPlh1, dst(宛先)IP IPres
ＬＨ２： source port(ソースホ゜ート)5000, dst port(宛先ホ゜ート)10000, src(ソース)IP IPlh2, dst(宛先)IP IPres
ＨＩＰプロキシ１６は、以下に示す発信（ＨＩＰホストにバインドされる）接続に対するマッピングを行う。
ＬＨ１： new source(新ソース)5001, dst port(宛先ホ゜ート)10000, src(ソース)IP IPproxy, dst(宛先)IP IPhip
ＬＨ２： new source(新ソース)5002, dst port(宛先ホ゜ート)10000, src(ソース)IP IPproxy, dst(宛先)IP IPhip
つまり、上記の内容は、宛先アドレスもＨＩＰプロキシ１６によってＩＰresからＩＰhipへ変更される以外は、まさに標準ＮＡＴ機能を示している。
ＨＩＰホスト１４は、同一のＩＰアドレスを用いて、ＨＩＰプロキシ１６から２つの別々の接続を見ている。ＨＩＰホスト１４からの着信（ＬＨでバインドされている）トラフィックに対しては、ＨＩＰプロキシ１６は、ここでは、以下のようなマッピングを行うことができる。
dst(宛先)IPproxy, src(ソース)IPhip, dst port(宛先ホ゜ート)5001, src port(ソースホ゜ート)10000
→ dst(宛先)IPlh1 ; src(ソース)IPres ; dst port(宛先ホ゜ート)5000 ; src port(ソースホ゜ート)10000
dst(宛先)IPproxy, src(ソース)IPhip, dst port(宛先ホ゜ート)5002, src port(ソースホ゜ート)10000
→ dst(宛先)IPlh2 ; src(ソース)IPres ; dst port(宛先ホ゜ート)5000 ; src port(ソースホ゜ート)10000
着信パケットのＮＡＴ機能も、図１２の下部で詳細に示されしている。これは、「Ｋ」で示されている。
ＨＩＰセキュリティアソシエーション２２が一旦ＨＩＰプロキシ１６とＨＩＰホスト１４間でセットアップされると、レガシーホスト１２とＨＩＰホスト１４間の連続通信は転送エージェント２６を通過しない。この転送エージェント２６は、上述の開始Ｉ１パケットを転送するためだけに使用される。それゆえ、確立されているセキュリティアソシエーション２２に対しては、転送エージェント（ＩＰfa）のＩＰアドレスは、これ以上、セキュリティアソシエーション２２に関連付けられているマッピングＭで必要とされない。代わりに、ＨＩＰホスト１４の現在の位置情報（ＩＰアドレスＩＰhip）が必要とされる。
それゆえ、転送エージェント２６（ＩＰfa）のＩＰアドレスは、マッピングＭにおいて、ＨＩＰホスト１４（ＩＰhip）のＩＰアドレスに置換することができる。換言すれば、マッピングＭは、｛ＨＩＴhip；ＩＰfa；ＩＰres｝から｛ＨＩＴhip；ＩＰhip；ＩＰres｝へ変更される。このことは、図１０では「Ｈ．１」で示されている。この方法では、自身の宛先アドレスとして代替ＩＰアドレスＩＰresを有する、レガシーホスト１２から送信される任意の連続パケットを、その変更されたマッピングＭを使用して、ＨＩＰプロキシ１６によってセキュリティアソシエーション２２にマッピングすることがことができ、かつ位置ＩＰhipにおけるＨＩＰホスト１４へ直接転送することができる。ソースＩＰアドレスと宛先ＩＰアドレスは、ＨＩＰプロキシ１６において、上記の変更されたマッピングＭから得られるマッピングを用いて｛ｄｓｔ＝ＩＰres；ｓｒｃ＝ＩＰlh｝から｛ｄｓｔ＝ＩＰhip；ｓｒｃ＝ＩＰproxy｝へマッピングされる。ＨＩＰプロキシ１６は、ＨＩＰネゴシエーション中に、Ｒ１パケットから、ＨＩＰホスト１４の実際のＩＰアドレスＩＰhipを受信する。
本発明の実施形態は、ＨＩＰホスト１４が転送エージェント２６の後に配置されている場合で説明されているが、本発明は、ＨＩＰホスト１４によって転送エージェントが使用されない場合にも適用される。例えば、ＨＩＰホスト１４（ドメイン名「hip.foo.com」を用いる）が固定のＩＰアドレスＩＰfixedを持っている場合、転送エージェントを用いずに、ＤＮＳクエリーは、固定ＩＰアドレスＩＰfixedとＨＩＰホスト１４のＨＩＴhipを返信することになる。レガシーホスト１２が「hip.foo.com」に対するＩＰアドレスを解決することを試行する場合、ＨＩＰプロキシ１６はこのＤＮＳクエリーを捕捉して、自身で、ＤＮＳからＩＰfixedとＨＩＴhipを検索することになる。ＨＩＰプロキシ１６は、ＤＮＳサーバ２４から返信されるＩＰアドレスがＨＩＰホスト１４の実際のＩＰアドレスであり、かつＨＩＰホスト１４によって使用される転送エージェントのＩＰアドレスではないことを通常は把握できないので、ＨＩＰプロキシ１６は、上述のように、代替ＩＰアドレスＩＰresを生成して、この代替ＩＰアドレスをレガシーホスト１２へ返信する。ＨＩＰプロキシ１６は、マッピング｛ＨＩＴhip；ＩＰfixed；ＩＰres｝を維持し、かつ、そのマッピングからの｛ＨＩＴhip；ＩＰfixed｝に基づいてＨＩＰホスト１４とネゴシエートする時に受信する、ＩＰresに対するＴＣＰ ＳＹＮパケットの監視を維持している。セキュリティアソシエーションが一旦セットアップされると、ＩＰresに対して指定されるパケットはＨＩＰプロキシ１６によってピックアップされ、かつそのマッピングを使用して｛ＨＩＴhip；ＩＰfixed｝へ転送される。これは、ＩＰfaが決してマッピングに記憶されない、つまり、決して置換されないということ以外は、上述の処理とほぼ同一である。代わりに、このマッピングは、最初からＨＩＰホスト１４のＩＰアドレスを有している。
ＨＩＰプロキシ１６に対して、ＤＮＳサーバ２４から検索されるＩＰアドレスがＨＩＰホスト１４の実際のＩＰアドレスであることを判定することが可能である場合、選択的には、代替ＩＰアドレスを生成することは、ＨＩＰホスト１４の実際のＩＰアドレスを単にレガシーホスト１２へ返信することになる。これは、レガシーホスト１２とＨＩＰホスト１４間の通信が、完全にＨＩＰプロキシ１６をバイパスすることができる可能性を広げることになる。これは、レガシーホスト１２がＨＩＰホスト１４の実際のＩＰアドレスを有しているからである。この場合となる場合、通信はＨＩＰプロトコルによって安全ではなくなるかもしれないが、それでもなお通信は標準ＴＣＰ／ＩＰに基づくことができる。しかしながら、小規模ネットワークでは、レガシーホスト１２からＨＩＰプロキシ１６への１つの発信ルートを用いることで、これまでのように、代替ＩＰアドレスとＨＩＰホスト１４の実際のＩＰアドレス間で必要とされるマッピングがなくても、十分に確立されているセキュリティアソシエーションを用いて、レガシーホスト１２とＨＩＰホスト１４間のセキュア（安全な）ゲートウェイとして動作することがＨＩＰプロキシ１６に対して依然として可能となる。それゆえ、後者の場合では、マッピングＭは、ＨＩＰホスト１４のＩＰアドレスＩＰhipと、ＨＩＰホスト１４のＨＩＴであるＨＩＴhipとのみを有することになる。
上述では、ＨＩＰプロキシ１６がＤＮＳクエリーを外部ＤＮＳサーバ２４へ送信することを説明しているが、ＨＩＰプロキシ１６は、外部のＤＮＳクエリーを必要としないで、自身でＤＮＳサーバの機能を提供可能にすることが可能である。
レガシーホスト１２、ＨＩＰプロキシ１６及びＨＩＰホスト１４の１つ以上の動作がデバイス上で動作するプログラムによって制御できることは明らかであろう。このようなオペレーティングプログラムは、コンピュータ可読媒体に記憶することができる。あるいは、例えば、インターネットウェブサイトから提供される、ダウンロード可能なデータ信号のような信号で実現することもできる。請求項は、それ自身によってオペレーティングプログラムを含むように解釈されるべきであり、あるいは、キャリヤ（搬送媒体）上のレコード、信号あるいは任意の他の形態として解釈されるべきである。
当業者は、本発明の実施形態は、トランスポートレイヤーあるいはネットワークレイヤーのようなレイヤーのそれぞれに対する特定のプロトコルに制限される必要はなく、どのようなアドレッシング（アドレス指定）あるいはトランスポートプロトコルがＨＩＰフレームワークに使用されるとしても、ＨＩＰフレームワーク内で機能することになることを理解するであろう。
ホストアイデンティティプロトコルにおける様々なレイヤーを示す図である。 ＨＩＰプロトコルにおける４ウェイハンドシェイクの動作を示す図である。 ＨＩＰにおける論理的かつ実際のパケット構造を示す図である。 ＩＰｖ６とＩＰｖ４間のハンドオーバを示す図である。 ＨＩＰプロキシを介する、レガシーホストとＨＩＰノード間の通信に対する汎用ネットワークセットアップを示す図である。 本発明の実施形態に従うレガシーホストとＨＩＰホスト間の通信を少なくとも部分的に安全にする方法を示すメッセージ交換図である。 ＴＣＰ、ＵＤＰ、ＥＳＰ及びＨＩＰで使用されるパケット構造の詳細図である。 図６の方法のステップの詳細を示すメッセージ交換図である。 図６の方法のステップの詳細を示すメッセージ交換図である。 図６の方法のステップの詳細を示すメッセージ交換図である。 図６の方法のステップの詳細を示すメッセージ交換図である。 図６の方法のステップの詳細を示すメッセージ交換図である。

Claims (25)

  1. ＨＩＰ（ホストアイデンティティプロトコル）プロキシを介して、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間の通信を少なくとも部分的に安全にする方法であって、
    前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するために、前記第１ホストからクエリーを送信し、
    前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを前記ＨＩＰプロキシから返信し、かつ前記ＨＩＰプロキシで、前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、
    自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの、前記ＨＩＰプロキシでの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する
    ことを特徴とする方法。
  2. 前記セッション開始メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記検索されたＩＰアドレスと前記検索されたＨＩＴを参照し、かつ該検索されたＩＰアドレスと該検索されたＨＩＴを使用してＨＩＰネゴシエーションを実行して、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴとともにレスポンダを検索して識別し、かつインジケータを検索して識別する
    ことを特徴とする請求項１に記載の方法。
  3. 前記検索されたＩＰアドレスは、前記第２ホストによって使用される転送エージェントのＩＰアドレスであり、
    更に、前記ＨＩＰプロキシと前記第２ホスト間の前記ＨＩＰネゴシエーションを、最初にＨＩＰネゴシエーションパケットを前記転送エージェットへ送信することによって開始する
    ことを特徴とする請求項１または２に記載の方法。
  4. 更に、前記ＨＩＰネゴシエーション中に、前記ＨＩＰプロキシで前記第２ホストの実際のＩＰアドレスの受信を行い、前記実際のＩＰアドレスを前記ＨＩＰプロキシで保持されるマッピングに含める
    ことを特徴とする請求項３に記載の方法。
  5. 前記検索されたＩＰアドレスは、前記ＨＩＰプロキシでの受信に続く前記実際のＩＰアドレスによって、前記マッピングにおいて置換される
    ことを特徴とする請求項４に記載の方法。
  6. 前記検索されたＩＰアドレスは、前記第２ホストの実際のＩＰアドレスである
    ことを特徴とする請求項１または２に記載の方法。
  7. 更に、前記安全なＨＩＰ接続が確立した後に前記ＨＩＰプロキシで受信される、自身の宛先アドレスとして前記代替ＩＰアドレスを含む発信メッセージに対して、前記マッピングを使用して、前記発信メッセージを前記安全なＨＩＰ接続を介して前記第２ホストへ転送する
    ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
  8. 請求項４に従属する場合には、更に、前記発信メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記実際のＩＰアドレスと前記検索されたＨＩＴを参照し、前記実際のＩＰアドレスと前記検索されたＨＩＴを使用して前記発信メッセージを前記第２ホストへ転送して、前記発信メッセージの宛先を検索して識別し、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴを使用して前記発信メッセージのソースを検索して識別する
    ことを特徴とする請求項７に記載の方法。
  9. 更に、前記安全なＨＩＰ接続を介して、前記セッション開始メッセージを前記ＨＩＰプロキシから前記第２ホストへ転送することによって、前記第１ホスト及び前記第２ホスト間の通信の確立を完了し、前記安全なＨＩＰ接続を介して、前記第２ホストから前記ＨＩＰプロキシへセッション応答確認メッセージでリプライし、前記セッション応答確認メッセージを前記第１ホストへ転送する
    ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
  10. 前記セッション応答確認メッセージは、ＴＣＰ ＡＣＫメッセージである
    ことを特徴とする請求項９に記載の方法。
  11. 前記セッション開始メッセージは、ＴＣＰ ＳＹＮメッセージである
    ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
  12. 更に、前記確立された安全なＨＩＰ接続を介して、前記第２ホストから前記プロキシで受信される着信メッセージに対して、前記ＨＩＰプロキシのＮＡＴ機能を使用して、前記着信メッセージを適切な宛先ホストへ転送する
    ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
  13. 前記クエリーは、ＤＮＳクエリーである
    ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
  14. 前記ＨＩＰプロキシは、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索することを実行する
    ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
  15. 前記ＨＩＰプロキシは、外部ＤＮＳサーバから、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索する
    ことを特徴とする請求項１４に記載の方法。
  16. 前記ＨＩＰプロキシは、内部ＤＮＳサーバから、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索する
    ことを特徴とする請求項１４に記載の方法。
  17. 前記ＨＩＰプロキシは、前記第１ホストから前記ＤＮＳクエリーを捕捉する
    ことを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
  18. ＨＩＰ（ホストアイデンティティプロトコル）使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホストと、ＨＩＰプロキシを備える通信システムであって、
    前記第１ホストは、
    前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するためのクエリーを送信する手段を備え、
    前記ＨＩＰプロキシは、
    前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索する手段と、
    前記第２ホストに関連付けられている代替ＩＰアドレスを返信する手段と、
    前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、
    自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段と
    を備えることを特徴とする通信システム。
  19. ＨＩＰ（ホストアイデンティティプロトコル）プロキシによって、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用する方法であって、
    前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するために、前記第１ホストからクエリーを受信し、
    前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、
    自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する
    ことを特徴とする方法。
  20. ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用するためのＨＩＰ（ホストアイデンティティプロトコル）プロキシであって、
    前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するために、前記第１ホストからクエリーを受信する手段と、
    前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、
    自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段と
    を備えることを特徴とするＨＩＰプロキシ。
  21. ＨＩＰプロキシ上で動作する場合に、前記ＨＩＰプロキシに請求項１９に記載の方法を実行させることを特徴とするオペレーティングプログラム。
  22. ＨＩＰプロキシ内にロードされる場合に、前記ＨＩＰプロキシが請求項２０に記載のＨＩＰプロキシを実現させることを特徴とするオペレーティングプログラム。
  23. 搬送媒体上で搬送されることを特徴とする請求項２１または２２に記載のオペレーティングプログラム。
  24. 前記搬送媒体は、送信媒体である
    ことを特徴とする請求項２３に記載のオペレーティングプログラム。
  25. 前記搬送媒体は、記憶媒体である
    ことを特徴とする請求項２３に記載のオペレーティングプログラム。
JP2006552476A 2004-02-13 2004-02-13 レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置 Expired - Fee Related JP4579934B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2004/050129 WO2005081466A1 (en) 2004-02-13 2004-02-13 Addressing method and method and apparatus for establishing host identity protocol (hip) connections between legacy and hip nodes

Publications (2)

Publication Number Publication Date
JP2007522744A true JP2007522744A (ja) 2007-08-09
JP4579934B2 JP4579934B2 (ja) 2010-11-10

Family

ID=34878414

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006552476A Expired - Fee Related JP4579934B2 (ja) 2004-02-13 2004-02-13 レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置

Country Status (8)

Country Link
US (1) US7827313B2 (ja)
EP (1) EP1714434B1 (ja)
JP (1) JP4579934B2 (ja)
CN (1) CN1938999B (ja)
AT (1) ATE366017T1 (ja)
DE (1) DE602004007301T2 (ja)
ES (1) ES2287697T3 (ja)
WO (1) WO2005081466A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010537604A (ja) * 2007-08-31 2010-12-02 テレフオンアクチーボラゲット エル エム エリクソン（パブル） モバイルノードの位置更新
JP2012517165A (ja) * 2009-02-05 2012-07-26 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成
JP2013504957A (ja) * 2009-09-17 2013-02-07 ゼットティーイー コーポレーション ネットワーク相互通信の実現方法及びシステム
JP2013506326A (ja) * 2009-09-25 2013-02-21 中興通訊股▲ふん▼有限公司 ネットワーク間ローミングの実現方法、システム並びに問合せ及びネットワークアタッチメントの方法及びシステム
JP2013526107A (ja) * 2010-04-20 2013-06-20 中興通訊股▲ふん▼有限公司 データメッセージの処理方法、システム及びアクセスサービスノード

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005101753A1 (en) * 2004-04-15 2005-10-27 Telefonaktiebolaget Lm Ericsson (Publ) Identification 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
EP1894371A1 (en) * 2005-05-18 2008-03-05 Ninety9.com PTY Ltd. Dynamic address mapping
GB2426672B (en) * 2005-05-27 2009-12-16 Ericsson Telefon Ab L M Host identity protocol method and apparatus
WO2006133740A1 (en) * 2005-06-17 2006-12-21 Telefonaktiebolaget Lm Ericsson (Publ) Host identity protocol method and apparatus
US8566928B2 (en) 2005-10-27 2013-10-22 Georgia Tech Research Corporation Method and system for detecting and responding to attacking networks
GB2442044B8 (en) * 2006-05-11 2011-02-23 Ericsson Telefon Ab L M Addressing and routing mechanism for web server clusters.
GB2449118A (en) * 2007-05-11 2008-11-12 Ericsson Telefon Ab L M Host Identity Protocol Rendezvous Servers which store information about nodes connected to other servers and forward address requests
CN101335747B (zh) * 2007-07-01 2012-10-03 华为技术有限公司 通信地址通知、探索及通信检测、恢复方法及其装置
CN101350807B (zh) * 2007-07-20 2012-04-04 华为技术有限公司 多地址空间移动网络架构、主机信息注册及数据发送方法
CN101383758B (zh) * 2007-09-07 2011-04-20 华为技术有限公司 多地址空间移动网络架构、路由器及数据发送方法
US20100284400A1 (en) * 2007-10-15 2010-11-11 Melen Jan Provisioning mobility services to legacy terminals
CN101425919B (zh) * 2007-11-02 2012-06-06 华为技术有限公司 主机标识标签的生成、分配方法和设备、网络
US10027688B2 (en) 2008-08-11 2018-07-17 Damballa, Inc. Method and system for detecting malicious and/or botnet-related domain names
CN101827011B (zh) * 2009-03-04 2013-03-27 华为技术有限公司 一种主机通信的方法、系统和设备
CN102025590B (zh) * 2009-09-18 2012-07-18 中兴通讯股份有限公司 新网与互联网互通的实现方法和系统
US8578497B2 (en) 2010-01-06 2013-11-05 Damballa, Inc. Method and system for detecting malware
US8826438B2 (en) 2010-01-19 2014-09-02 Damballa, Inc. Method and system for network-based detecting of malware from behavioral clustering
CN102223353A (zh) 2010-04-14 2011-10-19 华为技术有限公司 主机标识协议安全通道复用方法及装置
US9516058B2 (en) 2010-08-10 2016-12-06 Damballa, Inc. Method and system for determining whether domain names are legitimate or malicious
CN101958910B (zh) * 2010-10-18 2013-05-22 清华大学 基于双代理的一体化标识网络个人通信移动管理方法
CN101997875B (zh) * 2010-10-29 2013-05-29 北京大学 一种安全的多方网络通信平台及其构建方法、通信方法
WO2012055112A1 (zh) * 2010-10-29 2012-05-03 华为技术有限公司 连接建立方法、装置及通信系统
US8683019B1 (en) * 2011-01-25 2014-03-25 Sprint Communications Company L.P. Enabling external access to a private-network host
US8631489B2 (en) 2011-02-01 2014-01-14 Damballa, Inc. Method and system for detecting malicious domain names at an upper DNS hierarchy
US9021104B2 (en) * 2011-02-28 2015-04-28 Futurewei Technologies, Inc. System and method for mobility management in a wireless communications system
WO2012122709A1 (zh) * 2011-03-16 2012-09-20 中兴通讯股份有限公司 身份位置分离网络与互联网的互通方法及互通网络
US8315266B1 (en) * 2012-03-02 2012-11-20 Google Inc. Extending a local area network
CN103369519B (zh) * 2012-04-09 2016-09-28 腾讯科技（深圳）有限公司 获取终端号码的归属地信息的方法和终端
US10547674B2 (en) 2012-08-27 2020-01-28 Help/Systems, Llc Methods and systems for network flow analysis
US10084806B2 (en) 2012-08-31 2018-09-25 Damballa, Inc. Traffic simulation to identify malicious activity
US9166994B2 (en) 2012-08-31 2015-10-20 Damballa, Inc. Automation discovery to identify malicious activity
US9680861B2 (en) 2012-08-31 2017-06-13 Damballa, Inc. Historical analysis to identify malicious activity
US9894088B2 (en) 2012-08-31 2018-02-13 Damballa, Inc. Data mining to identify malicious activity
US9571511B2 (en) 2013-06-14 2017-02-14 Damballa, Inc. Systems and methods for traffic classification
US9912644B2 (en) * 2014-08-05 2018-03-06 Fireeye, Inc. System and method to communicate sensitive information via one or more untrusted intermediate nodes with resilience to disconnected network topology
US9930065B2 (en) 2015-03-25 2018-03-27 University Of Georgia Research Foundation, Inc. Measuring, categorizing, and/or mitigating malware distribution paths
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

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10136052A (ja) * 1996-11-01 1998-05-22 Hitachi Ltd ＩＰｖ４−ＩＰｖ６通信方法およびＩＰｖ４−ＩＰｖ６変換装置

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9303595D0 (en) * 1993-02-23 1993-04-07 Int Computers Ltd Licence management mechanism for a computer system
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
US6839323B1 (en) * 2000-05-15 2005-01-04 Telefonaktiebolaget Lm Ericsson (Publ) Method of monitoring calls in an internet protocol (IP)-based network
US20020194378A1 (en) * 2001-04-05 2002-12-19 George Foti System and method of hiding an internet protocol (IP) address of an IP terminal during a multimedia session
NO20013497D0 (no) * 2001-07-13 2001-07-13 Ericsson Telefon Ab L M Dynamisk distribuering av deltagere i sentraliserte IP- telefonkonferanser
US7028311B2 (en) * 2002-01-04 2006-04-11 Telefonaktiebolaget Lm Ericsson (Publ) Communications node architecture and method for providing control functions in a telecommunications network
US7340535B1 (en) * 2002-06-04 2008-03-04 Fortinet, Inc. System and method for controlling routing in a virtual router system
US7532614B2 (en) * 2002-09-24 2009-05-12 Siemens Communications, Inc. Methods and apparatus for facilitating remote communication with an IP network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10136052A (ja) * 1996-11-01 1998-05-22 Hitachi Ltd ＩＰｖ４−ＩＰｖ６通信方法およびＩＰｖ４−ＩＰｖ６変換装置

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010537604A (ja) * 2007-08-31 2010-12-02 テレフオンアクチーボラゲット エル エム エリクソン（パブル） モバイルノードの位置更新
JP2012517165A (ja) * 2009-02-05 2012-07-26 テレフオンアクチーボラゲット エル エム エリクソン（パブル） ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成
JP2013504957A (ja) * 2009-09-17 2013-02-07 ゼットティーイー コーポレーション ネットワーク相互通信の実現方法及びシステム
US8724630B2 (en) 2009-09-17 2014-05-13 Zte Corporation Method and system for implementing network intercommunication
JP2013506326A (ja) * 2009-09-25 2013-02-21 中興通訊股▲ふん▼有限公司 ネットワーク間ローミングの実現方法、システム並びに問合せ及びネットワークアタッチメントの方法及びシステム
JP2013526107A (ja) * 2010-04-20 2013-06-20 中興通訊股▲ふん▼有限公司 データメッセージの処理方法、システム及びアクセスサービスノード
KR101381701B1 (ko) 2010-04-20 2014-04-04 지티이 코포레이션 데이터 메시지 처리 방법, 시스템 및 접속 서비스 노드

Also Published As

Publication number Publication date
US20070274312A1 (en) 2007-11-29
DE602004007301T2 (de) 2008-02-28
ATE366017T1 (de) 2007-07-15
ES2287697T3 (es) 2007-12-16
EP1714434B1 (en) 2007-06-27
WO2005081466A1 (en) 2005-09-01
JP4579934B2 (ja) 2010-11-10
US7827313B2 (en) 2010-11-02
CN1938999A (zh) 2007-03-28
CN1938999B (zh) 2010-09-01
EP1714434A1 (en) 2006-10-25
DE602004007301D1 (de) 2007-08-09

Similar Documents

Publication Publication Date Title
JP4579934B2 (ja) レガシーノードとｈｉｐノード間のホストアイデンティティプロトコル（ｈｉｐ）接続を確立するためのアドレス指定方法及び装置
EP1340337B1 (en) Location-independent packet routing and secure access in a short-range wireless networking environment
EP1578083B1 (en) Virtual private network structure reuse for mobile computing devices
JP4755203B2 (ja) ホスト・アイデンティティ・プロトコルの方法および装置
US7849195B2 (en) Host identity protocol method and apparatus
US7873825B2 (en) Identification method and apparatus for establishing host identity protocol (HIP) connections between legacy and HIP nodes
JP5147995B2 (ja) ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成
US20120271965A1 (en) Provisioning mobility services to legacy terminals
US7623500B2 (en) Method and system for maintaining a secure tunnel in a packet-based communication system
Jokela et al. Host Identity Protocol: Achieving IPv4 œ IPv6 handovers without tunneling
JP4586721B2 (ja) 通信中にアドレス変更が可能な通信装置、システム及び通信方法
Pierrel et al. A policy system for simultaneous multiaccess with host identity protocol
Komu et al. Basic host identity protocol (HIP) extensions for traversal of network address translators
Camarillo et al. Hip bone: host identity protocol (hip) based overlay networking environment (bone)
Komu et al. RFC 5770: Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators
Nikander et al. Host Identity Protocol (HIP): an overview
Johnston et al. Internet Engineering Task Force (IETF) G. Camarillo Request for Comments: 6079 P. Nikander Category: Experimental J. Hautakorpi
AU2001286799A1 (en) Providing secure network access for short-range wireless computing devices
WO2002021803A2 (en) Providing secure network access for short-range wireless computing devices

Legal Events

Date Code Title Description
A529 Written submission of copy of amendment under article 34 pct

Free format text: JAPANESE INTERMEDIATE CODE: A529

Effective date: 20061010

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070207

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20091016

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091030

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100105

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100301

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100415

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20100709

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100806

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100826

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130903

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees