JP4763700B2 - 動的かつ安全なトンネル確立方法 - Google Patents

Description

本願は、とりわけ、コンピュータネットワークにおける動的かつ安全なトンネル確立方法に関する。

本出願は、２００４年８月１７日に提出された仮出願第６０／６０１，９８０号（発明の名称“動的かつ安全なトンネル確立方法（A METHOD FOR DYNAMICALLY AND SECURELY ESTABLISHING A TUNNEL）”）に対して優先権を主張している。

本願は、とりわけ、コンピュータネットワークにおける動的かつ安全なトンネル確立方法に関する。下記に示す現在の譲受人の同時継続特許出願それぞれの全開示は、背景技術のために参照してここに組み込まれる。１）２００４年１月２２日に提出された米国特許出願第１０／７６１，２４３号（発明の名称“事前認証、事前コンフィグレーション及び／又は仮想ソフトハンドオフを用いた移動性アーキテクチャー（Mobility Architecture Using Pre-Authentication, Pre-Configuration And/Or Virtual Soft-Handoff）”と、２）２００４年１０月２９日に提出された米国特許出願第１０／９０８，１９９号（発明の名称“隔離ネットワーキング（Quarantine Networking）”と、３）２００４年１０月２９日に提出された米国特許出願第１０／９７５，４９７号（発明の名称“動的ホストコンフィグレーション及びネットワークアクセス認証（Dynamic Host Configuration And Network Access Authentication）”
ネットワークとインターネットプロトコル：
最も有名なインターネットとともに多様な種類のコンピュータネットワークがある。インターネットはコンピュータネットワークの世界的なネットワークである。今日、インターネットは何百万ものユーザが使用できる公開された自立したネットワークである。インターネットはＴＣＰ／ＩＰ（つまり伝送制御プロトコル／インターネットプロトコル）と呼ばれている一式の通信プロトコルを使用して、ホストを接続する。インターネットはインターネットバックボーンとして公知の通信インフラストラクチャを有する。インターネットバックボーンに対するアクセスは、主として企業及び個人のアクセスをリセールするインターネットサービスプロバイダ（ＩＳＰ）によって制御されている。

ＩＰ（インターネットプロトコル）に関して、これは、あるデバイス（例えば、電話、ＰＤＡ［パーソナルデジタルアシスタント］、コンピュータ等）からネットワーク上の別のデバイスにデータを送信できるプロトコルである。今日では、ＩＰｖ４、ＩＰｖ６等を含む種々のバージョンのＩＰがある。ネットワーク上の各ホストデバイスは、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。

ＩＰはコネクションレスプロトコルである。通信中のエンドポイント間の接続は連続ではない。ユーザがデータ又はメッセージを送信又は受信すると、このデータ又はメッセージはパケットとして知られているコンポーネントに分割される。あらゆるパケットはデータの独立した単位として取り扱われる。

インターネット又は類似するネットワーク上でポイント間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワークの中の２つのポイントの間の通信プロセスを７つの積み重ねられた層に切り離し、それぞれの層が独自の機能のセットを追加する。各デバイスは、送信側エンドポイントにある各層を通る下降流と、受信側エンドポイントにある層を通る上昇流が存在するようにメッセージを処理する。機能の７つの層を提供するプログラミング及び／又はハードウェアは、通常は、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポートプロトコル及びネットワークプロトコル、ならびに他のソフトウェアとハードウェアの組み合わせである。

通常、メッセージがユーザから又はユーザに渡されるときには上部４つの層が使用され、メッセージがデバイス（例えばＩＰホストデバイス）を通過するときには下部の３つの層が使用される。ＩＰホストは、サーバ、ルータ、又はワークステーション等の、ＩＰパケットを送信及び受信できるネットワーク上の任意のデバイスである。なんらかの他のホストに向けられるメッセージは上位層まで渡されないが、他のホストに転送される。ＯＳＩモデルの層は以下に一覧表示される。第７層（つまり、アプリケーション層）は、例えば通信パートナーが特定され、サービスの質が特定され、ユーザ認証とプライバシーが考慮され、データ構文に対する制約が特定される等の層である。第６層（つまり、プレゼンテーション層）は、例えば入信データと発信データをあるプレゼンテーションフォーマットから別のプレゼンテーションフォーマットに変換する等の層である。第５層（つまり、セッション層）は、例えばアプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了する等の層である。第４層（つまり、トランスポート層）は、例えばエンドツーエンド制御及びエラーチェックを管理する等の層である。第３層（つまり、ネットワーク層）は、例えばルーティングと転送を処理する等の層である。第２層（つまり、データリンク層）は、例えば物理レベルに同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識と管理を提供する等の層である。電気電子技術者協会（ＩＥＥＥ）は、データリンク層を２つの追加の副層、つまり物理層への及び物理層からのデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層と接続し、コマンドを解釈し、エラー回復を実行するＬＬＣ（論理リンク制御）層に再分割する。第１層（つまり、物理層）は、物理レベルでネットワークを通してビットストリームを伝達する等の層である。ＩＥＥＥは、物理層をＰＬＣＰ（物理層収束手順）副層と、ＰＭＤ（物理媒体依存）副層に再分割する。

無線ネットワーク：
無線ネットワークは、例えばセルラー電話と無線電話、ＰＣ（パソコン）、ラップトップコンピュータ、ウェアラブルコンピュータ、コードレスフォン、ページャ、ヘッドホン、プリンタ、ＰＤＡ等の種々のタイプのモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するためにデジタルシステムを含んでよい。典型的なモバイル機器は、以下の構成要素のいくつか又はすべてを含む。つまり、トランシーバ（つまり、例えば送信機、受信機、及び所望される場合他の機能が統合されたシングルチップトランシーバ等を含む送信機と受信機）、アンテナ、プロセッサ、１台又は複数台の音声トランスデューサ（例えば、音声通信用のデバイスにおいてのようなスピーカ又はマイク）、（例えば、ＲＯＭ、ＲＡＭ、データ処理が提供されるデバイスにおいてのようなデジタルデータ記憶装置等の）電磁データ記憶装置、メモリ、フラッシュメモリ、フルチップセット又は集積回路、（例えばＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭ等の）インタフェース、及び／又は類似物である。

携帯電話利用者が無線接続を通してローカルエリアネットワーク（ＬＡＮ）に接続できる無線ＬＡＮ（ＷＬＡＮ）は、無線通信のために利用されてよい。無線通信は、例えば、光、赤外線、無線、マイクロ波等の電磁波を介して伝搬する通信を含むことができる。ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、及びＨｏｍｅＲＦ等、現在存在する種々のＷＬＡＮ規格がある。

一例として、ブルートゥース製品は、モバイルコンピュータ、携帯電話、ポータブル携帯端末、パーソナルデジタルアシスタント（ＰＤＡ）及び他のモバイル機器の間にリンクを、インターネットに接続性を提供するために使用されてよい。ブルートゥースは、モバイル機器が短距離無線接続を使用して互いに、及び非モバイル機器とどのように容易に相互接続できるのかを詳説するコンピュータ電気通信業界の仕様である。ブルートゥースは、ある装置から別の装置でデータを同期及び一貫させる必要がある多様なモバイル機器の拡散から生じるエンドユーザ問題に対処するためにデジタル無線プロトコルを作成し、それにより様々なベンダの装置がともにシームレスに動作できるようにする。ブルートゥースデバイスは共通の命名概念に従って名前が付けられてよい。例えば、ブルートゥースデバイスはブルートゥースデバイス名（ＢＤＮ）又は一意のブルートゥースデバイスアドレス（ＢＤＡ）と関連付けられた名称を持つことができる。また、ブルートゥースデバイスは、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥースデバイスがＩＰネットワーク上で機能する場合、それにはＩＰアドレスとＩＰ（ネットワーク）名が与えられてよい。したがって、ＩＰネットワーク上で参加するように構成されたブルートゥースデバイスは、例えばＢＤＮ、ＢＤＡ、ＩＰアドレス、及びＩＰ名を含んでよい。用語「ＩＰ名」はインタフェースのＩＰアドレスに対応する名称を指す。

ＩＥＥ規格であるＩＥＥＥ８０２．１１は、無線ＬＡＮとデバイスのための技術を規定する。８０２．１１を使用して、複数のデバイスをサポートしているそれぞれ単一の基地局との無線ネットワーキングが達成されてよい。いくつかの例では、デバイスは無線ハードウェアを事前に装備して納品されてよい、又はユーザがアンテナを含んでよいカード等の別個のハードウェアをインストールしてよい。一例として、８０２．１１で使用されるデバイスは、通常、デバイスがアクセスポイント（ＡＰ）であるのか、移動局（ＳＴＡ）であるのか、ブリッジであるのか、ＰＣＭＣＩＡカードであるのか、又は別のデバイス、つまり無線トランシーバ、アンテナ及びネットワーク内のポイントの間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層であるのかに関係なく３つの注目すべき要素を含む。

更に、いくつかの無線ネットワークではマルチプルインタフェースデバイス（ＭＩＤｓ）が活用されることがある。ＭＩＤはブルートゥースインタフェースと８０２．１１インタフェース等の２つの独立したネットワークインタフェースを含んでよく、このようにしてＭＩＤはブルートゥースデバイスと接続するだけではなく２つの別々のネットワークで参加することもできるようになる。ＭＩＤはＩＰアドレスと、このＩＰアドレスと関連付けられた共通ＩＰ（ネットワーク）名を有してよい。

