(57)【特許請求の範囲】
【請求項１】
パケット内のデータ処理に基づいてセキュリティプロトコルを実行するためのデータ処理システムにおいて、
−  フィルタコード(304)を保存し、保存されたフィルタコードに従ってデータパケットを処理するためのパケット処理装置(301)と、
−  フィルタコードを作成し、作成されたフィルタコードを前記パケット処理手段に伝達するためのポリシー管理装置(305)と、で構成され、
ここで、前記パケット処理装置は、保存されたフィルタコードが所定のパケット処理に適用できるかどうか検査し(503、504、505)し、その処理に保存されたフィルタコードが適用できないようなパケットを前記ポリシー管理装置に伝達する(507)ように配置されており、前記ポリシー管理装置は、前記パケット処理装置からパケットを受け取ったことに対する応答として、
−  パケットの処理に適用できるフィルタコードを作成し、作成されたフィルタコードを前記パケット処理装置に伝達するか、
−  パケットを前記ポリシー管理装置によって処理するか、
−  パケットを前記ポリシー管理装置によって処理し、パケットの処理に適用できるフィルタコードを作成し、作成されたフィルタコードを前記パケット処理装置に伝達するか、
のいずれか一つを行う(508、509)ように配置されていることを特徴とする前記システム。
【請求項２】
請求項１に記載のデータ処理システムにおいて、さらに複数のポリシー規則を保存するためのポリシーデータベース(306)からなり、該ポリシーデータベースが前記ポリシー管理装置(305)の一部をなしている、ことを特徴とする前記システム。
【請求項３】
請求項２に記載のデータ処理システムにおいて、さらに、キー管理機能を前記セキュリティプロトコルに従って実行するためのキー管理装置(307)を有し、該キー管理装置は、前記ポリシー管理装置(305)と通信するように配置されていることを特徴とする前記システム。
【請求項４】
請求項３に記載のデータ処理システムにおいて、前記キー管理装置(307)及び前記ポリシー管理装置(305)は、通信を確実にするために、複数のセキュリティ・アソシエーションを前記ポリシー規則およびキー管理機能の特有のアプリケーションとして作成、維持するように配置されていることを特徴とする前記システム。
【請求項５】
請求項４に記載のデータ処理システムにおいて、前記ポリシー管理装置(305)は、前記ポリシー規則および前記セキュリティ・アソシエーションの中に含まれている情報をベースとしてフィルタコードを作成するように配置されていることを特徴とする前記システム。
【請求項６】
請求項５に記載のデータ処理システムにおいて、前記ポリシー管理装置(305)が、作成されたフィルタコードに加えて、前記セキュリティ・アソシエーションに関する情報を前記パケット処理装置(301)に伝達するように配置されており、前記パケット処理装置(301)は、パケットの暗号変換を行うように配置されており、かかる暗号変換が前記フィルタコードおよび前記セキュリティ・アソシエーションに関する情報をベースとして行われることを特徴とする前記システム。
【請求項７】
請求項６に記載のデータ処理システムにおいて、前記ポリシー管理装置(305)は、該ポリシー管理装置(305)に知られたセキュリティ・アソシエーションの一部分だけに関する情報を前記パケット処理装置(301)に伝達するように配置されていることを特徴とする前記システム。
【請求項８】
請求項７に記載のデータ処理システムにおいて、前記パケット処理装置(301)は、フィルタコード(304)を前記セキュリティ・アソシエーションに関する情報と別個に保存するように配置されていることを特徴とする前記システム。
【請求項９】
請求項１に記載のデータ処理システムにおいて、さらにその処理に前記セキュリティプロトコルが適用できるパケットを、パケットの全体の流れから分離させるためのパケット分断装置(303)からなり、該パケット分断装置(303)が前記パケット処理装置(301)と通信するように配置されていることを特徴とする前記システム。
【請求項１０】
請求項１に記載のデータ処理システムにおいて、さらに、カーネル・スペース(604)およびユーザモード・プロセス・スペース(605)からなり、前記パケット処理装置(301)は前記カーネル・スペース(604)の中にあり、前記ポリシー管理装置(305)は前記ユーザモード・プロセス・スペース(605)の中にあることを特徴とする前記システム。
【請求項１１】
請求項１に記載のデータ処理システムにおいて、さらに、カーネル・スペース(604)及びユーザモード・プロセス・スペース(605)からなり、前記パケット処理装置(301)及び前記ポリシー管理装置(305)が前記ユーザモード・プロセス・スペース(605)の中にあることを特徴とする前記システム。
【請求項１２】
請求項１に記載のデータ処理システムにおいて、さらに、少なくとも2つのネットワークインタフェース(651、652)からなり、前記パケット処理装置(301)は、各ネットワークインタフェース毎に別個のフィルタコードを保存するように配置されていることを特徴とする前記システム。
【請求項１３】
請求項１に記載のデータ処理システムにおいて、前記パケット処理装置(301)は、入パケットと出パケットを処理し、入パケットと出パケットの処理のために別個のフィルタコードを保存するように配置されていることを特徴とする前記システム。
【請求項１４】
請求項１に記載のデータ処理システムにおいて、前記フィルタコードが後向きのジャンプを包含しないことを特徴とする前記システム。
【請求項１５】
請求項１に記載のデータ処理システムにおいて、前記フィルタコードが、パケットをドロップさせ(504)、パケットを通過させ(505)、パケットをポリシー管理装置に引き渡す(507)動作を包含することを特徴とする前記システム。
【請求項１６】
請求項１５に記載のデータ処理システムにおいて、前記フィルタコードが、加えて、パケットに変換を施す(506)動作を包含することを特徴とする前記システム。
【請求項１７】
請求項１に記載のデータ処理システムにおいて、前記パケット処理装置(301)が、パケットをフラグメントの形で処理するように配置されており、そこで、前記フィルタコードを使ってパケットの最初のフラグメントを処理してから他のフラグメントを受け取り、最初のフラグメントに向けられた動作を使って該パケットの残りのフラグメントを別々に処理するようになっていることを特徴とする前記システム。
【請求項１８】
請求項１７に記載のデータ処理システムにおいて、前記フィルタコードが、1つのフラグメントを受け取ったことに対する応答として、パケットをまるごと1つ要求する命令を包含し、そのあと処理が続行できるようになっていることを特徴とする前記システム。
【請求項１９】
請求項１に記載のデータ処理システムにおいて、前記フィルタコードが、実際のコンパイルされたプロセッサ命令からなることを特徴とする前記システム。
【請求項２０】
パケット処理装置とポリシー管理装置とを備えるシステムにおける、パケットの形でのデータ処理に基づいてセキュリティプロトコルを実行するための方法であって、
a) 入力されたパケットに適用できるフィルタコードが前記パケット処理装置において保存されている場合に、前記パケットを前記フィルタコードに従って処理する(503)ステップと、
b) 前記パケットをドロップさせるのがよいかを判定する(504)ステップと、
c) 前記パケットを受け入れるのがよいかを判定する(505)ステップと、
d) 前記パケットが受け入れられなかった場合に、前記パケットをポリシー管理装置に通信する(507)ステップと、
e) 前記パケットをポリシー管理装置において処理し、前記パケットに適用できるフィルタコードを作成する(508)ステップと、
f) 作成されたフィルタコードを前記パケット処理装置に通信する(509)ステップと、
を含む、方法。
【発明の詳細な説明】
【０００１】
本発明は、パケット化されたディジタル情報を認証し、暗号化／解読するプロトコルを実行する分野に関するものである。
【０００２】
IPセキュリティプロトコル（IPSEC）は、IETF（Internet Engineering Task Force）によって標準化されてきており、公知で広く使用されているIPプロトコルにセキュリティを追加するものである。これは、2つの通信ネットワークノード間でトラフィックの暗号認証と機密保持を提供する。これはエンドツーエンドモード、すなわち、通信ノードまたは通信ホストの間で直接、又はファイアウォール若しくはVPN（Virtual Private Network）デバイス間のトンネルモードの両方で使用することができる。また、一方がホストで他端がファイアウォール又はVPNの非対称接続も可能である。
【０００３】
IPSECは、各パケットに新しいプロトコルヘッダを追加することによってパケットレベルの認証および暗号化を実行する1組の動作を規定する。データパケットのIPSEC認証は、データパケットの全データとヘッダのほとんどにわたって認証コードを計算することにより実行される。認証コードはさらに秘密鍵に依存し、それを通信当事者のみが知る。認証コードは、次にパケットの中に保存され、既定のヘッダまたはトレーラに適宜包み込まれたる。
【０００４】
各パケット上で実行される動作は、通信ホストの各ペア間でいずれの認証方法と暗号化方法（合わせて変換と呼ばれる）を適用すべきかを指定するポリシーによって制御される。暗号アルゴリズム、暗号キー、及び2つのホスト若しくはピア(peers)の間でパケットを安全に処理することに関する他のデータを指定するパラメータは、セキュリティ・アソシエーションと呼ばれる。
【０００５】
あるポリシーは、代表的には、各規則が適用される通信又は通信組を強要する1組のセレクタ（IP発信元アドレス、IP宛先アドレス、サブネット、プロトコル、発信元ポート番号、宛先ポート番号など）を指定する、1組のポリシー規則として表される。ある特定のパケットに複数の規則を適用し得るが、通常は規則に相互の順序があるため、各受信パケット及び発信パケットに対して一つの規則が明確に選択される。
【０００６】
IPSEC標準及び公開された実施態様はポリシーデータベースと呼ばれるデータ構造を提示しており、そこにはメモリ内にアレイ又はテーブルが存在し、規則が包含される。ポリシーデータベース内の規則は、処理すべきパケットごとに調べられる。図1は、公知のIPSEC実施態様100を図式化して描いており、ポリシーデータベース101を包含し、インターネット網103から安全な内部網102を分離している。簡単のため、一方向にのみ流れるパケット（発信パケット）を考える。図1の入力パケット104は、内部網102内のユーザがインターネットを通じて別のユーザに送るデータであって、認証と暗号化の処理が必要なデータを含んでいる。IPSECの実施態様においては、ポリシーデータベース101内の規則を調べることによって、対象となる入力パケット105が対象となる出力パケット106に変換される。変換された出力パケット107はインターネットに送出されて、その正規受信ユーザに適宜ルーチングされる。
【０００７】
一方、IPパケットをフィルタリングするための機構が利用可能となってきており、文献においては以前からよく知られていた。適当な機構を紹介しているのは、例えばJ. Mogul、R. Rashid、M. Accetta "The Packet Filter: An Efficient Mechanism for User-Level Network Code" In Proc. 11th Symposium on Operating Systems Principles, pp 39-51, 1987、及びJeffrey Mogul "Using screend to implement IP/TCP security policies" Digital Network Systems Laboratory, NSL Network Note NN-16, July 1991等である。パケットフィルタは、典型的には1組の明示的または暗示的な論理演算子の組みによって結合された１組の規則を有する。パケットフィルタの仕事は、あるパケットの次の処理を許容するか拒絶するかのいずれかである。
【０００８】
パケットフィルタで使用される論理規則は、データパケットの各フィールドの単純な比較形式を取る。有効なものとして、そのような比較にブール代数（論理、真値）式を評価するものがある。このような表現式を評価する方法は、何世紀もの間、数学文献中ではよく知られていた。評価を実行する機械読取り可能な命令セットは、伝統的にフィルタコードと呼ばれる。図2は、記憶されたフィルタコード201を持つパケットフィルタ200を示す。入力パケット202は、パケットフィルタ200において一時に一つのパケットが検査され、検査されたパケットだけが出力パケット203として渡され、これらはフィルタコードの論理規則が適用された時に正しいブール値を生成する。
【０００９】
パケットフィルタ表現式の個々の記述（比較）は、典型的にはオリジナルのデータパケットフォーマットにおいて又はパケットの各フィールドへのアクセスがより容易な拡張フォーマットからのいずれにおいても、データパケットの個々のフィールドにアクセスするためのオペランドを含む。固定レイアウト及び可変レイアウトデータ構造のデータ構造フィールドにアクセスする方法、及びデータを構造にパック又はアンパックする方法は、フォートラン、コボル、パスカルのような標準プログラミング言語において公知のものであり、1960年代からプログラミング技法として一般に使用されてきた。
【００１０】
ブール表現式を制御の実行に使用するアイデア及び試験としてのその使用は、両方とも全ての近代プログラミング言語のまさに基礎をなす部分であって、その技法は1950年代またはそれ以前からプログラミングにおける標準的な方法であった。
【００１１】
照会及び検索仕様を1組の規則または制約として表現することは、データベース、パターン照合、データ処理、及び人工知能において標準的な方法である。データサンプルに対する数組の規則を効率よく評価することを扱った雑誌、書籍、及び会議は幾つか存在する。これらの標準的技法は、データ通信網におけるパケットを含めて数多くの種類のデータパケットに適用可能である。
【００１２】
別の周知技術は、ブール表現式及び条件等のプログラミング言語表現をより高速に処理するために中間言語に翻訳することである（例えば、A. Aho、R. Sethi, J. Ullman "Compilers − Principles, Techniques, and Tools"、Addison-Wesley, 1986を参照）。このような中間コードは、例えばツリー、タプル、又はインタープリットバイトコード命令の形式等でもよい。このようなコードは、レジスタベース、メモリベース、又はスタックベース等の多様な方法で構成し得る。このようなコードは、メモリアロケーションを実行できてもできなくてもよく、メモリ管理は、分離アロケーション及びフリーな明示型でも、又はランタイムシステムが自動的に不要部分の整理を通してメモリを管理する暗示型でもよい。このようなコード操作は、周知のUNIXプログラム“grep”、および1960年代またはそれ以前の他の類似プログラムと同様に、アプリケーション間でステートレス (stateless)でもよい（個々の中間言語命令の間にはプログラムカウンタが必要であるというような何らかのステートは実行されるが）。また、コードは、周知のUNIXプログラム“passwd”、多くのデータベースプログラム、及び1960年代又はそれ以前の類似するアプリケーションと同様に、呼出しの間にステートを実行し得る。これは、1980年代初期の多くのApple IIゲームやより古い多くのアセンブリ言語プログラムのように自己修飾型 (self-modifying) でもあってもよい。さらに、このような中間表現を一層最適化するために直接実行可能な機械コードにコンパイルすることも可能である。上記の全ては、当該分野において広く知られており、数十年間大学のプログラミング言語課程やコンパイラ課程で教えられきた。また、最近の周知の研究は、プログラムのインクリメンタルコンパイル方法や、初めて必要とされる時にそのプログラム部分をコンパイルする方法を提示している。
【００１３】
大量のデータパケットのリアルタイム・フィルタリングは、データを操作するため使用される方法において最適化が必要であった。そのため、標準プログラミング言語コンパイル技術が規則セットの論理表現の解釈に適用され、その結果、オリジナルの規則セットよりも高速に評価可能な中間コードが作られた。BSD 4.3オペレーティングシステムに用いられるこれら周知方法の特別な使い方は、大学のオペレーティングシステム教材の中に述べられており、少なくとも1991年以降、多くの大学で学生にアクセスできるサンプルソースで入手できるようになった。
【００１４】
最近、ステートレス・フィルタリングおよびステートフル・フィルタリングの周知の方法について特許が出願され、米国特許第5 606 668号が付与された。“ステートレス・フィルタリング”は、主に周知のBSD 4.3パケットフィルタ（カリフォルニア大学バークレイ校が、1991年、例えばBSD 4.3 net2リリースにおいて著作権使用料無しで全世界に配給することを目的に公開した）であり、“ステートフル・フィルタリング”は、A. Aho, R. Sethi, 及びJ. Ullman（1987年、同上）が前掲書の401ページで「このプロパティは、ローカルネームの値をプロシージャのアクティブ化期間中ずっと保持できるようにする。すなわち、制御がプロシージャに戻った時、ローカルネームの値は制御が以前に終了した時の値と同じである。」と特徴づけられるものに加えられる。同書は多分、1980年代後半から1990年代初期にかけて大学のコンパイラ課程において最も人気のある教材であった。アイデアそのものは、数十年さかのぼる。
【００１５】
既知のIPSECの実行は、IPSEC実行中に伝送されるパケットごとにポリシーデータベースの調査が必要である。高速VPN（Virtual Private Network）の実行は、例えば、毎秒幾万パケットの処理が必要となる。このようなパケットに対してデータベースからポリシー規則を調べ上げていく処理のオーバヘッドは、直ちに性能のボトルネックになる。
【００１６】
IPSEC方法を実行するネットワークデバイスへ着信するパケットは、レギュラーパケットとノンレギュラーパケットに分類できる。両者の違いは以下に詳述する。本発明は、下記のタスクを適宜区分し、整理することにあり、
−  ポリシーデータベースを作成、維持すること、
−  ポリシーデータベースの中の情報に基づいて、パケットに適用すべきフィルタコードをコンパイルすること、
−  コンパイルされたフィルタコードを使ってレギュラーパケットからノンレギュラーパケットを分離し、レギュラーパケットをポテンシャル処理 (potentially processing)すること、
−  各ノンレギュラーパケットの発生に対するポテンシャル応答として、コンパイルされたフィルタコードの新しいピース (pieces) を作成すること、からなる。
【００１７】
本発明の新規な特徴は、特に付記された請求項の中に記述されている。但し、発明自体は、その構成、操作の方法、付加的な対象及び利点に関し、添付図面により示される特有の実施態様を用いた下記説明から最もよく理解されよう。
【００１８】
ネットワークデバイスにおいてIPSEC方法によりパケット変換を実行するため使用されるデバイスまたはプロセスは、一般に“IPSECパケット処理エンジン”または略して“IPSECエンジン”と呼ばれる。本発明によれば、着信パケット及び／又は発信パケットについて実行される操作は、一般にあるフィルタコードの手段によって表現されるが、IPSECポリシーアプリケーションのフィルタコードに対する要求は上記従来技術で説明した単純なパケットフィルタリングのケースよりもはるかに複雑である。既知のパケットフィルタは、単に着信パケットを許容可能なパケットと許容不可能なパケットとに分類する。IPSECエンジンは、セキュリティポリシーを処理する必要があり、そのセキュリティはセキュリティ・アソシエーションを起動し、着信パケットと発信パケットの間の変換を行なう。さらに、IPSECエンジンは、セキュリティ・アソシエーションの生成と終了を処理し、外部キーマネージャを調べる必要がある。
【００１９】
本発明において、コンパイルされたフィルタコードはIPSECエンジンの制御ロジックの中核を形成する。フィルタコードは、着信パケットと発信パケットの処理を制御し、データパケットに適用される変換アプリケーションを制御し、変換することなくドロップまたはパスすべきパケットについてポリシー決定を行なう。フィルタコードは、実際のポリシー決定を行い必要に応じて新しいコンパイルされたフィルタコードを作り出す別のポリシーマネージャと通信する。新しくコンパイルされたフィルタコードの必要性は、IPSECエンジンが既存のコンパイルされたフィルタコードによって処理できないパケットを受信した各時に潜在的に発生する。次に、ポリシーマネージャは、“トラブル”を生じたパケット及び同様の別のパケットに対してポリシーを実行する。
【００２０】
コンパイルされたフィルタコードは、最近なされたポリシー決定のキャッシュとして有効に働き、どんな新しい決定もより一般的なポリシーマネージャコードが参照される。これは、レギュラーパケットとノンレギュラーパケットとの間の違いを明らかにする。すなわち、レギュラーパケットは先に処理した何らかのパケットに十分類似してるため、IPSECエンジンがコンパイルされたフィルタコードを適用し得る。ノンレギュラーパケットは、IPSECエンジンに到着した最初の種類のものであるからコンパイルされたフィルタコードはこれを処理する十分な情報を含んでおらず、その結果ポリシーマネージャが調査され、新たなポリシー決定が行なう必要がある。このポリシー決定は、コンパイルされたフィルタコードの一部となる。本発明は、大量データの処理をきわめて効率的にし、しかも任意のキー管理プロトコルにより洗練されたユーザモード・ポリシーマネージャの十分なフレキシビリティを許容し、既知のパケットフィルタをもってしては実現不可能なその他の特徴を可能にする。また、フィルタコードは、システムを安全且つ堅牢にする上で重要な役割を有する。すなわち、フィルタコードは、大抵の場合に、ポリシーマネージャを調べることなく無効又は許容不可能なパケットをきわめて高速にドロップし無視することができる。これは、リソース消耗攻撃に対抗措置となる。また、フィルタコードは、変換のアプリケーションを密に制御し、それによりネストされた暗号化によるリソース攻撃も防止する。
【００２１】
堅牢性を高める付加的特徴は、不正なフィルタコードが如何様に作られた場合でも、フィルタコードが常に終了する仕方で設計されていることである。この特徴は、フィルタコードが特に最高性能を要求するオペレーティングシステム・カーネル環境で実行されるのに適したものとなる。確実な終了の詳細なプロシージャは、以下で詳細に述べる。
【００２２】
本発明の第1の実施例によるIPSEC実行300のコンポーネントは、図3にその概略が描かれている。IPSECエンジン301は、ブロック302によって一般的に表されたTCP/IPスタック及び／又はネットワークアダプタとインタフェースし、そこではIPSEC処理のためにIPパケットをIPSECエンジンに渡すパケット・インターセプタ303（前記のように既知である）を使用している。IPSECエンジン301は、既知のIPSEC文献中で一般に述べられているようなパケット上の暗号変換を選択し適用する等のパケット・パー・パケット (packet-per-packet) 処理を実行する。それは、また本発明で述べらるフィルタコード機構304を含む。別のポリシーマネージャ305は、許容可能な通信及び必要な認証について全ポリシーデータベース306を維持し、各パケットを如何に処理すべきかのポリシー決定を行なう。キーマネージャブロック307は、ポリシーマネージャ305と通信する別の機能エンティティであり、IPSEC認証及び／又は暗号化／解読のプロセスに必要とされる実際のキー交換を行う。キーマネージャブロック307は、その動作において、それ自体知られた何らかのプロトコル、例えばISAKMP/Oakleyプロトコルを使用してよい。ここで、ISAKMPは、インターネット・セキュリティ・アソシエーション・キー管理プロトコルを意味する。
【００２３】
図3のブロック図の異なるセクションは異なる性能を要求される。パケット・インターセプタ303は、IPパケットと他のプロトコルによるパケットの両方を含めて、ネットワーク内のどのパケットも潜在的に監視する。これは、他のパケットからIPパケットを分離し、それをIPSECエンジン301にそれがサポートする最高パケット速度で渡せることが必要である。IPSECエンジン301は、通常どのIPパケットも監視し、これらのパケットをサポートする最高パケット速度で処理できることが要求される。パケット・インターセプタ303及びIPSECエンジン301は、共に典型的にはIPSEC実行300が行われるコンピュータ化されたネットワークデバイスのオペレーティングシステム・カーネル308の中に存在する。これにより、通信コストが最小限に抑えられる。
【００２４】
ポリシーマネージャ305及びキーマネージャブロック307は、最高速度で処理するブロック303および301の動作よりも終了までに長時間を要するタスクを処理する。ポリシーマネージャ305によるポリシーデータベース306の代表的な検査には、数百の個別規則を吟味することが含まれるケースがあり、また適当なポリシーを求めるのに外部ホスト（図示なし）との通信が必要なケースもある。キーマネージャブロック307が行うキー交換は、しばしばポリシーデータベース検査よりも長くなり、幾つかのケースでは数秒以上である。ポリシーマネージャ305及びキーマネージャブロック307は、きわめて明確に規定されたリソース要件を持たないため、ネットワークデバイスのユーザモード・プロセス・スペース309においてそれらをユーザモード・プロセスとして実行するのが好ましい。
【００２５】
汎用コンピュータにおけるカーネルモード・プロセスとユーザモード・プロセスとの間の通信には、メッセージが渡される毎のデータコピーや実質的なオーバヘッドが含まれるため、かなり時間が浪費される。従って、そのような通信量の低減が望まれる。図3に示す本発明の実施例において、それはIPSECエンジン301とポリシーマネージャ305の間の通信量を減ずることを意味する。フィルタコード機構304はこの目的の提供される。なぜなら、ポリシー決定が一旦フィルタコード機構にコンパイルされたフィルタコード形式でセーブされると、そのフィルタコードで処理可能なレギュラーパケットは、さらにIPSECエンジン301及びポリシーマネージャ305間でメッセージを転送させることが無くなるからである。
【００２６】
IPSECエンジンをオペレーティングシステム・カーネルの代わりにユーザモードで実行することが可能であり、時にはそれが望ましい。しかしながら、応答時間要求がIPSECエンジンとポリシーマネージャとでは異なるため、それらを別個のスレッド又はプロセスで実行することも望ましい。これらによる通信オーバヘッドは、多かれ少なかれIPSECエンジンをオペレーティングシステム・カーネルで実行するのと同程度である。
【００２７】
本発明によるシステムが適切に作業する上で重要なのは、IPSECエンジンとポリシーマネージャとの間で作業分担が明確に規定されていることである。各データパケット毎に独立に実行する必要のある全てのパケット処理は、IPSECエンジンの側に置かれる。ノンレギュラーパケットがIPSECエンジンに入力された時、その処理に間するポリシー決定には、ポリシーマネージャが参照される。ポリシーマネージャは、IPSECエンジンがポリシーマネージャに代わって後続のレギュラーパケットに関して同様の決定を下せるようにするための情報をIPSECエンジンに送る。これは、ポリシーマネージャが新たな情報をIPSECエンジンに送るか、又は情報のどれかが終了するまで続く。例えば、代表的なTCP/IPセッションにおいて、各方向での最初のパケットはノンレギュラーパケットであり、ポリシーマネージャに渡される。ポリシーマネージャは、そこでそのパケットを検査し、そのポリシー規則を決定する。代表的なポリシーは、あるTCP/IPセッションの全てのパケットを同等に処理することを含み、従ってポリシーマネージャは、IPSECエンジンが同じTCP/IPセッションに属する後続のパケットをレギュラーパケットとして認識することを許容する情報をIPSECエンジンに送り、それによってパケットが処理される。後続のレギュラーパケットに関するルーチンポリシーの決定及びそれらの処理（例えば暗号化）の両方ともIPSECエンジンで行われる。IPSECエンジンは、暗号キーと、ポリシーマネージャから受信し又はポリシーマネージャを介してキーマネージャブロックから受信した他のデータと、を使ってパケットを変換する。
【００２８】
ルーチンポリシー決定の他に、パケット毎に実行する必要があるアクションも存在する。例えばセキュリティ・アソシエーションでは、そのセキュリティ・アソシエーションを使って伝送されるデータ量により規定される限定した生存期間 (lifetime) を有してもよく、これはすでに伝送されたデータ量を記録する必要があり、伝送はドロップされるか又は生存期間の満了後に新たなセキュリティ・アソシエーションの確立プロセスが開始される必要があること意味する。データ伝送統計はパケット毎に更新される必要がある。好適には、これら全てのアクションはIPSECエンジンによって実行される。
【００２９】
ポリシーマネージャがIPSECエンジンに送る情報には2種類ある。すなわち、セキュリティ・アソシエーション・パラメータと、コンパイルされたフィルタコードである。セキュリティ・アソシエーション・パラメータは、パケットにIPSEC変換（例えばAHまたはESP）を適用するのに必要とされる情報である。このパラメータには、暗号化キー、認証キー、初期化ベクトル、応答防止カウンタ、トンネル情報、及び変換をパラメータ化するのに必要となる他の如何なるデータも含まれる。一方、コンパイルされたフィルタコードは、セキュリティポリシーのいくつかの側面を表現する実行可能な（または解釈可能な）情報である。
【００３０】
図4は、セキュリティ・アソシエーションにおいて保存すべき主要データ項目を表形式で示している。セル401はセキュリティ・アソシエーションを強要するセレクタを含む。セル402はセキュリティ・アソシエーションに属するパケットに適用すべき変換を識別し、セル403は変換に必要となるキーマテリアルを含む。セル404は伝送に対する応答防止データを含み、セル405は伝送されたバイト数を指示する。セル406はセキュリティ・アソシエーションの満了時期及びデータ転送リミットを含み。
【００３１】
セキュリティ・アソシエーション・パラメータは、通常セキュリティ・アソシエーションが各々異なる暗号化キー及び認証キーを有するため、セキュリティ・アソシエーション毎に別々にIPSECエンジンに保存される必要がある。一方、フィルタコードは、通常着信パケット及び発信パケットに別のコードを付して各ネットワークインタフェースに別々に保存される。その理由は、コードをインタフェース毎に別々に保存することによって、敵対的なアタッカーがパケットを実際のと異なるインタフェースから届いたかのように見せかける可能性を無くすことにある。さらに、フィルタコードにおけるコードパスはこれによって短縮され、実行速度が向上する。
【００３２】
IPSECエンジン内の情報は、実際には、ポリシーマネージャ内に保存される情報に対するキャッシュとして働く。換言すれば、ポリシーマネージャはアクティブ状態のセキュリティ・アソシエーションに関する権威的情報を有する。それは、自身の裁量でそのデータのどれかをIPSECエンジンに送り、且つフィルタコードを作成することができ、このフィルタコードにおいてセキュリティ・アソシエーションのためのパケットが処理され、そして他の使用頻度の低いアソシエーションのためのパケットがポリシーマネージャに渡される。その結果、ポリシーマネージャは、パケットの再処理の前にIPSECエンジンにおいてそのパケットに必要なフィルタコード及びアソシエーションをインストール可能となる。これは、IPSECエンジンにおける固定メモリ割当てを可能とし、それによってオペレーティングシステム・カーネルに対するリソース消耗攻撃が不可能となる。また、フィルタコードは、ある種類のパケットを拒否し、許容できないパケット処理をショートカットするという事実をキャッシュできる。
【００３３】
本発明による方法の単純な一実施例を図5にフローチャートとして示す。ブロック501および502は、図3のパケット・インターセプタ303の動作に対応する。すなわち、IPパケットだけがIPSECエンジンに到達できるようにする。ブロック503〜507は、IPSECエンジンで行われる動作を説明している。ブロック503において、IPSECエンジンは、先に保存したフィルタコードを適用する。ブロック503においてフィルタコードを適用することの中に、パケットの変換を行うことが含まれてもよいが、これは、本発明の請求するところではない。フィルタコードの適用の間、IPSECエンジンの中に保存された情報が、セキュリティ・アソシエーションの生存期間の満了時期まで有効であるかどうかもチェックされる。パケットがレギュラーパケットであれば、IPSECエンジンは、そのパケットをブロック504に従ってドロップさせるのがよいのか、又はブロック505に従ってそれを受け入れるのがよいかを知っている。受け入れた場合には、その受け入れらたパケットは、ブロック506に従って出力される。フィルタコードの適用中にパケットの変換または別の仕方でのパケットの処理を行うことが含まれていた場合、ブロック506は処理されたパケットの出力動作に対応する。ブロック505における答がノーの場合には、パケットはノンレギュラーパケットであって、ブロック507に従って検査を行うために、さらにブロック508に従ってポリシー規則を決めるためにポリシーマネージャに転送される。その結果生じた新しいポリシー決定は、ブロック509においてIPSECエンジン中にコンパイルされたフィルタコードの形式で保存され、その動作はブロック503から続行される。ブロック508および509に向かったパケットは、新たに保存されコンパイルされたフィルタコードが、パケットをどのように処理すべきかについての情報を含んでいるため、これによりレギュラーパケットになる。
【００３４】
また、ポリシーマネージャは、受け取ったノンレギュラーパケットを、新しいフィルタコードのコンパイルとそのIPSECエンジンへの通信を受け持つ代替パケットとして自ら処理してもよい。ポリシーマネージャの設計者は、どんな種類のノンレギュラーパケットに新しいフィルタコードをコンパイルさせる価値があるか、又はどんな種類のパケットがポリシーマネージャで処理されるのに最も有利であるか、等を自ら決定してもよい。加えて、ポリシーマネージャは、受け取ったノンレギュラーパケットを自ら処理し、新しいフィルタコードをコンパイルし、これを以降の同様のパケット処理のためにIPSECエンジンに伝送してもよい。最後に受け取った代替パケットがキー管理パケットであれば特に有用である。
【００３５】
先に述べた通り、フィルタコードは、オペレーティングシステム・カーネル内に保存されるのが最も有利である。それは素早く実行できる単純な動作からなる。例えば、フィルタコード動作は、パケットヘッダの1つのフィールドを既知の値と比較し、比較の結果に基づいてそれを分岐させ、複数の選択肢の中から最適な値を選択し、パケットに変換を適用し、パケットをドロップさせ、パケットをその現にある形で通過させ、パケットをさらに考慮できるようにポリシーマネージャに渡す工程を含む。本発明によるフィルタコードは、従って、ブール表現式を評価する伝統的考え方を一般化したものといえる。
【００３６】
本発明の優先実施例におけるフィルタコードは、有益な特徴をいくつか有する。すなわち、
−  リニアバイトコードであり、メモリバッファまたはアレイの中に容易に保存し、巡回させることができることを意味する。
−  バイトコードの中のジャンパがすべて前向きであり、これは、フィルタコードがどんな場合でも必ず終わりまで進むことを意味する。インタープリタをきわめて堅牢にすることは簡単である。
−  フィルタコードの中にループがない。例えば、互いの内部で2回変換を施さなければならない場合、最初の変換の後に許容値を処理するために別個のフィルタコードが作成される。これで、同じセキュリティ・アソシエーションを使用する重層的な暗号化によるリソース消耗攻撃は防止されることになる。
【００３７】
また、パケットをフラグメント化した形で処理するのが望ましいという事情もある。例えば、パケットをトンネルモードの変換（AHまたはESP）の中でトンネル処理しなければならない場合に、パケットを組み立てし直してから変換を施すのでなく、代わりにフラグメントごとに別々にトンネル変換を施すのが望ましいということがあり得る。
【００３８】
IPSECエンジンの中のフィルタコードは、この目的にも使用できる。パケットの最初のフラグメントが受け取られたら直ちに、このフラグメントにフィルタコードを適用することができる。パケットがまるごと1つ必要とされる場合には、特殊なフィルタコード命令を使って処理を中断することができる。この命令は、実際にパケットをまるごと1つ必要とするフィルタコードのコードパスにおいて使用することができる。個々のフラグメントを処理する（例えば、各フラグメントにトンネル変換を施し、それを無修正のまま通過させ、またはドロップさせることによって）ことのできるコードパスは、この命令を包含せず、常に最初のフラグメントにはめ込むことが保証されているパケットヘッダの部分をアクセスするだけである。情報は、そこで、同じパケットの他のフラグメントが最初のフラグメントの場合と同じ方法で処理されるようにフィルタコードの外でセーブされる。
【００３９】
また、ここに述べたフィルタコードは、ポリシーマネージャによって直接実行可能な機械コードにコンパイルし、それにより実際の実行可能なプロセッサ命令がIPSECエンジンに送られるようにすることもできる。
【００４０】
実行可能なプログラムに最適化を施す多くの方法が、プログラミング言語やコンパイラの文献からよく知られており、本発明のフィルタコードに、他の表現形式のプログラムに対してと同様うまく適用されるが、ここでは説明しなかった。規則のセットから中間コードを作成する方法も、文献の中で広く展開されており、当業者にはよく知られている。
【００４１】
本発明を、その主要な内容を変えることなく、図3に示すのとまったく異なる形で実現させることが可能であることは、当業者によく知られている。例えば、IPSECエンジンとポリシーマネージャを同じモジュールの中に混在する形で実現させること又はポリシーマネージャをキーマネージャの上に構築することも可能である。
【００４２】
以上、本発明をIPSECプロトコルのコンテキストの中で述べてきたが、これは、データをパケットレベルで解読する他の暗号セキュリティプロトコルにも適用可能である。その場合には、もちろん、本文中におけるIPSEC関連の全ての定義を当該のセキュリティプロトコルにおける対応する定義に変えなければならない。
【００４３】
図6aおよび6bは、本発明を実地に移すのに使用できるデータ処理システム600およびゲートウェイデバイス650を示す。図6aのシステム600は、ネットワーク602に接続するためのTCP/IPアダプタ601を有する。マイクロプロセッサ603が、TCP／IPアダプタ601を使って情報をネットワーク602経由で送受信する。マイクロプロセッサ603は、使用中のオペレーティングシステム・カーネルを保存するためのコアメモリ604と、これより大きい、ユーザモードプロセスを実行するための別個の記憶装置605を有する。メモリブロック604および605は、単一のメモリ回路の一部をなす形であってよい。あるいは、少なくとも一方および／または他方のメモリブロックの一部分がマイクロプロセッサ603と同じチップの上に位置していてよい。不揮発性マスメモリ606も、プログラムおよびデータを保存するために内蔵されている。図3の構成を採用するとすれば、パケット・インターセプタとIPSECエンジンは、オペレーティングシステム・カーネルの残りとともにコアメモリ604の中にあり、図3のポリシーマネージャとキーマネージャは、その動作に必要な記憶装置605を使用する。
【００４４】
ゲートウェイデバイス650は、2つのネットワークアダプタ651および652 − 1つは内部ネットワーク653接続用、もう1つは汎用データ転送ネットワーク654接続用 − を包含することを除けば、データ処理システム600と同様である。ゲートウェイデバイス650は、構内ネットワーク653を汎用データ転送ネットワーク654で生じる攻撃要因から守るIPSECセキュリティ機能を実行するのに使用される。
【００４５】
図6aおよび6bのデバイスは、もちろん、単に例として示されているだけであり、本発明を制限するものではない。データ処理システム600およびゲートウェイデバイス650は、図6aおよび6bに示された以外の部品を包含してよい。
【図面の簡単な説明】
【図１】  図１は、既知のIPSEC実行を示す。
【図２】  図２は、既知のパケットフィルタを示す。
【図３】  図３は、本発明の有利な一実施例を示す。
【図４】  図４は、本発明に従って保存された情報の詳細を示す。
【図５】  図５は、本発明による方法のフローチャート表現である。
【図６ａ】  図６ａは、本発明のいくつかの実施態様を示す。
【図６ｂ】  図６ｂは、本発明のいくつかの実施態様を示す。
【図１】
0004771390.tif 000002
【図２】
0004771390.tif 000003
【図３】
0004771390.tif 000004
【図４】
0004771390.tif 000005
【図５】
0004771390.tif 000006
【図６ａ】
0004771390.tif 000007
【図６ｂ】
0004771390.tif 000008