JP5000501B2 - 動的ホスト構成およびネットワークアクセス認証 - Google Patents

Description

本出願は、コンピュータネットワークに関し、詳細には、動的ホスト構成、マルチキャストセキュリティおよびネットワークアクセス認証に関する。

ネットワークおよびインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、最も有名なものがインターネットである。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公共の自己持続的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、送信制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンと呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスの大部分は、企業および個人にアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。

ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である機器（例えば、電話機、ＰＤＡ［携帯情報端末］、コンピュータ等）から別の機器にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なバージョンのＩＰがある。ネットワーク上の各ホスト機器は、各機器に固有の一意の識別子である、少なくとも１つのＩＰアドレスを有する。

ＩＰは、コネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータまたはメッセージを送信し、または受信するとき、データまたはメッセージは、パケットと呼ばれるコンポーネントに分割される。あらゆるパケットは、独立のデータ単位として扱われる。

インターネットなどのネットワークを介した各点間の送信を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク内の２点間の通信プロセスを７つの階層に分け、各層は独自の機能セットを付加する。各機器は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミングおよび／またはハードウェアは、通常、デバイスオペレーティングシステムと、アプリケーションソフトウェアと、ＴＣＰ／ＩＰおよび／または他のトランスポートおよびネットワークプロトコルと、この他のソフトウェアおよびハードウェアとの組み合わせである。

通常、上位４層は、メッセージがユーザから、またはユーザに渡されるときに使用され、下位３層は、メッセージが機器（ＩＰホスト機器など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の機器である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。以下に、ＯＳＩモデルの各層を列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証およびプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信および発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換およびダイアログをセットアップし、連携調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御およびエラーチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、ルーティングや転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、送信プロトコルの情報および管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（メディアアクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、エラー回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層に細分している。第１層（すなわち、物理層）は、例えば、物理レベルでネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層コンバージェンスプロシージャ）副層とＰＭＤ（物理メディア依存）副層とに細分している。

無線ネットワーク
無線ネットワークは、例えば、セルラおよび無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ページャ、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器には、音声および／またはデータの高速無線送信を確保するデジタルシステムが含まれてよい。典型的なモバイル機器は、送受信機（すなわち、例えば、送信機、受信機および、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機および受信機）、アンテナ、プロセッサ、１つ以上の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などにおける、ＲＯＭ、ＲＡＭ、デジタルデータストレージなど）、メモリ、フラッシュメモリ、フルチップセットまたは集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）といったコンポーネントの一部または全部を含む。

モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信用いられてもよい。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝播する通信などが含まれ得る。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ規格が存在する。

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

ＩＥＥＥ規格であるＩＥＥＥ８０２．１１は、無線ＬＡＮおよび機器の技術の仕様を規定している。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。場合によって、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含んでいる場合もある、カードなどの個別のハードウェアをインストールしてもよい。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であれ、移動局（ＳＴＡ）であれ、ブリッジであれ、ＰＣＭＣＩＡカードであれ、あるいは別の機器であれ、無線送受信機、アンテナ、およびネットワークにおける各点間のパケットの流れを制御するＭＡＣ（メディアアクセス制御）層という３つの注目すべき要素を含む。

加えて、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）も利用されてよい。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含んでいてもよく、よって、ＭＩＤが２つの個別のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェース接続することが可能になる。ＭＩＤは、ＩＰアドレス、およびＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を有してよい。

無線ネットワーク機器には、これに限られるものではないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（移動通信用グローバルシステム）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（時分割多重接続）機器、またはＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含まれてよい。各ネットワーク機器は、これに限られるものではないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥースコモンネーム、ブルートゥースＩＰアドレス、ブルートゥースＩＰコモンネーム、８０２．１１ＩＰアドレス、８０２．１１ＩＰコモンネーム、ＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含んでいてもよい。

また、無線ネットワークには、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、および他のモバイルネットワークシステムにおいて見られる方法およびプロトコルも関与し得る。モバイルＩＰに関して、これには、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、各ユーザに一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワーク全体で移動することができる。コメント要求（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、モバイルノードのホームネットワーク上のホームアドレスと、ネットワークおよびネットワークのサブネット内における機器の現在位置を識別する気付アドレス（ＣｏＡ）とを割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、モバイルノードが気付アドレスを変更するたび、ホームエージェントにバインディング更新を送ることができる。

基本的なＩＰルーティングでは（すなわち、モバイルＩＰ外部では）、ルーティング機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、各ノードが接続されているネットワークリンクを識別するという想定に依拠している。本明細書において、「ノード」という用語は、例えば、データ送信のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、かつ／または転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスプレフィックスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットなどを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットなどを調べることができる。典型的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからのモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスクおよびデフォルトのルータを用いて再構成される必要がある。そうでない場合、ルーティングプロトコルは、パケットを適正に配信することができないはずである。

動的ホスト構成プロトコル
動的ホスト構成プロトコル（ＤＨＣＰ）は、管理者が、ネットワークにおいてＩＰアドレス割り当てを管理し、かつ／または自動化することを可能にする通信プロトコルである。インターネットプロトコル（ＩＰ）では、インターネットに接続するあらゆる機器が、一意のＩＰアドレスを必要とする。ＩＳＰまたは組織がユーザのコンピュータをインターネットに接続するときには、この機器にＩＰアドレスが割り当てられる必要がある。ＤＨＣＰは、管理者が、ＩＰアドレスを配布し、コンピュータがネットワーク内の異なる場所に接続されたときに、新しいＩＰアドレスを配布することを可能にする。また、ＤＨＣＰは、永続ＩＰアドレスを必要とするＷｅｂサーバを含むコンピュータのための静的アドレスもサポートする。ＤＨＣＰは、以前のネットワークＩＰ管理プロトコル、ブートストラッププロトコル（ＢＯＯＴＰ）の拡張である。

１９９７年３月の、Ｒ．Ｄｒｏｍｓによる、「動的ホスト構成プロトコル（Dynamic Host Configuration Protocol）」という名称のＲＦＣ２１３１に詳述されているように、ＤＨＣＰは、インターネットホストに構成パラメータを提供する。ＤＨＣＰは、ＤＨＣＰサーバからホストにホスト固有の構成パラメータを配信するプロトコルと、各ホストへのネットワークアドレス割り振りの機構という２つのコンポーネントを含む（ＲＦＣ２１３１参照）。「ＤＨＣＰは、クライアント／サーバモデルに基づくものであり、指定されたＤＨＣＰサーバホストが、ネットワークアドレスを割り振り、動的に構成されるホストに構成パラメータを配信する」（同上参照）。

ＲＦＣ２１３１に記載されているように、ＤＨＣＰサーバは、ＤＨＣＰを介して初期設定パラメータを提供するホストを指し、ＤＨＣＰクライアントは、ＤＨＣＰサーバに初期設定パラメータを要求するホストを指す。ホストは、システム管理者によって適切に構成されない限り、ＤＨＣＰサーバとして働かない。ＤＨＣＰは、１）ＤＨＣＰがクライアントに永続ＩＰアドレスを割り当てる「自動割り振り」、２）ＤＨＣＰが限られた期間にわたって（またはクライアントが明示的にアドレスを放棄するまで）クライアントにＩＰアドレスを割り当てる「動的割り振り」、および３）クライアントのＩＰアドレスがネットワーク管理者によって割り当てられ、ＤＨＣＰを使って割り当てられたアドレスがクライアントに伝達される「手動割り振り」という、ＩＰアドレス割り振りの３つの機構をサポートする。これらのうち、動的割り振りは、割り当てられたクライアントによって必要とされなくなったアドレスの自動再利用を可能にする。よって、動的割り振りは、一時的にしかネットワークに接続されないクライアントにアドレスを割り当てるのに、または永続ＩＰアドレスを必要としないクライアントグループの間で、限られたＩＰアドレスプールを共用するのに役立つ（同上参照）。加えて、「動的割り振りは、ＩＰアドレス数が不十分であり、旧いクライアントが退いたときにＩＰアドレスを再利用することが重要であるネットワークに永続的に接続される新しいクライアントにＩＰアドレスを割り当てる際に適切な選択ともなりうる場合がある」（同上）。

様々なシステムおよび方法が知られているが、依然としてシステムの改善および方法が求められている。

本発明の好ましい実施形態は、既存の方法および／または装置を顕著に改善することができる。

いくつかの実施形態によれば、特に、例えば、接続が失われたときに同期を維持するなどのための、認証ＳＡ状態（ＰＡＮＡ ＳＡ状態など）とＤＨＣＰ ＳＡ状態の間の同期などを目的とする、認証エージェント（ＰＡＡなど）とＤＨＣＰサーバの間の対話に関連する、動的ホスト構成およびネットワークアクセス認証をバインドするシステムおよび方法が提供される。

いくつかの実施形態によれば、特に、前述の状況などにおいて、サービス盗用など（例えばＭＡＣアドレスおよび／またはＩＰアドレススプーフィングなど）を回避するなどのための認証エージェント（ＰＡＡなど）とレイヤ２スイッチの間の対話に関連する、ネットワークブリッジおよびネットワークアクセス認証をバインドするシステムおよび方法が提供される。

いくつかの実施形態によれば、特に、前述の状況などにおいて、許可された受信者と同じレイヤ２セグメントに接続されている無許可の受信者によって不必要に受け取られ、かつ／または処理されるＩＰマルチキャストストリームを回避するなどのための、保護されたＩＰマルチキャストストリームのキー管理に関連する、ネットワークアクセス認証プロトコルからマルチキャストセキュリティをブートストラップするシステムおよび方法が提供される。

本発明の好ましい実施形態を、限定ではなく、例として、添付の図に示す。

図１から１２は、特に、好ましい実施形態の詳細な説明の第１部に関連する、特に、動的ホスト構成およびネットワークアクセス認証のバインディングに関連する、本発明のいくつかの好ましい実施形態による特徴を示す例示的概略図である。

図１３乃至３９は、特に、好ましい実施形態の詳細な説明の第２部に関連する、特に、ネットワークブリッジおよびネットワークアクセス認証のバインディングに関連する、本発明のいくつかの好ましい実施形態による特徴を示す例示的概略図である。

図４０乃至４７は、特に、好ましい実施形態の詳細な説明の第３部に関連する、特に、ネットワークアクセス認証プロトコルからのマルチキャストセキュリティのブートストラップに関連する、本発明のいくつかの好ましい実施形態による特徴を示す例示的概略図である。

本発明は多種多様な形で実施されてよいが、本明細書では、本開示は、本発明の原理の例を提供するものとみなされるべきであり、このような例は、本発明を、本明細書で説明され、かつ／または図示される好ましい実施形態のみに限定するためのものではないという理解の下で、いくつかの例示的実施形態を説明する。

以下の詳細な説明では、本発明の好ましい実施形態を、３部に分けて説明する。「動的ホスト構成およびネットワークアクセス認証のバインディング」と題される第１部は、特に、ＰＡＡ（ＰＡＮＡ認証エージェント）とＤＨＣＰサーバの間の対話に関連するものである。特に、第１部では、例えば、接続が失われたときに同期を維持するなどの、ＰＡＮＡ ＳＡ状態とＤＨＣＰ ＳＡ状態との間の同期の方法を説明する。一方、「ネットワークブリッジおよびネットワークアクセス認証のバインディング」と題される第２部は、特に、ＰＡＡとレイヤ２スイッチの間の対話に関連するものである。特に、第２部では、第１部の状況において、サービス盗用など（例えば、ＭＡＣアドレスおよび／またはＩＰアドレススプーフィングなど）を回避する方法を説明する。他方、「ネットワークアクセス認証プロトコルからのマルチキャストセキュリティのブートストラップ」と題される第３部は、特に、保護されたＩＰマルチキャストストリームのキー管理に関連するものである。特に、第３部では、第１部の状況において、許可された受信者と同じレイヤ２セグメントに接続されている無許可の受信者によって不必要に受け取られ、かつ／または処理されるＩＰマルチキャストストリームを回避する方法を説明する。

第１部：動的ホスト構成およびネットワークアクセス認証のバインディング
１．既存のプロトコル
参照により全体が本明細書に組み込まれる、前述の、インターネット技術標準化委員会（ＩＥＴＦ）のＲＦＣ２１３１では、動的ホスト構成プロトコル（ＤＨＣＰ）が定義されている。前述のように、ＤＨＣＰは、ＴＣＰ／ＩＰネットワーク上でホストに構成情報を渡すためのフレームワークを提供する。ＤＨＣＰは、再利用可能なネットワークアドレスの自動割り振りおよび追加構成オプションを可能にする機能を有する。

参照により全体が本明細書に組み込まれる、ＩＥＴＦのＲＦＣ３１１８では、ＤＨＣＰメッセージの認証が記載されており、認証チケットを容易に生成し、新しく接続された適正な許可を有するホストを、認証されたＤＨＣＰサーバから自動的に構成するためのＤＨＣＰオプションが定義されている。

参照により全体が本明細書に組み込まれる、ＩＥＴＦのＲＦＣ３３１５では、ＩＰｖ６のための動的ホスト構成プロトコル（ＤＨＣＰｖ６）が定義されている。ＤＨＣＰｖ６は、ＤＨＣＰサーバが、ＩＰｖ６ネットワークアドレスなどの構成パラメータをＩＰｖ６ノードに渡すことができるようにする。ＤＨＣＰｖ６は、再利用可能なネットワークアドレスの自動割り振りおよびさらなる構成柔軟性を可能にする機能を提供する。また、ＲＦＣ３３１５は、ＤＨＣＰｖ６の遅延認証プロトコルも含む。

参照により全体が本明細書に組み込まれる、 ［http://www.ietf.org/internet-drafts/Yegin-Eap-Boot-RFC3118-00.txt］に記載されている、２００４年９月２日付けの、Ａ．Ｙｅｇｉｎらによる、「ＥＡＰベースのネットワークアクセス認証を使ったＲＦＣ３１１８遅延ＤＨＣＰ認証のブートストラップ（Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication）」という表題のインターネット草案文書では、ＥＡＰベースのネットワークアクセス認証を使ったＲＦＣ３１１８遅延ＤＨＣＰ認証のブートストラップが説明されている。この文書では、ＥＡＰベースのネットワークアクセス認証機構を使って、どのようにして、ローカルな信頼関係が確立され、ＲＦＣ３１１８と併せて使用され得るキーが生成され得るかが概説されている。

２．いくつかの現在の制限事項
ＲＦＣ３１１８およびＲＦＣ３３１５では、ＤＨＣＰ／ＤＨＣＰｖ６メッセージが、遅延認証プロトコルを使ってどのようにして認証され得るかが記載されているが、遅延認証プロトコルを開始するのに必要な共用キーの構成に関しては全く記載されていない。他方、Draft-Yegin-EAP-Boot-rfc3118-00.txtでは、ＥＡＰベースのネットワークアクセス認証機構を使ってどのようにキーを生成すべきかが記載されており、このため、ＤＨＣＰクライアントホストがネットワークに接続されたまさに最初の時点で、遅延認証プロトコルを開始することが可能になる。

しかしながら、Draft-Yegin-EAP-Boot-rfc3118-00.txtでは、どのようにすれば、ＥＡＰベースの認証セッションとＤＨＣＰセッションが、最初のＤＨＣＰのブートストラップ後に、最も有効に相互に対話し合うことができるかについては、考察も記載もされていない。

本発明の発明者らは、既存の技術に優る大きな利点を有する、ネットワークアクセス認証機構とホスト構成機構の間の新しいアーキテクチャおよび関係を開発している。特に、本発明のいくつかの好ましい実施形態によれば、以下の場合にＤＨＣＰおよび認証セッションを処理するためのシステムおよび方法が提供される、
終了：例えば、認証セッションが打ち切られた場合、
更新：例えば、認証セッションキーが更新された場合、
再始動：例えば、ＤＨＣＰサーバが再始動される必要のある場合、
期間満了：ＤＨＣＰバインディングの存続期間が満了した場合、および／または
新しいセッションの確立：例えば、新しい認証セッションが確立された場合。

３．方法案
「一般的なモデル」と表示された図１に、好ましい実施形態のいくつかが実施され得る基本環境を示す。この例示的環境において、オーセンティケータは、好ましくは、クライアントを認証し、アクセスネットワークを介したクライアントのネットワークアクセスを許可することのできる機能を有する機能エンティティである。加えて、ＥＡＰサーバは、好ましくは、ＥＡＰクライアントを認証するＥＡＰ認証方法を実行するエンティティである。加えて、ＰＡＮＡサーバは、好ましくは、ＥＡＰを使ってＰＡＮＡクライアントを認証するエンティティである。

図１には、説明のために、１つのオーセンティケータ、１つのＤＨＣＰサーバおよび１つのクライアントが示されているが、当分野の技術者であれば本開示に基づいて理解するように、別の実施形態は異なっていてもよい。例えば、別の実施形態では、複数のオーセンティケータ、複数のＤＨＣＰサーバおよび／または複数のクライアントを用いることができる。

「ネットワークアクセス認証およびＤＨＣＰ」と表示された図２は、好ましい実施形態のいくつかで用いられる原理のいくつかを説明するのに役立つ。

いくつかの説明例は、ネットワークアクセスのための認証情報を搬送するプロトコルとしてＰＡＮＡが使用され、ネットワークアクセスのための認証情報を搬送するプロトコルによって搬送される実際の認証プロトコルとしてＥＡＰが使用される状況で説明されるが、これらは単なる例にすぎない。本発明の様々な実施形態は、本開示に基づけば十分に理解されるように、ＰＡＮＡおよびＥＡＰと類似の機能、例えば、正常な認証および許可の結果としてクライアントとオーセンティケータの間で認証セッションキーを確立する機能などを提供する、任意のプロトコルまたはプロトコルセットに適用され得る。例えば、好ましい実施形態のシステムおよび方法は、ＥＡＰを搬送するプロトコルとしてＩＥＥＥ８０２．１Ｘが使用されるアクセスネットワーク内で用いられ得る。

