JP2004364315A - 複数のネットワーク・ポリシーを統合するための方法とフレームワーク - Google Patents

Abstract

【課題】 １つのネットワーク・デバイス内で複数ネットワーク・ポリシーを管理し実装するための方法およびシステムを開示する。
【解決手段】 複数のポリシーはそれぞれ、１つまたは複数のフィルタにより定義される。フィルタはポリシー・エンジン内にインストールされる。レイヤは、ポリシー・エンジンに要求を送信することによりパケットに適用されるネットワーク・ポリシーを識別する。ポリシー・エンジンは、次に、そのポリシーを要求レイヤに返す。この方法およびシステムは、複数のプロトコル・レイヤでセキュリティおよびその他のポリシーを適用することができるプログラム可能なホスト・ベースの分散認証ファイヤウォールを実装するために使用することができる。
【選択図】 図１０

Description

本発明は、一般に、コンピュータ・システムおよびネットワーク・セキュリティに関する。より具体的には、本発明は、複数のネットワーク・ポリシー（network policies）をネットワーク・デバイス（network device）内の単一フレームワーク（single framework）に統合する方法に関する。

本発明は、本出願と同日に出願されている特許出願「Multi-Layer Based Method for Implementing Network Firewalls」、「Multi-Layered Firewall Architecture Implemented in a Network Device」、および「Method for Managing Network Filter Based Policy」の対象事項に関係する対象事項を対象とし、それらの開示を参照により本発明に組み込む。

ネットワーク・プロトコルは、オープンなデータ交換を通じてネットワーク・デバイス間の通信を円滑にすることを目的としている。オープンなデータ交換は、作業遂行するためにネットワーク・デバイスの使用を拡大する一方、ネットワーク・プロトコルはネットワーク・セキュリティを考慮した設計にはなっておらず、また一般に、そのような機能も備えていないため、問題を生じさせている。ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、イントラネット、およびインターネットなどのパブリック・ネットワークおよびプライベート・ネットワークの両方に結合されているコンピュータは、ネットワークに直接的にまたは間接的に結合されている他のネットワーク・デバイスからの悪質な攻撃に影響されやすい。このような悪質な攻撃としては、情報窃盗（theft of data）、サービス拒否（ＤＯＳ）攻撃、コンピュータ・ウイルスの拡散、などがある。

ネットワーク・デバイスを悪質な攻撃から守るために、通常は１つまたは複数のネットワーク・ポリシーを使用するさまざまな方法が開発されてきた。ネットワーク・ポリシーの１つに、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ（ＩＰＳｅｃ）Ｓｕｉｔｅにより実現されるようなセキュリティ・ポリシーがある。ＩＰＳｅｃ ｓｕｉｔｅは、カプセル化セキュリティ・プロトコル（Encapsulating Security Protocol：ＥＳＰ）、認証ヘッダ（Authentication Header：ＡＨ）、およびインターネット鍵交換（自動鍵交換とも呼ばれる）および管理（Internet Key Exchange and Management：ＩＫＥ）などのプロトコルを備える。ＥＳＰプロトコルは、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）２４０６として文書化されている、データの完全性、ソース認証、および機密保持を実現する暗号化メカニズムを使用する認証および暗号化プロトコルである。ＡＨプロトコルは、ＩＥＴＦ ＲＦＣ ２４０２に文書化されている、パケット・ヘッダ内でハッシュ署名を使用してパケット・データの完全性および送信者の真正性（authenticity）を確認するための認証プロトコルである。

ＩＫＥプロトコルは、ＩＥＴＦ ＲＦＣ ２４０９に文書化されており、ＡＨおよびＥＳＰ形式とともに使用されるセキュリティ設定をネットワーク・デバイスでネゴシエートするための方法を提供する。ネゴシエートされたセキュリティ設定では、セキュリティ・アソシエーション（ＳＡ）と呼ばれるデータ構造体を形成する。ＳＡでは、認証アルゴリズム、暗号化アルゴリズム、鍵、および鍵の存続期間など、ＩＰパケットの内容を保護するためにＥＳＰまたはＡＨで使用するパラメータを定義する。ＥＳＰおよびＡＨは確立されたＳＡを必要とするため、ＥＳＰまたはＡＨプロトコルを使用してデータを送信する前にＩＫＥネゴシエーションが実行される。

ネットワーク・デバイスは、ＩＰＳｅｃ、例えば、ＩＫＥ、ＡＨ、またはＥＳＰ、処理の対象となるパケット、およびそのようなパケットをセキュリティ・ポリシー・データベース（ＳＰＤ）内で維持されるセキュリティ・ポリシーに基づいてＩＰＳｅｃ処理する方法を識別する。セキュリティ・ポリシーは、ＩＰＳｅｃの使用法を定義する、ネットワーク・デバイスに割り当てられる、一組のルールである。セキュリティ・ポリシーは、フィルタ・リスト、認証方法、およびその他の情報を含む。パケットに適用すべき適切なセキュリティ・ポリシーは、通常、パケットの送信元および送信先ＩＰアドレス、送信元および送信先ポート、およびプロトコル・タイプに基づいて決定される。

悪質な攻撃から防護するために使用される他のネットワーク・ポリシーとしては、ファイヤウォール・ポリシーがある。ファイヤウォール・ポリシーは、１つまたは複数のフィルタにより実装される。それぞれのフィルタは、フィルタ・パラメータにマッチするパケットに適用すべきフィルタ・パラメータおよび関連するポリシーを含む。フィルタ・パラメータは、ハードウェアのアドレス、例えば、メディア・アクセス制御（ＭＡＣ）アドレス、ネットワーク・アドレス、例えば、ＩＰアドレス、プロトコル・タイプ、例えば、トランスポート制御プロトコル（ＴＣＰ）、ポート番号などの情報を含む。フィルタ内のファイヤウォール・ポリシーにより、フィルタ・パラメータにマッチするパラメータを含むパケットをどのように処理するかを識別する。具体的な例をあげると、フィルタはパラメータとしてＵＲＬ（Uniform Resource Locator）アドレス、例えば「ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ」を含む。フィルタ・ポリシーにより、そのＵＲＬアドレスを含むパケットを削除することを指示する。ネットワーク・デバイスは、パケットを調査し、その調査の結果、ＵＲＬアドレス「ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ」をパケットに埋め込まれていると認識した場合、パケットを削除し、そうすることでそのパケットがネットワークをトラバースしないようにする。

また、ネットワーク・デバイスでは、セキュリティに関係しないポリシーを使用してネットワーク・トラフィックの流れを制御する。一例として、ネットワーク・デバイスでは、サービスの品質（ＱＯＳ）ベースのポリシーを実装する。ＱＯＳは、伝送速度、エラー率、およびその他の特性を測定し、これらを改善し、そしてこれらがある程度まであらかじめ保証されるという事実に対応するものである。パケットは、ポリシーおよび予約基準（reservation criteria）に基づき最優先で処理することができる。例えば、ＱＯＳは、ネットワーク帯域幅を割り当てて、ネットワーク・デバイス間の通信を改善するために使用される。

複数のポリシー、例えば、セキュリティ・ポリシー、ファイヤウォール・ポリシー、ＱＯＳポリシー、およびネットワーク・デバイスに実装するべき類似のものは、珍しいものではない。これらの複数のポリシーは、コンフリクト（conflict）する、つまり、同じパケットに矛盾した複数のアクションを採用すること、を認めてしまう。複数のネットワーク・ポリシーを１つのネットワーク・デバイス内に実装する場合も、パケット伝送問題の診断が困難になる。例えば、パケットが適切に送信されない場合、または受信されない場合、パケットを妨害しているネットワーク・ポリシーがどれであるかを識別することは困難である。

本発明は、１つのネットワーク・デバイス内に複数のネットワーク・ポリシーを実装する方法およびフレームワークを対象とする。複数のネットワーク・ポリシーは、ポリシー・エンジンにインストールされている一組のフィルタにより定義される。各フィルタは、一組のフィルタ条件、１つのアクション、および１つのポリシー・コンテキスト（policy context）を含む。フィルタ条件には、パケットにマッチする１つまたは複数のフィルタをポリシー・エンジンが識別することを可能にするパラメータが含まれる。アクションおよびポリシー・コンテキストは、フィルタ条件にマッチ（一致）するパケットに適用するネットワーク・ポリシーを識別（特定）する。

要求レイヤ（requesting layer）は、パケットに関連する一組のパラメータとともに要求をポリシー・エンジンに送信する。ポリシー・エンジンは、パケットに関連付けられているパラメータをフィルタ条件と比較することにより、そのパケットの１つまたは複数のマッチするフィルタ（matching filters）を識別する。その後、マッチするフィルタ内のポリシー・コンテキストとアクションから、ネットワーク・ポリシーが識別される。ネットワーク・ポリシーは、識別された後、ネットワーク・デバイスにより実行される。

本発明の一実施形態では、複数のネットワーク・ポリシーのうちの１つは、アクションとして一組のフィルタ内にｐｅｒｍｉｔ（許可）またはｂｌｏｃｋ（遮断）を記述するという形で実装されるファイヤウォール・ポリシーであり、それにより、フィルタ条件にマッチするパケットがネットワーク・スタック内のレイヤをトラバース（移動）するのを許可するか、またはその逆にそれ以上ネットワーク内をトラバースしないようにブロック（遮断）するかを識別することができる。

本発明の一実施形態では、複数のポリシーのうちの１つは、ポリシー・コンテキストとして、フィルタ条件にマッチするパケットに適用するセキュリティ・ポリシーを識別するデータを記述するセキュリティ・ポリシーである。

本発明の一実施形態では、複数のポリシーのうちの１つは、ポリシー・コンテキストとして、フィルタ条件にマッチするパケットに適用する通信設定を識別するデータを記述するサービスの品質（ＱＯＳ）ポリシーである。

本発明の方法およびフレームワークは、複数のプロトコル・レイヤでセキュリティおよびその他のポリシーを適用することができる、プログラム可能な、ホスト・ベースの、分散認証ファイヤウォールを実装するために使用することができる。本発明の他の特徴および利点は、添付図を参照して進められている説明目的の実施形態の以下の詳細な説明から明白であろう。

請求の範囲で本発明の特徴を詳細に述べているが、本発明は、その目的および利点とともに、添付図面に関する以下の詳細な説明から最もよく理解できると思われる。

ネットワーク・デバイス内に複数のフィルタ・ベースのネットワーク・ポリシーを実装し管理する方法およびフレームワークについて説明する。代表的なフィルタ・ベースのネットワーク・ポリシーとして、セキュリティ・ポリシー、ファイヤウォール・ポリシー、およびＱＯＳポリシーがある。１つのフィルタ・ポリシー・エンジンに、複数のフィルタ・ペースのネットワーク・ポリシーが格納される。

フィルタ・ベースのポリシーは、ユーザ・ポリシー・エンジンおよびカーネル・ポリシー・エンジンを含むフレームワーク内に実装される。フレームワークはさらに、カーネル・レイヤおよびユーザ・レイヤを含む。カーネル・ポリシー・エンジン、カーネル・レイヤ、および１つまたは複数のコールアウトは、オペレーティング・システムのカーネル・モードで実行される。カーネル・レイヤは、アプリケーション・レイヤ、トランスポート・レイヤ、ネットワーク・レイヤ、およびリンク・レイヤを含み、ネットワーク・スタックを形成する。ユーザ・ポリシー・エンジンおよびユーザ・モード・レイヤは、オペレーティング・システムのユーザ・モードで、１つまたは複数のポリシー・プロバイダとともに実行される。ユーザ・レイヤの一例として、セキュリティ・ポリシーを識別するために使用されるキーイング・モジュール・レイヤ（keying module layer）がある。それとは別に、本発明の方法およびフレームワークは、単一のオペレーティング・システム・モード内で、またはオペレーティング・システムの外部で実行される１つまたは複数のプログラム・モジュールあるいはアプリケーション内で、実行される。

ユーザ・レイヤおよびカーネル・レイヤはそれぞれ、前のレイヤまたはシステム・プロセスからパケットおよび対応するパケット・コンテキスト・データを受け取る要求レイヤを形成する。要求レイヤは、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を介してカーネル・ポリシー・エンジンまたはユーザ・ポリシー・エンジンに要求を送信する。この要求は、要求レイヤによって受信されたパケット、パケット・コンテキスト、および要求レイヤに関連付けられている一組のレイヤ・パラメータなどの情報、を含む。ポリシー・エンジンは、要求を処理し、アクションおよびポリシー・コンテキストを返す。その後、このレイヤでは、アクションおよびポリシー・コンテキストに従ってネットワーク・ポリシーを実装する。

複数のネットワーク・ポリシーは、一組のインストール済みのフィルタにより定義される。一組のインストール済みのフィルタは、それぞれ、一組のフィルタ条件、１つのアクション、およびポリシー・コンテキストを含む。アクションは、ｐｅｒｍｉｔ（許可）またはｂｌｏｃｋ（遮断）などのファイヤウォール・ポリシーを返すために使用される。ポリシー・コンテキストは、セキュリティまたはＱＯＳポリシーなどの他のポリシーを含む。カーネルまたはユーザ・ポリシー・エンジンは、１つまたは複数のマッチするフィルタを識別することにより、要求レイヤから送信された要求を処理する。マッチするフィルタは、レイヤ・パラメータおよびパケット・コンテキストにマッチするフィルタ条件を備える。

