JP4162210B2

JP4162210B2 - セッション追跡を利用する動的パケットフィルター

Info

Publication number: JP4162210B2
Application number: JP2002588042A
Authority: JP
Inventors: ローネン・ゴールドバーグ; ガディー・ダニエリー; モシェ・ゼザック; ドゥロリー・ショハット
Original assignee: テレコム・イタリア・エッセ・ピー・アー
Priority date: 2001-05-09
Filing date: 2002-05-10
Publication date: 2008-10-08
Anticipated expiration: 2022-05-10
Also published as: US6816455B2; US20040013112A1; DE60224177D1; WO2002091700A3; AU2002302873A1; KR20040008171A; ES2302809T3; DE60224177T2; EP1386464A2; JP2004538678A; CN1518823A; BR0209463A; EP1386464B1; CA2445751A1; BRPI0209463B1; CN100550889C; KR100876935B1; WO2002091700A2; CA2445751C; ATE381839T1

Description

発明の分野
本発明は、一般にデータ通信システムに関し、特に、セッション追跡を利用してパケットを許可するか拒否するか（許否）について決定する動的パケットフィルターに関する。

発明の背景
近年、世界はインターネットの爆発的な成長を経験した。ユーザーの数が限りなく増えつつあるように見える間にも、年を追ってはるかに多くのホストが加えらている。インターネットは、リモート・コンピュータ・ログイン、ファイル転送、ワールド・ワイド・ウエブ（ＷＷＷ）ブラウジング、電子メールなどを含めて、異なる技術を用いた通信を可能にする。様々な種類の通信に対処するために、種々のプロトコルが作られてインターネット上で使用されている。例えば、ファイル転送のためのファイル転送プロトコル（ＦＴＰ）、ウエブトラヒックのためのハイパーテキスト・マークアップ言語（ＨＴＭＬ）などがある。一般に、インターネット通信に関係したプロトコルは、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）一式の傘下で分類される。ＴＣＰ／ＩＰ一式は、ＯＳＩ通信スタックの種々のレイヤのプロトコルを含んだプロトコルからなる。

インターネットの重要な特徴は、それがコンピュータと電話回線とインターネット・サービス・プロバイダー（ＩＳＰ）アカウントを持っているほとんど誰でもアクセスできる公衆ネットワークであることである。この幅広い規模での公衆のアクセス可能性のマイナス面は、インターネット上の１以上のホストに対する悪意ある活動を企んでいるハッカーやその他の者の容易なアクセスを許してしまうことである。悪意あるユーザーによる機密情報の盗み取りや重要なファイルの消去などの違法行為は、リモートネットワークのコンピュータになんとか侵入して通信データを引き出すことに成功するハッカーによれば可能である。安全性の要求は、インターネットを介しての確実なトランザクションを可能にするＩＰｖ６における暗号化や認証などのセキュリティ機構を含ませることにより対処すべく、インターネット・アーキテクチャ委員会（ＩＡＢ）によって取り組まれた。

ハッカーの脅威と闘いプライベート・ネットワークを守るために、今日では、会社や組織内のプライベート・ネットワークの入口にファイアウォールを配置するのが一般的である。このファイアウォールは、ユーザー定義のセキュリティ・ポリシーを強化するよう機能する何らかの形態のパケットフィルターを用いる。ファイアウォールは、組織のローカル・ネットワークと全世界的なインターネットとの間の境界に存在するシステムである。このファイアウォールは、外部のネットワークへの情報の漏出を防ぎ、外部から内部のネットワークへの無許可のアクセスを防止するために、すべてのデータ通信のフィルタリングを実施する。

同時に、世界は、無線サービス（すなわち携帯電話、双方向ポケットベル、コードレス装置など）やパーソナルコンピュータ装置（ノート型パソコン、ＰＤＡなど）に対する増大する需要に直面している。これらのパーソナルコンピュータ装置の多くは、無線ネットワーク（例えば携帯電話又は他のブロードバンドの機構）を介してインターネットなどのＷＡＮネットワークとの通信を可能にするために、無線通信回路を組み込んでいる。このようにして、ますます多くのＰＤＡや携帯電話がインターネットに接続されつつあり、よってこれらの装置は安全性についての危険にさらされている。好ましくは、これらの装置は、該装置への無許可のアクセスに対して保護すべく何らかの種類のファイアウォールを使用する。しかしながら、今日たいていのファイアウォールは、ソフトウエアにて実現されており、デスクトップコンピュータ全体のコンピューティング資源を必要とし、携帯電話やＰＤＡなどの携帯式のコンピュータ装置におけるファイアウォールの使用は実際的でなくなっている。

従って、携帯電話や無線接続されるＰＤＡなどの小型の携帯式コンピュータ装置に組み込むのに適当な小サイズにて容易に実現し得るファイアウォール又はパケットフィルターが必要とされる。

発明の概要
本発明は、ハードウエア、ソフトウエア又はその両方の組合わせにて実現し得る新規かつ有用な動的パケットフィルターを提供する。本発明は、インターネットへの接続に適応した携帯電話や無線接続ＰＤＡなどのような携帯式コンピュータ装置において使用するのに適したハードウエアベースのファイアウォールに組み込むことができる。

本発明は、入力パケットストリーム上で受信したパケットに対して動的なパケットフィルタリングを行う。好ましくは、本発明は、ＷＡＮ（すなわちインターネット）とローカルＬＡＮの間に配置される。この場合、動的パケットフィルターは、ＷＡＮからＬＡＮに入ってくるパケットとＬＡＮからＷＡＮに出て行くパケットの両方に対してフィルタリングするよう機能する。動的フィルタリングは、プロトコルの静的規則よりもむしろ動的なプロトコル挙動をチェックするのに効果的であることに留意されたい。本発明は、セッションを作ってソースと宛先の間の通信状態を追跡することによってこのことを達成する。

新しいセッションが検出され、作られ、そしてそれに関係したデータがセッションデータベースに記憶される。受信した各パケットを認識し、それを前に開かれたセッションに関連付ける試みがなされる。セッションの認識は、ハッシュテーブルを用いてセッションデータベース中の対応するセッションレコードを迅速に決めることによって加速される。ハッシュテーブルは、完全な又は部分的なソケット情報のどちらかを用いて計算し得る。完全なソケット情報は、１０４ビットのソース及び宛先ＩＰアドレス、ソース及び宛先ポート番号並びにプロトコルを含む。部分的なソケット情報（ホールと称する）は、１以上の情報項目を欠いている。ホールデータベースは、現在開かれているホールを記憶するのに用いられる。一旦ホールセッションが認識されたなら、ホールには欠落パラメータが入れられる。

何も見つからなければ、新しいセッションが作られる。もし既存のものが見つかれば、そのセッションに関係するデータがセッションデータベースから読み出され、受信されたパケットが規則セットに基づいてチェックされる。これらの規則は、特定のプロトコルにより許可された状態と遷移を規定する状態遷移図として記載される。

もしパケットがプロトコルの正当な挙動に従っているなら、許可され、そうでなければ拒否される。次に、セッションデータが新しい状態情報と関連パラメータとによって更新され、セッションデータベース中の元の位置に書き込まれる。

本発明はハードウエアでの実現を意図したものではあるが、ソフトウエアにて実現することもできる。実施態様の一つでは、プロセッサ、メモリなどを備えたコンピュータが、本発明の動的パケットフィルタリング法の実行に適応したソフトウエアを実施すべく機能する。

従って、本発明により、各セッションがソケットに対応している複数のセッションに対して、セッションに関係したデータを記憶するセッションデータベースを設けるステップ；前記セッションデータベースに前に記憶されていないソケットを受信すると、新しいセッションを開くステップ；受信パケットに関連したセッションをその関連ソケットに従って認識するステップ；前記受信パケットに対応したセッションデータを複数の所定規則に従って処理して処理結果を生成するステップ；及び前記処理結果に従って前記受信パケットを許可するか又は拒否するかを決定するステップを含む、入力パケットストリームのフィルタリング方法が提供される。

また、本発明により、通信セッションの状態をモニターする方法であって、各セッションがソケットに対応した複数のセッションに対して、セッションに関係するデータを記憶するセッションデータベースを設けるステップ；受信パケットに関連したソケットについての第１ハッシュ計算に従ってセッションを認識するステップ；前記受信パケットに関連した部分ソケットについての第２ハッシュ計算に従ってホールセッションを認識するステップ；認識されたセッションか又は認識されたホールセッションのどちらかに関連した前記セッションデータを前記セッションデータベースから読み出すステップ；前記セッションの接続状態を追跡し、複数の規則に基づいて前記状態をチェックして前記受信パケットの許否を決定するステップ；及び更新されたセッションデータを前記セッションデータベースの元の位置に書き込むステップを含む前記方法が提供される。

さらに、本発明により、各セッションがソケットに対応した複数のセッションに対して、セッションに関係したデータを記憶するセッションデータベース；前記セッションデータベースにおいて関連ソケットが受信パケットのソケットと一致するセッションをサーチするセッション認識モジュール；前記セッションデータベースにおけるセッションの追加、削除及び修正を含めて、前記セッションデータベースを維持するセッション管理モジュール；及び受信パケットに対応したセッションの接続状態を追跡し、複数の規則に基づいて前記接続状態をチェックして前記受信パケットの許否を決定する機能を有する主フィルターモジュールを備えた、入力パケットストリームをフィルタリングするための動的フィルターが提供される。

また、本発明により、デジタルコンピュータ装置であって、前記装置を広域ネットワーク（ＷＡＮ）に接続する通信手段；揮発性メモリと１以上のアプリケーションプログラムを記憶するのに適応した不揮発性メモリとを含んだメモリ手段；前記１以上のアプリケーションプログラムを実行するために前記メモリ手段と前記通信手段に接続されたプロセッサ；及び入力パケットストリームをフィルタリングするための動的フィルターを備え、該動的フィルターが、各セッションがソケットに対応した複数のセッションに対して、セッションに関係したデータを記憶するセッションデータベース；前記セッションデータベースにおいて、関連ソケットが受信パケットのソケットに一致するセッションをサーチするセッション認識モジュール；前記セッションデータベースにおけるセッションの追加、削除及び変更を含めて前記セッションデータベースを維持するセッション管理モジュール；及び受信パケットに対応するセッションの接続状態を追跡し、複数の規則に基づいて前記接続状態をチェックして前記受信パケットの許否を決定する機能を有する主フィルターモジュールを備える前記デジタルコンピュータ装置が提供される。

さらにまた、本発明により、コンピュータ読出し可能な記憶媒体であって、その上に具現化されたコンピュータプログラムを有し、適切にプログラミングされたシステムに複数のストリングをサーチさせ、該サーチは、前記プログラムが前記システム上にて実行される際に以下のステップ、すなわち各セッションがソケットに対応した複数のセッションに対して、セッションに関係したデータを記憶するセッションデータベースを設けるステップ；前記セッションデータベース中に前に記憶されていないソケットを受信すると新しいセッションを開くステップ；受信パケットに関連したセッションをその関連ソケットに従って認識するステップ；前記受信パケットに対応したセッションデータを複数の所定規則に従って処理して処理結果を生成するステップ；及び前記処理結果に従って前記受信パケットの許否を決定するステップを実施することにより行われる前記コンピュータ読出し可能な記憶媒体が提供される。

図面の簡単な説明
ここでは、単なる例として添付図面に関して本発明を説明する。
図１は、ＷＡＮ又はインターネットとの関連において本発明の動的パケットフィルターのいくつかの適用例を示すブロック図であり；
図２は、本発明の動的パケットフィルターをさらに詳細に示したブロック図であり；
図３は、本発明の主フィルタープロセッサ法を示すフローチャートであり；
図４は、一致が見つかった場合の本発明の主フィルタープロセッサ法を示す状態遷移図であり；
図５は、一致が見つからなかった場合の本発明の主フィルタープロセッサ法を示す状態遷移図であり；
図６は、入力パケットに関連したセッションを決めるハッシング技術を示す図であり；
図７は、本発明のセッション認識プロセスのハッシング方法を示すフローチャートであり；
図８は、本発明のセッション認識プロセスのホールサーチ方法を示すフローチャートであり；
図９は、ＴＣＰセッションのパケットフローを示す図であり；
図１０は、ＴＣＰセッションを開く際の３−ウエイハンドシェイクを示す状態遷移図であり；
図１１Ａと図１１Ｂは、ＴＣＰセッションを閉じる際の４−ウエイハンドシェイクを示す状態遷移図であり；
図１２は、ＡＲＰセッションのパケットフローを示す図であり；
図１３は、ＩＣＭＰエコーセッションのパケットフローを示す図であり；
図１４は、ＩＣＭＰメッセージ／エラーセッションのパケットフローを示す図であり；
図１５は、主フィルタープロセッサによる規則のチェック中に行われるシーケンス番号のウインドウ追跡を示す図であり；
図１６は、主フィルタープロセッサによる規則チェック中に行われる肯定応答シーケンス番号のウインドウ追跡を示す図であり；
図１７は、セッションの古さを追跡するのに用いられる最長時間未使用のリンクリスト構造を示す図であり；
図１８は、入力パケットに関連したセッションを認識したときＬＲＵリンクリストを更新する方法を示すフローチャートであり；
図１９は、本発明のセッション管理モジュールの処理を示すフローチャートであり；
図２０は、セッションを開くために本発明のセッション管理モジュールにより実行される処理を示すフローチャートであり；
図２１は、セッションを閉じるために本発明のセッション管理モジュールにより実行される処理を示すフローチャートであり；
図２２は、セッションに対するファミリーポインタを示す図であり；
図２３は、複数のセッション間のファミリー関係の例を示す図であり；
図２４は、本発明のセッション追跡方法を用いて動的パケットフィルタリングを実行するのに適応したプラットフォームに対するコンピュータ処理システムの例を示すブロック図である。

発明の詳細な説明
全体を通して用いられる表記
この文書全体を通して以下の表記を用いる。

用語定義

ＡＤＳＬ非対称デジタル加入者回線
ＡＲＰアドレス絞り込みプロトコル
ＡＳＩＣ特定用途向け集積回路
ＣＰＵ中央演算処理装置
ＤＡＴデジタルオーディオテープ
ＤＳＬデジタル加入者回線
ＤＳＰデジタル・シグナル・プロセッサ
ＤＶＤデジタル多用途ディスク
ＥＥＰＲＯＭ電気的消去・プログラム可能型読取専用メモリ
ＥＥＲＯＭ電気的消去・書込み可能ＰＲＯＭ
ＥＰＲＯＭ消去可能プログラム可能読取専用メモリ
ＦＰＧＡフィールド・プログラマブル・ゲート・アレイ
ＦＴＰファイル転送プロトコル
ＨＤＳＬ高ビットレート・デジタル加入者回線
ＨＴＭＬハイパーテキスト・マークアップ言語
ＩＡＢインターネット・アーキテクチャ委員会
ＩＣＭＰインターネット・コントロール・メッセージ・プロトコル
ＩＰインターネット・プロトコル
ＩＳＰインターネット・サービス・プロバイダ
ＬＡＮローカルエリア・ネットワーク
ＬＲＵ最長時間未使用(Least Recently Used)
ＮＩＣネットワーク・インターフェース・カード
ＯＳＩ開放型システム間相互接続
ＰＣパーソナル・コンピュータ
ＰＤＡパーソナル・デジタル・アシスタント
ＰＤＵプロトコル・データ・ユニット
ＲＡＭランダムアクセスメモリ
ＲＯＭ読み出し専用メモリ
ＴＣＰ伝送制御プロトコル
ＵＤＰユーザー・データグラム・プロトコル
ＶＤＳＬ超高ビットレート・デジタル加入者回線
ＷＡＮ広域ネットワーク
ＷＷＷワールドワイドウエブ

発明の詳細な説明
本発明は、ハードウエア、ソフトウエア、又はその両方の組合わせにて実現し得る新規かつ有用な動的パケットフィルターを提供する。本発明は、インターネットへの接続に適応した携帯電話や無線接続ＰＤＡなどの携帯型コンピュータ装置において使用するのに適したハードウエアベースのファイアウォールに組み込むことができる。

本発明は、入力パケットストリーム上にて受信したパケットに対して動的なパケットフィルタリングを実施する。好ましくは、本発明はＷＡＮ（すなわちインターネット）とローカルのＬＡＮとの間に配置される。この場合、動的パケットフィルターは、ＷＡＮからＬＡＮに入ってくるパケットとＬＡＮからＷＡＮに出ていくパケットの両方をフィルタリングするよう機能する。動的フィルタリングはプロトコルの静的規則よりもむしろ動的なプロトコル挙動をチェックするのに効果的であることに留意されたい。本発明は、セッションを作ってソースと宛先との間の通信状態を追跡することによってこのことを達成する。

入力ストリームは、特定の用途に従った任意のタイプの入力データ、例えばフレーム、パケット、バイト、ＰＤＵなどを含み得る。説明のためにのみ、入力データストリームを一連のパケットとして考える。

示された動的パケットフィルターは例としてのみ提示されており、本発明の範囲を限定する意図ではないことに留意されたい。電気技術における熟達者ならば、ここに記載の本発明の範囲を逸脱することなく本発明の原理を用いて動的パケットフィルタリングを行うために、ハードウエア、ソフトウエア、又はその両方の組合わせにて他の動的パケットフィルターを構成することが可能である。

本発明の動的フィルターは、通信セッションの状態をモニターするためにセッションデータベースと称される接続テーブルを維持すべく機能する。新しいセッションは、静的なセキュリティ・ポリシー規則をパスした場合にセッションデータベースに加えられる。一旦セッションが作られると、このセッションに対応する後続のパケットが、当該パケットに関連した特定のプロトコルに対するセッション状態に従って検査される。当該パケットが特定プロトコルの規格に合っているときにのみ、当該パケットが許可される。

本発明の動的フィルターは、多くの異なるタイプのシステムにおいて幅広い用途を有する。図１には、ＷＡＮ又はインターネットに関連して、本発明の動的パケットフィルターのいくつかの用途例を示すブロック図が示される。ここに図示された３例の各々に示されているように、一般に動的フィルターは、保護されたネットワークへの無許可アクセスを防ぐために用いられるファイアウォールの一部として構成される。

第１の例では、動的フィルター１６は、ファイアウォール１４における１つのコンポーネントであり、このファイアウォール１４が、ＷＡＮ又はインターネットなどのネットワーク１０と有線又は無線通信する何らかの形態のパーソナルコンピュータ装置１２内にて実現される。このパーソナルコンピュータ装置は、パーソナル・デジタル・アシスタント（ＰＤＡ）、例えばパーム・ハンドヘルド(Palm handheld) 、携帯電話、無線受話器(wireless handset)などのような任意の装置でよい。この例では、動的フィルター／ファイアウォールは、インターネットと該装置との間でパケットを双方向的にフィルタリングする機能を有する。

第２の例では、動的フィルター２２は、ファイアウォール２０における１つのコンポーネントであり、このファイアウォール２０が、ＷＡＮ又はインターネットと有線又は無線通信するケーブル・プラグ・アダプタ１８内にて実現される。この装置１８は、インターネットと、ＬＡＮ２６をインターネットに接続する機能を有するブロードバンドモデム２４との間に置かれる。ケーブル・プラグ・アダプタ中の動的フィルターは、インターネットからＬＡＮ及びその逆に送られたパケットをフィルタリングする機能を有する。ブロードバンドモデムは、ｘＤＳＬ（例えばＡＤＳＬ、ＨＤＳＬ、ＶＤＳＬなど）、衛星、地上ベースのＲＦ、マイクロ波などのようなブロードバンド信号を変調及び復調する。

第３の例では、動的フィルター３０は、ファイアウォール２８における１つのコンポーネントであり、このファイアウォール２８が、ＷＡＮ又はインターネットと有線又は無線通信するスタンドアローンのコンピュータ３１、例えばパーソナルコンピュータ（ＰＣ）上にて実現される。ファイアウォールを含んだこのコンピュータは、インターネットと保護すべきＬＡＮ３２との間に配置される。ファイアウォールにおける動的フィルターは、インターネットからＬＡＮ及びその逆に送られるパケットをフィルタリングする機能を有する。

以下、動的フィルターを詳細に説明する。図２は、本発明の動的フィルターをさらに詳しく示したブロック図である。一般に符号４０で示された動的フィルターは、バス・インターフェース４８、バッファ／レジスタ５０、セッション認識モジュール５２、主フィルター処理モジュール５４、セッション管理モジュール５６、ハッシュテーブル６０、ホールテーブル６２及びセッションデータベース６４を備える。動的フィルターは、バス・インターフェースを介してバス４７上にてホスト装置／ＣＰＵ４２、ヘッダー復号器４６、静的フィルター５１、及びコンテンツ・サーチ・ユニット５３と通信する。

この文書全体を通して、動的フィルターがＷＡＮとＬＡＮの間に配置され、両方向にてパケットをフィルタリングする機能を有することに留意すべきである。入ってくるパケットとは、ＷＡＮからＬＡＮに向けて受信されたパケットをいい、出ていくパケットとは、ＬＡＮからＷＡＮに向けて受信されたパケットをいう。よって、入力パケットストリームは、入ってくるパケットと出ていくパケットとを含み得る。

入力パケットストリーム４４がＣＰＵから受信され、その内容がヘッダー復号器に送られる。ヘッダー復号器は、パケットのヘッダー部分を復号（又は構文解析）する機能を有する。ヘッダー復号器は、動的フィルターにより使用される関心あるフィールドを抽出するよう機能する。ヘッダー復号器により抽出されたデータは、バス上にて動的フィルターに送られる。このデータは、ＴＣＰプロトコルに対して、ハッシュ値（ＣＰＵにより計算された場合）、１０４ビットのソケットデータ（３２ビットのソース及び宛先ＩＰアドレス、１６ビットのソース及び宛先ポート、並びに８ビットのプロトコルを含む）、動的機能値（レイヤ４パケットの種類、例えばＩＣＭＰ、ＡＲＰ、ＴＣＰ、ＵＤＰを示す）などを含み、また、３２ビットのシーケンス番号、３２ビットの肯定応答、１１ビットのペイロード長、及び１６ビットのウインドウサイズをも含む。場合によっては、ヘッダー復号器は外部モジュールとして構成することもできるし、動的フィルターに一体化することもできることに留意されたい。

レイヤ４パケットの各タイプは、異なる動的機能値によって表される。この値は、セッション状態を追跡しその正当性を検証すべく受信パケットを処理する際に用いる適当なハードウエア機械を選択するために、動的フィルターによって用いられる。ペイロード長はヘッダー復号器により計算されて動的フィルターに送られる。これは、ＩＰヘッダーとＴＣＰヘッダー中のその長さの和をＩＰパケット中の全長フィールドから差し引くことにより計算される。

主フィルタープロセッサは、ＣＰＵインターフェース５８を備え、動的フィルターの主要な処理ブロックとして機能する。これは、新しいセッションを開き、既存のセッションを処理し、そして、特定のプロトコルに従って正当、すなわち許可された状態変化を検証している間に、セッションの状態を追跡する。セッション認識モジュールは、ソケットを受信し、セッションデータベースにおいてそのソケットに一致する開かれたセッションを検索する機能を有する。セッション管理モジュールは、ハッシュリンクリストと最長時間未使用（ＬＲＵ）リンクリストを維持し、それによってリストへのセッションの追加およびリストからセッションの削除を行う機能を有する。セッションデータベースは、動的フィルターの様々な処理モジュールによる使用のために、セッション状態と現在のステータスを含めて、ソケットとその他のセッション関連データとを記憶する機能を有する。セッションの認識を加速するのために、ハッシュテーブルとホールテーブルが用いられる。これらのコンポーネントについては、後にさらに詳細に説明する。

主フィルター処理
以下、主フィルター処理について詳細に説明する。図３は、本発明の主フィルタープロセッサ方法を示したフローチャートである。動的フィルターは、３段階でパケットデータを処理するように構成される。第一段階では、パケットに関連したセッションデータがセッションデータベースから読み出され、第二段階では、そのデータが処理され、第三段階では、処理結果がセッションデータベースの元の位置に書き込まれる。処理段階中に、セッション状態が所定の規則に対して追跡され、パケットの許否が決められる。

まず、セッションの認識が実行され（ステップ７０）、それによってセッションデータベースにおいて受信パケットのソケットに一致するソケットが検索される。認識結果は、主フィルタープロセッサに戻される（ステップ７２）。もし一致が見つからなかったなら（ステップ７４）、静的フィルターを用いて静的規則チェックが実行される（ステップ７６）。静的フィルター（これは動的フィルターの一部でもいいし、そうでなくてもよい）は、異なるプロトコルに対応する静的規則セットに基づいて受信パケットの静的チェックを実行する機能を有する。パケットの静的規則チェックは、通信技術においては周知であるから、ここではさらに詳しく述べない。