加えて、図では、ＥＡＰサーバとＰＡＮＡサーバが同じ単一のノードに位置する場合を示しているが、これら２つのエンティティは、例えば、ＡＡＡプロトコルを使ってこれらの間でＥＡＰメッセージを搬送するＡＡＡプロトコルを使うなどにより、個別のノードで実施することもできる。また、このような場合、認証セッションキーがＡＡＡキーとして表現されてもよい。

３．１．認証セッションが打ち切られたときのサーバ挙動
このセクションでは、いくつかの好ましい実施形態において、認証セッションが、意図的に、または意図せずに打ち切られたときに、オーセンティケータおよびＤＨＣＰサーバがどのような挙動を呈するかを説明する。これに関しては、参照のために「認証セッションが終了した場合のサーバの挙動」と表示された図３を使用する。

（１）通常、オーセンティケータは、認証セッションが終了していることに気付く。オーセンティケータが認証セッションの終了に気付き得る場合には、
認証セッションの存続期間の満了、
クライアントの再認証時の障害、
クライアントからの終了要求の受け取り
が含まれる。このような状況において、オーセンティケータは、終了が事故であるとみなされる場合には、新しい認証セッションを再開しようするための認証要求メッセージを送っても、送らなくてもよい。

（２）本発明のいくつかの好ましい実施形態によれば、オーセンティケータは、ＤＨＣＰサーバに、終了したばかりの認証セッションから導出されたＤＨＣＰキーがもはや有効ではないことを知らせることができる。特に、これが有利になり得るのは、ＤＨＣＰサーバが、通常、セッションが終了している場合でさえも、旧い構成ファイルを保存しているからである。好ましくは、オーセンティケータは、オーセンティケータが認証セッションの終了を認識するや否や、ＤＨＣＰサーバに知らせる。様々な実施形態において、オーセンティケータが、ＤＨＣＰサーバに、ＤＨＣＰキーの状況の無効または変化を知らせるための、いくつかの可能な実現形態がある。

第１の例では、構成ファイルが書き換えられ、または再ロードできる。例えば、オーセンティケータは、ＤＨＣＰサーバの構成ファイルを変更することができる。次いで、オーセンティケータは、ＤＨＣＰサーバを再始動させることもでき、ＤＨＣＰサーバに、再度構成ファイルを読み取るよう求める信号を送ることもできる。

第２の例では、ＤＨＣＰサーバに、クライアント構成を削除するよう求める要求が送ることができる。例えば、オーセンティケータは、ＩＰやＵＮＩＸ（登録商標）ドメインソケットなどの通信プロトコルを介して要求メッセージを送ることができる。

（３）いくつかのシステムでは、任意選択の機能に、ＤＨＣＰサーバがＤＨＣＰキー取消しのメッセージを受け取った場合で、ホスト構成プロトコルが許容する場合に、ＤＨＣＰサーバが、ＤＨＣＰクライアントに、前のＤＨＣＰメッセージでクライアントに割り振られたバインディングを解除するよう要求すること含んでいてもよい。例えば、ＤＨＣＰｖ６サーバは、クライアントに、以下の例示的ステップに従ってこれのバインディングを更新するよう要求することができる。

１．ＤＨＣＰｖ６サーバが、前のＤＨＣＰキーを使って再構成メッセージを送る。

２．ＤＨＣＰｖ６クライアントが、ＤＨＣＰサーバに、更新メッセージまたは情報要求メッセージを送る。

３．ＤＨＣＰｖ６サーバは、前のＤＨＣＰキーを使ってＤＨＣＰ認証オプションをチェックし、ゼロの存続期間を有するバインディングを含む応答メッセージを送る。

４．ＤＨＣＰｖ６クライアントは、旧いバインディングの使用を停止し、新しいバインディングの要求を開始してもよい。

５．ＤＨＣＰｖ６サーバは、前のＤＨＣＰキーを有するメッセージを廃棄する。

場合により、クライアントが認証セッションの終了に気付いた場合、クライアントは、これ自体で前のキーを廃棄する。したがって、このような場合には、上記ステップ２および後続の各ステップが行われない場合もある。

（４）いくつかのシステムでは、ＤＨＣＰサーバは、ＤＨＣＰキーを除去し、バインディングを使用不可にする。バインディングエントリを使用不可にするには、以下の可能な実現形態がある。

バインディングテーブルからのエントリの除去。

エントリの存続期間を、これらが満了しているかのごとく、強制的にゼロにすること。

バインディングテーブルからのエントリの除去は、これらのリソースが解放されることを意味するものではないことに留意する。例えば、クライアントは、おそらく、これらのリソースを意図せずに使用し続けることがある。ＤＨＣＰサーバは、バインディングに関連するリソースが、依然として、ネットワーク内の任意のエンティティによって使用されるか否かをチェックすることができる。例えば、ＲＦＣ２１３１には、割り振り側（ＤＨＣＰｖ４）サーバが、アドレスを割り振る前に、例えば、ＩＣＭＰエコー要求などを用いて、再利用されるアドレスを調べるべきであると記載されている。ＤＨＣＰｖ６サーバも、類似のやり方でネットワークリソースの整合性をチェックすることができる。

３．１．１．認証セッションが終了したときのクライアント挙動
このサブセクションでは、クライアントの観点から、クライアントが、どのようにして、認証セッションの終了を扱うかについて説明する。これに関して、「認証セッションが終了した場合のクライアントの挙動」と表示された図４に、これに関連する特徴を示す。図４を参照すると、システムは、以下のステップを実行する。

（１）第１に、図の（１）に示すように、クライアントが、認証セッションが打ち切られたことに気付く。これに関して、クライアントが、認証セッションの終了に気付き得る場合には、
認証セッションの存続期間の満了、
再認証の失敗、
終了要求
が含まれる。

（２）第２に、クライアントは、ＤＨＣＰサーバによって割り振られたリソースの使用を停止する。クライアントは、以前のＤＨＣＰキーを使ったバインディングを解除する解除メッセージを送っても、送らなくてもよい。

（３）第３に、図の（３）に示すように、クライアントは、必要に応じて、新しい認証セッションを再開し、新しいキーを取得する。

３．２．認証セッションキーが更新される場合
いくつかの好ましい実施形態によれば、認証セッションキーが更新されるとき、ＤＨＣＰキーが特別に処理される。好ましい実施形態では、３つの可能な方法が利用できる。

いくつかの実施形態では、クライアントとオーセンティケータおよび／または動的ホスト構成サーバは、いずれの方法が用いられるべきかに関して折衝することができる。例えば、いくつかの実施形態では、クライアントは、クライアントがいずれの方法をサポートしているか指示する信号を送ってもよい。例えば、いくつかの実施形態では、認証セッションキーが更新されるときに、動的ホスト構成およびネットワークアクセス認証をバインドするシステムで使用するためにクライアントによって実行される方法は、上記認証セッションまたは上記動的ホスト構成セッションの終了時に、あるいはこのようなセッションの開始時に、上記クライアント機器が、このような終了または開始を処理するために、このクライアント機器がいずれの動的ホスト構成キー取扱方法をサポートしているか識別するメッセージを送ることを含んでいてもよい。いくつかの実施形態では、上記クライアント機器は、上記メッセージをオーセンティケータに送る。いくつかの実施形態では、上記クライアント機器は、上記メッセージを動的ホスト構成サーバに送る。

３．２．１．不変のままのＤＨＣＰキー（方法１）
第１の実施形態によれば、第１の方法は、認証キーは変更されるが、ＤＨＣＰキーが不変のままであることを含む。「ＡＡＡキー更新：方法１：ＤＨＣＰキーが不変のまま」と表示された図５は、この実施形態の好ましい実現形態による特徴を示すのに役立つ。図５を参照すると、システムは、好ましくは、以下のステップを実行する。

（１）第１に、図の（１）に示すように、認証セッションで認証セッションキーが変更される。

（２）第２に、図の（２）に示すように、クライアントは認証セッションキーを更新し、ＤＨＣＰキーはこのままにしておく。オーセンティケータは、ＤＨＣＰキーに関してＤＨＣＰサーバに何も送らない。

（３）第３に、図の（３）に示すように、クライアントまたはＤＨＣＰサーバによってＤＨＣＰメッセージ交換が必要とされるときには、これらは、同じＤＨＣＰキーを使用し続ける。

３．２．２．ＤＨＣＰキー更新の据え置き（方法２）
第２の実施形態によれば、第２の方法は、ＤＨＣＰキーが後で更新されることを含む。特に、認証セッションキーの変更は、即時にＤＨＣＰメッセージ交換を生じさせない。こうして、いくつかの好ましい実施形態において、ＤＨＣＰサーバおよびクライアントは、キー変更後、最初にＤＨＣＰメッセージ交換を必要としたときに、ＤＨＣＰキーを更新する。これに関して、「ＡＡＡキー更新：方法２：ＤＨＣＰキー更新の据え置き」と表示された図６に、この例示的実施形態による好ましい特徴を示す。図６を参照すると、システムは、好ましくは、以下のステップを実行する。

（１）第１に、図の（１）に示すように、イベントによって認証セッションキー更新がトリガされる。

（２）第２に、図の（２）に示すように、オーセンティケータが、ＤＨＣＰサーバに新しいＤＨＣＰキーを送る。

（３）第３に、図の（３）に示すように、オーセンティケータとクライアントの間で、新しい認証セッションキーが確立される。

（４）第４に、図の（４）に示すように、クライアントも、このステップで、新しいＤＨＣＰキーを代替キーとして保存する。

（５）第５に、図の（５）に示すように、ＤＨＣＰサーバおよびクライアントは、妥当な場合には、新しい認証キーの獲得後のメッセージ交換に新しいＤＨＣＰキーを使用する。ＤＨＣＰサーバおよびクライアントは、新しいＤＨＣＰキーを使用した後、旧いＤＨＣＰキーを除去する。

３．２．３．即時のＤＨＣＰキー更新（方法３）
第３の実施形態によれば、第３の方法は、キー変更の直後に、ＤＨＣＰセッションが、新しいＤＨＣＰキーを使って再開されることを含む。「ＡＡＡキー更新：方法３：即時のＤＨＣＰキー更新」と表示された図７に、この例示的実施形態による特徴を示す。図７を参照すると、システムは、好ましくは、以下のステップを実行する。

（１）第１に、図の（１）に示すように、認証セッションで認証セッションキーが変更される。

（２）第２に、図の（２）に示すように、オーセンティケータとクライアントの間で新しい認証セッションキーが確立される。本発明の好ましい実施形態によれば、オーセンティケータは、好ましくは、このステップの終わりまでに、ＤＨＣＰサーバに新しいＤＨＣＰキーを送る。

（３）第３に、図の（３）に示すように、クライアントは、好ましくは、新しいＤＨＣＰキーを使って新しいＤＨＣＰセッションを開始する。

３．３．ＤＨＣＰサーバが再始動される必要のある場合
いくつかの好ましい実施形態によれば、ＤＨＣＰサーバは、リブート後に、または他の理由で、特別なやり方で再始動される。好ましい実施形態では、３つの用いられ得る可能な方法がある。

いくつかの実施形態では、クライアントとオーセンティケータおよび／または動的ホスト構成サーバが、いずれの方法が用いられるべきかに関して折衝することができる。例えば、いくつかの実施形態では、クライアントは、クライアントがいずれの方法をサポートしているか指示する信号を送ってもよい。例えば、いくつかの例では、動的ホスト構成バインディングの存続期間が満了したときに、動的ホスト構成およびネットワークアクセス認証をバインドするシステムで使用するために、クライアント機器によって実行される方法は、動的ホスト構成バインディングの存続期間満了時に（または、同様に、動的ホスト構成セッションの開始時に）、クライアント機器が、このような終了または開始を処理するために、クライアント機器がいずれの動的ホスト構成鍵キー取扱方法をサポートしているのかを識別するメッセージを送り得ることを含んでいてもよい。いくつかの実施形態では、上記クライアント機器は、上記メッセージをオーセンティケータに送る。いくつかの実施形態では、上記クライアント機器は、上記メッセージを動的ホスト構成サーバに送る。

３．３．１．不揮発性記憶からの全状態回復（方法１）
本発明の第１の実施形態によれば、第１の方法は、不揮発性記憶装置を使って状態を回復することを含む。これに関して、「ＤＨＣＰサーバ再始動：方法１：不揮発性記憶」と表示された図８に、この実施形態による例示的特徴を示す。図８を参照すると、システムは、好ましくは、以下のステップを実行する。

（１）第１に、図の（１）に示すように、ＤＨＣＰサーバが、好ましくは、ＤＨＣＰキーテーブルおよびバインディングテーブルを不揮発性記憶装置に保存する。ＤＨＣＰサーバは、テーブルが更新されたときに、随時、不揮発性記憶を更新してもよく、これを定期的に更新してもよい。不揮発性記憶装置は、例えば、ハードドライブ、磁気ディスク、フラッシュメモリなど、任意の適切なデータストレージまたはメモリを使って実施できる。

（２）第２に、ＤＨＣＰサーバが、好ましくは、何らかの理由で再始動する。

（３）第３に、図の（３）に示すように、ＤＨＣＰサーバは、好ましくは、不揮発性記憶装置から、キーテーブルおよびバインディングテーブルを復元する。好ましくは、ＤＨＣＰサーバは、存続期間が満了しているエントリを除去する。

（４）第４に、（４）に示すように、ＤＨＣＰサーバおよびクライアントは、好ましくは、キーの存続期間が満了するまで、同じキーを使用する。

３．３．２．ＤＨＣＰサーバからのリブート通知またはオーセンティケータによるリブート検出（方法２）
別の実施形態によれば、第２の方法は、ＤＨＣＰが最初から再始動することを含み得る。この場合、以前のキーテーブルおよびバインディングテーブルは廃棄される。また、各クライアントは、認証セッションを再開する必要がある。「ＤＨＣＰサーバ再始動：方法２：最初からのリブート」と表示された図９に、この実施形態によるいくつかの例示的特徴を示す。図９を参照すると、システムは、好ましくは、以下のステップを実行する。

（１）ＤＨＣＰサーバが何らかの理由で再始動する。

（２）オーセンティケータから動的に獲得されたすべてのＤＨＣＰキー、および対応するバインディングテーブル内のエントリが失われる。ＤＨＣＰサーバは、多重割り振りを防ぐために、以前のバインディングに割り振られた可能性のあるリソースをチェックすることも、チェックしない場合もある。これを行うためのいくつかの実現方法には、以下が含まれる。

ＤＨＣＰサーバは、可能であれば、バインディングテーブルを復元し、更新するために各クライアントに再構成を送ってもよい。

ＤＨＣＰサーバは、不揮発性記憶装置を使ってバインディングテーブルを復元してもよい。

（３）いくつかの好ましい実施形態によれば、任意選択的に、ａ）ＤＨＣＰサーバがオーセンティケータに、ＤＨＣＰキーが消去されていることを知らせ、または、ｂ）オーセンティケータが、ＤＨＣＰサーバからの通知なしで、ＤＨＣＰサーバのリブートを知ることができるステップが用いられてもよい。このような場合、オーセンティケータは、好ましくは、クライアントごとにＤＨＣＰキーを更新し、これらをＤＨＣＰサーバに送る。

（４）クライアントは、オーセンティケータが要求し、またはクライアントが、ＤＨＣＰセッションの終了に気付いたときに、認証セッションおよびＤＨＣＰセッションを再開する。

３．３．３．オーセンティケータへのキーの要求（方法３）
本発明の別の実施形態によれば、第３の方法は、ＤＨＣＰサーバがオーセンティケータに、キー情報を再送するよう要求し、ＤＨＣＰキーテーブルを復元することを含む。「ＤＨＣＰサーバ再始動：方法３：オーセンティケータへのキーの要求」と表示された図１０に、この実施形態による例示的特徴を示す。図１０を参照すると、システムは、好ましくは、以下のステップを実行する。

（１）第１に、図の（１）に示すように、ＤＨＣＰサーバが、ＤＨＣＰサーバが始動するときに、オーセンティケータにＤＨＣＰキーを再送するよう要求する。

（２）第２に、図の（２）に示すように、オーセンティケータが、すべての有効なＤＨＣＰキーをＤＨＣＰサーバに送る。

（３）第３に、図の（３）に示すように、ＤＨＣＰサーバが、ＤＨＣＰキーテーブルを復元する。この場合、バインディングテーブルエンティティは、復元されることも、復元されない場合もある。

いくつかの実施形態では、ＤＨＣＰサーバは、可能であれば、バインディングテーブルを復元し、更新するために、各クライアントに再構成メッセージを送ってもよい。

いくつかの実施形態では、ＤＨＣＰサーバは、不揮発性記憶装置を使ってバインディングテーブルを復元することができる。

３．４．ＤＨＣＰバインディングの存続期間が満了した場合
このセクションでは、ＤＨＣＰバインディングの存続期間が満了したときにＤＨＣＰクライアントがどのような挙動を呈するかを説明する。実施され得るいくつかの可能な方法がある。