ポリシー・プロバイダが使用され、揮発性または不揮発性メモリなどの任意の適当なソースから、またはグラフィカル・ユーザ・インターフェースを通じて、ネットワーク・ポリシーを作成し、ポリシーを取り出す。ポリシーは、一組のフィルタ条件、アクション、およびポリシー・コンテキストを含む、新しいフィルタを作成するための情報源である。ユーザ・ポリシー・エンジンは、新しいフィルタをユーザ・ポリシー・エンジンまたはカーネル・ポリシー・エンジン内の一組のインストール済みフィルタに追加する。

同様の参照番号は同様の要素を指している図面を参照すると、適切なコンピューティング環境に実装されているものとして、本発明が説明されている。必ずそうしなければならないというわけではないが、パーソナル・コンピュータによって実行されるプログラム・モジュールなどのコンピュータ実行可能命令の一般的状況において本発明を説明する。一般に、プログラム・モジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラム・モジュールは、ローカルおよびリモートのメモリ記憶デバイスに置くことができる。

図１は、本発明を実施するのに適しているコンピューティング・システム環境１００の一実施例の図である。コンピューティング・システム環境１００は、適当なコンピューティング環境の一例にすぎず、本発明の用途または機能性の範囲に関する制限を示唆する意図はない。コンピューティング環境１００は、オペレーティング環境例１００に示されている１つのコンポーネントまたはその組合せに関係する依存関係または要求条件がコンピューティング環境１００にあるものと解釈すべきでない。

本発明は、他の数多くの汎用または専用コンピューティング・システム環境または構成で動作する。本発明とともに使用するのに適していると思われるよく知られているコンピューティング・システム、環境、および／または構成の例として、パーソナル・コンピュータ、サーバ・コンピュータ、携帯型またはラップトップ・デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースのシステム、セットトップボックス、プログラム可能な家電製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、上記システムまたはデバイスを含む分散コンピューティング環境などがあるが、これらに限定されるものではない。

本発明は、コンピュータによって実行される、プログラム・モジュールなどのコンピュータ実行可能命令の一般的状況において説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスによりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラム・モジュールをメモリ記憶デバイスを含むローカルとリモートの両方のコンピュータ記憶媒体内に配置することができる。

図１を参照すると、本発明を実装するシステム例は、コンピュータ１１０の形態をとる汎用コンピューティング・デバイスを備える。コンピュータ１１０が備えるコンポーネントとしては、処理ユニット１２０、システム・メモリ１３０、およびシステム・メモリを備えるさまざまなシステム・コンポーネントを処理ユニット１２０に結合するシステム・バス１２１などがあるが、これらに限定されるものではない。システム・バス１２１は、メモリバスまたはメモリ・コントローラ、周辺機器バス、および各種バス・アーキテクチャを使用するローカル・バスを含む数種類のバス構造のどれでもよい。例えば、このようなアーキテクチャとしては、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｅ（ＶＥＳＡ）ローカル・バス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがあるが、これらに限定されるものではない。

コンピュータ１１０は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読可能媒体は、コンピュータ１１０によってアクセスできる媒体であればどのような媒体でも使用でき、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体を含む。例えば、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラム・モジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含むが、これらに限定されるものではない。コンピュータ記憶媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または目的の情報を格納するために使用することができ、コンピュータ１１０によりアクセスできるその他の媒体があるが、これらに限定されるものではない。通信媒体は、通常、コンピュータ可読命令、データ構造体、プログラム・モジュール、または搬送波またはその他のトランスポート・メカニズムなどの変調データ信号によるその他のデータを実現し、さらに情報配信媒体を含む。「変調データ信号」という用語は、信号内の情報を符号化する方法によりその特性のうち１つまたは複数が設定または変更された信号を意味する。例えば、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体があるが、これらに限定されるものではない。上記のいずれの組合せもコンピュータ可読媒体の範囲に収まらなければならない。

システム・メモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１およびランダム・アクセス・メモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動時などにコンピュータ１１０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は通常、ＲＯＭ １３１内に格納される。通常、ＲＡＭ １３２には、処理ユニット１２０に直接アクセス可能な、かつ／または処理ユニット１２０により現在操作されているデータおよび／またはプログラム・モジュールを格納する。例えば、図１は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７を示しているが、これらに限定されるものではない。

コンピュータ１１０はさらに、その他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。あくまでも例として、図１は、取り外し不可能な不揮発性磁気媒体の読み出しまたは書き込みを行うハードディスク・ドライブ１４１、取り外し可能な不揮発性磁気ディスク１５２の読み出しまたは書き込みを行う磁気ディスク・ドライブ１５１、およびＣＤ ＲＯＭまたはその他の光媒体などの取り外し可能な不揮発性光ディスク１５６の読み出しまたは書き込みを行う光ディスク・ドライブ１５５を示している。オペレーティング環境例で使用できる他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体としては、磁気テープ・カセット、フラッシュ・メモリ・カード、デジタル多目的ディスク、デジタル・ビデオ・テープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがあるが、これらに限定されるものではない。ハードディスク・ドライブ１４１は、通常、インターフェース１４０などの取り外し不可能なメモリ・インターフェースを介してシステム・バス１２１に接続され、磁気ディスク・ドライブ１５１および光ディスク・ドライブ１５５は、通常、インターフェース１５０などの取り外し可能なメモリ・インターフェースによりシステム・バス１２１に接続される。

図１に示されている上記のドライブおよび関連コンピュータ記憶媒体は、コンピュータ１１０用のコンピュータ可読命令、データ構造体、プログラム・モジュール、およびその他のデータを格納する機能を備える。例えば、図１では、ハードディスク・ドライブ１４１は、オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７を格納するものとして示されている。これらのコンポーネントは、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７と同じである場合もあれば異なる場合もあることに注意されたい。オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７に対しては、ここで、異なる番号を割り当てて、最低でも、それが異なるコピーであることを示している。ユーザは、キーボード１６２、およびマウス、トラック・ボール、またはタッチ・パッドと一般に呼ばれるポインティング・デバイス１６１などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力できる。他の入力デバイス（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスやその他の入力デバイスは、システム・バスに結合されているユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されることが多いが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）などの他のインターフェースおよびバス構造により接続することもできる。モニタ１９１またはその他の種類の表示デバイスも、ビデオ・インターフェース１９０などのインターフェースを介してシステム・バス１２１に接続される。モニタのほかに、コンピュータはさらにスピーカ１９７およびプリンタ１９６などの他の周辺出力デバイスも備えることができ、これらは出力周辺インターフェース１９５を介して接続することができる。

コンピュータ１１０は、リモート・コンピュータ１８０などの１つまたは複数のリモート・コンピュータへの論理接続を使用してネットワーク環境で動作することも可能である。リモート・コンピュータ１８０は、他のパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他の共通ネットワーク・ノードでもよく、通常は、パーソナル・コンピュータ１１０に関係する上述の要素の多くまたはすべてを含むが、メモリ記憶デバイス１８１だけを図１に示してある。図１に示されている論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）１７１とワイド・エリア・ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータ・ネットワーク、イントラネット、およびインターネットでは一般的なものである。

ＬＡＮネットワーキング環境で使用する場合は、パーソナル・コンピュータ１１０はネットワーク・インターフェースまたはアダプタ１７０を介してＬＡＮ １７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は通常、モデム１７２またはインターネットなどのＷＡＮ １７３上で通信を確立するための他の手段を備える。モデム１７２は、内蔵でも外付けでもよいが、ユーザ入力インターフェース１６０またはその他の適切なメカニズムを介してシステム・バス１２１に接続できる。ネットワーク環境では、パーソナル・コンピュータ１１０またはその一部に関して述べたプログラム・モジュールは、リモートメモリ記憶デバイスに格納できる。例えば、図１には、リモート・アプリケーション・プログラム１８５がメモリ・デバイス１８１に置かれているように示されているが、これらに限定されるものではない。図に示されているネットワーク接続は例であり、コンピュータ間に通信リンクを確立するための他の手段を使用できることは理解されるであろう。

以下の説明では、特に断りのない限り、１つまたは複数のコンピュータにより実行される活動（acts）および動作の記号的表現を参照しながら、本発明を説明する。したがって、そのような活動（acts）および動作（operation）は、ときにはコンピュータ実行と呼ばれることもあるが、構造化された形式でデータを表現する電気的信号についての、コンピュータの処理装置による、操作（manipulation）を含むことは理解されるであろう。この操作は、データを変換したり、あるいはデータをコンピュータのメモリ・システム内の複数のロケーションに保持したりして、当業者であればよく理解している方法で、コンピュータの動作を、再構成したり、さもなければ他の何らかの形で変更したりする。データが保持されているデータ構造は、データの形式により定められた特定の特性を備えるメモリの物理的な場所である。しかし、本発明は前記のコンテキストで説明されているが、制限する意図はなく、当業者にとっては以下で説明する各種の活動（acts）および動作（operation）がハードウェアで実装できることは周知のことであろう。

ネットワーク環境が、そこにおいて、本発明に従って複数のフィルタ・ベースのネットワーク・ポリシーを実装し管理する方法が、図２を参照して説明することにする。本発明の方法は任意のネットワーク構成に結合されている任意のネットワーク・デバイスに実装されるので、ネットワークは本質的に例である。ネットワーク環境には、プライベート・ネットワーク２００およびパブリック・ネットワーク２０２が含まれる。プライベート・ネットワーク２００およびパブリック・ネットワーク２０２は、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、イントラネット、インターネット、またはそれらの任意の組合せなど適当な種類のものである。

ネットワーク環境は、複数のネットワーク・デバイス２０４、２０６、２０８、２１０、および２１２を備える。ネットワーク・デバイス２０４、２０６は、プライベート・ネットワーク２００に結合される。ネットワーク・デバイス２１０、２１２は、パブリック・ネットワーク２０２に結合される。ネットワーク・デバイス２０８は、プライベート・ネットワーク２００およびパブリック・ネットワーク２０２の両方に結合され、それらの間のインターフェースとなる。ネットワーク・デバイスは、Ｅｔｈｅｒｎｅｔ（登録商標）、１３９４、または８０２．１１（ｂ）などの適当な技術を使用するパブリック・ネットワークおよびプライベート・ネットワークに結合される。ネットワーク・デバイスは、さらに、パーソナル・コンピュータ、サーバ、携帯型デバイス、プリンタ、スイッチ、ルータ、ブリッジ、リピータなどの適当なコンピューティング・デバイスとして実装される。

ネットワーク・デバイス２０８は、フィルタ管理モジュール２１４および１つまたは複数のフィルタ２１６を備える。管理モジュール２１４は、本発明に従って実装される、１つのプログラム・モジュールまたは一組のプログラム・モジュールである。管理モジュール２１４は、プライベート・ネットワーク２００に結合されているネットワーク・デバイス２０４、２０６、２０８とパブリック・ネットワーク２０２に結合されているネットワーク・デバイス２１０、２１２との間でやり取りされるネットワーク・パケットを検査する。本発明の一実施形態では、管理モジュール２１４はさらに、プライベート・ネットワーク２００内のネットワーク・デバイスから送信される、またそのネットワーク・デバイスを送信先とする、場所的に予定されたネットワーク・パケットも調べる。

管理モジュール２１４は、プライベート・ネットワーク２００とパブリック・ネットワーク２０２との間でやり取りされるネットワーク・トラフィックを制御する。それとは別に、管理モジュール２１４は、ネットワーク・デバイス２１０で例示されているような単一ネットワーク・デバイス内に実装し、そのネットワーク・トラフィックを制御する。管理モジュールは、さらに、中央集中管理されている一組のホストおよび／またはエッジ・ネットワーク・デバイスとして実装することもできる。

フィルタ２１６は、管理モジュール２１４の一部として実装される。それとは別に、フィルタ２１６は、管理モジュール２１４によりアクセス可能な別のデータ構造体の一部として実装される。各フィルタ２１６は、一組のフィルタ条件、１つのアクション、およびポリシー・コンテキストを含む。フィルタ条件は、ネットワーク・ポリシーが適用されるデータを識別するために使用され、インターフェース番号、ハードウェア・アドレス、ネットワーク・アドレス、プロトコル・タイプ、ポート番号、およびペイロード・データなどの情報を含む。アクションは、ファイヤウォール・ポリシーを実装するために使用され、管理モジュールを実装するネットワーク・デバイスで、フィルタ条件にマッチするパケットを処理する方法を指示する。通常のアクションとしては、パケットがネットワークのトラバースを続けることを許すｐｅｒｍｉｔと、パケットを削除することによりそれ以上ネットワークのトラバースが行われないように禁止するｂｌｏｃｋとがある。そのポリシー・コンテキストを使用して、セキュリティおよびＱＯＳポリシーなどの他のネットワーク・ポリシーを識別する情報を格納するが、これらのポリシーは、フィルタ条件にマッチするパケットに、同様に適用される。

本明細書で使用しているように、ネットワーク・パケット、または単にパケットという用語は、データを指している。データは、ＩＰ、ＴＣＰ、ＨＴＴＰなどのネットワーク・プロトコルによってフォーマットされたり、または基本データ・ストリームを含んだりすることができる。管理モジュールでは、本明細書でパケット・パラメータと呼ぶパケット情報をフィルタ条件と比較することにより、１つまたは複数のマッチするフィルタを識別する。フィルタ条件がパケット・パラメータにマッチする場合にマッチするフィルタが得られる。パケット・パラメータには、パケットから導出された情報が含まれ、またパケット・コンテキスト情報およびレイヤ・パラメータが含まれる。管理モジュールがマッチするフィルタを識別すると、フィルタ条件に関連付けられている１つまたは複数のアクションおよび／またはポリシー・コンテキストが実行される。

図３は、管理モジュール２１４のアーキテクチャの例を示している。管理モジュール２１４のアーキテクチャにより、カーネル・レイヤとユーザ・レイヤの両方でパケットにフィルタを適用することができる。このアーキテクチャは、フィルタの追加および削除、さらにフィルタの衝突の識別および解消を行うための中央管理機能を備える。管理モジュール２１４は、カーネルまたはユーザ・モード・レイヤの追加および削除を必要に応じて行い、コールアウト・モジュールを介して専用機能を内蔵するように拡張されるという点で拡張性がある。本発明は、特に、ファイヤウォール、サービスの品質（ＱＯＳ）、Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ （ＩＰＳｅｃ） ｓｕｉｔｅだけでなく、他の暗号化、認証、および鍵管理セキュリティ・プロトコルなどの複数のネットワーク・ポリシーとともに使用されるフィルタを実装し管理するのに好適である。

管理モジュール２１４は、ユーザ・モード・プロセス２５０およびカーネル・モード・プロセス２５２を含む。ユーザ・モード・プロセス２５０およびカーネル・モード・プロセス２５２は、ネットワーク・デバイス内のオペレーティング・システムの一部として実行される。当業者であれば、オペレーティング・システムのユーザ・モード・プロセス２５０およびカーネル・モード・プロセス２５２は、簡略化のため図に示されていない追加コンポーネントを含むことを理解するであろう。それとは別に、管理モジュール２１４は、１つまたは複数のプログラム・モジュールまたはアプリケーション・プログラムとして、オペレーティング・システムの外部で全部または一部実行される。

カーネル・モード・プロセス２５２は、カーネル・レイヤ２５４、カーネル・ポリシー・エンジン２５６、およびオプションのコールアウト２５８を含む。カーネル・モード・プロセス２５２は、ネットワーク・パケットにマッチするフィルタを識別し、知られているプロトコルに従ってパケットを処理し、マッチするフィルタで示されているようにパケットに対し他のアクションを実行することにより、定められているネットワーク・ポリシーを実装する。

本発明の一実施形態では、カーネル・レイヤ２５４は、ネットワーク・スタックを形成する。ネットワーク・スタックは、データ・ストリーム・レイヤ２６８、トランスポート・レイヤ２７０、ネットワーク・レイヤ２７２、およびリンク・レイヤ２７４を含む複数のレイヤからなる。管理モジュールは拡張性があり、必要に応じて、追加レイヤの動的追加および削除が行われる。追加レイヤの一例として、Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ（ＳＭＢ）プロトコルに従って実装されるファイル・アクセス・レイヤ２７６がある。カーネル・モード・プロセス２５２は、カーネル・レイヤ２５４をトラバースするパケットに適用するファイヤウォール・ポリシーを実装するように構成するのが好ましい。

カーネル・ポリシー・エンジン２５６は、レイヤＡＰＩ２８０、一組のインストールされているフィルタ２８２、およびコールアウトＡＰＩ２８４を含む。カーネル・ポリシー・エンジン２５６は、（１）ネットワーク・ポリシー、例えば、セキュリティ、ＱＯＳ、ファイヤウォール・ポリシーなどを定義する一組のインストールされているフィルタ２８２を維持すること、（２）カーネル・レイヤ２５４から要求を受け取ること、（３）その要求に基づいて１つまたは複数のマッチするフィルタを識別すること、および（４）レイヤに対して、そこで定義されているマッチするフィルタおよびネットワーク・ポリシーに基づき、パケットに採用されるアクションを指令すること、を含む本発明の方法によるさまざまな機能を実行する。

ユーザ・ポリシー・エンジン２６０は、フィルタ・モジュール２９４を含む。フィルタ・モジュール２９４は、ユーザ・モード２５０でのカーネル・ポリシー・エンジン２５６のインスタンスである。ユーザ・ポリシー・エンジン２６０内のフィルタ・モジュール２９４のインスタンスにより、ユーザ・ポリシー・エンジン２６０はカーネル・ポリシー・エンジン２５６のサービスを１つまたは複数のユーザ・レイヤ２９２に対して複製することができる。ユーザ・レイヤ２９２は、カーネル・モード・レイヤを作成するのと同じ方法で追加される。フィルタ・モジュール２９４はカーネル・ポリシー・エンジン２５６のユーザ・モードのインスタンスであるため、カーネル・ポリシー・エンジンについて本明細書で説明している機能はフィルタ・モジュール２９４にも適用されることが理解されるであろう。例えば、追加ユーザ・モード・レイヤをシステム・アーキテクチャに追加したり、削除したりし、コールアウトを作成してユーザ・モード・レイヤに機能を付加することが可能である。ネットワーク・ポリシーを定義するフィルタ２７８は、フィルタ・モジュール２９４に追加され、ユーザ・モード・レイヤ２９２は、ユーザ・ポリシー・エンジン２６０に要求を送信することにより、指定されたパラメータにマッチするパケットまたはデータに対するポリシーを識別することができる。ユーザ・レイヤ２９２はオペレーティング・システムのユーザ・モードで実行されているように示されているが、ユーザ・レイヤは、他のシステム・プロセスに分散させることもできる。

一組のインストールされているフィルタ２７８、２８２を使用して、１つまたは複数のネットワーク・ポリシーを実装する。各フィルタは、一組のフィルタ条件、１つのアクション、およびポリシー・コンテキストを含む。図２を参照して説明しているように、フィルタ条件により、アクションおよびポリシー・コンテキストで定義されているようなフィルタ・ポリシーの対象となるパケットが識別される。一組のインストールされているフィルタ２８２で規定されているアクションには、ｐｅｒｍｉｔとｂｌｏｃｋが含まれる。ポリシー・コンテキストは、セキュリティおよびＱＯＳなどのポリシーに対する知られているポリシー・パラメータを格納するために使用される適当なデータ構造体である。フィルタの例示的な形態については、図４を参照して説明する。

レイヤＡＰＩ２８０は、カーネル・レイヤとカーネル・ポリシー・エンジンとの間のインターフェースを提供する。要求レイヤは、レイヤＡＰＩ２８０を通じて、パケットに適用されるネットワーク・ポリシーを識別する要求をカーネル・ポリシー・エンジンに送る。

コールアウト２５８を使用して、親コントロール（parental controls）、侵入検出（intrusion detection）などの付加機能を実装する。コールアウトは、カーネル・ポリシー・エンジン２５６が、関連付けられたアクションとして、コールアウト・モジュールの１つへのコールアウトを含む、パケットにマッチする、フィルタを識別する場合に実行される。レイヤのように、追加コールアウトは必要に応じて付加されるため、拡張性の高いアーキテクチャが実現される。コールアウトＡＰＩ２８４の具体的実装については、図６を参照して説明する。

ユーザ・モード・プロセス２５０は、ユーザ・ポリシー・エンジン２６０、および「ＰＰ１」、「ＰＰ２」、および「ＰＰ３」として識別されている１つまたは複数のポリシー２６２を含む。ポリシー・プロバイダ２６２は、ネットワーク・ポリシー、つまり、インストールされたフィルタ２７８、２８２を管理モジュール２１４に追加するプロセスである。任意のプロセスを使って、この作業を実行する。一例として、レガシＩＰＳｅｃポリシー・サービス（ＬＩＰＳ）をあげる。レガシＩＰＳｅｃポリシー・サービスは、カプセル化セキュリティ・プロトコル（ＥＳＰ）および認証ヘッダ・プロトコル（ＡＨ）などのインターネット・プロトコル・セキュリティ（ＩＰＳｅｃ）を使用することが想定されているネットワーク・トラフィックを定義するフィルタを追加する。具体例として、レガシＩＰＳｅｃポリシー・サービスでは、非送信請求の到着パケット（unsolicited inbound packet）はＥＳＰプロトコルに従って暗号化されなければならないことを指示するファイヤウォール・ポリシーを追加する。ポリシーはさらに、クリア・テキスト（平文）の非送信請求の到着パケット、つまり、非暗号化パケットをブロックするよう規定する。ポリシー・プロバイダ２６２は、揮発性または不揮発性メモリ内のデータなどの適当なソースから、または管理者あるいはシステム・ユーザが直接ポリシーを入力するためのグラフィカル・ユーザ・インターフェース（ＧＵＩ）から、ポリシーを取得する。ユーザ・ポリシー・エンジン２６０は、そのポリシーを新しいフィルタに変換し、つまり、ポリシーをフィルタ条件および関連するアクションに関して定義し、その新しいフィルタを一組のインストールされているフィルタ２７８、２８２に追加する。

管理モジュール２１４は、さらに、ユーザ・ポリシー・エンジン２６０とカーネル・ポリシー・エンジン２５６との間のインターフェースを形成するフィルタ・エンジンＡＰＩ２６６を含む。エンジンＡＰＩ２６６は、ユーザ・ポリシー・エンジン２６０が、新しいフィルタを一組のインストールされているフィルタ２８２に追加するための、および診断目的のために選択された基準にマッチするインストールされているフィルタ２８２を調べるための、メカニズムを備える。管理ＡＰＩ２９０は、ポリシー・プロバイダ２６２からアクセス可能であり、またアーキテクチャにフィルタを追加したり、アーキテクチャからフィルタを削除したりするメカニズムも備える。

各ユーザおよびカーネル・レイヤは、前のレイヤ、モジュール、またはシステム・プロセスからパケットを受け取ることができる。各ユーザまたはカーネル・レイヤはさらに、パケット・コンテキストを保持し、パケット・コンテキストを次のレイヤまたはシステム・プロセスに渡し、分類要求（classification request）をカーネルまたはユーザ・ポリシー・エンジンに発行し、１つまたは複数のネットワーク・ポリシーに従ってパケットに対しアクションを実行する。

パケット・コンテキストは、パケットに付随するデータ構造体である。各レイヤは、コンテキスト・データ構造体に、設計上レイヤが処理するようになっている、あるいはパケットから導出することができる、一組のパラメータを加えるという形でコンテキストを保持する。パケット・コンテキストに使用されるデータ構造の例については、図５を参照して説明する。

分類要求は、パケットにマッチするフィルタを識別し、アクション、例えば、ｐｅｒｍｉｔまたはｂｌｏｃｋ、および／または関連するポリシー・コンテキストをレイヤに返すことを要求するレイヤによる呼び出し（call）である。分類要求を発行するレイヤは、本明細書では、要求レイヤと呼ばれる。各レイヤはさらに、カーネルまたはユーザ・ポリシー・エンジンにより返されるパケットに対しアクションを実行する。

また、管理モジュール２１４は、キーイング・モジュール・レイヤ２９６を含む。キーイング・モジュール・レイヤは、ＩＰＳｅｃなどのセキュリティ・プロトコルの一部として実装されるインターネット鍵交換（ＩＫＥ）プロトコルなどのキーイング・プロトコルとともに使用されるネットワーク・ポリシーの検索に使用される。キーイング・モジュールＡＰＩ２８８は、ユーザ・ポリシー・エンジン２６０とキーイング・モジュール・レイヤとの間のインターフェースを提供する。フィルタをフィルタ・モジュール２９４に追加することができるが、そのために、与えられた一組のセキュリティ・パラメータの対象となるパケットを定義するユーザ・ポリシー・エンジン２６０を使用する。キーイング・モジュールＡＰＩは、適用すべきポリシーを識別するポリシー・コンテキストを含むマッチするインストールされているフィルタを識別するため、他のプロセスがキーイング・モジュール・レイヤのサービスを呼び出すためのメカニズムを備えている。

次に、図４を参照して、フィルタ・モジュール２９４またはカーネル・ポリシー・プロバイダ２５６にインストールすることができる、一組のインストールされているフィルタ２８２を説明する。各フィルタ３１０は、フィルタＩＤ３１２、重み３１４、１つまたは複数のアクション３１６、ポリシー・コンテキスト３１７、および一組のフィルタ条件３１８を含む複数のフィールドが設定されている。フィルタＩＤ３１２により、フィルタを一意に識別できる。

重みフィールド３１４は、フィルタ３１０の優先度を識別する値が格納される。重みフィールド３１４の中の値が高いほど、フィルタの優先度は高くなる。フィルタ優先度により、カーネル・ポリシー・エンジン２５６またはユーザ・ポリシー・エンジンによりマッチするフィルタをパケットに割り当てる順序が決定される。あるいは、フィルタ３１０の順序を手動で決定し、重みフィールド３１４を除外することを選択することもできる。

一組のフィルタ条件３１８により、パケットがフィルタ３１０にマッチするかどうかが決定される。各フィルタ条件３１８には、データ型（type）３２０、データ３２２、およびレイヤＩｄ：フィールドＩｄ ３２４が含まれる。フィルタ条件３１８の個数は、動的に構成することが可能であり、フィルタにフィルタ条件３１８をいくつでも入れられ、フィルタ条件３１８の追加または削除を必要に応じて行うことができる。

データ型３２０により、対応するデータ３２２に含まれる変数の長さと個数が定義される。このアーキテクチャでは、バイト、短整数（short）、長整数（long）、８バイト、文字列、インターネット・プロトコル・バージョン４（ＩＰｖ４）アドレス、インターネット・プロトコル・バージョン６（ＩＰｖ６）アドレス、ＩＰｖ４アドレスとマスク、ＩＰｖ６アドレスとマスク、およびアドレス範囲などの、所定の知られている変数の型をサポートする。

データ・フィールド３２２は、データ型と一致するデータが格納される。例えば、ＩＰｖ４アドレス型であれば、データ・フィールド３２２の受け付けられる値は、ドット付き１０進法で表記して００．００．００．００〜２５５．２５５．２５５．２５５の範囲の３２ビットの数である。いくつかの例では、データ型３２０は、データ・フィールド３２２内に複数の値を入れられる。アドレス範囲、ＩＰｖ４アドレスとマスク、およびＩＰｖ６アドレスとマスクのデータ型では、ＩＰアドレスの開始および終了範囲を定義する２つのＩＰアドレス値を使用できる。自由度を最大限まで高めるために、このアーキテクチャではユーザ定義データ型も使用できる。あるいは、追加データ型を手動で、システム・アーキテクチャに加えられる。

レイヤＩｄ：フィールドＩｄフィールド３３２は、それぞれ、発信元レイヤとその発信元レイヤからのパラメータを識別する場合に使用される。発信元レイヤおよびその発信元レイヤからのパラメータは、パケット・パラメータ、つまり、データ３２２と対照されるレイヤ・パラメータおよびパケット・コンテキストを定義される。発信元レイヤは、特定のカーネルまたはユーザ・レイヤを識別する。発信元レイヤからのパラメータにより、発信元レイヤに関連付けられている特定のパラメータが識別される。具体例は、フィルタ条件３２６により例示されている。この型はＩＰｖ４なので、データ３２２は３２ビットＩＰアドレスであることを示している。レイヤＩｄは、３２ビット数がＩＰ、つまり、ネットワーク、レイヤ・パラメータであることを表す「ＩＰ」である。フィールドＩｄは、例では、ＩＰレイヤ・パラメータ、具体的には送信元ＩＰアドレスを表す、「Ｓｒｃ ＩＰ Ａｄｄｒ」である。データ・フィールドに入っているＩＰアドレスは、その送信元ＩＰアドレスを持つパケットがフィルタ条件と合致し、したがってフィルタにマッチすることを示す「１２３．３．２．１」である。

フィルタ３１０で指定されるアクション３１６は、ｐｅｒｍｉｔ、ｂｌｏｃｋ、ｃａｌｌｏｕｔ、またはｎｕｌｌである。フィルタ３１０内のアクション３１６がｐｅｒｍｉｔまたはｂｌｏｃｋであり、パケットがフィルタ３１０にマッチした場合、要求レイヤにｐｅｒｍｉｔまたはｂｌｏｃｋアクションが返される。ｐｅｒｍｉｔおよびｂｌｏｃｋアクションは、通常、ファイヤウォール・ポリシーを実装する場合に使用される。アクション３１６がコールアウトの場合、ポリシー・エンジンは、マッチするフィルタの完全パケット、レイヤ・パラメータ、コンテキスト、および識別を含む自分の分類要求を指定されたコールアウト・モジュール２５８に発行する。コールアウト・モジュール２５８は、パケットに対してプログラムされている機能、例えば、侵入検出を実行する。コールアウトは、アクション（ｐｅｒｍｉｔ、ｂｌｏｃｋのいずれか）をポリシー・エンジンに返し、さらにポリシー・エンジンはそのアクションを要求レイヤへと中継する。また、コールアウトは、ポリシー・エンジン２５６を介して要求レイヤに同様に返されたパケット・コンテキストを保持することができる。

カーネル・ポリシー・エンジンまたはユーザ・ポリシー・エンジンはさらに、ポリシー・コンテキスト３１７を返す。ポリシー・コンテキスト３１７は、セキュリティ・ポリシーまたはＱＯＳポリシーなどのファイヤウォール・ポリシー以外のポリシーを格納する場合に使用される。ポリシー・コンテキストは、適当な任意のデータ構造体である。例えば、ポリシー・コンテキストは、ポリシー・コンテキスト３１７を加えたプロセスにより解釈される６４ビット数である。フィルタ内のポリシー・コンテキストは、実際のポリシーまたは、実際のポリシーにマッピングするためにシステムによって使用される値を含むことができる。

図５は、カーネルおよびユーザ・レイヤ、およびコールアウト・モジュール２５８により保持されるパケット・コンテキストに使用されるデータ構造体３３０の一例を示している。各エントリには、レイヤＩｄ：フィールドＩｄ３３２および対応する値３３４が含まれる。レイヤＩｄ：フィールドＩｄ３３２は、フィルタ３１０（図４）内のフィルタ条件レイヤの一部として与えられたＩｄ：フィールドＩｄ３２４と同じ意味を持つ。つまり、レイヤＩｄ：フィールドＩｄ ３２２は、発信元レイヤおよび発信元レイヤからのレイヤ・パラメータを、値フィールド３３４内に格納されているデータとして識別する。値フィールド３３４は、特定のレイヤ・パラメータを格納する。

具体例として、エントリ３３６は、「ＮＤＩＳ：Ｓｒｃ．ＭＡＣ Ａｄｄｒ」のレイヤＩｄ：フィールドＩｄ３３２を含む。「ＮＤＩＳ」は、リンク・レイヤ２７４（図３）のネットワーク・ドライバ・インターフェース規約による実装を表す。「Ｓｒｃ Ｍａｃ ａｄｄｒ．」は送信元ＭＡＣアドレスを表す。したがって、レイヤ：フィールドＩＤ３３２は、値フィールド３３４内のデータがＮＤＩＳ（リンク）レイヤによって処理された送信元ＭＡＣアドレスであることを示す。値フィールド３３４は、実際の送信元ＭＡＣアドレスを含み、この例では１６進数表記で「００．０８．７４．４Ｆ．２２．Ｅ５」である。

第２の例では、エントリ３３８は「ＮＤＩＳ：ＩＦ Ｎｏ」のレイヤＩｄ：フィールドＩｄ３３２を持つ。これは、再び、レイヤをＮＤＩＳとして識別するが、この場合は、パラメータを、インターフェース番号を特定のＮＤＩＳパラメータとして表す「ＩＦ Ｎｏ」と識別する。値フィールド３３４は、実際のインターフェース番号を含み、この場合には２である。

第３の例では、エントリ３４０は「ＩＰ：Ｄｓｔ ＩＰ Ａｄｄｒ」のレイヤＩｄ：フィールドＩｄ３３２を持つ。「ＩＰ」は、ＩＰプロトコルを使用するネットワーク・レイヤを表し、「Ｄｓｔ ＩＰ Ａｄｄｒ」は、送信先ＩＰアドレスをＩＰレイヤ・パラメータとして表す。値フィールド３３４は、「１２３．３．２．１」の実際の送信先ＩＰアドレスを含む。

基礎のファイヤウォール・アーキテクチャについて説明したので、システムの機能インターフェースと本明細書で説明している基本のファイヤウォール・アーキテクチャを使用して実行される方法例に注目する。機能インターフェースは、複数のアプリケーション・プログラミング・インターフェース（ＡＰＩ）として実装される。ＡＰＩは、図６および図７に例示されているように、レイヤＡＰＩ２８０、コールアウトＡＰＩ２８４、フィルタ・エンジンＡＰＩ２６６、およびキーイング・モジュールＡＰＩ２８８を含む。

レイヤＡＰＩ２８０は、カーネル・レイヤとカーネル・ポリシー・エンジン２５６との間のデータ交換を容易にする。拡大解釈すると、レイヤＡＰＩ２８０について説明する方法は、さらに、ユーザ・レイヤ２９２とフィルタ・モジュール２９４との間のデータ交換を簡素化し、以下に説明するキーイング・モジュールＡＰＩ２８８の一部として含まれる。図に示されているように、レイヤＡＰＩ２８０は、Ｃｌａｓｓｉｆｙメソッド３５０、Ａｄｄ Ｌａｙｅｒメソッド３５２、およびＤｅｌｅｔｅ Ｌａｙｅｒメソッド３５４を備える。

Ｃｌａｓｓｉｆｙメソッド３５０は、要求レイヤによって使用されて、レイヤ・パラメータ、要求レイヤによって受信されたとおりのパケット、およびパケット・コンテキストをカーネル・ポリシー・エンジン２５６またはフィルタ・モジュール２８８に送信する。カーネル・ポリシー・エンジン２５６またはフィルタ・モジュール２８８は、（１）要求レイヤからのレイヤ・パラメータおよび（２）パケット・コンテキスト・エントリ、をマッチするフィルタを識別するために要求レイヤに割り当てられている各フィルタ３１０内のフィルタ条件３１８と、比較する。以下は、Ｃｌａｓｓｉｆｙメソッドの実装例である。以下のメソッドはデータ値を受信するかまたは返すものとして説明していることが理解されよう。知られているプログラミング手法によれば、これらのメソッドでは、実際のデータ値ではなく、データ値へのポインタを使用することができる。

以下に、列挙されているパラメータの特徴を述べる。

ＬａｙｅｒＩｄでは、分類要求を発行するカーネルまたはユーザ・レイヤ、つまり要求レイヤを識別する。図３を参照すると、レイヤは、レイヤＩｄにより、データ・ストリーム・レイヤ２６８、トランスポート・レイヤ２７０、ネットワーク・レイヤ２７２、リンク・レイヤ２７４、またはキーイング・モジュール・レイヤなどのユーザ・レイヤとして識別される。他のレイヤは、システムに追加した場合に有効である。

ｐＩｎＦｉｘｅｄＶａｌｕｅｓは、要求レイヤによって処理されるレイヤ・パラメータのサブ・セットを含む。ｐＩｎＦｉｘｅｄＶａｌｕｅｓをパケット・コンテキスト・エントリと合わせて、フィルタ条件と比較し、パケットがフィルタにマッチするかどうかを決定する。カーネル・レイヤのｐＩｎＦｉｘｅｄＶａｌｕｅｓに含まれるデフォルト（初期設定）のレイヤ・パラメータが以下の表Ａにまとめられている。ユーザ・レイヤにはデフォルトのパラメータはない。アーキテクチャの利点はレイヤ側でそのレイヤに可能などのような値でも使用できるという点であるので、以下の値は単なる例示であることに留意されたい。

ｐＩｎＣｏｎｔｅｘｔは、要求レイヤが受信するコンテキスト・データ構造体３３０（図５）を含む。パケット・コンテキストをレイヤ・パラメータとともに使用して、マッチするパケットを識別する。
ｐＰａｃｋｅｔは、要求レイヤによって受信されるパケット全体を含む。
ｐＡｃｔｉｏｎＴｙｐｅは、要求レイヤに返されるアクション３１６を含む。返されるアクション３１６は、マッチするフィルタにより識別されるｐｅｒｍｉｔ、ｂｌｏｃｋ、ｃｏｎｔｉｎｕｅ、またはｎｕｌｌであるか、またはマッチするフィルタにより実行されるコールアウト・モジュールである。すでに説明したように、アクション３１６を使用して、ネットワーク・ファイヤウォール・ポリシーを実装し、識別する。
ｐＯｕｔＣｏｎｔｅｘｔは、ポリシー・コンテキスト・データを含む。すでに述べたように、ポリシー・コンテキストは、ＩＰＳｅｃ、ＱＯＳ、および他の非ファイヤウォール・フィルタ・ベースのポリシーに関連付けられているネットワーク・ポリシーを実装するために使用される。

Ａｄｄ Ｌａｙｅｒ ３５２およびＤｅｌｅｔｅ Ｌａｙｅｒ ３５４のメソッドは、それぞれ、管理モジュール２１４にユーザまたはカーネル・レイヤを追加したり削除する場合に使用される。以下は、Ａｄｄ Ｌａｙｅｒ ３５２メソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ｐＬａｙｅｒＩｄは、追加されるレイヤ、つまり、Ａｄｄ Ｌａｙｅｒメソッドを実行するレイヤに返される一意的なレイヤ識別値である。

本発明の一実施形態では、オペレーティング・システムが開始したときに、いくつかのレイヤがアーキテクチャに含まれている。このようなレイヤの例として、リンク・レイヤ、ネットワーク・レイヤ、およびトランスポート・レイヤがある。したがって、ＡｄｄＥｘｔｅｎｓｉｏｎＬａｙｅｒメソッドはフレームワークにこれらのレイヤを含める必要はない。ポリシー・エンジンについて、どのフィールドがレイヤに対し有効なフィルタ条件であるか、フィルタの重みをどのように計算するのか、などを識別するＬａｙｅｒＳｅｔＰｒｏｐｅｒｔｉｅｓメソッドが用意されている。以下は、ＬａｙｅｒＳｅｔＰｒｏｐｅｒｔｉｅｓメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。

ｅｎｇｉｎｅｈａｎｄｌｅはポリシー・エンジンへのハンドルである。

ｌａｙｅｒＩｄによりレイヤを識別する。

ｌａｙｅｒＰｒｏｐｅｒｔｙは、レイヤ・フィールドおよびフィルタ重みの計算を含むレイヤプロパティを識別する。

以下は、Ｄｅｌｅｔｅ Ｌａｙｅｒ ３５４メソッドの例である。

ＬａｙｅｒＩｄは、削除対象のレイヤ、つまり、Ｄｅｌｅｔｅ Ｌａｙｅｒメソッドを実行するレイヤを識別する。

