JP4755203B2 - ホスト・アイデンティティ・プロトコルの方法および装置 - Google Patents

ホスト・アイデンティティ・プロトコルの方法および装置 Download PDF

Info

Publication number
JP4755203B2
JP4755203B2 JP2007556108A JP2007556108A JP4755203B2 JP 4755203 B2 JP4755203 B2 JP 4755203B2 JP 2007556108 A JP2007556108 A JP 2007556108A JP 2007556108 A JP2007556108 A JP 2007556108A JP 4755203 B2 JP4755203 B2 JP 4755203B2
Authority
JP
Japan
Prior art keywords
host
hip
identity
persistent
gateway node
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 - Fee Related
Application number
JP2007556108A
Other languages
English (en)
Other versions
JP2008530948A (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 JP2008530948A publication Critical patent/JP2008530948A/ja
Application granted granted Critical
Publication of JP4755203B2 publication Critical patent/JP4755203B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • 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
    • H04L63/0442—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 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/25—Mapping addresses of the same type
    • 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 Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、２つのホスト間の通信を少なくとも部分的に保護するために、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を使用する方法に関するものであり、２つのホストのうち、一方はＨＩＰが使用可能であり、他方はそうではない。
インターネットが当初考案されたとき、ホストの位置は固定されており、真のセキュリティもしくはホスト識別のプロトコルが欠けているにもかかわらず、ユーザ間には暗黙の信頼があり、この技術の理解や利用が次第に拡大しても、この状況は続いていた。コンピュータは比較的嵩が大きくて、移動不可能であったため、ホストの移動性を扱う技術を考慮する必要はほとんどなかった。
１９９０年代初頭の通信およびコンピュータ業界における大変革と共に、小型の通信機器やコンピュータがより広範に利用できるようになり、ワールドワイドウェブの発明とそれに伴って台頭したあらゆるサービスによって、ついにインターネットは普通の人にとっても魅力のあるものとなった。ネットワークと移動体通信の利用増加が組み合わさって、インターネットにおけるセキュアな移動管理の必要性が生じた。
関係する当事者数の増加や、特定のサービスに必要とされる金融取引の増加によって、アプリケーションレベルのセキュリティについての必要性がさらに加わった。現在、最も広範囲にわたって使用されている暗号化プロトコル（例えばＳＳＬ／ＴＬＳ）は、より上位のネットワーク層（例えばＴＣＰ）の中で実行されている。
上記の移動管理とセキュリティの問題とを考慮に入れて、モバイルＩＰ標準（C. Perkins, "IP Mobility Support for IPv4", RFC3220, IETF, 2002）およびモバイルＩＰｖ６標準（D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", RFC3775, IETF, 2004）が導入された。これらの仕様はともに、次世代インターネットのための移動性サポートを提供することが計画されている。セキュリティ作業は、ＩＰｓｅｃの形で進展中であり、例えば各種のキー交換プロトコルのような関連活動も、ＩＰ層にセキュリティを提供する目的で進展中である。しかし、現行の標準を用いてセキュリティと移動性を両方とも実現することはかなり難しいということが、経験から分っている。
ＩＰアドレスは、ネットワーク内でのノードのトポロジ的な位置を記述する。ＩＰアドレスは、発信元ノードから着信先へとパケットをルーティングするのに用いられる。同時に、ＩＰアドレスは、ノードを識別するのにも用いられ、１つの存在でありながら２つの異なる機能を提供する。これは、人が「あなたは誰か」と問われたとき、自宅の住所を答えるのに似ている。移動性についても考慮される場合、状況は一層複雑になる。ＩＰアドレスはこの枠組みにおいてはホスト識別子として機能するため、それらは変更されてはならない。しかし、ＩＰアドレスはトポロジ的な位置も記述しているため、ホストがネットワーク内で自分の位置を変える場合にはＩＰアドレスも必然的に変わらなければならない。安定性と動的変化とを同時に達成するのは、明らかに不可能である。
モバイルＩＰの場合の解決策は、固定されたホーム位置を用いて、ノードの「ホームアドレス」を提供することである。ホームアドレスは、ノードを識別し、ノードがホームにある場合にはノードの安定位置を提供する。現在位置情報は、気付アドレスの形で利用可能であり、気付アドレスは、ノードがホームから離れている場合にルーティングするために用いられる。
この問題に対するもう１つの解決策は、識別機能と位置機能とを互いに分離することであり、これは、ホスト・アイデンティティ・プロトコル（ＨＩＰ）提案（R. Moskowitz, P. Nikander, P. Jokela, "Host Identity Protocol", Internet Draft, 作業中, draft-ietf-hip-base-01, IETF, 2004）で取られている手法である。ＨＩＰは、ホスト・アイデンティティ（ＨＩ）という新たな名前スペースを導入することによって、ＩＰアドレスの位置の役割と識別の役割とを分離する。ＨＩＰにおいては、ホスト・アイデンティティは、基本的に公開鍵−秘密鍵ペアのうちの公開暗号鍵であって、秘密鍵から生成されて秘密鍵にリンクされている。公開鍵は、秘密鍵の唯一のコピーを保持する当事者を識別する。鍵ペアのうちの秘密鍵を所有するホストは、ネットワーク内で自分を識別するのに用いられる公開鍵を自分が「所有している」ことを直接証明することができる。また、分離することで、移動性とマルチホーミングとをセキュアな方法で扱う手段が得られる。
下記において、ＨＩＰについてさらに詳細に論ずるが、ＨＩＰは、位置と識別の分離という構想に基づく唯一の提案というわけではない。ＦＡＲＡ（D. Clark, R. Braden, A. Falk, V. Pingali, "FARA: Reorganizing the Addressing Architecture", ACM SIGCOMM 2003 Workshops, August 25 & 27, 2003）は、実際のアーキテクチャを導出可能な枠組みを提供するアイデアを一般化したモデルである。ＦＡＲＡは、ノードの識別が実証される場合にはＨＩＰを利用することができるであろうし、従って、ＨＩＰは特定のＦＡＲＡインスタンス化の一部で有り得る。また、ＰｅｅｒＮｅｔ提案（J. Eriksson, M. Faloutsos, S. Krishnamurthy, "PeerNet: Pushing Peer-to-Peer Down the Stack", IPTPS '03, February 20-21, 2003）も、位置と識別の分離について論じている。インターネット・インダイレクション・インフラストラクチャ（Ｉ３）（I. Stoica, et.al., "Internet Indirection Infrastructure", ACM SIGCOMM '02, August 19-23, 2002）も、識別とルーティング情報の分離について定義している。
ホスト・アイデンティティ・プロトコルは、ＩＰ層において位置と識別情報間の分離を導入する。分離に加えて、ＨＩＰが使用可能なノード間でセキュリティアソシエーション（ＳＡ）を交渉するようにプロトコルが定義される。
ＨＩＰでは、各ホストは、ネットワーク内で各ホストを識別するのに使用できる１つ以上のアイデンティティを有し、それらは、長期であってもよいし短期であってもよい。ＨＩＰでは、識別子は、公開鍵−秘密鍵ペアのうちの公開鍵である。ホストが秘密鍵を所有する場合、ホストは自分が実際に、公開鍵が表すこのアイデンティティを「所有する」ことを証明することができ、これはＩＤカードを提示するのに似ている。
各ホストは、短期間だけ使用可能な短期鍵を生成することができる。これらは、ノードがそれ以降同じアイデンティティで識別される必要がない場合に、有益である。例えば、書店から本を購入することは、長期の関係であってもよいが、他方、ユーザプロフィールを収集する目的でサーバに一度コンタクトすることは、短期の行動であるとみなされてもよい。後者の場合、長期アイデンティティの広範な拡散を避けるため、短期ＩＤが作成されてもよい。
ＨＩＰホスト・アイデンティティ（ＨＩ）は、公開鍵であり、かなり長いものである可能性があるため、すべての状況において実用的というわけではない。ＨＩＰでは、ＨＩは、ＨＩ自身をハッシュでて生成される１２８ビットの長さのホスト・アイデンティティ・タグ（ＨＩＴ）で表される。このようにして、ＨＩＴがＨＩを識別する。ＨＩＴは１２８ビットの長さであるため、ＩＰｖ６アドレスと全く同じ長さであることから、ＨＩＴはＩＰｖ６アプリケーションに直接使用されうる。
ホスト・アイデンティティのもう１つの表現は、ローカル・スコープ識別子（ＬＳＩ）であり、これはホスト・アイデンティティの３２ビット表現である。ＬＳＩの目的は、既存のプロトコルおよびＡＰＩにおけるホスト・アイデンティティの使用を円滑化することである。例えば、ＬＳＩは、ＩＰｖ４と同じ長さであるため、直接ＩＰｖ４アプリケーションとして使用されてもよい。本明細書の残りの記述の多くは、長いＨＩＴの使用に関して行われることになるが、同様のもしくは類似の考察は、別の選択肢のＬＳＩ表現にも適用されることは理解されるはずである。
ＨＩＰが使用される場合、アプリケーションを含む上位層は、もはやＩＰアドレスを見ない。代わりに、それらは、ＨＩＴを着信先ホストの「アドレス」として見る。位置情報は、下記に述べることになる、新規の層に隠される。ＩＰアドレスは、もはやノードを識別せず、それらはネットワーク内のパケットをルーティングするのに使用されるにすぎない。
アプリケーションは、通常、位置情報には関心を持たないが、それらのピアのアイデンティティを知る必要は確かにある。アイデンティティはＨＩＴによって表される。これは、ルーティングに関する限り、ＩＰアドレスが重要性を持つのは下位層に対してのみであることを意味する。アプリケーションが用いるＨＩＴは、いかなるパケットであろうとそのパケットがホストを出発する前に、対応するＩＰアドレスにマップされていなければならない。これは、下記のとおり、新規のホスト・アイデンティティ層において達成される。
添付の図面の図１は、標準のトランスポート層４、ネットワーク層８、およびリンク層１０を含む、ＨＩＰにおける各種の層を示しており、また、その下のトランスポート層４と交信するプロセス２も含む。ＨＩＰでは、新規のホスト・アイデンティティ層６が、トランスポート層４とネットワーク層８との間に配置されている。
ローカルには、各ＨＩ、およびその関連するＨＩＴは、ノードのＩＰアドレスにマップされる。パケットがホストを出発するとき、（どんな手段を用いてもよいが）正しいルートが選択され、対応するＩＰアドレスが発信元および着信先アドレスとしてパケットの中に入れられる。上位層から到着する各パケットは、着信先アドレスとして、ピアのＨＩＴを含む。ＨＩＴと位置情報との間のマッピングは、ＨＩ層６で見つけることができる。従って、着信先アドレスは、マップされたＩＰアドレスへと変換され、発信元ＨＩＴは発信元ＩＰアドレスへと変換される。
ピアＨＩＴとＩＰアドレスの間のマッピングは、複数の方法が検索できるが、その１つは、ＤＮＳサーバからである。位置情報は、ピアノードによって、いつでも更新されてよい。更新手順については、移動管理の部分でもっと詳細に論じることになろう。
ＨＩＰは、４個のメッセージ、すなわち４ウェイ・ハンドシェイクを含む基本的なメッセージ交換を定義し、これはＨＩＰが使用可能なホスト間のセキュリティ・アソシエーション（ＳＡ）を作成するのに使用される。メッセージ交換の間、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ手順を用いてセッション鍵が作成され、ノード間に、ＩＰｓｅｃのカプセル化セキュリティペイロード（ＥＳＰ）のペアが確立される。
添付図面の図２は、４ウェイ・ハンドシェイクの動作を示す図である。交渉中の当事者は、接続を開始する「イニシエータ」と「レスポンダ」と呼ばれる。「イニシエータ」は、交渉に参加しているノードのＨＩＴを含むＩ１パケットを送ることによって交渉を開始する。「レスポンダ」のＨＩＴが「イニシエータ」には分らない場合、着信先ＨＩＴもゼロにされてもよい。
「レスポンダ」は、Ｉ１パケットを受け取ると、「イニシエータ」によって解決されるべきパズルを含むＲ１パケットを返送する。プロトコルは、パズルを解く間、計算の大半を「イニシエータ」が行わなければならないように設計されている。これによって、ＤｏＳ攻撃に対する保護が幾分与えられる。Ｒ１も、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎパラメータと共に「レスポンダ」の公開鍵を含む、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ手順を開始する。
一旦Ｒ１パケットが受信されると、「イニシエータ」はパズルを解き、ＩＰｓｅｃＳＰＩ値およびその暗号化された公開鍵と共に、Ｉ２パケットの中で応答クッキーを「レスポンダ」へと送信する。「レスポンダ」は、パズルが解かれたことを検証し、「イニシエータ」を認証し、ＩＰｓｅｃのＥＳＰ ＳＡを作成する。最後のＲ２メッセージは、「レスポンダ」のＳＰＩ値を含む。
ホスト間のＳＡは、ＨＩＴによって表されるホスト・アイデンティティに結び付けられる。しかし、ネットワーク内を進むパケットが実際のＨＩ情報を含むのではなく、ＩＰｓｅｃヘッダ内のセキュリティ・パラメータ・インデックス（ＳＰＩ）を用いて、到着するパケットが識別され、正しいＳＡにマップされる。添付図面の図３は、パケットがネットワーク内を進むときの、論理的パケット構造および実際のパケット構造を示す図である。
上記から、パケット内で位置情報を変更しても、ＩＰｓｅｃ処理については何の問題も起こらないということが明らかである。パケットは、ＳＰＩを用いて、依然として正しく識別される。もし何かの理由で、パケットが間違った着信先にルーティングされた場合でも、受け手は正しい鍵を持っていないため、パケットを開くことができない。
発信パケットが上位層からＨＩ層に到着するとき、着信先ＨＩＴがＩＰｓｅｃＳＡＤＢから検証される。着信先ＨＩＴへ適合するＳＡが見つかった場合には、ＳＡに関連するセッション鍵を用いて、パケットが暗号化される。
ＨＩＴは、パケットをルーティングするのに使用することはできない。従って、着信先アドレス（および送信元アドレス）は、ノードのＩＰアドレスに適合するよう変更されなければならない。これらのマッピングは、前述のように、ＨＩ層に格納されている。アドレスが変更された後、パケットはネットワークへと送信されてもよく、パケットは、ネットワーク内でＩＰアドレス情報を用いて着信先へとルーティングされる。
受信側ホストでは、ＳＰＩ値を用いて、ＩＰｓｅｃＳＡＤＢから正しいＳＡを見つける。エントリが見つかった場合、ＩＰアドレスは対応するＨＩＴへと変更されてもよく、パケットはセッション鍵を用いて暗号化されてもよい。
移動性とは、ホストが通信コンテクストをアクティブに維持したままで移動する状況、言い換えれば、ホストが既存の接続をすべてアクティブに維持しながら、ＩＰアドレスによって記述されるそのトポロジ的な位置を変更する状況であると定義される。ホスト上で実行されているプロセスは、サービス品質の変化を体験する場合の可能性を除いて、移動性を実感しない。
モバイルホストは、１つのアクセスネットワーク内で位置を変えてもよいし、異なるアクセス技術間で、あるいは、例えば、ＩＰｖ４とＩＰｖ６ネットワーク間でというように、異なるＩＰアドレス領域間でさえ、位置を変えてもよい。ＨＩＰにおいては、アプリケーションは、ＩＰアドレスバージョンの変化に気づかない。ＨＩ層は、変化を上位層から完全に隠す。もちろん、ピアノードは、ＩＰバージョンを変更するような位置の更新を処理することが可能でなければならないし、パケットは、何らかの互換性を持つアドレスを用いてルーティングが可能でなければならない。ノードがＩＰｖ４とＩＰｖ６の両方の接続性を有していない場合、そのノードは、アドレスバージョン変換を実行してノードの代わりに接続性を提供するプロキシノードを使用してもよい。
マルチホーミングとは、エンドポイントが、自分が使用できる複数の並列通信パスを有する状況のことをいう。マルチホーミングは、通常、ホストが複数のネットワークインタフェースを有するか（エンドホスト・マルチホーミング）、あるいは、ホストと冗長パスを有するネットワークの残余との間のネットワークに因るものか（サイト・マルチホーミング）のいずれかの結果である。
ＨＩＰでは、位置情報と識別情報の分離によって、パケットの識別とルーティングが互いからきれいに分離されうることが明確になる。パケットを受信するホストは、最初に正しい鍵を入手し、次いでパケットを復号化することによって、送信者を識別する。このように、パケット内にあるＩＰアドレスは、無関係である。
ＨＩＰ移動ノード（ＨＭＮ）は、ネットワーク内を移動するため、インターネットへの接続点を絶えず変更する可能性がある。接続点が変更されると、ＩＰアドレスも変更される。このような位置変更情報はピアノード、すなわち、ＨＩＰ対向ノード（ＨＣＮ）へと送信されなければならず、これは添付図面の図４に示されている。同じアドレスが、より安定した点を経由してＨＭＮに到着できるように、ＨＭＮの転送エージェント（ＦＡ）にも送信されてよい。ＤＮＳシステムは、常に変化する位置情報について使用するには、遅すぎる。従って、ＨＭＮにコンタクトをとるのに使用できる、より安定したアドレスが必要である。このアドレスとは、ＦＡによって提供されるアドレスである。
ＨＩＰモビリティおよびマルチホーミング・プロトコル（P. Nikander, J. Arkko, P. Jokela, "End-Host Mobility and Multihoming with Host Identity Protocol", Internet Draft, 作業中, draft-ietf-hip-mm-00, IETF, 2004）は、ＨＭＮの現行ＩＰアドレスを含む再アドレス（ＲＥＡ）パラメータを搬送する、更新（ＵＰＤＡＴＥ）パケットを定義する。ＨＭＮは、位置およびＩＰアドレスを変更する場合、ＵＰＤＡＴＥパケットを生成し、使用されるＨＩに適合する秘密鍵を使ってパケットに署名し、そして、パケットをピアノードおよびＦＡへと送信する。
ピアノードは、ＵＰＤＡＴＥパケットを受信すると、ＵＰＤＡＴＥパケットの中に含まれるＩＰアドレスについてのアドレス検証プロセスを開始しなければならない。アドレス検証は、ＨＭＮから不正な更新を受け取るのを避けるために必要である。ピアノードは、ＵＰＤＡＴＥパケットの中にあったアドレスに、更新応答（ＵＰＤＡＴＥ−ＡＣＫ）パケットを送信する。ＨＭＮは、先に送信したＵＰＤＡＴＥに適合するＵＰＤＡＴＥ−ＡＣＫを受信すると、ＨＣＮへとデータを送信するため新しいＩＰアドレスの使用を開始してもよい。ピアノードが新たなアドレスから第１のデータパケットを受信した後で、アドレスの検証は完了し、ピアノードは、そのＩＰアドレスをＨＭＮの位置情報として追加できる。
ＨＭＮはさまざまなＩＰアドレスバージョンを用いてネットワーク間を移動できるため、ＨＣＮによって受信されたアドレスもまた、以前のアドレスとは異なるアドレス群からのものであってもよい。
ＨＣＮは、ＩＰアドレスバージョンを１つだけサポートしてもよい。この場合、ＨＣＮは、他のＩＰアドレスバージョンのネットワークへパケットをルーティングするのに使える、何か他のプロキシノードを使用しなければならない。
さまざまなアクセスネットワークに接続されたさまざまなインタフェース上で構成された複数のＩＰアドレスを有する、マルチホームのＨＩＰホストは、ピアノードに向かうトラフィックを処理する可能性が一層高い。ネットワーク内での自分の現在位置を表す複数のＩＰアドレスを有していることから、自分のピアノードにこれらのアドレスをすべて告げたくなる可能性もある。それを行うために、マルチホームのＨＩＰノードは、その特定のノードに向かって使用できるすべてのアドレスを含む、ＵＰＤＡＴＥパケットを作成する。このアドレスの集合は、マルチホームのＨＩＰノードが持つすべてのアドレスを含んでもよいし、これらのアドレスのうちの一部の下位集合を含んでもよい。ピアノードは、複数のアドレスを持つＵＰＤＡＴＥパケットを受け取ると、起こる可能性のある誤った更新を避けるため、これらのアドレスの各々についてアドレスの検証を行わなければならない。
ＨＭＮが不正ノードである、スタックの実装にエラーがあったり、または、インターネット内でのルーティングが不可能なプライベートアドレスを用いるネットワーク内にＨＭＮがあったりすることが原因となって、ＵＰＤＡＴＥパケット内に不正の、もしくは、ルーティング不能なアドレスが生じることがある。
マルチホームのＨＩＰノードは、利用可能な接続をすべて使用することができるが、接続を効率的に使用するには、基礎を成すアクセスネットワークの知識を有し、それらの利用を制御する、ポリシーシステムが必要である。そのようなポリシーシステムは、ユーザ選択、オペレータ選択、ＱｏＳなどのネットワーク接続からの入力など、さまざまな種類の情報を使用してもよい。
移動ノードとのＨＩＰ交換を開始するため、イニシエータノードは、移動ノードに到達する方法を知る必要がある。移動頻度の低いノードについては、この機能のためにダイナミックＤＮＳを使うこともできるであろうが、ＤＮＳをこの方法で使用することの代替案は、前述の静的インフラの一部、すなわち、転送エージェント（ＨＩＰランデブーサーバと呼ばれることもある）を使用することである。ＤＮＳサーバに現在の動的アドレスを登録する代わりに、移動ノードは自分の転送エージェントのアドレスを登録する。移動ノードは、自分の現在ＩＰアドレスを使って、転送ノードを連続的に更新し続ける。転送エージェントは、最初のＨＩＰパケットをイニシエータから現在の位置にある移動ノードへと、単純に転送する。さらなるパケットはすべて、イニシエータから移動ノードへと流れる。一般に、転送エージェントの動作は、非常に少なく、主としてアドレスの更新と最初のＨＩＰパケットの転送である。従って、１つの転送エージェントが多数の潜在的移動ノードをサポートしてもよい。移動ノードは、転送エージェントを信頼して、それらのＨＩＴおよびＩＰアドレスマッピングを適切に維持しなければならない。転送エージェントは、位置が固定されているノードでさえ使用されてもよいが、それは、固定ノードもＩＰアドレスを頻繁に変更する可能性がある場合が多いからであり、例えば、サービスプロバイダによってインターネット接続が設定されるたびにそのノードにＩＰアドレスが割当てられる場合などがそれに該当する。
また転送エージェントは、両方のノードが移動ノードであって、偶然、同時に移動する場合にも必要である。その場合、ＨＩＰ再アドレスパケットは、ネットワーク内で交錯し、ピアノードには決して達しないであろう。この状況を解決するため、ノードは転送エージェントのアドレスを記憶しておき、応答がない場合には、ＨＩＰ再アドレスパケットを転送エージェントへ再送信すべきである。
移動ノードは、転送エージェントとのＨＩＰアソシエーションを設定し、再アドレスを含んでいるＨＩＰ更新パケットをそれへと送信することによって、転送エージェント上で自分のアドレスを最新なものに維持する。転送エージェントは、２つの移動システムが、ＤＮＳを含めて（転送エージェント自身以外に）付加的なインフラが何もなくても、それらが相互のＨＩおよびＨＩＴを入手する方法をＤＮＳクエリ以外に有する場合には、ＨＩＰを使用するのを許可するであろう。
レガシー機器の場合、ホストはＨＩＰが使用可能ではない可能性があり、唯一の選択肢は、ＩＰアドレスを用いてホスト間の接続を識別することである。これはセキュアではない。ＨＩＰが使用可能なホストとＨＩＰを使用できないホストの間にＨＩＰプロキシを設置することによって、この状況が改善される可能性がある。典型的なシナリオは、クライアント端末がＨＩＰ使用可能ではないような小規模な企業ＬＡＮであろう。トラフィックは、ＨＩＰプロキシを経由して、（ＨＩＰが使用可能な）対向ホストへルーティングされる。
この構成を、添付図面の図５に示す。図５において、レガシーホスト１２（「ｈｉｐ．ｆｏｏ．ｃｏｍ」というドメイン名を有する）が、ＨＩＰ使用可能ノード１４と、ＨＩＰプロキシ１６を経由して通信している様子を示す。レガシーホスト１２は、ＨＩＰプロキシ１６がインターネット２０上でＨＩＰノード１４にアクセスする間、アクセスネットワーク１８上でＨＩＰプロキシ１６にアクセスする。レガシーホスト１２とＨＩＰノード１４の間の接続を部分的に保護するため、ＨＩＰプロキシ１６とＨＩＰノード１４の間のすべての通信は、図３を参照しながら上述した方法と同様の方法で、ＨＩＰプロキシ１６とＨＩＰノード１４の間で設定されたセキュリティアソシエーションを通じて行われる。
しかし、レガシーホスト１２とＨＩＰノード１４の間の通信を可能にするため図５に示すセキュリティアソシエーションが設定される前であっても、ＨＩＰノード１４が上述のように転送エージェント２６の後ろに位置している場合には、レガシーホスト１２が、ＤＮＳサーバ２４−１に（そして、次にはＤＮＳサーバ２４−２に）クエリを送ることによってＨＩＰノード１４のＩＰアドレスを解決しようとするとき、問題が発生する。ＤＮＳサーバ２４−１は、転送エージェント２６のＩＰアドレスと一緒に、ＨＩＰノード１４のＨＩＴを返送する。レガシーホスト１２は、ＨＩＰが使用可能ではないため、ＨＩＴを無視して転送エージェント２６へのメッセージの送信を開始するであろう。複数のＨＩＰノードが同じ転送エージェント２６を使用する可能性が高いことから、ＨＩＴがなければ、転送エージェント２６はこれらのメッセージの着信先アドレスを解明することができないであろう。同様に、レガシーホスト１２は、ＨＩＴを廃棄し、接続を開始するときにはＨＩＰノード１４のＩＰアドレスのみを使用することから、ＨＩＰプロキシ１６は、ＨＩＰノード１４のＨＩＴを知らないため、自分自身とＨＩＰノード１４との間のＨＩＰ交渉を開始することができない。この問題は、本願出願人らのＰＣＴ出願番号ＰＣＴ／ＥＰ０４／０５０１２９の中で取り上げられている。
そのほか、第３世代（３Ｇ）移動体通信ネットワークにＨＩＰを実装する場合にも、３Ｇ環境のユーザ装置（ＵＥ）のすべてがＨＩＰ使用可能というわけではないため、技術的検討事項が発生する。このコンテクストにおいて、ユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）は、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ）の３Ｇ後継システムである。ＵＭＴＳへ向けてのＧＳＭの最も重要な革新的ステップは、汎用パケット無線サービス（ＧＰＲＳ）である。ＧＰＲＳは、ＧＳＭコアネットワークにパケット交換を導入し、パケット・データ・ネットワーク（ＰＤＮ）への直接アクセスを可能にする。これによって、ＧＳＭコアネットワークによるＩＳＤＮの６４ｋｂｐｓという限界を大幅に超える、高速のデータ転送速度によるパケット交換送信が可能になるが、それは最大２ＭｂｐｓのＵＭＴＳデータ転送速度には必要不可欠である。ＧＰＲＳは、ＵＭＴＳ導入の前提条件なのである。
ＵＭＴＳもしくはＧＰＲＳのような１つのネットワーク環境で動作するレガシーホストと、インターネットのようなもう１つのネットワーク環境で動作するＨＩＰが使用可能なホストとの間の通信のために、上述のホスト・アイデンティティ・プロトコルの利点の少なくとも一部を提供することが望ましい。
本発明の第１の態様によって、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を用いて、第１のホストはＨＩＰ使用可能でなく、第２のホストはＨＩＰ使用可能である場合の第１のホストと第２のホストの間の通信を少なくとも部分的に保護する方法が提供されており、前記方法は、リモートサーバで維持される持続的ＨＩＰアイデンティティに第１のホストを関連付けることと、持続的ＨＩＰアイデンティティの公開部分と、第１のホストと第２のホストとの間のゲートウェイノードが、第１のホストに関連付けられた一時的ＨＩＰアイデンティティを後続の交渉するステップで使用することを承認する証明書とを、前記リモートサーバから取得することと、そして、持続的ＨＩＰアイデンティティと一時的ＨＩＰアイデンティティと証明書とのそれぞれのうち少なくとも一部を用いて、ゲートウェイノードと第２のホストとの間のセキュアなＨＩＰ接続を交渉することとを、含む。
取得するステップは、一時的ＨＩＰアイデンティティの公開部分をリモートサーバへ送信することを含んでもよい。
取得するステップは、一時的ＨＩＰアイデンティティの公開部分を証明書の中に含めることを含んでもよい。
取得するステップは、持続的ＨＩＰアイデンティティの秘密鍵部分を用いてリモートサーバで証明書に署名することを含んでもよい。
取得するステップは、証明書をゲートウェイノードへ送信することを含んでもよい。
公開部分は、持続的ＨＩＰアイデンティティの公開鍵部分であってもよい。
交渉するステップは、少なくとも１つのパケットをゲートウェイノードから第２のホストへ送信することを含み、前記少なくとも１つのパケットは、一時的ＨＩＰアイデンティティの秘密鍵部分を用いて署名されてもよい。
交渉するステップは、証明書をゲートウェイノードから第２のホストへ送信することを含んでもよい。
交渉するステップは、持続的ＨＩＰアイデンティティの公開部分をゲートウェイノードから第２のホストへ送信することを含んでもよい。
持続的ＨＩＰアイデンティティの公開部分は、証明書と同じパケットの中で送信されてもよい。
証明書は、交渉するステップの間にゲートウェイノードが一時的ＨＩＰアイデンティティを用いる権利を検証するため、第２のホストにおいて用いられてもよい。
持続的ＨＩＰアイデンティティの公開部分および証明書は、前記権利を検証するのに用いられてもよい。
持続的ＨＩＰアイデンティティのＨＩＰ公開識別子部分は、ゲートウェイと第２のホストとの間のＨＩＰ接続の交渉の間、ＨＩＰヘッダに含まれてもよい。
方法は、ゲートウェイノードにおいて一時的ＨＩＰアイデンティティを生成することを含んでもよい。
リモートサーバは、前記取得するステップの間、第１のホストとゲートウェイノードとの間の在圏ノードと通信してもよい。
取得するステップは、一時的ＨＩＰアイデンティティの公開部分をゲートウェイノードから在圏ノードへ送信することを含んでもよい。
在圏ノードは、在圏ＧＰＲＳサポートノード（ＳＧＳＮ）であってもよい。
方法は、第１のホストの位置に関連するＨＩＰランデブーサーバ内の情報を更新することを含んでもよい。
更新するステップは、取得するステップに応じて、もしくは取得するステップの間、リモートサーバによって実行されてもよい。
ＨＩＰランデブーサーバおよびリモートサーバは、単一のサーバとして提供されてもよい。
ＨＩＰランデブーサーバは、第１のホストのホームネットワーク内に位置してもよい。
ゲートウェイノードはＨＩＰプロキシの機能を提供してもよい。
ゲートウェイノードは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）であってもよい。
リモートサーバは、第１のホストのホームネットワーク内に位置してもよい。
リモートサーバは、認証サーバであってもよい。
方法は、新たなゲートウェイノードが第１のホストと第２のホスト間でアクティブになる場合、新たなゲートウェイノードと第２のホストの間の新たなセキュアなＨＩＰ接続を交渉するための基礎として、第１のホストについても同じ持続的ＨＩＰアイデンティティを用いることを含んでもよい。
方法は、第１のホストから第２のホストへの後続の通信に含まれている第２のホストのためのＨＩＰ公開識別子に基づいて、第２のホストを見つけるため、新たなゲートウェイノードで検索プロセスを用いることを含んでもよい。
方法は、前のセキュアなＨＩＰ接続を中断することを含んでもよい。
本発明の第２の態様によって、ホスト・アイデンティティ・プロトコル（ＨＩＰ）の方法が提供されるが、この方法は、ＨＩＰ使用可能でないホストが複数のゲートウェイノードを次々に経由してＨＩＰ使用可能ホストと通信するようなネットワーク内で用いられる方法であって、方法は、そのような使用されるゲートウェイノードの各々について、リモートサーバで維持される、第１のホストのための持続的ＨＩＰアイデンティティを用いることを含む。
本発明の第３の態様によって、通信システムが提供されるが、この通信システムは、第１のホストはホスト・アイデンティティ・プロトコル（ＨＩＰ）使用可能でなく、第２のホストはＨＩＰ使用可能であるような第１および第２のホストと、第１ホストと第２ホストの間のゲートウェイノードと、第１のホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバと、セキュアなＨＩＰ接続について交渉するために、持続的ＨＩＰアイデンティティの公開部分と第１のホストに関連付けられた一時的ＨＩＰアイデンティティをゲートウェイノードが使用することを承認する証明書とをリモートサーバから取得する手段と、ゲートウェイノードと第２のホストとの間で、持続的ＨＩＰアイデンティティと一時的ＨＩＰアイデンティティと証明書の各々のうちの少なくとも一部を用いてセキュアなＨＩＰ接続について交渉し、それによって少なくとも部分的に第１のホストと第２のホストとの間の通信をホスト・アイデンティティ・プロトコルを用いて保護する手段とを含む。
本発明の第４の態様によって、ネットワークの在圏ノードによって使用される方法が提供されるが、この方法は、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を用いて、ネットワークの第１ホストと第２ホストの間の通信が、第１のホストはＨＩＰ使用可能でなく第２のホストはＨＩＰ使用可能である場合に、少なくとも部分的に保護されることを可能にする方法であって、ここで、ネットワークは、第１のホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバを含み、そして方法は、持続的ＨＩＰアイデンティティと一時的ＨＩＰアイデンティティと証明書との各々のうち少なくとも一部を用いてゲートウェイノードと第２のホストとの間のセキュアなＨＩＰ接続について交渉するため、持続的ＨＩＰアイデンティティの公開部分と、第１ホストと第２ホストの間のネットワークのゲートウェイノードが、第１のホストに関連付けられた一時的ＨＩＰアイデンティティを後続のステップで使用することを承認する証明書とを、リモートサーバから取得することを含む。
本発明の第５の態様によって、ネットワークの在圏ノードとして使用される装置が提供されるが、この装置は、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を用いて、ネットワークの第１ホストと第２ホストの間の通信が、第１のホストはＨＩＰ使用可能でなく第２のホストはＨＩＰ使用可能である場合に、少なくとも部分的に保護されることを可能にする装置であって、ここで、ネットワークは、第１のホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバを含み、そして装置は、持続的ＨＩＰアイデンティティと一時的ＨＩＰアイデンティティと証明書との各々のうち少なくとも一部を用いてゲートウェイノードと第２のホストとの間のセキュアなＨＩＰ接続について交渉するため、持続的ＨＩＰアイデンティティの公開部分と、第１ホストと第２ホストの間のネットワークのゲートウェイノードが、第１のホストに関連付けられた一時的ＨＩＰアイデンティティを後続のステップで使用することを承認する証明書とを、リモートサーバから取得する手段を含む。
本発明の第６の態様によって、ネットワークの第１ホストと第２ホストの間のゲートウェイノードによって使用される方法が提供されるが、この方法は、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を用いて、第１ホストと第２ホストの間の通信が、第１のホストはＨＩＰ使用可能でなく第２のホストはＨＩＰ使用可能である場合に、少なくとも部分的に保護されることを可能にする方法であって、ここで、ネットワークは、第１のホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバと、持続的ＨＩＰアイデンティティの公開部分と第１のホストに関連付けられた一時的ＨＩＰアイデンティティをゲートウェイノードが使用することを承認する証明書とを、前記リモートサーバから取得する手段とを含み、そして方法は、持続的ＨＩＰアイデンティティと一時的ＨＩＰアイデンティティと証明書との各々のうち少なくとも一部を用いてゲートウェイノードと第２のホストとの間のセキュアなＨＩＰ接続について交渉することを含む。
本発明の第７の態様によって、ネットワークの第１ホストと第２ホストの間のゲートウェイノードとして使用される装置が提供されるが、この装置は、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を用いて、第１ホストと第２ホストの間の通信が、第１のホストはＨＩＰ使用可能でなく第２のホストはＨＩＰ使用可能である場合に、少なくとも部分的に保護されることを可能にする装置であって、ここで、ネットワークは、第１のホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバと、持続的ＨＩＰアイデンティティの公開部分と第１のホストに関連付けられた一時的ＨＩＰアイデンティティを装置が使用することを承認する証明書とを、前記リモートサーバから取得する手段とを含み、そして装置は、持続的ＨＩＰアイデンティティと一時的ＨＩＰアイデンティティと証明書との各々のうち少なくとも一部を用いて装置と第２のホストとの間のセキュアなＨＩＰ接続について交渉する手段を含む。
本発明の第８の態様によって、オペレーティング・プログラムが提供されるが、このプログラムが装置上で実行されると、装置ノードが、本発明の第４もしくは第６の態様による方法を実行することになる。
本発明の第９の態様によって、オペレーティング・プログラムが提供されるが、このプログラムが装置にロードされると、装置が、本発明の第５もしくは第７の態様による装置になることになる。
オペレーティング・プログラムは、搬送媒体で搬送されてもよい。搬送媒体は、送信媒体であってもよい。搬送媒体は記憶媒体であってもよい。
本発明の文脈において、ＨＩＰアイデンティティは、ＨＩＰ鍵ペアを含み、それ自体はＨＩＰ公開鍵とＨＩＰ秘密鍵とを含む。ＨＩＰアイデンティティの中では、別のＨＩＰ公開識別子がＨＩＰ公開鍵と関連付けられており、これは例えば、上述のホスト・アイデンティティ・タグ（ＨＩＴ）もしくはローカル・スコープ識別子（ＬＳＩ）であってもよい。ＨＩＰアイデンティティの公開部分は、ＨＩＰ公開鍵もしくはＨＩＰ公開識別子のいずれか、または両方である。ＨＩＰ公開識別子は、必要に応じてＨＩＰ公開鍵から生成されてもよい。
本発明の実施形態について、図６に示すＧＰＲＳ／ＵＭＴＳネットワーク・アーキテクチャの枠組みの中でこれから説明しよう。本発明の実施形態の基礎を成す原理は、ＧＰＲＳに適用可能であるのと同様にＵＭＴＳにも適用可能である。
上記のとおり、ＧＰＲＳは既存のＧＳＭネットワークインフラの延長としてデザインされたものであり、コネクションレス・パケット・データ・サービスを提供することを目的としている。下記に述べるように、ＧＰＲＳは、ＧＳＭに複数の新機能要素を導入したもので、ＩＰベースのパケットデータのエンド・ツー・エンドの転送を支援するものである。
図６に示す通信システム１００は、基地局（ＢＴＳ）１０４と通信する移動局（ＭＳ）１０２を含み、基地局は次に基地局制御装置（ＢＳＣ）１０６と通信する。ＢＴＳ１０４とＢＳＣ１０６は、一緒に基地局サブシステム（ＢＳＳ）を構成する。ＢＳＣ１０６において、パケット制御ユニット（ＰＣＵ、図示していない）が、電話ネットワーク１１０を着信先とする回線交換データと、パケットデータネットワーク１２０を着信先とするパケット交換データとを区別する。電話ネットワーク１１０は、例えば、公衆電話交換網またはＩＳＤＮであってもよいし、他方、パケットデータネットワークは、例えば、パケット交換公衆データ網、インターネット、または企業ＬＡＮであってもよい。
回線交換データは、ビジター・ロケーション・レジスタ（ＶＬＲ）を内蔵する移動交換センタ（ＭＳＣ）を経由して、電話ネットワーク１１０へとルーティングされる。他方、パケット交換データは、在圏ＧＰＲＳサポートノード（ＳＧＳＮ）１１２およびゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１１４を経由してパケットデータネットワーク１２０へとルーティングされる。ＭＳＣ１０８、ＳＧＳＮ１１２およびＧＧＳＮ１１４は、例えば、加入者に関するサービス、アカウントステータス情報、設定、ＩＰアドレスなどのような加入者情報を含むデータベースである、ホーム・ロケーション・レジスタ（ＨＬＲ）１１６へのアクセスを有する。図６には、ドメイン名システム（ＤＮＳ）サーバ１１８が、パケットデータネットワーク１２０を通じてアクセス可能であることを示す。また、パケットデータネットワーク１２０に接続されたホスト１２２も示す。
標準のＧＳＭネットワークに加えてＧＰＲＳには、２つの主な新しいコアネットワーク要素、すなわちＳＧＳＮ１１２とＧＧＳＮ１１４とが導入される。ＳＧＳＮ１１２は、移動局１０２の状態を監視し、所与の地理的エリア内でその動きを追跡する。また、移動ユーザと着信先ネットワークの間のデータ接続を確立し管理することにも責任を持つ。異なるＳＧＳＮによって管理されるネットワークのセグメントにユーザが侵入する場合、新たなＳＧＳＮへのハンドオフを行う。
ＧＧＳＮ１１４は、ＧＰＲＳネットワーク環境と、インターネットや企業のイントラネットのような、外部パケットデータネットワーク環境１２０の間の接続点を提供する。外部ネットワーク１２０の各々は、独自のアクセスポイント名（ＡＰＮ）を与えられ、それは必要な着信先ネットワークへの接続を確立するため移動ユーザによって使用される。さらなる情報は、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇから入手できるＧＰＲＳおよびＵＭＴＳの技術仕様から得られる。
移動局１０２は、ＧＰＲＳ接続手順を用いてＧＰＲＳネットワークのＳＧＳＮ１１２に登録してからでなければ、ＧＰＲＳサービスを使用できない。接続手順の間、ネットワークは、ユーザが承認されているのかを確認し、ＨＬＲ１１６からＳＧＳＮ１１２へユーザプロフィールをコピーし、そして、パケット一時移動加入者ＩＤ（Ｐ−ＴＭＳＩ）をユーザに割当てる。移動局１０２がすでにＳＧＳＮ１１２に接続されていた場合、更新位置メッセージが、新たなＳＧＳＮ１１２を考慮して位置更新プロセスを実行する、適切なＨＬＲ１１６へと送信される。ＧＰＲＳ接続手順に関する詳細情報は、ＧＰＲＳ技術仕様3GPP TS 23.060 V6.3.0(2003-12)のセクション６．５に記載されている。ＧＰＲＳネットワークからの切断は、ＧＰＲＳデタッチと呼ばれる。切断は、移動局もしくはネットワーク（ＳＧＳＮ１１２もしくはＨＬＲ１１６）によって開始されてもよい。
接続手順を完了した時点で、ネットワークは（それに続く位置更新を介して）ＭＳ１０２を追跡することができるようになり、ユーザがアクセスを有するサービスとネットワークとが認識される。しかし、この時点では、ユーザはパケットデータネットワークとのデータの送受信ができない。ＧＰＲＳ接続が成功した後でパケットデータネットワーク１２０とデータパケットを交換するには、最初にパケットデータプロトコル（ＰＤＰ）コンテクストを起動しなければならない。
ＨＩＰプロトコルのない従来技術のＧＰＲＳシステムにおいて、ＧＰＲＳ接続が成功した後で外部パケットデータネットワークとデータパケットを交換するには、移動局は、パケットデータネットワーク内で１つ以上のアドレスを用いなければならず、例えばパケットデータネットワークがＩＰネットワークである場合には、それはＩＰアドレスである。このアドレスはＰＤＰアドレスと呼ばれる。各セッションについて、ＰＤＰコンテクストが作成されるが、これはセッションの特徴を記述する。これには、ＰＤＰタイプ（例えばＩＰｖ４）、移動局に割り当てられたＰＤＰアドレス、要求されたサービス品質（ＱｏＳ）、そして、パケットデータネットワークへのアクセスポイントとして機能するＧＧＳＮ１１４のアドレスが含まれる。このコンテクストは、移動局１０２、ＳＧＳＮ１１２、そしてＧＧＳＮ１１４の中に記憶される。アクティブＰＤＰコンテクストならば、移動局１０２は外部パケットデータネットワーク１２０には「可視」であり、データパケットを送受信することができる。ＰＤＰとＩＭＳＩ（国際移動電話加入者ＩＤ）という２つのアドレス間のマッピングによって、ＧＧＳＮ１１４は、データパケットを、パケットデータネットワーク１２０と移動局１０２の間で転送できる。
図７は、そのようなＰＤＰコンテクストの起動手順の一例を示す図である。ステップＳ１において、ＰＤＰコンテクスト起動要求が、ＭＳ１０２からＳＧＳＮ１１２へと送信される。ステップＳ２において、通常のセキュリティ機能（例えば、ユーザ認証）が実行される。アクセスが許可される場合、ＳＧＳＮ１１２は、ＰＤＰコンテクスト作成要求メッセージを、影響を受けたＧＧＳＮ１１４へと送信するであろう（ステップＳ３）。ＧＧＳＮ１１４は、自分のＰＤＰコンテクストテーブルの中に新たなエントリを作成し、それによって、ＧＧＳＮ１１４は、データパケットをＳＧＳＮ１１２と外部パケットデータネットワーク１２０との間にルーティングできる。次いでステップＳ４においてＧＧＳＮ１１４は、割当てられたＰＤＰアドレス、例えばＩＰｖ４アドレスを含むＰＤＰコンテクスト作成応答を、ＳＧＳＮ１１２へと返信する。ＳＧＳＮ１１２は、自分のＰＤＰコンテクストテーブルを更新し、ステップＳ５においてＰＤＰコンテクスト起動承認メッセージで、新規ＰＤＰコンテクストの起動をＭＳ１０２へ確認する。ＧＰＲＳのＰＤＰコンテクスト起動手順については、上記のＧＰＲＳ技術仕様のセクション９．２．２の中でさらに詳細に記述されており、また、（「トンネル管理メッセージ」と呼ばれる）上記のメッセージ交換については、ＵＭＴＳ／ＧＰＲＳ技術仕様ETSI TS 129.060 V5.8.0(2003-12)のセクション７．３の中でさらに詳細に記述されている。
本願出願人らのＰＣＴ出願番号ＰＣＴ／ＥＰ０４／０５０５３３は、上述のＰＤＰコンテクスト起動手順が依然として適用されるけれども、ＧＰＲＳネットワーク環境の中の移動局１０２とパケットデータネットワーク環境１２０の中のホスト１２２との間の通信がＨＩＰを用いて少なくとも部分的に保護されうるように修正されたシステムを開示する。上述のように、ネットワーク内のノードにＨＩＰサポートを提供するには、そのネットワーク環境で動作しているレガシー端末に、少なくとも部分的にＨＩＰの利点を提供するため、ＨＩＰプロキシが必要である。ＧＰＲＳネットワーク環境のコンテクストにおいて、ＰＣＴ出願番号ＰＣＴ／ＥＰ０４／０５０５３３は、図６のＧＧＳＮ１１４がＧＧＳＮ ＨＩＰプロキシ１１４であるようにＧＧＳＮ１１４の一部としてＨＩＰプロキシが提供されているシステムを開示する。
本発明の実施形態においても、この基本的手法は踏襲されているが、以下にさらに記述するような顕著な実装の違いがある。とはいえ、以前の手法の記述は、本発明の実施形態を理解するに当って有益であろう。
次に、ＰＣＴ出願番号ＰＣＴ／ＥＰ０４／０５０５３３で開示されたシステムについて、図８を参照しながらさらに詳細に記述するが、図８の中で、図６のホスト１２２は、ＨＩＰが使用可能なホスト１２２であり、移動局１０２はレガシー（ＨＩＰ使用可能でない）移動局１０２である。
図８は、第１のネットワーク環境（ＧＰＲＳネットワーク環境）で動作する第１のホスト（レガシーＭＳ１０２）と第２のネットワーク環境（パケットデータ交換ネットワーク環境）で動作する第２のホスト（ＨＩＰホスト１２２）との間の通信を少なくとも部分的に保護するためにホスト・アイデンティティ・プロトコルを使用する、ＰＣＴ出願番号ＰＣＴ／ＥＰ０４／０５０５３３で開示された方法を示す信号図である。ＧＧＳＮ ＨＩＰプロキシ１１４は、２つのネットワーク環境間のゲートウェイを形成する。
ステップＴ１において、レガシーＭＳ１０２は、ＰＤＰコンテクスト起動手順を開始する。この例によるＰＤＰコンテクスト起動手順において、ＧＧＳＮ ＨＩＰプロキシ１１４は、鍵ペア（ＨＩおよび秘密鍵）を生成し、それをレガシーＭＳ１０２に関連付け、鍵ペアをＧＧＳＮ ＨＩＰプロキシ１１４に保存する。公開鍵（ＨＩ）に基づいて、識別子が生成され、レガシーＭＳ１０２に関連付けられ、次いで、ＰＤＰコンテクストの中で使用されることになるアドレスとして、レガシーＭＳ１０２へ送信される。これは、ＩＰアドレスが通常はＰＤＰアドレスとして移動局１０２へと返信される、上述の従来型のＰＤＰコンテクスト起動手順とは異なる。
ＩＰｖ６がレガシーＭＳ１０２で使用されている場合、レガシーＭＳ１０２に関連付けられた識別子は、上述のホスト・アイデンティティ・タグ（ＨＩＴ）であり、これはＩＰｖ６アドレスと同じ長さであって、ここではＨＩＴＭＳ（ＧＧＳＮ）と呼ばれる。ＩＰｖ４がレガシーＭＳ１０２で使用されている場合、識別子は、上述のローカル・スコープ識別子（ＬＳＩ）であり、これはＩＰｖ４アドレスと同じ長さであって、ここではＬＳＩＭＳ（ＧＧＳＮ）と呼ばれる。前者（ＩＰｖ６）の場合、ＰＤＰコンテクスト作成応答の中のエンドユーザ・アドレスを図９に示し、他方、後者（ＩＰｖ４）の場合、エンドユーザ・アドレスを図１０に示す。
いかなる形式の識別子でもよいが、識別子がレガシーＭＳ１０２によって、エンドユーザ・アドレスで受信され、ＭＳ１０２は、下記の後続セッション開始メッセージにおいて発信元アドレスとして使用するため、識別子を記憶する。従って、識別子の長さが、レガシーＭＳ１０２によって使用されるアドレス指定方式の発信元アドレスフィールドと同じであることは、重要である。
続いて、図８のステップＴ２によって示されるように、レガシーＭＳ１０２がＨＩＰホスト１２２への接続を希望する場合、レガシーＭＳ１０２は、ＨＩＰホスト１２２のＩＰアドレスを取得するため、ＤＮＳクエリを送信する。ＤＮＳクエリは、ＧＧＳＮ ＨＩＰプロキシ１１４を経由して、ＤＮＳサーバ１１８へと進む。ＤＮＳサーバ１１８は、ＨＩＰホスト１２２のＩＰアドレス（ＩＰＨＨ）、および、ＨＩＰホスト１２２のＨＩＴ（ＨＩＴＨＨ）を返信し、この情報はＧＧＳＮ ＨＩＰ プロキシ１１４に記憶される。ＨＩＴＨＨは、次いで、レガシーＭＳ１０２へと送信され、以下で記述されることになる後続セッション開始メッセージの中でインジケータとして使用されるであろう。着信先インジケータは、セッション開始メッセージの着信先アドレスフィールドに挿入されるであろうから、着信先インジケータがセッション開始メッセージの着信先アドレスフィールドと同じ長さであることは重要である。従って、レガシーＭＳ１０２が、ＩＰｖ４対応であるだけの場合、レガシーＭＳ１０２のＤＮＳクエリに応じてレガシーＭＳ１０２へと送信される着信先インジケータは、ＩＰｖ４アドレスと同じ長さでなければならない。従って、ＧＧＳＮ ＨＩＰプロキシ１１４は、移動ネットワーク環境内で固有の、ＬＳＩ、もしくはＩＰｖ４アドレス、もしくは他の３２ビット表現を、ＨＩＰホスト１２２に割当てなければならない。続いて、ＧＧＳＮ ＨＩＰプロキシ１１４でアドレスの変換が必要となるが、それは当業者であれば容易になしうるであろう。
ステップＴ３において、図１１に示すように、ＩＰヘッダ内の発信元フィールドがＨＩＴＭＳ（ＧＧＳＮ）識別子に設定され、着信先フィールドがＨＩＴＨＨに設定された状態で、セッション開始メッセージが、レガシーＭＳ１０２からＧＧＳＮ ＨＩＰプロキシ１１４へと送信される。ＩＰｖ４アドレス指定の場合、着信先アドレスは、ＨＩＰホスト１２２のＬＳＩ、すなわち、ＬＳＩＨＨ（または、ＩＰｖ６からＩＰｖ４への変換が動作中の場合、ＨＩＰホスト１２２に割当てられたＬＳＩ）に設定される。
セッション開始メッセージを受信するとすぐに、ＧＧＳＮ ＨＩＰプロキシ１１４は、上述したステップＴ２のＤＮＳクエリに続いて受信したパケットの着信先ＨＩＴ（もしくはＬＳＩ）に一致するＨＩＴ（もしくはＬＳＩ）が記憶されていることに気付く。従って、ＧＧＳＮ ＨＩＰプロキシ１１４は、対象とする着信先ノードはＨＩＰ使用可能であり、そして、レガシーＭＳ１０２とＨＩＰホスト１２２との間の通信は、少なくとも部分的に、ホスト・アイデンティティ・プロトコルを用いて保護されうるということが分かる。この例において、ＧＧＳＮ ＨＩＰプロキシ１１４は、自分とＨＩＰホスト１２２間の接続のためのセキュリティ・アソシエーション（ＳＡ）を発見できず、それゆえ、ＧＧＳＮ ＨＩＰプロキシ１１４とＨＩＰホスト１２２との間のセキュリティ・アソシエーションを作成するため、図２を参照しながら記述したＨＩＰ ４ウェイ・ハンドシェイクを行う。ＨＩＰハンドシェイクを、ステップＴ４として図８に示す。
ＨＩＰ ４ウェイ・ハンドシェイクのためのＩ１パケットヘッダおよびＲ１パケットヘッダを、図１１に示す。Ｉ１パケットおよびＲ１パケットのＨＩＰヘッダの中で、イニシエータフィールドはＨＩＴＭＳ（ＧＧＳＮ）に設定され、レスポンダフィールドは、ＨＩＴＨＨに設定される。ＩＰヘッダの中で、ＩＰＧＧＳＮは、Ｉ１パケットの発信元フィールドおよびＲ１パケットの着信先フィールドに使用され、他方、ＩＰＨＨは、Ｉ１パケットの着信先フィールドおよびＲ１パケットの発信元フィールドに使用される。
ＧＧＳＮ ＨＩＰプロキシ１１４とＨＩＰホスト１２２との間のセキュリティ・アソシエーションが設定されると、ステップＴ５において、ＧＧＳＮ ＨＩＰプロキシ１１４は、（レガシーＭＳ１０２からステップＴ３で受信した）セッション開始メッセージを、セキュリティ・アソシエーションを用いてＨＩＰホスト１２２へと送信する。ステップＴ６において、セッション開始確認が、レガシーＭＳ１０２へと返信される。
レガシーＭＳ１０２とＨＩＰホスト１２２間のその後の通信は、これからはＧＧＳＮ ＨＩＰプロキシ１１４とＨＩＰホスト１２２との間の通信がＨＩＰセキュリティ・アソシエーションで保護された状態で、継続しうる。ＧＧＳＮ ＨＩＰプロキシ１１４は、ＨＩＰホスト１２２からパケットを受信すると、それを処理し、そしてデータを通常のＩＰパケットとして、ステップＴ１でレガシーＭＳ１０２に割当てられたものと同じ、パケットの着信先ＨＩＴに基づいて、レガシー１０２へと送信する。
上述のように、ＧＧＳＮ ＨＩＰプロキシ１１４とＨＩＰホスト１２２との間でセキュリティ・アソシエーションを設定するＨＩＰ交渉の間、そして、それに続くレガシーＭＳ１０２とＨＩＰホスト１２２との間のＧＧＳＮ ＨＩＰプロキシ１１４を介した通信の間、ＧＧＳＮ ＨＩＰプロキシ１１４自身のＨＩＴと鍵ペアとではなく、レガシーＭＳ１０２のために生成されたＨＩＴＭＳ（ＧＧＳＮ）と、関連付けられた鍵ペアとが、用いられる。これは、ＨＩＰホスト１２２と通信するレガシーＭＳ１２２の各々について、別個のセキュリティ・アソシエーション（もしくは、セキュリティ・アソシエーションのペア）が作成されるためである。ＧＧＳＮ ＨＩＰプロキシ１１４のＨＩＴと鍵ペアとが用いられたとしたら、そして、同じＨＩＰホスト１２２と通信する移動局が複数存在したとしたら、ＧＧＳＮ ＨＩＰプロキシ１１４とＨＩＰホスト１２２との間の通信は、同じセキュリティ・アソシエーションを用いることになるであろうし、ピアからの着信パケットはすべて、同じ着信先ＩＰとＳＰＩとを含むであろうから、さまざまな移動局間の接続を分離するためＧＧＳＮ ＨＩＰプロキシ１１４で用いられうる情報など、まったくないであろう。しかし、特定のＨＩＰホスト１２２に話しかけているＭＳが１つしかなかったら、ＧＧＳＮ ＨＩＰプロキシ１１４のＨＩＴと鍵ペアとを用いることは可能であっただろう。
上記の例において、ステップＴ２／Ｐ２におけるＤＮＳクエリに続いて、ＨＩＰホスト１２２のＨＩＰＨＨが、ＤＮＳ応答の一部としてＭＳ１０２に返信された。続いて、Ｉ１パケットがＨＩＰホスト１２２へ送信されるまでは、セッション開始メッセージの中の着信先ＩＰアドレスとして、ＨＩＴＨＨが用いられ、ＧＧＳＮ ＨＩＰプロキシ１１４においてＨＩＴＨＨからＩＰＨＨへの適切な変換なされた。理解されるはずだが、セッション開始メッセージの着信先ＩＰアドレスフィールドにＩＰＨＨを直接用いることができるように、実際のＩＰアドレスであるＩＰＨＨが、ＤＮＳ応答の一部としてＭＳ１０２へと返信されることもできよう。この場合、ＧＧＳＮ ＨＩＰプロキシ１１４は、ホスト１２２が実際にＨＩＰが使用可能であることを、何らかの方法で、例えばＨＩＴＨＨとＩＰＨＨ間のローカルに記憶されるアソシエーションを参照することによって、判断することが必要であろう。
上記の例において、識別子ＨＩＴＭＳ（ＧＧＳＮ）は、ＨＩＰ交渉の間に用いられ、従って、正確な形であって、かつ、鍵ペアに関連付けられていなければならない。しかし、この例においてさえ、識別子ＨＩＴＭＳ（ＧＧＳＮ）は、それ自体がレガシーＭＳ１０２へ送信される必要はなく、必要なことは、ＨＩＴＭＳ（ＧＧＳＮ）に関する何らかの識別子が、レガシーＭＳ１０２へと送信され、その後、セッション開始メッセージの中で発信元ＩＰアドレスとして用いられることである。この識別子は、次いで、ＧＧＳＮ ＨＩＰプロキシ１１４において、その後のＨＩＰ交渉で用いられるＨＩＴＭＳ（ＧＧＳＮ）にリンクされることができよう。
上述のように、ＰＣＴ出願番号ＰＣＴ／ＥＰ０４／０５０５３３号は、レガシー端末の接続先であるＳＧＳＮからのＰＤＰコンテクスト起動要求に応じて、一時的なＨＩＰ秘密鍵と公開鍵（ＨＩ）とＨＩＴとが、レガシー端末のためにＧＧＳＮにおいて作成されるようなシステムを、開示する。この一時的ＨＩＰアイデンティティは、次いで、ＧＧＳＮと、レガシー端末が通信しようとしているＨＩＰホストとの間のセキュアなＨＩＰ接続を交渉するのに使用される。特に、一時的ＨＩＴは、交渉パケットの中で用いられ、パケットは、ＧＧＳＮにおいて、一時的ＨＩＰ秘密鍵を使って署名される。
しかし、ＰＣＴ出願番号ＰＣＴ／ＥＰ０４／０５０５３３号の中に述べられた手法では、レガシー端末に関連付けられた永続性の、もしくは持続的なＨＩＰアイデンティティは存在せず、使用されるＧＧＳＮのそれぞれについて、別個の一時的ＨＩＰアイデンティティが作成される。レガシー端末が、同じＨＩＰアイデンティティを用いて別のネットワーク間を移動する可能性は、まったくない。従って、端末と、単一のＨＩＰアイデンティティとの間に一意のアソシエーションがあるという点でのＨＩＰの利点は、この手法では部分的に否定される。
本発明の一実施形態で取られる手法は、レガシー端末に自分自身の持続的ＨＩＰアイデンティティを与えることである。レガシー端末は、定義によって、ＨＩＰ使用可能ではないことから、ＨＩＰアイデンティティについて知ったり、理解したりすることはできないため、レガシー端末のためのＨＩＰアイデンティティ（秘密鍵、公開鍵、もしくは、ＨＩ、ＨＩＴ）が生成され、リモートサーバに記憶される。
この手法に関してありうる問題の１つは、ＧＧＳＮが、レガシー端末に関連付けられた公開ＨＩＴだけでなく、レガシー端末に関連付けられたＨＩＰ秘密鍵をも必要とすることである。ＨＩＰ秘密鍵をリモートサーバからＧＧＳＮへ送信するのはセキュアでないであろうから、異なる手法が必要である。
しかし、本発明の一実施形態では、レガシー端末の公開アイデンティティだけが、リモートサーバからＧＧＳＮへと送信され、新たな一時的ＨＩＰアイデンティティがＧＧＳＮで生成され、レガシー端末と関連付けられる。またリモートサーバは、レガシー端末の代わりにセキュアなＨＩＰ接続を交渉するため、ＧＧＳＮが一時的ＨＩＰアイデンティティを使用するのを承認する証明書を、ＧＧＳＮへ送信する。証明書は、レガシー端末が無線ネットワークにコンタクトを取るときに、リモートサーバから要求される。証明書要求は、認証データ要求（技術仕様3GPP TS 33.102 V6.3.0(2004-12)セクション６．３．２）と組み合わされてもよいし、認証データ要求の後で、別個に行われてもよい。一時的アイデンティティは、事前に生成されてもよいし、新たなレガシー端末が、在圏ネットワークエリアに入るとき、要求に応じてネットワークが、それらを生成してもよい。
ＧＧＳＮと第２の（ＨＩＰ使用可能な）ホストとの間でＨＩＰ交渉が行われる間、レガシー端末の持続的ＨＩＴがパケットヘッダの中で用いられるが、パケットは一時的秘密鍵で署名される。このミスマッチは、ＨＩＰホストによって突き止められるが、ＨＩＰ交渉の間にＧＧＳＮからＨＩＰホストへ送信された証明書を参照することによって解決する。証明書は、ＨＩＴによって特定されたレガシー端末の代わりにＧＧＳＮがＨＩＰ接続を交渉することを承認されたことを検証し、それによって、ＧＧＳＮとＨＩＰホスト間にセキュアなＨＩＰ接続が作成されるように、ＨＩＰ交渉が継続される。
ここで、図１２を参照しながら、上記の手法に従う本発明の具体的な実施形態について記述しよう。図１２に示すＨＬＲ／認証サーバ（ＡｕＣ）は、上記の「リモートサーバ」と同じであり、この文脈において、認証サーバという用語とリモートサーバという用語は同等である。ホーム環境にあるノードと在圏環境にあるノードは、本質的に同じであるが、唯一の違いは、レガシー端末が在圏環境にある場合には、認証サーバがレガシー端末のホーム環境に留まり、在圏環境はレガシー端末のホーム環境の認証サーバを用いるであろうということである。
本発明を実施する方法の下記のステップは、図１２に示すものに対応する。
ステップＰ１：
レガシー端末が無線ネットワーク（図６のＢＴＳ１０４およびＢＳＣ１０６に同等の、ノードＢおよびＲＮＣ、すなわち無線ネットワーク制御装置）への接続要求を行うのに応じて、ＳＳＧＮ／ＶＬＲはレガシー端末の認証を要求する。
次に、一時的ＨＩＰ秘密鍵と一時的ＨＩＰ公開鍵を含む、レガシー端末のための一時的ＨＩＰアイデンティティが、選択される。ＧＧＳＮは、ＨＩＰパケットに署名できるようにするため（これの詳細は、以下を参照のこと）、ＨＩＰ交渉のための一時的秘密鍵を要求し、一時的秘密鍵はセキュリティのためＧＧＳＮに留まらなければならない。また、ＳＧＳＮは、証明される目的で認証サーバへ送信するため、一時的公開鍵を要求する。
ＨＩＰ秘密鍵は、常に、ＨＩＰ公開鍵の発信元であり、従って、ＧＧＳＮは何らかの方法で一時的公開鍵をＳＧＳＮに提供する必要がある。証明されることになる一時的公開鍵は、ＧＧＳＮがその後ＨＩＰ交渉の中で用いる秘密鍵と一致しなければならない。ＧＧＳＮが、一時的秘密鍵を用いてレガシー端末の代わりにパケットに署名する権利を持つことを証明するため、ＧＧＳＮも、レガシー端末の持続的ＨＩＰアイデンティティ（秘密鍵）で証明された、適合する一時的公開鍵を持つ必要がある。
一時的ＨＩＰアイデンティティは、認証サーバへ送信するためＳＧＳＮに供給される一時的公開鍵を使って、ＳＧＳＮからのステップＰ１における要求に応じて、ＧＧＳＮにおいて生成されてもよいし、あるいは、一時的アイデンティティの集まりが事前に生成され、必要に応じてステップＰ１でＳＧＳＮが使用するため、１つ以上の事前に生成された一時的公開鍵が前もって供給されてもよい。いずれにしても、ＧＧＳＮはその後、適合する一時的秘密鍵をＨＩＰ交渉において使用しなければならない。
ステップＰ２：
認証サーバが、認証ベクトル（技術仕様3GPP TS 33.102 V6.3.0(2004-12)セクション６．３．２）と、要求された証明書と、レガシー端末の持続的公開鍵を使って応答する。認証サーバは、レガシー端末に関連付けられた、レガシー端末のための持続的ＨＩＰアイデンティティのデータベースを維持する。証明書は、レガシー端末の持続的公開鍵を発行者として含み、一時的公開鍵を内容として含み、そして、有効期限と、この証明書がその主題を承認する動作のタイプに関連する情報とを含む。証明書は、レガシー端末の持続的秘密鍵で署名される。
ステップＰ３：
ＳＧＳＮ／ＶＬＲは、ユーザ認証要求を端末に送信する（技術仕様3GPP TS 33.102 V6.3.0(2004-12)セクション６．３．１）。
ステップＰ４：
レガシー端末が、ユーザ認証応答で応答する。
ステップＰ５：
レガシー端末が、ＰＤＰコンテクスト起動要求をＳＧＳＮへ送信する。
ステップＰ６：
ＳＧＳＮが、ＰＤＰコンテクスト起動要求をＧＧＳＮへ送信するが、要求の中には、証明書とレガシー端末の持続的公開鍵とを含む。
ステップＰ７：
ＧＧＳＮが、ＰＤＰコンテクスト起動応答によってＳＧＳＮに返信する。
ステップＰ８：
ＳＧＳＮが、ＰＤＰコンテクスト起動応答をレガシー端末に転送する。割当てられたアドレスは、レガシー端末の持続的公開鍵から生成された、ＨＩＴもしくはＬＳＩである。上記のとおり、ＨＩＴもしくはＬＳＩは、第１のホストによって用いられるＩＰアドレッシング体系の中のアドレスと同じ長さをしている。次いで、出方向の接続（レガシー端末からＨＩＰ ＣＮへ）が、以下のように設定される。
ステップＰ９：
レガシー端末が（ＴＣＰ ＳＹＮメッセージによって）ＨＩＰ ＣＮへの接続を開始する。
ステップＰ１０：
ＨＩＰ交渉が、ＨＩＰヘッダ内にＨＩＴＣＮおよびＨＩＴＬＴ（ＬＴはレガシー端末のこと）を含むＩ１パケットによって開始される。
ステップＰ１１：
ＨＩＰ ＣＮがＲ１パケットによって応答する。
ステップＰ１２：
ＧＧＳＮが、Ｉ１パケット用と同じＨＩＴを持つＩ２パケットを送信する。また、証明書が後に続く予定であることをＨＩＰ ＣＮが分るように、パケット内に証明書ビットを設定する。ＨＩＰ ＣＮは、まだＩ２パケットを検証することができないが、それは、パケットが「間違った」署名を含むからである。ＨＩＴは持続的公開鍵から生成されるが、パケットは、ＧＧＳＮで生成された、一時的秘密鍵で署名される。
ステップＰ１３：
ＧＧＳＮは、証明書をＨＩＰ ＣＮへ送信する。証明書から、ＨＩＰ ＣＮは、ＨＩＰ信号の責任が、一時的ＨＩＰアイデンティティへ委任されることを、確認することができる。
ステップＰ１４：
ＨＩＰ交渉は、Ｒ２パケットによって終了する。これで、ＧＧＳＮとＨＩＰ ＣＮとの間に、ＩＰｓｅｃセキュリティ・アソシエーションが作成された。
ステップＰ１５：
ＴＣＰ ＳＹＮパケットがＩＰｓｅｃ接続を介して送信され、データ接続が確立される。
ステップＰ１６：
ＴＣＰ ＳＹＮ ＡＣＫパケットが、ＩＰｓｅｃ接続を介してＨＩＰ ＣＮからＧＧＳＮへ送信される。
ステップＰ１７：
ＴＣＰ ＳＹＮ ＡＣＫパケットが、レガシー端末へ送信される。
ステップＰ１８：
ＧＧＳＮとＨＩＰ ＣＮとの間に現在設定されたセキュアなＨＩＰ接続によって少なくとも部分的に保護された状態で、データ送信を開始することができる。
上述のプロセスは、レガシー端末からＨＩＰ ＣＮへ向かう出方向の接続に関連がある。ここで、本発明の一実施形態がＨＩＰ ＣＮからレガシー端末への着信接続に対してどのように適用できるかについて、以下に記述する。
ホスト・アイデンティティ・プロトコルにおいて、接続開始パケット（Ｉ１）のための、実際の着信先ホストの現在位置に向かう転送ポイントとして用いられるランデブーサーバすなわち転送エージェントが、定義される。ＨＩＰホストは、ランデブーサーバをその現在位置を使って更新し、次には、ＨＩＰホストの現在位置をマップするため、ＨＩＴを用いて、着信するＩ１パケットを転送できる。ＨＩＰランデブーサーバすなわち転送エージェントの概念および基本動作については、上記で詳細に記述している。
コンテクストの起動は、上記のステップＰ１からＰ８までの中で記述したように進行する。その後、認証サーバは、レガシー端末についての現行のＧＧＳＮ情報を維持する。
上記で言及したＤＮＳは、レガシー端末に関する情報を含む。本発明の一実施形態のコンテクストにおいて、ＤＮＳは、例えば、レガシー端末のＦＱＤＮ（完全修飾ドメイン名）、ホームネットワーク（認証サーバもしくは何か他のノード）によって維持されるレガシー端末の持続的ホスト・アイデンティティ、そして、ホームネットワーク内のどこかに位置する固定的なランデブーサーバのＩＰアドレスを含むであろう。固定的なランデブーサーバは、例えば、認証サーバ（これはインターネットに直接接続することが必要とされるであろうから、理想的ではないかもしれない）、「ホーム」ＧＧＳＮ、もしくは、そのような種類の別個のランデブーサーバであってもよい。ＳＳＧＮが認証サーバにコンタクトをとる場合（ステップＰ１およびＰ２）、認証サーバは、レガシー端末の現在位置をランデブーサーバに対して更新してもよい。
ＨＩＰ ＣＮは、ＤＮＳ（または他のルックアップ・サービス）からのレガシー端末のためのホスト情報を解読すると、レガシー端末のＨＩとランデブーサーバへのＩＰアドレスとが分る。次いで、ＨＩＰ ＣＮは、Ｉ１パケットをそのアドレスへ送信することによって、ＨＩＰ交渉を開始する。ランデブーサーバは、Ｉ１パケットを、パケット内のＨＩＴを用いて、正しいＧＧＳＮへ向けて転送する。
Ｉ１パケットが、レガシー端末の通信先であるＧＧＳＮに到着すると、ＧＧＳＮは、持続的ＨＩＴとホストの現行の一時的アイデンティティとの間のマッピングを見つけることができる。これからＧＧＳＮは、証明書ビットが設定されているＲ１パケットを使って、ＨＩＰ ＣＮに応答することができる。この後、ＧＧＳＮは、一時的秘密鍵でパケットに署名するための承認情報を含んだ、ＣＥＲパケットを送信する。
Ｒ１パケット内の公開鍵は、一時的公開鍵、すなわち、在圏ネットワークによって生成された一時的ＨＩである。Ｒ１パケットは一時的公開鍵を含むが、それは、それが、パケットに署名するのにＧＧＳＮが使う鍵だからである。Ｒ１パケット内のＨＩＰヘッダは、ＬＴの持続的ＨＩＴを含む。ＧＧＳＮは、Ｒ１パケットを使って応答するとき、Ｒ１パケットに続く証明書パケットも送信する。この証明書パケットの中には、持続的公開鍵が搬送されており、それによって、ＧＧＳＮがレガシー端末の代わりに一時的アイデンティティを用いる許可を得ていることも、検証される。
Ｉ２パケットとＲ２パケットは、ＨＩＰ交渉を終了させ、ＩＰｓｅｃＳＡが、ＨＩＰ ＣＮおよび現行のＧＧＳＮの間に確立される。接続の設定は、通常はＩＰｓｅｃトンネルでＧＧＳＮ内のＨＩＰプロキシへと行われ、それが、ＴＣＰ ＳＹＮを、在圏ネットワーク内のレガシー端末へ転送する。
本発明の一実施形態によって、１つのネットワークから別のネットワークへのレガシー端末の移動を扱うための容易な手法が、可能になる。レガシー端末が移動して、ネットワークを変更するとき、レガシー端末はＧＧＳＮも変更してもよい。ＧＧＳＮが変われば、ＰＤＰコンテクストは新たなネットワークにおいて作り直される必要がある。新たなＰＤＰコンテクストは、ステップＰ１からＰ８までにおいて上記で記述したように、起動される。レガシー端末が、新たなネットワーク内で第１のデータパケットを送信するとき（必ずしも新たな接続の試行ではなく、どのようなパケットでもよい）、新たなＧＧＳＮは、パケット内で用いられる着信先ＨＩＴについての逆ルックアップ手順を実行する。逆ルックアップは、例えば分散ハッシュ・テーブル（ＤＨＴ）サーバもしくは同様のものを用いて実行することができ、これらの技法は、ＩＲＴＦ ＨＩＰ研究グループで研究されている（ＩＲＴＦ ＨＩＰ−ＲＧ、ｈｔｔｐ：／／ｗｗｗ．ｉｒｔｆ．ｏｒｇ／ｃｈａｒｔｅｒｓ／ｈｉｐ．ｈｔｍｌ）。逆ルックアップがうまく実行されたら、ＧＧＳＮは、新たなＩ１パケットをＨＩＰ ＣＮへと送信し、上述の基本交換ステップＰ１０からＰ１３までを実行することができる。基本交換が完了した後、ＨＩＰ ＣＮは古いＨＩＰアソシエーションをやめて、レガシー端末の新たな位置として新たなアソシエーションを設定するであろう。
新たなＧＧＳＮとＨＩＰ ＣＮとの間には新たなセキュリティ・アソシエーションがあるにもかかわらず、エンドポイントはその視点を変えないため、レガシー端末のアプリケーションは、そのタスクを連続して続けることができる。
レガシー端末があるネットワークへ移動した後の第１の通信が、ＨＩＰ ＣＮからレガシー端末へ（上述のように、その逆ではなく）である場合、ＨＩＰ ＣＮはパケットをレガシー端末の転送エージェント（ランデブーサーバ）へと送信するであろう。ＨＬＲ／ＡｕＣがレガシー端末の位置を転送エージェントに対して更新した場合、転送エージェントは、パケットを新たなＧＧＳＮへと転送するであろうし、その場合、新たなＧＧＳＮがＨＩＰ ＣＮに対して、これは未知のアソシエーションであると応答するであろう。ＨＩＰ ＣＮがこの応答を受け取る場合、ＨＩＰ ＣＮは、新たなＩ１パケットを送信して、ＨＩＰ交渉をもう一度開始し、交渉は上述のように進行するであろう。
レガシー端末に持続的ＨＩＰアイデンティティを用いると、移動性を可能にするのに大いに役立つ。一時的ＨＩＰアイデンティティの場合、ＨＩＰ ＣＮホストは、レガシー端末が、以前のゲートウェイノードもしくはＧＧＳＮの下にあったのと同じであることを検証できないであろう。本発明の一実施形態では、移動性スキームは、一時的アイデンティティを永続性のもしくは持続的なアイデンティティに結合させることを利用しており、それによって、今度は、新たなゲートウェイノードもしくはＧＧＳＮおよび新たな一時的アイデンティティを有しているとしても、このレガシー端末は実際には以前と同じであることを、ＨＩＰ ＣＮに対して検証する。以前に検討されたスキームにおいては、レガシー端末は、ゲートウェイノードもしくはＧＧＳＮを変更する度に新たな一時的アイデンティティを得ていたであろうし、また、レガシー端末がＰＤＰコンテクストを停止して再度ＰＤＰコンテクストを起動する場合には、新たな一時的アイデンティティが生成される。本発明の一実施形態では、レガシー端末は永続的なアイデンティティを有しており、ネットワーク間を移動することが可能であって、それでもやはり同じ存在として識別されることができる。上述のように、これはＨＩＰの中心となる概念であり、すなわち、アイデンティティはノードの地理的位置には依存せず、ノードがどこへ移動しようとも、アイデンティティは同じままであり、ノードは、あらゆる地理的およびトポロジ的な位置において同じ存在として識別される、ということである。
理解されるはずだが、レガシー端末、ＳＧＳＮ、ＧＧＳＮ ＨＩＰプロキシ、そしてＨＩＰホストのうち１つ以上の動作は、装置上または機器上で動作しているプログラムによって制御してもよい。そのような動作プログラムは、コンピュータ可読媒体上に保存されてもよいし、例えば、インターネットのウェブサイトから提供されるダウンロード可能なデータ信号のような信号の中に組み込まれることもできよう。添付の請求項は、動作プログラムを、単独で、または搬送波上の信号として、あるいは信号として、もしくは他の何らかの形で、カバーしていると解釈されるべきである。
当業者であれば、本発明の実施形態は、各層の、例えばトランスポート層またはネットワーク層の、何らかの特定のプロトコルまたはアドレス指定スキームに必ずしも限定されないこと、そして、ＨＩＰの枠組みの周辺でどのようなアドレス指定もしくはトランスポートプロトコルが用いられようと、その枠組みの中で機能するであろうことを、理解するであろう。
ホスト・アイデンティティ・プロトコルにおける各層を示す図である。 ＨＩＰプロトコルにおける４ウェイ・ハンドシェイクの動作を示す図である。 ＨＩＰにおける論理的および実際のパケットの構造を示す図である。 ＩＰｖ６とＩＰｖ４との間のハンドオーバを示す図である。 レガシーホストとＨＩＰプロキシを介したＨＩＰモードとの通信についての一般的なネットワーク設定について示す概略図である。 本発明の一実施形態が適用されるＧＰＲＳ／ＵＭＴＳネットワーク・アーキテクチャの要素を示すブロック図である。 ＰＤＰコンテクスト起動手順の一例を示す信号図である。 レガシーの第１ホストとＨＩＰが使用可能な第２ホストとの間の少なくとも部分的にセキュアな通信にホスト・アイデンティティ・プロトコルを用いる方法を示す信号図である。 識別子に１２８ビット表現を用いたエンドユーザ・アドレス情報を示す図である。 識別子に３２ビット表現を用いたエンドユーザ・アドレス情報を示す図である。 送信された特定のメッセージについてＨＩＰヘッダおよびＩＰヘッダの内容を示す図である。 本発明の一実施形態による方法を示す信号図である。

Claims (35)

  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. 前記リモートサーバは、認証サーバであることを特徴とする請求項１乃至２４の何れか１項に記載の方法。
  26. 前記第１ホストと第２ホストとの間で新規のゲートウェイノードがアクティブになる場合、前記新規のゲートウェイノードと前記第２ホストとの間の新規のセキュアなＨＩＰ接続を交渉するための基礎として、前記第１ホストについて同一の持続的ＨＩＰアイデンティティを用いる工程を備えることを特徴とする請求項１乃至２５の何れか１項に記載の方法。
  27. 前記第１ホストから前記第２ホストへの後続の通信に含まれている前記第２ホストのためのＨＩＰ公開識別子に基づいて、前記第２ホストの位置決めをするために前記新規のゲートウェイノードでルックアッププロセスを用いる工程を備えることを特徴とする請求項２６に記載の方法。
  28. 以前のセキュアなＨＩＰ接続を破棄する工程を備えることを特徴とする請求項２６または２７に記載の方法。
  29. 通信システムであって、
    第１ホストおよび第２ホストであって、前記第１ホストはホスト・アイデンティティ・プロトコル（ＨＩＰ）使用可能でなく前記第２ホストはＨＩＰ使用可能である、前記第１ホストおよび前記第２ホストと、
    前記第１ホストと前記第２ホストとの間のゲートウェイノードと、
    前記第１ホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバと、
    セキュアなＨＩＰ接続について交渉するために、前記持続的ＨＩＰアイデンティティの公開部分と前記第１ホストに関連付けられた一時的ＨＩＰアイデンティティの前記ゲートウェイノードによる使用を承認する証明書とを前記リモートサーバから取得するための前記ゲートウェイノードが備える取得する手段と、
    前記持続的ＨＩＰアイデンティティと前記一時的ＨＩＰアイデンティティと前記証明書の各々の少なくとも一部を用いて、前記ゲートウェイノードと前記第２ホストとの間のセキュアなＨＩＰ接続について交渉する手段であって、前記第１ホストと前記第２ホストとの間の通信を前記ホスト・アイデンティティ・プロトコルを用いて少なくとも部分的に保護する、手段と、
    を備えることを特徴とする通信システム。
  30. ネットワークのサービングノードによって使用され、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を用いて、前記ネットワークの第１ホストと第２ホストとの間の通信が少なくとも部分的に保護されることを可能にする方法であって、前記第１ホストはＨＩＰ使用可能でなく前記第２ホストはＨＩＰ使用可能であり、前記ネットワークは前記第１ホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバを備え、該方法は、
    前記第１ホストと前記第２ホストとの間の前記ネットワークのゲートウェイノードが、前記持続的ＨＩＰアイデンティティと前記一時的ＨＩＰアイデンティティと前記証明書との各々の少なくとも一部を用いて、前記ゲートウェイノードと前記第２ホストとの間のセキュアなＨＩＰ接続について交渉するため、前記持続的ＨＩＰアイデンティティの公開部分と、前記ゲートウェイノードによる前記第１ホストに関連付けられた一時的ＨＩＰアイデンティティの後続の工程での使用を承認する証明書と、を前記リモートサーバから取得する工程を備えることを特徴とする方法。
  31. ネットワークのサービングノードとして使用され、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を用いて、前記ネットワークの第１ホストと第２ホストとの間の通信が少なくとも部分的に保護されることを可能にする装置であって、前記第１ホストはＨＩＰ使用可能でなく前記第２ホストはＨＩＰ使用可能であり、前記ネットワークは前記第１ホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバを備え、該装置は、
    前記持続的ＨＩＰアイデンティティと前記一時的ＨＩＰアイデンティティと前記証明書との各々の少なくとも一部を用いて、前記ゲートウェイノードと前記第２ホストとの間のセキュアなＨＩＰ接続について交渉するため、前記持続的ＨＩＰアイデンティティの公開部分と、前記第１ホストと前記第２ホストとの間の前記ネットワークのゲートウェイノードによる前記第１ホストに関連付けられた一時的ＨＩＰアイデンティティの後続の工程での使用を承認する証明書と、を前記リモートサーバから取得する手段を備えることを特徴とする装置。
  32. ネットワークの第１ホストと第２ホストとの間のゲートウェイノードによって使用され、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を用いて、前記ネットワークの前記第１ホストと前記第２ホストとの間の通信が少なくとも部分的に保護されることを可能にする方法であって、前記第１ホストはＨＩＰ使用可能でなく前記第２ホストはＨＩＰ使用可能であり、前記ネットワークは、前記第１ホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバと、前記持続的ＨＩＰアイデンティティの公開部分と前記第１ホストに関連付けられた一時的ＨＩＰアイデンティティを前記ゲートウェイノードが使用することを承認する証明書とを前記リモートサーバから取得するための前記ゲートウェイノードが備える取得する手段と、を備え、該方法は、
    前記持続的ＨＩＰアイデンティティと前記一時的ＨＩＰアイデンティティと前記証明書との各々の少なくとも一部を用いて、前記ゲートウェイノードと前記第２ホストとの間のセキュアなＨＩＰ接続について交渉する工程を備えることを特徴とする方法。
  33. ネットワークの第１ホストと第２ホストとの間のゲートウェイノードとして使用され、ホスト・アイデンティティ・プロトコル（ＨＩＰ）を用いて、前記ネットワークの前記第１ホストと前記第２ホストとの間の通信が少なくとも部分的に保護されることを可能にする装置であって、前記第１ホストはＨＩＰ使用可能でなく前記第２ホストはＨＩＰ使用可能であり、前記ネットワークは、前記第１ホストに関連付けられた持続的ＨＩＰアイデンティティを維持するためのリモートサーバと、前記持続的ＨＩＰアイデンティティの公開部分と前記第１ホストに関連付けられた一時的ＨＩＰアイデンティティを前記ゲートウェイノードが使用することを承認する証明書とを前記リモートサーバから取得する手段と、を備え、該装置は、
    前記持続的ＨＩＰアイデンティティと前記一時的ＨＩＰアイデンティティと前記証明書との各々の少なくとも一部を用いて、前記装置と前記第２ホストとの間のセキュアなＨＩＰ接続について交渉する手段を備えることを特徴とする装置。
  34. 装置上で実行されることにより、該装置が請求項３０または３２に記載の方法を実行するオペレーティング・プログラム。
  35. 装置にロードされることにより、該装置が請求項３１または３３に記載の装置になるオペレーティング・プログラム。
JP2007556108A 2005-02-18 2005-11-17 ホスト・アイデンティティ・プロトコルの方法および装置 Expired - Fee Related JP4755203B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0503416A GB2423448B (en) 2005-02-18 2005-02-18 Host identity protocol method and apparatus
GB0503416.0 2005-02-18
PCT/SE2005/001730 WO2006088403A1 (en) 2005-02-18 2005-11-17 Host identity protocol method and apparatus

Publications (2)

Publication Number Publication Date
JP2008530948A JP2008530948A (ja) 2008-08-07
JP4755203B2 true JP4755203B2 (ja) 2011-08-24

Family

ID=34400970

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007556108A Expired - Fee Related JP4755203B2 (ja) 2005-02-18 2005-11-17 ホスト・アイデンティティ・プロトコルの方法および装置

Country Status (7)

Country Link
US (1) US8516243B2 (ja)
EP (1) EP1849279B1 (ja)
JP (1) JP4755203B2 (ja)
CN (1) CN101120572B (ja)
CA (1) CA2598098A1 (ja)
GB (1) GB2423448B (ja)
WO (1) WO2006088403A1 (ja)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7873825B2 (en) * 2004-04-15 2011-01-18 Telefonaktiebolaget L M Ericsson (Publ) Identification method and apparatus for establishing host identity protocol (HIP) connections between legacy and HIP nodes
EP1821487B1 (en) * 2006-02-21 2010-04-07 Microsoft Corporation Topology management in peer-to-peer content distribution clouds
DE602006018660D1 (ja) * 2006-04-25 2011-01-13 Ericsson Telefon Ab L M
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
CN101350807B (zh) 2007-07-20 2012-04-04 华为技术有限公司 多地址空间移动网络架构、主机信息注册及数据发送方法
US7969933B2 (en) * 2007-08-03 2011-06-28 Kapsch Trafficcom Ag System and method for facilitating a persistent application session with anonymity between a mobile host and a network host
EP2215771A1 (en) 2007-11-28 2010-08-11 Telefonaktiebolaget LM Ericsson (publ) Multicast source mobility
CN101827011B (zh) * 2009-03-04 2013-03-27 华为技术有限公司 一种主机通信的方法、系统和设备
CN102025587B (zh) * 2009-09-17 2014-07-02 中兴通讯股份有限公司 Lisp网络与互联网互通的实现方法和系统
CN102143487B (zh) * 2010-02-03 2015-06-10 中兴通讯股份有限公司 一种端对端会话密钥协商方法和系统
EP2559219B1 (en) * 2010-04-15 2017-11-15 Google Technology Holdings LLC Online secure device provisioning framework
US8347100B1 (en) 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
CN101997875B (zh) * 2010-10-29 2013-05-29 北京大学 一种安全的多方网络通信平台及其构建方法、通信方法
US9106699B2 (en) * 2010-11-04 2015-08-11 F5 Networks, Inc. Methods for handling requests between different resource record types and systems thereof
US9021104B2 (en) * 2011-02-28 2015-04-28 Futurewei Technologies, Inc. System and method for mobility management in a wireless communications system
US9843554B2 (en) 2012-02-15 2017-12-12 F5 Networks, Inc. Methods for dynamic DNS implementation and systems thereof
US9609017B1 (en) 2012-02-20 2017-03-28 F5 Networks, Inc. Methods for preventing a distributed denial service attack and devices thereof
US8832433B2 (en) * 2012-08-17 2014-09-09 Cellco Partnership Methods and systems for registering a packet-based address for a mobile device using a fully-qualified domain name (FQDN) for the device in a mobile communication network
US9282116B1 (en) 2012-09-27 2016-03-08 F5 Networks, Inc. System and method for preventing DOS attacks utilizing invalid transaction statistics
EP3081020A4 (en) * 2013-12-09 2016-10-19 Ericsson Telefon Ab L M METHOD AND APPARATUS FOR SHARING DATA CONNECTIVITY
CN103957152B (zh) * 2014-04-22 2017-04-19 广州杰赛科技股份有限公司 IPv4与IPv6网络通信方法及NAT‑PT网关
US11838851B1 (en) 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
WO2016096055A1 (en) * 2014-12-19 2016-06-23 Telefonaktiebolaget Lm Ericsson (Publ) Method, network node and terminal device in a communication network
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
CN106487742B (zh) 2015-08-24 2020-01-03 阿里巴巴集团控股有限公司 用于验证源地址有效性的方法及装置
US10797888B1 (en) 2016-01-20 2020-10-06 F5 Networks, Inc. Methods for secured SCEP enrollment for client devices and devices thereof
US10855478B2 (en) * 2018-08-13 2020-12-01 Taiwan Semiconductor Manufacturing Co., Ltd. Method and apparatus for protecting embedded software

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US6353891B1 (en) * 2000-03-20 2002-03-05 3Com Corporation Control channel security for realm specific internet protocol
US6982967B1 (en) * 2000-06-29 2006-01-03 Cisco Technology, Inc. Methods and apparatus for implementing a proxy mobile node in a wireless local area network
EP1350151A2 (en) * 2000-11-13 2003-10-08 Ecutel, Inc. System and method for secure network mobility
GB2369530A (en) * 2000-11-24 2002-05-29 Ericsson Telefon Ab L M IP security connections for wireless authentication
US7155518B2 (en) * 2001-01-08 2006-12-26 Interactive People Unplugged Ab Extranet workgroup formation across multiple mobile virtual private networks
GB2381423B (en) * 2001-10-26 2004-09-15 Ericsson Telefon Ab L M Addressing mechanisms in mobile IP
CN1215386C (zh) * 2002-04-26 2005-08-17 St微电子公司 根据量子软计算控制过程或处理数据的方法和硬件体系结构
US7346771B2 (en) * 2002-11-13 2008-03-18 Nokia Corporation Key distribution across networks
ATE366017T1 (de) * 2004-02-13 2007-07-15 Ericsson Telefon Ab L M Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
WO2006072891A1 (en) * 2005-01-07 2006-07-13 Alcatel Lucent Method and apparatus for providing route-optimized secure session continuity between mobile nodes

Also Published As

Publication number Publication date
GB2423448B (en) 2007-01-10
EP1849279B1 (en) 2017-01-18
JP2008530948A (ja) 2008-08-07
CA2598098A1 (en) 2006-08-24
US20080271132A1 (en) 2008-10-30
WO2006088403A1 (en) 2006-08-24
CN101120572A (zh) 2008-02-06
GB2423448A (en) 2006-08-23
CN101120572B (zh) 2010-12-08
US8516243B2 (en) 2013-08-20
EP1849279A1 (en) 2007-10-31
GB0503416D0 (en) 2005-03-30

Similar Documents

Publication Publication Date Title
JP4755203B2 (ja) ホスト・アイデンティティ・プロトコルの方法および装置
EP1735963B1 (en) Identification method and apparatus for establishing host identity protocol (hip) connections between legacy and hip nodes
US7827313B2 (en) Addressing method and method and apparatus for establishing host identity protocol (HIP) connections between legacy and HIP nodes
EP2016733B1 (en) Addressing and routing mechanism for web server clusters
EP1884102B1 (en) Host identity protocol method and apparatus
EP1735990B1 (en) Mobile ipv6 authentication and authorization
EP1782574B1 (en) Fast network attachment
EP1466458B1 (en) Method and system for ensuring secure forwarding of messages
GB2424154A (en) Streamlined network logon using Host Identity Protocol (HIP) with broadcast puzzle challenges and home server certificates
KR100737140B1 (ko) 이동통신에서의 인터넷 프로토콜 가상 사설망 서비스처리장치 및 방법

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100913

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20101213

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20101220

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110223

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110513

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: 20110526

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

Free format text: PAYMENT UNTIL: 20140603

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

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees