(57)【特許請求の範囲】
【請求項１】
通信システム内のノードで受信されたフラグメントを処理するための方法であって、
（ａ）受信シーケンスで１つまたは複数のフラグメントのグループを受信するステップであって、
１つまたは複数のフラグメントのグループが、増加するフラグメントオフセット値に対応するオフセット順序を有するフラグメントセットへと断片化されたパケットに対応し、
フラグメントセットが、オフセット−０フラグメントと、１つまたは複数の追加のフラグメントとを備え、
オフセット−０フラグメントが、フラグメントセットのオフセット順序で第１のフラグメントであり、
グループが、オフセット−０フラグメントの前に受信される少なくとも１つの追加のフラグメントを備える、ステップと、
（ｂ）１つまたは複数のフラグメントのグループをバッファリングするステップと、
（ｃ）バッファリングされたグループについて適合する規則を見つけるために規則セットを解析するステップと、
（ｄ）適合した規則をバッファリングされたグループに適用して、（ｉ）バッファリングされたグループが転送されるべきかどうか判断し、（ｉｉ）バッファリングされたグループが転送されるべき場合は、バッファリングされたグループをどのように転送すべきか決定するステップとを備え、
規則セットが、オフセット−０フラグメントの前に少なくとも１個の追加のフラグメントが受信されるかどうかに関係なく、単一のパケットに対応する受信フラグメントが、受信フラグメントが受信された受信シーケンスで転送されることを規定する第１の規則を備え、バッファリングされたグループに第１の規則が適用される場合は、オフセット−０フラグメントが、転送されるべきバッファリングされたグループの第１のフラグメントとならない、方法。
【請求項２】
フラグメントセットが、１つまたは複数のフラグメントのグループの一部でない１つまたは複数のフラグメントを備える、請求項１に記載の方法。
【請求項３】
通信システム内のノードで受信されたフラグメントを処理するための方法であって、
（ａ）フラグメントのグループを受信するステップであって、
それぞれのフラグメントグループが、増加するフラグメントオフセット値に対応するオフセット順序を有するフラグメントセットへと断片化された異なるパケットに対応し、
それぞれのフラグメントセットが、オフセット−０フラグメントと、１つまたは複数の追加のフラグメントとを備え、
オフセット−０フラグメントが、フラグメントセットのオフセット順序で第１のフラグメントである、ステップと、
（ｂ）フラグメントグループをバッファリングするステップと、
（ｃ）バッファリングされた各グループについて適合する規則を見つけるために規則セットを解析するステップと、
（ｄ）対応する適合した規則をバッファリングされた各グループに適用して、（ｉ）バッファリングされたグループが転送されるべきかどうか判断し、（ｉｉ）バッファリングされたグループが転送されるべき場合は、バッファリングされたグループをどのように転送すべきか決定するステップとを備え、規則セットが、
単一のパケットに対応する受信フラグメントが転送の前にリアセンブルされるべきと規定する第１の規則と、
単一のパケットに対応する受信フラグメントが転送の前にリアセンブルされるべきでないと規定する第２の規則とを備える、方法。
【請求項４】
フラグメントグループが第１のグループと第２のグループとを備え、
ステップ（ｃ）が、（ｉ）バッファリングされた第１のグループに適合する第１の規則を見つけ、（ｉｉ）バッファリングされた第２のグループに適合する第２の規則を見つけ、したがって、
バッファリングされた第１のグループが、転送される前にリアセンブルされ、
バッファリングされた第２のグループが、転送される前にリアセンブルされない、
請求項３に記載の方法。
【請求項５】
ステップ（ｃ）が、オフセット−０フラグメント内の情報に基づいて、バッファリングされた各グループについて、対応する適合した規則を決定するステップを備える、請求項３に記載の方法。
【請求項６】
第１の規則が、
単一のパケットに対応するリアセンブルされたフラグメントが転送の前に再断片化されるべきと規定する第１の下位規則と、
単一のパケットに対応するリアセンブルされたフラグメントが転送の前に再断片化されるべきでないと規定する第２の下位規則とを備える、請求項３に記載の方法。
【請求項７】
フラグメントグループが第１のグループと第３のグループとを備え、
ステップ（ｃ）が、（ｉ）バッファリングされた第１のグループに適合する第１の規則および第１の下位規則を見つけ、（ｉｉ）バッファリングされた第３のグループに適合する第１の規則および第２の下位規則を見つけ、
バッファリングされた第１のグループが、転送される前にリアセンブルされ、次いで再断片化され、
バッファリングされた第３のグループが、転送される前にリアセンブルされるが、次いで再断片化されない、
請求項６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信に関し、具体的には、デジタル通信網内のパケットのルーティングおよびフィルタリングに関する。
【背景技術】
【０００２】
インターネットなどのパケット交換網では、送信元と宛先の間のトラフィックは、１つまたは複数の個別の単位、すなわちデータグラムの形である。データグラムの生成は一般に、連携して働く複数のソフトウェアプロトコルによって実施される。これらのプロトコルは一般に、垂直のレイヤスタックとして視覚化される。それぞれの層／プロトコルは、隣接した層／プロトコルからデータグラムを受け取り、そのデータグラムに対して特定の１組の１つまたは複数のタスクを実施し、次いで、結果として生じるデータグラムをスタック内の次の層／プロトコルに引き渡す。
【０００３】
図１は、インターネットの５層プロトコルスタック、スタック内のプロトコルがどのようにデータグラムをフォーマットするか、それらのプロトコル層がどのように現実世界の物に対応するか、およびデータグラムがどのようにインターネットを介して送信元から宛先にルーティングされるかについて図で示している。
【０００４】
慣習によりプロトコル層は、下から上へと番号が付けられ、物理層１０２が第１、データリンク層１０４が第２、ネットワーク層１０６が第３、トランスポート層１０８が第４、アプリケーション層１１０が第５で最後である。
【０００５】
動作において、送信元１１２から宛先１５０に送信されるデータはまず、送信元１１２上でプロトコル層１１０−１０２を通って上から下に移動する。データは、送信元アプリケーション層で発生する。たとえば、ウェブサーバコンピュータ１２６上で実行される送信元ウェブサーバソフトウェアアプリケーション１１４は、宛先１５０に、この場合にはラップトップコンピュータ１５６上で実行されるウェブブラウザソフトウェアアプリケーション１６０に向けられるハイパーテキスト転送プロトコル（ＨＴＴＰ：Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）アプリケーションデータ１１６を生成する。
【０００６】
ウェブサーバアプリケーションソフトウェア１１４は、アプリケーションデータ１１６をトランスポート層１０８に、この例では端末制御プロトコル（ＴＣＰ：Ｔｅｒｍｉｎａｌ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）層に渡す。ＴＣＰ層の責任は、（１）アプリケーションデータ１１２が送信元１１２から宛先１５０に正確に送信されるかどうか判断し、（２）そうでない場合は、再送を開始することである。送信元と宛先の両方で実行される複数のアプリケーションソフトウェアがあり得るが、ＴＣＰ層１０８は、指定されたＴＣＰポート番号、たとえば送信元ポート１１８および宛先ポートＡ４２を使用することによって、それぞれ異なるアプリケーションを区別する。送信元１１２で、ＴＣＰ層１０８は、アプリケーションデータ１１６（この場合はＨＴＴＰデータ）をＴＣＰペイロード１２２として扱い、ＴＣＰヘッダ１２０を先頭に追加することによってペイロード１２２をカプセル化し、このＴＣＰヘッダ１２０はとりわけ、ＴＣＰ送信元ポート番号１１８とＴＣＰ宛先ポート番号Ａ４２とを含む。一般に、特定のプロトコル層について、用語「ペイロード」は、データグラムヘッダまたはフッタ（存在する場合）の一部でないデータグラムの部分に言及する。したがって、ある層のペイロードは、プロトコルスタック内の次の上位層のペイロード、ヘッダおよびフッタ（存在する場合）を含む。
【０００７】
ＴＣＰは、結果として生じるＴＣＰデータグラム１２４をネットワーク層１０６に、この例ではインターネットプロトコル（ＩＰ）層に渡す。ＩＰ層のタスクは、あるネットワークアドレスから別のネットワークアドレスにＩＰデータグラムをルーティングすることである。ＩＰ層１０６は、ＴＣＰデータグラム１２４をＩＰペイロード１３０として扱い、ＩＰヘッダ１２８を先頭に追加することによってそのペイロードをカプセル化し、このＩＰヘッダ１２８は、とりわけ送信元ＩＰアドレスと宛先ＩＰアドレスとを含む。結果は、ＩＰデータグラムＡ２７である。
【０００８】
次に、ＩＰ層１０６は、ＩＰデータグラム１３２をデータリンク層１０４に渡し、この層は、あるハードウェアデバイスから別のハードウェアデバイスにデータを移動する役割を担う。この例ではデータリンクプロトコルはイーサネット（登録商標）であり、イーサネット（登録商標）デバイスは、ウェブサーバコンピュータ１２６内のイーサネット（登録商標）カード１３４である。データリンク層１０４は、ＩＰデータグラム１３２をイーサネット（登録商標）ペイロード１３８として扱い、イーサネット（登録商標）ヘッダ１３６を先頭に追加し、イーサネット（登録商標）フッタ１４０を末尾に追加することによってそのペイロードをカプセル化する。次いで、データリンク層１０４は、結果として生じるイーサネット（登録商標）データグラム１４２を物理層１０２を介して、この例では１０ＢａｓｅＴ物理層仕様に準拠する銅ケーブル１４４を介してインターネット１４６に送る。
【０００９】
送信元１１２と宛先１５０を接続するのはインターネット１４６である。インターネット１４６は、互いに接続されたルーティングアプリケーション（ルータ）１４８の集合として視覚化され得る。ルータ１４８は、データグラム内に置かれた情報に一部基づいて、送信元から宛先に各データグラムをそれぞれ独立にルーティングする。ルーティングプロセスの一環として、ルータは、データグラムへの修正を行うことができる。
【００１０】
イーサネット（登録商標）データグラム１４２は、インターネット１４６を通過すると、宛先１５０上で、逆の順序でプロトコルスタックを昇り、元のアプリケーションデータ１１６が宛先アプリケーション１６０に提示されるまで、ヘッダおよびフッタを取り除く（カプセル化解除）。具体的には、イーサネット（登録商標）ケーブル１５２は、イーサネット（登録商標）データグラム１４２をデータリンク（イーサネット（登録商標））デバイス１５４に引き渡す。イーサネット（登録商標）デバイス１５４は、イーサネット（登録商標）ヘッダ１３６およびイーサネット（登録商標）フッタ１４０を削除し、ネットワーク（ＩＰ）層１０６にＩＰデータグラム１３２を渡す。ネットワーク（ＩＰ）層１０６は、ＩＰヘッダ１２８を削除し、ＴＣＰデータグラム１２４をトランスポート（ＴＣＰ）層１０８に引き渡す。最後に、トランスポート（ＴＣＰ）層１０８は、ＴＣＰヘッダ１２０を廃棄し、アプリケーションデータ１１６をアプリケーション１６０に引き渡す。
【００１１】
図２は、図１のデータグラム１３２の分解図であり、ＩＰパケット断片化の結果を示している。ＩＰヘッダ１２８およびＴＣＰヘッダ１２０はそれぞれ、複数のフィールドを備える。送信元ＴＣＰポートフィールド２２０は、送信元ポート１１８を特定し、この送信元ポート１１８は、送信元アプリケーション１１４に応答をルーティングして返すために使用される。宛先ＴＣＰポートフィールド２２２は、宛先ポート１５８を特定し、この宛先ポート１５８は、宛先コンピュータ１５６上のアプリケーションソフト１６０にアプリケーションデータ１１６をルーティングするために使用される。
【００１２】
ＩＰヘッダ１２８は、数あるフィールドの中で特に、全長フィールド２０８を備え、この全長フィールド２０８は、ＩＰデータグラムＡ２７のサイズをバイトで示す。送信元ＩＰアドレスフィールド２０２および宛先ＩＰアドレスフィールド２０４は、それぞれ送信元デバイス１２６および宛先デバイス１５６のＩＰアドレスを含む。
【００１３】
ＩＰデータグラムのルーティングの間、たとえば伝送経路内の中間ネットワークまたはルータの制約を満たすために、こうしたデータグラムを分割して、より小さいＩＰデータグラムのシーケンスにすることが時々必要である。この操作は、ＩＰパケット断片化と呼ばれる。断片化されていないＩＰデータグラムはパケットと呼ばれ、パケットの分割の結果生じるより小さい各ＩＰデータグラムは、フラグメントと呼ばれる。本明細書に言及されるように、単一のパケットに属する１組のフラグメントのオフセット順序は、そのパケット内でそれらのフラグメントが発生した順序である。
【００１４】
それぞれのフラグメントは完全なＩＰヘッダを所有するが、一般には、オフセット−０フラグメント２４６（すなわち断片化されたパケットの第１のフラグメント）だけが、元のパケット１３２からのＴＣＰヘッダ１２０を所有する。ＩＰ断片化の反対は、リアセンブル（すなわちその構成フラグメントからパケットを再構成すること）である。
【００１５】
インターネットなど、パケット交換網の重要な特徴は、それぞれのルータが、その特定の時点で最適な伝送経路であるとそのルータが決定したものに沿って特定のデータグラムをルーティングするということである。結果として、特定の送信元によって特定の宛先向けに送信されたデータグラムによって取られる伝送経路は、異なる時点において同じ送信元によって同じ宛先向けに送信された他のデータグラムによって取られる伝送経路と異なり得る。したがって、送信元が特定のシーケンス、たとえばオフセット順序でデータグラムを宛先に送ること、およびそれらの同じデータグラムが、本明細書では受信シーケンスと呼ばれる異なるシーケンスで宛先に到着することが可能である。さらに、宛先は、他のパケットに対応するデータグラムとインタリーブされた特定のパケットのフラグメントを受信することがある。しかしさらに、１つまたは複数のフラグメントは、その宛先に決して到着しないことがある。
【００１６】
したがって、宛先は、（１）どのフラグメントがどのパケットに属するか、（２）特定のパケットのすべてのフラグメントが受信されたかどうか、および（３）特定のパケットに属する１組のフラグメントのオフセット順序を決定する必要がある。この情報は、ＩＰヘッダ１２８の識別フィールド２０６、フラグメントオフセットフィールド２１０およびモアフラグメントフィールド２１２で見られる。
【００１７】
識別フィールド２０６は、パケットがインターネット上でアクティブである間、その送信元−宛先の対に一意である値（たとえば、この例では２１６）に設定される。特定のパケットのすべてのフラグメントは、パケットの識別値を継承する。
【００１８】
フラグメントオフセットフィールド（ＦＯ：Ｆｒａｇｍｅｎｔ  Ｏｆｆｓｅｔ）フィールド２１０は、ＩＰペイロードのデータ部分の冒頭に対するこのフラグメントのオフセットを８バイトの単位で示す。換言すると、フラグメントのフラグメントオフセット値は、元のパケットのデータ部分のどこに、このフラグメントのペイロードが生じたかを示す。したがって、フラグメントオフセット値は、オフセット順序でない受信フラグメントを適切なオフセット順序に並べ直すために使用されてよい。ＲＦＣ７９１、インターネットプロトコル仕様書によれば、断片化されていないパケットへのオフセットは０でなければならない。断片化されたパケットの第１のフラグメントへのオフセットもやはり０である（本明細書ではオフセット−０フラグメントと呼ばれる）。
【００１９】
モアフラグメントフィールド（ＭＦ：Ｍｏｒｅ  Ｆｒａｇｍｅｎｔｓ  ｆｉｅｌｄ）２１２、１ビットの真／偽フィールドは、このデータグラムの後に同じ識別値を有する別のデータグラムが（オフセット順序で）続くかどうか示す。ＲＦＣ７９１は、パケット、およびパケットの最後のオフセットフラグメントについて、０（偽）のＭＦ値を指定する。パケットの最後のオフセットフラグメントを除くすべてのフラグメントについて、ＲＦＣ７９１は、１（真）のＭＦ値を指定する。
【００２０】
たとえば、ＩＰパケット１３２（３２４バイトの全長および２０バイトのＩＰヘッダ長を有する）は、１４８バイトの最大伝送単位（ＭＴＵ：Ｍａｘｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｕｎｉｔ）でネットワークを通過し、次いで、ＩＰパケット１３２は、３つのフラグメント２４６、２６６および２８６に分割されてよく、そのそれぞれが、それ自体ＩＰデータグラムである。具体的には、３０４バイトのＩＰデータ１２４（ＴＣＰヘッダ１２０を含む）は、それぞれ１２８バイト、１２８バイトおよび４８バイトの３つの部分（１２０と２４４、２６４、および２８４）に分割される。次いで、それぞれの部分には、この例示の目的のために２０バイト長と仮定されるそれ自体のＩＰヘッダ（２３０、２５０、２７０）が先頭に追加されて、フラグメント２４６（１４８バイト）、２６６（１４８バイト）および２８６（６８バイト）がもたらされる。
【００２１】
フラグメントヘッダ２３０、２５０および２７０のフィールドの一部は、パケットＩＰヘッダ１２８内の対応するフィールドと同一である。具体的には、送信元ＩＰアドレス（２０２、２３２、２５２、２７２）、宛先ＩＰアドレス（２０４、２３４、２５４、２７４）、および識別（２０６、２３６、２５６、２７６）は、同一である。
【００２２】
フラグメントヘッダ２３０、２５０および２７０内の他のフィールドは、パケットＩＰヘッダ１２８内の対応するフィールドとは異なる。全長フィールド２３８、２５８および２７８は、断片化の効果を反映するように変化する。同様に、フラグメントオフセットフィールド２４０、２６０および２８０はこの時点で、フラグメントのオフセット順序を８バイトのブロックで反映する。最後に、モアフラグメントフィールド２４２、２６２および２８２はこの時点で、（１）断片化が生じたこと、および（２）フラグメント２８６が最後のオフセットフラグメントであることを示す。
【００２３】
断片化は、データグラムルーティングを複雑にする。ルータは日常的に、フラグメントからフラグメントへと複製されないデータ（たとえばＴＣＰヘッダ情報）を必要とする。したがって、ルータは、フラグメント内に含まれた情報だけを使用してそれがルーティングできないフラグメントを受信することがある。さらに、一部のルーティング操作は、ルータがパケットデータを修正すること（たとえばネットワークアドレス変換）を必要とし、したがって、ルータは、パケットの１つまたは複数のフラグメントを修正する必要があり得る。しかし、断片化は、単なるデータグラムルーティングよりも複雑化する。
【００２４】
ＩＰデータグラムの効率的なルーティングに加えて、今日インターネットを使用する多くの人々の第２の関心事は、ネットワークセキュリティである。通常、データグラムは、通信を混乱させ、あるいは保護されたデバイスおよび保護されたネットワークサービスへの無許可のアクセスを得るために操作され、意図的にインターネット上に取り入れられる。こうした「攻撃」は、様々な形で起こる。一例は、正当な通信を危険にさらし、さらには妨げるためにルータまたは他のデバイスを故意にデータグラムでいっぱいにするサービス拒否攻撃である。別の例は、なりすまし攻撃であり、このなりすまし攻撃では、１つまたは複数のデータグラムが信頼されまたは許可された送信元からきているように見せるためにＩＰとＴＣＰのヘッダが操作され、送信側に未許可のアクセスが与えられる。
【００２５】
したがって、伝送経路には、その機能がこうした攻撃を検出および／または防止することである要素、たとえばファイアウォールや侵入検出システム（ＩＤＳ：ｉｎｔｒｕｓｉｏｎ−ｄｅｔｅｃｔｉｏｎ  ｓｙｓｔｅｍ）が存在する場合が多い。一般に、ファイアウォールまたはＩＤＳは、受信されたデータグラムを、１つまたは複数の規則に対して評価する。受信されたデータグラムが１つまたは複数の規則を満たす場合は、それは通過する（再送のために処理される）が、そうでない場合は、それはドロップされる（廃棄される）。規則に従うデータグラムのこの選択的な通過およびドロップは、フィルタリングとして知られている。
【００２６】
フィルタリングは一般に、ゾーン、ステートフルインスペクション、およびアプリケーション層フィルタリングを伴う。ゾーンは、特定のインターフェースに許容可能な送信元ＩＰアドレスの範囲である。単一のインターフェースについて定義された複数のゾーンがあってよい。インターフェース上で受信されたデータグラムの送信元ＩＰアドレスが、そのインターフェースについて定義されたゾーンのうちのどのゾーン内にもない場合、データグラムはドロップされる。したがって、たとえば、インターフェースが２つのゾーン、１９２．１６８．１．１から１９２．１６７．１．１２７の送信元ＩＰアドレスを有するすべてのデータグラムを許容する第１のゾーンと、２０４で始まる送信元ＩＰアドレスを有するすべてのデータグラムを許容する第２のゾーンとをもつ場合、そのインターフェース上で受信された１９．６３．８．３０の送信元ＩＰアドレスを有するデータグラムはドロップされる。
【００２７】
ステートフルインスペクションは、孤立したデータグラムだけではなく、送信元と宛先の間の進行している通信状態、したがって現在のデータグラムと、もしあるならば、それに先行した関連データグラムとの関係をも検査する。たとえば、ステートフルインスペクションを実施するファイアウォールは、ファイアウォールの背後から開始された通信への応答ではないインバウンドデータグラムをドロップしてよい。ディープパケットインスペクションとしても知られているアプリケーション層フィルタリングは、通過／ドロップの決定を行うために、データグラムヘッダを超えて、アプリケーション層データを検査する。
【００２８】
データグラムルーティングの場合とまさに同様に、断片化は、データグラムフィルタリングのタスクを複雑にする。ＩＰパケットが断片化されているとき、規則によって必要とされるデータは、パケットのフラグメントのうちのいずれか１つまたは複数に位置することがある。さらに、一部のフラグメントシーケンスはそれ自体、それらの個々のフラグメントのコンテンツが無害に見える場合でも、ネットワーク要素に対して脅威を及ぼす。こうしたシーケンスは、偶然生じることも、標的とされたネットワークを厳密に調べ、損害を与え、またはそれに侵入しようとする攻撃者の意図により故意に作られることもある。たとえば、一部のファイアウォールフィルタをバイパスし、保護されたサービスへのアクセスを得るために、重複するフラグメントの特定のシーケンスが使用されてよい。同様に、オフセット順序でないフラグメントシーケンスは、ファイアウォールを回避し、またはサービス拒否攻撃でそれを圧倒するように設計され得る。
【００２９】
ルータ、ファイアウォールおよび侵入検出システムは、フラグメントのフィルタリングおよびルーティングのためのそれぞれ異なる戦略を採用する。より単純な戦略は、すべてのフラグメントを通過させること、オフセット順序でないすべてのフラグメントをドロップすること、またはすべての重複および／または複製フラグメントシーケンスを追跡およびドロップすることを含む。すべてのフラグメントを通過させることは、保護されたホストなどの下流のデバイスにフラグメント処理をシフトし、それによって、特定の通信が重要なリソースに到達することを阻止するというファイアウォールの目的がくじかれる。すべてのフラグメントをドロップすることは、断片化攻撃に対して有効であるだけではなく、多くの正当な通信を無効にする。オフセット順序でないすべてのフラグメントをドロップすることは同様に、過度に包括的であり、重複したフラグメント攻撃に対して保護しない。さらに、これらの戦略のいずれもが、より精巧なフラグメントフィルタリングまたはフラグメント修正を提供しない。
【００３０】
フラグメントフィルタリングおよびルーティングのためのより有効な戦略は、完全なリアセンブルである。ここでは、ルータが、特定のパケットのすべてのフラグメントをメモリ内にバッファリングし、オフセット順序でないどんなフラグメントをもオフセット順序に並べ直し、それらのフラグメントをリアセンブルして、損なわれていないパケットをもたらす。ルータは次いで、損なわれていないパケットをフィルタリング／ルーティングし、適切な場合にはパケットを再断片化し、結果として生じるデータグラムを適切な宛先に向けて再送する。
【００３１】
完全リアセンブルの１つの欠点は、それがリソース集約型であり、パケットのすべてのフラグメントが到着するのに要する時間の間、ルータがそのパケットのあらゆるフラグメントをメモリ内にバッファリングすることを必要することである。さらに、バッファリング、並べ直し、リアセンブルの行為は、処理リソースを消費する。
【００３２】
完全リアセンブルの別の欠点は、可視性である。完全リアセンブルは完全なパケットまたは１組のフラグメントをオフセット順序で再送するので、完全リアセンブルに入るデータグラムと、そこから出るデータグラムとの間に差がある場合が多い。こうしたデータストリームを監視する誰かが、動作中のファイアウォールがあると決定することができ、そのファイアウォールを攻撃し始めることができる。
【００３３】
完全リアセンブルの代替案は、オフセット−０フラグメントに含まれた情報に基づいてフラグメントをルーティングすることである。（フラグメント−０ルーティング）。こうした方法は、その教示全体が引用により本明細書に組み込まれる、米国特許第６，７９５，８６６号に詳述されている。この方法は、（もしあれば）オフセット−０フラグメントの前に到着するフラグメントだけをメモリ内にバッファリングする。もしオフセット−０フラグメントが到着するときは、この方法は、オフセット−０フラグメントのＩＰおよびＴＣＰヘッダに基づいてルーティング決定を行い、それに応じてそのフラグメントを再送する。次いで、この方法は、バッファリングされたいずれかのフラグメント、およびその後に受信されたいずれかのフラグメントにそのルーティング決定を適用する。したがって、一般に最初にルーティングされるオフセット−０フラグメントを例外として、フラグメントは、この方法によって、それらが受信された順序でルーティングされる。
【００３４】
フラグメント−０ルーティングには、完全リアセンブルに優るいくつかの利点がある。フラグメント−０ルーティングは、オフセット−０フラグメントの前に到着するものだけをバッファリングする必要はあるが、すべてのフラグメントをバッファリングする必要はなく、それによって、完全リアセンブルより少ないメモリリソースが消費される場合が多い。さらに、フラグメント−０ルーティングは、バッファリングされたフラグメントが最も遅いフラグメントの到着を待つ間アイドル状態にはなるのではなく、オフセット−０フラグメントの到着までに限ってアイドル状態になるので、平均して、完全リアセンブルより迅速である。最後に、完全なパケットを並べ直し、リアセンブルするステップが取り除かれ、オーバーヘッドが減少し、効率が高まる。
【００３５】
しかし、フラグメント−０ルーティングには、いくつかの欠点もある。第１に、この方法は、オフセット−０フラグメント以外の情報、たとえばアプリケーション層データに基づいてルーティング決定を行う能力を提供しない。第２に、この方法は、広範囲のフラグメントベース攻撃の検出または緩和をもたらさない。換言すると、フラグメント−０ルーティングは、フィルタリングを実施しない。第３に、この方法は、フラグメントの再送に優る完全な制御を提供しない。たとえば、システム管理者は、受信された順序で個々にではなく、完全にリアセンブルされたパケットとしてフラグメントを再送することを望むことがある。
【００３６】
これらの欠点のうちの第１の欠点（フラグメント−０フラグメント以外のフラグメントを検査すること）は、米国特許第７，０６５，０８６号で考慮されており、その教示全体が、引用として本明細書に組み込まれる。この方法は、フラグメント０に加えて他のフラグメントを検査することを示唆しているが、こうした検査がどのように行われるかについての詳細を提供していない。フラグメント−０ルーティングと同様に、この方法は、フィルタリングを実施せず、またフラグメントの再送に対する完全な制御をも提供しない。
【先行技術文献】
【特許文献】
【００３７】
【特許文献１】米国特許第６，７９５，８６６号
【特許文献２】米国特許第７，０６５，０８６号
【非特許文献】
【００３８】
【非特許文献１】ＲＦＣ７９１
【発明の概要】
【発明が解決しようとする課題】
【００３９】
本発明の一実施形態は、ステートフルパケットフィルタリングファイアウォールの性能を向上させるシステムを提供して、ファイアウォールが幅広い範囲の断片化ベースの攻撃およびプローブの検出および緩和をもたらすことを保証しながら、ファイアウォールフィルタリングのためにフラグメントを完全にまたは部分的にリアセンブルしなければならない頻度を減少させる。この手法は、アプリケーション層フィルタリングを実施するために、ファイアウォールが厳密なＴＣＰ状態の実施を課し、選択的にパケットを部分的または完全にリアセンブルすることを可能にする。
【課題を解決するための手段】
【００４０】
このシステムは、フラグメントに対してどんなアクションが取られるべきかファイアウォールが検査し決定できるほど十分なプロトコルヘッダおよびペイロードの情報が存在するまでフラグメントを収集し再順序付けすることによって動作する。
【００４１】
本発明の一実施形態は、フラグメントがどのように再送されるかに対する完全な制御をシステム管理者に提供することによって従来技術の欠点にも対処する。ファイアウォールフィルタリング規則の指示の下、たとえばフラグメントは、完全にリアセンブルされ、一様に再断片化されてもよいし、オフセット順序または受信された順序で増分的に再送されてもよい。
【００４２】
本発明の一実施形態は、潜在的なフラグメントベース攻撃に対する広範囲の保護をも提供する。フラグメントは、それらが互いに重複しておらず、またフラグメントシーケンスがＩＰパケットリアセンブルアルゴリズムの一般的な弱点を利用していないことを検証するために、それが受信されるときに検査される。受信側への潜在的な脅威を表す有効なフラグメントシーケンスは再順序付けされ、かつ／または完全にまたは部分的にリアセンブルされ、受信側への脅威を取り除きまたは減少させるフラグメントシーケンスへと再断片化される。可能性の高い攻撃を表す断片化されたシーケンスは、関連するパケットの後続のフラグメントと同様にブロックされる。
【００４３】
本発明の一実施形態では、通信システム内のノードは、受信シーケンスで１つまたは複数のフラグメントのグループを受信し、ここで、このグループは、増加するオフセット値に対応するオフセット順序を有するフラグメントセットへと断片化されたパケットに対応する。フラグメントセットは、オフセット−０フラグメント（すなわちフラグメントセットのオフセット順序における第１のフラグメント）と、オフセット−０フラグメントの前に受信される少なくとも１つの追加のフラグメントとを備える。ノードは、１つまたは複数のフラグメントのグループをバッファリングし、バッファリングされたグループについて適合する規則を見つけるために規則セットを解析し、適合した規則をバッファリングされたグループに適用して、（ｉ）バッファリングされたグループが再送されるべきかどうか判断し、（ｉｉ）バッファリングされたグループが再送されるべき場合は、バッファリングされたグループをどのように再送するか決定する。規則セットは、オフセット−０フラグメントの前に少なくとも１個の追加のフラグメントが受信されるかどうかに関係なく、単一のパケットに対応する受信フラグメントが受信シーケンスで再送されることを規定する第１の規則を備え、したがって、バッファリングされたグループに第１の規則が適用される場合、オフセット−０フラグメントは、再送されるべきバッファリングされたグループの第１のフラグメントとならない。
【００４４】
本発明の別の実施形態では、通信システム内のノードは、受信シーケンスで１つまたは複数のフラグメントのグループを受信し、ここで、このグループは、増加するオフセット値に対応するオフセット順序を有するフラグメントセットへと断片化されたパケットに対応し、グループは、フラグメントセットのサブセットである。ノードは、１つまたは複数のフラグメントのグループをバッファリングし、バッファリングされたグループを再送する。ノードは、グループに隣接していないさらなるフラグメントを受信し、そのさらなるフラグメントをバッファリングする。ノードは、そのグループおよびバッファリングされたさらなるフラグメントと共に単一の連続したフラグメントサブセットを形成する１つまたは複数の他のフラグメントを受信し、１つまたは複数の他のフラグメント、およびバッファリングされたさらなるフラグメントを再送する。
【００４５】
本発明の別の実施形態では、通信システム内のノードが、フラグメントのグループを受信し、フラグメントの各グループが、増加するフラグメントオフセット値に対応するオフセット順序を有するフラグメントセットへと断片化された異なるパケットに対応する。各フラグメントセットは、オフセット−０フラグメントと、１つまたは複数の追加のフラグメントとを備え、オフセット−０フラグメントは、フラグメントセットのオフセット順序で最初のフラグメントである。ノードは、フラグメントグループをバッファリングし、バッファリングされた各グループについて適合する規則を見つけるために規則セットを解析し、対応する適合した規則をバッファリングされた各グループに適用して、（ｉ）バッファリングされたグループが再送されるべきかどうか判断し、（ｉｉ）バッファリングされたグループが再送されるべき場合は、バッファリングされたグループをどのように再送するか決定する。規則セットは、単一のパケットに対応する受信されたフラグメントが、再送の前にリアセンブルされるべきと規定する第１の規則と、単一のパケットに対応する受信フラグメントが、再送の前にリアセンブルされるべきでないと規定する第２の規則とを備える。
【００４６】
本発明の別の実施形態では、通信システム内のノードが、受信シーケンスでフラグメントセットを受信し、フラグメントセットが、増加するフラグメントオフセット値に対応するオフセット順序を有するフラグメントセットへと断片化された異なるパケットに対応する。フラグメントセットは、オフセット−０フラグメントと、１つまたは複数の追加のフラグメントとを備え、オフセット−０フラグメントは、フラグメントセットのオフセット順序における第１のフラグメントである。フラグメントセットはオフセット順序外で受信され、追加のフラグメントのうちの少なくとも１つは、オフセット−０フラグメントの後に受信される。ノードは、フラグメントセットをバッファリングし、次いで、セット内のフラグメントのすべてが受信されバッファリングされるまでフラグメントのどれもが再送されないように、フラグメントセットをオフセット順序のフラグメントとして再送する。
【００４７】
本発明の別の実施形態では、通信システム内のノードは、増加するフラグメントオフセット値に対応するオフセット順序を有するフラグメントセットへと断片化されたパケットに対応する第１のフラグメントを受信する。フラグメントセットは、オフセット−０フラグメントと、１つまたは複数の追加のフラグメントとを備え、オフセット−０フラグメントは、フラグメントセットのオフセット順序で第１のフラグメントである。ノードは、（ｉ）第１のフラグメントについて適合する規則を見つけるために規則セットを解析し、（ｉｉ）適合した規則を適用して、第１のフラグメントを処理し、（ｉｉｉ）パケットに対応する第２のフラグメントを受信し、（ｉｖ）適合した規則を適用して、第２のフラグメントを処理し、第２のフラグメントの処理は第１のフラグメントの処理と異なる。
【００４８】
本発明の別の実施形態では、通信システム内のノードが、１つまたは複数のフラグメントの第１のグループを受信し、第１のグループが、第１のフラグメントセットへと断片化された第１のパケットに対応する。ノードは、第１のグループについて適合する第１の規則を見つけるために規則セットを解析し、適合した第１の規則を適用して、第１のグループを処理する。ノードは、１つまたは複数のフラグメントの第２のグループを受信し、第２のグループが、第１のパケットとは異なっており、第２のフラグメントセットへと断片化された第２のパケットに対応する。ノードは、第２のグループについて適合する第２の規則を見つけるために規則セットを解析し、適合した第２の規則を適用して第２のグループを処理し、第１のグループは再送され、第２のグループは再送されない。
【００４９】
本発明の他の態様、特徴および利点は、下記の詳細な説明、添付の特許請求の範囲、および添付の図面からより完全に明らかになろう。図面では、同じ参照符号は、類似のまたは同一の要素を特定する。
【図面の簡単な説明】
【００５０】
【図１】インターネットの５層プロトコルスタック、スタック内のプロトコルがどのようにデータグラムをフォーマットするか、それらのプロトコル層がどのように現実世界の物に対応するか、およびデータグラムがどのようにインターネットを介して送信元から宛先にルーティングされるかについて示す図である。
【図２】図１のデータグラム１３２の分解図であり、ＩＰパケット断片化の結果を示す図である。
【図３】本発明の一実施形態によるフラグメント処理システムのブロック図である。
【図４】図３の断片化されたパケットのリスト３０６の一実施形態の図である。
【図５】図３のフラグメント処理システムによって処理された一般的な断片化されたパケットの一般的なライフサイクルを表す要約フローチャートである。
【図６】図３のフラグメント処理プロセス３０２の一実施形態を表すフローチャートである。
【図７】図３のフラグメント処理プロセス３０２の一実施形態を表すフローチャートである。
【図８】図３のフラグメント処理プロセス３０２の一実施形態を表すフローチャートである。
【図９】図３のタイムアウト処理３０４の一実施形態のフローチャートである。
【発明を実施するための形態】
【００５１】
本発明の実施形態は、パケットおよびフラグメントの効率的なルーティング、ならびに悪意のある、そうでないにせよ不所望の通信の検出、防止および緩和のためのシステム、方法および装置として実施されてよい。
【００５２】
図３は、本発明の一実施形態による、フラグメント処理システム３００のブロック図である。システム３００は、フラグメント処理プロセス３０２と、断片化されたパケットのリスト３０６と、規則セット３０８と、セッション状態データベース３１２と、タイムアウトプロセス３０４と、フラグメントバッファ領域３１０とを備える。フラグメント処理システム３００は一般に、ルータ、たとえば図１のルータ１４８として実装される。
【００５３】
フラグメント処理プロセス３０２は、フラグメントを受信し、バッファリングし、ルーティングし、フィルタリングし、フラグメントおよび／またはパケット再送する。システム３００（図３に図示せず）の上流の処理は、データグラムのＩＰヘッダ内のフラグメントオフセットフィールド２１０およびモアフラグメントフィールド２１２を検査することによって、受信されたデータグラムがパケットか、それともフラグメントか決定する。またフラグメント処理プロセス３０２は、システム３００の他のコンポーネントと通信し、たとえば受信されたフラグメントをフラグメントバッファ領域３１０にバッファリングし、バッファリングされたフラグメントをそこから受信し、断片化されたパケットのリスト３０６にデータを書き込み、そこからのデータを要求し、フラグメント、および部分的にリアセンブルまたは完全にリアセンブルされたパケットを、規則マッチングのために規則セット３０８にサブミットする。
【００５４】
断片化されたパケット（ＦＰ：Ｆｒａｇｍｅｎｔｅｄ  ｐａｃｋｅｔ）のリスト３０６は、システム３００の他のコンポーネントから情報を受信し格納するデータ構造を含む。具体的には、ＦＰリスト３０６は、（１）受信されたフラグメントおよび現在の処理状態に関する、パケット処理プロセス３０２からの情報と、（２）規則マッチング時の規則セット３０８からのポリシー情報と、（３）フラグメントバッファ領域３１０内のフラグメントバッファへのポインタと、（４）タイムアウトプロセス３０４の操作からの結果とを受信し格納する。
【００５５】
規則セット３０８は、任意の数の規則を備えるデータ構造を含む。それぞれの規則は、１つまたは複数のデータグラム特性にマッチングされ、したがって、定義されたデータグラムセットだけに適用される。たとえば、２５のＴＣＰ宛先ポートを有するすべてのフラグメントについて、または１９．６３．０８．３０のＩＰ送信元アドレスを有するすべてのフラグメントにいての規則があってよい。データグラムについて適合する規則を選択するプロセスは、規則マッチングとして知られている。
【００５６】
規則は、任意の数のポリシーを備える。ポリシーは、フラグメント処理プロセス３０２に、対応する規則に適合するフラグメントまたはフラグメントセットをどのように処理するか指示する。フィルタおよび再送ポリシーを含めて、いくつかのタイプのポリシーがある。フィルタポリシーは、受信されたフラグメント（１つまたは複数）を評価し、通過／ドロップ判定を行う。たとえば、フィルタポリシーは、２５のＴＣＰ宛先ポートを有するどんなフラグメントをもドロップすることがある。フィルタポリシーは、フラグメントのＩＰおよびＴＣＰヘッダを超えて、アプリケーション層データを検査し、たとえば特定のＵＲＬを要求するすべてのフラグメントをドロップすることがある。
【００５７】
通過させるべきフラグメントについて、再送ポリシーは、再送される前にそれらのフラグメントがどのように処理されるべきか決定する。ある再送ポリシーは、特定のパケットについて受信されたフラグメントを、修正なしで、それが受信された正確な順序で再送するとする。たとえば、０、１、２、３、４を、オフセット順序でパケットの５つのフラグメントを表すものとする。フラグメントの受信順序が（１  ０  ２  ４  ３）であったならば、フラグメントは、順序（１  ０  ２  ４  ３）で再送される。こうした再送ポリシーは、ステルスモードで実行される侵入検出システムによって使用されることがあり、このステルスモードの目的は、データグラムを検査し、その存在を外部に見せずに潜在的な問題に対して他のデバイスに警告することである。
【００５８】
別の再送ポリシーは、すべてのフラグメントが受信されるまで、特定のパケットのフラグメントをバッファリングし、次いで、それらフラグメントをオフセット順序のフラグメントとして再送することであってよい。たとえば、パケットは、６つのフラグメントに断片化される。それらの６つが順序（１  ２  ３  ４  ０  ５）で受信される場合、システムは、６個のすべてのフラグメントが到着するまで待ち、次いで、それらのすべてのフラグメントを順序（０  １  ２  ３  ４  ５）のフラグメントとして再送する。この再送ポリシーは、アウトオブシーケンスのフラグメントシーケンスを利用する攻撃の防止に役立つと分かり得る。
【００５９】
しかし、別の再送ポリシーは、以前の再送ポリシーのようにすべてのフラグメントが到着するのをまず待つのではなく、受信されたフラグメントをオフセット０からのオフセット順序のフラグメントとしてできるだけすぐに再送することであってよい。たとえば、特定のパケットの最初の７個のフラグメントが順序（１  ２  ３  ４  ０  ６  ５）で受信されたと仮定する。システムは、フラグメント１、２、３および４をバッファリングする。フラグメント０の到着によって、オフセット０からの連続したフラグメントセットがもたらされ、したがって、システムは、その時点で、受信されたフラグメントをオフセット順序（０  １  ２  ３  ４）で再送する。次いで、システムは、フラグメント６がオフセット０からのデータと隣接していないので、フラグメント６を受信しバッファリングする。しかし、フラグメント５を受信すると、この時点でデータは連続しているので、システムは、２つのフラグメントをオフセット順序（５  ６）で再送する。
【００６０】
しかし、別の再送ポリシーは、完全なリアセンブルであり、すなわち特定のパケットのすべてのフラグメントを収集し、受信されたフラグメントをオフセット順序に並べ直し（必要な場合）、それらのフラグメントを単一のパケットへと完全にリアセンブルし、そのパケットを再送し得る。この再送ポリシーについてのさらなる変形例は、再送の前に、リアセンブルされたパケットを再断片化することであり、ここで、再断片化処理によっては、再断片化は、受信されたものとは異なるフラグメントセットをもたらすことがある。
【００６１】
適合した規則のポリシーがフィルタポリシーであれ、再送ポリシーであれ、他の何らかのタイプのポリシーであれ、適合した規則のポリシーを適用することは、規則適用として知られている。
【００６２】
規則セット３０８は、規則マッチングのためにフラグメント処理プロセスＹ０２から、フラグメント、および部分的にリアセンブルされ、または完全にリアセンブルされたパケットを受信し、もし規則が適合する場合にはポリシー情報をＦＰリストＹ０６に送信する。
【００６３】
セッション状態データベース３１２は、アクティブなセッションの状態を示す１つまたは複数のセッション状態記録を含む。セッションは一般に、データグラム間の時間が指定のタイムアウト値を超過しない、特定のトランスポートプロトコル（たとえばＴＣＰ、ＵＤＰ）を使用する２つの特定のＩＰアドレス間の通信として少なくとも定義される。しばしば、他のパラメータが、セッションの定義に追加される。たとえば、ＴＣＰセッションは一般に、上記にリストされたパラメータだけでなく、データグラムの送信元および宛先のＴＣＰポートからなる。したがって、タイムアウトの制約に違反しない、１９．６３．８．３０：８０と１２．３４．５６．７８：１１０３２の間で交換される１組のＴＣＰデータグラムは、一般的なＴＣＰセッションを構成する。
【００６４】
セッション状態記録は、規則マッチングの結果を記録する。すなわち、規則が１組のデータグラム特性（すなわちセッション）に適合した場合、その関連付けは、セッション状態データベース内に記録される。セッション状態データベースは、後続のセッションデータグラムに対してどんなアクションを取るべきか確認するのにフラグメント処理プロセスＹ０２によって必要とされる時間を著しく減少させる。
【００６５】
フラグメント処理プロセス３０２以外のプロセスが、セッション状態記録を作成することがある。たとえば、新しいセッションの第１の受信されたデータグラムが断片化されていないパケットである場合、フラグメント処理プロセス３０２ではなく、断片化されていないパケットを扱うプロセスが、その新しいセッションについてのセッション状態記録を作成する。
【００６６】
タイムアウトプロセス３０４は、ＦＰリスト３０６を周期的に検査し、指定された時間間隔より古いどんなデータをも修正する。
【００６７】
フラグメントバッファ領域３１０は、受信されたフラグメントが処理中にフラグメント処理プロセス３０２によって格納されるメモリ空間である。
【００６８】
図４は、図Ｙの断片化されたパケットのリスト３０６の一実施形態の図である。ＦＰリスト３０６は、それぞれが異なるパケットに関連付けられる任意の数のパケットエントリ（ＰＥ：Ｐａｃｋｅｔ  Ｅｎｔｒｙ）４０４を備える。ＰＥ  ４０４は、１つまたは複数のフラグメントエントリ（ＦＥ：ｆｒａｇｍｅｎｔ  ｅｎｔｒｙ）４６０、関連するパケットについて受信された各フラグメントにつき１つのフラグメントエントリに関連付けられる。それぞれのＦＥ  ４６０は、実際のフラグメントデータを格納する１つまたは複数のバッファ４８０に関連付けられる。ＦＰリスト３０６は、単独に連結されたリストとして示されているが、それは、複数のやり方で、たとえば二重連結リストでも実施され得る。
【００６９】
それぞれのＰＥ  ４０４は、複数のフィールドを備える。ＰＡＣＫＥＴ＿ＦＲＡＧＭＥＮＴ＿ＬＩＳＴフィールド４０６は、このＰＥに関する任意の数のフラグメントエントリ（ＦＥ）４６０のうちの第１のフラグメントエントリを指すポインタである。
【００７０】
ＩＰ＿ＰＡＣＫＥＴ＿ＩＤフィールド４０８は、受信されたフラグメントのＩＰヘッダの識別フィールド（たとえば図２のフィールド２３６）の値を含む。ＩＰ＿ＳＯＵＲＣＥ＿ＡＤＤＲＥＳＳフィールド４１０は、受信されたフラグメントのＩＰヘッダの送信元ＩＰアドレスフィールド（たとえば図２のフィールド２３２）の値を含む。ＺＯＮＥフィールド４１２は、送信元ＩＰアドレスと、パケットのフラグメントが受信されたインターフェースとを照合するファイアウォールゾーンを示す。これらの３つのフィールドは、ＦＰリスト内のあらゆるＰＥを一意に識別する鍵を構成する。
【００７１】
ＡＣＴＩＯＮ＿ＫＮＯＷＮフィールド４１４とＤＲＯＰフィールド４１６の両方は、真／偽のフィールドである。これらの２つのフィールドは共に、ＰＥアクションを示す。ＰＥアクションは、３つの関数：通過（ｐａｓｓ）、ドロップ（ｄｒｏｐ）または不明（ｕｎｋｎｏｗｎ）のうちの１つであってよい。具体的には、ＡＣＴＩＯＮ＿ＫＮＯＷＮが偽である場合、ＰＥアクションは、ＤＲＯＰの値にかかわらず不明である。ＡＣＴＩＯＮ＿ＫＮＯＷＮが真であり、ＤＲＯＰが真の場合、ＰＥアクションはドロップである。ＡＣＴＩＯＮ＿ＫＮＯＷＮが真であり、ＤＲＯＰが偽の場合、ＰＥアクションは通過である。ＰＥが初期化される場合、ＡＣＴＩＯＮ＿ＫＮＯＷＮとＤＲＯＰの両方が、偽に設定される。これらのフィールド内の値は、フラグメント処理プロセス３０２またはタイムアウトプロセス３０４によって変更されてよい。
【００７２】
ＰＥアクションが不明の場合、フラグメント処理プロセス３０２は、通過／ドロップ判定を行う前に、同じパケットのより多くのフラグメントを必要とする。したがって、このプロセスは、受信されたフラグメントをバッファリングし、同じパケットからのさらなるフラグメントを待つ。ＰＥアクションがドロップである場合、受信フラグメントは廃棄され、プロセスは、そのフラグメントに関してさらなるアクションを取らない。ＰＥアクションが通過である場合、受信されたフラグメントは、ＰＥに関連する再送ポリシーに従って処理され再送される。
【００７３】
ＮＥＸＴ＿ＯＦＦＳＥＴフィールド４１８は、このＰＥについて受信された、オフセット０からの連続するバイトの数を示す。一般に、新しい隣接フラグメントが受信されるごとに、ＮＥＸＴ＿ＯＦＦＳＥＴの値が更新される。一般に、受信時に、オフセット０から連続するどのデータにも隣接していないフラグメントが受信されると、ＮＥＸＴ＿ＯＦＦＳＥＴフィールド４１８は変更されない。
【００７４】
ＲＥＱＵＩＲＥＤ＿ＢＹＴＥＳフィールド４２０は、適合した規則を適用するのに必要なバイト数を示す。ＲＥＱＵＩＲＥＤ＿ＢＹＴＥＳは、０に初期化され、一般に、規則が適合すると更新され、状況によっては、その後に繰り返し更新され得る。
【００７５】
ＲＵＬＥ＿ＫＮＯＷＮフィールド４２２は、規則が適合したかどうか示す真／偽のフィールドである。ＲＵＬＥ＿ＫＮＯＷＮは偽に初期化され、もし規則が適合したならば、真に設定される。
【００７６】
ＨＯＬＥＳフィールド４２４は、受信されたフラグメントのセット内にいくつのギャップすなわち「穴」があるか示す。フラグメントが受信されたが、直前のオフセット順序フラグメントが受信されない場合、穴が作られる。たとえば、図２を参照すると、パケット１３２の第２のフラグメント（２６６）が受信されたが、第１のフラグメント（２４６）が受信されない場合は、ＨＯＬＥＳは１に等しい。同様に、パケットＡ２７の第１のフラグメント（２４６）および第３のフラグメント（２８６）が受信されたが、第２のフラグメント（２６６）が受信されない場合は、ＨＯＬＥＳはやはり１に等しい。適切な場合、ＨＯＬＥＳは、有効なフラグメントがＰＥに追加されるごとに０に初期化され更新される。ＭＡＸ＿ＨＯＬＥ＿ＳＩＺＥフィールド４２６は、このＰＥに許容される最大の穴のサイズをバイトで示す。この値を超過する穴が作られる場合、ＰＥアクションは、ドロップに変更される。たとえば、図２を参照すると、パケット１３２の第１（２４６）および第３（２８６）フラグメントが受信されたが、第２のフラグメント（２６６）が受信されない場合、１２８バイトの穴が作られる。ＭＡＸ＿ＨＯＬＥ＿ＳＩＺＥが６４バイトである場合、この１２８バイトの穴の作成によって、ＰＥアクションがドロップに変更されることになる。ＭＡＸ＿ＨＯＬＥ＿ＳＩＺＥは、ＰＥが初期化される場合にはゾーンデフォルトに、またはゾーンデフォルトがない場合にはシステムデフォルトに設定される。ＭＡＸ＿ＨＯＬＥ＿ＳＩＺＥは、規則が適合すると更新され得る。
【００７７】
ＳＡＷ＿ＬＡＳＴフィールド４２８は、最後のオフセットフラグメント（すなわち、０に設定されたＭＦフラグ、たとえば図２のフィールド２８２を有するフラグメント）が受信されたかどうか示す真／偽フィールドである。このフィールドは一般に、このパケットについてすべてのフラグメントが受信されたかどうかの判断を迅速化するのに使用される。それは偽に初期化され、もし最後のオフセットフラグメントが受信される場合には、真に更新される。
【００７８】
ＳＡＷ＿ＦＩＲＳＴフィールド４３０は、オフセット−０フラグメント（すなわち、０に設定されたフラグメントオフセットフィールド、たとえば図２のフラグメント２４６を有するフラグメント）が受信されたかどうか示す真／偽フィールドである。一般にこのフィールドは、規則マッチングにオフセット−０フラグメントが一般に必要とされるので、規則マッチングを迅速化するために使用される。
【００７９】
ＯＲＤＥＲＥＤフィールド４３２は、このＰＥについてこれまで受信されたフラグメントがオフセット順序で受信されたかどうか示す真／偽フィールドである。フラグメントがオフセット順序外で受信される場合、このフィールドは、偽に設定され、偽のままである。このＰＥについて適合した規則が厳密なオフセット順序でフラグメントが受信されることを必要とする場合、このフィールドによって、その条件が満たされたかどうかの判断が迅速化する。
【００８０】
ＯＰＴＩＯＮＳフィールド４３４は、もしあれば受信されたフラグメントが適合する規則の様々なポリシーを示す１つまたは複数のフラグの集合である。たとえば、ＯＰＴＩＯＮＳフィールド４３４内のフラグは、フラグメントがオフセット順序で受信されなければならないかどうか示してよい。そのフラグが真に設定される場合、フラグメントをオフセット順序外で受信すると、ＰＥアクションがドロップに変わる。ＯＰＴＩＯＮＳフィールド４３４は、ＰＥが作成されるとき、グローバルまたはゾーンデフォルトに初期化され、適合した規則が適用されるときに更新され得る。
【００８１】
ＯＰＴＩＯＮＳフィールド４３４と同様に、ＴＥＲＭＩＮＡＴＩＮＧ＿ＣＯＮＤＩＴＩＯＮＳフィールド４３６は、もしあれば受信されたフラグメントが適合した規則の様々なポリシーを示す１つまたは複数のフラグの集合である。たとえば、ＴＥＲＭＩＮＡＴＩＮＧ＿ＣＯＮＤＩＴＩＯＮＳ内のフラグは、閾値との組合せで、特定のパケットまたは１組のパケットについて受け取られる最大のフラグメント数を設定することができる。その数を超える場合、ＰＥアクションは、ドロップに変更される。
【００８２】
ＲＥＡＳＳＥＭＢＬＥフィールド４３８は、再送される前に、このパケットのすべてのフラグメントが完全にリアセンブルされなければならないかどうか示す真／偽フィールドである。ＲＥＦＲＡＧＭＥＮＴフィールド４４０は、このＰＥの完全にリアセンブルされたパケットが再送の間に再断片化されなければならないかどうか示す真／偽フィールドである。
【００８３】
ＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＣＯＬＬＥＣＴフィールド４４２は、ＰＥアクションが不明または通過のままであってよいミリ秒数、すなわち収集間隔を示す。新しいＰＥが作成されるとき、ＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＣＯＬＬＥＣＴ内の値が、現在のシステム時刻に追加され、合計がＴＩＭＥＯＵＴフィールド４４６に書き込まれる。
【００８４】
ＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＤＩＳＣＡＲＤフィールド４４４は、ＰＥアクションがドロップのままであってよいミリ秒数、すなわちドロップ間隔を示す。収集間隔の終了、または適合した規則の適用によってＰＥアクションがドロップに設定される（すなわちＡＣＴＩＯＮ＿ＫＮＯＷＮフィールド４１４とＤＲＯＰフィールド４１６の両方が真に設定される）とき、ＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＤＩＳＣＡＲＤ内の値が現在のシステム時刻に追加され、合計がＴＩＭＥＯＵＴフィールド４４６に書き込まれる。
【００８５】
ＴＩＭＥＯＵＴフィールド４４６は、現在のＰＥアクションが終了するときを示す。新しいＰＥが作成されるとき、ＴＩＭＥＯＵＴは、現在のシステム時刻に、ＤＲＯＰフィールド４１６の状態に応じてＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＣＯＬＬＥＣＴフィールド４４２またはＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＤＩＳＣＡＲＤフィールド４４４によって指定されたミリ秒数を足した値に等しい値に初期化される。タイムアウトプロセス３０４およびＴＩＭＥＯＵＴフィールド４４６についてのさらなる説明は、図９に関して下記に示される。
【００８６】
さらなるＰＥがない場合、ＮＥＸＴ＿ＩＮ＿ＬＩＳＴフィールド４４８は、ＦＰリスト内の次のＰＥ、またはＮＵＬＬを指すポインタである。
【００８７】
それぞれのフラグメントエントリ（ＦＥ）４６０は、複数のフィールドを備える。ＮＥＸＴ＿ＩＮ＿ＬＩＳＴフィールド４６２は、このＰＥについてさらなるＦＥがない場合、次のＦＥまたはＮＵＬＬを指すポインタである。ＦＲＡＧＭＥＮＴ＿ＯＦＦＳＥＴフィールド４６４およびＦＲＡＧＭＥＮＴ＿ＬＥＮＧＴＨフィールド４６６は、それぞれＩＰヘッダフラグメントオフセット（たとえば図２のフィールド２４０）および全長（たとえば図２のフィールド２３８）から取られる。
【００８８】
フラグメントは、受信されるとき、メモリ内で単一のバッファ４８０に格納されることも、バッファ４８０のチェーンに格納されることもある。ＰＯＩＮＴＥＲ＿ＴＯ＿ＢＵＦＦＥＲ＿ＣＨＡＩＮフィールド４６８は、このＦＥに関連する第１のバッファ４８０へのポインタである。ＰＯＩＮＴＥＲ＿ＴＯ＿ＩＰ＿ＨＤＲフィールド４７０は、バッファチェーン内のＩＰヘッダ（もしあれば）の位置４８４を指す。バッファのＮＥＸＴ＿ＩＮ＿ＣＨＡＩＮ  ４８２は、チェーン内の次のバッファを、またはこのチェーン内にさらなるバッファがない場合にはＮＵＬＬを指す。
【００８９】
図５は、図３のフラグメント処理システム３００によって処理された一般的な断片化されたパケットの一般的なライフサイクルを表す要約フローチャートである。したがって、図５は、単一のパケットの受信された各フラグメントにつき１回、フラグメント処理プロセス３０２を複数回繰り返すことを表す。まず、フラグメント処理システム３００は、既存のセッションまたは適合する規則を見つけることができるほどの有効な受信フラグメントをバッファリングする（ステップ５０２）。次に、セッション状態データベース３１２が、パケットへの一致を求めて探索される。一致が見つかる場合、関連する規則が識別される。そうでない場合は、規則セット３０８が探索され、規則が適合する（ステップ５０４）。セッション記録発見または規則検索は、特定のパケットについて一度しか実施されない。次いで、システムは、適合した規則のフィルタポリシーの適用に必要な追加のフラグメント（もしあれば）をバッファリングする（ステップ５１０）。
【００９０】
規則適用５０８は、適合した規則のフィルタポリシーの適用から開始し、その一般的な結果は、ＰＥアクションを不明から通過またはドロップに変更することである（ステップ５１０）。ステップ５１２で、ＰＥアクションがドロップである場合、バッファリングされたフラグメントはドロップされ（廃棄され）（ステップ５１８）、その後に受信された有効なフラグメントは同様にドロップされる（ステップ５２０）。したがって、ＰＥアクションは、ドロップに変更されると、タイムアウトプロセス３０４によってＰＥが削除されるまでドロップのままである。
【００９１】
そうではなく、ステップＺ１２で、ＰＥアクションが通過である場合、バッファリングされたフラグメントは、適合した規則の再送ポリシー（１つまたは複数）に従って再送される（ステップＺ１４）。再送ポリシー（１つまたは複数）は、後続のフラグメントが到着するまで、バッファリングされたすべてのフラグメントの再送を遅延させることも、バッファリングされた一部のフラグメントを遅延させ、その他を再送することも、バッファリングされたすべてのフラグメントをこのときに再送することもある。ドロップのＰＥアクションを有するパケットについてその後に受信された有効なフラグメントとは異なり、通過のＰＥアクションを有するパケットについてその後に受信された有効な各フラグメントは、規則適用Ｚ０８を経る（ステップＺ１６）。したがって、通過のＰＥアクションは、その後に受信されるフラグメントについては、ドロップに変化することがある。
【００９２】
図Ｚは、一般的なフラグメントに関するものであることに留意されたい。任意の特定のフラグメントのライフサイクルは、図Ｚと異なることがある。たとえば、受信された重複または複製フラグメントは、ステップＺ０２でＰＥアクションをドロップに変更し、したがって、そのステップからＺ１８に直接にジャンプしてもよい。同様に、フラグメント処理システム３００は、適合する規則を見つける、または適合した規則のフィルタポリシーを適用できるほど十分なデータを決して受信しないことがある。これらの変形例は、図６−８に示されている。
【００９３】
同様に、図５は、要約フローチャートであり、詳細は省略されている。たとえば、受信されたフラグメントについてＰＥを作成し更新する特定のステップは、ＰＥアクションの更新以外は、理解を促すために省略されている。これらの詳細については、図６−８に述べられる。
【００９４】
図６−８は、図３のフラグメント処理プロセス３０２の一実施形態を表すフローチャートである。フラグメント処理プロセス３０２は、フラグメントだけを処理し、完全なパケットは処理しない。処理は、図６のステップ６０２で、フラグメントの受信から開始する。ステップ６０４で、受信されたフラグメントは、それが有効なＩＰフラグメントかどうか判断するための任意の数のテストを受ける。たとえば、あるテストは、全長（たとえば図２のフィールド２３８）がｌＰプロトコルの制限内にあるかどうかであってよい。別のテストは、受信されたフラグメントの送信元ＩＰアドレス（たとえば図２のフィールド２３２）が、受信フラグメントが受信されたネットワークインターフェースのいずれかのゾーンに一致するかどうか判断することであってよい。受信フラグメントがステップ６０４のテストのうちのいずれか１つに失敗する場合、受信フラグメントはドロップされる（ステップ６０６）。この受信フラグメントの処理は終了し、フラグメント処理プロセス３０２は、ステップ６０２に戻って別のフラグメントの受信を待つ。
【００９５】
受信フラグメントがステップ６０４をうまく通過する場合、次のステップは、受信フラグメントが、新しいパケットの第１の受信フラグメントであるかどうか判断することである。ステップ６０８で、フラグメント処理プロセス３０２は、受信フラグメントの送信元ＩＰアドレスフィールド（たとえば図２のフィールド２３２）、受信フラグメントのパケット識別フィールド（たとえば図２のフィールド２３６）、およびステップ６０４で一致したゾーンのＩＤから生成された鍵を使用して、一致するパケットエントリ（ＰＥ）（たとえば図４の４０４）を求めてＦＰリスト３０６を探索する。
【００９６】
一致するＰＥが見つからない場合は、受信フラグメントは、新しいパケットについて受信された第１のフラグメントである。したがって、ステップ６１０で、ＦＰリスト３０６内に新しいＰＥが作成され、そのＰＥのフィールドが初期化される。一般に、ＰＥフィールドは、一致したゾーンに関連するデフォルト値で初期化される。一致したゾーンがフィールドのデフォルトを指定しない場合、システムデフォルト値が一般に使用される。またステップ６１０で、受信フラグメントのフラグメントエントリ（ＦＥ）４６０が作成され、新しく作成されたＰＥに関連付けられる。新しいＰＥおよびＦＥが作成され初期化されると、処理は、ＥＸＩＳＴＳノード６１２に進む。
【００９７】
そうではなく、ステップ６０８でこのフラグメントについて一致するＰＥがＦＰリスト３０６内に見られる場合は、ステップ６１４で、ＰＥアクションが検査される。ＰＥアクションは、２つのＰＥフィールド：ＡＣＴＩＯＮ＿ＫＮＯＷＮフィールド４１４およびＤＲＯＰフィールド４１６によって定義される。ＰＥアクションは、３つの関数：通過、ドロップまたは不明のうちの１つであってよい。ステップ６１４で、ＰＥアクションがドロップである場合は、処理は、ステップ６０６に進む。この受信フラグメントの処理は終了し、フラグメント処理プロセス３０２は、ステップ６０２に戻って、別のフラグメントの受信を待つ。
【００９８】
ステップ６１４で、ＰＥアクションがドロップでない場合は、ステップ６１６で、受信フラグメントは、受信フラグメントが１つまたは複数のフラグメント間テストに失敗するかどうか判断するために、もしあれば同じＰＥに関連する他の受信されたフラグメントと比較される。たとえば、受信されたフラグメントが、以前に受信されたフラグメントの複製であり、以前に受信されたフラグメントと重複し、あるいはアセンブルされたＩＰデータグラムが全長６５，５３５バイトを超えることになる、全長（たとえば図２のフィールド２３８）とフラグメントオフセット（たとえば図２のフィールド２４０）との合計値を有する場合には、受信されたフラグメントは失敗する。
【００９９】
受信フラグメントがステップ６１６で失敗する場合は、ステップ６１８は、ＰＥアクションがドロップに変更されることをポリシーが必要とするかどうか判断する。そうである場合は、ＰＥアクションは、ステップ６２０でドロップに変更され、処理は、ＢＬＯＣＫノード６２２に進む。そうでない場合は、処理は、ステップ６０６に進む。たとえば、あるＰＥのポリシーは、重複フラグメントがＰＥアクションに影響を及ぼさず、すなわち問題を起こすフラグメントはステップ６０６で廃棄されるが、以前に受信されたパケットおよびＰＥアクションは変化しないままであり、したがって、フラグメント処理プロセスは、この同じパケットについてさらなるフラグメントを受け取ることであってよい。別のパケットについて、ポリシーは、単一の複製のフラグメントが、このフラグメント、ならびに以前に受信されたすべてのフラグメント、およびその後に受信されるどんなフラグメントもがドロップされることを必要とすることであってよい。この場合、ＰＥアクションは、ステップ６２０で、ドロップに変更される。
【０１００】
受信フラグメントがステップ６１６のテストを満たす場合、ステップ６２４で、このＰＥに関連する規則のフィルタポリシーが、受信フラグメントおよびバッファされたどのフラグメントにも適用され、ＰＥアクションがそれに応じて設定される。規則セット３０８からの規則がまだ適合していない場合、一致したゾーンのデフォルト規則が使用される。一致したゾーンについて規則がない場合、システムデフォルト規則が使用される。フィルタポリシー適用は、アプリケーション層フィルタリングのために、受信フラグメントの部分的なリアセンブルまたは完全リアセンブルを必要とすることがある。受信フラグメントがフィルタポリシー適用に失敗する場合、ＰＥアクションは、ドロップに設定され、すなわちＡＣＴＩＯＮ＿ＫＮＯＷＮフィールド４１４は真に設定され、ＤＲＯＰフィールド４１６は真に設定される。
【０１０１】
ステップ６２６で、ＰＥアクションが、再び検査される。ＰＥアクションがドロップである場合は、処理は、ＢＬＯＣＫノード６２２に続く。そうでない場合は、ステップ６２８で、受信フラグメントについて新しいフラグメントエントリ（ＦＥ）（すなわち図４の４６０）が作成され、このフラグメントに関連するＰＥにリンクされる。
【０１０２】
ステップ６３０で、ＰＥアクションが、再び検査される。ＰＥアクションが通過である場合は、受信フラグメントはフィルタポリシー適用を満たしており、適合した規則の再送ポリシーに従って再送される準備が整っている。したがって、制御は、ＡＬＬＯＷノード６３２に進む。そうでない場合は、受信フラグメントについてのアクションは、不明のままであり、処理は、ＥＸＩＳＴＳノード６１２に続く。
【０１０３】
図７は、図６の続きである。受信されたフラグメントが図６のすべてのテストに合格した場合、制御は図７に進むが、（１）規則がまだ適合しておらず、または（２）規則は適合しているが、フィルタポリシー適用に十分なオフセット０から連続するパケットデータが受信されていないので、そのフラグメントに関連するＰＥアクションは不明のままである（すなわち図４のＡＣＴＩＯＮ＿ＫＮＯＷＮフィールド４１４は偽である）。図７は、規則マッチングおよびフィルタポリシー適用に関連する処理を示している。
【０１０４】
処理は、ＥＸＩＳＴＳノード６１２で開始する。ステップ７０２で、受信フラグメントに関連するＰＥについて適合する規則が既に見つかっているかどうか、すなわち図４のＲＵＬＥ＿ＫＮＯＷＮフィールド４２２が真か、それとも偽か決定される。そのフィールドが真である場合は、規則は既に適合しており、処理は、ステップ７０４に続く。そのフィールドが偽である場合は、規則は適合しておらず、処理は、ステップ７０６に続く。
【０１０５】
ステップ７０６で、適合する規則を見つけるのに十分なデータがあるかどうか判断される。たとえば、本発明の一実施形態は、適合する規則を見つけるのにＩＰヘッダ全体（たとえば図２のフィールド１２８）、送信元ＴＣＰポート（図２のフィールド２２０）および宛先ＴＣＰポート（図２のフィールド２２２）を必要とすることがある。一般に、こうしたデータは、オフセット−０フラグメントで見られるが、オフセット−０フラグメントが最初に受信される保証はなく、または受信される保証は全くない。さらに、ＴＣＰヘッダの一部（たとえば図２のヘッダ１２０）は、オフセット−０フラグメント以外のフラグメントで見られ得る。規則マッチングに必要なデータがまだ受信されていない場合は、処理は、ＷＡＩＴノード７０８に続く。そうではなく、規則マッチングに十分な受信データがある場合は、処理はステップ７１０に続く。
【０１０６】
ステップ７１０で、フラグメント処理プロセス３０２は、既存のセッションとの一致を見つけようと試み、またはそれに失敗し、適合する規則を見つけようと試みる。具体的には、セッション状態データベースが、状態記録または規則のマッチングに必要などんなデータをも使用して、状態エントリを求めて探索される。状態記録が見られない場合は、図３の規則セット３０８は、規則マッチングに必要ないかなるデータをも使用して探索される。状態記録も規則も適合しない場合は、ステップ７１２で、ＰＥアクションはドロップに変更され、処理は、ＢＬＯＣＫノード７１４に続く。
【０１０７】
そうではなく、ステップ７１０で、規則がうまく適合する場合は、ステップ７１６で、いくつかの変更がＰＥに加えられる。第１に、図４のＲＵＬＥ＿ＫＮＯＷＮフィールド４２２は、規則が適合したことを示す、真に設定される。第２に、ＰＥ内の他のフィールドは、適合した規則のポリシーを表す値、たとえばＭＡＸ＿ＨＯＬＥ＿ＳＩＺＥフィールド４２６、ＯＰＴＩＯＮＳフィールド４３４、ＴＥＲＭＩＮＡＴＩＮＧ＿ＣＯＮＤＩＴＩＯＮＳフィールド４３６、ＲＥＡＳＳＥＭＢＬＥフィールド４３８、ＲＥＦＲＡＧＭＥＮＴフィールド４４０、ＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＣＯＬＬＥＣＴフィールド４４２およびＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＤＩＳＣＡＲＤフィールド４４４で更新されてよい。最後に、ＲＥＱＵＩＲＥＤ＿ＢＹＴＥＳフィールド４２０は、規則ポリシーの適用にはオフセット０から連続するいくつのバイトが、適合した規則によって必要とされるか示す値で更新される。次いで、処理は、ステップ７０４に続く。
【０１０８】
規則マッチングがオフセット０から連続する任意の数のバイトを要求とし得るように、適合した規則のフィルタポリシーの適用も、オフセット０から連続する任意の数のバイトを必要とし得る。さらに、それらの２つの数は、それぞれ異なってよい。
【０１０９】
したがって、ステップ７０４で、適合した規則のフィルタポリシーの適用に十分な、オフセット０から連続するバイトが受信されたかどうか判断される。具体的には、フィルタポリシーの適用に、オフセット０から連続するいくつのパケットデータのバイトが必要とされるか示すＲＥＱＵＩＲＥＤ＿ＢＹＴＥＳフィールド４２０が、オフセット０から連続するいくつのパケットデータのバイトが受信されたか示すＮＥＸＴ＿ＯＦＦＳＥＴフィールド４１８と比較される。ＲＥＱＵＩＲＥＤ＿ＢＹＴＥＳがＮＥＸＴ＿ＯＦＦＳＥＴより大きい場合は、フィルタポリシー適用に十分なデータはなく、プロセスは、ＷＡＩＴノード７０８に続き、さらなるフラグメントの到着を待つ。そうではなく、ＮＥＸＴ＿ＯＦＦＳＥＴがＲＥＱＵＩＲＥＤ＿ＢＹＴＥＳ以上である場合は、フィルタポリシー適用に十分なフラグメントデータがあり、処理は、ステップ７１８に進む。
【０１１０】
ステップ７１８で、１つまたは複数の受信フラグメントが適合した規則のすべてのフィルタポリシーを満たすかどうか判断される。このステップは、受信フラグメントがアプリケーション層フィルタリングのために部分的にまたは完全にリアセンブルされることを必要とすることがある。ステップ７１８で、適合した規則のフィルタポリシーが満たされる場合は、ＰＥアクションは通過に設定され、すなわちＡＣＴＩＯＮ＿ＫＮＯＷＮフィールド４１４は、真に設定され、ＤＲＯＰフィールド４１６は、偽に設定され、ステップ７２０は、処理がＡＬＬＯＷノード７２２に続くと決定する。そうではなく、受信フラグメントデータがセキュリティポリシーのいずれか１つに失敗する場合は、ＰＥアクションはドロップに設定され、すなわちＡＣＴＩＯＮ＿ＫＮＯＷＮフィールド４１４は真に設定され、ＤＲＯＰフィールド４１６は真に設定され、ステップ７２０は、処理がＢＬＯＣＫノード７１４に続くと決定する。
【０１１１】
ステップ７１８の第３の代替案は、ＮＥＸＴ＿ＯＦＦＳＥＴ  ４１８がＲＥＱＵＩＲＥＤ＿ＢＹＴＥＳ  ４２０以上である場合でも、受信されたフラグメントデータが、適合した規則のフィルタポリシーを適用するには不十分であることである。一般的な例は、アプリケーション層フィルタリング、すなわちウェブクッキーなど、アプリケーションデータ内のどこにでも置かれ得る特定のデータ（たとえば図２のペイロード１１６）を検査することである。その場合、プロセスは、適合した規則のフィルタポリシーを受信された各隣接フラグメントに適用する。必要なアプリケーション層データが見られる場合は、ポリシー（１つまたは複数）が評価され、それに従ってＰＥアクションが設定される。そうではなく、受信された隣接データが必要なアプリケーション層データを含んでいない場合は、ステップ７１８は、ＰＥアクションを不明に設定し、ステップ７２０は、ステップ７２４に処理を向け、このステップ７２４で、ＲＥＱＵＩＲＥＤ＿ＢＹＴＥＳ  ４２０がＮＥＸＴ＿ＯＦＦＳＥＴ＋１の値で更新される。ＲＥＱＵＩＲＥＤ＿ＢＹＴＥＳ  ４２０のこの新しい値は、フラグメント処理プロセス３０２に、次の隣接フラグメントが到着するならば、適合した規則のフィルタポリシーを再び適用させる。
【０１１２】
図８は、図６および７の続きである。受信フラグメントが１つまたは複数のシステム、ゾーンまたは規則フィルタポリシーに失敗するとき、処理は、ＢＬＯＣＫノード６２２に到達し、ＰＥアクションが、図６のステップ６２４または図７のステップ７１８でドロップに設定される。ステップ８０２で、フラグメントエントリおよびその各々のフラグメントバッファが解放され、それらのリソースは解放されるが、ＰＥは保持される。次に、ステップ８０４で、ＰＥのタイムアウトはドロップ間隔に設定され、すなわちＴＩＭＥＯＵＴフィールド４４６は、システム時刻に、ＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＤＩＳＣＡＲＤ  ４４４に格納されたミリ秒数を足した値に等しい値に設定される。この時点から、ＴＩＭＥＯＵＴフィールドに指定された時刻まで、フラグメント処理プロセス３０２は、このＰＥについてその後に受信されたどんなフラグメントをもドロップする。この受信フラグメントの処理は終了し、フラグメント処理プロセス３０２は、ノード８０６を介して図６のステップ６０２に戻って、別のフラグメントの受信を待つ。
【０１１３】
処理は、（１）規則が適合しなかった場合、または（２）規則は適合したが、適合した規則のフィルタポリシーを適用するにはオフセット０から連続するパケットデータが不十分である場合、図７からのＷＡＩＴノード７０８に到達する。ステップ８０８で、受信フラグメントのフラグメントバッファまたはバッファチェーン４８０が対応するフラグメントエントリ４６０にリンクされ、ＮＥＸＴ＿ＯＦＦＳＥＴフィールド４１８が、オフセット０から連続したデータのバイト長で更新される。この受信フラグメントの処理が終了し、フラグメント処理プロセス３０２は、ノード８０６を介してステップ６０２に戻って、別のフラグメントの受信を待つ。
【０１１４】
処理は、ＰＥアクションが図６のステップ６３０または図７のステップ７２０で通過である場合、ＡＬＬＯＷノード７２２に到達する。この経路に沿って、フラグメントは、適合した規則の再送ポリシーに従って、フラグメント処理プロセスによって修正され再送される。本発明の一実施形態では、３つのこうした再送ポリシーがある。第１の再送ポリシーは、フラグメントを受信順序のフラグメントとして再送することである。第２の再送ポリシーは、オフセット０から連続するフラグメントをオフセット順序で再送することである。第３の再送ポリシーは、すべてのフラグメントを収集し、それらのフラグメントを並べ直し、それらのフラグメントを完全なパケットにリアセンブルし、次いで、損なわれていないパケットを再送し、またはパケットを再断片化し、次いで再送することである。第３の再送ポリシーは、フラグメントのうちのいずれかを再送する前にすべてのフラグメントが受信されることを必要とするが、第１および第２のポリシーはそうでない。
【０１１５】
ステップ８１０で、特定のパケットについてすべてのフラグメントが受信されたかどうか決定される。そうである場合は、適合した規則の再送ポリシーに関係なく、さらなるフラグメントを待つ必要はない。したがって、ステップ８１２で、適合した規則の再送ポリシーに従って、受信フラグメント、およびバッファリングされたどんなフラグメントも処理される。フラグメントが処理される間、フラグメントエントリ（４６０）およびバッファチェーン（４８０）は解放される。すべてのフラグメントが処理され、再送が完了すると、ステップ８１４でＰＥアクションはドロップに設定され、すなわちＤＲＯＰフィールド４１６は真に設定され（ステップＪ１５）、ＴＩＭＥＯＵＴ  ４４６は、ＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＤＩＳＣＡＲＤ  ４４４に設定され、処理は、ステップ８０４に進む。
【０１１６】
やはりステップ８１２で、必要ならばフラグメントが修正される。パケットヘッダの送信元および／または宛先アドレスが修正されている場合（たとえばネットワークアドレス変換の場合によく見られる）、パケットのすべてのフラグメントのすべてのヘッダが修正される必要があることがあり、ヘッダチェックサムは、パケットの各フラグメントが再送される前に更新される必要があり得る。適合した規則のフィルタポリシーの適用のためにパケットの初期フラグメントを部分的にリアセンブルすることが必要であった場合、戻ったとき、部分的にリアセンブルされたパケットが修正されたという表示がある。これが生じ、パケットサイズが変化していない場合、パケットフラグメントは、これらの変更を反映するように適所に修正される。パケットのサイズを変更することが必要である場合、パケットは一般に、完全にリアセンブルされ、再送の前に再断片化される。
【０１１７】
そうではなく、ステップ８１０で、すべてのフラグメントが受信されていない場合、次の質問は、再送ポリシーが再送の前にすべてのフラグメントを収集することを必要とするかどうかである（ステップ８１６）。すべてのフラグメントの収集が必要とされる場合は、制御はしたがって、ＷＡＩＴ経路に進む（ステップ７０８）。
【０１１８】
ステップ８１６で再送ポリシーがすべてのフラグメントの収集を必要とするとは限らない場合は、再送ポリシーは、受信されたフラグメントをオフセット順序で再送し、または受信されたフラグメントを受信順序で再送することである。したがって、次の質問は、先行するすべてのオフセット順序フラグメントが受信されたかどうかである（ステップ８１８）。答えがはいである場合は、残りの両方の再送ポリシーが満たされ、処理は、受信フラグメントが再送されるステップ８２２へと続く。ステップ８１８の答えがいいえである場合は、次の質問は、ステップ８２０で、再送ポリシーがオフセット順序を必要とするかどうかである。再送ポリシーが受信順序でフラグメントを再送することである場合は、ステップ８２０の答えはいいえであり、処理は、受信フラグメントが再送されるステップ８２２に続く。そうではなく、再送ポリシーがオフセット順序で再送することである場合は、ステップ８２０の答えは、はいであり、処理は、ＷＡＩＴ経路７０８に続く。
【０１１９】
ステップ８２２で、受信フラグメントは再送され、フラグメントバッファ（たとえばバッファ４８０）は解放されるが、フラグメントエントリ（たとえば４６０）は保持され、したがって、フラグメント処理プロセスは、複製および重複を検出することができる。ステップ８２２の後、この受信フラグメントの処理は終了し、フラグメント処理プロセス３０２は、ステップ６０２に戻って、別のフラグメントの受信を待つ。
【０１２０】
本発明の実施形態の別の要素は、図３のタイムアウトプロセス３０４、フラグメント処理プロセス３０２とは別のプロセスであり、このプロセス３０４は、ＦＰリスト３０６内のありとあらゆるＰＥのＰＥアクションおよびタイムアウト値を定期的に（たとえば１秒に１回）チェックし、必要に応じてそれらの値に変更を加える。
【０１２１】
タイムアウトプロセスは、リソース管理プロセスである。ＰＥ、ＦＥおよびバッファはすべて、メモリ空間およびプロセッサクロックサイクルを消費する。多くのパケットでは、最後のフラグメントが受信されるときにそれらのリソースのほとんどが解放され、ＰＥアクションは、通過からドロップに変更される（たとえば図８のステップ８１２および８１４）。
【０１２２】
しかし、パケット交換網の性質は、どのフラグメント（１つまたは複数）も決して到着しないことがあるということである。こうした状況では、ＰＥアクションは一般に、通過からドロップには決して変化せず、リソースは決して解放されない。十分に長い時間に渡って、システムリソースのすべてが永久的に、不完全なフラグメントシーケンスに専用となり、したがって、新しい通信の処理が妨げられる。実際、一般的なフラグメントベースの攻撃は、ルータのリソースのすべてを消費するために、ルータを不完全なフラグメントシーケンスで意図的にいっぱいにすることである。
【０１２３】
さらに、最終フラグメントが受信され、バッファおよびＦＥが解放される場合でも、ＰＥは、依然としてドロップのＰＥアクションのままであり、複製フラグメントをブロックし、またはフラグメント攻撃を緩和する。何らかの時点で、メモリ空間が再利用され得るように、そのＰＥ自体が削除されるべきである。
【０１２４】
したがって、システム管理者は、（１）どのくらいの間、ＰＥアクションが不明または通過であってよいか（収集間隔）、および（２）どのくらいの間、ＰＥアクションがドロップであってよいか（ドロップ間隔）を指定することができる。さらに、システム管理者は、ＦＰリスト内のすべてのＰＥを定期的にチェックし、ドロップまたは収集間隔が終了したＰＥを変更する処理を有する。
【０１２５】
図９は、図３のタイムアウトプロセス３０４の一実施形態のフローチャートである。処理は、ＳＴＡＲＴノード９０２から開始し、ステップ９０４に続き、記録ポインタがＦＰリスト（たとえば図３のＦＰリスト３０６）内の第１のＰＥに向けられる。ＦＰリストが空である場合はステップ９０６で、記録ポインタは、ＦＰリストの末尾を指し、タイムアウトプロセスは、ＳＴＡＲＴノード９０２に戻る前、所定の時間量の間待つ（ステップ９０８）。そうではなく、ステップ９０６で、記録ポインタがＰＥを指す場合は、処理は、ステップ９１０に続き、ＰＥのタイムアウト（すなわちＴＩＭＥＯＵＴフィールド４４６）が現在のシステム時刻と比較される
ステップ９１０で、ＰＥのタイムアウトがシステム時刻以下である場合は、タイムアウトはまだ終了しておらず、このＰＥに変更が加えられる必要はない。その場合、ポインタは、ＦＰリスト内の次のＰＥに設定され（ステップ９１２）、処理は、ステップ９０６にループバックする。
【０１２６】
そうではなく、タイムアウトが現在のシステム時刻より大きい場合は、タイムアウトは終了しており、ＰＥアクションは変更されるべきである。処理は、ステップ９１４に続く。ステップ９１４が、現在のＰＥアクションが不明または通過であると決定する場合、収集間隔は終了しており、ＰＥアクションはドロップに変更されるべきである（ステップ９１６）。具体的には、ＤＲＯＰフィールド４１６は真に設定され、このＰＥについてのすべてのフラグメントエントリ（たとえばＦＥ  ４６０）およびすべてのフラグメントバッファ（たとえばバッファ４８０）が削除され、タイムアウトは、ドロップ間隔（すなわちＴＩＭＥ＿ＩＮＴＥＲＶＡＬ＿ＤＩＳＣＡＲＤ  ４４４）に、現在のシステム時刻を足した値に等しい値に設定される。次いで、記録ポインタは、ステップ９１２で、ＦＰリスト内の次のＰＥに設定され、処理は、ステップ９０６にループバックする。
【０１２７】
そうではなく、ステップ９１４のＰＥアクションがドロップである場合、ドロップ間隔は終了しており、このＰＥは、ＦＰリストから削除される（ステップ９１８）。次いで、記録ポインタは、ステップ９１２で、ＦＰリスト内の次のＰＥにセットされ、処理は、ステップ９０６にループバックする。
【０１２８】
ステップ９０６で、ＦＰリスト内にもはやＰＥがない場合、タイムアウトプロセスは、ステップ９０４でＦＰリスト内の第１のＰＥから再開する前に、ステップ９０８で所定の時間の間待つ。
【０１２９】
本発明は、インターネット、およびインターネットについて述べるのに従来使用される５層プロトコルモデルの文脈で述べられているが、本発明は、それに限定されない。本発明は、任意の適切なパケット交換網、および７層ＯＳＩモデルなど任意の適切なプロトコルスキーマに適用される。
【０１３０】
本発明は、単一の集積回路（ＡＳＩＣやＦＰＧＡなど）、マルチチップモジュール、単一のカードまたはマルチカード回路パックとしての可能な実装形態を含めて、（アナログ、デジタル、またはアナログとデジタルの両方のハイブリッド）回路ベースのプロセスとして実装されてよい。当業者には明らかなように、回路素子の様々な機能は、ソフトウェアプログラム内の処理ブロックとして実装されることもできる。こうしたソフトウェアは、たとえばデジタル信号プロセッサ、マイクロコントローラまたは汎用コンピュータで使用されてよい。
【０１３１】
本発明は、それらの方法を実施するための方法および装置の形で具現化されてよい。本発明は、磁気記録媒体、光記録媒体、ソリッドステートメモリ、フロッピー（登録商標）（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意のマシン読取り可能記憶媒体など、有形媒体で具現化されたプログラムコードの形で具現化されることができ、プログラムコードがコンピュータなどのマシンにロードされ、それによって実行されるとき、このマシンは、本発明を実施する装置となる。本発明は、記憶媒体に格納され、マシンにロードされかつ／またはそれによって実行されようが、電気配線またはケーブルを介して、光ファイバによって、または電磁放射によってなど何らかの伝送媒体または搬送波を介して送信されようが、プログラムコードの形で具現化されることもでき、プログラムコードがコンピュータなどのマシンにロードされ、それによって実行されるとき、このマシンは、本発明を実施する装置となる。汎用プロセッサ上で実装されるとき、プログラムコードセグメントは、プロセッサと結合して、特定の論理回路に類似して動作する固有のデバイスを提供する。
【０１３２】
本発明は、媒体を介して電気的または光学的に送信されるビットストリームまたは信号値の他のシーケンス、本発明の方法および／または装置を使用して生成された、磁気記録媒体内に格納された磁場変化の形で具現化されることもできる。
【０１３３】
他に明示的に定められていない限り、それぞれの数値および範囲は、単語「約（ａｂｏｕｔ）」または「およそ（ａｐｐｒｏｘｉｍａｔｅｌｙ）」がその値または範囲の値の前に置かれるかのように近似のものと解釈されるべきである。
【０１３４】
本発明の性質について説明するために述べられ示された部分の詳細、材料および構成の様々な変更が、添付の特許請求の範囲に表された本発明の範囲から逸脱せずに当業者によって行われ得ることがさらに理解されよう。
【０１３５】
特許請求の範囲において図の番号および図の参照ラベルを使用することは、特許請求の範囲の解釈を促すために、特許請求された主題の１つまたは複数の可能な実施形態を特定するためのものである。こうした使用は、それらの請求項の範囲を対応する図に示された諸実施形態に必ずしも限定するものと解釈されるべきでない。
【０１３６】
本明細書に述べられた例示的な方法の諸ステップは、述べられた順番で必ずしも実施される必要はなく、こうした方法の諸ステップの順序は、単に例示的なものと理解されたい。同様に、こうした方法に追加のステップが含まれてよく、本発明の様々な実施形態に一致する方法では、特定のステップが省かれることも、組み合わされることもある。
【０１３７】
添付の方法クレーム内の諸要素は、もしあれば、対応するラベルを伴って特定の順序で列挙されているが、請求項の列挙がそれらの要素の一部またはすべてを実施する特定の順序を他に示唆していない限り、それらの要素は、その特定の順序での実施に制限されることが必ずしも意図されていない。
【０１３８】
本明細書では、「一実施形態（ｏｎｅ  ｅｍｂｏｄｉｍｅｎｔ、ａｎ  ｅｍｂｏｄｉｍｅｎｔ）」への言及は、実施形態に関連して述べられた特定の特徴、構造または特性が本発明の少なくとも１つの実施形態に含まれ得ることを意味する。本明細書の様々な場所に語句「一実施形態では」が現れることは、必ずしもすべてが同じ実施形態に言及するとは限らず、また別個のまたは代替の実施形態は、他の実施形態と必ずしも相互排他的であるとは限らない。同じことが、用語「実装形態」にも当てはまる。
【図１】
0005394482.tif 000002
【図２】
0005394482.tif 000003
【図３】
0005394482.tif 000004
【図４】
0005394482.tif 000005
【図５】
0005394482.tif 000006
【図６】
0005394482.tif 000007
【図７】
0005394482.tif 000008
【図８】
0005394482.tif 000009
【図９】
0005394482.tif 000010