３．４．１．現在のＤＨＣＰキーの保持
既存の方法は、ＤＨＣＰクライアントおよびサーバが、現在のキーを使って存続期間を延長することを伴う。これに関して、「ＤＨＣＰ存続期間満了：方法１：現在のＤＨＣＰキーの保持」と表示された図１１に、この既存の方法の特徴を示す。図１１を参照すると、システムは、好ましくは、以下のステップを実行する。

（１）第１に、図の（１）に示すように、ＤＨＣＰバインディング更新のタイマが時間切れになる。

（２）第２に、図の（２）に示すように、ＤＨＣＰサーバまたはクライアントが、存続期間を延長するために現在のＤＨＣＰキーを使ったＤＨＣＰメッセージ交換を開始する。

３．４．２．再認証の要求
本発明の好ましい実施形態によれば、ＤＨＣＰクライアントに、ＤＨＣＰメッセージ交換の前に認証セッションを更新するよう要求させることを含む別の方法が用いられ得る。これに関して、「ＤＨＣＰ存続期間満了：方法２：再認証の要求」と表示された図１２に、この実施形態による例示的特徴を示す。図１１を参照すると、システムは、好ましくは、以下のステップを実行する。

（１）第１に、ＤＨＣＰバインディング更新のタイマが時間切れになる。

（２）第２に、図の（２）に示すように、クライアントが、オーセンティケータに、ＤＨＣＰキーを再認証し、更新するよう要求する。いくつかの実施形態では、ＤＨＣＰサーバは、オーセンティケータに、ＤＨＣＰキーを再認証し、更新するよう要求することができる。

（３）第３に、図の（３）に示すように、オーセンティケータが、ＤＨＣＰサーバに、新しいＤＨＣＰキーを送る。好ましくは、ＰＡＮＡクライアントは、ＤＨＣＰクライアントに、新しいＤＨＣＰキーを知らせる。

（４）第４に、図の（４）に示すように、クライアントが、新しいＤＨＣＰキーを使って新しいＤＨＣＰセッションを開始する。

３．５．新しい認証セッションが確立されたときのサーバ挙動
好ましい実施形態によれば、オーセンティケータとクライアントの間で新しいＤＨＣＰキーを作成するために認証メッセージが交換される間、オーセンティケータは、好ましくは、ＤＨＣＰキーがＤＨＣＰサーバに正常にインストールされるまで、新しい認証セッションが正常に確立されていることを指示するメッセージを返さないことになっている。このようにして、クライアントは、正常な認証セッションの確立後、直ちに、新しいキーを用いた新しいＤＨＣＰセッションを開始し、同時に、競合状態を回避することができる。

第２部：ネットワークブリッジおよびネットワークアクセス認証のバインディング
１．既存の方法
参照により全体が本明細書に組み込まれる、Internet Draft-IETF-EAP-RFC2284bis-09では、複数の認証方法をサポートする認証フレームワークである、拡張可能認証プロトコル（ＥＡＰ）が定義されている。

参照により全体が本明細書に組み込まれる、Internet-Draft-IETF-PANA-PANA-04では、拡張可能認証プロトコル（ＥＡＰ）がクライアントとアクセスネットワークの間のネットワークアクセス認証を可能にするためのリンク層不可知トランスポートである、ネットワークアクセスの認証を搬送するプロトコル（ＰＡＮＡ）が定義されている。

前述のように、ＲＦＣ３１１８では、ＤＨＣＰメッセージの認証が説明されており、認証チケットを生成し、新しく接続された適正な許可を有するホストを、認証されたＤＨＣＰサーバから自動的に構成するためのＤＨＣＰオプションが定義されている。

また前述のように、ＲＦＣ３３１５では、ＩＰｖ６（ＤＨＣＰｖ６）のための動的ホスト構成プロトコルが定義されている。ＤＨＣＰｖ６は、ＤＨＣＰサーバが、ＩＰｖ６ネットワークアドレスなどの構成パラメータをＩＰｖ６ノードに渡すことを可能にする。これは、再利用可能なネットワークアドレスの自動割り振り、およびさらなる構成柔軟性を可能にする機能を提供する。また、ＲＦＣ３３１５は、ＤＨＣＰｖ６のための遅延認証プロトコルも含む。

やはり前述したように、Draft-Yegin-EAP-Boot-RFC3118-00.txtには、ＥＡＰベースのネットワークアクセス認証を使ったＲＦＣ３１１８遅延ＤＨＣＰ認証のブートストラップが記載されている。これには、ＥＡＰベースのネットワークアクセス認証機構を使って、どのようにして、ローカルな信頼関係が確立され、ＲＦＣ３１１８と併せて使用され得るキーが生成できるかが記載されている。

加えて、参照により全体が本明細書に組み込まれる、「ローカルおよびメトロポリタンエリアネットワークの規格草案：ポートベースのネットワークアクセス制御の規格（Draft Stands for Local and Metropolitan Area Networks: Standard for Port based Network Access Control）」という表題のＩＥＥＥ草案Ｐ８０２．１Ｘには、認証、および結果として生じる処置が行われるアーキテクチャフレームワークが説明されている。しかしながら、これでは、スイッチの異なる物理ポート間の対話は説明されていない。

参照により全体が本明細書に組み込まれる、Ｒｉｃｈ Ｓｅｉｆｅｒｔ著、「スイッチブック（The Switch Book)」、JOHN WILEY & SONS、INC.ISBN0-471034586-5では、既存のスイッチおよびブリッジがどのように動作するか説明されている。

２．既存の方法の限界
ＥＡＰおよびＰＡＮＡは、ネットワークアクセスの認証のためのフレームワークを提供する。加えて、遅延ＤＨＣＰ認証を使ってＤＨＣＰパケットを認証することもできる。これらのプロセスが一旦完了すると、クライアントは、例えば、アプリケーションデータないずれのパケットの送受信を開始してもよい。この時点において、ＥＡＰ／ＰＡＮＡおよびＤＨＣＰ認証は、もはやこのようなパケットのためのパケットごとの保護を提供しなくなり、サービス盗用の可能性が生じ得る。

「考えられるサービス盗用」と表示された図１３に、起こる場合があるサービス盗用のいくつかの例を示す。図の部分（ａ）には、ＰＡＡ、ＤＨＣＰサーバ、ルータおよびいくつかのクライアント（例えばクライアント１や攻撃者など）が、ブロードキャストハブや同軸ケーブルイーサネット（登録商標）などのブロードキャストＬＡＮと接続されている単純なアクセスネットワークが示されている。クライアント１が、アプリケーションサーバ（Ａｐｐ）として示すネットワークサービスを使っているとき、Ａｐｐサーバからクライアント１に送られたパケットは、ＬＡＮに直接接続されているすべてのノードにブロードキャストされる。結果として、攻撃者は、おそらく、Ａｐｐサーバからのパケットを受け取ることができる。加えて、攻撃者は、ソースＩＰアドレスを偽装することによって、Ａｐｐサーバに、パケットを、これらがあたかもクライアント１から送られたかのように送ってもよい。これは、例示的「サービス盗用」と考えられる。

他方、部分（ｂ）には、ブロードキャストメディアの代わりに、Ｌ２ブリッジをＬＡＮとして使用するネットワークが示されている。ブリッジは、普通、クライアント１にアドレス指定されたユニキャストパケットを、クライアント１以外のいずれのノードにも送らない。しかし、攻撃者が、クライアント１のＭＡＣアドレスを偽装したパケットを送ると、ブリッジは、悪意の情報に従ってこれの転送データベースを更新し、クライアント１にアドレス指定された後続のパケットを、正当なクライアント１ではなく、攻撃者に転送する。よって、サービス盗用は、依然として可能である。これらの攻撃方法を使用することによって、攻撃者は、いかなる認証も得ずに、ネットワークにアクセスすることができる。

よって、これらの環境において、悪意のある攻撃者が、無許可でネットワークにアクセスするのを防ぐ新しい方法が求められている。

３．モデル案
３．１．ネットワーク例の概要
「ネットワーク例の概要」と表示された図１４に、ネットワーク例を示す。この説明例では、ネットワークアクセスプロバイダが、オーセンティケータとしてのＰＡＡ、ＤＨＣＰサーバ、ルータおよびレイヤ２ネットワークブリッジを有する。ブリッジは、オーセンティケータとＤＨＣＰサーバのためにネットワークに接続された物理ポートを有する。本明細書では、このポートを「サーバポート」と呼ぶ。図１４では、Ｐ０という名前のポートがサーバポートである。

加えて、ブリッジは、クライアントホストおよびネットワークに接続された他の物理ポートも有する。これらを「クライアントポート」と呼ぶ。例えば、各クライアントポートは、Ｐ１、Ｐ２、Ｐ３のような名前を有する。図１４に示す実施形態では、ルータが、プロバイダネットワークと、インターネットなどの外部ネットワークを接続している。図１４に示すネットワークは例であり、単に、例示のために使用されているにすぎないことを理解すべきである。例えば、他の様々なネットワークでは、システムが大きく異なることもあり、複数のオーセンティケータ、複数のＤＨＣＰサーバ、複数のルータ、複数のブリッジおよび／またはこの他があってもよい。

３．２．転送データベース
既存のネットワークブリッジは、ＭＡＣアドレスとブリッジポートの間の関係を保存する、転送データベースという名前のテーブルを有する。本発明の好ましい実施形態では、いくつかの新しい種類の転送データベースがブリッジに導入されている。

３．２．１．許可された転送データベース
第１の新規のデータベースの例を、許可された転送データベース（ＡＦＤ）といい、好ましくは、ＭＡＣアドレスとポート番号との対のリストを含む。以下の表１にＡＦＤの例を示す。

好ましくは、ＡＦＤは、いずれのＭＡＣアドレスも２回以上表示されることがないようなやり方で維持される。好ましくは、所与のＭＡＣアドレスのレコードがＡＦＤに存在する場合、これは、このＭＡＣアドレスを有し、このポートに接続されているクライアントノードが、オーセンティケータによって認証されていることを意味する。好ましい実施形態では、ブリッジに接続されているすべての認証済みクライアントノードが、ブリッジのＡＦＤに表示される。好ましくは、クライアントとオーセンティケータの間の認証セッションが削除されたとき、このクライアントのＭＡＣアドレスに対応するレコードが、ＡＦＤから直ちに除去される。好ましくは、ＡＦＤからレコードが除去されたとき、除去されたレコードのＭＡＣアドレスに対応する認証セッションが、直ちに削除される。

好ましい実施形態では、オーセンティケータは、ブリッジに、ＡＦＤへのレコードの追加、またはＡＦＤからのレコードの除去を要求するように構成されている。いくつかの実施形態では、例えば、ネットワークプロバイダおよび／またはクライアントノードのポリシーに応じて、クライアントノードの物理的切断によって、ＡＦＤからクライアントのレコードが除去されることも、除去されない場合もある。

例えば、クライアントノードがあるポートから別のポートに頻繁に切り換わる場合、このクライアントノードは、これのＭＡＣアドレスに対応するレコードが、ポートから切断したときに、直ちにＡＦＤから除去されることを望んでもよい。

しかし、切断時の自動除去は、サービス拒否（ＤｏＳ）攻撃をより容易にし得る。ＤｏＳ攻撃については、以下で、例示的脅威２および３として説明する考察を参照されたい。

３．２．２．無許可の転送データベース
第２の例示的な新規のデータベースの例を無許可の転送データベース（ＵＦＤ）といい、好ましくは、ＭＡＣアドレスとポート番号の対のリスト、すなわち、ＡＦＤと類似のものを含む。好ましくは、いずれのＭＡＣアドレスも、ＵＦＤに２回以上表示されない。好ましくは、システムは、ＡＦＤまたはＵＦＤにすでに存在するＭＡＣアドレスを追加するのを妨げられる。好ましい実施形態では、所与のＭＡＣアドレスのレコードがＵＦＤに存在する場合、これは、このＭＡＣアドレスを有し、このポートに接続されているとみなされるクライアントノードが、まだ、オーセンティケータによって認証されていないことを意味する。好ましくは、クライアントとオーセンティケータの間の認証セッションが確立されたとき（すなわち、クライアントが認証されたとき）に、このクライアントのＭＡＣアドレスに対応するレコードは、ＵＦＤから除去され、ＡＦＤに追加される。他方、好ましくは、認証メッセージ交換が、例えば、エラーまたはタイムアウトなどで失敗したとき、このクライアントに対応するレコードは、好ましくは、ＵＦＤから除去される。

好ましい実施形態では、例えば前述のようなイベントの際に、レコードが削除される必要があるとき、オーセンティケータは、ブリッジに、このレコードをＵＦＤに追加し、またはＵＦＤから除去するよう要求する。好ましくは、ＵＦＤ内のレコードは存続期間を有する。好ましくは、存続期間には上限がある。存続期間を超過すると、レコードは、好ましくは、ＵＦＤから除去される。いくつかの実施形態では、ＵＦＤ内のレコードが、クライアントとオーセンティケータとの間の認証メッセージ交換の最中に除去された場合、認証は、直ちに失敗となる。

レコードの除去および認証セッションの失敗は、好ましくは、同期して行われるべきである。例えば、同期を維持する１つの簡単な方法が、オーセンティケータのみが、ＵＦＤ内のレコードのタイムアウトを決定するというものである。他の実施形態では、必要に応じて、同期を維持する他の任意の方法が用いられてもよい。

好ましくは、ブリッジがポートを介してあるＭＡＣアドレスからのパケットを受け取り、このＭＡＣアドレスがどのような（１つまたは複数の）転送データベースにも表示されていない場合、このＭＡＣアドレスとポートのレコードがＵＦＤに追加される。好ましくは、このレコードは、存続期間の上限を過ぎるまで、またはオーセンティケータが、このレコードを除去するよう、もしくはＡＦＤに移動するよう要求するまで留まる。いくつかの実施形態では、認証失敗またはタイムアウトが発生したとき、レコードは、次のセクションで説明するペナルティリストに移動されることも、移動されない場合もある。

いくつかの好ましい実施形態では、それぞれのポートの最大レコード数を制限することを用いて、ＵＦＤをオーバフローさせることを狙ったようなＤｏＳ攻撃を防止する手立てを講じることができる。同じポート番号を有するレコードの数が限界に達した場合、ブリッジは、好ましくは、このポートのレコードを追加するよう求める要求を拒否し、このポートのレコード数がある一定の閾値未満に減少するまで、ＵＦＤ内の既存のレコードにマッチしないあらゆるパケットをブロックする。

いくつかの実施形態では、ブリッジは、オーセンティケータおよび／または動的ホスト構成サーバ（例えば、ＤＨＣＰサーバなど）に、ＵＦＤへのレコードの追加またはＵＦＤからのレコードの除去を直ちに通知する。この通知は、好ましくは、レコードのポート番号およびＭＡＣアドレスを含む。この通知を使って、オーセンティケータおよび／または動的ホスト構成サーバは、各クライアントのポート識別子を知ることができる。よって、オーセンティケータおよび／または動的ホスト構成サーバは、例えば、ポート識別子に従って疑わしいクライアントからの要求をブロックすることができる。「レコード追加／除去の通知」と表示された図１４（Ａ）を参照されたい。図１４（Ａ）に示す説明例では、クライアント１のレコードが追加または除去され、ブリッジＢ１が、オーセンティケータ（ＰＡＮＡ認証エージェント［ＰＡＡ］など）および／または動的ホスト構成サーバ（ＤＨＣＰサーバなど）に通知メッセージを送信しているものとして示されている。

いくつかの好ましい実施形態では、ブリッジは、オーセンティケータおよび／またはＤＨＣＰサーバが、クライアントのポート識別子を知ることができるように、オーセンティケータおよび／または動的ホスト構成サーバ（ＤＨＣＰサーバなど）からのＵＦＤのレコードに関する照会に回答することができる。いくつかの実施形態では、オーセンティケータおよび／またはＤＨＣＰサーバは、例えば、ポート識別子に従って、疑わしいクライアントからの要求をブロックすることができる。「ＵＦＤレコードに関する照会／回答」と表示された図１４（Ｂ）を参照されたい。図１４（Ｂ）に示す説明例では、オーセンティケータ（ＰＡＮＡ認証エージェント［ＰＡＡ］など）および／または動的ホスト構成サーバ（ＤＨＣＰサーバなど）が、ブリッジｂ１に、クライアント１（ＭＡＣ１）がどのようなポート番号を有するか尋ねるための照会を送る。次いで、ブリッジＢ１は、クライアント１（ＭＡＣ１）のレコードをチェックする。次いで、ブリッジＢ１は、オーセンティケータまたは動的ホスト構成サーバに回答する。

３．２．３．ペナルティリスト
第３の新規のデータベースの例をペナルティリスト（ＰＬ）といい、まさにＡＦＤやＵＦＤのような、ＭＡＣアドレスとポート番号の対のリストを含む。好ましくは、ＰＬ内のレコードは、タイムスタンプやタイマ等の、タイムアウトを処理するためのタイムアウト情報も有する。好ましくは、ＰＬ内の各レコードは存続期間を有し、これは、統計的に特定の長さに設定されてもよく、実現形態に応じて動的に変更されてもよい。存続期間タイマが時間切れになると、レコードは、好ましくは、ＰＬから自動的に除去される。

好ましくは、ＭＡＣアドレスは、ＰＬに２回以上表示できるが、ＭＡＣアドレスとポートの組み合わせは、好ましくは、ＰＬ内で一意である。ペナルティリストの例を以下の表２に示す。

様々な実施形態において、列「タイムアウト情報」の実際のフォーマットは、実施状況に左右される場合がある。例えば、１つの例示的実現形態では、（表２に示す例のように）期限が切れるまでの秒数を保存していてもよい。別の例として、別の実現形態では、レコードがＰＬに追加された日の時刻を保存し、失効時刻を動的に決定してもよい。