コールアウトＡＰＩ２８４を使用すると、カーネルまたはユーザ・ポリシー・エンジンとコールアウトとの間のデータ交換がやりやすくなる。レイヤＡＰＩ２８０のように、コールアウトＡＰＩ２８４にはＣｌａｓｓｉｆｙメソッドが用意されている。コールアウトＡＰＩ２８４のＣｌａｓｓｉｆｙメソッド３５６は、マッチするフィルタ・データも含むことを除き、レイヤＡＰＩ２８０のＣｌａｓｓｉｆｙメソッド４０２に類似している。以下は、コールアウトを実行するために使用するＣｌａｓｓｉｆｙメソッド３５６の例である。

以下に、列挙されているパラメータの特徴を述べる。
ｆｉｘｅｄＶａｌｕｅｓは、要求レイヤから送信されたレイヤ・パラメータを含む。このｆｉｘｅｄＶａｌｕｅｓは、レイヤＡＰＩ２８０のＣｌａｓｓｉｆｙメソッド３５０の一部として送信されたｐＩｎＦｉｘｅｄＶａｌｕｅｓデータで要求レイヤにより供給されるデータと同じである。

ｗｆｐＣｏｎｔｅｘｔは、コンテキスト・データ構造体３３０（図５）を含む。このデータは、レイヤＡＰＩ２８０のＣｌａｓｓｉｆｙメソッド３５０の一部として送信されたｐＩｎＣｏｎｔｅｘｔで要求レイヤにより供給されるのと同じである。

ｐａｃｋｅｔは、要求レイヤにより受信されるパケット全体を含む。このデータは、レイヤＡＰＩ２８０のＣｌａｓｓｉｆｙメソッド３５０の一部として送信されたｐＰａｃｋｅｔで要求レイヤにより供給されるのと同じである。

ｍａｔｃｈｅｄＦｉｌｔｅｒは、コールアウトを要求するフィルタを識別する。通常、マッチするフィルタは、コールアウトＡＰＩ２８４のＣｌａｓｓｉｆｙメソッド３５０を開始するマッチするフィルタ３１０のフィルタＩｄ３１２により識別される。

ａｃｔｉｏｎは、コールアウト２５８からカーネルまたはユーザ・ポリシー・エンジンに返されるアクションを含む。ａｃｔｉｏｎがｐｅｒｍｉｔまたはｂｌｏｃｋであれば、レイヤＡＰＩ２８０により返されるａｃｔｉｏｎとして要求レイヤに返される。コールアウトは、マッチするフィルタをパケットに適用する作業を続行させることをポリシー・エンジンに指令するＣｏｎｔｉｎｕｅアクションを返すこともできる。

ＯｕｔＣｏｎｔｅｘｔは、セキュリティまたはＱＯＳポリシー・データなどのポリシー・コンテキスト・データを格納する。

コールアウトＡＰＩ４０８は、Ｎｏｔｉｆｙメソッド３５８も含む。Ｎｏｔｉｆｙメソッド３５８は、コールアウト・モジュール２５８をアクション３１６の１つとして識別する一組のインストールされているフィルタ２８２にフィルタ３１０が追加される場合にそのことをコールアウトに通知するために使用する。Ｎｏｔｉｆｙは、適時コールアウトを提供して、ポリシー・エンジン２５６によって実行される際にコールアウト２５８により使用されるバッファの割り当てまたは解放などの必要なアクションをとる。以下は、Ｎｏｔｉｆｙメソッド３５８の例である。

以下に、列挙されているパラメータの特徴を述べる。
ｎｏｔｉｆｙは、フィルタの追加または削除を示す数値を格納する。例えば、値１はフィルタの追加、値２はフィルタの削除を指し示す。

ｆｉｌｔｅｒは、追加または削除対象のフィルタを一意的な値で識別する。これは、フィルタ３１０の一部として含まれるフィルタＩｄ３１２を用意することで実現できる。

コールアウトＡＰＩはさらに、Ｃａｌｌｏｕｔ Ｒｅｇｉｓｔｒａｔｉｏｎメソッド３６０およびＣａｌｌｏｕｔ Ｄｅｒｅｇｉｓｔｒａｔｉｏｎメソッド３６２も含み、それぞれ、コールアウト・モジュールの追加および削除を行う。Ｃａｌｌｏｕｔ Ｒｅｇｉｓｔｒａｔｉｏｎメソッド３６０の例を以下に示す。

以下に、列挙されているパラメータの特徴を述べる。
ｃａｌｌｏｕｔＩｄは、登録コールアウト・モジュールの一意的な識別を行う。

ｃａｌｌｏｕｔは、ドライバ・サービス名、デバイス名、およびコールアウトのｃａｌｓｓｉｆｙおよびｎｏｔｉｆｙ関数へのポインタなどのコールアウト固有の情報を与える。

ｓｄは、コールアウトのセキュリティ・ディスクリプタを与える。このセキュリティ・ディスクリプタは、どのプロセスでコールアウトの読み取りおよび削除を行えるかを識別する。

Ｃａｌｌｏｕｔ Ｄｅｒｅｇｉｓｔｒａｔｉｏｎメソッド３６２の例を以下に示す。

以下に、列挙されているパラメータの特徴を述べる。
ｃａｌｌｏｕｔＩｄは、削除されるべきコールアウトの一意的Ｉｄである。

フィルタ・エンジンＡＰＩ２６６は、ユーザ・ポリシー・エンジン２６０とカーネル・ポリシー・エンジン２５６との間のデータ交換を容易にする。図に示されているように、フィルタ・エンジンＡＰＩ２６６は、Ａｄｄ Ｆｉｌｔｅｒメソッド３６４、Ｄｅｌｅｔｅ Ｆｉｌｔｅｒメソッド３６６、およびＥｎｕｍ Ｌａｙｅｒメソッド３６８を備える。

Ａｄｄ Ｆｉｌｔｅｒ３６４およびＤｅｌｅｔｅ Ｆｉｌｔｅｒ３６６メソッドは、それぞれ、一組のインストールされているフィルタ２８２に新しいフィルタを追加し、一組のインストールされているフィルタ２８２から既存のフィルタを削除する場合に使用する。以下は、Ａｄｄ Ｆｉｌｔｅｒ３６４メソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ＬａｙｅｒＩｄは、フィルタに割り当てられているレイヤを識別する。

ｐＦｉｌｔｅｒは、一組のインストールされているフィルタ２８２に追加されるフィルタ３１０である。

以下は、Ｄｅｌｅｔｅ Ｆｉｌｔｅｒメソッド３６６の例である。

以下に、列挙されているパラメータの特徴を述べる。
ＬａｙｅｒＩｄは、フィルタの割り当てられているレイヤを識別する。

ｐＦｉｌｔｅｒは、一組のインストールされているフィルタから、削除されるフィルタである。

Ｅｎｕｍ Ｌａｙｅｒメソッド３６８は、一組の基準とマッチするすべてのフィルタを識別するユーザ・ポリシー・エンジン２６０のメカニズムを実装する。これにより、管理ＡＰＩはフィルタのアービトレーションおよびコンフリクト解消のために、コンフリクトしているフィルタを識別することができる。以下は、Ｅｎｕｍ Ｌａｙｅｒメソッド３６８の例である。

以下に、列挙されているパラメータの特徴を述べる。
ｐＥｎｕｍＴｅｍｐｌａｔｅは、返すフィルタを定義するデータ構造体を格納する。例えば、返されるフィルタに対しフィルタ条件がマッチしていなければならないパラメータが格納される。

ｐＭａｔｃｈＣｏｕｎｔには、指定されたｐＥｎｕｍＴｅｍｐｌａｔｅに基づいてマッチするフィルタ数を含む。

ｐＥｎｕｍＨａｎｌｄｅには、マッチしたフィルタ・エントリへの参照が格納される。

キーイング・モジュールＡＰＩ２８８は、ユーザ・モード・キーイング・モジュール・レイヤ２９６とユーザ・ポリシー・エンジン２６０との間のインターフェースを提供する。キーイング・モジュールＡＰＩ２８８は、ＩＰＳｅｃ ＳＡ Ａｃｑｕｉｒｅメソッド３７０、Ｅｘｐｉｒｅ Ｎｏｔｉｆｙメソッド３７２、およびＩＰＳｅｃ ＳＡ Ａｃｑｕｉｒｅ Ｃｏｍｐｌｅｔｅメソッド３７４、Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｒｅｇｉｓｔｅｒメソッド３７６、Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｄｅｒｅｇｉｓｔｅｒメソッド３７８、ＩＰＳｅｃ Ｉｎｂｏｕｎｄ Ｇｅｔ ＳＰＩメソッド３８０、Ａｄｄ Ｉｎｂｏｕｎｄ ＳＡメソッド３８２、Ａｄｄ Ｏｕｔｂｏｕｎｄ ＳＡメソッド３８４、Ｉｎｂｏｕｎｄ ＳＡ Ｅｘｐｉｒｅメソッド３８６、およびＫｅｙｉｎｇ Ｍｏｄｕｌｅ Ｉｎｉｔｉａｔｅメソッド３８８を含む。キーイング・モジュールＡＰＩ２８８はさらに、レイヤＡＰＩについてすでに説明したメソッドも含むことができる。

キーイング・モジュールＡＰＩを使用することで、ＩＰＳｅｃで定義されているような、開始するコンピュータやユーザまたはサービスによって、および応答するコンピュータやユーザまたはサービスによって使用される、公知のセキュリティ・プロトコルの使い勝手が向上する。ＩＰＳｅｃは、ＡＨおよびＥＳＰなどのプロトコルを含む。ＥＳＰプロトコルは、データの完全性、ソース認証、および機密保持を実現する暗号化メカニズムを使用する認証および暗号化プロトコルである。ＡＨプロトコルは、パケット・ヘッダ内でハッシュ署名を使用してパケット・データの完全性および送信者の真正性を確認するための認証プロトコルである。

ＩＫＥプロトコルは、開始コンピュータおよび応答コンピュータがＡＨおよびＥＳＰプロトコルとともに使用されるセキュリティ設定のネゴシエーションをするための方法を実現する。ネゴシエートされたセキュリティ設定では、セキュリティ・アソシエーション（ＳＡ）と呼ばれるデータ構造体を形成する。ＳＡでは、認証アルゴリズム、暗号化アルゴリズム、鍵、および鍵の存続期間など、ＩＰパケットの内容を保護するためにＥＳＰまたはＡＨで使用するパラメータを定義する。ＥＳＰおよびＡＨはＳＡを必要とするため、例示する方法は、開始および応答コンピュータによってＥＳＰまたはＡＨプロトコルが使用される前にＩＫＥネゴシエーションが使用される。それとは別に、ＳＡを手動で作成することもできる。与えられたＳＡは、Ｓｅｃｕｒｉｔｙ Ｐａｒａｍｅｔｅｒ Ｉｎｄｅｘ（ＳＰＩ）と呼ばれる値によって識別される。

開始および応答コンピュータはそれぞれ、ＩＰＳｅｃドライバおよび分類モジュールを備え、これらは、ＩＰＳｅｃポリシーに基づき、開始コンピュータと応答コンピュータとの間で送信されるデータが暗号化または認証を必要とするかどうかを決定する。ＩＰＳｅｃポリシーは、ネットワーク・デバイスでＩＰＳｅｃを使用する方法を定義する一組のフィルタであり、フィルタ・リスト、認証方法、およびその他の情報が含まれる。本発明の一実施形態では、ＩＰＳｅｃポリシーは、カーネル・ポリシー・エンジンまたはフィルタ・モジュール２９４内の一組のインストールされているフィルタに含まれるフィルタにより定義される。パケットに適用されるポリシーは、マッチするフィルタを識別するＣｌａｓｓｉｆｙメソッドを使用するキーイング・モジュール・レイヤを呼び出す（起動する）ことにより識別される。

ＩＰＳｅｃ ＳＡ Ａｃｑｕｉｒｅメソッド３７０は、（クライアント・プロキシを介して）ユーザ・ポリシー・エンジン２６０により呼び出され、ドライバ・アクワイヤ取得または外部開始要求がキーイング・モジュール・レイヤに渡される。キーイング・モジュール・レイヤは、この呼び出しを返し、ネゴシエーションを非同期に実行する。キーイング・モジュール・レイヤがネゴシエーションを完了した後、キーイング・モジュール・レイヤはＩＰＳｅｃ ＳＡ Ａｃｑｕｉｒｅ Ｃｏｍｐｌｅｔｅメソッド３７４を呼び出して、ネゴシエーションが完了していることをユーザ・ポリシー・エンジンに通知する。以下は、ＩＰＳｅｃ ＳＡ Ａｃｑｕｉｒｅメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ｉｐｓｅｃＣｏｎｔｅｘｔは、追加しようとしているＳＡでａｃｑｕｉｒｅをリンクするハンドルである。

ａｃｑｕｉｒｅは、ＩＫＥなどの知られているプロトコルによりＳＡをネゴシエーションための必要な情報を用意する。

ｉｎｂｏｕｎｄＳＡｓｐｉは、到着ＳＡに使用されるＳＰＩを含む。

Ｅｘｐｉｒｅ Ｎｏｔｉｆｙメソッド３７２を呼び出して、ｅｘｐｉｒｅ−ｎｏｔｉｆｙを、到着ＳＡを追加したキーイング・モジュール・レイヤに渡す。以下は、Ｅｘｐｉｒｅ Ｎｏｔｉｆｙメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ｅｘｐｉｒｅＮｏｔｉｆｙは、期限切れになろうとしているＳＡを識別する情報を格納する。例えば、出発ＳＡの場合、ＳＰＩが供給される。