無線ネットワークデバイスは、ブルートゥースデバイス、マルチプルインタフェースデバイス（ＭＩＤ）、８０２．１１ｘデバイス（例えば８０２．１１ａ、８０２．１１ｂ及び８０２．１１ｇのデバイスを含むＩＥＥＥ ８０２．１１デバイス）、ＨｏｍｅＲＦ（ホーム無線周波数）デバイス、Ｗｉ−Ｆｉ（ワイヤレスフィディリティー）デバイス、ＧＰＲＳ（ジェネラルパケットラジオサービス）デバイス、３Ｇセルラーデバイス、２．５Ｇセルラーデバイス、ＧＳＭ（グローバルシステムフォーモバイルコミュニケーションズ）デバイス、ＥＤＧＥ（Enhanced Data for GSM Evolution）デバイス、ＴＤＭＡタイプ（時分割多元接続）デバイス、又はＣＤＭＡ２０００を含むＣＤＭＡタイプ（符号分割多元接続）デバイスを含んでよいが、これらに限定されない。それぞれのネットワークデバイスは、ＩＰアドレス、ブルートゥースデバイスアドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、又はＩＥＥＥ ＭＡＣアドレスを含むが、これらに限定されない様々なタイプのアドレスを含んでよい。

無線ネットワークは、例えばモバイルＩＰ（インターネットプロトコル）システムにおいて、ＰＣＳシステムにおいて、及び他の携帯電話ネットワークシステムにおいて見られる方法及びプロトコルも含むことがある。モバイルＩＰに関して、これはインターネットエンジニアリングタスクフォース（ＩＥＴＦ）により作成された標準通信プロトコルを含む。モバイルＩＰを使用すると、モバイル機器ユーザは、一度割り当てられた自分のＩＰアドレスを維持しながらネットワーク全体で移動することができる。リクエストフォーコメント（ＲＦＣ）３３４４を参照されたい。注意：ＲＦＣはインターネットエンジニアリングタスクフォース（ＩＥＴＦ）の公式文書である。モバイルＩＰはインターネットプロトコル（ＩＰ）を強化し、自らのホームネットワークの外部で接続するときにインターネットトラフィックをモバイル機器に転送する手段を追加する。モバイルＩＰは、各モバイルノードに、そのホームネットワークでのホームアドレスと、ネットワーク及びそのサブネットの中でのデバイスの現在位置を特定する気付アドレス（ＣｏＡ）とを割り当てる。デバイスは別のネットワークに移動すると、それは新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは各ホームアドレスをその気付アドレスと関連付けることができる。モバイルノードは、それがその気付アドレスを例えばインターネットコントロールメッセージプロトコル（ＩＣＭＰ）を使用して変更するたびにホームエージェントにバインディングアップデートを送信できる。

基本ＩＰルーティング（例えば、モバイルＩＰ外部）では、ルーティング機構は、各ネットワークノードが常に、例えばインターネットに対する一定の接続点を有し、それぞれのノードのＩＰアドレスが、それが接続されるネットワークリンクを特定するという仮定に依存している。本明細書では、用語「ノード」は、例えばデータ伝送のための再分布点又はエンドポイントを含むことがあり、他のノードへの通信を認識する、処理する、及び／又は転送することができる接続点を含む。例えば、インターネットルータは、デバイスのネットワークを特定する、例えばＩＰアドレスプレフィクス等を見ることができる。次にルータは、ネットワークレベルで、特定のサブネットを特定するビットのセットを見ることができる。次にルータは、サブネットレベルで、特定のデバイスを特定するビットのセットを見ることができる。典型的なモバイルＩＰ通信を用いる場合、ユーザが例えばインターネットからモバイル機器を切断し、新しいサブネットでそれを再接続しようと試みる場合、デバイスは新しいＩＰアドレス、適切なネットマスク及びデフォルトルータで再構成されなければならない。それ以外の場合、ルーティングプロトコルはパケットを適切に配信できないであろう。

好ましい実施形態は、その参考文献の全体的な開示が参照してここに組み込まれる、とりわけ以下の参考文献に説明される技術の改良を提供する。
・［ＲＦＣ２００３］ C.Perkins, “IP Encapsulation within IP”, RFC2003, 1996年10月.
・［ＲＦＣ２００４］ C.Perkins, “Minimal Encapsulation within IP”, RFC2004, 1996年10月.
・［ＲＦＣ２７８４］ D.Farinacciら, “Generic Routing Encapsulation (GRE)”, RFC2784, 2000年3月.
・［ＲＦＣ２４０１］ S.Kent and R.Atkins, “Security Architecture for the Internet Protocol”, RFC2401, 1998年11月.
・［ＲＦＣ３３４４］ C.Perkins, “IP Mobility Support for IPv4”, RFC3344, 2002年8月.
・［ＲＦＣ３７７５］ C.Perkinsら, “IP Mobility Support for IPv6”, 2004年6月.
・［ＲＦＣ２４０９］ D.Harkins and D.Carrel, “The Internet Key Exchange (IKE)”, RFC2409, 1998年11月.
・［ＩＫＥｖ２］ C.Kaufman, “Internet Key Exchange (IKEv2) Protocol”, Internet-Draft, draft-ietf-ipsec-ikev2-14.txt, work in progress, 2004年11月.
・［ＲＦＣ３７４８］ B.Abobaら, “Extensible Authentication Protocol (EAP)”, RFC3748, 2004年6月.
・［ＰＡＮＡ−ＦＲＷＫ］ P.Jayaraman, “PANA Framework”, Internet-Draft, draft-ietf-pana-framework-01.txt, work in progress, 2004年7月.
・［ＰＡＮＡ］ D.Forsbergら, “Protocol for Carrying Authentication for Network Access (PANA)”, Internet-Draft, draft-ietf-pana-pana-05.txt, work in progress, 2004年7月.
・［ＰＡＮＡ−ＩＰＳＥＣ］ M.Parthasarathy, “PANA Enabling IPsec Based Access Control”, Internet-Draft, draft-ietf-pana-ipsec-03.txt, 2004年5月.
インターネットプロトコルは、イーサネット（登録商標）及びＰＰＰ(Point-to-Point Protocol)を含む様々なリンク層上でネットワークレイヤ・パケット（すなわち、インターネットプロトコルにおけるＩＰデータグラム）を運ぶ方法を定義する。ＩＰデータグラムは、“ＩＰリンク”上で運ばれることも可能であり、そこでは、他のＩＰデータグラムのペイロードにカプセル化されて伝送される。この技術は、“ＩＰトンネリング”又は“トンネリング”と呼ばれる。トンネリングは、データグラムを、最初のＩＰヘッダにおけるＩＰ宛先アドレス・フィールド（のネットワークパート）に基づいては選択されないであろう中間の宛先へ伝えることによって、データグラムのための通常のルーティングを変更する手段として使用される［C．Perkins, “IP Encapsulation within IP”, RFC2003, １９９６年１０月を参照]。カプセル化されたデータグラムがこの中間の宛先ノードへ到着すると、それはデカプセル化されて、最初のＩＰデータグラムが生成され、これが、最初の宛先アドレス・フィールドにより指示される宛先へ伝えられる。トンネリングの機能性を提供するＩＰリンクは、“トンネル”と呼ばれる。そして、トンネリングにおけるＩＰリンクのエンカプシュレータ及びデカプシュレータは、トンネルの“エンドポイント”に存在するように考慮される。

トンネルは、例えば、ＩＰ−ｉｎ−ＩＰエンカプシュレーション［C．Perkins, “IP Encapsulation within IP”, RFC2003, １９９６年１０月を参照］、ミニマルエンカプシュレーション［C．Perkins, “Minimal Encapsulation within IP”, RFC2004, １９９６年１０月を参照］、ジェネリックルーティングエンカプシュレーション(GRE)［D．Farinacciら, “Generic Routing Encapsulation(GRE)”, RFC2784, ２０００年３月を参照］、ＩＰｓｅｃトンネルモードエンカプシュレーション［S．Kent and R．Atkins, “Security Architecture for the Internet Protocol”, RFC 2401, １９９８年１１月を参照］に基づいてもよい。トンネルは、静的にも動的にも作成される。トンネルが、ＩＰ−ｉｎ−ＩＰエンカプシュレーション、ミニマルエンカプシュレーション又はＧＲＥに基づき、また、このトンネルが、ホームエージェントからモバイルノードへのＩＰデータグラムのトンネリングのためのＩＰ移動プロトコルにより使用される場合には、このトンネルは、モバイルＩＰｖ４［C．Perkins, “IP Mobility Support for IPv4”, RFC3344, ２００２年８月を参照］又はモバイルＩＰｖ６［C．Perkinsら, “IP Mobility Support for IPv6”, RFC3775, ２００４年６月を参照］を用いて動的に作成される。トンネルが、ＩＰｓｅｃトンネルモードエンカプシュレーションに基づく場合には、このトンネルは、ＩＫＥｖ１［D．Harkins and D．Carrel, “The Internet Key Exchange (IKE)”, RFC2409, １９９８年１１月を参照］又はＩＫＥｖ２［C．Kaufman, “Internet Key Exchange (IKEv2) Protocol”, Internet−Draft, draft−ietf−ipsec−ikev2−14.txt, work in progress, ２００４年１１月を参照］を用いて動的に作成されてもよい。適切な認証方法は、動的にトンネルを作成するための上記方法のいずれにも関係する。

参考のために、モバイルステーションは、異なるネットワーク（例えば、ＬＡＮ）上のアクセスポイントと通信できる必要がある。したがって、ＡＰのＩＰアドレスとMACアドレスとの間のマッピングが解決される必要がある。２つの好ましいＡＰ解決のためのアプローチがある。すなわち、事前に設定された解決（例えば、静的解決）と動的解決である。静的解決においては、モバイルステーションは、例えば、ＡＰからのビーコンフレームを受信する前に、近くのＡＰそれぞれのＩＰアドレス及びＭＡＣアドレスのペアのリストを得ることができる。動的解決においては、ＡＰのためのマッピングは、例えば、ＡＰからのビーコンフレーム又はこれに類するものをモバイルステーションが受信した場合に、解決することができる。

参考のために、例えば、モバイルインターネットプロトコル(モバイルＩＰ)においては、ホームエージェントは、モバイルノードのホームネットワーク上にある、例えばその気付アドレス(CoA)において特定されるような、例えばそのデバイスの現在の位置に関する情報を維持するルータを含むことができ、ホームエージェントは、例えば異なる位置から接続してもその都度デバイスのＩＰアドレスが変わらないようにするために、例えばインターネットトラフィックを転送するためのトンネリング機構を使用することができる。いくつかの場合、ホームエージェントは、移動先のネットワーク上にあるルータを含むことのできるフォーリンエージェントと協調して動作してもよい。フォーリンエージェントとホームエージェントは、(例えばインターネットエンジニアリングタスクフォース(IETF)におけるＲ．Ｆ．Ｃ．２００２仕様書において定義された）二つのタイプの移動エージェントである．
ＰＡＮＡ：
参考のために、「P.Jayaraman、 “PANA Framework”、Internet-Draft、draft-ietf-pana-framework-01.txt、work in progress、２００４年７月」からのＰＡＮＡに関する情報が本明細書の本項に組み込まれている。この点で、ＰＡＮＡは、ネットワークにアクセスを希望するノードとネットワーク側のサーバの間で実行するリンク層にとらわれないネットワークアクセス認証プロトコルである。ＰＡＮＡは、新しいＥＡＰ［B.Abobaら, “Extensible Authentication Protool(EAP)”, RFC3748, ２００４年６月を参照］を定義し、下位層ではプロトコルエンドポイント間でＩＰを使用する。

このようなプロトコルと要件を定義するための動機は、「Yegin,A．及びY.Ohba, Protocol for Carrying Authentication for Network Access(PANA)Requirements， draft-ietf-pana-requirements-08(work in progress）, ２００４年６月」に説明されている。プロトコルの詳細は、「Forsberg,D., Ohba,Y., Patil,B., Tschofenig,H.及びA.Yegin, Protocol for Carrying Authentication for Network Access(PANA), draft-ietf-pana-pana-04(work in progress）、２００４年５月」に文書化されている。「Parthasarathy,M., PANA Enabling IPsec Based Access Control, draft-ietf-pana-ipsec-03(work in progress）, ２００４年５月」は、ＰＡＮＡをベースにした認証に続くアクセス制御のためのＩＰｓｅｃの使用を説明する。ＩＰｓｅｃは、パケット単位のアクセス制御に使用できるが、それにも関わらずそれはこの機能性を達成する唯一の方法ではない。代替策は物理的セキュリティ及びリンク層暗号化を信頼することを含む。アクセス制御を施行しているエンティティからＰＡＮＡサーバを分離することは、オプションの配備の選択肢として想定されてきた。ＳＮＭＰ［Mghazli,Y., Ohba,Y.及びJ.Bournelle, SNMPUsage for PAA-2-EP Interface, draft-ietf-pana-snmp-00(work in progress), ２００４年４月を参照］が、別々のノードの間で関連した情報を伝搬するためのプロトコルとして選ばれた。
ＰＡＮＡ設計は、多様なタイプの配備にサポートを提供する。アクセスネットワークは、より下位の層のセキュリティの可用性、ＰＡＮＡエンティティの設置、クライアントＩＰ構成の選択、及び認証方法等に基づいて異なることがある。

ＰＡＮＡは根本的なセキュリティに関わりなく任意のアクセスネットワークで使用できる。例えば、ネットワークは物理的に保護される、つまりクライアント−ネットワークの認証が成功した後に暗号機構によって保護される可能性がある。

ＰＡＮＡクライアント、ＰＡＮＡ認証エージェント、認証サーバ、及び施行ポイントはこの設計では機能上のエンティティであった。ＰＡＮＡ認証エージェント及び施行ポイントは、アクセスネットワーク内の多様な要素（例えば、アクセスポイント、アクセスルータ、専用ホスト等）に対して設置できる。

ＩＰアドレス構成機構も変化する。静的構成、ＤＨＣＰ、ステートレスアドレス自動構成が選ぶために考えられる機構である。クライアントがパケット単位のセキュリティを可能にするためにＩＰｓｅｃトンネルを構成する場合、該トンネルの内部でＩＰアドレスを構成することに意味があるようになり、これらに対してＩＫＥ等の追加の選択肢が存在する。

ＰＡＮＡプロトコルはアクセスネットワークにおけるクライアントの認証と承認を容易にすることを目的としている。ＰＡＮＡは、ＥＡＰ［Aboba,B., Blunk,L., Vollbrecht,J., Carlson,J.及びH.Levkowetz, Extensible Authentication Protocol(EAP), ２００４年６月を参照］の一つであり、下位層では、アクセスネットワークにおけるクライアントホストとエージェントとの間でＥＡＰの内部にカプセル化されるＥＡＰ認証メソッドを搬送する。ＰＡＮＡはこの２つのエンティティの間で認証プロセスを可能にするが、それは全体的なＡＡＡ及びアクセス制御フレームワークの一部にすぎない。ＰＡＮＡを使用するＡＡＡとアクセス制御フレームワークは、後述されるように、及び図１（Ａ）〜図１（Ｃ）に概略で描かれている４つの機能エンティティを含む。

第１の機能エンティティは、ＰＡＮＡプロトコルのクライアントのインプリメンテーションである、ＰＡＮＡクライアント（ＰａＣ）である。このエンティティは、ネットワークアクセスを要求しているエンドホスト上に常駐する。エンドホストは、例えば、ラップトップコンピュータ、ＰＤＡ、携帯電話、デスクトップＰＣ、及び／又は有線インタフェース又は無線インタフェースを介してネットワークに接続される類似物を含むことがある。ＰａＣは、ネットワークアクセスを要求し、ＰＡＮＡプロトコルを使用して認証プロセスに従事することに関与する。

第２の機能エンティティは、ＰＡＮＡプロトコルのサーバのインプリメンテーションである、ＰＡＮＡ認証エージェント（ＰＡＡ）である。ＰＡＡはネットワークアクセスサービスについてそれらを認証し、承認するためにＰａＣと接続することを担当する。ＰＡＡはＰａＣの信用証明書（クレデンシャル）及び権利を検証するために認証サーバに相談する。認証サーバがＰＡＡと同じホストに常駐する場合は、アプリケーションプログラムインタフェース（ＡＰＩ）がこの相互作用に十分である。それらが分離されると（パブリックアクセスネットワークではより一般的な場合）、プロトコルがこの２つの間で実行するために使用される。ＬＤＡＰ［Hodges,J.及びR.Morgan, Lightweight Directory Access Protocol(v3):Technical Specification, RFC3377, ２００２年９月を参照］及びＲＡＤＩＵＳ［Rigney,C., Willens,S., Rubens,A.及びW.Simpson, Remote Authentication Dial In User Service(RADIUS), RFC2865, ２０００年６月を参照］のようなＡＡＡプロトコル、及びDiameter［Calhoun,P., Loughney,J., Guttman,E., Zorn,G.及びJ.Arkko, Diameter Base Protcol, ２００３年９月を参照］が、この目的に一般的に使用されている。

ＰＡＡは、認証状態の作成及び削除に応じてアクセス制御状態（つまり、フィルタ）を更新することにも関与する。ＰＡＡは更新された状態をネットワーク内の施行ポイントに通信する。ＰＡＡとＥＰが同じホスト上に常駐している場合、ＡＰＩがこの通信にとって十分である。それ以外の場合、プロトコルはＰＡＡからＥＰに承認されたクライアント属性を搬送するために使用される。他のプロトコルを禁止していないが、現在のＳＮＭＰ［Mghazli,Y., Ohba,Y.及びJ.Bournelle, SNMP Usage for PAA-2-EP Interface, draft-ietf-pana-snmp-00(work in progress）, ２００４年４月を参照］がこのタスクに提案されていた。

ＰＡＡは、ローカルエリアネットワークの中のネットワークアクセスサーバ（ＮＡＳ）と通常呼ばれるノードに常駐する。ＰＡＡはＰａＣと同じＩＰサブネット上の任意のＩＰによって可能にされたノード上で動作できる。例えば、ＤＳＬネットワークのＢＡＳ（ブロードバンドアクセスサーバ）で、又は３ＧＰＰ２ネットワークのＰＤＳＮで等で動作できる。

第３の機能エンティティは、ネットワークアクセスサービスを要求しているＰａＣのクレデンシャルの検証を担当するサーバのインプリメンテーションである、認証サーバ（ＡＳ）である。ＡＳはＰａＣの代わりにＰＡＡから要求を受け取り、認証パラメータ（例えば、許可された帯域幅、ＩＰ構成等）とともに検証の結果をもって応答する。ＡＳはＰＡＡと同じホストで、アクセスネットワーク上の専用ホストで、あるいはインターネット上のどこかのセントラルサーバで動作できる可能性がある。

第４の機能エンティティは、他者によるアクセスを妨げる一方で承認されたクライアントへのアクセスを許可することを担当するアクセス制御のインプリメンテーションである、施行ポイント（ＥＰ）である。ＥＰはＰＡＡから承認されたクライアントの属性を学習する。ＥＰは、非暗号フィルタ又は暗号フィルタを使用して選択的にデータパケットを許可し、廃棄する。これらのフィルタはリンク層又はＩＰ層で適用されてよい。暗号アクセス制御を使用する場合、セキュアアソシエーションプロトコルがＰａＣとＥＰの間で実行する必要がある。セキュアアソシエーションプロトコルが完全性保護、データ発信元認証、再生保護及び任意に機密性保護を可能にするために必要なセキュリティアソシエーション（security association）を確立した後、リンク又はネットワーク層保護（例えば、TKIP、IPsec ESP）が使用される。ＥＰは、承認されていないクライアントのネットワークへのアクセスを最小限に抑えるためにローカルエリアネットワーク内に戦略的に配置されなければならない。例えば、ＥＰは、有線ネットワーク内のクライアントに直接的に接続されているスイッチ上で動作できる。そのようにして、ＥＰは、それらが他のクライアントホストに到達する前に、又はローカルエリアネットワークを越える前に承認されていないパケットを削除できる。

エンティティのいくつかは、配備シナリオに応じて同一位置に配置されてよい。例えば、ＰＡＡとＥＰは、ＤＳＬネットワーク内の同じノード（ＢＡＳ）上にある可能性がある。その場合、ＰＡＡとＥＰの間では単一ＡＰＩで十分である。小企業の配備ではＰＡＡとＡＳは、この２つの間で実行されるプロトコルに対する必要性を排除する同じノード（例えば、アクセスルータ）の上で動作してよい。これらのエンティティを同一位置に配置するかそうしないかの決定、及びネットワークトポロジーの中のそれらの正確な位置が、配備の決定である。

セキュアアソシエーションのためのＩＫＥ又は４ウェイハンドシェイクプロトコルの使用は、ＰＡＮＡを実行する前に任意の下位層セキュリティがない場合にだけ必要とされていた。（例えば、ＤＳＬ等の）物理的に保護されたネットワーク又はＰＡＮＡの前にリンク層ですでに暗号により保護されているネットワーク（例えば、ｃｄｍａ２０００）は、追加のセキュアアソシエーション及びパケット単位の暗号化を必要としない。これらのネットワークはＰＡＮＡの認証と承認を、すでに使用できる下位層の安全なチャネルに結び付けることができる。

アクセスネットワーク上のＥＰが任意の承認されたＰａＣからの一般的なデータトラフィックを可能にするのに対し、それは承認されていないＰａＣのための限られたタイプのトラフィック（例えば、ＰＡＮＡ、ＤＨＣＰ、ルータ発見）だけを可能にする。これにより、新規に接続されたクライアントがＰＡＮＡに従事するための最小のアクセスサービスを有し、無制限のサービスに対して承認されることが確実になる。

ＰａＣはＰＡＮＡを実行する前にＩＰアドレスを構成する必要がある。ＰＡＮＡ認証が成功した後、配備シナリオに応じて、ＰａＣはそのＩＰアドレスを構成し直す、又は追加のＩＰアドレス（複数の場合がある）を構成する必要がある場合がある。追加のアドレス構成は、セキュアアソシエーションプロトコル実行の一部として実行されてよい。

最初に承認されていないＰａＣは、アクセスネットワーク上でＰＡＡを発見し、後にＰＡＮＡ上でのＥＡＰの交換が続くことによってＰＡＮＡ認証を開始する。ＰＡＡはこのプロセスの間にＡＳと相互に作用する。認証及び承認の結果をＡＳから受信すると、ＰＡＡはＰａＣにそのネットワークアクセス要求の結果について知らせる。

ＰａＣがネットワークにアクセスすることを承認されている場合、ＰＡＡはＳＮＭＰを使用することによりＥＰにＰａＣ特有の属性（例えば、ＩＰアドレス、暗号キー等）も送信する。ＥＰはＰａＣから及びＰａＣへのデータトラフィックが通過できるようにするためにそのフィルタを改変するためにこの情報を使用する。

ＰＡＮＡ認証後に暗号アクセス制御が可能にされる必要がある場合、セキュアアソシエーションプロトコルがＰａＣとＥＰの間で実行する。ＰａＣはＰＡＮＡ交換が成功した結果としてすでにこのプロセスに対する入力パラメータを持っているはずである。同様に、ＥＰはＳＮＭＰを介してＰＡＡからそれらを取得するはずである。セキュアアソシエーション交換により、ＰａＣとＥＰとの間に必要とされるセキュリティアソシエーションが生じ、暗号データトラフィック保護が可能になる。パケット単位の暗号データトラフィック保護が追加のパケット単位のオーバヘッドを導入するが、オーバヘッドはＰａＣとＥＰの間だけに存在し、ＥＰを超えて通信に影響を及ぼさないであろう。この意味で、ネットワークの端の可能な限り近くにＥＰを配置することが重要である。

最後に、データトラフィックが新規に承認されたＰａＣから及びＰａＣに流れ始めることができる。

ＩＰｓｅｃのブートストラッピングによるＰＡＮＡ
「P．Jayaraman, “PANA Framework”, Internet−Draft, draft−ietf−pana−framework−01．txt, work in progress, ２００４年７月」にて議論されているように、このモデルにおいて、データトラフィックは、ＩＰｓｅｃトンネルモードのＳＡを用いることによって保護され、ＩＰアドレスは、ＰａＣのデバイス識別子として使用される。ＡＰのいくつか又は全て、ＤＨＣＰｖ４サーバ(ＰＲＰＡのＤＨＣＰｖ４サーバ及びＩＰｓｅｃ−ＴＩＡのＤＨＣＰｖ４サーバを含む)、ＤＨＣＰｖ６サーバ、ＰＡＡ及びＥＰは、単一の機器に配置されてもよい。ＥＰは、ＡＲ（アクセスルータ）と同一位置に配置される。また、ＥＰは、ＰＡＡと同一位置に配置されてもよい。ＥＰ及びＰＡＡが同一位置に配置されない場合、ＰＡＡ−ＥＰプロトコルは、ＰＡＡとＥＰとの間の通信のために使用される。

ＰＡＮＡデバイス識別子
参考のために、現在のＰＡＮＡの仕様書（http://www．ietf．org/internet−drafst/draft−ietf−pana−pana−10．txt）において、“デバイス識別子”(DI)は、デバイスのネットワークアクセスを制御し及び取り締まるためのハンドルとしてネットワークにより使用される識別子として定義されている。アクセス技術に応じて、この識別子は、プロトコルヘッダにより伝送されるアドレス（例えば、ＩＰ層又はリンク層のアドレス）、又は接続された機器のローカルプロトコルスタックにより利用できるように作成された、ローカルに重要な識別子（例えば、回路ＩＤ、PPPインタフェースＩＤ）を含んでもよい。

ＰＡＮＡ移動操作
ＰＡＮＡ移動操作（PANA Mobility Operations）というタイトルのＰＡＮＡワーキンググループのドキュメント（draft−ietf−pana−mobopts−00．txt 1で見つけられる）の全開示は参照してここに組み込まれる。このドキュメントは、ＰＡＮＡを用いたＰＡＮＡ認証クライアント(PaC)は、サブネット間（例えば、ＰＡＡ間）移動においてＥＡＰ／ＰＡＮＡを完全に実行することが要求されることを説明し、及びシームレスな移動が要求される場合に、ＡＡＡサーバによる完全なＥＡＰ認証を実行する必要のあることが、望ましくないレイテンシを引き起こすであろうことを説明する。それゆえに、ＰａＣがＰＡＡ間のハンドオーバーを遂行する毎にＥＡＰを実行する必要を除去するために、このドキュメントのアウトラインは、ベースのＰＡＮＡの仕様書を拡張する。このスキームは、実在している他のＰＡＡとのセッションに基づく新たなＰＡＡとの新たなＰＡＮＡセッションの作成を許容する。このドキュメントは、新たなＰＡＮＡセッションの生成は、ＥＡＰベースの認証の実行を要求しないが、その代わりに、前のＰＡＡから新たなＰＡＡへ適切な状態情報を届けるために、コンテキスト転送ベースのスキームが使用される。参考のために、移動性を最適化したＰＡＮＡの実行を描写したコールフローは、前記ドキュメントに示されている。前記ドキュメントは、次のフローを説明している。すなわち、ＰａＣが既に承認されサブネット１に接続され、ここに前ＰＡＡが存在し、そして、ＰａＣがサブネット１からサブネット２へのハンドオーバーを遂行し、そして、ＰＡＮＡディスカバリーとハンドシェイクのフェイズが実行され、そして、ＰＳＡに含まれるパラメータに応答して、ＰＡＮＡセッションのコンテキストが前ＰＡＡから新ＰＡＡへ転送され、最後に、ＰＡＮＡバインドが、ＰＡＮＡ認証の成功の信号を交換する。ＥＡＰ認証は発生しない。結果として、モバイルＰａＣのネットワークアクセス認証の遂行は、コンテキスト転送ベースの機構を配置することによって、強化することができ、ここで、いくつかのセッション属性は、完全なＥＡＰ認証を遂行することを避けるために、前ＰＡＡから新ＰＡＡへ転送される。

本発明は、前記及び／又は他の背景技術及び／又はその中の課題を改良する。

本発明の好ましい実施形態は、前記現存する技術に見られる欠点を克服する。

いくつかの実施形態に従って、モバイル機器のための動的かつ安全なトンネル確立方法は、コミュニケーションのアドレスのために、認証プロトコルのソースポート番号の使用に基づく認証結果に応じて、1以上のトンネルのエンドポイントのアドレスを、認証エージェントと同一のＩＰリンク上には存在しないクライアントに動的に割り当てることを含んで提供される。

いくつかの例において、前記方法は、同一のＩＰリンク上に存在しないクライアントと認証エージェントとの間でプロトコルが動作することを許容するために、該クライアント又は認証エージェントのＩＰアドレスだけでなく、該クライアント又は認証エージェントから送信されたメッセージのソースポート番号も、該クライアント又は認証エージェントのデバイス識別子として使用されることを更に含む。

いくつかの例において、前記方法は、ＰＡＮＡ認証の結果に応じて、1以上のトンネルのエンドポイントのアドレスを、ＰＡＮＡ認証エージェントと同一のＩＰリンクには存在しないＰＡＮＡクライアントに動的に割り当てることを含む。

いくつかの例において、前記方法は、同一のネットワークアドレス変換ルータの背後に存在するであろう複数のクライアントを識別できるように、前記クライアントのＩＰアドレス及び該記クライアントから送信された認証メッセージのＵＤＰソースポート番号を、該クライアントのデバイス識別子として使用することを更に含む。

いくつかの例において、前記方法は、同一のＩＰリンク上に存在しないＰＡＮＡクライアントとＰＡＮＡ認証エージェントとの間でＰＡＮＡプロトコルが動作することを許容するために、前記ＰＡＮＡクライアント又はＰＡＮＡ認証エージェントのＩＰアドレスだけでなく、同一のネットワークアドレス変換ルータの背後に存在するであろう複数のＰＡＮＡクライアントを識別できるように該ＰＡＮＡクライアント又はＰＡＮＡ認証エージェントから送信されたＰＡＮＡメッセージのＵＤＰソースポート番号も、該ＰＡＮＡクライアント又はＰＡＮＡ認証エージェントのデバイス識別子として使用されることを更に含む。

いくつかの例において、前記方法は、クライアントは、認証セッションを開始させる最初のディスカバーメッセージ及びこれに続く認証メッセージを、ＵＤＰ宛先ポートとして認証プロトコルのために割り当てられたＵＤＰポート番号を指定して、前記認証エージェントに送信し、該認証エージェントは、認証メッセージを、ＵＤＰ宛先ポートとして前記最初のディスカバーメッセージのＵＤＰソースポートを指定して、該クライアントへ送信することを更に含む。

いくつかの例において、前記方法は、ＰＡＮＡクライアントは、ＰＡＮＡ−ＰＡＡ−Ｄｉｓｃｏｖｅｒ（ＰＤＩ）及びこれに続くＰＡＮＡ認証メッセージを、ＵＤＰ宛先ポートとしてＰＡＮＡのために割り当てられたＵＤＰポート番号を指定して、前記ＰＡＮＡ認証エージェントに送信することによってＰＡＮＡセッションを開始し、該ＰＡＮＡ認証エージェントは、ＰＡＮＡ−Ｓｔａｒｔ−Ｒｅｑｕｅｓｔ及びこれに続くＰＡＮＡ認証メッセージを、ＵＤＰ宛先ポートとして前記ＰＤＩのＵＤＰソースポートを指定して、該ＰＡＮＡクライアントへ送信することを更に含む。

いくつかの例において、前記方法は、ネットワークアドレスルータがクライアントと認証エージェントとの間に存在する場合に、前記ネットワークアドレスルータがそのアドレス変換状態を消去することを阻止することを更に含む。いくつかの例において、前記方法は、前記ネットワークアドレスルータがそのアドレス変換状態を消去することを阻止するように、ピアライブネステストのために定義されたＰＡＮＡメッセージ変換を遂行することを更に含む。

いくつかの例において、前記方法は、同一のＩＰリンク上に存在しない認証エージェントとのセッションを確立したクライアントが、それが新たなＩＰリンクに移動することを知っている場合に、移動ハンドリング手順を行うことを更に含む。

多様な実施形態の前記の及び／又は他の態様、特長及び／又は利点は、添付図面に関連して以下の説明を鑑みるとさらに理解されるであろう。多様な実施形態は、当てはまる場合、様々な態様、特長、及び／又は利点を含む、及び／又は除くことができる。加えて、多様な実施形態は、当てはまる場合、他の実施形態の１つ又は複数の態様又は特長を組み合わせることができる。特定の実施形態の態様、特長、及び／又は利点の説明は、他の実施形態又は請求項を制限するとして解釈されてはならない。

本発明の好ましい実施形態は、制限ではなく一例として添付図に示されている。

本発明は多くの異なる形式で具現化されてよいが、多くの例示的な実施形態は、本開示が本発明の原則の例を提供すると見なされるべきである旨、及びこのような例が、本明細書に説明されている、及び／又は本明細書に描かれている好ましい実施形態に本発明を制限することを目的としていない旨を理解した上で本明細書に説明されている。

現存する方法に関する問題点：
動的にトンネルを確立するための現存する方法は、例えば以下に示すような様々な問題を有する。

・モバイルＩＰｖ４及びモバイルＩＰｖ６のようなＩＰ移動性管理プロトコルは、動的にトンネルを確立するために、必ずしも常に必要ではない。

・モバイルＩＰｖ４及びＩＫＥｖ１は、多数の認証メソッドがサポートされているＥＡＰ(Extensible Authentication Protocol)［RFC3748参照］をサポートしない。ＥＡＰの最近の激増を考慮すると、ＥＡＰ認証を含む安全なトンネル確立方法が必要である。

・現存する方法は、トンネルのエンドポイントを、他のエンドポイントへ（例えば、新たなエンドポイントへ）、該他のエンドポイントの認証結果に応じて、動的に割り当てることをサポートしない。

・ＩＫＥｖ２はＥＡＰ認証をサポートするが、ＩＫＥｖ２シグナリング及びＡＰ認証は、とても固く連結されているので、ＩＫＥ＿ＳＡ(IKE Security Association)が確立された場合、ＥＡＰ再認証が遂行される必要があり、これは、一つのエンドポイントから異なる複数のエンドポイントへ複数のトンネルが確立された場合に、能率が悪い。ＰＡＮＡ（Protocol for Carrying Authentication for Network Access）フレームワーク［P．Jayaraman, “PANA Framework”, Internet−Draft, draft−ietf−pana−framework−01．txt, work in progress, ２００４月を参照］は、ＰＡＮＡクライアントが、異なるＩＰｓｅｃゲートウェイにより、複数のＩＰｓｅｃトンネルモードのＳＡを確立することを許容する。しかしながら、現在のＰＡＮＡフレームワークは、ＰＡＮＡクライアントがＰＡＮＡ認証エージェントから１より多いＩＰホップだけ離れているケースを、完全にはサポートしない。この点で、一つのＩＰホップは、ネットワークにおいてデータパケットが一つのルータ又は中間のポイントから他のルータ又は中間のポイントへ進むという移動に関連し、“ホップカウント”は、パケットがその宛先へ向けて取るホップ数である。

総論：
図１（Ａ）、図１（Ｂ）、図１（Ｃ）及び図２は、本発明のいくつかの実施形態で採用されてもよい、いくつかの例示的なアーキテクチャー要素を描いている。この点で、図１（Ａ）は、ＰＡＮＡを用いたいくつかの例示的な実施に従って4つの基本的な機能要素、すなわち、ＰＡＮＡクライアント（ＰａＣ）、ＰＡＮＡ認証エージェント（ＰＡＡ）、認証サーバ（ＡＳ）及び施行ポイント（ＥＰ）を例示する概略図である。図１（Ｂ）は、いくつかの例示的な実施に従って第1のアクセスポイント（ＡＰ）及び第２のアクセスポイント（ＡＰ）と通信するモバイルクライアントを描いた概略図である。図１（Ｃ）は、いくつかの例示的な実施に従って採用されてもよいオーセンティケータ及びクライアントの機能要素を例示する概略図であり、ここで、オーセンティケータは、とりわけＥＡＰサーバ及びＰＡＮＡサーバ（ＰＡＡ）の機能を含み、一方、クライアントは、とりわけＥＡＰクライアント及びＰＡＮＡクライアント(PaC)の機能を含む。図２は、ＩＰｓｅｃトンネリングによって、同時に複数のＶＰＮを確立するような方法で、第1のアクセスルータ（ｐＡＲ）及び第２のアクセスルータ（ｎＡＲ）と通信するモバイルクライアントを描いた概略図である。

好ましい実施形態は、ＰＡＮＡ認証に含まれるＥＡＰにより、動的かつ安全にトンネルを確立するための方法を提供することができる、提案された解決策を提供する。好ましい実施形態において、提案された解決策は、ＰＡＮＡプロトコル［D．Forsbergら, Protocol for Carrying Authentication for Network Access(PANA), Internet−Draft, draft−ietf−pana−pana−05．txt, work in progress, ２００４年７月を参照］を、ＰＡＮＡ認証エージェントと同一のＩＰリンク上に位置することが必要ないＰＡＮＡクライアントへ、ＰＡＮＡ認証の結果に応じて、1以上のトンネルのエンドポイントのアドレスを動的に割り当てることができるようなプロトコルに拡張して使用する。ＰＡＮＡプロトコルに対する次の拡張が、この提案において定義される。

好ましい実施形態において、同一のＩＰリンク上に位置しないＰＡＮＡクライアント(PaC)とＰＡＮＡ認証エージェント(PAA)との間でＰＡＮＡプロトコルを動作することを許容するために、例えば同一のネットワークアドレス変換(NAT)ルータ又はこれに類するものの背後にさえ存在するであろう複数のＰＡＮＡクライアントを識別できるように、ＰａＣからＰＡＡへ送信されるメッセージについては、好ましくは、ＰＡＮＡクライアントのＩＰアドレスだけでなく、ＰＡＮＡクライアントから送信されるＰＡＮＡメッセージのＵＤＰ(User Datagram Protocol)ソースポート番号も、ＰＡＮＡクライアントのデバイス識別子として使用される（及び、ＰＡＡからＰａＣへ逆方向に送信されるメッセージについては、好ましくは、ＰＡＡのＩＰアドレスだけでなく、ＰＡＮＡ認証エージェントから送信されるＰＡＮＡメッセージのＵＤＰソースポート番号も、ＰＡＮＡのデバイス識別子として使用される）。ＰＡＮＡは、そのトランスポートレイヤプロトコルとしてUDPを使用することに注意する。また、ＮＡＴは、一般的に、パブリックネットワーク（例えば、インターネット）とプライベートネットワーク（例えば、ローカルエリアネットワーク）との間のエージェントとして動作するルータのような単一デバイスを含むこと、及び、例えば、単一固有のＩＰアドレスが、そのプライベートネットワークの外側にあるエンティティに対するコンピュータ又はデバイスのグループを表すことを可能にすることに注意する。ＮＡＴルータは、本質的に、前記プライベートネットワークへ入って行く及びそこから出て行くトラフィックを変換する。

好ましい実施形態において、ＮＡＴの環境下で動作するＰＡＮＡを作るために、ＰＡＮＡクライアントは、ＰＡＮＡ−ＰＡＡ−Ｄｉｓｃｏｖｅｒ（ＰＤＩ）及びこれに続くすべてのＰＡＮＡメッセージを、ＵＤＰ宛先ポートとしてＰＡＮＡに割り当てられたＵＤＰポート番号を指定して、ＰＡＮＡ認証エージェントへ送信することによって、常に、ＰＡＮＡセッションの開始者になることができ（注意（ＮＢ）：好ましい実施形態において、このＵＤＰポート番号は、予め割り当てられたポート番号であろう）、及び、ＰＡＮＡ認証エージェントは、ＰＡＮＡ−Ｓｔａｒｔ−Ｒｅｑｕｅｓｔ及びこれに続くすべてのＰＡＮＡメッセージを、該メッセージのＵＤＰ宛先ポートとしてＰＤＩのＵＤＰソースポート番号を指定して、ＰＡＮＡクライアントへ送信することができる（注意（ＮＢ）：好ましい実施形態において、このＵＤＰポート番号は、ＮＡＴによって割り当てられるであろう）。参考のために、ＰＡＮＡ−ＰＡＡ−Ｄｉｓｃｏｖｅｒ（ＰＤＩ）メッセージは、ＰａＣによりＰＡＡへ送信され、ＰＡＡのアドレスを発見するために使用され、一方、ＰＡＮＡ−Ｓｔａｒｔ−Ｒｅｑｕｅｓｔ（ＰＳＲ）は、ＰＡＡによりＰａＣへ送信されることに注意する。

また、参考のために、ＰＡＮＡ−Ｂｉｎｄ−Ｒｅｑｕｅｓｔ及びＰＡＮＡ−Ｂｉｎｄ−Ａｎｓｗｅｒメッセージの交換は、ＰａＣ及びＥＰのデバイス識別子と、ＰＡＮＡ ＳＡに対するＰＡＡのＩＰアドレスとのバインドのために用いられてきた。ＩＰｓｅｃベースのセキュリティがアクセス制御の選択であったときは、ＰＡＡは、ＥＰのデバイスＩＤとしてＩＰアドレスを提供したであろうし、また、ＰａＣが代わりにＩＰアドレスを提供することを予期したであろう。しかしながら、例えば、デバイス識別子の一部としてソースポート番号を更に含むことによって、前述のように、十分な利点が得られる。

前述のように、現在のＰＡＮＡの仕様書における“デバイス識別子”の定義（http://www．ietf．org/internet−drafst/draft−ietf−pana−pana−10．txt）は、デバイス識別子の内部で使用されるＵＤＰポート番号を収容しない定義を意味する。言い換えると、好ましい実施形態において、デバイス識別子の現在の定義は、前述のような方法においてＵＤＰポート番号を含むように再定義される。好ましい実施形態において、デバイス識別子は、そのように、複数のクライアント又は認証エージェントを識別できる能力を含むように再定義される。よって、好ましい実施形態において、デバイス識別子は、複数のクライアント又は認証エージェントを識別できるように、該クライアント又は該認証エージェントの“識別ＩＤ（distinguishment identifier）”としても作用する。

図３は、本発明のいくつかの好ましい実施形態に従っていくつかの特徴を描くのを助ける概略的なダイアグラムである。

この点で、１１０に示されるように、好ましい実施形態は、有益に“ＰＡＮＡクライアントのＩＰアドレス及びＰＡＮＡクライアントから送信されたＰＡＮＡメッセージのＵＤＰソースポート番号をデバイス識別子として使用する”。加えて、１１５に示されるように、好ましくは、“ＰＡＮＡクライアントは、ＰＡＮＡ−ＰＡＡ−Ｄｉｓｃｏｖｅｒ（ＰＤＩ）と、これに続く全てのメッセージを、ＵＤＰ宛先ポートとしてＰＡＮＡに割り当てられたＵＤＰポート番号を指定して、ＰＡＮＡ認証エージェントへ送信することによって、ＰＡＮＡセッションの開始者になる”。

更に、１２０に示されるように、好ましい実施形態は、有益に“ＰＡＮＡ認証エージェントのＩＰアドレス及びＰＡＮＡ認証エージェントから送信されたＰＡＮＡメッセージのＵＤＰソースポート番号をデバイス識別子として使用する”。加えて、１２５に示されるように、好ましくは、“ＰＡＮＡ認証エージェントは、ＰＡＮＡ−Ｓｔａｒｔ−Ｒｅｑｕｅｓｔと、これに続く全てのメッセージを、該メッセージのＵＤＰ宛先ポートとして前記ＰＤＩのＵＤＰソースポート番号を指定して、前記ＰＡＮＡクライアントへ送信する”。

そこで、１３０に示されるように、好ましい実施形態は、それによって、“ＮＡＴ（ネットワークアドレス変換）ルータの背後に存在するであろう複数のＰＡＮＡクライアントの識別”を可能にする。

さらに、１４０に示されるように、好ましい実施形態は、それによって、”一つのエンドポイントから異なる複数のエンドポイントへの複数のトンネルの確立（例えば、異なるＩＰｓｅｃゲートウェイとの複数のＩＰｓｅｃトンネルモードのＳＡの確立）”を可能にする。

さて、図４を参照すると、この図は、本発明のいくつかの例示的な実施形態に従ってメッセージフローを例示するダイアグラムである。特に、図４は、ＮＡＴを通したＰａＣとＰＡＡとの間のメッセージフローを、図４に示されるように、ＰＡＮＡ−ＰＡＡ−Ｄｉｓｃｏｖｅｒメッセージで始まり、複数のＩＰｓｅｃゲートウェイのためのＩＰｓｅｃトンネルの確立まで描いている。

さて、図５を参照すると、この図は、本発明のいくつかの例示的な実施形態に従ってクライアント（ＰａＣ）と認証エージェント（ＰＡＡ）との間のメッセージの転送におけるメッセージ情報を例示するダイアグラムである。特に、示されるように、ＰａＣからＰＡＡへのメッセージについては、最初に、ソースＩＰアドレスは、ＮＡＴ通過前については、ＰａＣのアドレスであり、ＮＡＴ通過後については、ＮＡＴのアドレスである。加えて、宛先ＩＰアドレスは、最初のＰＡＮＡ−ＰＡＡ−Ｄｉｓｃｏｖｅｒメッセージについては、マルチキャストアドレスであり、後の全てのメッセージについては、ＰＡＡのＩＰアドレスである。加えて、ソースポートは、示されるように、ＮＡＴ通過前については、（一例として）Ｐ１であり、ＮＡＴ通過後については、（一例として）Ｐ２である。そして、宛先ポートは、ＰＡＮＡポートである。

他方、ＰＡＡからＰａＣへの逆方向のメッセージについては、ソースＩＰアドレスは、ＰＡＡのＩＰアドレスである。加えて、宛先ＩＰアドレスは、ＮＡＴ通過前については、ＮＡＴのアドレスであり、ＮＡＴ通過後については、ＰａＣのアドレスである。加えて、ソースポートは、ＰＡＮＡポートである。そして、宛先ポートは、示されるように、ＮＡＴ通過前については、Ｐ２であり、ＮＡＴ通過後については、Ｐ１である。

トンネルのエンドポイントの割り当て：
好ましい実施形態は、動的にトンネルを確立するために、ＰＡＮＡの仕様書で既に定義されているメソッドを使用することができる。すなわち、ＩＰｓｅｃトンネルモードは、トンネリングメソッドとして使用することができ、1以上のトンネルのエンドポイントは、ＰＡＮＡ−Ｂｉｎｄ−Ｒｅｑｕｅｓｔメッセージにおいて運ばれるＥＰ−Ｄｅｖｉｃｅ−Ｉｄ ＡＶＰ(属性値ペア)を通したＰＡＮＡシグナリングにおいて特定することができる。提案されたスキームは、好ましくは、ＩＰｓｅｃトンネルモードを使用する。なぜならば、それは、安全なトンネルを提供し、また、ＮＡＴの環境下においてさえ動作するからである。ＩＰｓｅｃトンネルは、好ましくは、ＩＫＥｖ１又はＩＫＥｖ２を用いて確立される。ここで、要求されたＩＫＥクレデンシャルは、［M．Parthasarathy, “PANA Enabling ＩＰｓｅｃ Based Access Control”, Internet−Draft, draft−ietf−pana−ipsec−03．txt, ２００４年５月］で詳述された方法を用いることによって、ＰＡＮＡからブートストラップされる。

ＮＡＴ状態の保持：
いくつかの場合、ＮＡＴルータは、あるＮＡＴ状態を維持される。例として、ＮＡＴルータがＰＡＮＡクライアントとＰＡＮＡ認証エージェントとの間に存在する場合に、ＮＡＴがそのアドレス変換状態を消去することを阻止するようにするために、ピアライブネステストのために定義されたＰＡＮＡメッセージ交換（例えば、PANA−Reauth−Request／Answer）が、ある頻度（例えば、ある時間間隔で）遂行されることができる。

移動ハンドリング：
いくつかの例では、ＰａＣは、あるＰＡＡからもう一つのＰＡＡへ移動するモバイルＰａＣであってもよい。いくつかの実施形態では、ＰＡＮＡクライアントが、同一のＩＰリンク上に存在しないＰＡＮＡ認証エージェントとのＰＡＮＡセッションを確立した場合、それが新たなＩＰリンクへ移動することを知っていれば、同一のＰＡＮＡ移動ハンドリング手順を遂行することができる。

この点で、ある現存するＰＡＮＡ移動ハンドリング手順は、ＰＡＮＡワーキンググループの次のドキュメント、（１）PANA Mobility Operations found at draft−ietf−pana−mobopts−00．txt及び（２）Preauthentication Support For PANA by Y．Ohba（http://www．ietf．org/internet−drafts/draft−bournelle−pana−ctp−03．txtで見つけられる）、において見つけることができる。これらドキュメントは、コンテント転送プロトコル(CTP)に基づく移動性最適化メソッドを記述している。上記ドキュメント（１）は、ＣＴＰのためのＰＡＮＡプロトコルの拡張を記述し、（２）は、ＰＡＮＡへのＣＴＰの拡張を記述する。ドキュメント（１）及び（２）の全開示は、参照してここに組み込まれる。更なる参考のために、次の米国仮特許出願の全開示も、参照してここに組み込まれる。（１）２００５年６月１３日出願のY.Ohbaの米国特許出願第６０／５９５，１６９号明細書（発明の名称“Framework of Media Independent Pre-Authentication Support for PANA”）及び（２）２００５年２月４日出願の米国特許出願第６０／６４９，５５４号明細書（発明の名称“Framework of Media Independent Pre-Authentication filed”）
本発明の幅広い範囲：
本発明の例示的な実施形態を本明細書に説明してきたが、本開示に基づいて当業者により理解されるように、本発明は本明細書に説明されている多様な好ましい実施形態に限定されるのではなく、同等な要素、変型、省略、（例えば、多様な実施形態全体での態様の）組み合わせ、適応、及び／又は改変を有するあらゆるすべての実施形態を含む。（例えば、後に加えられるものを含む）請求項における制限は請求項で利用される言語に基づいて幅広く解釈されるべきであり、本明細書に、あるいは出願の手続き追行の間に説明される例に限定されず、その例は包括的と解釈されるべきである。例えば、本開示では、用語「好ましくは」は包括的であり、「好ましいが、限定されない」を意味する。本開示では、及び本開示の手続き追行中、手段プラス機能（means-plus-function）又はステッププラス機能（step-plus-function）の制限は、特定の請求項の制限について、以下の条件のすべてがその制限内に存在する場合にだけ利用される。つまりａ）「のための手段」又は「のためのステップ」は、明示的に列挙され、ｂ）対応する機能は明示的に列挙され、及びｃ）その構造をサポートする構造、材料又は行為が列挙される。本開示において、及び本出願の手続き追行中、用語「本発明」又は「発明」は、本開示の中で１つ又は複数の態様に対する参照として使用されてよい。言語本発明又は発明は、臨界の識別として理解されてはならず、すべての態様又は実施形態全体で当てはまると不適切に解釈されてはならず（つまり、本発明は多数の態様と実施形態を有することが理解されるべきである）、出願つまり請求項の範囲を制限すると不適切に解釈されてはならない。本開示では、及び本願の手続き追行の間、用語「実施形態」は任意の態様、特徴、プロセス又はステップ、その組み合わせ、及び／又はその任意の部分等を説明するために使用できる。いくつかの例では、多様な実施形態は重複する特長を含むことがある。本開示では、以下の省略された用語、つまり「例えば」を意味する「ｅ．ｇ．」が利用されてよい。

いくつかの例示的な実施に従ってオーセンティケータ及びクライアントの機能要素を例示する概略図である。 ＰＡＮＡを用いたいくつかの例示的な実施に従って基本的な機能要素を例示する概略図である。 いくつかの例示的な実施に従って第1のアクセスポイント（ＡＰ）及び第２のアクセスポイント（ＡＰ）と通信するモバイルクライアントを描いた概略図である。 ＩＰｓｅｃトンネリングによって、同時に複数のＶＰＮを確立するような方法で、第1のアクセスルータ（ｐＡＲ）及び第２のアクセスルータ（ｎＡＲ）と通信するモバイルクライアントを描いた概略図である。 本発明のいくつかの好ましい実施形態に従っていくつかの特徴を描くのを助ける概略的なダイアグラムである。 本発明のいくつかの例示的な実施形態に従ってメッセージフロー例を例示するダイアグラムである。 本発明のいくつかの例示的な実施形態に従ってクライアント（ＰａＣ）と認証エージェント（ＰＡＡ）との間のメッセージの転送におけるメッセージヘッダ情報の例を例示するダイアグラムである。

Claims (15)

1. モバイル機器のための動的かつ安全なトンネル確立方法であって、
   コミュニケーションのアドレスのために、認証プロトコルのソースポート番号の使用に基づく認証結果に応じて、１以上のトンネルのエンドポイントのアドレスを、認証エージェントと同一のＩＰリンク上には存在しないクライアントに動的に割り当てることを含み、
   同一のＩＰリンク上に存在しないクライアントと認証エージェントとの間でプロトコルが動作することを許容するために、該クライアントのデバイス識別子が、複数のクライアントの識別を可能にするために再定義されるように、該クライアントのＩＰアドレスだけでなく、複数のクライアントを識別できるように該クライアントから送信されたメッセージのソースポート番号も、該クライアントのデバイス識別子として使用されることを更に含み、
   前記認証エージェントのデバイス識別子が、複数の認証エージェントの識別を可能にするために再定義されるように、前記認証エージェントのＩＰアドレスだけでなく、該認証エージェントから送信されたメッセージのソースポート番号も、該認証エージェントのデバイス識別子として使用されることを更に含み、
   前記クライアントから異なる複数のエンドポイントへの複数のＩＰｓｅｃトンネルを確立すること（他のエンドポイントに関する認証結果に応じて、トンネルのエンドポイントを新たなエンドポイントに動的に割り当てることを含む）を更に含み、
   先行するＰＡＮＡ認証の結果に応じて、トンネルのエンドポイントのアドレスを、ＰＡＮＡ認証エージェントと同一のＩＰリンク上には存在しないＰＡＮＡクライアントに動的に割り当てるように、ＰＡＮＡプロトコルを拡張することを更に含み、
   ここで、同一のＩＰリンク上に存在しないＰＡＮＡクライアントとＰＡＮＡ認証エージェントとの間でＰＡＮＡプロトコルが動作することを許容するために、（ａ）該ＰＡＮＡクライアントから該ＰＡＮＡ認証エージェントへ送信されるメッセージについて、該ＰＡＮＡクライアントのＩＰアドレスだけでなく、該ＰＡＮＡクライアントから送信される該ＰＡＮＡメッセージのソースポート番号も、該ＰＡＮＡクライアントのＰＡＮＡデバイス識別子として使用され、及び、（ｂ）該ＰＡＮＡ認証エージェントから該ＰＡＮＡクライアントへ送信されるメッセージについて、該ＰＡＮＡ認証エージェントのＩＰアドレスだけでなく、該ＰＡＮＡ認証エージェントから送信されたＰＡＮＡメッセージの前記ソースポート番号も、該ＰＡＮＡ認証エージェントのＰＡＮＡデバイス識別子として使用される方法。
2. モバイル機器のための動的かつ安全なトンネル確立方法であって、
   コミュニケーションのアドレスのために、認証プロトコルのソースポート番号の使用に基づく認証結果に応じて、１以上のトンネルのエンドポイントのアドレスを、認証エージェントと同一のＩＰリンク上には存在しないクライアントに動的に割り当てることを含み、
   ここで、前記方法は、前記ＰＡＮＡ認証の結果に応じて、１以上のトンネルのエンドポイントのアドレスを、ＰＡＮＡ認証エージェントと同一のＩＰリンク上には存在しないＰＡＮＡクライアントに動的に割り当てることを含み、
   同一のネットワークアドレス変換ルータの背後に存在する複数のクライアントを識別できるように、前記クライアントのＩＰアドレス及び該クライアントから送信された認証メッセージのＵＤＰソースポート番号を、該クライアントのデバイス識別子として使用することを更に含み、
   同一のＩＰリンク上に存在しないＰＡＮＡクライアントとＰＡＮＡ認証エージェントとの間でＰＡＮＡプロトコルが動作することを許容するために、前記ＰＡＮＡクライアント又はＰＡＮＡ認証エージェントのＩＰアドレスだけでなく、同一のネットワークアドレス変換ルータの背後に存在する複数のＰＡＮＡクライアントを識別できるように該ＰＡＮＡクライアント又はＰＡＮＡ認証エージェントから送信されたＰＡＮＡメッセージの前記ＵＤＰソースポート番号も、該ＰＡＮＡクライアント又はＰＡＮＡ認証エージェントのデバイス識別子として使用されることを更に含み、
   前記クライアントから異なる複数のエンドポイントへの複数のＩＰｓｅｃトンネルを確立すること（他のエンドポイントに関する認証結果に応じて、トンネルのエンドポイントを新たなエンドポイントに動的に割り当てることを含む）を更に含み、
   先行するＰＡＮＡ認証の結果に応じて、トンネルのエンドポイントのアドレスを、ＰＡＮＡ認証エージェントと同一のＩＰリンク上には存在しないＰＡＮＡクライアントに動的に割り当てるように、ＰＡＮＡプロトコルを拡張することを更に含む方法。
3. 前記ＰＡＮＡクライアントは、ＰＡＮＡ−ＰＡＡ−Ｄｉｓｃｏｖｅｒ（ＰＤＩ）及びこれに続くＰＡＮＡ認証メッセージを、ＵＤＰ宛先ポートとしてＰＡＮＡのために割り当てられたＵＤＰポート番号を指定して、前記ＰＡＮＡ認証エージェントに送信することによってＰＡＮＡセッションを開始し、該ＰＡＮＡ認証エージェントは、ＰＡＮＡ−Ｓｔａｒｔ−Ｒｅｑｕｅｓｔ及びこれに続くＰＡＮＡ認証メッセージを、ＵＤＰ宛先ポートとして前記ＰＤＩのＵＤＰソースポートを指定して、該ＰＡＮＡクライアントへ送信することを更に含む請求項１または２に記載の方法。
4. ＰＡＮＡ認証メッセージ交換を実行することを更に含み、
   前記ＰＡＮＡ認証メッセージ交換を実行することは、
   前記ＰＡＮＡクライアントは、ＰＡＮＡ−ＰＡＡ−Ｄｉｓｃｏｖｅｒ（ＰＤＩ）及びこれに続くＰＡＮＡメッセージを、ＰＡＮＡのために割り当てられたＵＤＰポート番号を指定して、ネットワークアドレス変換ルータの背後の前記ＰＡＮＡ認証エージェントに送信することによって、ＰＡＮＡセッションの開始者になることと、
   前記ＰＡＮＡ認証エージェントが、ＰＡＮＡ−Ｓｔａｒｔ−Ｒｅｑｕｅｓｔ及びこれに続くＰＡＮＡメッセージを、前記ＰＤＩのＵＤＰソースポートを指定して、該ＰＡＮＡクライアントに送信することと、
   前記ＰＡＮＡ認証エージェント及び前記ＰＡＮＡクライアントが、前記ＰＡＮＡクライアントと前記複数のエンドポイントのそれぞれとをバインディングするために、ＰＡＮＡ−Ｂｉｎｄ−Ｒｅｑｕｅｓｔ及びＰＡＮＡ−Ｂｉｎｄ−Ａｎｓｗｅｒメッセージ交換を実行することを含む請求項１または２に記載の方法。
5. 複数のＩＰｓｅｃゲートウェイのために確立されたＩＫＥの信用証明書を使用することを含む前記ＰＡＮＡ認証メッセージ交換に基づいて、複数のＩＰｓｅｃトンネルを確立することを更に含み、
   前記ＩＫＥの信用証明書は、ＰＡＮＡからブートストラップされる請求項４に記載の方法。
6. ＩＫＥのあるバージョンを用いて前記複数のＩＰｓｅｃトンネルを確立することを更に含み、
   前記ＩＰｓｅｃトンネルは、前記モバイル機器と、複数の異なるＩＰｓｅｃゲートウェイとの間に確立されるものであり、
   前記ＩＰｓｅｃトンネルの各々は、再認証を要求することなしに、前記先行するＰＡＮＡ認証に基づいて確立されるものである請求項１ないし５のいずれか１項に記載の方法。
7. ＥＡＰ認証によって前記複数の安全なトンネルを確立することを更に含む請求項１ないし６のいずれか１項に記載の方法。
8. ネットワークアドレス変換ルータがクライアントと認証エージェントとの間に存在する場合に、該ネットワークアドレス変換ルータがそのアドレス変換状態を消去することを阻止することを更に含む請求項１ないし７のいずれか１項に記載の方法。
9. ネットワークアドレス変換ルータがＰＡＮＡクライアントとＰＡＮＡ認証エージェントとの間に存在する場合に、該ネットワークアドレス変換ルータがそのアドレス変換状態を消去することを阻止することを更に含む請求項１ないし８のいずれか１項に記載の方法。
10. 前記ネットワークアドレス変換ルータがそのアドレス変換状態を消去することを阻止するように、ピアライブネステストのために定義されたＰＡＮＡメッセージ変換を遂行することを更に含む請求項９に記載の方法。
11. 同一のＩＰリンク上に存在しない認証エージェントとのセッションを確立したクライアントが、それが新たなＩＰリンクに移動することを知っている場合に、移動ハンドリング手順を行うことを更に含む請求項１ないし１０のいずれか１項に記載の方法。
12. 前記移動ハンドリング手順は、コンテキスト転送プロトコルに基づく移動性最適化を含む請求項１１に記載の方法。
13. 同一のＩＰリンク上に存在しないＰＡＮＡ認証エージェントとのＰＡＮＡセッションを確立したＰＡＮＡクライアントが、それが新たなＩＰリンクに移動することを知っている場合に、ＰＡＮＡ移動ハンドリング手順を行うことを更に含む請求項１ないし１２のいずれか１項に記載の方法。
14. 前記移動ハンドリング手順は、コンテキスト転送プロトコルに基づく移動性最適化を含む請求項１３に記載の方法。
15. 前記モバイルは、ソースＩＰアドレスがネットワークアドレス変換ルータ（ＮＡＴ）の横断前は初期的にＰａＣのアドレスのそれであり且つ該ＮＡＴの横断後は該ＮＡＴのアドレスのそれであり、宛先ソースアドレスが初期ＰＡＮＡ−ＰＡＡ−Ｄｉｓｃｏｖｅｒメッセージについてはマルチキャストアドレスであり且つ後のメッセージについてはＰＡＡのＩＰアドレスであり、前記宛先ポートがＰＡＮＡポートであるメッセージを、ＰＡＮＡ認証エージェント（ＰＡＡ）に送信するＰＡＮＡクライアント（ＰａＣ）を含む請求項１ないし１４のいずれか１項の方法。

Images