いくつかの代替の実施形態において、ＰＬは、各レコードに「カウンタ」フィールドを含めるよう拡張され得る。これに関して、ＰＬに、ＭＡＣアドレスとポートの同じ組み合わせを追加するよう要求されたとき、この組み合わせのカウンタは、好ましくは、増数される。いくつかの実施形態において、ネットワーク管理者は、ブリッジを、カウンタ数がある一定の値に達するまでブロッキングを開始しないように（例えば、一定の値に達したときにブロッキングを開始するように）構成することも、構成しない場合もある。特に、これは、ユーザが、パスワード入力ミスおよび／または別の悪意のないエラーのすぐ後に認証を試行することを可能にし得る。好ましくは、過度の誤ったアクセスを防ぐために、カウンタの上限閾値を使って、同じＭＡＣアドレスとポートの組み合わせからのこれ以上のアクセスがブロックされてもよい。

加えて、１ポート当たりの最大レコード数を制限することも、ＰＬをオーバフローさせることを意図するようなＤｏＳ攻撃を防ぐ適切な方法である。好ましくは、同じポート番号Ｐを有するレコードの数が限界に達した場合、ブリッジは、「ワイルドカード」レコード（＊，Ｐ）を追加し、ＰＬのために空きを作るために、ポート番号Ｐを有する他のレコードを除去する。ワイルドカードは、例えば、許容される最大存続期間を有していてもよい。加えて、ワイルドカードレコードは、カウンタ数を問わず実施されてもよい。好ましくは、ワイルドカードレコードは、ＵＦＤまたはＡＦＤ内のレコードとマッチするパケットに影響を及ぼさない。ポートＰのワイルドカードレコードがある場合、ブリッジは、好ましくは、ポートＰからのあらゆるアンマッチパケットをブロックする。

３．２．４．パケットフィルタリング
好ましい実施形態では、ブリッジは、好ましくは、前述のＡＦＤ、ＵＦＤおよびＰＬ転送データベースに従ってパケットをフィルタする。好ましくは、クライアントポートＰで受け取られるパケットは、レコードのＭＡＣアドレスフィールドがこのパケットのソースＭＡＣアドレスと等しく、レコードのポート番号フィールドがＰを含む場合に、転送データベース内のレコードと正確にマッチするものとみなされる。他方、好ましくは、サーバポートで受け取られるパケットは、レコードのＭＡＣアドレスフィールドが、このパケットの宛先ＭＡＣアドレスと等しい場合に、転送データベース内のレコードと正確にマッチするものとみなされる。

例として、「パケットフィルタリング」と表示された図１５に、本発明のいくつかの例示的実施形態によるいくつかのパケットフィルタリングスキーマを示す。

好ましい実施形態では、各パケットが、フィルタリングのために、以下のように（すなわち、以下のスキーマの少なくとも一部、好ましくは全部に従って）チェックされる。

パケットがＡＦＤ内のレコードと正確にマッチする場合、ブリッジはこのパケットを転送する。例えば、図１５に示すポート１のＭＡＣ１を参照されたい。

パケットがＵＦＤ内のレコードと正確にマッチする場合、ブリッジは、このパケットのＩＰヘッダを調べる。パケットが、アクセスネットワーク外部のノードにアドレス指定されている場合、ブリッジは、このパケットをブロックする。そうでない場合、パケットがアクセスネットワーク内部のノードにアドレス指定されている場合、ブリッジは、許可された種類のパケットを転送してもよい。例えば、いくつかの種類のパケットがブリッジによって転送されてもよい。いくつかの例示的実施形態では、許可された種類のパケットには、認証（ＰＡＮＡ）メッセージおよびＤＨＣＰメッセージが含まれてよい。例えば、図１５に示すポート３のＭＡＣ３を参照されたい。

パケットがＰＬ内のレコードと正確にマッチする場合、ブリッジはこのパケットをブロックする。例えば、図１５のポート４のＭＡＣ３を参照されたい。

パケットがクライアントポートで受け取られたものであり、このソースＭＡＣアドレスがＡＦＤまたはＵＦＤ内のレコードに見られる場合、ブリッジは、このパケットをブロックする。例えば、図１５のポート３のＭＡＣ１を参照されたい。

３．３．ポート識別タグ
３．３．１．ポート識別タグに関する全般的説明
本明細書では、ブリッジの識別子（すなわち、ブリッジ識別子）とポート番号の組み合わせを「ポート識別子」と呼ぶ。好ましくは、ブリッジ識別子は、アクセスネットワークで使用されるブリッジの間で一意である。

好ましい実施形態では、ポート識別子は、有利には、パケットに添付されている。本開示では、これを、「ポート識別タグ」（ＰＩＴ）と呼ぶ。ポート識別タグ機能がイネーブルにされている場合、ブリッジは、オーセンティケータまたはＤＨＣＰサーバにアドレス指定されているパケットにポート識別子をタグ付けし、元のパケットの代わりにタグ付きのパケットを転送する。ブリッジは、オーセンティケータまたはＤＨＣＰサーバから送られたタグ付きパケットを受け取ると、タグ内のポート識別子を調べ、タグで指定されているポートにタグが外されたパケットを転送する。

「ポート識別タグを用いた転送」と表示された図１６に、２つのブリッジを用いた、非限定的な説明例を示す。ブリッジ１のポート１に接続されたノードがＰＡＡにパケットを送信しようとする。この場合、ブリッジ１は、このパケットに、パケットがブリッジ１（Ｂ１）のポート１（Ｐ１）から送られたことを示すポート識別タグ「Ｂ１：Ｐ１」を添付する。次いで、このタグ付きパケットがＰＡＡに送られる。元のパケットの宛先ＭＡＣアドレスが（例えば、単一の受信者に送られた）ユニキャストアドレスである場合、宛先ＩＰアドレスの決定はむしろ些細な事項である。例えば、宛先ＩＰアドレスは、ＰＩＴノードテーブルで見つかる場合がある（図１８などを参照）。ＡＲＰ（アドレス解決プロトコル）テーブルを検索することが別の可能な実現方法である。元のパケットの宛先ＭＡＣアドレスが（例えば、不特定者に送られた）ブロードキャストアドレス、または（例えば、複数の受信者に送られた）マルチキャストアドレスである場合、より多くの設計実現形態の選択肢が考えられ、これらのうちのいくつかを以下に示す。

ブリッジは、ブロードキャストまたはマルチキャストアドレスのために、ＰＩＴノードテーブルレコードにある各ＩＰアドレスごとにユニキャストパケットを送ることができる。

ブリッジは、ブロードキャストまたはマルチキャストパケットのために事前構成された事前共用キー（ＰＳＫ）を使ってブロードキャストまたはマルチキャストパケットを送ることができる。

ブリッジは、パケットのＩＰヘッダを調べ、どのようなサービスが求められているか決定する。パケットがＵＤＰパケットであり、パケットの宛先ポートが、例えば、ブートストラッププロトコル（ＢＯＯＴＰ）サーバポートである場合、ブリッジは、パケットをＢＯＯＴＰ（またはＤＨＣＰ）サーバに転送する。

図１６では、ＤＨＣＰサーバも、ブリッジ２のポート３に接続されたノードにもパケットを送信しようとする。この場合、ＤＨＣＰサーバは、好ましくは、ポート識別タグ「Ｂ２：Ｐ３」が添付されたパケットを作成し、これをブリッジ２に送る。ブリッジ２は、パケットからポート識別タグを取り外し、このパケットを、ポート３を介して宛先に転送する。ブリッジ２は、好ましくは、別のポートに同じＭＡＣ３を有する別のノードがあった場合でも、このパケットを、ポート識別子に従ってポート３を介して転送する。ＭＡＣアドレスは、好ましくは、世界で唯一一意のものであるべきであるが、実際には、これは通常あり得ない。しかしながら、悪意のある偽装ノードが存在し得る場合、同じＭＡＣアドレスを有するノードを、ポート識別子によって相互に区別すれば、非常に有利となり得る。

３．３．２．セッション識別
いくつかのネットワークサーバは、これらのサーバのクライアントノードのＭＡＣアドレスによってセッションを区別する。ＰＡＡ（ＰＡＮＡサーバ）およびＤＨＣＰサーバが、この種のサーバの例である。しかしながら、偶発的な、かつ／または意図的な攻撃のために、複数のノードが同じＭＡＣアドレスを有し得ると想定される場合、ＭＡＣアドレスのみではセッションを識別するのに不十分である。

これに関して、「ＰＩＴを用いたセッション識別」と表示された図１７の、図の左側に、既存のブリッジおよびサーバ（ＰＡＡなど）での問題を示す。いくつかの好ましい実施形態によれば、ポート識別タグが使用されているときには、ポート識別子とＭＡＣアドレスの組み合わせを用いてセッションを相互に区別することができる。図１７の右側には、ポート識別子とＭＡＣアドレスの組み合わせが、どのようにして、セッションを区別するのに有利に使用され得るかが示されている。好ましくは、ブリッジは、ＰＩＴ対応サーバにアドレス指定されているパケットのみがタグ付けされるように構成できるべきである。

３．３．３．ポート識別タグに関するセキュリティ考慮事項
ポート識別タグは非常に効果的であるため、好ましくは、誤った、または悪意のある使用から隔離しておくべきである。攻撃者がＰＩＴを攻撃ツールとして使用するのを禁じるためには、ブリッジを、クライアントポートから送られたＰＩＴを有するパケットをブロックするように構成することが好ましい。例えば、図１６を参照すると、いくつかの好ましい実施形態では、ブリッジ１およびブリッジ２は、ポート１からポート４までを介して送られたあらゆるＰＩＴパケットを廃棄し、図のポート０を介して送られたＰＩＴのみを受け入れるように構成されていてもよい。加えて、外部ネットワーク、例えばインターネットなどへの接続がある場合、ゲートウェイルータまたはファイアウォールは、好ましくは、外部ネットワークから、かつ／または外部ネットワークに送られるＰＩＴパケットを廃棄するように構成されるべきである。

ＰＩＴの信頼性を向上させる別の方法は、ＨＭＡＣ（メッセージ認証のためのキー付きハッシング：ハッシュ関数に基づくメッセージ認証符号）または類似のメッセージ認証技法を使用するものである。

３．３．４．ポート識別タグの可能な実現形態
いくつかの例示的実施形態において、ＰＩＴを実施する方法には、例えば、
ＵＤＰ／ＩＰカプセル化、
新規のイーサタイプ、
新規のＩＰオプション
などが含まれ得る。

「ＰＩＴメッセージフォーマットの例」と表示された図１８に、ＵＤＰ／ＩＰカプセル化が用いられている、非限定的な例示的実施形態を示す。図１８には、ブリッジが、クライアントポートで受け取られたイーサネットフレームから、どのようにしてＵＤＰ／ＩＰカプセル化パケットを構築し得るかが示されている。好ましい実施形態では、ブリッジは、パケットを以下のように扱う。

１．ブリッジは、パケットをチェックし、ＡＦＤ、ＵＦＤおよびＰＬに従って、パケットが転送され得るか、それともブロックされるべきか決定する。パケットがブロックされるべきである場合、パケットは廃棄される。

２．ブリッジは、好ましくは、ＭＡＣアドレスでインデックスが付与されたＩＰアドレスとＰＳＫ（事前共用キー）のレコードを含む、例えば「ＰＩＴノードテーブル」などのテーブルで宛先ＭＡＣアドレスを検索する。いくつかの実施形態では、ＰＩＴノードテーブルが、管理者により、ブリッジで事前構成されていてもよい。好ましくは、イーサネットパケットの宛先ＭＡＣアドレスがテーブルで見つからない場合、パケットは、ＰＩＴなしの通常の方法で転送される。

３．ブリッジは、元のイーサネットパケットをカプセル化した新規のＵＤＰ／ＩＰパケットを構築する。ＰＩＴノードテーブル内のレコードから宛先ＩＰアドレスがコピーされる。このレコードは、宛先ＩＰノードでＰＩＴパケットを受け取るためのＵＤＰポート番号を含んでいてもよい。ソースＩＰアドレスは、ブリッジ自体のＩＰアドレスであってよい。ブリッジ識別子がこれのＩＰアドレスでテーブルされる場合、ＰＩＴパケットのサイズを縮小するために、以下の「ブリッジ識別子」フィールドが省略されてもよい。また、ブリッジは、「ブリッジ識別子」フィールドおよび「ブリッジポート番号」フィールドを含むＰＩＴ特有のフィールドも記入する。ブリッジ識別子は、ネットワーク内で使用されるすべてのブリッジの間で一意の番号である。ネットワークの管理者は、各ブリッジごとにこのように事前構成を行ってもよい。ブリッジポート番号は、ブリッジ内のポートを識別するものである。ＨＭＡＣフィールドが、例えば、ＰＩＴパケットを認証するために使用されてもよい。ブリッジは、好ましくは、ＰＩＴノードテーブルのレコードのＰＳＫを使って、ＰＩＴメッセージのＨＭＡＣを計算する。ＨＭＡＣは、好ましくは、ＩＰデータグラム全体にわたって計算される。

３．４．ブリッジに関するこの他の考慮事項
また、いくつかの好ましい実施形態では、ＰＡＡおよび／またはＤＨＣＰサーバの偽装を防ぐために、ブリッジは、あるクライアントポートから別のクライアントポートにＰＡＮＡおよびＤＨＣＰパケットを転送しないように構成されていてもよい。

４．実現例
以下の各セクションでは、２つの例示的実現形態を説明する。これらは、単なる説明例にすぎないことを、本開示に基づいて理解すべきである。

４．１．第１の実現形態の例
４．１．１．第１の例のシナリオ
第１の例示的実現形態によれば、システムは、ＡＦＤ、ＵＦＤ、および任意選択的に、ＰＬを用いることができる。好ましい実施形態では、システムは、以下の少なくとも一部、好ましくは全部を実行するはずである。

１−Ａ．「例１：ステップ１−Ａ」と表示された図１９を参照して、クライアント（クライアント１）がアクセスネットワークへの接続を開始する状況について考察する。ここで、クライアント１は、ブリッジ（Ｂ１）のポート１（Ｐ１）に接続されており、ブート時に第１のパケットを送る。例えば、これには、ルータ送信請求メッセージ、ＤＨＣＰ発見／送信請求メッセージまたは別の形の（１つまたは複数の）メッセージが関与する場合がある。

２−Ａ．「例１：ステップ２−Ａ」と表示された図２０を参照すると、ブリッジは、クライアント１のＵＦＤに新しいレコードを追加する（またはブリッジに追加させるようオーセンティケータに要求してもよい）。この理由は、ソースＭＡＣアドレス（ＭＡＣ１）がＡＦＤにも、ＵＦＤにも、ＰＬにも見つからないからである。好ましくは、ブリッジ（またはオーセンティケータ）は、新しいレコードの期限を維持するために新しいタイマを開始する。

３−Ａ．「例１：ステップ３Ａ」と表示された図２１を参照すると、クライアント１は、ブートストラップ時にメッセージ交換に移る。これらのメッセージ交換には、例えば、ＩＰアドレスの自動構成またはＤＨＣＰメッセージおよびＰＡＮＡ認証メッセージなどが含まれてよい。好ましくは、ネットワーク接続を開始するのに必要なこれらのメッセージは、クライアント１がＵＦＤにレコードを有することから、転送を許可される。

４−Ａ．「例１：ステップ４Ａ」と表示された図２２を参照すると、クライアント１が正常に認証された場合、オーセンティケータは、ブリッジ（Ｂ１）に、ＵＦＤ内のクライアント１レコードをＡＦＤに移動させるよう要求する。

５−Ａ．「例１：ステップ５Ａ」と表示された図２３を参照すると、クライアント１は、他のアプリケーションのためのメッセージ交換を開始する。この場合、ブリッジ（Ｂ１）は、好ましくは、クライアント１のレコード（ＭＡＣ１：Ｐ１）がＡＦＤに存在するため、任意の許可されたパケットを転送する。

他方、クライアント１が認証に失敗した場合、またはＵＦＤ内のクライアント１レコードが上記ステップ３−Ａの間に失効した場合、ステップ４−Ａから５−Ａは、好ましくは、以下のステップ４−Ｂから６−Ｂと置き換えられる。

４−Ｂ．「例１：ステップ４Ｂ」と表示された図２４を参照すると、クライアント１のレコードがＵＦＤから除去される。

５−Ｂ．「例１：ステップ５Ｂ」と表示された図２５を参照すると、任意選択的に、新しいレコード（ＭＡＣ１，Ｐ１）がＰＬに追加される。この場合、クライアント１から、かつ／またはクライアント１に転送された任意のパケットは、好ましくは、このレコードがＰＬに存続している間、ブリッジＢ１によって妨げられる。

６−Ｂ．このステップで、クライアント１は、ステップ１−Ａから再度開始する別の認証を試行することも、試行しない場合もある。

４．１．２．セキュリティ考慮事項
４．１．２．１．脅威１：スプーフィングによるサービス盗用
「例１：脅威１」と表示された図２６を参照すると、場合により、攻撃者は、クライアント１が認証された後、またはクライアント１が認証されようとする直前に、クライアントのＭＡＣアドレスＭＡＣ１を偽装してパケットを送ることもできる。例えば、これは、悪意のある情報に従ってブリッジにこれの（１つまたは複数の）転送データベースを更新させ、クライアント１にアドレス指定された後続のパケットを、正当なクライアント１ではなく攻撃者に転送させようとする意図をもって行うことができる。これが、サービス盗用攻撃の一例である。