ＩＰＳｅｃ ＳＡ Ａｃｑｕｉｒｅ Ｃｏｍｐｌｅｔｅメソッド３７４は、キーイング・モジュール・レイヤによって呼び出されて、ネゴシエーションが終了し、すべてのＳＡが追加された後、またはエラーに遭遇した後、ユーザ・ポリシー・エンジンのコンテキストを閉じる。このメソッドが実行された後、キーイング・モジュール・レイヤは他のＡＰＩメソッドに対してｉｐｓｅｃＣｏｎｔｅｘｔを再利用しない。以下は、ＩＰＳｅｃ ＳＡ Ａｃｑｕｉｒｅ Ｃｏｍｐｌｅｔｅメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ｅｎｇｉｎｅＨａｎｄｌｅはユーザ・ポリシー・エンジン２６０へのハンドルを与える。

ｉｐｓｅｃＣｏｎｔｅｘｔはＩＰＳｅｃ Ａｃｑｕｉｒｅメソッドでユーザ・ポリシー・エンジンにより渡されるコンテキストである。

ｓｔａｔｕｓは、ＳＡネゴシエーションのステータスおよびその他の詳細を指定する。このステータスは、ＦｗｐＫｅｙｉｎｇＭｏｄｕｌｅＩｎｉｔｉａｔｅ０を介してａｃｑｕｉｒｅが外部で開始された場合に、ユーザ・ポリシー・エンジン２６０により返される。

Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｒｅｇｉｓｔｅｒメソッド３７６は、キーイング・モジュール・レイヤにより呼び出されて、ユーザ・ポリシー・エンジン２６０を登録し、その関数ポインタを渡す。以下は、Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｒｅｇｉｓｔｅｒメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ｅｎｇｉｎｅＨａｎｄｌｅは、ユーザ・ファイヤウォール・エンジン２６０へのハンドルを与える。

ｋｅｙｉｎｇＭｏｄｕｌｅＩＤは、キーイング・モジュール・レイヤの一意的なＩＤである。

ｋｅｙｍｏｄＩｎｆｏには、プロセスＩＰＳｅｃ ＳＡ ＡｃｑｕｉｒｅおよびプロセスＩＰＳｅｃ ＳＡ Ｅｘｐｉｒｅ関数へのポインタなどの、キーイング・モジュール・レイヤに関する登録情報が格納される。

Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｄｅｒｅｇｉｓｔｅｒメソッド３７８は、キーイング・モジュール・レイヤにより呼び出されて、ユーザ・ポリシー・エンジン２６０からキーイング・モジュールの登録を解除する。以下は、Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｄｅｒｅｇｉｓｔｅｒメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ｅｎｇｉｎｅＨａｎｄｌｅはユーザ・ポリシー・エンジン２６０へのハンドルである。

ｋｅｙｉｎｇＭｏｄｕｌｅＩＤは、キーイング・モジュール・レイヤの一意的なＩＤである。

ＩＰＳｅｃ Ｉｎｂｏｕｎｄ Ｇｅｔ ＳＰＩメソッド３８０は、キーイング・モジュール・レイヤにより呼び出されて、新しい到着ＳＡのＳＰＩを取得する。ＩＰＳｅｃ Ｉｎｂｏｕｎｄ Ｇｅｔ ＳＰＩメソッド３８０は、通常、キーイング・モジュール・レイヤが応答ネットワーク・デバイス内で実行される場合に使用される。以下は、ＩＰＳｅｃ Ｉｎｂｏｕｎｄ Ｇｅｔ ＳＰＩメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ｅｎｇｉｎｅＨａｎｄｌｅはユーザ・ファイヤウォール・エンジン２６０へのハンドルである。

ｉｐｓｅｃＴｒａｆｆｉｃＤｅｓｃｒｉｐｔｉｏｎは、到着の初期段階のＳＡ（ｉｎｂｏｕｎｄ ｌａｒｖａｌ ＳＡ）を作成するための５つのタプル（tuple：構造体）の記述である。この５つのタプルには、送信元および送信先ＩＰアドレス、送信元および送信先ポート、およびトランスポート・レイヤのプロトコル・タイプが含まれる。

ｕｄｐＥｎｃａｐＩｎｆｏは、初期段階のＳＡを作成するためのＵＤＰカプセル化データである。ＵＤＰカプセル化は、セキュリティ・プロトコルに従って書式化されているパケットを非暗号化ＵＤＰパケットに埋め込む公知の方法である。

ｉｎｂｏｕｎｄＳｐｉは、到着ＳＡのＳＰＩである。

Ａｄｄ Ｉｎｂｏｕｎｄ ＳＡメソッド３８２は、キーイング・モジュール・レイヤにより呼び出されて、到着ＳＡを追加する、つまり初期段階のＳＡを更新する。ユーザ・ポリシー・エンジン２６０はＳＡの中のＳＰＩを使用して、この呼び出しを内部状態にマッピングし、ｉｏｃｔｌでＳＡをＩＰＳｅｃドライバに送る。以下は、Ａｄｄ Ｉｎｂｏｕｎｄ ＳＡメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ｅｎｇｉｎｅＨａｎｄｌｅはユーザ・ポリシー・エンジンへのハンドルである。

ｉｎｂｏｕｎｄＳＡは、到着ＳＡを含む。

Ａｄｄ Ｏｕｔｂｏｕｎｄ ＳＡメソッド３８４は、キーイング・モジュール・レイヤにより呼び出されて、出発ＳＡを追加する。ユーザ・ポリシー・エンジンでは、到着ＳＰＩパラメータを使用して、この呼び出しを内部状態にマッピングし、ｉｏｃｔｌでＳＡをＩＰＳｅｃドライバに送る。以下は、Ａｄｄ Ｏｕｔｂｏｕｎｄ ＳＡメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。

ｅｎｇｉｎｅＨａｎｄｌｅはユーザ・ファイヤウォール・エンジン２６０へのハンドルである。

iｎｂｏｕｎｄＳｐｉは、出発ＳＡのペアの相手である到着ＳＡのＳＰＩである。

ｏｕｔｂｏｕｎｄＳＡは、出発ＳＡを含む。

Ｉｎｂｏｕｎｄ ＳＡ Ｅｘｐｉｒｅメソッド３８６は、キーイング・モジュール・レイヤにより呼び出されて、すでに追加されている到着ＳＡの有効期限を満了させる。以下は、Ｉｎｂｏｕｎｄ ＳＡ Ｅｘｐｉｒｅメソッド３８６の例である。

以下に、列挙されているパラメータの特徴を述べる。
ｅｎｇｉｎｅＨａｎｄｌｅはユーザ・ファイヤウォール・エンジン２６０へのハンドルである。

ｅｘｐｉｒｅは、有効期限の切れるＳＡに対するデータを格納する。

Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｉｎｉｔｉａｔｅメソッド３８８は、ＲＡＳ、Ｗｉｎｓｏｃｋ ＡＰＩなどの公知の外部アプリケーションにより呼び出され、アプリケーションがネットワーク・トラフィックの送信を開始する前に、キーイング・モジュール・レイヤを開始し、ＳＡを設定する。ユーザ・ポリシー・エンジン２６０は、ＲＰＣ呼び出しを非同期にペンディングし、ＩＰＳｅｃドライバからＳＰＩを取得し、ａｃｑｕｉｒｅを該当するキーイング・モジュールに渡す。キーイング・モジュール・レイヤがＦｗｐＩＰＳｅｃＳＡＡｃｑｕｉｒｅＣｏｍｐｌｅｔｅ０を呼び出すと、ユーザ・ファイヤウォール・エンジンは非同期ＲＰＣを、ネゴシエーション・ステータスを使用して達成する。以下は、Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｉｎｉｔｉａｔｅメソッドの例である。

以下に、列挙されているパラメータの特徴を述べる。
ｅｎｇｉｎｅＨａｎｄｌｅはユーザ・ポリシー・エンジン２６０へのハンドルである。

ａｃｑｕｉｒｅは、ＳＡのネゴシエーションに必要なデータを格納する。

ｗａｉｔＥｖｅｎｔは、ネゴシエーション・ステータスが利用可能な場合にトリガされるイベントへのハンドルである。クライアント、つまり、呼び出し側外部アプリケーションがネゴシエーションの完了を待とうとしない場合、クライアントは、このパラメータをＮＵＬＬに設定することができる。内部では、クライアント・プロキシは、任意選択により、このイベントをＲＰＣに渡し、非同期ＲＰＣ呼び出しが完了した後、そのイベントを設定するよう要求する。

ｎｅｇｏｔｉａｔｉｏｎＳｔａｔｕｓは、ネゴシエーションの結果を格納する。ｎｅｇｏｔｉａｔｉｏｎＳｔａｔｕｓは、ｗａｉｔＥｖｅｎｔがＮＵＬＬの場合にＮＵＬＬである。そうでなければ、ｎｅｇｏｔｉａｔｉｏｎＳｔａｔｕｓは、ｗａｉｔＥｖｅｎｔがトリガされるまで有効である。

図８は、パケットに対するマッチするフィルタを見つけ、アクションおよび／またはポリシー・コンテキストを要求レイヤに返すために使用されるメソッドを示している。図に示されているように、第１の要求レイヤ４０４は、要求４０８をポリシー・エンジン４００に発行することによりネットワーク・ポリシーを取得する。ポリシー・エンジン４００は、カーネル・ポリシー・エンジン２５６であり、またはフィルタ・モジュール２９４を備えるユーザ・ポリシー・エンジン２６０である。ポリシー・エンジン４００は、複数のネットワーク・ポリシー、例えば、セキュリティ、ＱＯＳ、およびファイヤウォール・ポリシーを定義するインストールされているフィルタ４０２を含む。

第１の要求レイヤ４０４は、キーイング・モジュール・レイヤなどのユーザ・モード・レイヤ２９２、またはネットワーク・スタック内のレイヤの１つなどのカーネル・レイヤ２５４とすることができる。第１の要求レイヤ４０４は、レイヤＡＰＩを介してポリシー・エンジン４００と通信する。

要求４０８、例えば、Ｃｌａｓｓｉｆｙメソッドを使用する分類要求は、レイヤ・パラメータ４１０、パケット・コンテキスト４１２、および要求レイヤ４０４により受信されるような完全なパケット４１４を含む。ポリシー・エンジン４００は、レイヤ・パラメータ４１０およびパケット・コンテキスト４１２を使用して、インストールされているフィルタ４０２からマッチするフィルタを識別する。通常、ポリシー・エンジン４００は、マッチするフィルタによって規定される重みの順序でフィルタを適用する。その後、ポリシー・エンジン４００は、アクション４１８およびポリシー・コンテキスト４２０を含む値４１６を返す。アクション４１８は、ｐｅｒｍｉｔまたはｂｌｏｃｋなどのファイヤウォール・ポリシーを返すために使用される。ポリシー・コンテキスト４２０は、セキュリティまたはＱＯＳポリシーなどの他のポリシーを返す場合に使用される。返されたアクション４１８およびポリシー・コンテキスト４２０は、対応するポリシーをフィルタが含まない場合、ｎｏｎｅまたはｎｕｌｌとして示される。

第１の要求レイヤ４０４は、第２の要求レイヤ４０６と対話することができる。この対話は、要求レイヤがネットワーク・スタック内のカーネル・レイヤ２５４である場合に実行される。第１の要求レイヤ４０４は、要求レイヤにより処理されるレイヤ・パラメータを使用してパケット・コンテキスト４２２を更新することができる。また、第１の要求レイヤ４０４はレイヤ・プロトコルに従ってパケットを処理することができる。要求レイヤは、修正されたパケット４２２を第２の要求レイヤ４０６に渡す。パケット４２４がレイヤ・プロトコルに従って処理された後、要求レイヤはさらにそのパケットを渡す。例えば、第１の要求レイヤ４０４は、ＩＰプロトコルを実装している場合、ＩＰプロトコルに従ってパケットを処理する。その後、第１の要求レイヤは、到着パケットの場合にはトランスポート・プロトコル・レイヤであり、出発パケットの場合にはリンク・レイヤである、第２の要求レイヤ４０６にパケットを渡す。そして、第２の要求レイヤ４０６は、分類要求を送信し、返されたアクションおよびポリシー・コンテキスト値を受信することで、このプロセスを繰り返すことができる。

図９は、パケットに対する適用可能なネットワーク・ポリシー、例えば、アクションおよびポリシー・コンテキスト、を取得するために要求レイヤによって使用される５００と示されているメソッドを例示している。ステップ５０２で、要求レイヤは完全なパケットおよび対応するパケット・コンテキストを、前のレイヤまたは他のプロセスまたはプログラム・モジュールから、受信する。

ステップ５０４で、要求レイヤはレイヤ・パラメータを識別する。レイヤ・パラメータは、パケット・コンテキストと組み合わせて、マッチするフィルタを識別するために使用されるパラメータである。既定のレイヤ・パラメータは、上の表Ａで説明されており、Ｃｌａｓｓｉｆｙメソッド３５０のｐＩｎＦｉｘｅｄＶａｌｕｅｓに含まれる。

ステップ５０６で、要求レイヤは分類要求をカーネルまたはユーザ・ポリシー・エンジンに発行する。分類要求を発行する方法例については、レイヤＡＰＩ２８０のＣｌａｓｓｉｆｙメソッド３５０を参照して説明されている。