もし静的規則チェックの結果がパケットを拒否することであるならば、すなわちパケットが１以上のプロトコル規則に違反しているならば（ステップ７８）、パケットは拒絶される（ステップ９６）。もし静的規則チェックの結果がパケットを許可することであるならば、そのパケットがセッションのオープナー(opener)であるか否かがチェックされる（ステップ８０）。もしパケットがセッションを論理的に開き得るパケットであるならば、そのパケットはセッションオープナーである。例えば、応答パケットはセッションを開くことはできなが、ＴＣＰパケットはセッションを開くＳＹＮパケットでなければならない等々である。もしパケットがセッションオープナーでなければ、拒絶される（ステップ９６）。

もしパケットが有効なセッションオープナーであるなら、新しいセッションが作られる（ステップ８２）。セッション関連データ及びパラメータがセッションデータベースに記憶される（ステップ８４）。次に、この新しいセッションに対するハッシュポインタが計算され、ハッシュテーブルに記憶される（ステップ８６）。ハッシュポインタは、認識段階中にセッションをすばやく見つけるために使用される。

もし受信パケットのソケットと一致するソケットを有するセッションが見つかれば（ステップ７４）、セッションデータがセッションデータベースから読み出され（ステップ８８）、処理される（ステップ９０）。特定のパケットプロトコルに関連した動的規則がチェックされ、パケットの許否が決定される。そのセッション状態が追跡され、特定のプロトコルに対して許可された挙動に基づいてチェックされる。本発明によると、ソフトウエアよりむしろハードウエアにて動的規則チェックが行われる。別法として、ソフトウエア手段によっても同様に動的規則がチェックされ得る。

もしパケットが拒否されたなら（ステップ９２）、パケットは拒絶される（ステップ９６）。もし許可されたなら、更新されたセッション追跡状態と共に更新されたセッションデータがセッションデータベースの元の位置に書き込まれる（ステップ９４）。

どちらかのセッションオープナー、すなわちパケットの拒絶又はパケットの許可に続いて、１以上のステータスレジスタに書き込まれ、割り込みが為されてＣＰＵ又は他のホスト装置に主フィルター処理の完了が知らされる（ステップ９８）。

図４は、一致が見つかったときの本発明の主フィルタープロセッサ方法を示す状態遷移図である。全体として２９０で示された状態遷移図は、一致が見つかったときの主フィルタリング処理の論理を実施する複数の遷移と状態を含む。このプロセスは、一致状態２９２において始まり、ポインタとステータスをフェッチする状態２９４に進む。この状態では、セッションに関連したポインタとステータスデータがフェッチされる。

もしセッションがＴＣＰセッションであるならば、ＴＣＰ関連データがセッションデータベースからフェッチされる（ステップ２９７）。次に、プロセスはＴＣＰ処理状態２９８に進む。後に詳細に説明するように、実行される処理は、ＴＣＰセッション状態の追跡、及びセッション挙動が正当か否かのチェックからなる。パケットは拒絶（状態３０２）され得るか又は許可され得、その際には処理は静的フィルタリングチェックが完了するのを待ち続ける（状態３０４）。静的フィルタリングは、周知の静的フィルタリング技術を用いて動的フィルターの外部にて実行される。静的フィルターチェックは、パケットを拒絶（状態３０２）又はパケットを許可し、それによって該処理は、コンテンツ機械が有効ストリングのペイロードの検索を完了するのを待ち、かつチェックサム検証が完了するのを待つ（状態３０６）。もしチェックサム検証がパスしかつ有効なストリングが見つかったならば、ＴＣＰパラメータが更新され、セッションデータベースに記憶される（状態３１０）。次にセッションポインタが更新され（状態３１２）、パケットが許可される（状態３１４）。もしチェックサム検証がチェックサムエラーを戻すか又はコンテンツ機械が無効ストリングを見つけたならば、そのパケットは拒絶される（状態３０２）。無効ストリングは、コンテンツ機械により見つけられた１以上の理由（例えば、それらがウイルスやＦＴＰＤＥＬＥＴＥコマンドなどの不許可コマンドの存在を示している等々）によって許可されないストリングを含む。有効なストリングは、許可されたストリングか又は不一致(no matching) ストリングを含む。本発明で用いるのに適したコンテンツ機械は、同様に譲渡された米国出願第Ｘ号（２００１年２月２１日提出、標題「Apparatus for and Method of Multiple Parallel String Searching」）に詳細に記載されており、その全体をここに援用する。

ＴＣＰ以外のプロトコルに対しても同様の処理が行われる。もしセッションが非ＴＣＰセッション（例えばＵＤＰ、ＡＲＰ、ＩＣＭＰ等）であるならば、もう一方のプロトコル処理状態２９６に入れられる。後に詳細に説明するように、実行される処理は、接続状態の追跡、及びセッション挙動が特定のプロトコルに対して正当であるか否かのチェックからなる。パケットは拒絶され得るか（状態３０２）、又は許可され、その際に処理は静的フィルタリングチェックが完了するのを待ち続ける（状態３００）。静的フィルターチェックは、パケットを拒絶することができるか（状態３０２）、又は許可することができ、それによって該プロセスはコンテンツ機械がペイロードの検索を完了するのを待ち、かつチェックサムの検証が完了するのを待つ（状態３０６）。もしチェックサムの検証がパスし且つ有効なストリングが見つかったならば、特定プロトコルのパラメータが更新され、セッションデータベースに記憶される（状態３０８）。次に、セッションポインタが更新され（状態３１２）、そのパケットが許可される（状態３１４）。もしチェックサムの検証がチェックサムエラーを戻すか又はコンテンツ機械が無効ストリングを見つけたならば、そのパケットは拒絶される（状態３０２）。

図５は、一致が見つからないときの本発明の主フィルタープロセッサ方法を示す状態遷移図である。全体として３２０で示した状態遷移図は、一致が見つからないときに主フィルタリング処理の論理を実施する複数の遷移と状態を含む。このプロセスは、一致が見つからない状態３２２において始まり、もしセッションがセッションオープナーであるなら、静的フィルター決定待ち状態３２６に進む。もしセッションがセッションオープナーでないならば、パケットは拒絶される（状態３２４）。

もし静的フィルターがパケットを許可するならば、プロセスはコンテンツ機械及びチェックサム検証器がチェックを完了するのを待ち（状態３２８）、そうでなければパケットは拒絶される（状態３２４）。もしコンテンツ機械チェックが無効ストリングを見つけるか又はチェックサム検証がチェックサムエラーを明らかにするならば、そのパケットは拒絶される（状態３２４）。もしチェックサム検証及びコンテンツ機械検索がエラーなしで完了するならば、セッションが開かれ、ソケットデータがセッションデータベースに記憶される（状態３３０）。ステータス、タイムスタンプ及び接続状態もまた、セッションデータベースに記憶される（状態３３２）。もしセッションが非ＴＣＰセッションであるならば、そのパケットは許可される（状態３３６）。ＴＣＰセッションの場合には、ＴＣＰセッションが開かれ（状態３３４）、パケットが許可される（状態３３６）。

本発明によると、動的フィルターが、サポートされた総てのプロトコルに対して並列にてセッション追跡処理を行うべくハードウエアにて実現するのに適している。ソケット一致の場合にセッションデータのフェッチ中、前にフェッチされたデータが並列にて処理される。一旦データがフェッチされると、種々のプロトコルに対する総てのセッションチェックが、１クロックサイクル内に実行される。よって、本発明のハードウエアでの実現は、パケットフィルタリングプロセスを大いに加速させる。

セッション認識
以下、セッション認識プロセスを詳細に説明する。図６は、入力パケットに関連したセッションを決めるハッシング技術の説明図である。各々のセッションは固有のソケットに対応する。セッションは、受信パケットのソケットと、セッションデータベースに記憶され前に開かれたセッションに関連するソケットとを比較することにより識別される。セッションの認識を速めるため、セッションレコードへのハッシュポインタをセッションデータベースに記憶し、かつ受信ソケットに対応したセッションの素早い検索が可能なハッシュテーブルが用いられる。

新しいセッションはセッションデータベースに記憶され、動的フィルター又はＣＰＵによってソケットのハッシュが計算される。ハッシュポインタは、ハッシュ結果により示されたされたハッシュテーブル６０（図２）中の場所に記憶される。もし１より多いセッションがその場所に記憶されるならば、該セッションはリンクリストに加えられる。最初にハッシュテーブル中の各エントリがヌル（ＮＵＬＬ）に初期化されることに留意されたい。

パケットを受信すると、ソケット１００が、ハッシュ計算器１０２に入力される。ハッシュ計算器１０２は、ハッシュ結果１０４を発生し出力する機能を有する。ハッシュ結果は、ハッシュテーブル１０６に対するインデックスとして用いられる。ハッシュテーブル１０６は、複数のエントリ１０８を含み、その各々がハッシュポインタを含む。ハッシュポインタは、セッションデータベースにおけるセッション１１０のリンクリストを示す。セッションデータベース中の各セッションは、前のポインタ１１４と次のポインタ１１２を含み、よって二重リンクリストを実現している。もしソケットのヒット(hit) が生じたならば、リンクリスト中の各セッションは、受信パケットのソケットとの一致がチェックされなければならない。

好ましくは、ハッシュテーブル全体においてハッシュ結果のできるだけ均一な広がりを作るべく、ハッシュ関数が選択される。ハッシュ関数は、ＸＯＲ関数やＣＲＣなどの任意の適当な関数とし得る。一実施態様では、次式に従ってハッシュ結果を計算する際にランダムベクトルを用いることによって、単純なＸＯＲハッシュ関数を越えて性能を改善し得る。

よって、入力ソケットデータは、ランダムベクトルと入力ソケットデータとを用いて生成される。

図７は、本発明のセッション認識プロセスにおけるハッシング方法を説明したフローチャートである。最初のステップは、例えば上述した方法により受信パケット中のソケットからハッシュ値を計算することである（ステップ１２０）。このソケットに対応するハッシュポインタを検索するために、ハッシュテーブルへのインデックスとしてＲバイトのハッシュ結果が用いられる。もしハッシュポインタがヌルを示すならば（ステップ１２４）、セッションは存在しなく、「セッション見つからず」が主フィルタープロセスに戻される（ステップ１２６）。

もしハッシュポインタがヌルでないならば、セッションのソケットがセッションデータベースから読み出され（ステップ１２８）、受信パケット中のソケットと比較される（ステップ１３０）。もしこれらのソケットが一致するならば（ステップ１３２）、セッション一致が見つけられ（ステップ１３４）、主フィルタープロセスに報告される。もしこれらのソケットが一致しないならば（ステップ１３２）、次のハッシュポインタがリンクリストから読み出され（ステップ１３６）、最後のハッシュポインタがヌルを示すか又は一致が見つけられるまで、該方法がステップ１２４から繰り返される。

ただ１つのセッションがリンクリストに記憶されている場合においてさえ、ソケットの完全な比較が常に実施されることに留意されたい。また、本発明の範囲は、どの実体すなわち動的フィルター又はＣＰＵがリンクリストを更新し維持するかによっては制限されないことにも留意されたい。ハッシュテーブルの深さは、任意の所望値とし得る。しかしながら、一般には、この深さは、同時に追跡されるセッション数に従って設定される。好ましくは、ハッシュエントリ数は、セッション数の２又は４倍である。というのは、ソケットの完全比較では時間がかかるゆえに、多くの複製を持つのは望ましくないからである。

本発明によれば、セッション認識モジュールは、部分的なソケットデータを用いてセッションをサーチする能力を備える。部分的なソケットデータ（ホールと称する）は、情報の１以上の項目を欠いているソケット、すなわちソケットを作る５つの要素（ソース及び宛先ＩＰアドレス、ソース及び宛先ポート並びにプロトコル）のうちの１以上の任意の組合わせを含む。ホールは、ファイアウォール／動的フィルター内に作られた開口を検索し、後続のパケットがたとえ静的フィルター規則ベースをパスしなくてもそれらのパケットを通過可能にする。ホールに関連したパケットは、その関連ソケットにおいて欠落している零又はそれより多いパラメータを有し得る。ソケットは、１以上の欠落パラメータと共にホールテーブル中に配置され、ホールサーチが実行される。