しかしながら、Ｐ１以外のポートを介したＭＡＣ１との間のすべてのパケット交換は、好ましくは、ＡＦＤとＵＦＤのいずれかにレコード（ＭＡＣ１，Ｐ１など）が存在している間は妨げられる。結果として、この種の攻撃は、前述のステップ５−Ａ（すなわち、ＡＦＤがレコードを有する）およびステップ２−Ａから４−Ａ（すなわち、ＵＦＤがレコードを有する）の間に失敗するようになっている。

４．１．２．２．脅威２：認証なしのＤｏＳ攻撃
図２７乃至図２９を参照すると、場合により、攻撃者は、クライアント１のネットワークへの最初の接続の前に、クライアント１のＭＡＣアドレスＭＡＣ１を偽装したパケットを送ってもよい。例えば、攻撃者が、ＭＡＣ１を偽装したパケットをブリッジに送った場合、ブリッジは、ＵＦＤに新しいレコードを作成するはずであり、そのため、このレコードが存在する間、後でクライアント１によって送られるパケットは、ブリッジによってブロックされることになる。

次いで、攻撃者は、ステップ１−Ａから３−Ａ、および４−Ｂから６−Ｂを繰り返すことができる。攻撃者の状態がステップ１−Ａから４−Ｂまでの間にある期間、正当なクライアント１は、ネットワークにアクセスすることができないはずである。これが、別種のサービス拒否攻撃（ＤｏＳ攻撃）の例である。「例１：脅威２：（ステップ１−Ａから３−Ａおよび４−Ｂ）」と表示された図２７にこのようなＤｏＳ攻撃を示す。

加えて、攻撃者が認証試行で失敗し、ステップ５−Ｂがイネーブルにされた場合、攻撃者のレコード（ＭＡＣ１，Ｐ２）はペナルティリスト（ＰＬ）に追加されてよい。しかしながら、このレコードが存続する間、クライアント１は、ブリッジに、ＵＦＤにクライアント１のレコード（ＭＡＣ１，Ｐ１）を作成するパケットを送ることができない場合がある。しかしながら、クライアント１がＵＦＤにレコードを取得した後、クライアント１は、攻撃者に煩わされずに、認証を試みることができる。攻撃者がＤｏＳ攻撃に複数のポートを使用することができる場合、攻撃者は、おそらく、ＰＬ内にある他の攻撃ノードを用いて期間を埋めることができる。

「例１：脅威２：同時攻撃」と表示された図２９を参照すると、チャート（１）には、この複数のポートからの同時ＤｏＳ攻撃が示されている。チャート（１）では、攻撃者は、ポートＰ２、Ｐ３、Ｐ４を使用し、繰り返しブリッジに偽装パケットを送ろうとしている。時刻０で、Ｐ２のノードがパケットを送り、ＵＦＤにおいてレコードを獲得する。よって、このノードは、ポートＰ１の被害者が、ブリッジを介してパケットを送るのを妨げる。ＵＦＤ内の攻撃側のレコードは時刻１に失効するが、Ｐ３の別の攻撃ノードがブリッジにパケットを送り、ＵＦＤにおいてレコードを獲得する。このレコードは時刻２に失効するが、Ｐ４のさらに別のノードがＵＦＤにレコードを獲得する。このレコードが失効するときに、第１のノードＰ１は、再度パケットを送ることができるようになる。図示のように、これらのステップが繰り返されて、ＤｏＳ状態が生じ得る。

いくつかの実施形態では、この種の攻撃に対する１つの例示的解決策は、同じＭＡＣアドレスを有するＵＦＤとＰＬのレコードの数に比例して、ＰＬレコードの存続期間を延長することである。この種の解決策の説明例を図２９のチャート（２）に示す。チャート（２）に示すように、Ｐ２の攻撃ノードがパケットを送り、時刻０にＵＦＤにレコードを獲得し、Ｐ３のノードが、時刻１にレコードを取得する。Ｐ３のノードのＵＦＤレコードは時刻２に失効し、レコード（ＭＡＣ１，Ｐ３）がＰＬに移動される。しかしながら、チャート（１）に示すものとは対照的に、今度は、ＰＬレコードの存続期間が、ＵＦＤ内の類似のレコードの数とＰＬ内のレコード数に比例して計算される。この例では、時刻２において、ＵＦＤとＰＬにＭＡＣ１を有する２つのレコードがある。したがって、このレコードの存続期間は２倍にされる。時刻３において、Ｐ４のノードがＰＬに移動される。したがって、ＵＦＤとＰＬとに３つのＭＡＣ１のレコードがあるため、このレコードの存続期間は３倍にされる。結果として、Ｐ１の正当なノードには、時刻４と６の間および時刻７と９の間にブリッジにパケットを送る若干の可能性が生じることになる。

他の実施形態において、ＰＬ実現形態のさらなる可能な拡張には、ＭＡＣアドレスとポートの同じ組み合わせが繰り返しＰＬに追加されたときに、ＰＬレコードの存続期間を、ある一定の増加率で、または指数関数的に延長することが含まれてよい。これは、このセクションで説明しているＤｏＳ攻撃を一層実現し難くするはずである。しかしながら、これは、別種のＤｏＳ攻撃を容易にする結果にもなり得る。これに関して、攻撃者と被害者が同じポート１を使用する場合、攻撃者は、ＭＡＣアドレスＭＡＣ１を、Ｐ１から過剰な回数でＰＬに追加しようとすることがある。この後、被害者は、ＭＡＣアドレスがＭＡＣ１であるノードをポート１に接続しようとすると、ＰＬ内のレコード（ＭＡＣ１，Ｐ１）が指数関数的に大きい存続期間を有するため、これに失敗することがある。この後者の種類のＤｏＳ攻撃を防ぐために、このような指数関数的増加には適度の上限時間制限が有用である場合がある。

４．１．２．３．認証ありのＤｏＳ攻撃
「例１：脅威３」と表示された図３０を参照して、第１のユーザ「ユーザ１」がノード「クライアント１」を使用し、第２のユーザ「ユーザ２」がノード「クライアント２」を使用する状況を考察する。図示のように、クライアント１は、Ｐ１に接続されており、クライアント２はＰ２に接続されている。この例では、各ユーザ、ユーザ１およびユーザ２は、オーセンティケータ上に独自のアカウントを有する。ユーザ１がネットワークに接続するのを妨げるために、攻撃者ユーザ２は、クライアント１のＭＡＣアドレスを偽装して、クライアント２をネットワークに接続することができる。ユーザ２が認証に失敗した場合、状況は、前のセクションで説明している脅威２の場合と同様である。しかしながら、この場合、ユーザ２は、オーセンティケータ上に有効なアカウントを有するため、このユーザ自身のユーザクリデンシャル（資格情報）を使って認証を得ることができる。クライアント２は、ユーザ２のクリデンシャルを使って認証されるため、クライアント２のレコードがＡＦＤに作成される。したがって、クライアント１は、これにより、ブリッジＢ１に接続できなくなる可能性がある。この種の攻撃を防ぐために、ネットワーク管理者は、不当なユーザ２のクリデンシャルを取り消すことができる。代替として、管理者は、ユーザ１のクリデンシャルのみがＭＡＣ１の認証に使用できるように、オーセンティケータを構成することもできる。

いくつかの実施形態では、オーセンティケータが、クライアントのポート識別子を知ることができるように、オーセンティケータのより柔軟な構成が可能である。例えば、以下のセクション４．２．２．３の最後に列挙されている例を参照されたい。

４．２．第２の実現形態の例
４．２．１．第２の例のシナリオ
第２の例示的実現形態によれば、システムは、ＡＦＤ、ＰＩＴ、および任意選択的にＰＬを用いることができる。好ましい実施形態では、システムは、以下の少なくとも一部、好ましくは全部を実行することになる。

１−Ａ．「例２：ステップ１−Ａ」と表示された図３１を参照すると、このような例示的状況において、クライアント（クライアント１）が、アクセスネットワークへの接続を開始しようとする。図示のように、クライアント１は、ブリッジ（Ｂ１）のポート１（Ｐ１）に接続されており、ブート時に最初のパケットを送る。このメッセージは、ルータ送信請求メッセージ、ＤＨＣＰ発見／送信請求メッセージまたは別の（１つまたは複数の）メッセージとすることができる。

２−Ａ．「例２：ステップ２−Ａ」と表示された図３２を参照すると、ブリッジは、クライアント１から送られたパケットにＰＩＴを添付し、ソースＭＡＣアドレス（ＭＡＣ１）がＡＦＤとＰＬにないため、これを、ＰＩＴノードテーブルにある宛先ノードに転送する。図３２の例に示すように、ブリッジは、元のパケットの宛先アドレスがブロードキャストアドレスであるため、ＰＡＡとＤＨＣＰサーバにパケットを送る。前述のように、ブロードキャストパケットには、他の実現形態も使用できる。

３−Ａ．「例２：ステップ３−Ａ」と表示された図３３を参照すると、ＤＨＣＰサーバは、要求パケットからコピーされたＰＩＴを添付して、クライアント１に応答を送る。

４−Ａ．「例２：ステップ４−Ａ」と表示された図３４を参照すると、ブリッジは、パケットからＰＩＴを取り外し、これをＰＩＴで見つかったポートに転送する。

５−Ａ．「例２：ステップ５−Ａ」と表示された図３５を参照すると、クライアント１は、ブートストラップ時にメッセージ交換に移る。これらのメッセージ交換には、例えば、ＩＰアドレス自動構成またはＤＨＣＰメッセージおよびＰＡＮＡ認証メッセージが含まれていてもよい。

６−Ａ．「例２：ステップ６−Ａ」と表示された図３６を参照すると、クライアント１が正常に認証された場合、オーセンティケータは、ブリッジ（Ｂ１）に、クライアント１のためにＡＦＤに新しいレコードを追加するよう要求する。

７−Ａ．「例２：ステップ７−Ａ」と表示された図３７を参照すると、クライアント１は、他のアプリケーションのためのメッセージ交換を開始する。この場合、ブリッジ（Ｂ１）は、クライアント１のレコード（ＭＡＣ１：Ｐ１）がＡＦＤに存在するため、任意の許可されたパケットを転送する。

いくつかの好ましい実施形態では、クライアント１が上記のステップ５−Ａで認証に失敗した場合、オーセンティケータは、ブリッジに、クライアント１のためにＰＬに新しいレコードを追加するよう要求してもよい。

４．２．２．セキュリティ考慮事項
４．２．２．１．脅威１：スプーフィングによるサービス盗用
図３８から図３９を参照すると、場合により、攻撃者は、クライアント１が認証された後、またはクライアント１が認証されようとする直前に、クライアント１のＭＡＣアドレスＭＡＣ１を偽装したパケットを送ることがある。これは、悪意のある情報に従ってブリッジにこれの転送データベースを更新させ、クライアント１にアドレス指定された後続のパケットを、正当なクライアント１にではなく、攻撃者に転送させようとする意図をもって行われてよい。しかし、オーセンティケータおよびＤＨＣＰサーバは、好ましくは、ＭＡＣアドレスによってのみならず、ポート識別子によってもセッションを区別する。したがって、これらは、異なるポートから送られた偽装パケットによって混乱させられるべきではない。「例２：脅威１および２：ステップ５−Ａにおける複数セッション」と表示された図３８を参照されたい。加えて、ステップ６−Ａでクライアント１が認証され、クライアント１のレコードがＡＦＤに追加されると、Ｐ１以外のポートを介したＭＡＣ１との間のあらゆるパケット交換が妨げられることになる。結果として、この種の攻撃は失敗となるべきである。「例２：脅威１および２：ステップ７−Ａ」と表示された図３９を参照されたい。

４．２．２．２．脅威２：認証なしのＤｏＳ攻撃
やはり図３８から図３９を参照すると、場合によって、攻撃者は、クライアント１のネットワークへの最初の接続の前に、クライアント１のＭＡＣアドレスＭＡＣ１を偽装したパケットを送ることがある。これは、前述のＵＦＤを使った実現形態ではおそらく問題となる可能性もあるが、前述のＰＩＴを使った実現形態では問題となってはならない。

オーセンティケータとＤＨＣＰサーバが複数のセッションを区別することができるため、クライアント１は、攻撃者が偽装パケットを送っている間、常に、クライアント１の認証を試みることができる。「例２：脅威１および２：ステップ５−Ａにおける複数セッション」と表示された図３８を参照されたい。ステップ６−Ａで、クライアント１が認証され、クライアント１のレコードがＡＦＤに追加されると、Ｐ１以外のポートを介したＭＡＣ１との間のあらゆるパケット交換が妨げられる。したがって、このような攻撃は、失敗することになる。「例２：脅威１および２：ステップ７−Ａ」と表示された図３９を参照されたい。

４．２．２．３．脅威３：認証ありのＤｏＳ攻撃
次に、ａ）ユーザ「ユーザ１」がノード「クライアント１」を使用し、ユーザ「ユーザ２」が「クライアント２」を使用し、ｂ）クライアント１はポートＰ１に接続されており、クライアント２はポートＰ２に接続されており、ｃ）ユーザ１とユーザ２は、それぞれ、オーセンティケータ上に独自のアカウントを有する場合の例を考察する。ユーザ１がネットワークに接続するのを妨げるために、攻撃者ユーザ２は、クライアント１のＭＡＣアドレスを偽装して、クライアント２をネットワークに接続することができる。ユーザ２が認証に失敗した場合、状況は、前のセクションで説明している脅威２に同様である。しかしながら、今回、ユーザ２は、オーセンティケータ上に有効なアカウントを有するため、ユーザ自身のユーザクリデンシャルを使って認証できる。さらに、クライアント２は、ユーザ２のクリデンシャルを使って認証されるため、クライアント２のレコードがＡＦＤに作成される。結果として、クライアント１は、このために、ブリッジＢ１に接続することができなくなる可能性がある。

この種の攻撃を防ぐために、ネットワーク管理者は、不当なユーザ２のクリデンシャルを取り消すことができる。代替として、管理者は、ユーザ１のクリデンシャルのみがＭＡＣ１の認証に使用できるようにオーセンティケータを構成する場合もある。

ＰＩＴは、オーセンティケータのより柔軟な構成を可能にする。例えば、オーセンティケータは各メッセージのポート識別子を知っているため、ポート識別子を使って制限を指定することが可能である。いくつかの例示的実施形態では、例えば、以下の規則の一部または全部が実施されてもよい。

ＭＡＣ１の認証要求がポートＢ１：Ｐ２からもたらされた場合、これを拒否する。例えば、この規則は、前述の場合に役立つことがある。

ユーザ１のクリデンシャルがポートＢ１：Ｐ１以外のポートからもたらされた場合、これを受け入れない。ユーザ１が、特定のポートＢ１：Ｐ１においてこのユーザのネットワークノードを使用する場合、この規則は役立ち得る。結果として、何者かがユーザ１のシークレットキーを盗んだ場合でも、攻撃者は、ポートＢ１：Ｐ１以外のポートでこのキーを使用することができない。

ＭＡＣ１の認証要求が、ポートＢ１：Ｐ１以外のポートからもたらされた場合、これを拒否する。ポートＢ１：Ｐ１に接続されたネットワークノードがあり、このノードが数人のユーザの間で共用されているものとする。好ましくは、各ユーザは、このノードを使用するための自分のアカウントを有する。各ユーザはこのノードを使用することができ、攻撃者は、Ｂ１：Ｐ１以外のポートからＤｏＳ攻撃を行うことができない。

ポートＢ１：Ｐ１からのあらゆる有効なクリデンシャルを許可し、Ｂ１：Ｐ１以外の（１つまたは複数の）ポートにおいては、クリデンシャルとＭＡＣの限られた組み合わせのみを許可する。この規則は、ポートＢ１：Ｐ１がセキュリティ保護された部屋に置かれており、他のポートがセキュリティ保護されていない開放された場所に位置している場合に役立つことがある。

第３部：ネットワークアクセス認証プロトコルからのマルチキャストセキュリティのブートストラップ
１．背景情報
１．１．参照文献
以下の一般的背景の参照文献全部を、参照により本明細書に組み込むものである。

１．Ｂ．Ｃａｉｎら、「インターネットグループ管理プロトコル、バージョン３（Internet Group Management Protocol, Version 3)」、RFC3376、２００２年１０月（以下［RFC3376］という）。

２．Ｒ．ＶｉｄａおよびＬ．Ｃｏｓｔａ、「ＩＰｖ６のためのマルチキャストリスナ発見バージョン２（ＭＬＤｖ２）（Multicast Listener Discovery Version 2 (MLDv2)for IPv6)」、RFC3810、２００４年６月（以下［RFC3810］という）。

３．Ｔ．Ｈａｙａｓｈｉら、「マルチキャストリスナ発見認証プロトコル（ＭＬＤＡ）（Multicast Listener Discovery Authentication Protocol (MLDA)）」、インターネット草案、draft-hayashi-mlda-02.txt、作成中、２００４年４月（以下［ＭＬＤＡ］という）。

４．Ｍ．Ｃｈｒｉｓｔｅｎｓｅｎら、「ＩＧＭＰおよびＭＬＤスヌープスイッチのための考慮事項（Considerations for IGMP and MLD Snooping Switches）」、インターネット草案、draft-ietf-magma-snoop-11.txt、作成中、２００４年５月、（以下［ＭＬＤＳＮＯＯＰ］という）。