ステップ５０８に示されているように、分類要求に対する応答として、アクションおよびポリシー・コンテキストが要求レイヤに返される。要求レイヤは、返されたアクションに基づき、パケットを削除（drop）するかどうかを決定する。ポリシー・エンジンがアクションとしてｂｌｏｃｋを返した場合、要求レイヤはパケットを削除（drop）する。要求レイヤはさらに、ポリシー・エンジンが、マッチするフィルタが見つからないとしてアクションを返した場合、パケットを削除（drop）することができる。すでに説明したように、このアクションを使用して、ファイヤウォール・ポリシーを実装する。マッチするフィルタがファイヤウォール・ポリシーを含まない場合、返されるアクションはｎｏｎｅまたはｎｕｌｌである。

ステップ５１０、５１２、５１４は、通常、要求レイヤがネットワーク・スタック内のレイヤである場合にしか実行されないが、任意選択でユーザ・モード・レイヤにより実行することもできる。返されたアクションがｐｅｒｍｉｔである場合、さらにパケット処理が実行される。ステップ５１０で、要求レイヤは、レイヤ情報、通常は分類要求にレイヤ・パラメータとして含まれていたのと同じ種類の情報、を含むようにパケット・コンテキストを修正する。こうして、表Ａ（上記）では、レイヤ・パラメータを明記するだけでなく、パケット・コンテキストに各レイヤによって追加される既定の情報をも明記している。パケット・コンテキストは、図５を参照して説明されているデータ構造体などのデータ構造体内に保持される。

ステップ５１２で、要求レイヤはそのレイヤに対するプロトコル実装に従いパケットを処理する。このような処理はよく知られており、ここで詳しく説明する必要はない。プロトコルの実装の例としては、アプリケーション・レイヤのＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、およびＲＰＣ、トランスポート・レイヤのＴＣＰおよびＵＤＰ、ネットワーク・レイヤのＩＰ、およびリンク・レイヤのＮＤＩＳがある。

ステップ５１４で、要求レイヤは、修正されたパケット・コンテキストとともに、レイヤ・プロトコルに従って処理されたパケットを次のレイヤに受け渡す。プロセス５００は各レイヤにより繰り返され、パケットが一連のレイヤ内のすべてのレイヤ、例えば、ネットワーク・スタック内のレイヤをトラバースするまで、またはパケットがレイヤの１つにより削除（drop）されるまで、続く。

ここでは図１０を参照して、マッチするフィルタを識別し、アクションおよびポリシー・コンテキストを要求レイヤに返すためカーネルまたはユーザ・ポリシー・エンジンにより使用されるメソッド５２０について説明する。ステップ５２２で、ポリシー・エンジンは、適切なＡＰＩを介して要求レイヤからパケット、レイヤ・パラメータ、およびパケット・コンテキストを受信する。

ステップ５２４で、ポリシー・エンジンは、１つまたは複数のマッチするフィルタを識別する。本発明の一実施形態では、フィルタは特定の要求レイヤに割り当てられる。ポリシー・エンジンは、フィルタが要求レイヤに割り当てられて、且つパケット・パラメータがすべてのフィルタ条件３１８（図５）を満たしている場合、フィルタをマッチしていると識別することを試みるだけである。すでに述べたように、パケット・パラメータは、要求レイヤとパケット・コンテキストの両方のレイヤ・パラメータを含む。すべてのマッチするフィルタが識別された後、ポリシー・エンジンは、それぞれのマッチするフィルタ内の重みフィールド３１４に基づきフィルタの順序付けを行う。あるいは、フィルタを特定の要求レイヤに割り当てず、すべてのフィルタをマッチするフィルタとすることもできる。

ステップ５２６で、ポリシー・エンジンはまだ適用されていない最高の重みのフィールド３１４を持つフィルタを適用する。特に、ポリシー・エンジンは、フィルタおよびポリシー・コンテキストで指定されているアクション３１６を識別する。アクション３１６でコールアウト・モジュールを指定している場合、ポリシー・エンジン２５６はコールアウトを実行する。コールアウトは、ポリシー・エンジンにアクションを返す場合がある。

ステップ５３６に示されているように、アクションがｃａｌｌｏｕｔでなかった場合、またはコールアウトが実行された後、ポリシー・エンジンはマッチするフィルタから、またはコールアウトにより識別されている、関連するアクションおよびポリシー・コンテキストを要求レイヤに返す。あるいは、ポリシー・エンジンは、すべてのマッチするフィルタが適用されるまで、ステップ５３６の実行を待つ、つまりアクションを返す。

ステップ５３４で、ポリシー・エンジンは、さらにマッチするフィルタが存在するかどうかを決定する。存在しなければ、プロセスは終了する。マッチするフィルタがさらに存在すれば、プロセスはステップ５２６に戻り、そこで次に高い優先度のフィルタが適用される。このプロセスは、すべてのマッチするフィルタが適用されるまで続けられる。あるいは、このプロセスは、終了アクションがそのパケットに対して識別された後に終了する。アクションタイプは、終了アクションとして定義することができる。既定では、ｐｅｒｍｉｔおよびｂｌｏｃｋは終了アクションである。そのパケットに対し識別されるマッチするフィルタがない場合、ポリシー・エンジンは、マッチするフィルタが見つからなかったと要求レイヤに通知する。

図１１は、新しいフィルタを、一組のインストールされているフィルタに追加するためにユーザ・ポリシー・エンジン２６０により使用されるプロセス５４０を例示している。フィルタは、カーネル・ポリシー・エンジン２５６またはフィルタ・モジュール２９４にインストールすることができる。ステップ５４２で、ユーザ・ポリシー・エンジンは、ポリシー・プロバイダ２６２の１つからポリシーを受け取る。ポリシー・プロバイダは、ＬＩＰＳ、ＧＵＩなどの知られているプロセスを含む。ユーザ・ポリシー・エンジンは、必要に応じて、フィルタ条件、アクション、およびポリシー・コンテキストに関してポリシーを定義することによりポリシーをフィルタ形式にする。

ステップ５４４で、ユーザ・ポリシー・エンジンによりフィルタに重み値が割り当てられる。この重み値は、ポリシー・プロバイダ、例えば、ユーザがポリシー・プロバイダＧＵＩを使用して手動で割り当てる。あるいは、ユーザ・ポリシー・エンジンは、この重み値を自動的に計算する。カーネル・ポリシー・エンジン２５６は、何らかの適当な方法を使用して重みを計算する。例えば、より具体的なフィルタ条件が設定されたフィルタに、あまり具体的でない詳しくないフィルタよりも高い重み値を付ける。フィルタ条件が具体的なほど、フィルタ条件を満たす潜在的パケットの数は少なくなる。例えば、単一のＩＰアドレスをそのフィルタ条件とするフィルタは、ある範囲のＩＰアドレスをフィルタ条件とするフィルタよりも具体的である。

ステップ５４８で、ユーザ・ポリシー・エンジン２６０は、新しいフィルタを、コンフリクトを識別するために、同じレイヤに割り当てられているインストールされているフィルタのそれぞれと、比較する。フィルタをコンフリクトさせるためには、同じパケットに作用し、異なるアクションを識別するような共通の一組のフィルタ条件を共有する必要がある。例えば、インストールされているフィルタのフィルタ条件が１２３．４．０．０から１２３．４．０．１００までの範囲の送信元ＩＰアドレスで、関連するアクションがｐｅｒｍｉｔであり、新しいフィルタのフィルタ条件が１２３．４．０．５０から１２３．４．０１５０までの範囲の送信元ＩＰアドレスで、関連するアクションがｂｌｏｃｋの場合、両方のフィルタ条件に１２３．４．０．５０から１２３．４．０．１００までのＩＰアドレス範囲が含まれる限り、新しいインストールされたフィルタは重なり合う。

フィルタがコンフリクトする場合、ユーザ・ポリシー・エンジン２６０は、ステップ５５２で示されているように、適当な手法を使用してコンフリクトを解消する。フィルタ重みを計算し、フィルタのコンフリクトを識別して解消する方法は、「Method for Managing Network Filter Based Policy」という表題の米国同時係属特許出願で説明されている。コンフリクト解消プロセスの一部として、新しいフィルタを一組のインストールされているフィルタに追加することができる。新しいフィルタが一組のインストールされているフィルタとコンフリクトしない場合、新しいフィルタは、ステップ５５０で示されているように、ユーザ・ポリシー・エンジンまたはカーネル・ポリシー・エンジンのいずれかの一組のインストールされているフィルタに追加される。

新しいフィルタが一組のインストールされているフィルタにロードされると、ステップ５５４で示されているように、フィルタによって実行されるコールアウト、つまり、関連するアクションとしてフィルタに含まれるコールアウトに通知が行われる。コールアウトに通知する方法の例については、コールアウトＡＰＩ２８４の一部として説明したＮｏｔｉｆｙメソッド４１２を参照して説明されている（図６）。

本明細書で引用した参考文献はすべて、参照によりその全体が本明細書に組み込まれる。

本発明の原理を適用することが可能な考えうる多くの実施形態にかんがみて、図面に関して本明細書で説明した実施形態は説明のみを目的としており、本発明の範囲を制限するものとしてみなすべきではないことは理解されるであろう。例えば、当業者であれば、ソフトウェアで示されている説明した実施形態の要素は、ハードウェアで実装することができるが、その逆も可能であること、あるいは説明した実施形態は、本発明の精神から逸脱することなくその配置および詳細を修正できることを理解するであろう。本発明は、フィルタ、およびこれらのプロセスおよび追加プロセスのフィルタ・ベースのポリシーを管理し、実行するために使用できる。したがって、本明細書で説明した発明は、請求項およびそれと同等の条項の範囲内に納められるようなすべての実施形態を対象としている。

本発明が配置されるコンピュータ・システム例の概要を説明するブロック図である。 本発明を使用できるネットワーク環境例のブロック図である。 複数のネットワーク・ポリシーを実装し、管理するために使用されるシステム・アーキテクチャのブロック図である。 ポリシー・フィルタのデータ構造例の図である。 パケット・コンテキストのデータ構造例の図である。 本発明とともに使用されるアプリケーション・プログラミング・インターフェース例の図である。 本発明とともに使用されるアプリケーション・プログラミング・インターフェース例の図である。 データに対するポリシーを取得する要求レイヤを例示するブロック図である。 ネットワーク・ポリシーを実装するため要求レイヤによって使用される方法を例示する流れ図である。 データに対するネットワーク・ポリシーを識別するためポリシー・エンジンによって使用される方法を例示する流れ図である。 新しいポリシー・フィルタをポリシー・エンジンに追加するため使用される方法を例示する流れ図である。

符号の説明

１００ コンピューティング・システム環境
１１０ コンピュータ
１２０ 処理ユニット
１２１ システム・バス
１３０ システム・メモリ
１３１ 読み取り専用メモリ（ＲＯＭ）
１３２ ランダム・アクセス・メモリ（ＲＡＭ）
１３３ 基本入出力システム
１３４ オペレーティング・システム
１３５ アプリケーション・プログラム
１３６ その他のプログラム・モジュール
１３７ プログラム・データ
１４１ ハードディスク・ドライブ
１５１ 磁気ディスク・ドライブ
１５２ 取り外し可能な不揮発性磁気ディスク
１５５ 光ディスク・ドライブ
１５６ 取り外し可能な不揮発性光ディスク
１６０ ユーザ入力インターフェース
１６１ ポインティング・デバイス
１６２ キーボード
１７１ ローカル・エリア・ネットワーク（ＬＡＮ）
１７２ モデム
１７３ ワイド・エリア・ネットワーク（ＷＡＮ）
１８０ リモート・コンピュータ
１８１ メモリ記憶デバイス
１８５ リモート・アプリケーション・プログラム
１９０ ビデオ・インターフェース
１９１ モニタ
１９５ 出力周辺インターフェース
１９６ プリンタ
１９７ スピーカ
２００ プライベート・ネットワーク
２０２ パブリック・ネットワーク
２０４、２０６、２０８、２１０、および２１２ ネットワーク・デバイス
２１４ フィルタ管理モジュール
２１６ フィルタ
２５０ ユーザ・モード・プロセス
２５２ カーネル・モード・プロセス
２５４ カーネル・レイヤ
２５６ カーネル・ポリシー・エンジン
２５８ コールアウト
２６２ ポリシー・プロバイダ
２６６ フィルタ・エンジンＡＰＩ
２６８ データ・ストリーム・レイヤ
２７０ トランスポート・レイヤ
２７２ ネットワーク・レイヤ
２７４ リンク・レイヤ
２７６ ファイル・アクセス・レイヤ
２８０ レイヤＡＰＩ
２８２ フィルタ
２８４ コールアウトＡＰＩ
２９２ ユーザ・モード・レイヤ
２９４ フィルタ・モジュール
２９６ キーイング・モジュール・レイヤ
３１０ フィルタ
３１２ フィルタＩＤ
３１４ 重み
３１６ アクション
３１７ ポリシー・コンテキスト
３１８ フィルタ条件
３２０ データ型
３２２ データ
３２４ レイヤＩＤ：フィールドＩＤ
３３２ レイヤＩｄ：フィールドＩｄフィールド
３３４ 値
３３６ エントリ
３５０ Ｃｌａｓｓｉｆｙメソッド
３５２ Ａｄｄメソッド
３５４ Ｄｅｌｅｔｅ Ｌａｙｅｒメソッド
３６０ Ｃａｌｌｏｕｔ Ｒｅｇｉｓｔｒａｔｉｏｎメソッド
３６２ Ｃａｌｌｏｕｔ Ｄｅｒｅｇｉｓｔｒａｔｉｏｎメソッド
３６４ Ａｄｄ Ｆｉｌｔｅｒ
３６６ Ｄｅｌｅｔｅ Ｆｉｌｔｅｒ
３６８ Ｅｎｕｍ Ｌａｙｅｒメソッド
３７０ ＩＰＳｅｃ ＳＡ Ａｃｑｕｉｒｅメソッド
３７２ Ｅｘｐｉｒｅ Ｎｏｔｉｆｙメソッド
３７４ ＩＰＳｅｃ ＳＡ Ａｃｑｕｉｒｅ Ｃｏｍｐｌｅｔｅメソッド
３７６ Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｒｅｇｉｓｔｅｒメソッド
３７８ Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｄｅｒｅｇｉｓｔｅｒメソッド
３８０ ＩＰＳｅｃ Ｉｎｂｏｕｎｄ Ｇｅｔ ＳＰＩメソッド
３８２ Ａｄｄ Ｉｎｂｏｕｎｄ ＳＡメソッド
３８４ Ａｄｄ Ｏｕｔｂｏｕｎｄ ＳＡメソッド
３８６ Ｉｎｂｏｕｎｄ ＳＡ Ｅｘｐｉｒｅメソッド
３８８ Ｋｅｙｉｎｇ Ｍｏｄｕｌｅ Ｉｎｉｔｉａｔｅメソッド
４００ ポリシー・エンジン
４０２ フィルタ
４０４ 第１の要求レイヤ
４０６ 第２の要求レイヤ
４０８ 要求
４１０ レイヤ・パラメータ
４１２ パケット・コンテキスト
４１４ 完全なパケット
４１８ アクション
４２０ ポリシー・コンテキスト
４２２ パケット・コンテキスト
５００ プロセス
５４０ プロセス
２６２ ポリシー・プロバイダ