ホールサーチ方法は、図７に関して説明した完全ソケット一致方法を用いてもセッションの一致を見つけられない際に、セッション認識モジュールにより実行される第２のサーチ方法である。ホールは望ましくなく、一旦出来てしまうと、ＣＰＵと動的フィルターは、部分的なソケット一致を生じる第１パケットの受信に際してそれらのホールを「充填(fill)」しようとする。

ホールテーブル（図２）は、処理レイヤ５以上において一般にソフトウエアにより与えられるホール情報を記憶するのに用いられる。ソケットが５つの項目からなる場合には、ホールテーブルは３２個のレコード（０〜３１）を含む。例えば、ＦＴＰパケット、ＩＰ電話技術に関係したパケットなどの処理においては、初期にはソケットからの１以上のパラメータが未知である。これらの場合には、ＣＰＵは、ホールテーブル内にて欠落パラメータに対応した位置にホールを開く。

ホールテーブル中のエントリ３１（すなわち総てのもの）は、欠落パラメータを表さないので使用されないことに留意されたい。ホールテーブル中の各エントリは、第１表に載せられた以下のフィールドを有する。

第１表：ホールテーブルフィールド
───────────────────────────────────
フィールド説明
───────────────────────────────────
ＬＡＮホールがＬＡＮ側から閉じられると期待される、すなわちＬＡＮ
からのパケットがこのホールタイプと一致すると仮定される。
ＷＡＮホールがＷＡＮ側から閉じられると期待される、すなわちＷＡＮ
からのパケットがこのホールタイプと一致すると仮定される。
ＥＨ既存のホール。このフィールドの数は、このタイプを有して現在
開かれている既存のホール数を表す。
ＰＥＨＴ前に存在したホールタイプ。既存ホールの二重リンクリストにお
ける前のホールタイプへのポインタ。
ＮＥＨＴ次に存在するホールタイプ。既存ホールの二重リンクリストにお
ける次のホールタイプへのポインタ。
───────────────────────────────────

ここに与えられた例では、ホールタイプは、５つの可能な欠落パラメータ（すなわち、ビット４−プロトコル；ビット３−リモートポート；ビット２−ローカルポート；ビット１−リモートＩＰ；ビット０−ローカルＩＰ）として定義される。よって、ホールタイプ「１１０１１」は、ローカルポートパラメータの欠落に対応する。

上述したハッシュ方法は、ハッシュ値を生成するために、完全なソケット情報を要求する。もし受信したパケットがホールを「充填」すべきものであるならば、セッション認識を用いたハッシュ方法（図７）は、一致見つからずとなり、ホールは充填し得ない。「ホール」セッションは見つかり得ない。というのは、ハッシュは、受信パケットのソケット全体について計算される一方、ホールセッションを指すハッシュテーブル中のエントリは部分的な事前既知パケットについて計算されたからである。

ホールテーブルは、ＣＰＵにより書き込まれ動的フィルターにより読み出されるホール情報を記憶することによってこの問題を解決する。ホールは、アプリケーションレイヤ上にて動的フィルタリングを実行する外部プロセスによって開かれたセッションである。ＣＰＵはホールの存在を最初に検出する実体であるので、ＣＰＵがまず部分的なハッシュ値を計算してそれをハッシュテーブルに記憶することに留意されたい。欠落パラメータは受信パケットから決めることができるので、部分的なソケットがデータベースのものと一致する第１パケットが当該ホールを閉じる。ホールテーブルは３２個のエントリを含み、その各々が１以上の欠落パラメータの固有の組合わせに対応し、その際、各「ビット」はソケットを作る５つのパラメータのうちの一つを表す。

各々のエントリは、その特定種類のホール数と他のエントリに対する次及び前のポインタを示すフィールドを記憶する。よって、次及び前のポインタは、ホールのリンクリストを形成する。ｆｉｒｓｔ＿ｖａｌｉｄ＿ｅｎｔｒｙレジスタは、該リスト中の第１エントリへのポインタを記憶する。このレジスタにおけるヌルは、セッションデータベースにホールが記憶されていないことを示す。最後のエントリは、リストの最後を示すヌルポインタを記憶する。

図８は、本発明のセッション認識プロセスのホールサーチ方法を説明するフローチャートである。最初のステップは、ｆｉｒｓｔ＿ｖａｌｉｄ＿ｅｎｔｒｙの内容を用いて第１ホールエントリを読み出すことである（ステップ１４０）。もしレジスタ中のホールポインタがヌルを示すならば（ステップ１４２）、ホールは見つからず、このことが報告され（ステップ１４４）、本方法はもとに戻る。

もしレジスタ中のホールポインタがヌルを示していないならば（ステップ１４２）、ホールコード(code)に従ってハッシュ値が計算される（ステップ１４６）。ホールコードは、欠落パラメータの５ビット表現であり、この欠落パラメータは、ホールポインタにより指されるホールテーブル中のエントリによって示される。欠落パラメータは、ハッシュ計算においては使用されないか、又は一定値、すなわち零又は１で置き換えられる。

次に、ハッシュ結果をインデックスとして用いてハッシュテーブル６０（図２）からハッシュポインタを検索すべく、上述のように生成されたハッシュ結果が使用される（ステップ１４８）。もしハッシュポインタがヌルを示すならば（ステップ１５０）、次のホールポインタがホールリンクリストから読み出され（ステップ１６４）、本方法はステップ１４２を続ける。もしハッシュポインタがヌルを示さなければ（ステップ１５０）、部分的なソケット情報が、ハッシュポインタに対応するセッションデータベース内のエントリから読み出される（ステップ１５２）。

セッションデータベース中のエントリから読み出された部分ソケットは、パケットにおける受信した部分ソケットと比較される（ステップ１５４）。もしこれらの部分ソケットが一致するならば（ステップ１５６）、セッション一致が見つかったことが宣言される（ステップ１５８）。もし部分ソケットが一致しないならば、次のハッシュポインタがリンクリストから読み出され（ステップ１６０）、もしハッシュポインタがヌルを示さなければ（ステップ１６２）、本方法はステップ１５２を続け、次のセッション中の部分ソケットがチェックされる。もし次のハッシュポインタがヌルを示すならば（ステップ１６２）、次のホールポインタがホールリンクリストから読み出され（ステップ１６４）、本方法はステップ１４２を続ける。

一旦ホールサーチ方法を用いてセッションが認識されたなら、パケット及びセッションデータの処理は、完全ソケットサーチの場合のように進行する。よって、本発明によると、完全又は部分ソケット情報を用いてセッション認識が実行し得る。次に受信したパケットから情報が抽出されるので、開いたどのホールも充填される。

セッションデータベース
以下、セッションデータベース６４（図２）について詳細に説明する。上述したように、セッションデータベースは、複数のセッションに対してセッション関係データを記憶する機能を有する。セッションデータベースの大きさは、運用及びシステム要求に依存して変わり得る。データベースの各レコードを作るフィールドを次の第２表に載せる。

第２表：セッションデータベースレコードフィールド
───────────────────────────────────
フィールドフィールドの説明長さ
番号（ビット）
───────────────────────────────────
１ローカルＩＰアドレス３２
２リモートＩＰアドレス３２
３プロトコル８
４ローカルポート／ＩＣＭＰシーケンス番号／ＩＰ識別１６
５リモートポート／タイプおよびコード／ヌル１６
６次のハッシュポインタ１６
７前のハッシュポインタ１６
８次のＬＲＵポインタ１６
９前のＬＲＵポインタ１６
１０子の数１６
１１セッションステータス１６
１２ローカルＭＡＣアドレス４８
１３ＬＡＮＡＣＫ上(above) 変化８
１４ＬＡＮシーケンス上変化８
１５ＷＡＮＡＣＫ上変化８
１６ＷＡＮシーケンス上変化８
１７ＬＡＮＡＣＫ下(below) 変化８
１８ＬＡＮシーケンス下変化８
１９ＷＡＮＡＣＫ下変化８
２０ＷＡＮシーケンス下変化８
２１ＬＡＮシーケンスおよびＡＣＫ変化しきい値３２
２２ＷＡＮシーケンスおよびＡＣＫ変化しきい値３２
２３期待されるＬＡＮＡＣＫ３２
２４期待されるＷＡＮＡＣＫ３２
２５最大ＬＡＮシーケンス３２
２６最大ＷＡＮシーケンス３２
２７最大ＬＡＮウインドウサイズ３２
２８最大ＷＡＮウインドウサイズ３２
２９接続状態３２
３０タイムスタンプ３２
３１ＬＡＮ初期シーケンス３２
３２ＷＡＮ初期シーケンス３２
３３親セッションポインタ１６
３４第１子ポインタ１６
３５次の兄弟ポインタ１６
３６前の兄弟ポインタ１６
───────────────────────────────────

第１グループのフィールド１〜５は、セッションを識別するのに用いられるソケットを表す。フィールド番号４及び５は、プロトコルに依存して異なるデータを記憶する。例えば、ローカル及びリモートポートデータが、ＴＣＰ及びＵＤＰパケットに対して記憶され、ＩＣＭＰシーケンス番号、タイプ及びコードデータが、ＩＣＭＰエコーセッションに関係したパケットに対して記憶される。

フィールド６及び７は、上述したハッシュリンクリスト内の次及び前のハッシュポインタを記憶する。ハッシュリンクリストは、パケットのセッション認識中に用いられる。フィールド８及び９は、古さ(staleness) の観点からセッションを順序付けるのに用いられるＬＲＵリンクリスト内の次及び前のＬＲＵポインタを記憶する。ＬＲＵリンクリストの操作は後に詳しく説明する。フィールド１０は子の数を記憶する。このフィールドは、このセッションに関連したアプリケーションが追加セッションの開設を要求する場合に用いられる。開かれた各々のセッション（すなわち子セッション）が当該子の数をインクリメントする。

動的フィルターはまた、ステータス関係の情報をＣＰＵに送りかつＣＰＵから送るためのセッションステータスレジスタを備える。セッションステータスは、下の第３表に示されるように複数のビットを含む。

第３表：セッションステータスビット
───────────────────────────────────
ビット名説明
───────────────────────────────────
ＵＳＤセッションレコードが使用されているか否か（すなわち有効か
否か）を示す
ＳＴＲどちらの側がセッションを開始したかを示す、すなわちＬＡＮ
かＷＡＮか
ＨＳＨこのセッションがハッシュリンクリスト中の最初のものである
ことを示す
ＮＡＴこのセッションがネットワークアドレス変換（ＮＡＴ）セッシ
ョンであるか否かを示す
ＡＲＰアドレス絞り込みプロトコル（ＡＲＰ）ＮＡＴセッションを示
す
ＦＲＧセッションが細分化(fragmented)されたＩＰセッションである
ことを示す
ＵＣＭこのセッションがＣＰＵによりマーク(marked)されたこと、す
なわち、このマークされたセッションに属する各パケットにつ
きステータスビットによりＣＰＵが通知されることを示す
ＦＲＥファミリ関係が存在することを示す
ＨＬＤタイムアウト等に関わらずセッションが閉じられ得ないことを
示す
ＰＳＶ受動セッション、すなわちタイムスタンプの更新がなく、パケ
ットはこのセッションを通過することができないことを示す
ＮＯＣセッションの閉鎖の通知、すなわち割り込みの発生を示す
ＳＢＰセッションバイパス、すなわち動的フィルタリングがなく、タ
イムスタンプの更新のみあることを示す
ＣＳＨセッションを生かしつつ（すなわち、ＬＲＵ及び入ってくるパ
ケットのタイムスアンプを更新するが、それを許可しない）、
このセッションの総てのトラヒックを止めることを示す
───────────────────────────────────

次のフラグ、すなわちＵＣＭ、ＦＲＥ、ＨＬＤ、ＰＳＶ、ＮＯＣ、ＳＢＰ、ＣＳＨが、ＣＰＵにより設定され、動的フィルターにより使用される。

フィールド１２〜２２は、ネットワークアドレス変換のために用いられる。フィールド２３〜２８及び３１〜３２は、すべてＴＣＰ関係のフィールドであり、ＴＣＰパケットを処理及び追跡する際に用いられる。フィールド２９は、すべてのプロトコルタイプに対して接続状態を記憶する。接続状態パラメータは、現在の接続状態を表す値である。異なるプロトコルに対しては、異なる値が用いられる。説明のための例として、いくつかのプロトコルの接続状態が、下の第４表に示される。

