(57)【要約】  ＨＩＰプロキシ（１６）を介して、ＨＩＰ使用可能でない第１ホスト（１２）と、ＨＩＰ使用可能である第２ホスト（１４）間の通信を少なくとも部分的に安全にする方法が提供される。この方法は、前記第２ホスト（１４）のＩＰアドレスを解決するために、前記第１ホスト（１２）からクエリーを送信し（Ａ）、前記クエリーに応じて、前記第２ホスト（１４）に関連付けられているＩＰアドレス（ＩＰfa）とＨＩＴ（ＨＩＴhip）を検索し（Ｂ，Ｃ）、前記第２ホスト（１４）に関連付けられている代替ＩＰアドレス（ＩＰres）を前記ＨＩＰプロキシ（１６）から返信し（Ｅ）、かつ前記ＨＩＰプロキシ（１６）で、前記代替ＩＰアドレス（ＩＰres）、前記検索されたＩＰアドレス（ＩＰfa）及び前記検索されたＨＩＴ（ＨＩＴhip）間のマッピングを保持し（Ｄ）、自身の宛先アドレスとして前記代替ＩＰアドレス（ＩＰres）を含む、前記第１ホスト（１２）からのセッション開始メッセージ（ＴＣＰ  ＳＹＮ）の、前記ＨＩＰプロキシでの受信（Ｆ）において、前記ＨＩＰプロキシ（１６）と前記第２ホスト（１４）間の安全なＨＩＰ接続（２２）をネゴシエートするために前記マッピングを使用する。
2007522744.tif 000002
【特許請求の範囲】
【請求項１】
ＨＩＰ（ホストアイデンティティプロトコル）プロキシを介して、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間の通信を少なくとも部分的に安全にする方法であって、
前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するために、前記第１ホストからクエリーを送信し、
前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを前記ＨＩＰプロキシから返信し、かつ前記ＨＩＰプロキシで、前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、
自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの、前記ＨＩＰプロキシでの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する
ことを特徴とする方法。
【請求項２】
前記セッション開始メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記検索されたＩＰアドレスと前記検索されたＨＩＴを参照し、かつ該検索されたＩＰアドレスと該検索されたＨＩＴを使用してＨＩＰネゴシエーションを実行して、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴとともにレスポンダを検索して識別し、かつインジケータを検索して識別する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記検索されたＩＰアドレスは、前記第２ホストによって使用される転送エージェントのＩＰアドレスであり、
更に、前記ＨＩＰプロキシと前記第２ホスト間の前記ＨＩＰネゴシエーションを、最初にＨＩＰネゴシエーションパケットを前記転送エージェットへ送信することによって開始する
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
更に、前記ＨＩＰネゴシエーション中に、前記ＨＩＰプロキシで前記第２ホストの実際のＩＰアドレスの受信を行い、前記実際のＩＰアドレスを前記ＨＩＰプロキシで保持されるマッピングに含める
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記検索されたＩＰアドレスは、前記ＨＩＰプロキシでの受信に続く前記実際のＩＰアドレスによって、前記マッピングにおいて置換される
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記検索されたＩＰアドレスは、前記第２ホストの実際のＩＰアドレスである
ことを特徴とする請求項１または２に記載の方法。
【請求項７】
更に、前記安全なＨＩＰ接続が確立した後に前記ＨＩＰプロキシで受信される、自身の宛先アドレスとして前記代替ＩＰアドレスを含む発信メッセージに対して、前記マッピングを使用して、前記発信メッセージを前記安全なＨＩＰ接続を介して前記第２ホストへ転送する
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
請求項４に従属する場合には、更に、前記発信メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記実際のＩＰアドレスと前記検索されたＨＩＴを参照し、前記実際のＩＰアドレスと前記検索されたＨＩＴを使用して前記発信メッセージを前記第２ホストへ転送して、前記発信メッセージの宛先を検索して識別し、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴを使用して前記発信メッセージのソースを検索して識別する
ことを特徴とする請求項７に記載の方法。
【請求項９】
更に、前記安全なＨＩＰ接続を介して、前記セッション開始メッセージを前記ＨＩＰプロキシから前記第２ホストへ転送することによって、前記第１ホスト及び前記第２ホスト間の通信の確立を完了し、前記安全なＨＩＰ接続を介して、前記第２ホストから前記ＨＩＰプロキシへセッション応答確認メッセージでリプライし、前記セッション応答確認メッセージを前記第１ホストへ転送する
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記セッション応答確認メッセージは、ＴＣＰ  ＡＣＫメッセージである
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記セッション開始メッセージは、ＴＣＰ  ＳＹＮメッセージである
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１２】
更に、前記確立された安全なＨＩＰ接続を介して、前記第２ホストから前記プロキシで受信される着信メッセージに対して、前記ＨＩＰプロキシのＮＡＴ機能を使用して、前記着信メッセージを適切な宛先ホストへ転送する
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記クエリーは、ＤＮＳクエリーである
ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記ＨＩＰプロキシは、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索することを実行する
ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記ＨＩＰプロキシは、外部ＤＮＳサーバから、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索する
ことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記ＨＩＰプロキシは、内部ＤＮＳサーバから、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索する
ことを特徴とする請求項１４に記載の方法。
【請求項１７】
前記ＨＩＰプロキシは、前記第１ホストから前記ＤＮＳクエリーを捕捉する
ことを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
【請求項１８】
ＨＩＰ（ホストアイデンティティプロトコル）使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホストと、ＨＩＰプロキシを備える通信システムであって、
前記第１ホストは、
前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するためのクエリーを送信する手段を備え、
前記ＨＩＰプロキシは、
前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索する手段と、
前記第２ホストに関連付けられている代替ＩＰアドレスを返信する手段と、
前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、
自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段と
を備えることを特徴とする通信システム。
【請求項１９】
ＨＩＰ（ホストアイデンティティプロトコル）プロキシによって、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用する方法であって、
前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するために、前記第１ホストからクエリーを受信し、
前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、
自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する
ことを特徴とする方法。
【請求項２０】
ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用するためのＨＩＰ（ホストアイデンティティプロトコル）プロキシであって、
前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するために、前記第１ホストからクエリーを受信する手段と、
前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、
自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間の安全なＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段と
を備えることを特徴とするＨＩＰプロキシ。
【請求項２１】
ＨＩＰプロキシ上で動作する場合に、前記ＨＩＰプロキシに請求項１９に記載の方法を実行させることを特徴とするオペレーティングプログラム。
【請求項２２】
ＨＩＰプロキシ内にロードされる場合に、前記ＨＩＰプロキシが請求項２０に記載のＨＩＰプロキシを実現させることを特徴とするオペレーティングプログラム。
【請求項２３】
搬送媒体上で搬送されることを特徴とする請求項２１または２２に記載のオペレーティングプログラム。
【請求項２４】
前記搬送媒体は、送信媒体である
ことを特徴とする請求項２３に記載のオペレーティングプログラム。
【請求項２５】
前記搬送媒体は、記憶媒体である
ことを特徴とする請求項２３に記載のオペレーティングプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の背景
１．本発明の分野
本発明は、ＨＩＰ使用可能でないホストと、ＨＩＰ使用可能である別のホスト間の通信を少なくとも部分的に安全する（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とのみを有することになる。
【００８６】
上述では、ＨＩＰプロキシ１６がＤＮＳクエリーを外部ＤＮＳサーバ２４へ送信することを説明しているが、ＨＩＰプロキシ１６は、外部のＤＮＳクエリーを必要としないで、自身でＤＮＳサーバの機能を提供可能にすることが可能である。
【００８７】
レガシーホスト１２、ＨＩＰプロキシ１６及びＨＩＰホスト１４の１つ以上の動作がデバイス上で動作するプログラムによって制御できることは明らかであろう。このようなオペレーティングプログラムは、コンピュータ可読媒体に記憶することができる。あるいは、例えば、インターネットウェブサイトから提供される、ダウンロード可能なデータ信号のような信号で実現することもできる。請求項は、それ自身によってオペレーティングプログラムを含むように解釈されるべきであり、あるいは、キャリヤ（搬送媒体）上のレコード、信号あるいは任意の他の形態として解釈されるべきである。
【００８８】
当業者は、本発明の実施形態は、トランスポートレイヤーあるいはネットワークレイヤーのようなレイヤーのそれぞれに対する特定のプロトコルに制限される必要はなく、どのようなアドレッシング（アドレス指定）あるいはトランスポートプロトコルがＨＩＰフレームワークに使用されるとしても、ＨＩＰフレームワーク内で機能することになることを理解するであろう。
【図面の簡単な説明】
【００８９】
【図１】ホストアイデンティティプロトコルにおける様々なレイヤーを示す図である。
【図２】ＨＩＰプロトコルにおける４ウェイハンドシェイクの動作を示す図である。
【図３】ＨＩＰにおける論理的かつ実際のパケット構造を示す図である。
【図４】ＩＰｖ６とＩＰｖ４間のハンドオーバを示す図である。
【図５】ＨＩＰプロキシを介する、レガシーホストとＨＩＰノード間の通信に対する汎用ネットワークセットアップを示す図である。
【図６】本発明の実施形態に従うレガシーホストとＨＩＰホスト間の通信を少なくとも部分的に安全にする方法を示すメッセージ交換図である。
【図７】ＴＣＰ、ＵＤＰ、ＥＳＰ及びＨＩＰで使用されるパケット構造の詳細図である。
【図８】図６の方法のステップの詳細を示すメッセージ交換図である。
【図９】図６の方法のステップの詳細を示すメッセージ交換図である。
【図１０】図６の方法のステップの詳細を示すメッセージ交換図である。
【図１１】図６の方法のステップの詳細を示すメッセージ交換図である。
【図１２】図６の方法のステップの詳細を示すメッセージ交換図である。
【図１】
2007522744.tif 000003
【図２】
2007522744.tif 000004
【図３】
2007522744.tif 000005
【図４】
2007522744.tif 000006
【図５】
2007522744.tif 000007
【図６】
2007522744.tif 000008
【図７】
2007522744.tif 000009
【図８】
2007522744.tif 000010
【図９】
2007522744.tif 000011
【図１０】
2007522744.tif 000012
【図１１】
2007522744.tif 000013
【図１２】
2007522744.tif 000014
【手続補正書】
【提出日】平成17年12月8日(2005.12.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＨＩＰ（ホストアイデンティティプロトコル）プロキシを介して、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間の通信を少なくとも部分的に安全にする方法であって、
前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するために、前記第１ホストからクエリーを送信し、
前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索し、
前記検索に応じて、前記第２ホストに関連付けられている代替ＩＰアドレスを前記ＨＩＰプロキシから返信し、かつ前記ＨＩＰプロキシで、前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、
自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの、前記ＨＩＰプロキシでの受信において、前記ＨＩＰプロキシと前記第２ホスト間のＨＩＰ接続をネゴシエートするために前記マッピングを使用する
ことを特徴とする方法。
【請求項２】
前記セッション開始メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記検索されたＩＰアドレスと前記検索されたＨＩＴを参照し、かつ該検索されたＩＰアドレスと該検索されたＨＩＴを使用してＨＩＰネゴシエーションを実行して、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴとともに前記ＨＩＰネゴシエーションにおけるレスポンダを検索して識別し、かつ前記ＨＩＰネゴシエーションにおけるインジケータを検索して識別する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記検索されたＩＰアドレスは、前記第２ホストによって使用される転送エージェントのＩＰアドレスであり、
更に、前記ＨＩＰプロキシと前記第２ホスト間の前記ＨＩＰネゴシエーションを、最初にＨＩＰネゴシエーションパケットを前記転送エージェットへ送信することによって開始する
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
更に、前記ＨＩＰネゴシエーション中に、前記ＨＩＰプロキシで前記第２ホストの実際のＩＰアドレスの受信を行い、前記実際のＩＰアドレスを前記ＨＩＰプロキシで保持されるマッピングに含める
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記検索されたＩＰアドレスは、前記ＨＩＰプロキシでの受信に続く前記実際のＩＰアドレスによって、前記マッピングにおいて置換される
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記検索されたＩＰアドレスは、前記第２ホストの実際のＩＰアドレスである
ことを特徴とする請求項１または２に記載の方法。
【請求項７】
更に、前記ＨＩＰプロキシにおいて前記代替ＩＰアドレスを生成する
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
更に、前記ＨＩＰ接続が確立した後に前記ＨＩＰプロキシで受信される、自身の宛先アドレスとして前記代替ＩＰアドレスを含む発信メッセージに対して、前記マッピングを使用して、前記発信メッセージを前記ＨＩＰ接続を介して前記第２ホストへ転送する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
請求項４に従属する場合には、更に、前記発信メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記実際のＩＰアドレスと前記検索されたＨＩＴを参照し、前記実際のＩＰアドレスと前記検索されたＨＩＴを使用して前記発信メッセージを前記第２ホストへ転送して、前記発信メッセージの宛先を検索して識別し、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴを使用して前記発信メッセージのソースを検索して識別する
ことを特徴とする請求項８に記載の方法。
【請求項１０】
更に、前記ＨＩＰ接続を介して、前記セッション開始メッセージを前記ＨＩＰプロキシから前記第２ホストへ転送することによって、前記第１ホスト及び前記第２ホスト間の通信の確立を完了し、前記ＨＩＰ接続を介して、前記第２ホストから前記ＨＩＰプロキシへセッション応答確認メッセージでリプライし、前記セッション応答確認メッセージを前記第１ホストへ転送する
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記セッション応答確認メッセージは、ＴＣＰ  ＡＣＫメッセージである
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記セッション開始メッセージは、ＴＣＰ  ＳＹＮメッセージである
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１３】
更に、前記確立されたＨＩＰ接続を介して、前記第２ホストから前記プロキシで受信される着信メッセージに対して、前記ＨＩＰプロキシのＮＡＴ機能を使用して、前記着信メッセージを適切な宛先ホストへ転送する
ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記クエリーは、ＤＮＳクエリーである
ことを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記ＨＩＰプロキシは、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索することを実行する
ことを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
前記ＨＩＰプロキシは、外部ＤＮＳサーバから、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索する
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ＨＩＰプロキシは、内部ＤＮＳサーバから、前記第２ホストに関連付けられている前記ＩＰアドレスと前記ＨＩＴを検索する
ことを特徴とする請求項１５に記載の方法。
【請求項１８】
前記ＨＩＰプロキシは、前記第１ホストから前記クエリーを捕捉する
ことを特徴とする請求項１乃至１７のいずれか１項に記載の方法。
【請求項１９】
ＨＩＰ（ホストアイデンティティプロトコル）使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホストと、ＨＩＰプロキシを備える通信システムであって、
前記第１ホストは、
前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するためのクエリーを送信する手段を備え、
前記ＨＩＰプロキシは、
前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索する手段と、
前記検索に応じて、前記第２ホストに関連付けられている代替ＩＰアドレスを返信する手段と、
前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、
自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間のＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段と
を備えることを特徴とする通信システム。
【請求項２０】
ＨＩＰ（ホストアイデンティティプロトコル）プロキシによって、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用する方法であって、
前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するために、前記第１ホストからクエリーを受信し、
前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索し、
前記検索に応じて、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、
自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間のＨＩＰ接続をネゴシエートするために前記マッピングを使用する
ことを特徴とする方法。
【請求項２１】
ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用するためのＨＩＰ（ホストアイデンティティプロトコル）プロキシであって、
前記第２ホストのＩＰ（インターネットプロトコル）アドレスを解決するために、前記第１ホストからクエリーを受信する手段と、
前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴ（ホストアイデンティティタグ）を検索し、前記検索に応じて、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、
自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間のＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段と
を備えることを特徴とするＨＩＰプロキシ。
【請求項２２】
ＨＩＰプロキシ上で動作する場合に、前記ＨＩＰプロキシに請求項２０に記載の方法を実行させることを特徴とするコンピュータプログラム。
【請求項２３】
ＨＩＰプロキシ内にロードされる場合に、前記ＨＩＰプロキシが請求項２１に記載のＨＩＰプロキシを実現させることを特徴とするコンピュータプログラム。
【請求項２４】
搬送媒体上で搬送されることを特徴とする請求項２２または２３に記載のコンピュータプログラム。
【請求項２５】
前記搬送媒体は、送信媒体である
ことを特徴とする請求項２４に記載のコンピュータプログラム。
【請求項２６】
前記搬送媒体は、記憶媒体である
ことを特徴とする請求項２４に記載のコンピュータプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００４８
【補正方法】変更
【補正の内容】
【００４８】
本発明の要約
本発明の第１の構成に従えば、ＨＩＰプロキシを介して、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間の通信を少なくとも部分的に安全にする方法が提供される。この方法は、前記第２ホストのＩＰアドレスを解決するために、前記第１ホストからクエリーを送信し、前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴを検索し、前記第２ホストに関連付けられている代替ＩＰアドレスを前記ＨＩＰプロキシから返信し、かつ前記ＨＩＰプロキシで、前記代替ＩＰアドレス、前記検索に応じて、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの、前記ＨＩＰプロキシでの受信において、前記ＨＩＰプロキシと前記第２ホスト間のＨＩＰ接続をネゴシエートするために前記マッピングを使用する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００４９
【補正方法】変更
【補正の内容】
【００４９】
この方法は、前記セッション開始メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記検索されたＩＰアドレスと前記検索されたＨＩＴを参照し、該検索されたＩＰアドレスと該検索されたＨＩＴを使用してＨＩＰネゴシエーションを実行して、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴとともにＨＩＰネゴシエーションにおけるレスポンダを検索して識別し、かつＨＩＰネゴシエーションにおけるインジケータを検索して識別することを含んでも良い。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００５２
【補正方法】変更
【補正の内容】
【００５２】
前記検索されたＩＰアドレスは、前記第２ホストの実際のＩＰアドレスであっても良い。
前記方法は、更に、前記ＨＩＰプロキシにおいて前記代替ＩＰアドレスを生成しても良い。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００５３
【補正方法】変更
【補正の内容】
【００５３】
この方法は、更に、前記ＨＩＰ接続が確立した後に前記ＨＩＰプロキシで受信される、自身の宛先アドレスとして前記代替ＩＰアドレスを含む発信メッセージに対して、前記マッピングを使用して、前記発信メッセージを前記ＨＩＰ接続を介して前記第２ホストへ転送することを含んでも良い。このことは、前記発信メッセージ内の前記代替ＩＰアドレスに基づいて、前記マッピングから前記実際のＩＰアドレスと前記検索されたＨＩＴを参照し、前記実際のＩＰアドレスと前記検索されたＨＩＴを使用して前記発信メッセージを前記第２ホストへ転送して、前記発信メッセージの宛先を検索して識別し、前記ＨＩＰプロキシのＩＰアドレスとＨＩＴを使用して前記発信メッセージのソースを検索して識別することを含んでも良い。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００５４
【補正方法】変更
【補正の内容】
【００５４】
この方法は、更に、前記ＨＩＰ接続を介して、前記セッション開始メッセージを前記ＨＩＰプロキシから前記第２ホストへ転送することによって、前記第１ホスト及び前記第２ホスト間の通信の確立を完了し、前記ＨＩＰ接続を介して、前記第２ホストから前記ＨＩＰプロキシへセッション応答確認メッセージでリプライし、前記セッション応答確認メッセージを前記第１ホストへ転送することを含んでも良い。前記セッション応答確認メッセージは、ＴＣＰ  ＡＣＫメッセージであっても良い。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００５６
【補正方法】変更
【補正の内容】
【００５６】
この方法は、更に、前記確立されたＨＩＰ接続を介して、前記第２ホストから前記プロキシで受信される着信メッセージに対して、前記ＨＩＰプロキシのＮＡＴ機能を使用して、前記着信メッセージを適切な宛先ホストへ転送することを含んでも良い。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００５９
【補正方法】変更
【補正の内容】
【００５９】
本発明の第２の構成に従えば、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホストと、ＨＩＰプロキシを備える通信システムが提供される。前記第１ホストは、前記第２ホストのＩＰアドレスを解決するためのクエリーを送信する手段を備える。前記ＨＩＰプロキシは、前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴを検索する手段と、前記検索に応じて、前記第２ホストに関連付けられている代替ＩＰアドレスを返信する手段と、前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間のＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段とを備える。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００６０
【補正方法】変更
【補正の内容】
【００６０】
本発明の第３の構成に従えば、ＨＩＰプロキシによって、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用する方法が提供される。この方法は、前記第２ホストのＩＰアドレスを解決するために、前記第１ホストからクエリーを受信し、前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴを検索し、前記検索に応じて、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持し、自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間のＨＩＰ接続をネゴシエートするために前記マッピングを使用することを含んでいる。
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００６１
【補正方法】変更
【補正の内容】
【００６１】
本発明の第４の構成に従えば、ＨＩＰ使用可能でない第１ホストと、ＨＩＰ使用可能である第２ホスト間で少なくとも部分的に安全な通信を使用するためのＨＩＰプロキシが提供される。このＨＩＰプロキシは、前記第２ホストのＩＰアドレスを解決するために、前記第１ホストからクエリーを受信する手段と、前記クエリーに応じて、前記第２ホストに関連付けられているＩＰアドレスとＨＩＴを検索し、前記検索に応じて、前記第２ホストに関連付けられている代替ＩＰアドレスを返信し、かつ前記代替ＩＰアドレス、前記検索されたＩＰアドレス及び前記検索されたＨＩＴ間のマッピングを保持する手段と、自身の宛先アドレスとして前記代替ＩＰアドレスを含む、前記第１ホストからのセッション開始メッセージの受信において、前記ＨＩＰプロキシと前記第２ホスト間のＨＩＰ接続をネゴシエートするために前記マッピングを使用する手段とを備えている。
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】００６２
【補正方法】変更
【補正の内容】
【００６２】
本発明の第５の構成に従えば、ＨＩＰプロキシ上で動作する場合に、前記ＨＩＰプロキシに本発明の第３の構成に従う方法を実行させるコンピュータプログラムが提供される。
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】００６３
【補正方法】変更
【補正の内容】
【００６３】
本発明の第６の構成に従えば、ＨＩＰプロキシ内にロードされる場合に、前記ＨＩＰプロキシが本発明の第４の構成に従うＨＩＰプロキシを実現させるコンピュータプログラムが提供される。
【手続補正１３】
【補正対象書類名】明細書
【補正対象項目名】００６４
【補正方法】変更
【補正の内容】
【００６４】
前記コンピュータプログラムは、搬送媒体上で搬送されても良く、この搬送媒体は、送信媒体あるいは記憶媒体であっても良い。
【国際調査報告】
2007522744.tif 000015
2007522744.tif 000016