Claims (37)

1. 少なくとも１つのファイヤウォール・ポリシーおよびセキュリティ・ポリシーを含む、データ・パケットに適用されるべき、複数のフィルタ・ベースのポリシーを統合するフレームワークであって、
   パケットに関連付けられている少なくとも１つのパラメータを識別する一組のレイヤ・プロセスと、
   前記一組のレイヤ・プロセスと通信するポリシー・エンジンと、
   前記ポリシー・エンジンに格納される一組のフィルタであって、前記一組のフィルタ内の各フィルタは、フィルタ条件、前記ファイヤウォール・ポリシーを識別するアクション、および前記セキュリティ・ポリシーを識別するポリシー・コンテキストを有する、一組のフィルタと
   を備えることを特徴とするフレームワーク。
2. 前記複数のフィルタ・ベースのポリシーは、さらに、パケットに適用すべき送信設定を識別するサービスの品質（ＱＯＳ）ポリシーを含み、前記サービスの品質（ＱＯＳ）ポリシーは前記一組のフィルタ内の前記ポリシー・コンテキストにより定義されることを特徴とする請求項１に記載のフレームワーク。
3. 前記一組のレイヤ・プロセス内に、前記少なくとも１つのパラメータを前記ポリシー・エンジンに送信する要求レイヤのプロセスを、さらに備え、
   前記ポリシー・エンジンは、前記少なくとも１つのパラメータにマッチするフィルタ条件を持つ前記一組のフィルタからマッチするフィルタを識別し、前記ファイヤウォール・ポリシーおよび前記セキュリティ・ポリシーを前記要求レイヤに返すことを特徴とする請求項１に記載のフレームワーク。
4. 前記要求レイヤは、キー入力モジュール・レイヤであり、前記マッチするフィルタ内の前記セキュリティ・ポリシーは、鍵ネゴシエーション・プロトコルに従ってセキュリティ・アソシエーションのネゴシエーションを行うためのポリシーを、識別することを特徴とする請求項３に記載のフレームワーク。
5. 前記少なくとも１つのパラメータは、複数のパラメータであり、前記複数のパラメータは、送信元および送信先ＩＰアドレス、送信元および送信先ポート、およびプロトコル・タイプを備えることを特徴とする請求項４に記載のフレームワーク。
6. 前記鍵ネゴシエーション・プロトコルは、ＩＫＥプロトコルであることを特徴とする請求項４に記載のフレームワーク。
7. 前記要求レイヤは、さらに、パケット・コンテキストを送信し、前記ポリシー・エンジンは、さらに、前記パケット・コンテキストから前記マッチするフィルタを識別することを特徴とする請求項３に記載のフレームワーク。
8. レイヤ・プロセスでパケットに適用すべき複数のネットワーク・ポリシーを決定する方法であって、
   前記レイヤ・プロセスにより、前記パケットに関連付けられている一組のパラメータを識別すること、
   前記レイヤ・プロセスにより、前記パケットに適用すべき前記ネットワーク・ポリシーを識別する、前記パケットに関連付けられている前記パラメータを含む要求を送信すること、および
   前記レイヤ・プロセスで、第１のネットワーク・ポリシーを識別する第１のポリシー値と第２のネットワーク・ポリシーを識別する第２のポリシー値を含む応答を受信すること
   を備えることを特徴とする方法。
9. 前記レイヤ・プロセスは、ユーザ・レイヤであることを特徴とする請求項８に記載の方法。
10. 前記レイヤ・プロセスは、カーネル・レイヤであることを特徴とする請求項８に記載の方法。
11. 前記第１のネットワーク・ポリシーは、ファイヤウォール・ポリシーであり、前記第１のポリシー値は、アクション値であることを特徴とする請求項８に記載の方法。
12. 前記アクション値は、許可（permit）または遮断（block）の一方であることを特徴とする請求項１１に記載の方法。
13. 前記第２のネットワーク・ポリシーは、鍵ネゴシエーション・プロトコル・パラメータを定義するセキュリティ・ポリシーであることを特徴とする請求項８に記載の方法。
14. ネットワーク・デバイス内で複数のネットワーク・ポリシーを保持する方法であって、
    一組のフィルタをポリシー・エンジンにインストールすること
    を備え、前記それぞれのフィルタは、
    １組のフィルタ条件と、
    第１のネットワーク・ポリシーを識別する第１のポリシー値と第２のネットワーク・ポリシーを識別する第２のポリシー値と
    を備えることを特徴とする方法。
15. 前記第１のネットワーク・ポリシーは、ファイヤウォール・ポリシーであり、前記第２のネットワーク・ポリシーは、セキュリティ・ポリシーであることを特徴とする請求項１４に記載の方法。
16. 前記セキュリティ・ポリシーは、ＩＰＳｅｃポリシーであることを特徴とする請求項１５に記載の方法。
17. 前記第１のポリシー値は、アクションであり、前記第２のポリシー値は、ポリシー・コンテキストであることを特徴とする請求項１５に記載の方法。
18. ポリシー・エンジンにより、前記複数のネットワーク・ポリシーが適用されるパケットにマッチするフィルタ条件を含むマッチするフィルタを前記一組のフィルタから識別すること、および
    前記パケットに対して少なくとも前記第１のネットワーク・ポリシーを実行すること
    を備えることを特徴とする請求項１４に記載の方法。
19. 前記一組のフィルタをインストールするステップは、オペレーティング・システムのユーザ・モードで実行されることを特徴とする請求項１４に記載の方法。
20. 前記一組のフィルタをインストールするステップは、オペレーティング・システムのカーネル・モードで実行されることを特徴とする請求項１４に記載の方法。
21. 前記複数のポリシーは、ファイヤウォール・ポリシー、セキュリティ・ポリシー、およびサービスの品質（ＱＯＳ）ポリシーを含むことを特徴とする請求項１４に記載の方法。
22. 前記一組のフィルタ条件は、目的のポリシーに従ってフィルタ条件が追加または削除されるように動的に構成可能であることを特徴とする請求項１４に記載の方法。
23. フィルタを定義するデータ構造体が格納されているコンピュータ可読媒体であって、
    マッチするパケットを定義する一組のフィルタ条件を備える第１の一組のデータと、
    第１のネットワーク・ポリシーを備える第２の一組のデータと、
    第２のネットワーク・ポリシーを備える第３の一組のデータと
    を備え、前記第１のネットワーク・ポリシーは前記第２のネットワーク・ポリシーと異なっていることを特徴とするコンピュータ可読媒体。
24. 前記一組のフィルタ条件は、動的に構成可能な複数のフィルタ条件を含むように適合されることを特徴とする請求項２３に記載のコンピュータ可読媒体。
25. 前記一組のフィルタ条件は、データ型および当該データ型と一致する対応するデータを含むことを特徴とする請求項２３に記載のコンピュータ可読媒体。
26. 前記第１のネットワーク・ポリシーは、ファイヤウォール・ポリシーであることを特徴とする請求項２３に記載のコンピュータ可読媒体。
27. 前記第２のネットワーク・ポリシーは、サービスの品質（ＱＯＳ）ポリシーであることを特徴とする請求項２６に記載のコンピュータ可読媒体。
28. 前記第２のネットワーク・ポリシーは、セキュリティ・ポリシーであることを特徴とする請求項２６に記載のコンピュータ可読媒体。
29. 前記データ構造体は、さらに、フィルタの優先度を識別するフィルタ重みを備えることを特徴とする請求項２６に記載のコンピュータ可読媒体。
30. 少なくとも１つのファイヤウォール・ポリシーおよびセキュリティ・ポリシーを含む、データ・パケットに適用すべき、複数のフィルタ・ベースのポリシーを統合するフレームワークを容易にするコンピュータ実行可能命令を実行するためのコンピュータ可読媒体であって、
    パケットに関連付けられている少なくとも１つのパラメータを識別する一組のレイヤ・プロセスと、
    前記一組のレイヤ・プロセスと通信するポリシー・エンジンと、
    前記ポリシー・エンジンに格納される一組のフィルタであって、前記一組のフィルタ内の各フィルタは、フィルタ条件、前記ファイヤウォール・ポリシーを識別するアクション、および前記セキュリティ・ポリシーを識別するポリシー・コンテキストを有する、一組のフィルタと
    を備えることを特徴とするコンピュータ可読媒体。
31. 前記複数のフィルタ・ベースのポリシーは、さらに、パケットに適用すべき送信設定を識別するサービスの品質（ＱＯＳ）ポリシーを含み、前記サービスの品質（ＱＯＳ）ポリシーは、前記一組のフィルタ内の前記ポリシー・コンテキストにより定義されることを特徴とする請求項３０に記載のコンピュータ可読媒体。
32. 前記一組のレイヤ・プロセス内に、前記少なくとも１つのパラメータを前記ポリシー・エンジンに送信する要求レイヤのプロセスを、さらに備え、
    前記ポリシー・エンジンは、前記少なくとも１つのパラメータにマッチするフィルタ条件を持つ前記一組のフィルタからマッチするフィルタを識別し、前記ファイヤウォール・ポリシーおよび前記セキュリティ・ポリシーを前記要求レイヤに返すことを特徴とする請求項３０に記載のコンピュータ可読媒体。
33. 前記要求レイヤは、キー入力モジュール・レイヤであり、前記マッチするフィルタ内の前記セキュリティ・ポリシーは、鍵ネゴシエーション・プロトコルに従ってセキュリティ・アソシエーションのネゴシエーションを行うためのポリシーを識別することを特徴とする請求項３２に記載のコンピュータ可読媒体。
34. レイヤ・プロセスでパケットに適用すべき複数のネットワーク・ポリシーを決定するためのコンピュータ実行可能命令を実行するためのコンピュータ可読媒体であって、
    前記レイヤ・プロセスにより、前記パケットに関連付けられている一組のパラメータを識別すること、
    前記レイヤ・プロセスにより、前記パケットに適用すべき前記ネットワーク・ポリシーを識別する、前記パケットに関連付けられている前記パラメータを含む、要求を送信すること、および
    前記レイヤ・プロセスで、第１のネットワーク・ポリシーを識別する第１のポリシー値と第２のネットワーク・ポリシーを識別する第２のポリシー値とを含む応答を受信すること
    を備えることを特徴とするコンピュータ可読媒体。
35. ネットワーク・デバイス内で複数のネットワーク・ポリシーを保持するコンピュータ実行可能命令を実行するためのコンピュータ可読媒体であって、
    一組のフィルタをポリシー・エンジンにインストールすること
    を備え、前記それぞれのフィルタは、
    １組のフィルタ条件と、
    第１のネットワーク・ポリシーを識別する第１のポリシー値と第２のネットワーク・ポリシーを識別する第２のポリシー値と
    を備えることを特徴とするコンピュータ可読媒体。
36. ポリシー・エンジンにより、前記複数のネットワーク・ポリシーが適用されるパケットにマッチするフィルタ条件を含むマッチするフィルタを前記一組のフィルタから識別すること、および
    前記パケットに対して少なくとも前記第１のネットワーク・ポリシーを実行すること
    を、さらに備えることを特徴とする請求項３５に記載のコンピュータ可読媒体。
37. 前記一組のフィルタ条件は、目的のポリシーに従ってフィルタ条件が追加または削除されるように動的に構成可能であることを特徴とする請求項３５に記載のコンピュータ可読媒体。
    

Images