フィールド３０は、セッションのエージ(age) を決定するのに用いられるタイムスタンプを記憶する。時間は１６ビットで表され、特定のプロトコルに従って時間差又はデルタとして記憶される。周期的にＣＰＵがセッション管理モジュールに対してセッションのエージ測定(aging) を指示し、それによりエージオーバーのセッションが閉じられる。

フィールド３３〜３６は、このセッションに関係したセッションに対するポインタを記憶するのに用いられる。兄弟、子、親情報を含めて、種々のファミリ情報が、セッションデータベースに記憶される。

セッション追跡例：ＴＣＰセッションの開／閉
上述したように、主フィルター処理は、一旦セッションが認識され且つ受信パケットに関連したセッションデータがセッションデータベースから読み出されると規則チェックを実行する実体である。本発明のハードウエア手段によると、ＴＣＰが最も複雑である場合、動的基礎にてチェックされる各プロトコルに対して別々の回路が設けられる。ソフトウエア手段は、動的規則チェッキングを行うためにアプリケーションコードを利用する。

例として、ＴＣＰプロトコルのためのハードウエア回路により実行される必要のある処理が、ＴＣＰセッションの開閉プロセスの状態遷移図の形態にて説明される。電気技術の分野の習熟者ならば、ここに開示された状態遷移図を利用して、図示された同じ機能を実現する回路を構成することが可能であることに留意されたい。

図９は、ＴＣＰセッションのパケットフローを示す図である。ここに記載のフローは、通信技術においては周知であり、次の３−ウエイ及び４−ウエイハンドシェイクの状態遷移図を理解する際の助けとして示される。ＴＣＰセッションは、ＳＹＮフラグを含んだパケットを介して同期シーケンス番号を要求することにより、２つのホストＡとＢの間で開かれる。一旦開かれると、ＡＣＫパケットにより表されたように２つのホスト間にてデータが流れる。ＴＣＰセッションは、両サイドがＦＩＮフラグを含んだパケットを送ることにより閉じられる。このＦＩＮフラグは、送り手が送るべきデータをもはや持っていないことを示す。ＦＩＮパケットの肯定応答がセッションを閉じる。

ハンドシェイク中に受信パケットから抽出された肯定応答数が、セッションデータベース中に記憶された期待される肯定応答数に基づいて検証される。後に説明するように、開かれたセッションの追跡中、ウインドウ内にあるべきシーケンス及び肯定応答数が検証される。もしＲＳＴパケット（すなわち、ＴＣＰヘッダー中にアサート(asserted)されたＲＥＳＥＴフラグを有するパケット）が到着すると、セッションは閉じられる。

図１０は、ＴＣＰセッションを開く際に生じる３−ウエイハンドシェイクを説明する状態遷移図である。可能な入力パケットには、ＲＸ／ＴＸＳＹＮ、ＲＸ／ＴＸＳＹＮＡＣＫ、ＲＸ／ＴＸＡＣＫパケットが挙げられる。一般に、符号１７０で示した状態遷移図は、複数の有効な（すなわち正当な）状態とその関連の遷移を含む。ＴＸはＬＡＮからＷＡＮへの方向を示し、ＲＸはＷＡＮからＬＡＮへの方向を示すことに留意されたい。

ＴＣＰセッションの開設を検出すると、ヌル状態１７２に入れられる。この状態において、新しいセッションがセッションデータベース内にて開かれ、以下のフィールドが生成されてセッションレコード中に記憶される。該フィールドとは、受信したシーケンス数、タイムスタンプ、ヌル状態を示す接続状態、最大ウインドウサイズ、最大シーケンス数、及び期待される肯定応答数である。その次の状態は、パケットが受信されるサイドはどちらか、すなわちＬＡＮか又はＷＡＮに依存する。もしＲＸＳＹＮパケットが受信されるならば、次の状態は、「ＷＡＮリクエストのＴＣＰ接続(WAN requested TCP Connection)」状態１７６となる。さもなければ、「ＬＡＮリクエストのＴＣＰ接続(LAN requested TCP Connection)」状態１８４に入れられる。この状態では、他の総ての状態におけるのと同様に実行されるように、受信パケットから得られた認識セッションに対応するデータが、セッションデータベースから読み出される。１以上のフィールドが正当性をチェックされ、１以上のフィールドが更新され、セッションデータがセッションデータベースの元の位置に書き込まれる。

状態１７６において実行される主チェックは、肯定応答数が期待される肯定応答数に相関しているか否かをチェックすることを含む。接続状態、ＬＡＮ初期シーケンス数、ＬＡＮ最大シーケンス数、ＬＡＮウインドウサイズ、及びハンドシェイクの最後の部分に対して期待される肯定応答が更新される。ＲＸＳＹＮ及びＴＸＳＹＮの受信が正当ならば、状態の変化は生じない。

ＴＸＳＹＮＡＣＫの受信は、セッションを「ＬＡＮ承認のＴＣＰ接続(LAN Accepted TCP Connection) 」状態１７８に移動させる一方、ＲＸＳＹＮＡＣＫの受信は、セッションを「ＷＡＮ承認のＴＣＰ接続(WAN Accepted TCP Connection) 」状態１８６に移動させる。ＲＸＳＹＮ、ＴＸＳＹＮ、ＲＸＳＹＮＡＣＫ及びＴＸＳＹＮが正当ならば、状態の変化は生じない。これら２つの状態において、セッションパラメータの同様のチェックが実行される。一旦チェックと更新が完了したならば、更新されたパラメータがセッションデータベースの元の位置に書き込まれる。

状態１７８中でのＲＸＡＣＫ又は状態１８６中でのＴＸＡＣＫの受信は、セッションを「ＴＣＰ接続の開設(Open TCP Connection) 」状態１８０に移動させる。ＲＸＳＹＮＡＣＫ、ＴＸＳＹＮ、ＲＸＡＣＫ又はＴＸＡＣＫの受信が正当ならば、状態の変化は生じない。これは、このセッションにてその後に受信される各ＴＣＰパケットが正当性についてチェックされるとすぐに、「ＴＣＰセッションの開設(open TCP session)」状態を表す。例えば、シーケンス数と肯定応答の追跡が実行される。パケットの方向に依存するＬＡＮ又はＷＡＮに対する最大シーケンス数のフィールドもまた、更新される。

よって、ＴＣＰセッションを開くための３−ウエイハンドシェイクの各ステップが、動的に追跡され、不正な遷移を試みるパケットは拒絶される。従って、ＴＣＰプロトコルに適切に準拠したパケットのみが通過を許可される。

図１１Ａ及び１１Ｂは、ＴＣＰセッションを閉じる際に生じる４−ウエイハンドシェイクを説明した状態遷移図である。全体として符号１９０で示されたこの図中の可能な入力として、ＲＸ／ＴＸＡＣＫ、ＲＸ／ＴＸＦＩＮＡＣＫ、ＲＸ／ＴＸＦＩＮＡＣＫ（ＦＩＮ）又はＲＸ／ＴＸＡＣＫ（ＦＩＮ）が挙げられる。ＴＸ／ＲＸＡＣＫは正規の肯定応答パケットを表す一方、ＡＣＫ（ＦＩＮ）はＦＩＮパケットの肯定応答を表すことに留意されたい。

