(57)【特許請求の範囲】
【請求項１】
第１のホストシステムと第２のホストシステムの間で、前記第２のホストシステムを保護するファイアウォールを介して接続を確立する方法であって、
ＫＯＦ（ノックオンフィーチャ）装置によって、
前記第１のホストシステムによって送信された第１のメッセージを受信すること、
前記第１のメッセージが、前記第１のホストシステムと前記第２のホストシステムの間で前記接続を確立するための第１のタイプであると判定すること、
前記第１のメッセージから前記第１のホストシステムのアドレス、および前記第２のホストシステムのアドレスをそれぞれ特定すること、
前記ＫＯＦ装置上に前記第１のホストシステムの前記アドレス、および前記第２のホストシステムの前記アドレスに対応する２タプルに関する状態情報が存在するかどうかを判定すること、および
前記ＫＯＦ装置上に前記２タプルに関する前記状態情報が存在しない場合、前記第１のメッセージを前記第２のホストシステムに送信することを実行することを備える、方法。
【請求項２】
前記２タプルに関する第１のタイマを初期設定し、開始すること、
前記２タプルに関するメッセージカウンタを初期設定し、インクリメントすること、
前記第１のタイマが満了した場合、前記ＫＯＦ装置上の前記状態情報を除去し、さらに前記ＫＯＦ装置上に前記２タプルに関する前記状態情報が存在する場合、
前記第１のタイマを調べること、
前記メッセージカウンタのカウントを調べること、
前記カウントが所定の値に達している場合、前記２タプルに関する第２のタイマを開始して、前記第１のメッセージをドロップすること、および
前記カウントが前記所定の値に達していない場合、前記第１のメッセージを前記第２のホストシステムに送信することをさらに備える、請求項１に記載の方法。
【請求項３】
前記ＫＯＦ装置上に前記２タプルに関する前記状態情報が存在する場合、
前記第２のタイマを調べること、
前記第２のタイマが満了していない場合、前記第１のメッセージをドロップすること、
前記第２のタイマが満了している場合、前記ＫＯＦ装置上の前記２タプルに関するすべての前記状態情報を除去すること、
前記第２のホストシステムによって送信された第２のメッセージを受信すること、
前記第２のメッセージが、前記第１のメッセージに応答して前記第１のホストシステムから情報を要求するための第２のタイプであると判定すること、および
前記第２のメッセージを前記第１のホストシステムに送信することをさらに備える、請求項２に記載の方法。
【請求項４】
前記ＫＯＦ装置が、前記ファイアウォールの外部に、ファイアウォールと直列に位置する方法であって、
前記第２のタイマを調べること、
前記第２のタイマが満了していない場合、前記第１のメッセージをドロップすること、および
前記第２のタイマが満了している場合、前記２タプルに関する５タプル状態情報を含め、前記ＫＯＦ装置上の前記２タプルに関するすべての前記状態情報を除去することをさらに含み、前記５タプル状態情報が、前記２タプルに加えて、前記接続に関して、プロトコルタイプの指示と、前記第１のホストシステムの第１のポートの指示と、前記第２のホストシステムの第２のポートの指示とを含む、請求項２に記載の方法。
【請求項５】
前記第２のホストシステムに関して前記ＫＯＦ装置上に存在する状態情報の量を特定すること、
前記量が所定の上限を超えたことに応答して、前記第２のホストシステムと、各ペアにおいて異なる別のホストシステムとをそれぞれが備える２つのホストシステムペアの状態情報を組み合わせて、前記第２のホストシステムの前記アドレスと、前記２つのホストシステムペアの他方のホストシステムのそれぞれのアドレスに共通であるアドレスプレフィックスとを備える１つのホストシステムペアに関する状態情報にすること、
前記１つのホストシステムペアに関する組み合わされたタイマを、前記２つのホストシステムペアのそれぞれの第１のタイマの小さい方に設定すること、および
前記１つのホストシステムペアに関する組み合わされたメッセージカウンタを、前記２つのホストシステムペアのそれぞれのメッセージカウンタの大きい方に設定することをさらに備える、請求項１に記載の方法。
【請求項６】
前記第２のホストシステムによって送信された第３のメッセージを受信すること、
前記第３のメッセージが、前記第１のホストシステムと前記第２のホストシステムの間の前記接続を終了させるための第３のタイプであると判定すること、および
前記第３のタイプのメッセージを受信したことに応答して、前記ＫＯＦから、前記２タプルに関する５タプル状態情報を除去することをさらに含み、前記５タプル状態情報が、前記２タプルに加えて、前記接続に関して、プロトコルタイプの指示と、前記第１のホストシステムの第１のポートの指示と、前記第２のホストシステムの第２のポートの指示とを含む、請求項１に記載の方法。
【請求項７】
前記ＫＯＦ装置が前記ファイアウォールの一部である方法であって、
前記第２のホストシステムによって送信された第４のメッセージを受信すること、
前記第４のメッセージが、前記第１のメッセージに応答して前記接続を開始するための第４のタイプであると判定すること、
前記５タプルに関して第３のタイマを開始すること、
前記第１のホストシステムによって送信され前記第２のホストシステムを宛先とする通信トラフィックを受信すること、
前記第３のタイマを調べること、
前記ファイアウォール上に前記５タプルに関する状態情報が存在するかどうかを判定すること、および
前記第３のタイマが満了していないことに応答して、さらに前記ファイアウォール上に前記５タプルに関する前記状態情報が存在することに応答して、前記通信トラフィックを通過させることをさらに備える、請求項６に記載の方法。
【請求項８】
前記ＫＯＦ装置が、前記ファイアウォールの外部にある中継サーバの一部である方法であって、
前記受信するステップが、前記第１のホストシステムと前記中継サーバの間の前もって確立された第１のシグナリング接続を介して前記第１のメッセージを受信することを備え、さらに前記送信するステップが、前記第２のホストシステムと前記中継サーバの間の前もって確立されたシグナリング接続を介して前記第１のメッセージを前記第２のホストシステムに送信することを備える、請求項１に記載の方法。
【請求項９】
前記送信するステップが、
前記ＫＯＦ上に、前記第１のホストシステムの前記アドレス、および前記第２のホストシステムの前記アドレスに対応する２タプルエントリを作成すること、および
その２タプルエントリを通過状態に設定することをさらに備える、請求項１に記載の方法。
【請求項１０】
前記第１のホストシステムに関して前記ＫＯＦ装置上に存在する状態情報の量を特定すること、
前記量が所定の上限を超えたことに応答して、前記第１のホストシステムと、各ペアにおいて異なる別のホストシステムとをそれぞれが備える２つのホストシステムペアの状態情報を組み合わせて、前記第２のホストシステムの前記アドレスと、前記２つのホストシステムペアの他方のホストシステムのそれぞれのアドレスに共通であるアドレスプレフィックスとを備える１つのホストシステムペアに関する状態情報にすることをさらに備える、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットデータネットワークを対象とし、詳細には、いずれかがファイアウォールを介してパケットデータネットワークに接続された２つのホストシステム間でセキュリティで保護された接続を開始することを対象とする。以降、パケットデータネットワークに対するホストシステムのそのような接続を、ファイアウォールの背後にあるホストシステムと称する。
【背景技術】
【０００２】
ＦＷ（ファイアウォール）およびＮＡＴ（ネットワークアドレストランスレータ）は、以下のセキュリティフィーチャを適用する：ＦＷが、インバウンドパケットを、それらのパケットが、ＦＷを以前に通過したアウトバウンドパケットに応答して着信した場合に限って、受け付ける。ＦＷは、インバウンドパケットが、｛プロトコルタイプ、送信元ＩＰアドレス、送信元ポート、宛先ＩＰアドレス、宛先ポート｝という５タプルに関して、以前のアウトバウンドパケットと合致することを要求する。
【０００３】
このＦＷセキュリティフィーチャは、さらなるフィルタリングフィーチャが適用されない限り、内部のホスト（すなわち、ファイアウォールの背後のホストシステム）が、任意の外部のホスト（すなわち、同一のファイアウォールの背後にはないホストシステム）に対して接続を開くことを許す。しかし、外部のホストは、内部のホストに対する接続を要請することができない。
【０００４】
残念ながら、このＦＷセキュリティフィーチャは、外部のホストによって開始される接続確立を、その確立が内部のホストに望ましい場合でさえ、禁止するという副作用を有する。２つのホストが異なるＦＷの背後にあり、接続を確立することを所望する場合、完全なデッドロックがもたらされる。その場合、その２つのホストは、互いに直接に通信することができない。
【０００５】
また、ＦＷセキュリティフィーチャは、本明細書で単にＮＡＴと呼ばれる、ほとんどのネットワークアドレストランスレータまたはネットワークアドレス＆ポートトランスレータに組み込まれる。したがって、以降、ＦＷについて述べることのすべてが、ＮＡＴにも一般に該当する。
【０００６】
さらに、ＦＷセキュリティフィーチャは、モバイルＩＰｖ６（ＩＥＴＦ  ＲＦＣ  ３７７５）のようなホストベースの移動性をサポートする技術に関する問題をもたらしもする。これらの技術は、ホストが、進行中のトランスポート接続を途絶えさせることなしに、移動すること、およびそのホストのＩＰアドレスを変更することを許す。移動するホストは、バインディング更新を使用して、そのホストの新たなＩＰアドレスについて、そのホストの対応ノード（ＣＮ）を更新しなければならない。しかし、バインディング更新は、新たなＩＰアドレスから着信するので、セキュリティフィーチャは、ＦＷにそのバインディング更新を阻止させる。
【０００７】
ＦＷセキュリティフィーチャによってもたらされる、この望ましくない副作用を克服する２つの主要なソリューションが存在する：１）ＦＷが、外部のホストが内部のホストと連絡をとるポートを開き、さらに２）内部のホストが、任意の外部のホストによって連絡がとられることが可能な外部の中継サーバ（ＲＳ）に対してシグナリング接続を維持する。第２のソリューションは、例えば、ＴＵＲＮ方法（ｄｒａｆｔ−ｉｅｔｆ−ｂｅｈａｖｅ−ｔｕｒｎ−０４．ｔｘｔ）によって提案される。ＴＵＲＮ方法はさらに、ＩＥＴＦによって提案される対話型接続確立（ＩＣＥ）アプローチ（ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｉｃｅ−ｔｃｐ−０７）の全体を成す。
【０００８】
両方のソリューションとも、内部ホストが、ＦＷ上、またはＲＳ上の開かれたポートを介して実行される攻撃の犠牲となり得るので、ＦＷのセキュリティを危険にさらす。第２のソリューションのいくつかの変種は、内部ホストとＲＳの間のリンク上でさらなるセキュリティをもたらす。しかし、これらの変種は、内部のホストに生じる主な脆弱性に全く影響を与えない。この脆弱性のため、ＴＵＲＮおよびＩＣＥは、市場にあまり受け入れられていないように見受けられる。ＦＷ管理者は、同じ理由でそのようなサービス、および他のＲＳベースの方法を嫌う傾向にある。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】ＩＥＴＦ  ＲＦＣ  ３７７５
【非特許文献２】ｄｒａｆｔ−ｉｅｔｆ−ｂｅｈａｖｅ−ｔｕｒｎ−０４．ｔｘｔ
【非特許文献３】ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｉｃｅ−ｔｃｐ−０７
【非特許文献４】ＩＥＴＦ  ＲＦＣ  ４３０６
【非特許文献５】ＩＥＴＦ  ＲＦＣ  ５３８９
【発明の概要】
【発明が解決しようとする課題】
【００１０】
以上のことに鑑みて、ＦＷの有益なセキュリティ機能を保持し、それと同時に、外部のホストが内部のホストに対して接続確立を開始することを許すことが望ましい。さらに、外部のホストが新たなＩＰアドレスに移動した場合、内部のホストを相手に確立された接続が継続するのを許すことが望ましい。
【課題を解決するための手段】
【００１１】
本発明の実施形態は、ファイアウォールの背後のホストに対して接続を確立するための、本明細書でノックオンプロトコル（ＫＯＰ）と呼ばれる、ホスト間シグナリングプロトコルを対象とする。
【００１２】
本発明の一部の実施形態は、中間のファイアウォールまたはネットワークアドレストランスレータによって、ＦＷまたはＮＡＴを介して、ＦＷまたはＮＡＴの背後のホストに対する接続確立を可能にするのに使用されるノックオンフィーチャ（ＫＯＦ）を対象とする。
【００１３】
本発明の一部の実施形態は、外部のホストが内部のホストを相手に接続を確立しようとする試みの頻度を制限することによって、セキュリティをもたらす。
【００１４】
ＫＯＦがＦＷまたはＮＡＴに組み込まれる本発明の実施形態において、さらに、ＫＯＦがＦＷまたはＮＡＴと直列に実装される実施形態において、さらなるセキュリティが、有利には、対応する接続が終了された後、開かれた５タプルエントリを「塞ぐこと」（すなわち、閉じること、または削除すること）によってもたらされ得る。
【００１５】
本発明の一部の実施形態において、ＫＯＦは、有利には、メッセージフラッディング攻撃において使用されるアドレススプーフィングから保護するプレフィックスベースの保護フィーチャを含む。
【００１６】
有利には、本発明の実施形態によるＫＯＦの通常の処理要件およびメモリ要件は、ＦＷまたはＮＡＴの処理要件およびメモリ要件と比べて小さい。
【００１７】
本発明の或る態様によれば、第１のホストシステムと第２のホストシステムの間で、第２のホストシステムにセキュリティ保護をもたらすファイアウォールを介して接続を確立する方法が提供される。この方法は、ノックオンフィーチャ（ＫＯＦ）装置によって：第１のホストシステムによって送られた第１のメッセージを受信するステップと、第１のメッセージが、第１のホストシステムと第２のホストシステムの間で接続を確立するための第１のタイプであると判定するステップと、第１のメッセージから第１のホストシステムのアドレス、および第２のホストシステムのアドレスをそれぞれ特定するステップと、第１のホストシステムのアドレス、および第２のホストシステムのアドレスに対応する２タプルに関してＫＯＦ装置上に状態情報が存在するかどうかを判定するステップと、ＫＯＦ装置上に２タプルに関して前述した状態情報が存在しない場合、第１のホストシステムに第１のメッセージを送るステップとを実行することを備える。
【００１８】
有利には、この方法は、第２のホストシステムに関してＫＯＦ装置上に存在する状態情報の量を特定するステップと、その量が所定の上限を超えたことに応答して、第２のホストシステムと、各ペアにおいて異なる別のホストシステムとをそれぞれが備える２つのホストシステムペアの状態情報を組み合わせて、第２のホストシステムのアドレスと、その２つのホストシステムペアの他方のホストシステムのそれぞれのアドレスに共通であるアドレスプレフィックスとを備える１つのホストシステムペアに関する状態情報にするステップとをさらに含むことが可能である。
【００１９】
本発明の以上、およびその他の目的、特徴、および利点は、添付の図面に示される好ましい実施形態の、後述のより詳細な説明から明白となろう。
【図面の簡単な説明】
【００２０】
【図１】典型的な従来技術のファイアウォールアーキテクチャの５タプルに関係する状態および状態遷移を示す図である。
【図２】典型的な従来技術のファイアウォールアーキテクチャのインバウンドパケット（上）およびアウトバウンドパケット（下）に関する有限状態マシン（ＦＳＭ）を示す図である。これらの流れ図は、タイマ満了による図１に示される５タプル状態遷移を含まない。
【図３】本発明の実施形態による（ａ）ＦＷに組込み型ＫＯＦ、（ｂ）レガシーＦＷと直列のＫＯＦ、および（ｃ）外部ＲＳ上のＫＯＦに関するそれぞれのネットワークアーキテクチャを示す図である。
【図４】図３パートａに示される実施形態による組込み型ＫＯＦファイアウォールアーキテクチャのＫＯＰメッセージコールフローを示す図である。
【図５】図３パートａに示される実施形態による組込み型ＫＯＦファイアウォールアーキテクチャの５タプルおよび２タプルに関係する状態および状態遷移を示す図である。
【図６】図３パートｂに示される実施形態によるレガシーファイアウォールアーキテクチャと直列のＫＯＦの５タプルおよび２タプルに関係する状態および状態遷移を示す図である。
【図７】図３パートｃに示される実施形態による外部ＲＳアーキテクチャにおいて提供されるＫＯＦのＫＯＰメッセージコールフローを示す図である。
【図８】図３パートａに示される実施形態による組込み型ＫＯＦファイアウォールアーキテクチャのインバウンドパケットに関するＦＳＭを示す図である。これらの流れ図は、タイマ満了による図５に示される状態遷移を含まない。
【図９】図３パートａに示される実施形態による組込み型ＫＯＦファイアウォールアーキテクチャのアウトバウンドパケットに関するＦＳＭを示す図である。これらの流れ図は、タイマ満了による図５に示される状態遷移を含まない。
【図１０】図３パートｂに示される実施形態によるファイアウォールアーキテクチャと直列のＫＯＦのインバウンドパケットに関するＦＳＭを示す図である。これらの流れ図は、タイマ満了による図６に示される状態遷移を含まない。
【図１１】図３パートｂに示される実施形態によるファイアウォールアーキテクチャと直列のＫＯＦのアウトバウンドパケットに関するＦＳＭを示す図である。これらの流れ図は、タイマ満了による図６に示される状態遷移を含まない。
【発明を実施するための形態】
【００２１】
これらの図面において、同様の特徴は、同様の参照符号によって表される。
【００２２】
図１を参照すると、ＦＷ上で、既存の接続に実際に、または潜在的に関係するすべての５タプルが、２つの状態：通過状態１または阻止状態２のいずれかに関連付けられることが可能であり、ただし、関連付けられた通過機能および阻止機能は、インバウンドパケットに適用される。各５タプルは、この５タプルを有するアウトバウンドパケットが通過している際、阻止状態２から通過状態１に変化する。通過状態１は、存続期間に関連付けられる。存続期間満了の後、５タプルは、阻止状態２に戻る。通過状態１で、タイマは、対応する５タプルを保持するアウトバウンドパケットごと、またはインバウンドパケットごとにリフレッシュされることが可能である。
【００２３】
通常のＦＷ実施形態において、通過状態１にある５タプルだけしか、キャッシュメモリの割当てを要求しない。阻止状態２は、デフォルトの状態であり、時間に左右される情報を担持しないので、キャッシュの割当てを要求しない。以下のデータ：５タプルおよび有効期限が、通過状態にある５タプルに関してＦＷ上に通常、保持される。
【００２４】
図２を参照すると、ＦＷ機能が、２つの有限状態マシン（ＦＳＭ）を通して表され得る。一方の状態マシン４は、インバウンドパケットを扱い、他方の状態マシン５は、アウトバウンドパケットを扱う。図２におけるＦＳＭ図は、状態有効期限切れによる状態遷移を省略していることに留意されたい。
【００２５】
図３を参照すると、ＫＯＰが、ホスト間接続管理を組み立てる規約手順（ｃｏｕｒｔｅｓｙ  ｐｒｏｃｅｄｕｒｅ）としてエンドホストによって使用されなければならない。例えば、認証などのさらなる機能が、これらのメッセージに組み込まれ得る。
【００２６】
ＫＯＰメッセージは、ＦＷ上のＫＯＦによってインターセプトされ、評価され、さらに処理されることが可能である。何らかの条件規則セットに基づいて、インバウンドＫＯＰメッセージが、ＦＷ上のＫＯＦによって内部のホストまで通過させられることが可能である。ＫＯＰメッセージおよびＫＯＦ規則セットの注意深い定義により、ＦＷを介する接続確立が、非常に強いセキュリティで保護された仕方で提供され得る。以下のセクションは、ＫＯＦが、ＦＷのセキュリティ機能を損なわないように、どのように設計されるかの概略を述べる。
【００２７】
ＫＯＰメッセージは、５タプルによって与えられるトランスポート接続に基づく。したがって、ＫＯＰメッセージは、対応する５タプル情報を伝送する。ＫＯＰは、以下のメッセージをサポートする：
−  ＫＯＰ  ＲＥＱ：特定の５タプルを代表して接続確立を要求する。
−  ＫＯＰ  ＡＣＫ：ＫＯＰ  ＲＥＱメッセージに応答して接続確立を承認する。
−  ＫＯＰ  ＮＡＫ：ＫＯＰ  ＲＥＱメッセージに応答して接続確立を拒否する。
−  ＫＯＰ  ＲＳＰ：ＫＯＰ  ＲＥＱメッセージに応答して、さらなる情報を要求する。このメッセージに対する応答は、別のＫＯＰ  ＲＥＱメッセージである。
−  ＫＯＰ  ＦＩＮ：５タプル接続を終了する。
【００２８】
以上の初めの４つのメッセージは、接続確立の時点に先立って、またはその時点で使用され、最後のメッセージは、接続終了時に、または接続終了の後に使用される。接続の存続期間中、ホスト上のＫＯＰクライアントは、状態情報を全く保持しなくてもよい。
【００２９】
５タプルとは別に、ＫＯＰメッセージは、任意の追加の情報を主に伝送することが可能である。例えば、ＫＯＰ  ＲＥＱメッセージは、ピアホストに接続に入ることを納得させる埋め込まれた情報を、例えば、送信側のホストの認証資格証明として伝送することも可能である。ＫＯＰ  ＲＳＰメッセージは、ピアホストが追加の情報を要求することを許す。ＫＯＰ  ＲＥＱ／ＲＳＰメッセージペアを使用することによって、より複雑なハンドシェークが確立され得る。
【００３０】
ＫＯＰメッセージは、タイプ−長さ−値フォーマットを使用して、情報を保持することが可能である。ＫＯＰメッセージは、以下のトランスポートフォーマットを使用し得る：
−  ＫＯＰメッセージは、特定のポート番号を有するＵＤＰを使用することが可能である。以降、特に明記しない限り、このアプローチが、ＫＯＰに関して使用される。
−  ＫＯＰメッセージは、それらのメッセージ独自のプロトコルタイプを伝送することが可能である。
−  ＫＯＰメッセージは、ＩＣＭＰを使用することが可能である。
−  ＫＯＰ情報は、ＩＰオプションヘッダ（ＩＰｖ４）またはＩＰ拡張ヘッダ（ＩＰｖ６）の中に埋め込まれ得る。これは、ＩＰｖ６に関して特に良好なソリューションである。
−  ＫＯＰメッセージは、特定のトランスポートプロトコルの中で実施されることも可能である。例えば、ＴＣＰの場合、ＴＣＰオプションヘッダが、ＫＯＰメッセージにフラグを付けるのに使用されることも可能である。例えば、ＫＯＰ  ＲＥＱメッセージは、ＴＣＰ  ＳＹＮメッセージ上に便乗させることが可能である。
−  ＫＯＰ情報は、既存のシグナリングプロトコル、例えば、ＩＫＥｖ２（ＩＥＴＦ  ＲＦＣ  ４３０６）の中に含められることが可能である。
【００３１】
ＫＯＰ対応のホストは、ＫＯＰメッセージを使用して、別のホストとの接続を確立すること、および終了すること、または別のホストからの接続開始要求を拒否することを目的として、ＫＯＰメッセージを作成すること、送信すること、受信すること、解釈すること、またはＫＯＰメッセージに応答することができるホストシステムである。好ましくは、ＫＯＰ対応のホストは、レガシーホストを相手に相互動作することができる。例えば、ＫＯＰ対応のホストが、レガシーホストに、接続を確立するＫＯＰ  ＲＥＱメッセージを送信すると、応答は、全く行われない。この場合、ＫＯＰ対応のホストは、数回の再送の後、単に諦めて、そのレガシーホストを相手に従来の仕方で接続を確立しようと試みることが可能である。
【００３２】
ＫＯＰの目的は、ＦＷやＮＡＴなどの中間ボックスを克服することであるので、接続を開始する側のホストは、ＫＯＰ  ＲＥＱメッセージを送信することと並行して、または従来の接続確立が失敗した後に、接続を確立しようと試みることさえ可能である。ＫＯＦを有するＦＷだけが、ＫＯＰ  ＲＥＱメッセージを通過させることに留意されたい。受信側のホスト（すなわち、ＫＯＰ  ＲＥＱメッセージが送信されるホスト）がＫＯＰ対応である場合、そのホストは、接続を開始する側のホストとの接続に入ることなしに、ＫＯＰ  ＮＡＫメッセージ、またはＫＯＰ  ＲＳＰメッセージでＫＯＰ  ＲＥＱメッセージに応答する機会を有する。しかし、受信側のホストが、レガシーホストであり、ＦＷの背後にはない場合、接続は、遅延なしに開始され得る。このことは、従来のコール確立手順が、ホストのいずれかがＫＯＰ対応ではない場合に、それでも適切に機能することを意味する。
【００３３】
ＫＯＰ情報が、トラフィック接続のＴＰＣ  ＳＹＮパケットと多重化されたＩＰオプションヘッダ、ＩＰ拡張ヘッダ、またはＴＣＰオプションヘッダの上で伝送される場合、注意が払われなければならない。例えば、中間ＦＷ上のＫＯＦフィーチャは、パケットのＫＯＰ部分に反応すること、すなわち、パケットを通過させることが可能である一方で、受信側のレガシーホストは、そのメッセージのＫＯＰ部分を単に破棄し、ＴＣＰ  ＳＹＮＡＣＫでＴＣＰ  ＳＹＮパケットに応答する。このことは、ＦＷのセキュリティ機能を基本的に無効にする。
【００３４】
ＫＯＰ  ＡＣＫメッセージは、ＫＯＰ対応の受信側のホストが、単に主導権を握り、ＫＯＰ  ＲＥＱメッセージに応答して接続を開始することが可能であるので、原則として不必要である。この事例に対処するのに、ＫＯＰ  ＲＥＱメッセージの送信側は、送信側で並行して接続を開始することができる。これにより、受信側のホストによって送信された着信するトラフィックパケットを通過させる５タプルを、送信側自らのファイアウォール上に作成する。
【００３５】
図３を参照すると、ＫＯＦが、内部のホストＨｉが、ＦＷの背後の内部のネットワーク１４、およびＦＷの反対側の外部のネットワーク１６を介して外部のホストＨｏに通信するように接続される、それぞれのネットワークアーキテクチャ１０ａから１０ｃに示される３つの仕方で提供されることが可能である。したがって、ＫＯＦは、ａ）組込み型ＫＯＦファイアウォール１２として示される第１の仕方、ｂ）に、レガシーファイアウォールであり得るＦＷ２０と直列に追加されたＫＯＦ１８として示される第２の仕方、またはｃ）に、公共のＲＳ（中継サーバ）２２上で提供されるＫＯＦで示される第３の仕方で提供され得る。
【００３６】
図４は、第１のネットワークアーキテクチャ１０ａによる組込み型ＫＯＦファイアウォール１２の事例に関する接続確立および接続終了の例示的なコールフローを示す。また、これらのコールフローは、ＫＯＦ１８がＦＷ２０に直列に追加された第２のネットワークアーキテクチャ１０ｂにも当てはまる。
【００３７】
図４を参照すると、外部のホストＨｏが、内部のホストＨｉにＫＯＰ  ＲＥＱメッセージを送信すること（３０）によって、内部のホストＨｉとの接続を開始しようと試みる。組込み型ＫＯＦファイアウォール１２が、ＫＯＰ  ＲＥＱメッセージを受信し、このメッセージをＫＯＰメッセージとして認識して、このメッセージを内部のホストＨｉに転送する（３２）。内部のホストＨｉは、ＫＯＰ  ＮＡＫメッセージを外部のホストＨｏに送信すること（３４）によって、このＫＯＰ  ＲＥＱメッセージに応答することが可能である。組込み型ＫＯＦファイアウォール１２が、このＫＯＰ  ＮＡＫメッセージを受信し、このメッセージをＫＯＰメッセージとして認識して、このメッセージを外部のホストＨｏに転送する（３６）。このＫＯＰ  ＮＡＫメッセージは、内部のホストＨｉが、要求された接続の確立を拒否したことを示すので、このメッセージを受信すると、外部のホストＨｏは、要求された接続を確立することをしない。ＫＯＰ  ＮＡＫの代わりに、内部のホストＨｉは、ＫＯＰ  ＡＣＫメッセージを外部のホストＨｏに送信すること（３８）が可能であり、そのメッセージは、内部のホストＨｉが、要求される接続の確立を承認したことを示す。組込み型ＫＯＦファイアウォール１２が、このＫＯＰ  ＡＣＫメッセージを受信し、このメッセージをＫＯＰメッセージとして認識して、このメッセージを外部のホストＨｏに転送する（４０）。このＫＯＰ  ＡＣＫメッセージを受信すると、外部のホストＨｏが、要求された接続を確立することを開始する。
【００３８】
ＫＯＰ  ＡＣＫメッセージまたはＫＯＰ  ＮＡＫメッセージを送信することの代替として、内部のホストＨｉが、追加の情報を要求するＫＯＰ  ＲＳＰメッセージを外部のホストＨｏに送信すること（４２）が可能である。組込み型ＫＯＦファイアウォール１２が、このＫＯＰ  ＲＳＰメッセージを外部のホストＨｏまで通過させる（４４）とともに、このＫＯＰ  ＲＳＰメッセージに応答して外部のホストＨｏが内部のホストＨｉに送信する（４６）第２のＫＯＰ  ＲＥＱメッセージを通過させる（４８）。第２のＫＯＰ  ＲＥＱメッセージを受信すると、内部のホストＨｉは、前に、第１のＫＯＰ  ＲＥＱメッセージが受信された場合と同一のオプションを有する。内部のホストＨｉが接続を確立しており、この接続を終了することを所望する場合、内部のホストＨｉは、ＫＯＰ  ＦＩＮメッセージを外部のホストＨｏに、このメッセージを外部のホストＨｏまで通過させる（５２）組込み型ＫＯＦファイアウォール１２を介して送信すること（５０）によって、この接続が終了されるべきことを外部のホストＨｏにシグナリングする。
【００３９】
図５を参照すると、組込み型ＫＯＦファイアウォール１２機能が、インバウンドトラフィックパケットに関係する５タプル６０、およびインバウンドＫＯＰ  ＲＥＱパケットに関係する２タプル６２に関連付けられることが可能である。５タプル６０状態は、インバウンドトラフィックパケットが通過させられるべきか、または阻止されるべきかを決定する。２タプル６２状態は、インバウンドＫＯＰ  ＲＥＱメッセージが通過させられるべきか、または阻止されるべきかを決定する。２タプルとは、｛Ｈｉ，Ｈｏ｝ＩＰアドレスペアを指し、ただし、Ｈｉは、内部のホストＨｉを表し、Ｈｏは、外部のホストＨｏを表す。外部のホストＨｏは、外部のホストＨｏ自らのＦＷの背後に存在することも可能であることに留意されたい。
【００４０】
一般に、ＫＯＰメッセージは、通過状態にある対応する２タプルエントリが存在する場合に限って、通過させられる。そのようなエントリが存在しない場合、ＫＯＦは、そのようなエントリを作成し、そのエントリを通過状態に設定する。ＫＯＦは、阻止状態にある対応する２タプルエントリが存在する場合、ＫＯＰ  ＲＥＱメッセージを通過させない。２タプルのこの２モードの振舞いは、以下の機能をもたらす：通過状態が、ＫＯＰ  ＲＥＱメッセージの着信レートがクリティカルなレベルを下回っているかどうかを調べ、下回っている場合、ＫＯＰ  ＲＥＱメッセージは、通過することを許され、下回っていない場合、阻止状態が呼び出されて、さらなるＫＯＰ  ＲＥＱメッセージの着信から内部のホストＨｉを保護する。
【００４１】
各５タプルは、通過状態６８または阻止状態６６にあることが可能であるのに対して、各２タプルは、アイドル状態７４、通過状態８６、または阻止状態７８にあることが可能である。ＫＯＦが組み込まれたＦＷは、５タプル阻止状態６６または２タプルアイドル状態７８がデフォルトの状態であり、さらにこれらの状態が時間に左右される情報を全く担持しないので、これらの状態に関するキャッシュメモリを、全く保持しない。５タプル通過状態６８に関して、ＫＯＦが組み込まれたＦＷは、５タプル、および有効期限をキャッシュする。２タプル通過状態８６に関して、ＫＯＦが組み込まれたＦＷは、その２タプル、有効期限タイマ、およびメッセージカウンタをキャッシュする。２タプル阻止状態７８に関して、ＫＯＦが組み込まれたＦＷは、その２タプル、および有効期限タイマをキャッシュする。
【００４２】
ＫＯＦが組み込まれたＦＷ１２は、内部のホストＨｉと外部のホストＨｏの間の既存の接続、または内部のホストＨｉによる接続確立の試みに対する５タプル通過状態６８エントリを保持する（７２）。ＫＯＦが組み込まれたＦＷ１２は、外部のホストＨｏが内部のホストＨｉとの接続を確立しようと試みる際、インバウンドＫＯＰ  ＲＥＱメッセージのレートを制御する２タプル通過状態エントリ｛Ｈｉ，Ｈｏ｝を保持する（８６）。ＫＯＦが組み込まれたＦＷ１２は、外部のホストＨｏによるさらなるＫＯＰ  ＲＥＱメッセージの試みからそのようなメッセージが内部のホストＨｉによって所望されない場合に、または外部のホストＨｏが、外部のホストＨｏが内部のホストＨｉに送信したＫＯＰ  ＲＥＱメッセージの容認可能なレートを超えた場合に、内部のホストＨｉを保護する２タプル阻止状態７８エントリを保持する。
【００４３】
５タプル６０に基づく機能は、いくつかの例外を除いて従来のＦＷによって提供される機能と同様である。第１に、５タプル６０に基づく阻止機能は、インバウンドＫＯＰ  ＲＥＱメッセージには適用されない。代わりに、インバウンドＫＯＰ  ＲＥＱメッセージは、そのメッセージに関連付けられた２タプル６２の状態の対象となる。第２に、５タプル６０エントリは、アウトバウンドのＫＯＰ  ＲＥＱメッセージ、ＲＳＰメッセージ、またはＦＩＮメッセージが通過した際には、作成されない。
【００４４】
従来のＦＷ機能に加えて、５タプル６０は、５タプルに対応するアウトバウンド（すなわち、内部のホストＨｉから送信された）ＫＯＰ  ＡＣＫメッセージが、組込み型ＫＯＰファイアウォール１２を通過させられると、阻止状態６６から通過状態６８への遷移６４を経験する。また、この遷移６４は、通常のパケット（すなわち、ＫＯＰメッセージを伝送していないパケット）が、組込み型ＫＯＰファイアウォール１２を通過されられた際にも、生じる。
【００４５】
従来のＦＷ機能に加えて、５タプル６０は、５タプル６０に対応するアウトバウンドＫＯＰ  ＦＩＮパケットが、組込み型ＫＯＰファイアウォール１２を通過させられると、通過状態６８から阻止状態６６への遷移７０をさらに経験する。このフィーチャは、内部のホストＨｉが、終了した接続に関してＦＷ上の５タプルエントリを閉じることを許し、これにより、さもなければ、「セキュリティホール」（つまり、セキュリティの脆弱性）となる可能性があるエントリが、内部のホストＨｉによって閉じられることが可能であるので、内部のホストＨｉに相当なセキュリティをもたらす。
【００４６】
組込み型ＫＯＰファイアウォール１２は、各５タプルの通過状態６８に関するタイマを含み、このタイマは、満了すると、通過状態６８から阻止状態６６への遷移７０を生じさせる。さもなければ、５タプル６０に対応するインバウンドパケットまたはアウトバウンドパケットが、組込み型ＫＯＰファイアウォール１２を通過するとともに、５タプル６０は、ＦＷ状態を通過状態６８に保つ（７２）。通過状態６８におけるタイマに関連する機能、および通過状態６８からの遷移７０に関連する機能は、従来のファイアウォールの場合と同一である。
【００４７】
すべての２タプル６２は、内部のホストＨｉと外部のホストＨｏの間のＫＯＰメッセージに含まれる｛Ｈｉ  ＩＰアドレス，Ｈｏ  ＩＰアドレス｝−ペアに基づく。ＫＯＦが組み込まれたＦＷ１２は、３つの状態：アイドル状態７４、通過状態７６、および阻止状態７８のうちの１つに２タプル６２を保つ。ＫＯＦが組み込まれたＦＷ１２は、以下のように動作する。アイドル状態７４にあり、対応する内部のホストＨｉに対するインバウンドＫＯＰ  ＲＥＱメッセージが着信すると、２タプル６２は、通過状態７６に遷移し（８０）、ＫＯＰ  ＲＥＱメッセージに、組込み型ＫＯＦファイアウォール１２を通過させる。通過状態７６は、存続期間属性と、最大カウント属性とを有する。存続期間属性の値によって決まる、通過状態７６の存続期間中、最大カウント属性の値と等しい最大限の数のＫＯＰ  ＲＥＱメッセージしか、この２タプルに関して転送され得ない。通過状態７６の存続期間が、ＫＯＰ  ＲＥＱメッセージのこの最大限の数に達する前に満了した場合、２タプル６２は、アイドル状態７４に遷移する（８２）。通過状態７６の存続期間が満了する前に、ＫＯＰ  ＲＥＱメッセージの最大限の数に達した場合、２タプル６２は、阻止状態７８に遷移する（８４）。最大限の数に達していない場合、通過状態７６にある２タプル８６は、２タプルのアウトバウンドＫＯＰ  ＲＥＱメッセージ、およびアウトバウンドＫＯＰ  ＲＳＰメッセージが、組込み型ＫＯＦファイアウォール１２を通過するとともに通過状態をリフレッシュする（８６）。遷移８６は、通過状態７６の通過状態タイマ、および通過状態カウンタをリセットする。阻止状態７８において、外部のホストＨｏから内部のホストＨｉへのさらなるインバウンドＫＯＰメッセージは、組込み型ＫＯＦファイアウォール１２によって拒否される。阻止状態７８は、阻止状態７８独自の存続期間属性を有し、この存続期間属性の値が、阻止状態７８の存続期間を決める。阻止状態７８の存続期間の満了の後、２タプル６２は、アイドル状態７４に遷移する（８８）。
【００４８】
内部のホストＨｉが、ＫＯＰ  ＲＥＱメッセージを受信し、さらに内部のホストＨｉは、要求された接続を確立することに関心がない場合、内部のホストＨｉは、ＫＯＰ  ＮＡＫメッセージで、接続を開始する側の外部のホストＨｏに応答することが可能である。このＫＯＰ  ＮＡＫメッセージは、ＫＯＦが組み込まれたＦＷ１２上の２タプル６２に、通過状態７６から阻止状態７８に直接に遷移させ（８４）、これにより、組込み型ＫＯＦファイアウォール１２に、外部のホストＨｏから内部のホストＨｉに送信されるさらなるＫＯＰ  ＲＥＱメッセージを阻止させる。
【００４９】
ＫＯＦ状態が、通過状態７６にあり、さらに対応する内部のホストＨｉが、対応する外部のホストＨｏからさらなる情報を要求するアウトバウンドＫＯＰ  ＲＳＰメッセージを送信した場合、ＫＯＦが組み込まれたＦＷ１２は、２タプル６２に関する通過状態タイマおよび通過状態カウンタをリセットする。ＫＯＦが組み込まれたＦＷ１２は、通過状態タイマおよび通過状態カウンタを使用して、その２タプル６２に関して、対応する通過状態存続期間が満了したかどうか、または通過状態７６にある間に許されるメッセージの最大限の数に達しているかどうかを判定する。このリセット能力は、外部のホストＨｏに、必要である可能性がある再送を含むＫＯＰ  ＲＥＱメッセージで、ＫＯＰ  ＲＳＰメッセージに応答する機会を与える。
【００５０】
内部のホストＨｉによって送信されるＫＯＰ  ＲＳＰメッセージおよびＡＣＫメッセージは、外部のホストＨｏもＦＷの背後に存在する場合、ＫＯＰ  ＲＥＱメッセージの役割をすることも可能である。したがって、ＫＯＰ  ＲＥＱ／ＲＳＰメッセージハンドシェークまたはＫＯＰ  ＲＥＱ／ＡＣＫメッセージハンドシェークが、両方のファイアウォール上のパスを通過できるようにする。そのようなハンドシェークは、両方のホストがファイアウォールの背後にある場合に、セキュリティで保護された仕方で接続確立を可能にする。
【００５１】
このセットのフィーチャを用いて、ＫＯＦは、組込み型ＫＯＦファイアウォール１２を介して以下の保護をもたらす：ＫＯＦは、或るタイプの制御メッセージを内部のホストＨｉまで通過させるようにＦＷを開く一方で、そのようなメッセージのインバウンドパケットフローを、通過状態７６存続期間当りの最大カウントに制限する。このレート（通過状態７６最大カウントの値、および存続期間属性の値によって決まる）が外部のホストＨｏによって超えられると、阻止状態７８が、何らかの延長された期間にわたって、内部のホストＨｉをさらなるＫＯＰ  ＲＥＱメッセージから保護する。通過状態７６存続期間属性の値は、有利には、複数のＫＯＰ  ＲＥＱメッセージ再送に対処することができるように数秒に設定される。したがって、阻止状態７８は、ＫＯＰ  ＲＥＱメッセージフラッディング攻撃から、内部のホストＨｉを保護するために、阻止状態７８存続期間属性の値は、通過状態７６の存続期間より長い存続期間をもたらさなければならない（例えば、阻止状態７８の存続期間は、数分または数時間でさえある）。
【００５２】
組込み型ＫＯＦファイアウォール１２におけるＫＯＦによってもたらされる前述の保護を向上させるのに、ＫＯＰメッセージのパケット長が、指定された最大限の長さに制限されることが可能である。合計のメッセージ長を５７６オクテット未満に保つことが賢明であり、このことは、パケット断片化が適用されないことを意味する。したがって、ＫＯＰメッセージを処理する前に、ＫＯＦは、そのＫＯＰメッセージを伝送するパケットの長さを評価し、そのパケットの長さが指定された最大限の長さを超える場合、そのパケットを破棄する。
【００５３】
ＫＯＦによって提供される保護をさらに強化するために、ＫＯＰメッセージに関して特定のＴＬＶフォーマットが導入されることも可能である。このフォーマットは、タイプ定義および値の長さが柔軟であるが、組込み型ＫＯＦファイアウォール１２およびホストが、組込み型ＫＯＦファイアウォール１２およびホストがタイプ定義を認識しないＫＯＰメッセージを破棄することを可能にすることによって、ホストにさらなる保護をもたらす。
【００５４】
ＫＯＦは、内部のホストが、内部のホストがＫＯＰ  ＲＥＱメッセージを拒否した外部のホストを相手に接続を確立することを禁止しないことに留意されたい。この能力は、ＫＯＦが組み込まれたＦＷ１２が、対応するホストペアの２タプル６２が阻止状態７８を保持しているものの、５タプル６０を通過状態６８に保つことができることを意味する。この振舞いは、組込み型ＫＯＦファイアウォール１２をレガシーＦＷ機能に適合させるので、重要である。
【００５５】
２タプル６２の状態は、かなり簡単に実施され得る：アイドル状態７４は、時間に左右される情報を全く保持しないので、メモリの割当てを要求しない。したがって、通過状態７６にある２タプル、または阻止状態にある２タプルだけが、メモリの中に保持される。この目的で、以下のデータ構造がメモリの中に保持される：
ＫＯＦ通過状態：
−  ２タプル
−  有効期限（通過状態存続期間が満了する時刻）
−  カウンタ（最大カウント属性の値までＫＯＰメッセージの数をカウントアップする、または最大カウント属性の値からＫＯＰメッセージの数をカウントダウンする）
ＫＯＦ通過状態有効期限は、前述した通過状態タイマを実施し、さらにＫＯＦ通過状態カウンタは、前述した通過状態カウンタを実施する。
ＫＯＦ阻止状態：
−  ２タプル
−  有効期限（阻止状態存続期間が満了する時刻）
通常の動作の下で、メモリの中に保持されるべきＫＯＦ状態の数は、ごくわずかである。しかし、この数は、メッセージフラッディング攻撃中、大幅に増大する可能性がある。そのような状況下で、次のセクションで説明されるプレフィックスベースの保護が有益である。
プレフィックスベースの保護
ＫＯＦが組み込まれたＦＷ１２は、それぞれの内部のホストＨｉに着信するＫＯＰ  ＲＥＱメッセージのレートを制限するが、内部のホストをＫＯＰ  ＲＥＱメッセージのフラッディング攻撃から保護することもしなければならない。このことは、ＫＯＦ自体の過負荷につながる攻撃を含む。そのような状況下で、ＫＯＦは、ＫＯＦの機能をむしろ一時的に低下させなければならず、これにより、組込み型ＫＯＦファイアウォール１２機能を従来のＦＷの機能に戻す。
【００５６】
ＫＯＦは、多数のスプーフィングされたＩＰアドレスを発信元とし、１つの内部のホストＨｉに向けられたＫＯＦ  ＲＥＱメッセージのフラッドに対して脆弱になり得る。これは、ＫＯＦが、スプーフィングされたすべてのＩＰアドレスを発信元とするＫＯＦ  ＲＥＱメッセージのもたらされる２タプルごとに１つのエントリ６２を保持し、このことが、組込み型ＫＯＦファイアウォール１２が、メッセージのフラッド全体を通過させることをもたらすためである。
【００５７】
原則として、ＩＰアドレススプーフィングは、中間ルータによるイングレスフィルタリングを介して挫かれる。しかし、イングレスフィルタリングは、必ずしも執行されるとは限らない。さらに、攻撃者はそれでも、同一のＬ２ネットワーク、すなわち、１つのＬ３サブネットに属するＩＰアドレスをスプーフィングすることができる可能性がある。
【００５８】
ＫＯＦは、前段で概説した｛Ｈｉ  ＩＰアドレス，Ｈｏ  ＩＰアドレス｝という原始２タプルを｛Ｈｉ  ＩＰアドレス、Ｈｏ  ＩＰプレフィックス｝というプレフィックスベースの形態に拡張することによって、そのようなフラッディング攻撃に対して防御することができる。このプレフィックスベースの形態において、外部のホストＨｏのプレフィックスに適合する、内部のホストＨｉに関するすべての着信するＫＯＰ  ＲＥＱメッセージは、同一のＫＯＦ状態を使用して同一の２タプル６２によって扱われる。
【００５９】
２タプル６２の、原始形態からプレフィックスベースの形態への拡張は、ＩＰプレフィックスに基づく阻止が、多数の友好的なホストについてもアクセスのしやすさを低減する可能性があるので、徐々に行われる必要がある。様々なアルゴリズムが、この目的で導入され得る。１つの簡単で、非常に効果的な方法は、以下のとおりである：
−  それぞれの内部のホストＨｉに関して、ＫＯＦは、通過状態７６または阻止状態７８にある或る最大限の数Ｎの２タプルだけを、これら２つの状態がメモリ割当てを要求するので、保持することが可能である。これら２つの状態のいずれかを保つ２タプルは、２タプルエントリと呼ばれる。
−  内部のホストＨｉに関する２タプルエントリの数がＮに達し、さらに内部のホストＨｉに対する新たなインバウンドＫＯＦ  ＲＥＱが着信して、通過状態７６にある新たな２タプルエントリの生成をもたらすと、内部のホストの２タプルエントリのうちの２つが組み合わされて、単一の２タプルエントリにされなければならない。組み合わされた２タプルエントリは、前述した２つの２タプルエントリのそれぞれ１つの２タプルにそれぞれが対応する、外部のホストＨｏのＩＰアドレスの共通部分を「プレフィックス」として使用する。プレフィックスという用語は、この場合、サブネット割当ての意味で使用されていないことに留意されたい。
−  両方の２タプルエントリが、同一の状態（通過状態７６または阻止状態７８）を有する場合、この状態は、組み合わされた２タプルエントリに持ち越される。この状態が通過状態７６である場合、組み合わされた２タプルエントリのカウンタは、前の２タプルエントリのカウンタのうちの大きい方の値に設定され、さらに組み合わされた有効期限は、前の２タプルエントリの有効期限のうちの小さい方の値に設定される。この状態が阻止状態７８である場合、組み合わされた２タプルエントリの有効期限は、前の２タプルエントリの有効期限のうちの大きい方の値に設定される。
−  両方の２タプルエントリが、異なる状態を有する（一方が、通過状態７６にあり、他方が、阻止状態７８にある）場合、組み合わされた２タプルエントリは、阻止状態７８に設定され、有効期限は、リセットされる。
−  組合せ手順のために使用される２タプルエントリの選択は、マージされた２タプルに関する最長のプレフィックスに基づくことが可能である。このプレフィックスが長いほど、外部のホストのＩＰアドレス間のトポロジ上の距離は小さくなる。この選択プロセスの計算作業は、数Ｎがかなり小さいように選択され得るので、かなり少ない。
例：Ｎ＝３：
内部のホストＨｉは、内部のホストＨｉに対する新たなＫＯＦ  ＲＥＱが着信する際に、Ｎ＝３個の２タプルエントリを既に有する：
【００６０】
【表１】
0005524361.tif 000002
0005524361.tif 000003
２タプルエントリ１と３が、最大の共通のプレフィックスを有するため、組み合わされ、このことが、以下をもたらす：
【００６１】
【表２】
0005524361.tif 000004
−  現時点で状態１として示される、組み合わされたＫＯＦ状態は、ＩＰアドレスの最下位の２オクテットに関して使用される「Ｘ．Ｘ」により、いわゆるプレフィックスベースの形態である、２００．１．Ｘ．Ｘという外部ホストのＨｏ  ＩＰアドレスを有する。「Ｘ．Ｘ」は、外部のホストのＩＰアドレスの対応するオクテットに関するすべての値と合致する。さらに、組み合わされたＫＯＦ状態の通過状態カウンタ（メッセージカウンタ）は、前のＫＯＦ状態１および３の通過状態カウンタの値の大きい方である、３に設定される。新たなＫＯＦ状態の通過状態タイマ（有効期限タイマ）は、前のＫＯＦ状態１および３の通過状態タイマの短い方である、「現在＋３１２０ミリ秒」に設定される。
【００６２】
ＫＯＦは、２タプルエントリ組合せの履歴についての情報を全く保持する必要はない。状態遷移は、従来のＩＰアドレスベースの状態と同様にプレフィックスベースの状態に当てはまる。アイドル状態７４に達すると、アイドル状態７４において全くメモリが保持されないので、状態バンドル情報が、失われる。この機構は、状態バンドルをスムーズに逆転させ、さらにＫＯＦがその通常の動作モードを緩和することを許す。
【００６３】
前述の組合せプロセスは、内部のホストＨｉに関する２タプルエントリの最大限の数Ｎに基づく。この数は、動的に調整され得る。あるいは、Ｎに関する固定値が、それぞれの内部のホストＨｉに割り当てられる、または代替として、２タプルエントリの１つの共通のプールが、すべての内部のホストＨｉのために割り当てられることが可能である。このプールが一杯であり、新たな２タプルエントリが追加されることになる場合、最大の数の２タプルを有する内部のホストＨｉが選択され得る。このプールが、内部のホストＨｉの数より小さい場合、プールが一杯である一方で、すべての内部のホストＨｉが、複数の２タプルエントリを保持することはないことが生じ得る。これが該当する場合、同一の組合せ手順が、Ｈｉ−ＩＰアドレスに関して適用されることが可能である。この場合、２タプルエントリは、内部のホストＨｉのためにプレフィックスを保持することも可能である。
【００６４】
プレフィックスベースの保護の場合、送信元ＩＰアドレスのプールを使用する、内部のホストＨｉに対するＫＯＦ  ＲＥＱメッセージのフラッディング攻撃は、攻撃者のサブネットに属する外部のホストＨｏのＩＰアドレスプレフィックスを有する、阻止状態７８にある１つの２タプルエントリをもたらす。攻撃者からの、その内部のホストＨｉに対するすべてのさらなるＫＯＰ  ＲＥＱメッセージは、組込み型ＫＯＰファイアウォール１２によって阻止される。同時に、組込み型ＫＯＰファイアウォール１２は、その内部のホストＨｉを相手に接続を確立しようと試みる別のサブネットからの外部のホストに関して、通常どおりに動作する。
【００６５】
そのようなフラッディング攻撃は、中間ルータのイングレスフィルタリングが、不可解な出所のパケットを破棄するので、１つのサブネットに属するＩＰアドレスに通常、限定されることに留意されたい。攻撃者がインターネット全体からＩＰアドレスをスプーフィングするという起こりそうにないことが生じた場合でさえ、プレフィックスベースの保護は、すべての着信するＫＯＦ  ＲＥＱメッセージを阻止することになる。この限度内で、組込み型ＫＯＦファイアウォール１２は、従来のＦＷと同一の保護をもたらす。
【００６６】
ＫＯＰ  ＲＥＱメッセージフラッディング攻撃から内部のホストＨｉを保護することに加えて、プレフィックスベースの保護は、有利には、２タプルエントリのために必要とされるメモリの量を制限する。さらに有利には、プレフィックスベースの保護は、それぞれのホストに関して少数のＫＯＦ状態しか保持されないので、内部のホストＨｉに対して新たなＫＯＰ  ＲＥＱメッセージが着信した場合の計算作業を少なくする。
レガシーファイアウォールと直列のノックオンフィーチャ
図３を再び参照し、特に、第２のネットワークアーキテクチャ１０ｂを参照すると、ＫＯＦ１８が、ファイアウォール２０と直列に別個の機能として追加されることも可能である。このことは、ＵＤＰベースのＫＯＰメッセージが使用される場合、実現するのが特に容易である。この場合、ファイアウォール上で対応するＵＤＰポートが、開かれる。
【００６７】
図６は、ＫＯＦ１８がファイアウォール２０と直列である第２のネットワークアーキテクチャ１０ｂのＫＯＦ１８およびファイアウォール２０の５タプル状態および２タプル状態、ならびに状態遷移を示す。ファイアウォール２０は、この場合、従来のファイアウォール機能をもたらす５タプル１００をサポートするレガシーファイアウォールである。ＫＯＦ１８は、組込み型ＫＯＦファイアウォール１２に関して前述した２タプル６２と同一の仕方で動作する２タプル１０２と、５タプル１０４とをサポートする。
【００６８】
５タプル１００は、内部のホストＨｉと外部のホストＨｏの間の接続に関連する、対応する５タプルに関する状態を保持する。ＦＷ２０が、特定の５タプルが通過状態１０６に、もしくは阻止状態１０８に留まるべきか、または通過状態１０６から阻止状態１０８への遷移、もしくは阻止状態１０８から通過状態１０６への遷移を行うべきかを制御する。通過状態１０６にある間、通過タイマが更新され、通過タイマが満了すると、５タプル１００状態は、通過状態１０６から阻止状態１０８に遷移する（１１０）。満了していない場合、ＦＷ状態は、対応する５タプルのインバウンドパケットまたはアウトバウンドパケットがファイアウォール２０を通過させられる限り、通過状態に留まる（１１２）。通過状態１０６に留まっている際、通過状態１０６に関連付けられたタイマがリセットされる。阻止状態１０８にある間、ＦＷ状態は、対応する５タプルのアウトバウンドパケットがファイアウォール２０によって通過させられると、阻止状態１０８から通過状態１０６に遷移する（１１４）。
【００６９】
ＫＯＦ１８は、内部のホストＨｉと外部のホストＨｏの間のインバウンドＫＯＰ  ＲＥＱメッセージに関連する２タプルを保持する。ファイアウォール２０は、ＫＯＰメッセージを橋渡しするので、ＫＯＦ１８は、ＫＯＦが組み込まれたＦＷ１２が２タプル６２を操作したのと同一の仕方で、第２のネットワークアーキテクチャ１０ｂにおいて２タプル１０２を操作することが可能である。この実施形態の以上の説明を簡単にするため、２タプル１０２のＫＯＦ１８処理は、ＫＯＦが組み込まれたＦＷ１２における２タプル６２と同一の仕方で実施されるものと理解される。
【００７０】
第１のネットワークアーキテクチャ１０ａの組込み型のアプローチとは異なり、第２のネットワークアーキテクチャ１０ｂのＫＯＦ１８は、５タプル１００を処理するＦＷ２０と直列で５タプル１０４を処理する。ＫＯＦ１８によって保持される５タプルは、内部のホストＨｉと外部のホストＨｏの間の任意の実際の、または潜在的な接続に対応する。ＫＯＦ１８は、５タプル１０４が通過状態１１６に、もしくは阻止状態１１８に留まるべきか、または通過状態１１６から阻止状態１１８への遷移、もしくは阻止状態１１８から通過状態１１６への遷移を行うべきかを制御する。ＫＯＦ１８は、ＫＯＰ  ＦＩＮメッセージをサポートし、すなわち、内部のホストＨｉからのアウトバウンドＫＯＰ  ＦＩＮメッセージに基づいて、内部のホストＨｉに対する５タプルの着信するトラフィックパケットを阻止する。したがって、ＫＯＦの５タプル状態１０４が、通過状態１１６にあり、さらに５タプル１０４に対応するＫＯＰ  ＦＩＮメッセージが、アウトバウンド方向でＫＯＦ１８を通過させられると、通過状態１１６にある５タプル１０４は、阻止状態１１８に遷移する（１２０）。そうではなく、ＫＯＦの５タプル状態１０４が、ＫＯＰ  ＦＩＮメッセージがＫＯＦ１８を通過させられる際に既に阻止状態１１８にある場合、ＫＯＦの５タプル状態１０４は、阻止状態１１８に留まり（１２２）、さらに５タプル阻止タイマをリセットする。阻止状態タイマが満了した場合、または５タプルに対応するアウトバウンドパケットが、内部のホストＨｉからＫＯＦ１８を通過させられた場合、５タプル１０４は、阻止状態１１８から通過状態１１６に遷移する（１２４）。阻止状態タイマは、５タプル１００の通過状態タイマが満了するのにかかる時間と等しい時間の後に満了する。
【００７１】
５タプル１００は、５タプル１００に関して通過状態１０６だけを実施することによって実現され得る一方で、ＫＯＦの５タプル１０４は、ＫＯＦの５タプル１０４に関して阻止状態１１８だけを実施することによって実現され得る。したがって、ＫＯＦの５タプル１０４に関するメモリ要件は、ほぼ、ＦＷの５タプル１００のメモリ要件以下である。つまり、ＦＷの５タプル１００に関して、通過状態１０６にあるＦＷ状態は、それらの状態に対応する接続の存続期間に通過状態１０６の存続期間を足した期間にわたってメモリを占有する。一方、ＫＯＦの５タプル１０４の場合、阻止状態１１８にあるＫＯＦの５タプル状態は、それぞれの阻止状態タイマによって決定される阻止状態１１８の存続期間にわたってのみ、メモリを占有し、前述したとおり、阻止状態タイマは、ＦＷの５タプル１００通過状態１０６の通過タイマが満了するのにかかる時間と等しい時間の後、満了する。
【００７２】
第２のネットワークアーキテクチャ１０ｂの５タプル１００動作とＫＯＦの５タプル１０４動作の組合せは、組込み型ＫＯＦファイアウォール１２における５タプル６０動作と同一の機能を実現する。しかし、第２のネットワークアーキテクチャ１０ｂの直列ソリューションは、ＫＯＦ  ＡＣＫメッセージをサポートしない。有利には、ＫＯＦ  ＡＣＫメッセージの効果は、通常のトラフィックパケットによって実現されることが可能である。
【００７３】
図７、ならびにレガシーＦＷ２０をサポートする中継サーバ（ＲＳ）２２上でＫＯＦが提供される、対応する第３のネットワークアーキテクチャ１０ｃを参照する。ＲＳ２２は、公共のインターネットにある、または公共のインターネットから少なくともアドレス指定可能であるものと仮定される。さらに、内部のホストＨｉは、ＲＳ２２に対するシグナリング接続を有する。本明細書では、内部のホストＨｉは、例えば、ＤＮＳ（ドメインネームサーバ）を使用して、ＲＳ２２と連絡をとることができる、ＲＳ２２のＩＰアドレス、プロトコルタイプ、およびポートを公開するものと仮定する。
【００７４】
組込み型ＫＯＦファイアウォール１２のセキュリティと同等のレベルのセキュリティをもたらすのに、第３のネットワークアーキテクチャ１０ｃにおいて、内部のホストＨｉとＲＳ２２の間のシグナリング接続上のトラフィックが、完全性保護される。シグナリングトラフィックが公共のインターネットを通過し、したがって、完全性攻撃に脆弱であるので、このことが行われる。
【００７５】
外部のＨｏが、ＲＳ２２にＫＯＰ  ＲＥＱメッセージを送信する際、外部のホストＨｏは、そのＫＯＰ  ＲＥＱメッセージのペイロードの中で内部のホストＨｉを明示的に参照する必要がある。このことは、組込み型ＫＯＦファイアウォール１２が、ＫＯＰ  ＲＥＱメッセージのＩＰヘッダから内部のホストＨｉを推測することができる第１のネットワークアーキテクチャ１０ａとは異なる。同様に、外部のホストＨｏは、プロトコルタイプおよびポート番号についての情報をＫＯＰ  ＲＥＱメッセージのペイロードの中に追加することが可能である。
【００７６】
しかし、このアプローチは、脆弱性を増大させる。つまり、内部のホストＨｉのＩＰアドレスが、ルーティング目的で使用されず、ＫＯＰ  ＲＥＱメッセージのペイロードの中で伝送されるだけであるので、このＩＰアドレスは、任意の攻撃者によって変更され得る。この脆弱性を克服するのに、外部のホストＨｏは、ＲＳ２２に送信されるＫＯＰ  ＲＥＱメッセージの完全性を保護しなければならない。
【００７７】
ＫＯＰ  ＲＥＱメッセージのこの完全性保護は、公開鍵／秘密鍵ペアまたは共有鍵を介して実現され得る。例えば、ＤＨ（ディフィ−ヘルマン）交換を使用するセキュリティ関連付けで十分であるはずである。ＤＨ交換に基づくそのような共有鍵を破るのに、各終端との別々の接続を維持するＭｉｔＭ（中間者）システムが要求されることになる。この手順において、ＭｉｔＭシステムは、中間ルータによるイングレスフィルタリングの犠牲にならずに、それぞれのエンドポイントのＩＰアドレスをスプーフィングすることができる必要があることになる。そのようなＭｉｔＭシステムが存在する場合、そのシステムは、ＦＷ２０を直接に、すなわち、ＦＷ２０上の既存の５タプルエントリに対するＩＰアドレスをスプーフィングすることによって、克服することもできることになる。したがって、ＲＳ２２と外部もしくは内部のホストＨｏ／Ｈｉの間のＫＯＰメッセージ交換に関してＤＨベースの鍵を使用することで、そうすることが、レガシーＦＷ２０と少なくとも同一のレベルの保護をもたらすので、これらの交換の完全性保護に十分であるはずである。
【００７８】
図７を参照し、図３パートｃも参照すると、ＲＳ２２と外部のホストおよび内部のホストＨｏ／Ｈｉの間の例示的なメッセージコールフロー２００が、以下のとおり生じる：
−  内部のホストＨｉとＲＳ２２が、ＤＨ交換を使用してセキュリティで保護されたシグナリング接続を確立する（２０２）。これにより、ＦＷ２０上に第１の５タプルエントリを作成し、このエントリは、内部のホストＨｉおよびＲＳ２２に対応する。
−  外部のホストＨｏが、ＤＨ交換を使用してＲＳ２２を相手にセキュリティで保護された接続を確立する（２０４）。
−  外部のホストＨｏが、ＫＯＰ  ＲＥＱメッセージをＲＳ２２に、このメッセージをまず完全性保護した後、送信する（２０６）。ＫＯＰ  ＲＥＱメッセージのペイロードは、事前定義されたパラメータタイプを使用して内部のホストのＨｉデータを含む。このデータは、提案される接続のために使用されるべき内部のホストＨｉのＩＰアドレス、プロトコルタイプ、およびポート番号を含む。
−  ＲＳ２２上に存在するＫＯＦが、ＫＯＰ  ＲＥＱメッセージを評価する。その目的で、ＫＯＦは、第１のネットワークアーキテクチャ１０ａ、および第２のネットワークアーキテクチャ１０ｂに関連して前述したのと同一の２タプル６２動作を使用する。
−  内部のホストＨｉのＩＰアドレス、および外部のホストＨｏのＩＰアドレスに対応する２タプルに関するＫＯＦ状態が、阻止状態７８にはない場合、ＲＳ２２は、ＫＯＰ  ＲＥＱメッセージを、シグナリングリンクを介して内部のホストＨｉにトンネリングする（２０８）。ＲＳ２２は、前述したとおり、ＫＯＰ  ＲＥＱメッセージに関する完全性保護を提供する。ＫＯＰ  ＲＥＱメッセージは、外部のホストＨｏのＩＰアドレスを含む。
−  ＦＷ２０上の第１の５タプルエントリの作成に関連して前述したとおり、メッセージが伝送されるシグナリングリンクが既に確立されているので、ＦＷ２０はＫＯＰ  ＲＥＱメッセージを通過させる（２１０）。
−  内部のホストＨｉが、ＫＯＰ  ＲＥＱメッセージの中の情報を使用して、外部のホストＨｏと直接に連絡をとる。この連絡は、内部のホスト、および外部のホストＨｏに対応する第２の５タプルエントリをＦＷ２０上に作成し、このエントリは、外部のホストＨｏが、内部のホストＨｉからの通信に直接に応答することを許す。
−  内部のホストＨｉが、外部のホストＨｏにＫＯＰ  ＮＡＫメッセージを送信すること（２１２）を所望する場合、内部のホストＨｏは、ＲＳ２２に対するシグナリング接続を使用し、外部のホストＨｏのＩＰアドレスを含め、さらにメッセージを完全性保護する。ＦＷ２０が、完全性保護されたＫＯＰ  ＮＡＫメッセージをＲＳ２２に転送する（２１４）。ＲＳ２２が、このメッセージを検証し、このメッセージの２タプル６２は阻止状態７８に遷移し、さらにＫＯＰ  ＮＡＫメッセージを外部のホストＨｏに転送する（２１６）。
−  内部のホストＨｉは、ＫＯＰ  ＲＥＱメッセージに応答して外部のホストＨｏにＫＯＰ  ＡＣＫメッセージを送信する（２１８）オプションも有する。ＦＷ２０が、ＫＯＰ  ＲＥＱメッセージをＲＳ２２に転送する（２２０）。ＲＳ２２上に組み込まれたＫＯＦが、内部のホストＨｉおよび外部のホストＨｏの５タプルに対応するＦＷ状態を保つ、前述したＦＷの５タプル６０と同一である５タプルに関するエントリを保持する。５タプルのＦＷ状態は、ＲＳ２２が、ＫＯＰ  ＡＣＫメッセージを外部のホストＨｏまで通過させる（２２２）と、通過状態６８に設定される。５タプルのＦＷ状態が通過状態６８にある間、ＲＳ２２は、外部のホストＨｏから内部のホストＨｉに、さらに内部のホストＨｉから外部のホストＨｏに任意の情報を中継する。
−  内部のホストＨｉは、ＫＯＰ  ＲＥＱメッセージに応答して外部のホストＨｏにＫＯＰ  ＲＳＰメッセージを送信するオプションも有する。このメッセージは、ＫＯＰ  ＡＣＫメッセージに関して説明したのと同一の仕方で外部のＨｏに通信される。外部のホストＨｏは、ＫＯＰ  ＲＳＰメッセージによって要求される情報を含む、別のＫＯＰ  ＲＥＱメッセージでＫＯＰ  ＲＳＰメッセージに応答する。第２のＫＯＰ  ＲＥＱメッセージは、第１のＫＯＰ  ＲＥＱメッセージに関して説明したのと同一の仕方で内部のホストＨｉに通信される。説明されるこれらの複数のＫＯＰ  ＲＳＰ／ＫＯＰ  ＲＥＱメッセージ交換２２４が、許される。
−  内部のホストＨｉが、外部のホストＨｏにＫＯＦ  ＦＩＮメッセージを送信して（２２６）、ＫＯＰ  ＡＣＫメッセージを介して開始された中継接続を終了させる。ＫＯＦ  ＦＩＮメッセージは、ＫＯＰ  ＡＣＫメッセージに関して説明したのと同一の仕方で外部のホストに中継される。ＫＯＦ  ＦＩＮメッセージおよびＫＯＦ  ＡＣＫメッセージは、ＲＳ２２がすべてのトラフィックデータを中継する事例において使用されることに留意されたい。
【００７９】
図８は、図３パートａに示される実施形態による組込み型ＫＯＦファイアウォール１２によって実行されるインバウンドパケットを扱う方法４００を示す流れ図である。これらの流れ図は、タイマ満了による図５に示される状態遷移を含まない。
【００８０】
図８を参照すると、方法４００が、インバウンドパケットが組込み型ＫＯＦファイアウォール１２に着信するのを待つ（４０２）。インバウンドパケットが着信すると、この方法は、そのパケットがＫＯＰ  ＲＥＱメッセージであるかどうかを判定する（４０４）。そのパケットがＫＯＰ  ＲＥＱメッセージではない場合、この方法は、そのパケットが、組込み型ＫＯＦファイアウォール１２上に既に格納されている５タプルエントリと合致するかどうかを判定する（４１０）。合致する５タプルエントリが存在する場合、この方法は、その５タプルエントリに対応するタイマをリフレッシュし（４０６）、そのパケットを内部のホストＨｉまで通過させる（４０８）。その後、この方法は、別のインバウンドパケットを待つことに戻る。そうではなく、この方法が、組込み型ＫＯＦファイアウォール１２上に合致する５タプルエントリが存在しないと判定した（４１０）場合、そのパケットは阻止され（４１２）、この方法は、インバウンドパケットを待つことに戻る。
【００８１】
方法４００が、そのパケットがＫＯＰ  ＲＥＱメッセージであると判定した場合（４０４）、次に、方法４００は、組込み型ＫＯＦファイアウォール１２上にそのパケットと合致する２タプルエントリが存在するかどうかを判定する（４１４）。そのような合致する２タプルエントリが存在しない場合、この方法は、そのパケットに関する２タプルエントリを作成し（４１６）、さらにそのエントリを通過状態にする。次に、この方法は、そのパケットを内部のホストＨｉまで通過させ（４１８）、別のインバウンドパケットを待つことに戻る。この方法が、合致する２タプルエントリが存在すると判定した（４１４）場合、この方法は、そのエントリが阻止状態にあるかどうかを判定する（４２０）。そのエントリが阻止状態にある場合、この方法は、そのパケットを阻止し（４２２）、別のインバウンドパケットを待つことに戻る。しかし、この方法が、その２タプルエントリが阻止状態にはないと判定した（４２０）場合、この方法は、そのエントリに対応する２タプルカウンタをインクリメントし、その後、カウンタがオーバーロードしたかどうかを判定する（４２８）。カウンタがオーバーロードした場合、この方法は、その２タプルエントリを阻止状態に設定し（４２６）、そのエントリに関するタイマをリセットする。次に、この方法は、そのパケットを阻止し（４２２）、別のインバウンドパケットを待つことに戻る。しかし、カウンタがオーバーロードしていない場合、この方法は、そのパケットを内部のホストＨｉまで通過させ（４３０）、その後、別のインバウンドパケットを待つことに戻る。
【００８２】
図９は、図３パートａに示される実施形態による組込み型ＫＯＦファイアウォール１２によって実行されるアウトバウンドパケットを扱う方法５００を示す流れ図である。これらの流れ図は、タイマ満了による図５に示される状態遷移を含まない。
【００８３】
図９を参照すると、方法５００が、アウトバウンドパケットが組込み型ＫＯＦファイアウォール１２に着信するのを待つ（５０２）。アウトバウンドパケットを受信すると、方法は、そのパケットがＫＯＰメッセージであるかどうかを判定する（５０４）。そのパケットがＫＯＰメッセージではない場合、次に、この方法は、組込み型ＫＯＦファイアウォール１２上にそのパケットと合致する５タプルエントリが存在するかどうかを判定する（５０６）。そのような合致する５タプルエントリが存在する場合、この方法は、そのエントリに対応するタイマをリセットし（５０８）、さらにそのパケットを外部のホストＨｏに向けて通過させる（５１０）。その後、この方法は、別のアウトバウンドパケットを待つことに戻る。そのような合致する５タプルエントリが存在しない場合、この方法は、そのパケットに対応する５タプルエントリを作成し（５１２）、さらにそのパケットを外部のホストＨｏに向けて通過させる（５１０）。その後、この方法は、別のアウトバウンドパケットを待つことに戻る。
【００８４】
この方法が、そのパケットがＫＯＰメッセージであると判定した（５０４）場合、次に、この方法は、そのパケットがＫＯＰ  ＡＣＫメッセージであるかどうかを判定する（５１４）。ＫＯＰ  ＡＣＫメッセージである場合、この方法は、組込み型ＫＯＦファイアウォール１２上に合致する５タプルエントリが存在するかどうかを判定する（５１６）。そのような合致する５タプルエントリが存在する場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（５２０）、別のアウトバウンドパケットを待つことに戻る。そうではなく、そのような合致する５タプルエントリが存在しない場合、方法は、そのパケットに対応する５タプルエントリを作成し（５１８）、その後、そのパケットを外部のホストＨｏに向けて通過させる。その後、この方法は、別のアウトバウンドパケットを待つことに戻る。
【００８５】
この方法が、そのパケットがＫＯＰ  ＡＣＫメッセージではないと判定した（５１４）場合、次に、この方法は、そのパケットがＫＯＰ  ＦＩＮメッセージであるかどうかを判定する（５２２）。ＫＯＰ  ＦＩＮメッセージである場合、この方法は、組込み型ＫＯＦファイアウォール１２上に合致する５タプルエントリが存在するかどうかを判定する（５２４）。そのような合致するエントリが存在しない場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（５２０）、別のアウトバウンドパケットを待つことに戻る。そうではなく、合致する５タプルエントリが存在する場合、この方法は、その５タプルエントリを削除し（５２６）、次に、そのパケットを外部のホストＨｏに向けて通過させる（５２０）。その後、この方法は、別のアウトバウンドパケットを待つことに戻る。
【００８６】
この方法が、そのパケットがＫＯＰ  ＦＩＮメッセージでないと判定した（５２２）場合、次に、この方法は、そのパケットがＫＯＰ  ＲＳＰメッセージであるかどうかを判定する（５２８）。ＫＯＰ  ＲＳＰメッセージである場合、この方法は、組込み型ＫＯＦファイアウォール１２上にそのパケットに合致する２タプルエントリが存在するかどうかを判定する（５３０）。そのような合致する２タプルエントリが存在しない場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（５２０）、別のアウトバウンドパケットを待つことに戻る。そうではなく、合致する２タプルエントリが存在する場合、この方法は、そのエントリが通過状態にあるかどうかを判定する（５３２）。通過状態にある場合、この方法は、その２タプルエントリに対応するタイマおよびカウンタをリセットし（５３４）、次に、そのパケットを外部のホストＨｏに向けて通過させる（５２０）。その後、この方法は、別のアウトバウンドパケットを待つことに戻る。そうではなく、この方法が、その２タプルエントリが通過状態にはないと判定した（５３２）場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（５２０）、その後、別のアウトバウンドパケットを待つことに戻る。
【００８７】
この方法が、そのパケットがＫＯＰ  ＲＳＰではないと判定した（５２８）場合、次に、この方法は、そのパケットがＫＯＰ  ＮＡＫメッセージであるかどうかを判定する（５３６）。ＫＯＰ  ＮＡＫメッセージである場合、この方法は、組込み型ＫＯＦファイアウォール１２上にそのパケットと合致する２タプルエントリが存在するかどうかを判定する（５３８）。そのような合致する２タプルエントリが存在しない場合、この方法は、組込み型ＫＯＦファイアウォール１２上で、そのパケットに対応する２タプルエントリを作成し（５４０）、さらにそのエントリを阻止状態に設定する。次に、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（５２０）、別のアウトバウンドパケットを待つことに戻る。そうではなく、合致する２タプルエントリが存在する場合、この方法は、そのエントリを阻止状態に設定し（５４２）、さらにそのエントリに対応するタイマをリセットする。次に、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（５２０）、別のアウトバウンドパケットを待つことに戻る。
【００８８】
この方法が、そのパケットがＫＯＰ  ＮＡＫメッセージではないと判定した（５３６）場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（５２０）、別のアウトバウンドパケットを待つことに戻る。
【００８９】
図１０は、図３パートｂに示される実施形態によるファイアウォール２０と直列のＫＯＦ１８によって実行されるインバウンドパケットを扱う方法６００を示す流れ図である。これらの流れ図は、タイマ満了による図６に示される状態遷移を含まない。
【００９０】
図１０を参照すると、方法６００が、インバウンドパケットがＫＯＦ１８に着信するのを待つ（６０２）。インバウンドパケットが着信すると、この方法は、そのパケットがＫＯＰ  ＲＥＱメッセージであるかどうかを判定する（６０４）。そのパケットがＫＯＰ  ＲＥＱメッセージではない場合、この方法は、そのパケットをＦＷ２０まで通過させ（６０６）、別のインバウンドパケットを待つことに戻る。そのパケットがＫＯＰ  ＲＥＱメッセージである場合、この方法は、そのパケットがＫＯＦ１８上に既に格納されている２タプルエントリと合致するかどうかを判定する（６０８）。そのような合致する２タプルエントリが存在しない場合、次に、この方法は、そのパケットに対応する２タプルエントリを作成し（６１０）、さらにそのエントリを通過状態に設定する。次に、この方法は、そのパケットをＦＷ２０まで通過させ（６１２）、別のインバウンドパケットを待つことに戻る。この方法が、合致する２タプルエントリが存在すると判定した（６０８）場合、次に、この方法は、そのエントリが阻止状態にあるかどうかを判定する（６１４）。阻止状態にある場合、この方法は、そのパケットを阻止し（６１６）、別のインバウンドパケットを待つことに戻る。
【００９１】
この方法が、２タプルエントリが阻止状態にはないと判定した（６１４）場合、この方法は、通過状態にある、そのエントリに対応する２タプルカウンタをインクリメントし、次に、そのカウンタがオーバーロードしたかどうかを判定する（６２２）。そのカウンタがオーバーロードしている場合、この方法は、２タプルエントリを阻止状態に設定し（６２０）、さらにそのエントリに関するタイマをリセットする。次に、この方法は、そのパケットを阻止し（６１６）、別のインバウンドパケットを待つことに戻る。しかし、そのカウンタがオーバーロードしていない場合、この方法は、そのパケットをＦＷ２０まで通過させ（６２４）、その後、別のインバウンドパケットを待つことに戻る。
【００９２】
図１１は、図３パートｂに示される実施形態によるファイアウォール２０と直列のＫＯＦ１８によって実行されるインバウンドパケットを扱う方法７００を示す流れ図である。これらの流れ図は、タイマ満了による図６に示される状態遷移を含まない。
【００９３】
図１１を参照すると、方法７００が、アウトバウンドパケットがＫＯＦ１８に着信するのを待つ（７０２）。アウトバウンドパケットを受信すると、この方法は、そのパケットがＫＯＰメッセージであるかどうかを判定する（７０４）。そのパケットがＫＯＰメッセージではない場合、次に、この方法は、ＫＯＦ１８上にそのパケットと合致する５タプルエントリが存在するかどうかを判定する（７０６）。そのような合致する５タプルエントリが存在しない場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させる（７０８）。その後、この方法は、別のアウトバウンドパケットを待つことに戻る。そのような合致する５タプルエントリが存在する場合、この方法は、阻止状態にある、その５タプルエントリを削除し（７１０）、さらにそのパケットを外部のホストＨｏに向けて通過させる（７０８）。その後、この方法は、別のアウトバウンドパケットを待つことに戻る。
【００９４】
この方法が、そのパケットがＫＯＰメッセージであることを判定した（７０４）場合、次に、この方法は、そのパケットがＫＯＰ  ＦＩＮメッセージであるかどうかを判定する（７１２）。ＫＯＰ  ＦＩＮメッセージである場合、この方法は、ＫＯＦ１８上に合致する５タプルエントリが存在するかどうかを判定する（７１４）。そのような合致する５タプルエントリが存在しない場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（７０８）、別のアウトバウンドパケットを待つことに戻る。そうではなく、合致する５タプルエントリが存在する場合、この方法は、そのパケットに対応する５タプルエントリを作成し（７１６）、さらにそのエントリを阻止状態に設定する。次に、この方法は、そのパケットを外部のホストＨｏに向けて通過させる（７０８）。その後、この方法は、別のアウトバウンドパケットを待つことに戻る。
【００９５】
この方法が、そのパケットがＫＯＰ  ＦＩＮメッセージではないと判定した（７１２）場合、次に、この方法は、そのパケットがＫＯＰ  ＲＳＰメッセージであるかどうか判定する（７１８）。ＫＯＰ  ＲＳＰメッセージである場合、この方法は、ＫＯＦ１８上に合致する２タプルエントリが存在するかどうかを判定する（７２０）。そのような合致する２タプルエントリが存在しない場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（７０８）、別のアウトバウンドパケットを待つことに戻る。そうではなく、合致する２タプルエントリが存在する場合、この方法は、そのエントリが通過状態にあるかどうかを判定する（７２２）。通過状態にある場合、この方法は、そのエントリに対応するタイマおよびカウンタをリセットし（７２４）、次に、そのパケットを外部のホストＨｏに向けて通過させる（７０８）。その後、この方法は、別のアウトバウンドパケットを待つことに戻る。そうではなく、合致する２タプルエントリが通過状態にはない場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（７０８）、別のアウトバウンドパケットを待つことに戻る。
【００９６】
この方法が、そのパケットがＫＯＰ  ＲＳＰメッセージではないと判定した（７１８）場合、次に、この方法は、そのパケットがＫＯＰ  ＮＡＫメッセージであるかどうかを判定する（７２６）。ＫＯＰ  ＮＡＫメッセージである場合、この方法は、ＫＯＦ１８上にそのパケットに合致する２タプルエントリが存在するかどうかを判定する（７２８）。そのような合致する２タプルエントリが存在しない場合、この方法は、そのパケットに対応する２タプルエントリをＫＯＦ１２上に作成し（７３０）、さらにそのエントリを阻止状態に設定する。次に、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（７０８）、別のアウトバウンドパケットを待つことに戻る。そうではなく、合致する２タプルエントリが存在する場合、この方法は、そのエントリを阻止状態に設定し（７３２）、さらにそのエントリに対応するタイマをリセットする。次に、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（７０８）、別のアウトバウンドパケットを待つことに戻る。
【００９７】
この方法が、そのパケットがＫＯＰ  ＮＡＫメッセージではないと判定した（７２６）場合、この方法は、そのパケットを外部のホストＨｏに向けて通過させ（７０８）、別のアウトバウンドパケットを待つことに戻る。
ネットワークアドレストランスレータへの適用
ほとんどのＮＡＴは、ネットワークアドレス変換またはネットワークアドレス／ポート変換をファイアウォール機能と組み合わせる。これらの場合、前述したのと同一のＫＯＦ方法が、適用され得る。しかし、ＮＡＴにより、内部のホストＨｉの内部アドレスおよび内部ポート番号は、ＮＡＴによって変換された内部のホストＨｉの公開のアドレス、および公開のポート番号とは異なる。したがって、外部のホストＨｏは、内部のホストＨｉとどのように連絡をとるべきかを知らない可能性がある。さらに、内部のホストＨｉは、内部のホストＨｉの公開のＩＰアドレスを知らない可能性がある。この状況は、ＫＯＰメッセージに影響するとともに、トランスポート接続の確立にも影響する。
【００９８】
ＫＯＰメッセージが、従来のトランスポートタイプ（ＵＤＰまたはＴＣＰ）によってサポートされる場合、ホストは、ＩＥＴＦ（ＲＦＣ  ５３８９）によって提案されるＮＡＴに関する接続通過ユーティリティ（ＳＴＵＮ）を使用して、ホストのＫＯＰ公開ＩＰアドレスおよびＫＯＰ公開ポート番号を見出すことが可能である。内部のホストＨｉは、これらのデータをＤＮＳにおいて公開して、これらのデータが公共で利用可能であるようにすることが可能である。
【００９９】
また、内部のホストＨｉは、ＳＴＵＮ法を使用して、内部のホストＨｉがセットアップすることを所望するトランスポート接続に関する公開のＩＰアドレス、および公開のポート番号を見出すことも可能である。次に、ＳＴＵＮ法の結果が、接続セットアップ時にＫＯＰ  ＲＥＱメッセージの中で遠隔のホストに転送されることが可能である。遠隔のホストもまた、ＮＡＴの背後に存在する場合、遠隔のホストは、同一のＳＴＵＮ法を使用し、遠隔のホスト自らの公開のＩＰアドレス、および公開のポート番号をＫＯＰ  ＡＣＫメッセージまたはＫＯＰ  ＲＳＰメッセージの中で戻す。次に、内部のホストと外部のホストの両方が、トランスポートパケットを互いに転送することができ、このアクションは、それぞれＮＡＴ上で５タプルエントリを作成する。「ホールパンチング」としばしば呼ばれるこの技術は、両方のホストの間でトランスポート接続が確立されることを可能にする。
【０１００】
同一の主要な方法が、ＫＯＰメッセージが、例えば、ＩＰ拡張ヘッダ（ＩＰｖ６）またはＩＰオプションヘッダ（ＩＰｖ４）を介して、トランスポート接続上に多重化される際に、またはＫＯＰメッセージがトランスポート層に埋め込まれる場合に、適用される。この方法は、ホストのＤＮＳサーバにおいて公開され得るＫＯＰアドレスおよびポート番号が唯一ではないという欠点を有する。この場合、ＲＳが使用され得る。ＲＳは、両方のホストに関してＳＴＵＮサービスを実行し（両方のホストがＮＡＴの背後にある場合）、さらにそれらをＫＯＰメッセージ交換に含める。
【０１０１】
最後に、一方または両方のＮＡＴが対称型ＮＡＴである場合、ＲＳの機能が、ＫＯＰメッセージ交換からトランスポートデータのトンネリングに拡張されることが可能である。
【０１０２】
特許請求の範囲で規定される、本発明の範囲を逸脱することなく、前述した本発明の実施形態に多数の変形、変更、および適合が行われることが可能である。
【図１】
0005524361.tif 000005
【図２】
0005524361.tif 000006
【図３】
0005524361.tif 000007
【図４】
0005524361.tif 000008
【図５】
0005524361.tif 000009
【図６】
0005524361.tif 000010
【図７】
0005524361.tif 000011
【図８】
0005524361.tif 000012
【図９】
0005524361.tif 000013
【図１０】
0005524361.tif 000014
【図１１】
0005524361.tif 000015