５．Ｂ．ＬｌｏｙｅｄおよびＷ．Ｓｉｍｐｓｏｎ、「ＰＰＰ認証プロトコル（PPP Authentication Protocols）」、RFC1334、１９９２年１０月（以下［RFC1334］という）。

６．Ｍ．Ｂａｕｇｈｅｒら、「セキュアなリアルタイムトランスポートプロトコル（ＳＲＴＰ）（The Secure Real-time Transport Protocol (SRTP)）」、RFC3711、２００４年３月、（以下［RFC3711］という）。

７．Ｊ．Ａｒｋｋｏら、「ＭＩＫＥＹ：マルチメディアインターネットキー管理（MIKEY: Multimedia Internet Keying）」、インターネット草案、draft-ietf-msec-mikey-08.txt、作成中、２００３年１２月（以下［MlKEY］という）。

８．Ｍ．ＴｈｏｍａｓおよびＪ．Ｖｉｌｈｕｂｅｒ、「キーのKerberosによるインターネット折衝（KINK)(Kerberized Internet Negotiation of Keys (KINK)）」、インターネット草案、draft-ietf-kink-kink-05.txt、作成中、２００３年１月（以下［KINK］という）。

９．Ｔ．ＨａｒｄｊｏｎｏおよびＢ．Ｗｅｉｓ、「マルチキャストグループセキュリティアーキテクチャ（The Multicast Group Security Architecture）」、RFC3740、２００４年３月（以下［RFC3740］という）。

１０．Ｈ．Ｈａｒｎｅｙら、「ＧＳＡＫＭＰ」、インターネット草案、draft-ietf-msec-gsakmp-sec-06.txt、作成中、２００４年６月（以下［ＧＳＡＫＭＰ］という）。

１１．Ｔ．ＮａｒｔｅｎおよびＥ．Ｎｏｒｄｍａｒｋ、「ＩＰバージョン６（ＩＰｖ６）のための近隣探索（Neighbor Discovery for IP Version 6 (IPv6)）」、RFC2461、１９９８年１２月（以下［RFC2461］という）。

１２．Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅら、「ＲＴＰ：リアルタイムアプリケーションのためのトランスポートプロトコル（RTP: A Transport Protocol for Real-time Applications）」、RFC3550、２００３年７月（以下［RFC3550］という）。

１３．Ｂ．Ａｂｏｂａら、「拡張可能認証プロトコル（ＥＡＰ）（Extensible Authentication Protocol (EAP)）」、RFC3748、２００４年６月（以下［RFC3748］という）。

１４．Ｂ．Ａｂｏｂａら、「拡張可能認証プロトコル（ＥＡＰ）キー管理フレームワーク（Extensible Authentication Protocol (EAP)Key Management Framework）」、インターネット草案、draft-ietf-eap-keying-02.txt、作成中、２００４年６月（以下［EAP-KEY］という）。

１５．Ｄ．Ｗａｉｔｚｍａｎら、「距離ベクトル型マルチキャスト経路プロトコル（Distance Vector Multicast Routing Protocol）」、RFC1075、１９９８年１１月（以下［RFC1075］という）。

１６．Ａ．Ｂａｌｌａｒｄｉｅ、「コアベースツリー（ＣＢＴバージョン２）マルチキャストルーティング（Core Based Trees (CBT version 2)Multicast Routing）」、RFC2189、１９９７年９月（以下［RFC2189］という）。

１７．Ｄ．Ｅｓｔｒｉｎら、「プロトコル独立マルチキャスト粗モード（ＰＩＭ−ＳＭ）：プロトコル仕様（Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification）」、RFC2362、１９９８年６月（以下［RFC2362］という）。

１８．Ｄ．Ｆｏｒｓｂｅｒｇら、「ネットワークアクセスための認証を搬送するプロトコル（ＰＡＮＡ）（Protocol for Carrying Authentication for Network Access (PANA)）」、インターネット草案、draft-ietf-pana-pana-04.txt、作成中、２００４年５月７日（以下［ＰＡＮＡ］という）。

１９．ローカルおよびメトロポリタンエリアネットワークのためのＩＥＥＥ規格、「ポートベースのネットワークアクセス制御（Port-Based Network Access Control）」、ＩＥＥＥ規格８０２．１Ｘ−２００１（以下［８０２．１Ｘ］という）。

１．２．用語
本開示において、「マルチキャストルータ」という用語には、例えば、ＩＰマルチキャストパケットを転送することのできるルータが含まれる。いくつかの例では、同じＩＰリンクに複数のＩＰマルチキャストルータがある場合もある。

本開示において、「マルチキャストリスナ」という用語には、例えば、ＩＰマルチキャストパケットを受け取ろうとしているホストまたはルータなどが含まれる。

１．３．ＩＰマルチキャスト概要
図４０に、ＩＰマルチキャストネットワークの例を示す。この説明例で、Ｓ１およびＳ２は、ネットワークに、特定のマルチキャストアドレスＧに向けられたＩＰマルチキャストパケットを発信するノードである。Ｒ１、Ｒ２およびＲ３は、ＩＰマルチキャストパケットを転送することのできるルータである。加えて、Ｄ１、Ｄ２およびＤ３は、ＩＰマルチキャストパケットの最終受信者となるノードである。この説明例では、各リンクがポイントツーポイントリンクであるものとする。

図４１から図４２に、Ｓ１とＳ２から、それぞれ、図４０に示すネットワークのマルチキャストアドレスＧに発信されたマルチキャストパケットのＩＰマルチキャストパケット転送パスの例を示す。マルチキャストパケットをリスナに転送するために、各ルータによってマルチキャストルーティングテーブルが維持される。マルチキャストルーティングテーブルは、統計的に、動的に、または統計的と動的の両方で構築できる。距離ベクトル型マルチキャストルーティングプロトコル（［ＲＦＣ１０７５］参照）、ベースツリー（［ＲＦＣ２１８９］参照）、およびＰＩＭ（プロトコル独立マルチキャスト）（［ＲＦＣ２３６２］参照）が、マルチキャストルーティングテーブルの動的構築に使用され得る。結果として生じるマルチキャスト転送パスは、使用するマルチキャストルーティングプロトコルに応じて異なり得る。これらの例で、ルータＲ３は、各マルチキャストパケットを、マルチキャストアドレスＧの複数の次のホップノードに転送するために、各マルチキャストパケットの複数のコピーを作成する必要がある。

図４３に、共用リンクを含むＩＰマルチキャストネットワークの説明例を示す。図示ように、Ｓ１およびＳ２は、ネットワークに、特定のマルチキャストアドレスＧに向けられたＩＰマルチキャストパケットを発信するノードである。Ｒ１、Ｒ２およびＲ３は、ＩＰマルチキャストパケットを転送することのできるルータである。加えて、Ｄ１、Ｄ２およびＤ３は、ＩＰマルチキャストパケットの最終的な受信者となるノードである。

図４４に、Ｓ１からマルチキャストアドレスＧに発信されたマルチキャストパケットのＩＰマルチキャストパケット転送パスの説明例を示す。前の例と異なり、ここでは、ルータＲ１は、マルチキャストパケットを転送するためにマルチキャストパケットの複数のコピーを作成する必要はない。

１．４．マルチキャストリスナ発見
マルチキャストリスナ発見（ＭＬＤ）は、マルチキャストリスナ状態を維持するために同じＩＰリンク上のＩＰｖ６マルチキャストルータとＩＰｖ６マルチキャストリスナの間で実行するように設計されたプロトコルである。

以下で、ＭＬＤプロトコルのバージョン２の概要を説明する（［ＲＦＣ３８１０］も参照されたい）。ＩＰｖ４では、ＩＧＭＰ（インターネットグループ管理プロトコル）（［ＲＦＣ３３７６］参照）がＭＬＤと類似の目的に使用される。ＭＬＤとＩＧＭＰは類似の機能を提供するため、（メッセージ名およびアドレス型に関する相違を除く）類似の説明および考察がＩＧＭＰにも適用され得る。したがって、本開示では、ＩＧＭＰに関連する考察は、本開示ではこれ以上詳述しない。

マルチキャストリスナ状態は、マルチキャストルータのリンクごとに維持され、概念的には、（ＩＰｖ６マルチキャストアドレス，フィルタモード，ソースリスト）の形のレコードの組が関与する。フィルタモードは、ＩＮＣＬＵＤＥ（使用）またはＥＸＣＬＵＤＥ（除外）を指示し、ＩＮＣＬＵＤＥは、ソースリストに記載されている任意のソースアドレスから送られ、ＩＰｖ６マルチキャストアドレスに向けられたマルチキャストパケットがリンク上で転送されることを指示し、ＥＸＣＬＵＤＥは、ソースリストに記載されている任意のソースアドレスから送られ、ＩＰｖ６マルチキャストアドレスに向けられたマルチキャストパケットがリンク上で転送されないことを指示する。

ＭＬＤｖ２で、マルチキャストルータは、各リンク上で定期的に、または要求に応じて、マルチキャストリスナ照会（ＭＬＱ）メッセージをマルチキャストする。ＭＬＱメッセージは、リンクのマルチキャストリスナ状態に変更を生じさせるマルチキャストリスナ報告（ＭＬＲ）メッセージがリンク上で受け取られたときに、要求に応じて送られる。マルチキャストリスナは、特定のマルチキャストアドレス（またはソース）をリッスン(listen)しようとする要求またはもはやリッスンしないという要求を表明するときに、あるいはＭＬＱメッセージを受け取ったときに、ＭＬＲメッセージを送る。マルチキャストルータは、ＭＬＲを受け取ったときにマルチキャストリスナ状態を更新する。マルチキャストルータは、特定のソースＳから発信され、リンク上の特定のマルチキャストアドレスＧに向けられたマルチキャストパケットを、リンクのマルチキャストリスナ状態が、ソース／宛先アドレス対（Ｓ，Ｇ）を有する転送パケットが明示的に許可されており、または明示的に禁止されていないことを指示している場合に限って転送する。

図４５に、（Ｓ１，Ｇ）または（Ｓ２，Ｇ）マルチキャストトラフィックのマルチキャストリスナの有無を照会するＭＬＱメッセージの送信例を示す。図４６に、図４５のＭＬＱに応答して、（Ｓ１，Ｇ）トラフィックのマルチキャストリスナＮ１およびＮ２の存在を報告するＭＬＲメッセージの送信例を示す。

１．５．ＭＬＤスヌープ
図４７乃至図４８に、図４５から図４６に示すＭＬＤ手順の完了後の（Ｓ１，Ｇ）マルチキャストパケットのパケット転送を示す。図４７において、リンク層スイッチＳＷは、いわゆる「ＭＬＤスヌープ」（［ＭＬＤＳＮＯＯＰ］参照）の機能を有していない。図４８において、リンク層スイッチＳＷは、この「ＭＬＤスヌープ」機能を有する。ＭＬＤスヌープ(snooping)を有するリンク層スイッチは、リンク層フレームのペイロードを調べて、ＭＬＤヘッダまたはペイロードおよびＩＣＭＰを含む上位層情報を参照し、ＩＰマルチキャストパケットを搬送するリンク層マルチキャストデータフレームを、ＭＬＤメッセージ交換を監視することによって、マルチキャストリスナの存在が知られているポートにだけ転送する。より具体的には、マルチキャストリスナは、スイッチがポート上でＭＬＲメッセージを参照する場合にこのスイッチのポートに存在するものとみなされ、マルチキャスト宛先アドレスやマルチキャストソースアドレス等の、ＭＬＲメッセージペイロードの内容を使用することによって、よりきめ細かい（またより効率的な）リンク層マルチキャスト転送が可能になる。ＭＬＤスヌープがないと、スイッチは、転送が許容されている任意のリンク層マルチキャストデータフレームを、マルチキャストリスナがないポートを含むすべてのポートに転送することになり、非効率的なリソース使用をもたらしかねない。

１．６．ＭＬＤ認証
ＭＬＤ認証プロトコルまたはＭＬＤＡプロトコルと呼ばれるＭＬＤのセキュアな拡張が、上記の参照文献［ＭＬＤＡ］で定義されている。ＭＬＤＡプロトコルは、リンク上の認証されたマルチキャストリスナのみが、マルチキャストルータのこのリンクのマルチキャストリスナ状態を更新することができるように、マルチキャストリスナがマルチキャストルータへの認証を受ける機能を提供する。このように、ＭＬＤ認証は、データトラフィックを、認証され、許可されている加入者ノードだけに転送することによる加入ベースのマルチキャストストリーミングコンテンツ配信に使用され得る。ＭＬＤＡは、マルチキャストリスナを認証するためにＰＡＰ（パスワード認証プロトコル）およびＣＨＡＰ（チャレンジ／応答認証プロトコル）認証プロトコルをサポートしており、これは、マルチキャストリスナのパスワードがアクセスネットワーク内のあらゆるマルチキャストルータ上に保存されるのを回避するために、マルチキャストルータ上にＡＡＡクライアント機能を有することによって、マルチキャストリスナが、バックエンドＡＡＡ（認証、許可およびアカウンティング）サーバによって認証されるようにする。

１．７．ＳＲＴＰ
ＳＲＴＰ（セキュアなリアルタイムトランスポートプロトコル）は、上記参照文献［ＲＦＣ３７１１］に記載されており、アプリケーション層のパケットごとの暗号化、保全性保護および反復再生の保護を提供する。

２．既存の方法の問題
以下で説明するように、既存の方法には様々な問題および限界がある。

問題１
第１の問題には、ＭＬＤ自体が、無許可のリスナが、マルチキャストパケットを受け取るためにマルチキャストリスナ状態を変更するＭＬＲメッセージを送ることを妨げないことが関与しており、これは、リスナとマルチキャストルータの間のリンクの種類（ポイントツーポイントや共用など）を問わず、また、共用リンクの場合にリンク上でＭＬＤスヌープが使用されているか否かに関わりなく、マルチキャストベースのサービスへのただ乗りを招くことになる。

これに関しては、例えば、リスナ認証およびＭＬＤＡによって提供される認証と結合された適切なアクセス制御を用いるなどによって、ＭＬＤＡが、このセキュリティ問題を解決するために使用できるはずである。しかしながら、このような、リスナ認証およびＭＬＤＡなどの認証機構と結合されたアクセス制御方法はいまだ存在していない。

問題２
第２の問題には、ＭＬＤＡによってサポートされている認証プロトコルの弱点に起因するセキュリティ問題が関与する。ＭＬＤＡによってサポートされているＰＡＰとＣＨＡＰの両方が、ＰＡＰおよびＣＨＡＰの共用キーとしてマルチキャストリスナの静的パスワードが使用されているときに、辞書攻撃に対して脆弱であることが知られているため、これらのアルゴリズムの使用は危険であり、これらの認証プロトコルが、セキュアな通信路を介して実行されるものでない限り推奨されない。特に、ＰＡＰおよびＣＨＡＰは、攻撃者が、ユーザパスワードを獲得し、または推測するために、容易に偽のアクセスポイントになりすますことのできる無線ＬＡＮを介して使用されるべきではない。

問題３
第３の問題には、ＭＬＤＡが、ＭＬＤＡペイロードの機密保持を提供しないことが関与する。さらに、ＭＬＤＡは、ＭＬＤへの変更も必要とする。

問題４
第４の問題に関与するのは、ＭＬＤＡはＡＡＡと統合できるが、大部分の商用アクセスネットワークは、やはりＡＡＡと統合されるネットワークアクセス認証を必要とするため、好ましくはできる限り回避されるべきである、ＡＡＡ手順を２回実行すること、すなわち、一度はグローバルＩＰアドレスを獲得するネットワークアクセス認証のために、一度はクリデンシャルを受け取るために提示することを考慮すると、マルチキャストリスナでもあるネットワークアクセスクライアントが、非効率的な信号を生じることになる可能性がある点である。

問題５
第５の問題には、ＭＬＤＡおよびＩＥＥＥ８０２．１１ｉを含むネットワーク層および／またはリンク層セキュリティ機構のみに頼った解決策では、無線アクセスリンクを介してネットワークアクセスを認証され、許可されているクライアントが、リンク上で他のマルチキャストリスナに転送されたマルチキャストデータパケットを受信し、復号化するのを防ぐことができない点が関与する。これは、完全に共用されているアクセスリンクを介したマルチキャストサービスのただ乗りを回避するには、ＳＲＴＰ（［ＲＦＣ３７１１］参照）など上位層のパケットごとのセキュリティ機構が必要とされることを意味する。このような上位層のパケットごとのマルチキャストセキュリティ機構は、マルチキャストキー配布手順を自動化するために、マルチキャストリスナにマルチキャスト暗号キーを配信する交換プロトコルを必要とする。上記ＭＩＫＥＹ（［ＭＩＣＫＥＹ］参照）およびＫＩＮＫ（［ＫＩＮＫ］参照）は、このようなものとして機能するように設計されている。しかしながら、このようなマルチキャストキー交換プロトコルを使用するのに必要なクリデンシャルを確立する実際の解決策はない。

３．解決策案
３．１．ネットワークアクセス認証からのＭＬＤＡのブートストラップ
ＭＬＤＡを使用することの１つの問題は、マルチキャストリスナの静的パスワードをＭＬＤＡにおけるＰＡＰおよびＣＨＡＰの共用シークレットキーとして使用することに起因する。１つの解決策は、ＭＬＤＡにおけるＰＡＰおよびＣＨＡＰに動的に生成された共用シークレットキーを使用することである。共用シークレットキーは、好ましくは、このシークレットキーが限られた期間の間だけ有効であるような存続期間を有する。本開示では、ＭＬＤＡで使用される共用シークレットキーに基づいたマルチキャストリスナとマルチキャストルータの間のセキュリティアソシエーションを、ＭＬＤＡセキュリティアソシエーションまたはＭＬＤＡ ＳＡといい、共用シークレットキーをＭＬＤＡキーという。好ましい実施形態において、ＭＬＤＡキーの動的生成をアーカイブする２つの例示的方法を以下で説明する。

第１の方法において、ＭＬＤＡキーは、例えば、ＰＡＮＡ（［ＰＡＮＡ］参照）やＩＥＥＥ８０２．１Ｘ（［８０２．１Ｘ］参照）などのネットワークアクセス認証プロトコルを使って動的に作成される認証セッションキーから導出される。ネットワークアクセス認証プロトコルにＰＡＮＡまたはＩＥＥＥ８０２．１Ｘが使用されるとき、認証セッションキーは、ＡＡＡキーを介してＥＡＰ（［ＲＦＣ３７４８］参照）マスタセッションキー（ＭＳＫ）から導出され得る（［ＥＡＰ−ＫＥＹ］参照）。

第２の方法において、ＭＬＤＡキーは、暗号化され、ＰＡＮＡやＩＥＥＥ８０２．１Ｘなどのネットワークアクセス認証プロトコルを介して搬送できる。ネットワークアクセス認証としてＰＡＮＡが使用されるとき、暗号化ＭＬＤＡキーは、例えば、ＰＡＮＡバインド要求メッセージおよびＰＡＮＡバインド応答メッセージなどとして搬送されてよい。この場合、ＭＬＤＡキーは、例えば、キー配布センタ（ＫＤＣ）などによって生成され、または管理できる。この場合、ＭＬＤＡキー配布機構が、本開示に基づいて、適宜このような目的で実施されてもよい。

図４９に、第１の方法におけるＭＬＤＡキー階層を示す。図４９では、３つのプロトコルエンティティ、すなわち、ＥＡＰ、ネットワークアクセス認証プロトコル（ＰＡＮＡやＩＥＥＥ８０２．１Ｘなど）、およびＭＬＤＡが含まれている。ＭＬＤＡキーの存続期間は、ＭＬＤＡキーと一緒に、ネットワークアクセス認証エンティティからＭＬＤＡエンティティに配信されてよいことに留意されたい。

長期パスワードを使用するのではなく、短期共用シークレットキーをＭＬＤＡキーとして使用することによって、ＭＬＤＡのセキュリティレベルが改善できる。特に、これは、前のセクション２で説明している問題２に対する解決策を提供する。加えて、これらの例示的方法は、ネットワークアクセス認証のためのＡＡＡ手順が行われた後、ＭＬＤＡのための別のＡＡＡ手順が必要とされないという点で効率的である。結果として、これらは、前のセクション２で説明している問題４に対する解決策も提供することになる。

様々な実施形態において、本開示に基づき、当分野の技術者によって、適宜、ＭＬＤＡキー導出アルゴリズムが実施できる。

図５３に、第１の方法の機能モデルを示す。図示のように、ＥＰＡ−Ｓ（ＥＡＰサーバ）は、ＥＡＰ方法のエンドポイントである。ＡＡ（認証エージェント）は、ネットワークアクセス認証プロトコルのオーセンティケータ（ＩＥＥＥ８０２．１ＸオーセンティケータやＰＡＮＡエージェントなど）である。Ｒはマルチキャストルータである。Ｌはマルチキャストリスナである。いくつかの実施形態では、ＥＡＰ−Ｓは、ＡＡと同じ物理エンティティ内に位置してよい。加えて、いくつかの実施形態では、ＡＡも、ＥＡＰ−ＳまたはＲと同じ物理エンティティ内に位置してよい。

図５３を参照すると、ＭＬＤＡが実行される前に、ネットワークアクセス認証が、ＬとＡＡの間で行われる。いくつかの実施形態では、ネットワークアクセス認証は、Ｌを認証するのにＥＡＰを使用し、ここでＡＡは、ＥＡＰ−Ｓと連絡をとり、ＡＡＡプロトコルまたはＡＰＩを介してＡＡＡキーを獲得する。ネットワークアクセス認証が正常に完了すると、ＡＡは、ＡＡＡキーからＭＬＤＡキーを導出し、ＭＬＤＡキーをＲに渡す。Ｌは、同じＭＬＤＡキーを、ＡＡと共用するＡＡＡキーからローカルで導出する。この後、ＲおよびＬは、ＭＬＤＡを実行することができる。

図５４に、第２の方法の機能モデルを示す。図示のように、ＥＡＰ−Ｓ（ＥＡＰサーバ）は、ＥＡＰ方法のエンドポイントである。ＡＡ（認証エージェント）は、ネットワークアクセス認証プロトコルのオーセンティケータ（ＩＥＥＥ８０２．１ＸオーセンティケータやＰＡＮＡエージェントなど）である。Ｒはマルチキャストルータである。Ｌはマルチキャストリスナである。加えて、ＫＤＣは、キー配布センタである。いくつかの実施形態では、ＥＡＰ−Ｓは、ＡＡと同じ物理エンティティに位置し得る。加えて、いくつかの実施形態では、ＡＡも、ＥＡＰ−ＳまたはＲと同じ物理エンティティに位置し得る。さらに、ＫＤＣも、ＥＡＰ−Ｓ、ＡＡまたはＲと同じ物理エンティティに位置し得る。

図５４を参照すると、まず、ＬとＡＡの間でネットワークアクセス認証が行われる。ネットワークアクセス認証は、Ｌ１を認証するのにＥＡＰを使用し、ここでＡＡは、ＥＡＰ−Ｓに連絡をとり、ＡＡＡプロトコルまたはＡＰＩを介してＡＡＡキーを獲得する。ネットワークアクセス認証が正常に完了すると、ＡＡは、ＫＤＣからＭＬＤＡキーのコピーを獲得し、これを暗号化して、ネットワークアクセス認証プロトコルを介してＬに配信する。Ｒは、ＫＤＣからＭＬＤＡキーのコピーを獲得してもよい。ＭＬＤＡキーがＬに配信されると、ＲおよびＬはＭＬＤＡを実行することができる。

３．２．マルチキャストＩＰｓｅｃを用いたＭＬＤの保護
ＭＬＤＡを使用する代わりに、ＩＰｓｅｃ ＡＨおよび／またはＥＳＰを使ってＭＬＤプロトコル交換を保護することも可能である。この方法は、保全性保護および反復再生の保護のみならず、ＭＬＤメッセージの内容の機密保護も提供する。加えて、この方法は、ＭＬＤプロトコル自体への変更を全く必要としない。これら２つ（ＩＰｓｅｃ ＡＨおよび／またはＥＳＰ）は、前のセクション２で説明した問題３のための解決策を提供する。ＭＬＤプロトコルは（例えばリンクローカルなどの）マルチキャスト通信に基づくものであるため、基礎をなすＩＰｓｅｃ ＳＡは、（例えば、ＭＬＤの場合のマルチキャストリスナとマルチキャストルータの間の）多対多アソシエーションであるグループセキュリティアソシエーションまたはＧＳＡ（［ＲＦＣ３７４０］参照）を形成する。ＩＰｓｅｃ ＧＳＡを自動的に作成するために、マルチキャストキー管理プロトコルが使用されてよい。ＧＳＡを確立するのに使用できる、ＧＳＡＫＭＰ（［ＧＳＡＫＭＰ］参照）、ＭＩＫＥＹ（［ＭｌＫＥＹ］参照）、ＫＩＮＫ（［ＫｌＮＫ］参照）等の、いくつかのキー管理プロトコルがある。

ＩＫＥなどのユニキャストキー管理プロトコルと同様に、マルチキャストキー管理プロトコルは、一般に、ユニキャスト通信に基づくものであるはずであり、マルチキャストキーが誤ったエンティティによって確立されるのを回避するために、エンドポイントの相互認証を有するべきである。これは、マルチキャストキー管理プロトコルにおける相互認証に使用されるあるキーが、マルチキャストキー管理プロトコルの各エンドポイントで事前構成される必要があることを意味する。このようなキーをマルチキャストキー管理キーまたはＭＫＭキーという。好ましい実施形態では、方法案は、ＭＫＭキーを導出することに基づくものであり、ＭＬＤＡキーを導出するのと同じようにネットワークアクセス認証プロトコルから導出される。

図５０に、マルチキャストキー管理プロトコルを使用することによってＩＰｓｅｃ ＧＳＡが確立され、ネットワークアクセス認証プロトコルからＭＫＭキーが導出される場合のマルチキャストＩＰｓｅｃキー階層を示す。

このキー導出モデルは、マルチキャストＩＰｓｅｃを用いてＭＬＤをセキュリティ保護するためのみならず、マルチキャストＩＰｓｅｃを用いて、ＩＰｖ６近隣探索（［ＲＦＣ２４６１］参照）やＲＴＰ（［ＲＦＣ３５５０］参照）など、他のマルチキャスト通信プロトコルをセキュリティ保護するためにも使用され得る。

この例示的方式は、例えば、ネットワークアクセス認証のためのＡＡＡ手順が行われた後、ＭＬＤＡのための別のＡＡＡ手順が必要とされないなどの点で、非常に効率的となり得る。結果として、これは、前のセクション２で説明されている問題４に対する解決策を提供することになる。

様々な実施形態において、各可能なマルチキャストキー管理プロトコルごとのＭＫＤ導出アルゴリズムが、本開示に基づき、当分野の技術者によって、適宜、実施できる。

図５５に、この方法の機能モデルを示す。図示のように、ＥＡＰ−Ｓ（ＥＡＰサーバ）はＥＡＰ方法のエンドポイントである。ＡＡ（認証エージェント）はネットワークアクセス認証プロトコルのオーセンティケータ（例えば、ＩＥＥＥ８０２．１ＸオーセンティケータやＰＡＮＡエージェントなど）である。ＲはマルチキャストＩＰｓｅｃ受信者である。ＳはマルチキャストＩＰｓｅｃ送信者である。ＫＭＳはキー管理プロトコルサーバである。ここで、ＥＡＰ−Ｓは、ＡＡと同じ物理エンティティに位置していてもよい。加えて、ＫＭＳも、ＡＡ、ＥＡＰ−ＳまたはＳと同じ物理エンティティに位置していてもよい。

図５５では、まず、ＲとＡＡの間でネットワークアクセス認証が行われる。ネットワークアクセス認証は、Ｒを認証するのにＥＡＰを使用し、ここでＡＡは、ＥＡＰ−Ｓに連絡をとり、ＡＡＡプロトコルまたはＡＰＩを介してＡＡＡキーを獲得する。ネットワークアクセス認証が正常に完了すると、ＡＡは、ＡＡＡキーからＭＫＭキーを導出し、ＭＫＭキーをＫＭＳに渡す。次いで、キー管理プロトコルが、ＫＭＳとＲの間で実行される。キー管理プロトコルがＩＰｓｅｃ暗号キーを生成した後、ＩＰｓｅｃ暗号キーがＫＭＳからＳに配信され、最終的に、ＳおよびＲは、ＭＬＤまたはマルチキャストＩＰｓｅｃを介した他の任意のマルチキャストベースのプロトコルを実行することができる。

３．３．ＭＬＤまたはＭＬＤＡとリンク層マルチキャストアクセス制御の統合
いくつかの実施形態では、レイヤ２マルチキャストフレームの限られたポートの組へのコピー（限られたマルチキャスト機能など）をサポートするリンク層スイッチが、共用リンクを介したマルチキャストトラフィックのアクセス制御に使用できる。

ＩＰｓｅｃを用いたＭＬＤＡまたはＭＬＤがマルチキャストリスナ状態をセキュアに維持するのに使用されるとき、マルチキャストルータは、リンク上のこのようなリンク層スイッチを、マルチキャストパケットが、暗号として有効なＭＬＲメッセージが受け取られるマルチキャストリスナがあるポートに転送されるように制御することができる。この方法では、ＩＰｓｅｃを用いたＭＬＤＡおよびＭＬＤが、前のセクション３．１および３．２で説明している方法を使って、ＰＡＮＡやＩＥＥＥ８０２．１Ｘなどのネットワークアクセス認証プロトコルからブートストラップできる。

限られたマルチキャスト機能を備えるリンク層スイッチが、前述の「ネットワークブリッジおよびネットワークアクセス認証のバインディング」という表題の第２部で説明している方式もサポートしている場合、正常に認証されておらず、ネットワークアクセスを許可されていないリスナから発信され、これらのリスナに向けられたＭＬＲおよびＭＬＱメッセージを除去することが可能である。また、スイッチがＭＬＤスヌープもサポートしている場合には、ＩＰｓｅｃを用いたＭＬＤＡもＭＬＤも利用せずに、リンク層マルチキャストアクセス制御を実行することが可能である。この方法では、マルチキャストリスナは、ＰＡＮＡやＩＥＥＥ８０２．１Ｘなどのネットワークアクセス認証プロトコルを使って、認証され、ネットワークアクセスを許可される。

よって、これら２つの方法は、有利には、セクション２の問題１への解決策を提供することができる。

ＭＬＤまたはＭＬＤＡとは無関係に提供される信号機構を使って、マルチキャストリスナのためのマルチキャストトラフィックフィルタリング情報（例えば、許可されたマルチキャストグループアドレスや許可されたマルチキャストソースアドレスなど）がリンク層スイッチにインストールされ、後続の許可されたマルチキャストトラフィックのリンク層への配信が可能とされる場合、ＭＬＤまたはＭＬＤＡは、マルチキャストリスナとマルチキャストルータの間では使用されなくてもよい。

３．４．ネットワークアクセス認証からのセキュアなマルチキャストアプリケーションセッションのブートストラップ
セクション２で問題５に関して説明したように、完全に共用されているアクセスリンクを介したマルチキャストサービスのただ乗りを回避するには、ＳＲＴＰ（［ＲＦＣ３７１１］参照）など、上位レベルのパケットごとにセキュリティ機構が必要である。このような機構は、アプリケーションデータトラフィックの暗号化を含む。このようなアプリケーション層セキュリティが、大規模な環境で動作するためには、マルチキャストキーを用いたセキュアなアプリケーションセッションのためのセキュリティアソシエーションを自動的に確立する機構が使用されるはずである。いくつかの実施形態では、これをアーカイブする２つの例示的方法があり、これらを以下で詳細に説明する。

第１の方法は、セキュアなアプリケーションセッションのためのセキュリティアソシエーションを確立するのに使用されるマルチキャストキー管理プロトコルのブートストラップに基づくものである。様々な実施形態において、ＧＳＡＫＭＰ（［ＧＳＡＫＭＰ］参照）や、ＭＩＫＥＹ（［ＭＩＫＥＹ］参照）や、ＫＩＮＫ（［ＫＩＮＫ］参照）など、セキュアなマルチキャストアプリケーションセッションのためにセキュリティアソシエーションを確立するのに使用され得るいくつかのキー管理プロトコルがある。加えて、ＳＩＰも、マルチキャストキー管理プロトコルとして使用できる。セクション３．２で説明しているように、マルチキャストキー管理プロトコルでの相互認証にはＭＫＭキーが必要である。この方法は、セクション３．２で説明したのと同じやり方で、ネットワークアクセス認証プロトコルからＭＫＭキーを導出する。

図５１に、第１の方法で、ＳＲＴＰがセキュアなアプリケーション層プロトコルとして使用される場合のマルチキャストアプリケーションセッションキー階層を示す。図５１では、マルチキャストキー管理プロトコルを使ってＳＲＴＰマスタキー（［ＲＦＣ３７１１］参照）が確立され、ネットワークアクセス認証プロトコルからＭＫＭキーが導出される。このキー導出モデルは、ＳＲＴＰのみならず、他のマルチキャストベースのアプリケーション層プロトコルをセキュリティ保護するのにも使用できる。各可能なマルチキャストキー管理プロトコルごとの具体的なＭＫＭキー導出アルゴリズム、および各可能なマルチキャストアプリケーションごとのアプリケーションセッションキー導出アルゴリズムは、本開示に基づき、当分野の技術者によって、適宜、実施できる。

第２の方法は、ＰＡＮＡやＩＥＥＥ８０２．１Ｘなどのネットワークアクセス認証プロトコルを介したアプリケーションセッションキーの搬送に基づくものである。ネットワークアクセス認証としてＰＡＮＡが使用されるとき、ＳＲＴＰマスタキー（［ＲＦＣ３７１１］参照）などのアプリケーションセッションキーは、ＰＡＮＡバインド要求メッセージおよびＰＡＮＡバインド応答メッセージとして暗号化されて搬送されてよい。この場合、アプリケーションセッションキーは、キー配布センタ（ＫＤＣ）によって生成でき、または管理できる。アプリケーションセッションキー配布機構は、本開示に基づき、当分野の技術者によって、適宜、実施できる。

図５２に、第２の方法において、ＳＲＴＰがセキュアなアプリケーション層プロトコルとして使用される場合のマルチキャストアプリケーションセッションキー階層を示す。図５２では、マルチキャストキー管理プロトコルを使ってＳＲＴＰマスタキー（［ＲＦＣ３７１１］参照）が確立され、ネットワークアクセス認証プロトコルからＭＫＭキーが導出される。

いくつかの実施形態では、これら２つの方法は、上記のセクション２で説明している問題５に対する解決策を提供することができ、セクション３．１から３．３で説明している他の方法と一緒に使用されてもよい。

図５６に、第１の方法の機能モデルを示す。ＥＡＰ−Ｓ（ＥＡＰサーバ）は、ＥＡＰ方法のエンドポイントである。ＡＡ（認証エージェント）は、ネットワークアクセス認証プロトコルのオーセンティケータ（例えば、ＩＥＥＥ８０２．１ＸオーセンティケータやＰＡＮＡエージェントなど）である。Ｒはマルチキャストアプリケーション受信者である。Ｓはマルチキャストアプリケーション送信者である。ＫＭＳはキー管理プロトコルサーバである。加えて、ＥＡＰ−Ｓは、ＡＡと同じ物理エンティティに位置していてもよい。さらに、ＫＭＳも、ＡＡ、ＥＡＰ−ＳまたはＳと同じ物理エンティティに位置していてもよい。

図５６では、まず、ＲとＡＡの間でネットワークアクセス認証が行われる。ネットワークアクセス認証は、Ｒを認証するのにＥＡＰを使用し、ここでＡＡは、ＥＡＰ−Ｓと連絡をとり、ＡＡＡプロトコルまたはＡＰＩを介してＡＡＡキーを獲得する。ネットワークアクセス認証が正常に完了すると、ＡＡは、ＡＡＡキーからＭＫＭキーを導出し、ＭＫＭキーをＫＭＳに渡す。次いで、キー管理プロトコルが、ＫＭＳとＲの間で実行される。キー管理プロトコルが一旦アプリケーションセッションキーを生成すると、ＳおよびＲは、アプリケーション層セキュリティ機構で保護されたマルチキャストアプリケーショントラフィックを送受信することができる。

図５７に、第２の方法の機能モデルを示す。ＥＡＰ−Ｓ（ＥＡＰサーバ）は、ＥＡＰ方法のエンドポイントである。ＡＡ（認証エージェント）は、ネットワークアクセス認証プロトコルのオーセンティケータ（例えば、ＩＥＥＥ８０２．１ＸオーセンティケータやＰＡＮＡエージェントなど）である。Ｒはマルチキャストアプリケーション受信者である。Ｓはマルチキャストアプリケーション送信者である。ＫＤＣはキー配布センタである。加えて、ＥＡＰ−Ｓは、ＡＡと同じ物理エンティティに位置していてもよい。また、ＫＤＣも、ＡＡ、ＥＡＰ−ＳまたはＳと同じ物理エンティティに位置していてもよい。

図５７では、まず、ＲとＡＡの間でネットワークアクセス認証が行われる。ネットワークアクセス認証は、Ｒを認証するのにＥＡＰを使用し、ここでＡＡは、ＥＡＰ−Ｓに連絡をとり、ＡＡＡプロトコルまたはＡＰＩを介してＡＡＡキーを獲得する。ネットワークアクセス認証が正常に完了すると、ＡＡは、ＫＤＣからアプリケーションセッションキーのコピーを獲得し、これを、ネットワークアクセス認証プロトコルを介してＲに配信する。Ｓは、ＫＤＣからアプリケーションセッションキーのコピーを獲得してもよい。アプリケーションセッションキーが一旦Ｒに配信されると、ＳおよびＲは、アプリケーション層セキュリティ機構で保護されたマルチキャストアプリケーショントラフィックを送受信することができる。

本発明の広い適用範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明する様々な好ましい実施形態のみに限定されるものではなく、本開示に基づき、当分野の技術者によって理解されるであろう、同等の要素、改変、省略、（様々な実施形態にまたがる態様などの）組み合わせ、適合および／または変更を有する任意の実施形態すべてを含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられている言語に基づいて広く解釈されるべきであり、本明細書において、または本願の出願手続中に示される、非排他的であると解釈されるべきである例のみに限定されるものではない。例えば、本開示において、「好ましくは」という用語は、非排他的ということであり、「好ましくは、しかし、これに限られるものではないが」を意味する。本開示および本願の出願手続中において、手段プラス機能限定またはステッププラス機能限定は、特定の請求項限定について、この限定に、ａ）「〜の手段」または「〜のステップ」が明示的に記載されている、ｂ）対応する機能が明示的に記載されている、そしてｃ）構造、材料またはこの構造を支持する動作が記載されていないという条件すべてが存在する場合に限って用いられる。本開示および本願の出願手続中において、「本発明」または「発明」という用語は、本開示内の１つまたは複数の態様に言及するものとして使用されてよい。本発明または発明という言葉は、重要度を識別するものであると不適切に解釈されるべきではなく、すべての態様または実施形態にまたがって適用されるものであると不適切に解釈されるべきでなく（すなわち、本発明はいくつかの態様と実施形態を有すると理解されるべきであり）、本願または特許請求の範囲を限定するものであると不適切に解釈されるべきではない。本開示および本願の出願手続中において、「実施形態」という用語は、任意の態様、機能、プロセスまたはステップ、これらの任意の組み合わせ、および／またはこれらの任意の部分などを示すのに使用され得る。いくつかの例では、様々な実施形態が、重なり合う機能を含んでいることがある。本開示では、「例えば」を意味する「ｅ．ｇ．」、および「注記」を意味する「ＮＢ」という省略用語が用いられることがある。

一般的なアーキテクチャモデルを示す概略図である。 特に、ネットワークアクセス認証およびＤＨＣＰを示す概略図である。 特に、認証セッションが終了した場合の、サーバの挙動を示す概略図である。 特に、認証セッションが終了した場合の、クライアントの挙動を示す概略図である。 特に、ＡＡＡキー更新方法１：ＤＨＣＰキーが不変のままであることを示す概略図である。 特に、ＡＡＡキー更新方法２：据え置きＤＨＣＰキー更新を示す概略図である。 特に、ＡＡＡキー更新方法３：即時のＤＨＣＰキー更新を示す概略図である。 特に、ＤＨＣＰサーバ再始動方法１：不揮発性記憶を示す概略図である。 特に、ＤＨＣＰサーバ再始動方法２：最初からのリブートを示す概略図である。 特に、ＤＨＣＰサーバ再始動方法３：オーセンティケータへのキーの要求を示す概略図である。 特に、ＤＨＣＰ存続期間満了方法１：現在のＤＨＣＰキーの保持を示す概略図である。 特に、ＤＨＣＰ存続期間満了方法２：再認証の要求を示す概略図である。 特に、考えられるサービス盗用：ＭＡＣおよびＩＰアドレススプーフィングを示す概略図である。 特に、ネットワーク例の概要を示す概略図である。 特に、レコード追加／除去の通知を示す概略図である。 特に、ＵＦＤレコードに関する照会／回答を示す概略図である。 特に、例示的パケットフィルタリング機能を示す概略図である。 特に、ポート識別タグ（ＰＩＴ）機能を用いた例示的転送を示す概略図である。 特に、ＰＩＴを用いたセッション識別を示す概略図である。 特に、ＰＩＴメッセージフォーマットの一例を示す概略図である。 特に、説明例１：ステップ１−Ａを示す概略図である。 特に、説明例１：ステップ２−Ａを示す概略図である。 特に、説明例１：ステップ３−Ａを示す概略図である。 特に、説明例１：ステップ４−Ａを示す概略図である。 特に、説明例１：ステップ５−Ａを示す概略図である。 特に、説明例１：ステップ４−Ｂを示す概略図である。 特に、説明例１：ステップ５−Ｂを示す概略図である。 説明例１：脅威１を示す概略図である。 説明例１：脅威２（ステップ１−Ａから３−Ａおよび４−Ｂ）を示す概略図である。 特に、説明例１：脅威２（ステップ５−Ｂ）を示す概略図である。 説明例１：脅威２：同時攻撃を示す概略図である。 説明例１：脅威３を示す概略図である。 説明例２：ステップ１−Ａを示す概略図である。 説明例２：ステップ２−Ａを示す概略図である。 説明例２：ステップ３−Ａを示す概略図である。 説明例２：ステップ４−Ａを示す概略図である。 説明例２：ステップ５−Ａを示す概略図である。 説明例２：ステップ６−Ａを示す概略図である。 説明例２：ステップ７−Ａを示す概略図である。 説明例２：脅威１および２：ステップ５−Ａにおける複数セッションを示す概略図である。 説明例１および２：ステップ７−Ａにおける複数セッションを示す概略図である。 例示的ＩＰマルチキャストネットワークを示す概略的アーキテクチャ図である。 （Ｓ１，Ｇ）のパケット転送パスの例を示す概略的アーキテクチャ図である。 （Ｓ２，Ｇ）のパケット転送パスの例を示す概略的アーキテクチャ図である。 共用リンクを有する例示的ＩＰマルチキャストネットワークを示す概略的アーキテクチャ図である。 （Ｓ１，Ｇ）のパケット転送パスの例を示す概略的アーキテクチャ図である。 マルチキャストリスナ発見（照会）を示す概略的アーキテクチャ図である。 マルチキャストリスナ発見（報告）を示す概略的アーキテクチャ図である。 ＭＬＤスヌープなしのマルチキャストデータパケット転送を示す概略的アーキテクチャ図である。 ＭＬＤスヌープありのマルチキャストデータパケット転送を示す概略的アーキテクチャ図である。 ＭＬＤＡキー階層を示す概略的アーキテクチャ図である。 ＩＰｓｅｃキー階層を示す概略的アーキテクチャ図である。 第１の方法におけるＳＲＴＰキー階層を示す概略的アーキテクチャ図である。 第２の方法におけるＳＲＴＰキー階層を示す概略的アーキテクチャ図である。 第１の方法におけるＭＬＤＡブートストラップの機能モデルを示す概略的アーキテクチャ図である。 第２の方法におけるＭＬＤＡブートストラップの機能モデルを示す概略的アーキテクチャ図である。 マルチキャストＩＰｓｅｃブートストラップの機能モデルを示す概略的アーキテクチャ図である。 第１の方法におけるセキュアなマルチキャストアプリケーションブートストラップの機能モデルを示す概略的アーキテクチャ図である。 第２の方法におけるセキュアなマルチキャストアプリケーションブートストラップの機能モデルを示す概略的アーキテクチャ図である。

Claims (25)

1. 動的ホスト構成およびネットワークアクセス認証をバインドする方法であって、少なくとも１つのクライアント機器を認証するネットワークアクセスオーセンティケータネットワークノードを設けることと、クライアント機器のＩＰアドレスを動的に配信する動的ホスト構成サーバネットワークノードを設けることと、認証セッションと動的ホスト構成セッションのいずれかが失われたときに、前記少なくとも１つのクライアント機器と前記ネットワークアクセスオーセンティケータネットワークノードの間の認証セッションと、前記動的ホスト構成サーバネットワークノードと前記少なくとも１つのクライアント機器の間の動的ホスト構成セッションとの同期を維持することと、を備え、
   前記方法は前記少なくとも1つのクライアント機器と前記ネットワークアクセスオーセンティケータネットワークノードとの間の認証セッションと前記動的ホスト構成サーバネットワークノードと前記少なくとも1つのクライアント機器との間の前記動的ホスト構成セッションとの同期を前記認証セッション及び前記動的ホスト構成セッションの存続期間にわたり維持することを含む、方法。
2. 動的ホスト構成およびネットワークアクセス認証をバインドするシステムであって、少なくとも１つのクライアント機器を認証するネットワークアクセスオーセンティケータネットワークノードと、クライアント機器のＩＰアドレスを動的に配信するように構成されている動的ホスト構成サーバネットワークノードと、を備え、認証セッションと動的ホスト構成セッションのいずれかが失われたときに同期を維持するようなやり方で、前記少なくとも１つのクライアント機器と前記ネットワークアクセスオーセンティケータネットワークノードの間の認証セッションと、前記動的ホスト構成サーバネットワークノードと前記少なくとも１つのクライアント機器の間の動的ホスト構成セッションとの同期を維持するように構成され、
   前記システムは前記少なくとも1つのクライアント機器と前記ネットワークアクセスオーセンティケータネットワークノードとの間の認証セッションと前記動的ホスト構成サーバネットワークノードと前記少なくとも1つのクライアント機器との間の前記動的ホスト構成セッションとの同期を前記認証セッション及び前記動的ホスト構成セッションの存続期間にわたり維持するように構成される、システム。
3. 前記ネットワークアクセスオーセンティケータは、認証プロトコルを使ってネットワークアクセスのための認証情報を搬送する、請求項２に記載のシステム。
4. 前記認証プロトコルは、ネットワークアクセスのための認証情報を搬送するプロトコルとしてＰＡＮＡを含む、請求項３に記載のシステム。
5. ネットワークアクセスのための認証情報を搬送する前記プロトコルによって搬送される認証プロトコルとしてＥＡＰが使用される、請求項４に記載のシステム。
6. 前記動的ホスト構成サーバは、動的ホスト構成プロトコル（ＤＨＣＰ）サーバである、請求項２に記載のシステム。
7. 前記オーセンティケータは、認証セッションの終了時に、前記動的ホスト構成サーバに前記セッションが終了していることを知らせるメッセージを送信するように構成されている、請求項２に記載のシステム。
8. 前記メッセージは、前記動的ホスト構成サーバに、前記認証セッションから導出された動的ホスト構成キーがもはや有効ではないことを知らせる、請求項７に記載のシステム。
9. 前記システムは、前記動的ホスト構成サーバ内の構成ファイルを更新するように構成されている、請求項７に記載のシステム。
10. 前記システムは、前記動的ホスト構成サーバ内の構成ファイルを書き換え、または再ロードするように構成されている、請求項７に記載のシステム。
11. 前記オーセンティケータは、前記動的ホスト構成サーバに、クライアント構成を削除するよう求める削除要求を送るように構成されている、請求項７に記載のシステム。
12. 前記システムは、認証セッションの終了時に、動的ホスト構成キーをこのままにして、認証セッションを更新するように構成されている、請求項２に記載のシステム。
13. 前記システムは、認証セッションの終了時に、認証セッションキーは更新するが、動的ホスト構成キーは後で更新するように構成されている、請求項２に記載のシステム。
14. 認証セッションの終了時に、前記オーセンティケータとクライアントの間で新しい認証セッションキーが確立されるシステムであり、前記システムは新しい動的ホスト構成キーを使って直ちに前記動的ホスト構成セッションを再始動するように構成されている、請求項２に記載のシステム。
15. 前記システムは、前記動的ホスト構成サーバの再始動時に、不揮発性記憶装置を使って前記動的ホスト構成キーの状態が回復されるように構成されている、請求項２に記載のシステム。
16. 前記動的ホスト構成サーバは、再始動時に、動的ホスト構成キーテーブルおよびバインディングテーブルを不揮発性記憶装置に保存するように構成されている、請求項１５に記載のシステム。
17. 前記システムは、前記動的ホスト構成サーバのリブート時に、前記動的ホスト構成サーバが、前記オーセンティケータに、動的ホスト構成キーが消去されていることを知らせるように構成されるように構成されている、請求項２に記載のシステム。
18. 前記システムは、前記動的ホスト構成サーバのリブート時に、前記オーセンティケータが、動的ホスト構成キーが消去されていることを知るように、前記動的ホスト構成サーバのリブートについて気付かせるように構成されている、請求項２に記載のシステム。
19. 前記システムは、前記動的ホスト構成サーバが、動的ホスト構成キー情報の喪失時に、前記オーセンティケータに、動的ホスト構成キー情報を再送するよう要求し、前記オーセンティケータからの応答に基づいて前記動的ホスト構成キーテーブルを復元するように構成されるように構成されている、請求項２に記載のシステム。
20. 前記動的ホスト構成サーバは、前記動的ホスト構成サーバが始動するときに、前記オーセンティケータに動的ホスト構成キーを再送するよう要求するように構成されている、請求項１９に記載のシステム。
21. 前記オーセンティケータは、前記動的ホスト構成サーバに、すべての有効な動的ホスト構成キーを送るように構成されている、請求項１９に記載のシステム。
22. 前記システムは、動的ホスト構成バインディングの失効時に、クライアントが、前記オーセンティケータに、動的ホスト構成メッセージ交換の前に前記動的ホスト構成キーを再認証し、更新するよう要求するように構成されている、請求項２に記載のシステム。
23. 前記システムは、動的ホスト構成バインディングの失効時に、前記動的ホスト構成サーバが、前記オーセンティケータに、動的ホスト構成メッセージ交換の前に前記動的ホスト構成キーを再認証し、更新するよう要求するように構成されている、請求項２に記載のシステム。
24. 前記システムは、前記オーセンティケータとクライアントの間で新しい動的ホスト構成キーを作成するために認証メッセージが交換されている間に、前記オーセンティケータが、前記動的ホスト構成キーが前記動的ホスト構成サーバにインストールされるまで、新しい認証セッションが正常に確立されていることを指示するメッセージの送信を回避するように構成されるように構成されている、請求項２に記載のシステム。
25. 動的ホスト構成およびネットワークアクセス認証をバインドするシステムであって、少なくとも１つのクライアント機器を認証するネットワークアクセスオーセンティケータネットワークノードと、クライアント機器のＩＰアドレスを動的に配布するように構成されている動的ホスト構成サーバネットワークノードと、を備え、前記動的ホスト構成セッションの初回のブートストラップ後に、前記少なくとも１つのクライアント機器と前記ネットワークアクセスオーセンティケータネットワークノードの間の認証セッションと、前記動的ホスト構成サーバネットワークノードと前記少なくとも１つのクライアント機器の間の動的ホスト構成セッションとの同期を取るように構成され、
    前記システムは前記少なくとも1つのクライアント機器と前記ネットワークアクセスオーセンティケータネットワークノードとの間の認証セッションと前記動的ホスト構成サーバネットワークノードと前記少なくとも1つのクライアント機器との間の前記動的ホスト構成セッションとの同期を前記認証セッション及び前記動的ホスト構成セッションの存続期間にわたり維持するように構成される、システム。

Images