この図における開始状態は、接続の開設(Open Connection）状態１９２である。ＲＸＡＣＫ又はＴＸＡＣＫパケットの受信は、状態の変化を生じさせない。ＴＸＦＩＮＡＣＫの受信は、セッションを「ＬＡＮ送出のＦＩＮ(LAN sent FIN)」状態１９４に移動させる一方、ＲＸＦＩＮＡＣＫの受信は、セッションを「ＷＡＮ送出のＦＩＮ(WAN sent FIN)」状態２０４に移動させる。状態１９４中でのＲＸＦＩＮＡＣＫ又は状態２０４中でのＴＸＦＩＮＡＣＫの受信は、セッションを「ＷＡＮ送出のＦＩＮ／ＬＡＮ送出のＦＩＮ(WAN sent FIN/LAN sent FIN) 」状態２０２に移動させる。ＲＸ／ＴＸＦＩＮ又はＲＸ／ＴＸＡＣＫパケットの受信は、状態変化を生じさせない。

状態１９４中でのＲＸＡＣＫ（ＦＩＮ）パケットの受信は、セッションを「ＷＡＮ応答のＬＡＮＦＩＮ(WAN ACKed LAN FIN) 」状態１９６に移動させる。ＲＸ／ＴＸＡＣＫ、ＲＸＡＣＫ（ＦＩＮ）又はＴＸＦＩＮＡＣＫパケットの受信は状態変化を生じさせない。状態２０４中でのＴＸＡＣＫ（ＦＩＮ）パケットの受信は、セッションを「ＬＡＮ応答のＬＡＮＦＩＮ(LAN ACKed LAN FIN) 」状態２０６に移動させる。ＲＸ／ＴＸＡＣＫ、ＴＸＡＣＫ（ＦＩＮ）又はＴＸＦＩＮＡＣＫパケットの受信は、状態変化を生じさせない。

状態１９６中でのＲＸＦＩＮＡＣＫ又はＲＸＦＩＮＡＣＫ（ＦＩＮ）パケットの受信は、セッションを「ＷＡＮ応答のＬＡＮＦＩＮ／ＷＡＮ送出のＦＩＮ(WAN ACKed LAN FIN/WAN Sent FIN)」状態１９８に移動させる。ＲＸ／ＴＸＡＣＫ、ＲＸＡＣＫ（ＦＩＮ）、ＲＸＦＩＮＡＣＫ（ＦＩＮ）及びＲＸ／ＴＸＦＩＮパケットは、状態変化を生じさせない。状態２０６中でのＴＸＦＩＮＡＣＫ又はＴＸＦＩＮＡＣＫ（ＦＩＮ）パケットの受信は、セッションを「ＷＡＮ応答のＬＡＮＦＩＮ／ＷＡＮ送出のＦＩＮ(WAN ACKed LAN FIN/WAN Sent FIN)」状態２１０に移動させる。ＲＸ／ＴＸＡＣＫ、ＴＸＡＣＫ（ＦＩＮ）、ＴＸＦＩＮＡＣＫ（ＦＩＮ）及びＲＸ／ＴＸＦＩＮパケットは、状態変化を生じさせない。

状態１９４中でのＲＸＦＩＮＡＣＫ（ＦＩＮ）パケットの受信は、セッションを「ＷＡＮ応答のＬＡＮＦＩＮ／ＷＡＮ送出のＦＩＮ(WAN ACKed LAN FIN/WAN Sent FIN)」状態１９８に直接移動させる。状態２０４中でのＴＸＦＩＮＡＣＫ（ＦＩＮ）パケットの受信は、セッションを「ＬＡＮ応答のＷＡＮＦＩＮ／ＬＡＮ送出のＦＩＮ(LAN ACKed WAN FIN/LAN Sent FIN)」状態２１０に直接移動させる。

状態１９８中でのＴＸＡＣＫ（ＦＩＮ）若しくはＴＸＦＩＮＡＣＫ（ＦＩＮ）パケットの受信、又は状態２１０中でのＲＸＡＣＫ（ＦＩＮ）若しくはＲＸＦＩＮＡＣＫ（ＦＩＮ）パケットの受信は、セッションを「ＦＩＮによるＴＣＰの閉鎖(Close TCP By FIN)」状態２００に移動させる。ＲＸ／ＴＸＦＩＮ、ＲＸ／ＴＸＡＣＫ、ＴＸＦＩＮ及びＲＸ／ＴＸＡＣＫ（ＦＩＮ）パケットは、状態の変化を生じさせない。

このようにして、ＴＣＰセッションを閉じるための４−ウエイハンドシェイクの各ステップが動的に追跡され、不正な遷移を試みるパケットは拒絶される。よって、ＴＣＰプロトコルに適切に準拠するパケットのみが通過を許可される。

本発明はまた、他のプロトコルも同様に追跡するセッションを含む。図１２は、ＡＲＰセッションのパケットフローの説明図である。２つのホストＡ及びＢを仮定すると、ＡＲＰセッションの追跡は、ＡＲＰリクエストパケットを受信するとセッションを開くことを含む。同じソケットを有する後続のＡＲＰリクエスト／リプライパケットが許可される（再送信を含めて）。好ましくは、ＡＲＰリプライの後に短いデルタタイムアウトが規定される。というのは、開いたＡＲＰセッションは、長時間の間開いたまま保持されるべきでないからである。ＡＲＰリプライがセッションを閉じる。

図１３は、ＩＣＭＰエコーセッションのパケットフローの説明図である。２つのホストＡ及びＢを仮定すると、ＩＣＭＰエコーリクエストがＩＣＭＰエコーセッションを開く。一旦セッションが開かれると、同じソケットを持ったＩＣＭＰエコーリプライのみが許可される。エコー再送信は異なるシーケンスＩＤ番号、すなわち異なるソケットを利用するので、再送信は許可されない。

図１４は、ＩＣＭＰメッセージ／エラーセッションのパケットフローの説明図である。ＩＣＭＰメッセージ／エラーパケットは、ＩＰヘッダーフィールド、ＩＣＭＰヘッダー、ＩＰヘッダー及び６４ビットのＴＣＰヘッダーを含む。ＩＣＭＰメッセージ／エラーは、６４ビットのＴＣＰヘッダーに加えて、元のパケットのＩＰヘッダーを取り込んでいる(encapsulated)。ＩＣＭＰメッセージ／エラーパケットは、セキュリティポリシー規則のデータベース（すなわち外部静的フィルター）によって許可されなければならず、さもなければ、主フィルター処理によって自動的に拒絶される。動的フィルターは、取り込まれた部分パケットのみを処理する（すなわちセッションは取り込まれたソケットに従って認識される）。もし静的フィルターにより許可され且つセッション認識中にセッションが見つかったならば、（１）ＩＣＭＰメッセージパケットが許可され、セッションのタイムスタンプフィールドのみが修正され、（２）ＩＣＭＰエラーパケットが許可され、接続状態が「ＬＡＮ／ＷＡＮＩＣＭＰＥＲＲＯＲによる閉鎖(closed by LAN/WAN ICMP ERROR)」に変えられる。このセッションに属する後続のパケットは、このエラーゆえに拒絶される。外部構成（例えばＣＰＵを介して）は、どの種類のＩＣＭＰ（ＩＣＭＰタイプ／コード）がメッセージであると考えられるか、及びどれがエラーであると考えられるかを決める。セキュリティ問題を有するＩＣＭＰパケットは、セキュリティポリシー規則のデータベースにより先行して拒絶されなければならない。

シーケンス／肯定応答数の追跡
本発明によると、主フィルター処理は、ＴＣＰ／ＩＰセッションのシーケンス番号を追跡する。図１５は、主フィルタープロセッサによる規則チェック中に実行されるシーケンス番号のウインドウ追跡の説明図である。シーケンス番号の追跡は、ＴＣＰヘッダー中のバッファサイズのフィールドを用いて「ＴＣＰ接続の開設」状態１８０中にて主フィルター処理によって実行される。ｘ軸がＬＡＮシーケンス番号を表していると仮定すると、垂直の破線で示されているように、最大ＬＡＮシーケンス番号からバイトで表された最大ＷＡＮウインドウサイズ２４０が減じられ、かつ最大ＬＡＮシーケンス番号に加えられる。初期ＬＡＮシーケンス番号は、ｘ軸の左端に示されている。許可されるＬＡＮシーケンス範囲２４２が示されている。

各パケットに対して、下限が、初期ＬＡＮシーケンス番号又は最大ＬＡＮシーケンスー( マイナス）最大ＷＡＮウインドウサイズのうちの大きいほうとして計算される。上限は、最大ＬＡＮシーケンス番号と最大ＷＡＮウインドウサイズの和である。もし送信されたパケットのシーケンス番号が下限と上限の間にあるならば、そのパケットは許可される。そうでないならば、そのパケットは拒絶される。許可されたシーケンス範囲の外側のシーケンス番号を持ったパケットは拒絶される。受信パケットのシーケンス番号が同様に追跡されるが、上述のＬＡＮとＷＡＮの交換の点で異なることに留意されたい。

図１６は、主フィルタープロセッサによる規則チェック中に実行される肯定応答シーケンス数のウインドウ追跡の説明図である。肯定応答数の追跡は、ＴＣＰヘッダー中のバッファサイズフィールドを用いて「ＴＣＰ接続の開設」状態１８０中にて主フィルター処理によって実行される。ｘ軸がＷＡＮシーケンス番号を表すと仮定すると、垂直破線により示されているように、最大ＷＡＮシーケンス番号からバイトで表された最大ＬＡＮウインドウサイズ２５０が減じられ、かつ最大ＷＡＮシーケンス番号に加えられる。初期ＷＡＮシーケンス番号は、ｘ軸の左端に示される。許可された肯定応答範囲２５２が示されている。肯定応答数に対する規則チェックは、パケットがＷＡＮ又はＬＡＮにより送られたか受信されたかに依存して、上述されたシーケンス番号の規則チェックに類似する。

本発明によると、主フィルター処理モジュールは、限定的ではないがＵＤＰ、エコーリクエスト／リプライ、コントロール及びエラーメッセージの両方を含んだＩＣＭＰ、ＡＲＰ、ＩＣＭＰフラグメンテーション、及びＩＰを含めて、他のプロトコルも同様に関連した規則を動的にチェックする機能を有する。

セッション管理モジュール
本発明によると、セッション管理モジュールは、最長時間未使用の順番にてセッションを記憶すべくリンクリストを維持する機能を有する。セッション管理モジュールは、セッションデータベースの維持及び制御に関係したいくつかの機能を実行する。セッション管理モジュールは、ＣＰＵからの命令に応じて、セッションデータベース中に記憶されたセッションのタイムスタンプの有効性をチェック（すなわちエージ測定）するよう機能する。エージ測定を実行する命令が受信されると、セッションデータベース中の各レコードのタイムスタンプフィールドが調査され、期限が切れたレコードが閉じられる。古くなり且つ何らかの理由で正常に閉じられなかったセッションを廃棄する(flush) ために、エージ測定がセッションについて行われる。例えば、セッションは、もしそれが規則に違反したパケットに対応するならば、エージオーバーし得る。

セッション管理モジュールまたは、リクエストに応じて未使用（すなわち空で利用可能な）セッションをＣＰＵ又は主フィルター処理５４（図２）に与える機能を有する。動作中、ＣＰＵ／主フィルター処理は新しいセッションをリクエストし、セッション管理モジュールは１をサーチし、インデックスをＣＰＵ／主フィルター処理にそれぞれ戻す。同様に、セッション管理モジュールはまた、要求されるとき、すなわちエージ測定、ＣＰＵリクエスト、主フィルター処理リクエストなどのときに使用されているセッションを切り離す。セッション管理モジュールはまた、新しいセッションを開き、その際、ハッシュテーブル中のＬＲＵポインタとハッシュポインタ及びセッションデータベースが更新される。

図１７は、セッション使用を追跡するのに用いられる最長時間未使用の（ＬＲＵ）リンクリスト構造を示す。セッションが認識（すなわちアクセス）され、対応するパケットが主フィルター処理によって許可される度に、セッションがＬＲＵリンクリストの末尾に配置される。全体として符号２２０で示された二重リンクリストは複数のセッション２２６を含み、その各々が次のポインタ２２２と前のポインタ２２４を有する。ＬＲＵリンクリストの末尾のセッションは、ｔａｉｌ＿ＬＲＵ＿ｉｎｄｅｘ＿ｒｅｇレジスタ２２８の内容によって指示される。このレジスタにより指示されたセッションは、最短時間未使用のセッションを表す。ＬＲＵリンクリストの先頭のセッションは、ｈｅａｄ＿ＬＲＵ＿ｉｎｄｅｘ＿ｒｅｇレジスタ２２７の内容によって指示される。

後の詳細に説明するように、セッション管理モジュールはまた、セッションを閉じる際にファミリ関係を更新及び維持する。

セッションデータベースがいっぱいの場合において、新しいセッションが加えられたときにどのセッションを除去するかを決めるために、ＬＲＵリンクリストが用いられる。この場合、最長時間未使用のセッションが閉じられ、新しいセッションを記憶するのにそのレコードが用いられる。

図１８は、入力パケットに関連したセッションを認識した際にＬＲＵリンクリストを更新する方法を示すフローチャートである。一致セッションがアクセスされかつ対応するパケットが許可される度に、この更新方法が実行される。図１７に関し、特に前のセッション、一致セッション及び次のセッションとラベル付けされたセッションに関し、一致セッションがリスト中のその位置から末尾に移されて最短時間未使用のセッションとなる。一致セッションは、（１）前のセッションの次のＬＲＵポインタを一致セッションの次のＬＲＵポインタに設定すること、及び（２）次のセッションの前のＬＲＵポインタを一致セッションの前のＬＲＵポインタに設定することによって除去される（ステップ２３０）。

次に、一致セッションは、（１）一致セッションの次のＬＲＵポインタをヌルに設定すること、（２）一致セッションの前のＬＲＵポインタをｔａｉｌ＿ＬＲＵ＿ｉｎｄｅｘ＿ｒｅｇレジスタの内容に設定すること、及び（３）ｔａｉｌ＿ＬＲＵ＿ｉｎｄｅｘ＿ｒｅｇレジスタを一致セッションのインデックスに設定することによって、最短時間未使用のものとされる（ステップ２３２）。

図１９は、本発明のセッション管理モジュールの処理を示すフローチャートである。セッション管理処理はアイドルステップ３４２にて始まり、事象に依存して次のステップに移動する。ＣＰＵ又は主フィルタープロセッサからの「未使用を得る(get unused)」命令の場合、最長時間未使用のセッションのステータスがフェッチされる（ステップ３４４）。もしセッションが使用中であるならば（ステップ３５０）、そのセッションは閉じられる（ステップ３４８）。もしセッションが使用中でないならば、ｈｅａｄ＿ＬＲＵ＿ｉｎｄｅｘ＿ｒｅｇは、最長時間未使用のセッションの次のＬＲＵポインタに設定され、次の（前のＬＲＵポインタ）(next (previous LRU pointer))はヌルに設定される（ステップ３５２）。次に、除去されたセッションの次のＬＲＵポインタと前のＬＲＵポインタが、ヌルに設定され、それにより、最長時間未使用のセッションをＬＲＵリンクリストから除去する（ステップ３５４）。ｕｎｕｓｅｄ＿ｓｅｓ変数は、ちょうど切り離されたセッションに設定され、従って、ＣＰＵ又は主フィルター処理に知らせるフラグは、「１」に設定される（ステップ３５６）。次に、プロセスはアイドルに戻る（ステップ３５８）。

ＣＰＵからの「タイムアウトをチェック(check timeout）」コマンドは、セッションマネージャにセッションのタイムアウトのチェックを開始させる。ｉｎｄｅｘ＿ｃｏｕｎｔｅｒがインクリメントされ（ステップ３６２）、セッションのステータスがフェッチされる（すなわちｉｎｄｅｘ＿ｃｏｕｎｔｅｒ）（ステップ３６４）。もしセッションが現在使用中であるならば（ステップ３６６）、セッションのタイムスタンプがフェッチされる（ステップ３７２）。もしタイムスタンプが実際の時間よりも大きい（すなわちセッションがエージオーバーした）ならば（ステップ３７４）、セッションが閉じられる（ステップ３７６）。

もしセッションが使用されていないか又はセッションがエージオーバーしていないならば、ｉｎｄｅｘ＿ｃｏｕｎｔｅｒが最後のインデックスよりも小さいか否かがチェックされる（ステップ３６８）。もし肯ならば、ｉｎｄｅｘ＿ｃｏｕｎｔｅｒがインクリメントされ（ステップ３７０）、本方法はステップ３６４を続ける。もし否ならば、タイムアウトのチェックは完了し、主フィルター処理に通知され（ステップ３６０）、本方法はアイドルに戻る（ステップ３５８）。

図２０は、セッションを開くために本発明のセッション管理モジュールによって実行される処理を示すフローチャートである。セッションが開かれるとき、それはＬＲＵリンクリストの末尾に配置される（ステップ３８０）。セッションはまた、ハッシュリンクリスト中の適当な場所にも配置される（ステップ３８２）。次に、本方法はアイドル状態に戻る（ステップ３８４）。

図２１は、セッションを閉じるために本発明のセッション管理モジュールによって実行される処理を示すフローチャートである。もしセッションがＨＬＤフラグにより規定されたように閉じることができるならば、ＬＲＵポインタの変更なしにセッションが消去される（ステップ３９２）。次に本方法はアイドル状態に戻る（ステップ４０４）。

もしセッションを閉じることができず、閉鎖のリクエストがタイムアウトのチェックに起因していたならば（ステップ３９０）、セッションは閉じられず（ステップ３９６）、本方法はアイドル状態に戻る（ステップ４０４）。もし閉鎖リクエストがタイムアウトのチェックに起因したものでないならば、最長時間未使用のセッションにより指示された次のセッションがフェッチされる（ステップ３９８）。もしこのセッションを閉じることができないならば（ステップ４００）、本方法はステップ３９８を続け、本プロセスは、閉じられ得るセッションが見つかるまで繰り返される。もし閉じられ得るセッションが見つかれば（ステップ４００）、セッションはＬＲＵとして構成される（ステップ４０１）。次に、セッションはＬＲＵポインタを除いて消去され（ステップ４０２）、そして本方法はアイドル状態に戻る（ステップ４０４）。

上述したように、セッション管理モジュールもまた、セッションのファミリ関係を定めるセッションデータベース中の４つのファミリ関係ポインタを維持するべく機能する。セッションの閉鎖の際に、ファミリ関係ポインタが更新される。図２２は、セッションに対するファミリポインタの説明図である。各々のセッションは、親セッションを指示する親ポインタ、親からその第１子を指示する第１子ポインタ、及び同じ親を持ったセッション間にて二重リンクリストを実現するのに用いられる次／前の兄弟ポインタを有し得る。

ファミリ関係ポインタ情報を記憶するために、セッションデータベース中のフィールド３３〜３６が用いられる。ファミリ関係自体はＣＰＵによって決められる。従って、もしセッションがセッションマネージャによって（すなわちタイムアウトのチェックゆえに、又は新しいセッションのための余地を作るために）閉じられるならば、セッションマネージャは、ファミリポインタを更新する機能を有する。

本発明によると、同じアプリケーションに属するセッション間を論理接続するために、ファミリポインタが使用される。例えば、ＦＴＰサービスは、２つの異なるＴＣＰ／ＩＰセッション、すなわちポート２１上の制御セッションとポート２０上のデータセッションを開く。ＦＴＰ制御は親セッションであり、一方、ＦＴＰデータは子セッションである。一般に、子フィールド（１０）の数と共に４つのファミリポインタを用いて、任意のファミリ関係が可能である、すなわち、任意のネスティングの親／子アプリケーションがサポートされる。親セッションがＬＲＵ／タイムアウト機構を介して閉じられる場合、ファミリに属する後続作成セッションのすべてを閉じるために、セッションマネージャはファミリポインタを使用する。

しばしば、すべての接続が同時に使用されるわけではない。例えば、ある期間、子セッションのみを用いてアプリケーションが接続可能である。ＬＲＵ／タイムアウト機構により親制御セッションを閉じることを避けるために、ＣＰＵが親セッション中のＨＬＤビットを設定する。セッションマネージャは、開かれた子セッション（すなわち子の数＞０）を有するセッションは閉じず、そのＨＬＤビットがアサートされる。ファミリセッションの一つが閉じられるとき、セッションマネージャは、すべてのファミリポインタを維持する、すなわち（もし存在すれば）その子セッションすべてを閉じ、（もし存在すれば）ファミリ兄弟セッションの二重リンクリストを更新し、（もし存在すれば）その親セッションの子の数をデクリメントし、親／第１子の二重リンクリストを更新する機能を有する。

図２３は、複数のセッション間のファミリ関係の例を示す説明図である。この例では、親セッションは子セッションに関係付けられ、この子セッションは２つの兄弟セッションに関係付けられる。第１子セッションは、子セッションを有する親セッションでもあり、この子セッションは、上の親セッションの孫である。

コンピュータ実施態様
別の実施態様では、コンピュータは、本発明の動的パケットフィルター方法を実施するソフトウエアを実行する機能を有する。図２４は、本発明のセッション追跡方法を用いて動的パケットフィルタリングを実行するプラットフォームのコンピュータ処理システムの例を示すブロック図である。本システムは、ＰＤＡ、携帯電話、ケーブルモデム、ブロードバンドモデム、ラップトップ、ＰＣ、ネットワーク送信若しくは交換装置、ネットワーク装置、又は他の有線若しくは無線通信装置などの通信装置内に組み込むことができる。この通信装置は、ハードウエア及び／又はソフトウエアの任意の組合わせを用いて構成し得る。

全体的に符号２６０で示されたコンピュータシステムは、プロセッサ２６４を含み、このプロセッサ２６４は、マイクロコントローラ、マイクロプロセッサ、マイクロコンピュータ、ＡＳＩＣコア、ＦＰＧＡコア、中央処理装置（ＣＰＵ）又はデジタル信号プロセッサ（ＤＳＰ）として実現し得る。本システムは、スタティック読出し専用メモリ（ＲＯＭ）２６６とダイナミック主メモリ（例えばＲＡＭ）２７０とをさらに備え、これらはすべてプロセッサと通信する。プロセッサはまた、これもコンピュータシステム中に含まれるいくつかの周辺装置とバス２６２を介して通信する。

この装置は、インターネットなどのＷＡＮ２８０にＷＡＮインターフェース２７２を介して接続される。このインターフェースは、１以上のＷＡＮ通信チャンネルへの有線及び／又は無線インターフェースを備える。通信Ｉ／Ｏ処理２７４は、ＷＡＮインターフェースとプロセッサの間でデータを転送する。コンピュータシステムは、運用に依存してネットワークインターフェースカード（ＮＩＣ）２７１を介してＬＡＮ２７３にも接続される。動作中、コンピュータシステムは、上述のようにＷＡＮからＬＡＮに入ってくるパケット、及びＬＡＮからＷＡＮに出ていくパケットを動的にフィルタリングする機能を有する。

オプションのユーザーインターフェース２７６は、ユーザー入力に応答し、フィードバックと他のステータス情報とを与える。ホストインターフェース２７８は、ホストコンピュータ装置２８２を本システムに接続する。ホストは、システムの動作を構成、制御及び維持する。システムはまた、アプリケーションプログラムとデータを記憶するための磁気記憶装置２６８を備える。システムは、コンピュータ読出し可能な記憶媒体を備え、この記憶媒体としては、限定するものではないが磁気記憶装置、光記憶装置、ＣＤ−ＲＯＭドライブ、ＺＩＰドライブ、ＤＶＤドライブ、ＤＡＴカセット、半導体揮発性若しくは不揮発性メモリ、生体記憶(biological memory) 装置、又は他の任意のメモリ記憶装置を含めて、任意の適当なメモリ手段が挙げられる。

本発明の動的フィルターの機能を実現するために更新されるソフトウエアは、ディスクドライブ装置内の磁気ディスクなどのコンピュータ読出し可能な媒体上に存在し得る。別法として、コンピュータ読出し可能な媒体として、フロッピーディスク、フラッシュメモリカード、ＥＰＲＯＭ、ＥＥＲＯＭ、ＥＥＰＲＯＭベースのメモリ、バブルメモリ記憶装置、ＲＯＭ記憶装置などが挙げられる。本発明の動的パケットフィルター方法を実行するソフトウエアはまた、スタティック若しくはダイナミック主メモリ内、又はコンピュータシステムのプロセッサ内のファームウエア内（すなわち、マイクロコントローラ、マイクロプロセッサ、マイクロコンピュータ、ＤＳＰなどの内部メモリ内）に全部又は一部が存在し得る。

別の実施態様では、本発明の方法は、集積回路、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、チップセット若しくは特定用途向け集積回路（ＡＳＩＣ）、無線機器、及び他の通信システム製品において、本発明の実施に適用し得る。

添付の特許請求の範囲は、本発明の思想及び範囲内にある本発明の特徴及び利点のすべてに及ぶものである。当該技術の習熟者ならば多くの変更を容易に行えるであろうから、本発明はここに記載の限定された数の実施態様に制限されるものではない。よって、適切なあらゆる変形物、修正物及び均等物が本発明の思想及び範囲内にあることが理解されよう。

ＷＡＮ又はインターネットとの関連において本発明の動的パケットフィルターのいくつかの適用例を示すブロック図である。本発明の動的パケットフィルターをさらに詳細に示したブロック図である。本発明の主フィルタープロセッサ法を示すフローチャートである。一致が見つかった場合の本発明の主フィルタープロセッサ法を示す状態遷移図である。一致が見つからなかった場合の本発明の主フィルタープロセッサ法を示す状態遷移図である。入力パケットに関連したセッションを決めるハッシング技術を示す図である。本発明のセッション認識プロセスのハッシング方法を示すフローチャートである。本発明のセッション認識プロセスのホールサーチ方法を示すフローチャートである。ＴＣＰセッションのパケットフローを示す図である。ＴＣＰセッションを開く際の３−ウエイハンドシェイクを示す状態遷移図である。ＴＣＰセッションを閉じる際の４−ウエイハンドシェイクを示す状態遷移図である。ＴＣＰセッションを閉じる際の４−ウエイハンドシェイクを示す状態遷移図である。ＡＲＰセッションのパケットフローを示す図である。ＩＣＭＰエコーセッションのパケットフローを示す図である。ＩＣＭＰメッセージ／エラーセッションのパケットフローを示す図である。主フィルタープロセッサによる規則のチェック中に行われるシーケンス番号のウインドウ追跡を示す図である。主フィルタープロセッサによる規則チェック中に行われる肯定応答シーケンス番号のウインドウ追跡を示す図である。セッションの古さを追跡するのに用いられる最長時間未使用のリンクリスト構造を示す図である。入力パケットに関連したセッションを認識したときＬＲＵリンクリストを更新する方法を示すフローチャートである。本発明のセッション管理モジュールの処理を示すフローチャートである。セッションを開くために本発明のセッション管理モジュールにより実行される処理を示すフローチャートである。セッションを閉じるために本発明のセッション管理モジュールにより実行される処理を示すフローチャートである。セッションに対するファミリーポインタを示す図である。複数のセッション間のファミリー関係の例を示す図である。本発明のセッション追跡方法を用いて動的パケットフィルタリングを実行するのに適応したプラットフォームに対するコンピュータ処理システムの例を示すブロック図である。

符号の説明

１０ＷＡＮ／インターネット
１２ＰＤＡ
１４、２０、２８ファイアウォール
１６、２２、３０動的フィルター
１８ケーブル・プラグ・アダプタ
２４ブロードバンドモデム
２６、３２ＬＡＮ
３１コンピュータ
４０動的フィルター
４２ホスト装置／ＣＰＵ
４６ヘッダー復号器
４７バス
４８バス・インターフェース
５０バッファ／レジスタ
５１静的フィルター
５２セッション認識モジュール
５３コンテンツ・サーチ・ユニット
５４主フィルター処理モジュール
５６セッション管理モジュール
６０ハッシュテーブル
６２ホールテーブル
６４セッションデータベース

Claims

各セッションがソケットに対応している複数のセッションに対して、セッションに関係したデータを記憶するセッションデータベースを設けるステップ；
前記セッションデータベースに前に記憶されていないソケットを受信すると、新しいセッションを開くステップ；
受信パケットに関連したセッションをその関連ソケットに従って認識するステップ；
前記受信パケットに対応したセッションデータを複数の所定規則に従って処理して処理結果を生成するステップ；及び
前記処理結果に従って前記受信パケットを許可するか又は拒否するかを決定するステップ
を含む、入力パケットストリームのフィルタリング方法であって、
最長時間未使用（ＬＲＵ）二重リンクリストを設定し維持するステップをさらに含み、このリストは先頭と末尾を有し、最短時間未使用のセッションは末尾に記憶され、最長時間未使用のセッションは先頭に記憶され、
複数のレコードを含んだホールテーブルを設定するステップをさらに含み、その各レコードは不完全なソケット情報の固有の部分集合を表し、前記セッションを認識するステップがホールテーブルを調べることによりホールセッションを認識することを含むことを特徴とするフィルタリング方法。
前記処理結果に従って前記セッションデータベースの内容を更新するステップをさらに含む、請求項１に記載の方法。
前記決定ステップが、もし受信パケットが前記複数の所定規則のいずれにも違反していないならば前記受信パケットを許可することを含む、請求項１に記載の方法。
前記決定ステップが、もし受信パケットが前記複数の所定規則の１以上に違反しているならば前記受信パケットを拒否することを含む、請求項１に記載の方法。
前記セッションデータベースから未使用のセッションを除去するステップをさらに含む、請求項１に記載の方法。
前記ＬＲＵリストがいっぱいの場合、先頭のセッションが削除されて新しいセッションが末尾に加えられる、請求項１に記載の方法。
関連するタイムスタンプが所定のしきい値を越えたセッションを除去するステップをさらに含む、請求項１に記載の方法。
新しいセッションを開く前記ステップが、
前記セッションデータベース中に前記新しいセッションに関係したセッションデータを記憶するステップ；
前記新しいセッションに関連したソケットについてハッシュ値を計算するステップ；及び
ハッシュテーブル中に前記ハッシュ値を記憶するステップ
を含む、請求項１に記載の方法。
セッションを認識する前記ステップが、
認識されるセッションに関連したソケットについてハッシュ値を計算するステップ；
ハッシュ結果をインデックスとして用いてハッシュテーブル内のハッシュポインタを探すステップ；
前記ハッシュポインタに従って前記セッションデータベースからソケットデータを検索するステップ；及び
もし検索されたソケットが受信セッションに関連したソケットに一致するならば前記セッションを認識するステップ
を含む、請求項１に記載の方法。
前記セッションデータを処理する前記ステップが、もしセッションが伝送制御プロトコル（ＴＣＰ）の開設セッションを含むならば伝送制御プロトコル（ＴＣＰ）開設のハンドシェイクの状態を追跡することを含む、請求項１に記載の方法。
前記セッションデータを処理する前記ステップが、もしセッションが伝送制御プロトコル（ＴＣＰ）の閉鎖セッションを含むならば伝送制御プロトコル（ＴＣＰ）閉鎖のハンドシェイクの状態を追跡することを含む、請求項１に記載の方法。
前記セッションデータを処理する前記ステップが、もし前記セッションが伝送制御プロトコル（ＴＣＰ）セッションを含むならばウインドウに対して前記セッションのシーケンスと肯定応答を追跡することを含む、請求項１に記載の方法。
通信セッションの状態をモニターする方法であって、
各セッションがソケットに対応した複数のセッションに対して、セッションに関係するデータを記憶するセッションデータベースを設けるステップ；
受信パケットに関連したソケットについての第１ハッシュ計算に従ってセッションを認識するステップ；
前記受信パケットに関連した部分ソケットについての第２ハッシュ計算に従ってホールセッションを認識するステップ；
認識されたセッションか又は認識されたホールセッションのどちらかに関連した前記セッションデータを前記セッションデータベースから読み出すステップ；
前記セッションの接続状態を追跡し、複数の規則に基づいて前記状態をチェックして前記受信パケットの許否を決定するステップ；及び
更新されたセッションデータを元の前記セッションデータベースに書き込むステップ
を含む前記方法において、
最長時間未使用（ＬＲＵ）二重リンクリストを設定し維持するステップをさらに含み、このリストが先頭と末尾を有し、最短時間未使用のセッションが末尾に記憶され、最長時間未使用のセッションが先頭に記憶されることを特徴とする方法。
前記許否を決定するステップが、もし前記受信パケットが前記複数の規則のいずれにも違反していないならば前記受信パケットを許可することを含む、請求項１３に記載の方法。
前記許否を決定するステップが、もし前記受信パケットが前記複数の規則の１以上に違反しているならば前記受信パケットを拒否することを含む、請求項１３に記載の方法。
前記セッションデータベースから未使用のセッションを除去するステップをさらに含む、請求項１３に記載の方法。
関連のタイムスタンプが所定のしきい値を越えたセッションを除去するステップをさらに含む、請求項１３に記載の方法。
新しいセッションを開く前記ステップが、
前記セッションデータベース中に前記新しいセッションに関係したセッションデータを記憶するステップ；
前記新しいセッションに関連したソケットについてハッシュ値を計算するステップ；及び
ハッシュテーブル中に前記ハッシュ値を記憶するステップ
を含む、請求項１３に記載の方法。
セッションを認識する前記ステップが、
認識されるセッションに関連したソケットについて前記第１ハッシュ値を計算するステップ；
前記第１ハッシュの結果をインデックスとして用いてハッシュテーブル中のハッシュポインタを探すステップ；
前記ハッシュポインタに従って前記セッションデータベースからソケットデータを検索するステップ；及び
もし検索したソケットが受信されたセッションに関連のソケットに一致するならば前記セッションを認識するステップ
を含む、請求項１３に記載の方法。
ホールセッションを認識する前記ステップが、
認識されるセッションに関連した前記部分ソケットについて前記第２ハッシュ値を計算するステップ；
前記第２ハッシュの結果をインデックスとして用いてハッシュテーブル中のハッシュポインタを探すステップ；
前記ハッシュポインタに従って前記セッションデータベースから部分ソケットデータを検索するステップ；及び
もし検索したソケットが受信されたセッションに関連する部分ソケットに一致するならば前記ホールセッションを認識するステップ
を含む、請求項１３に記載の方法。
前記接続状態を追跡する前記ステップが、もしセッションが伝送制御プロトコル（ＴＣＰ）の開設セッションを含むならば伝送制御プロトコル（ＴＣＰ）開設のハンドシェイクを追跡することを含む、請求項１３に記載の方法。
前記接続状態を追跡する前記ステップが、もしセッションが伝送制御プロトコル（ＴＣＰ）の閉鎖セッションを含むならば伝送制御プロトコル（ＴＣＰ）閉鎖のハンドシェイクを追跡することを含む、請求項１３に記載の方法。
前記接続状態を追跡する前記ステップが、もし前記セッションが伝送制御プロトコル（ＴＣＰ）セッションを含むならばウインドウに対して前記セッションのシーケンスと肯定応答を追跡することを含む、請求項１３に記載の方法。
各セッションがソケットに対応した複数のセッションに対して、セッションに関係したデータを記憶するセッションデータベース；
前記セッションデータベースにおいて関連ソケットが受信パケットのソケットと一致するセッションをサーチするセッション認識モジュール；
前記セッションデータベースにおけるセッションの追加、削除及び修正を含めて、前記セッションデータベースを維持するセッション管理モジュール；及び
受信パケットに対応したセッションの接続状態を追跡し、複数の規則に基づいて前記接続状態をチェックして前記受信パケットの許否を決定する機能を有する主フィルターモジュール
を備えた、入力パケットストリームをフィルタリングするための動的フィルターであって、
前記セッション管理モジュールが、最長時間未使用（ＬＲＵ）二重リンクリストを設定及び維持し、このリストは先頭と末尾を有し、その末尾には最短時間未使用のセッションが記憶され、その先頭には最長時間未使用のセッションが記憶され、
複数のレコードからなるホールテーブルをさらに含み、その各レコードが不完全なソケット情報の固有の部分集合を表し、前記セッション認識モジュールはまたホールテーブルを調べることによりホールセッションを認識することを特徴とする動的フィルター。
前記主フィルターが、前記受信パケットの許否の決定後に修正されたセッションデータを元の前記セッションデータベースに書き込む、請求項２４に記載の動的フィルター。
前記主フィルターが、もし前記受信パケットが前記複数の規則のいずれにも違反していないならば前記受信パケットを許可する、請求項２４に記載の動的フィルター。
前記主フィルターが、もし前記受信パケットが前記複数の規則の１以上に違反しているならば前記受信パケットを拒否する、請求項２４に記載の動的フィルター。
前記セッション管理モジュールが、前記セッションデータベースから未使用のセッションを除去する、請求項２４に記載の動的フィルター。
前記セッション管理モジュールが、関連するタイムスタンプが所定のしきい値を越えたセッションを除去する、請求項２４に記載の動的フィルター。
前記セッション管理モジュールが、セッション開設手段を備え、該手段が、
前記セッションデータベースにおいて前記新しいセッションに関係したセッションデータを記憶し；
前記新しいセッションに関連したソケットについてハッシュ値を計算し；そして
ハッシュテーブル中に前記ハッシュ値を記憶する、
請求項２４に記載の動的フィルター。
前記セッション認識モジュールが、
認識されるセッションに関連するソケットについてハッシュ値を計算し；
ハッシュ結果をインデックスとして用いてハッシュテーブル中のハッシュポインタを探し；
前記ハッシュポインタに従って前記セッションデータベースからソケットデータを検索し；かつ
もし検索したソケットが受信セッションに関連したソケットに一致するならば前記セッションを認識する手段
を備える、請求項２４に記載の動的フィルター。
前記主フィルターが、もしセッションが伝送制御プロトコル（ＴＣＰ）開設セッションを含むならば伝送制御プロトコル（ＴＣＰ）開設のハンドシェイクの状態を追跡するための手段をさらに備える、請求項２４に記載の動的フィルター。
前記主フィルターが、もしセッションが伝送制御プロトコル（ＴＣＰ）閉鎖セッションを含むならば伝送制御プロトコル（ＴＣＰ）閉鎖のハンドシェイクの状態を追跡するための手段を備える、請求項２４に記載の動的フィルター。
前記主フィルターが、もし前記セッションが伝送制御プロトコル（ＴＣＰ）セッションを含むならばウインドウに対して前記セッションのシーケンスと肯定応答を追跡するための手段を備える、請求項２４に記載の動的フィルター。
前記動的フィルターが、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）にて実現される、請求項２４に記載の動的フィルター。
前記動的フィルターが、特定用途向け集積回路（ＡＳＩＣ）にて実現される、請求項２４に記載の動的フィルター。
デジタルコンピュータ装置であって、
前記装置を広域ネットワーク（ＷＡＮ）に接続する通信手段；
揮発性メモリと１以上のアプリケーションプログラムを記憶するのに適応した不揮発性メモリとを含んだメモリ手段；
前記１以上のアプリケーションプログラムを実行するために前記メモリ手段と前記通信手段に接続されたプロセッサ；及び
入力パケットストリームをフィルタリングするための動的フィルター
を備え、該動的フィルターが、
各セッションがソケットに対応した複数のセッションに対して、セッションに関係したデータを記憶するセッションデータベース；
前記セッションデータベースにおいて、関連ソケットが受信パケットのソケットに一致するセッションをサーチするセッション認識モジュール；
前記セッションデータベースにおけるセッションの追加、削除及び変更を含めて前記セッションデータベースを維持するセッション管理モジュール；及び
受信パケットに対応するセッションの接続状態を追跡し、複数の規則に基づいて前記接続状態をチェックして前記受信パケットの許否を決定する機能を有する主フィルターモジュール
を備え、前記セッション管理モジュールが、最長時間未使用（ＬＲＵ）二重リンクリストを設定及び維持し、このリストは先頭と末尾を有し、その末尾には最短時間未使用のセッションが記憶され、その先頭には最長時間未使用のセッションが記憶され、
複数のレコードからなるホールテーブルをさらに含み、その各レコードが不完全なソケット情報の固有の部分集合を表し、前記セッション認識モジュールはまたホールテーブルを調べることによりホールセッションを認識することを特徴とする前記デジタルコンピュータ装置。
コンピュータ読出し可能な記憶媒体であって、その上に具現化されたコンピュータプログラムを有し、適切にプログラミングされたシステムに複数のストリングをサーチさせ、該サーチは、前記プログラムが前記システム上にて実行される際に以下のステップ、すなわち
各セッションがソケットに対応した複数のセッションに対して、セッションに関係したデータを記憶するセッションデータベースを設けるステップ；
前記セッションデータベース中に前に記憶されていないソケットを受信すると新しいセッションを開くステップ；
受信パケットに関連したセッションをその関連ソケットに従って認識するステップ；
前記受信パケットに対応したセッションデータを複数の所定規則に従って処理して処理結果を生成するステップ；及び
前記処理結果に従って前記受信パケットの許否を決定するステップ
を実施することにより行われる前記コンピュータ読出し可能な記憶媒体において、
前記サーチでは、最長時間未使用（ＬＲＵ）二重リンクリストを設定し維持するステップをさらに含み、このリストは先頭と末尾を有し、最短時間未使用のセッションは末尾に記憶され、最長時間未使用のセッションは先頭に記憶され、
複数のレコードを含んだホールテーブルを設定するステップをさらに含み、その各レコードは不完全なソケット情報の固有の部分集合を表し、前記セッションを認識するステップがホールテーブルを調べることによりホールセッションを認識することを含むことを特徴とする前記コンピュータ読出し可能な記憶媒体。