JP2004522335A - ルールにアクセスするためにインデックスを用いたファイアウォール - Google Patents
ルールにアクセスするためにインデックスを用いたファイアウォール Download PDFInfo
- Publication number
- JP2004522335A JP2004522335A JP2002557096A JP2002557096A JP2004522335A JP 2004522335 A JP2004522335 A JP 2004522335A JP 2002557096 A JP2002557096 A JP 2002557096A JP 2002557096 A JP2002557096 A JP 2002557096A JP 2004522335 A JP2004522335 A JP 2004522335A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- value
- control
- index
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0263—Rule management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
- H04M7/0078—Security; Fraud detection; Fraud prevention
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
パケットコントロール手段は、複数のルールに従うパケットであって、各々がコントロール値と協働するパケットをチェック手段であり、パケットと協働する前記コントロール値からインデックス値を発生させるインデックス手段と、前記インデックス値を用いて前記複数のルールから前記パケットをチェックするルールにアクセスする手段とを備えている。前記コントロール値は、前記パケットコントロール手段によって設定される。有効性としては、前記パケットのチェックは、常に、より高速の動作を許容し、前記複数のルールに対するアクセスを単一としていることである。
Description
【技術分野】
【０００１】
本発明は、一般的な通信分野、特にパケットコントロール手段に係る。
【背景技術】
【０００２】
通信ネットワークに基づいたパケットにおいては、セキュアネットワーク上のデータに対してアクセス権を与えないように、インセキュアなネットワーク間、すなわち、公開ネットワークと、商用組織における内部ネットワークのようなセキュアネットワークとの間で、パケットアクセスを制御する必要がある。アクセス制御は、いわゆるファイアウォールによって実施される。ファイアウォールはセキュアとインセキュアのネットワーク間のインターフェースを提供し、ファイアウォールコントローラーの制御下で、インターフェースを通過するパケットをチェックするためのパケットフィルタを含んでいる。チェックは、一連のルールに対して受信したパケット特性を対照することにより行われる。これは、保護されたネットワークへのIPの通過と保護されたネットワークからのIPの通過の制御を許可する。ルールがパケットと一致していると確認されれば、通過することを許可され、帯域幅が制限される。そうでなければ、そのパケットは拒否される。ファイアウォールのフィルタはハードウェアまたはソフトウェアにおいて必要な権限を与えることになる。実際上、両者の主な相違点は帯域幅にある。ソフトウェアフィルタは、処理能力が制限されるため、帯域幅は狭い。
【０００３】
前記フィルタは、保護されていない側であるインターネットと、保護されている側である仮想プライベートネットワークとの間のIPパケットのためのインターフェースを一任され提供する。前記フィルタは、保護されているネットワークと保護されていないネットワークとの間のIP境界線を横切って、どのパケットを伝送させるかを決定する責任を負っている。前記フィルタは、どのルールを設定するかという決定は行わない。これは、ファイアウォールを通る経路を要求するシステム内の要素の責任である。前記フィルタは、ルールを備えたパケットヘッダのデータを対照することにより、各パケットに対する決定を下す。パケットがフィルタに到達する時、宛先IPアドレス、宛先ポート番号、プロトコルかまたは他の要素により、パケットが拒否される場合には、パケットが廃棄され、有効なパケットとして受け付けられる場合には、伝送される。
【０００４】
【特許文献１】US5,951,651(Lakshman et al)は、各入力パケットに対するパケットフィルタで前記の適切なルールを発見することに関係している。WO 00/02114(Effnet)は、ルールのサブセットを識別するために２つのアドレス値（すなわち、前記パケットの送信元アドレスと宛先アドレス）に基づいてルックアップ動作を実行しているファイアウォールについて述べている。
【非特許文献１】Y-D Lin, et al "Orderd Lookup with Bypass Matching for Scalable pre-flows Classification", Networld+Interop 2000, 2000/5/11は、簡潔に、連続したルックアップ動作が実行されるプロトコルとポートに関して、複数のデータベースを用いているパケットとサービスとの間で調整してマッピングすることを述べている。
【０００５】
IP電話で用いられるパケットフィルタは、コールコントロールファンクション（CCF）かまたは"gatekeeper"（定義のリストは、記述の最後に提供されている）によって決定されており、迅速に多くのルール変更の設定を行う必要がある。これは、一般のデータファイアウォールと対比すると、一般のデータファイアウォールは、ルールがほとんど変化がなく、ネットワーク管理部によって制御され、利用は比較的少ない。この故に、IP電話呼び出し（IP telephony calls）は、遅延及び遅延の変量がサービスの質に対して重大であり、“リアルタイム”でIP電話パケットをチェックする必要があるため、従来のデータトラフィックとは違った扱いが必要となる。
【０００６】
今、我々は、二つの間のエンドポイント、つまりセキュアでないネットワークに位置するオリジナルエンドポイントと、セキュアネットワーク上に位置する宛先エンドポイントとの間のIP電話の場合を考慮している。ファイアウォールを経由するIP電話において、パケットは、ファイアウォール上にアドレス/ポート番号を割り当てられている。そのパケットとは、セキュアでないエンドポイントからセキュアでない側のファイアウォールまでのパケットと、セキュアなエンドポイントからセキュアな側までのパケットのことである。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来技術において、ファイアウォール上における、これらのIPアドレスの値とポート番号は、呼び出しのエンドポイントによって決定される。前記フィルタにより受け取ったそれぞれのパケットは、パケットを通過するルールが見つけ出されるか、または、パケットが廃棄されるまで、次に存在しているルールに対してチェックされる。ハッシングは、そのパケットに対して関連したルールの内、可能性の高いものを指示するのに使用され得る。ハッシングが存在すれば、そのインデックス値は、ある位置を指す。つまり、仮にその位置がルールを包含して無いならば、その時、パケットは廃棄される。もし、その位置がルールを包含するならば、パケットはそれに対してチェックする。一度、ルールとして評価されると、異なる位置にある２番目のルールに対する指標を含む場合にチェックは行われ、その２番目のルールに対しても、またパケットがチェックされる。この２番目の位置はまた、３番目のルールに対するもう一つの指標を包んでいることもあり、これに対してもチェックが行われる。このように、ルールチェック行為には決定性がない。個々のアクセスは、時には従来技術の組合せで十分であることが判明するかも知れないが、これは、特殊なパケットがルールテーブルに対して複数アクセスする処理を許可しており、このために従来技術でのファイアウォールの帯域幅が、制限されるので、その場合に対しては保証されない。
【０００８】
パケットチェックは、典型的には、利用されるプロトコルと送信元と宛先のIPアドレス及びポート番号をチェックすることを伴う。これは、本質的に、普通のデータファイアウォールによって利用されているのと同様な処理であり、ここでルールは、ネットワーク管理部により維持されている。類似した処理が、パケットルーターで起こるが、パケットルーターにおいては、どのインターフェースの出口をパケットの経路に定めるかをルールは最初に決定する。しかしながら、全てのこれらの従来技術における処理は、多くの処理能力/時間を必要とするか、または、並列に全ての位置に対してのアクセスを実行する連想記憶装置ような高価なハードウェアを必要とする。この時、フィルタ内でパケット通過するための最大帯域幅は効果的に制限される。
【課題を解決するための手段】
【０００９】
本発明は、複数のルールに従うパケットであって、各々がコントロール値と協働するパケットをチェックするパケットコントロール手段を備え、前記パケットコントロール手段が、パケットと協働する前記コントロール値からインデックス値を発生させるインデックス手段と、前記インデックス値を用いて前記複数のルールから前記パケットをチェックするルールにアクセスする手段とを含み、前記パケットが、常に、前記複数のルールに対して単一のアクセスを必要とすることを特徴とする通信システムを提供する。
さらに具体的な表現をすると、前記コントロール値は、前記パケットコントロール手段によって設定される。
【００１０】
さらに、具体的な表現をすると、前記通信システムは、前記パケットコントロール手段の外部にあるパケット値手段を含んでおり、前記コントロール値は、前記パケットコントロール手段と共同して、前記パケット値手段によって設定される。
【００１１】
本発明は、具体的な表現をすると、パケットコントロール手段がパケットを通過すべきか拒否すべきかを決定するのための手段を備えている通信システムを提供する。
【００１２】
本発明は、さらに、パケットコントロール手段を備えているパケットに基づく通信システムにおいて、前記コントロール手段でコントロール値を含んでいるパケットを受信するステップと、前記コントロール値を利用して、前記パケットのチェック機能の使用時に、複数のルールから一つのルールにアクセスするステップとを備え、前記パケットのチェックが、常に、前記複数のルールに対して単一のアクセスを必要とするパケットをフィルタ処理する方法を提供する。
【００１３】
さらに具体的な表現をすると、前記パケットコントロール手段は前記パケットに対して前記コントロール値を割り当てる。
【００１４】
本発明は、以下の図に従い、さらに具体的な表現をすると、パケット値手段を備えている、パケットに基づく通信システムにおけるパケットをフィルタ処理する方法を提供し、前記方法は、前記コントロール手段でコントロール値を含んでいるパケットを受信するステップと、チェック機能の使用時にルールを識別するために前記コントロール値を利用するステップとを有している。
【発明を実施するための最良の形態】
【００１５】
図１に、従来のファイアウォールフィルタの主な構成要素のブロック図を示す。
【００１６】
図２から図４に、本発明によるルールインデックスのさまざまな計算方法を示す。
【００１７】
次の具体的な説明では、IPバージョン4との関係について述べるが、本発明は、IPバージョン6を用いるシステムにも適用される。
【００１８】
図１より、IP電話をセットアップするために、オリジナルエンドポイントは、ファイアウォールのIPアドレスとポート番号に関係を持つ登録パケットを送信する。フィルタは、チェックのために適切な呼び出し制御ファンクション（H.323におけるgatekeeperで知られている）へ登録パケットを転送するファイアウォールコントローラーに対して登録パケットを振り向ける。登録パケットは、オリジナルエンドポイントのIPアドレスとポート番号を含んでいる。仮に、登録パケットがCCFにより実行されたチェックを通過するならば、CCFは、フィルタを経由してオリジナルエンドポイントへ応答パケットを送信する。その時、ファイアウォールコントローラーは、一般的には、前記呼び出しのためにフィルタにおいて２つのルールを設定する（各方向に対して一つのルール）。これらのルールは、通常、多くの同時読み出しを扱うために他のルールを含んでいる前記ファイアウォールで保持されている大きなテーブルの内の一部を作り上げる。フィルタのインセキュア側（すなわちオリジナル側）のIPアドレスとポート番号は、オリジナルエンドポイントに対して伝達される。この時、このIPアドレスとポート番号は、前記呼び出しの一部のように次のパケットの宛先アドレスとしてオリジナルエンドポイントによって利用される。同様に、フィルタの保護された側（すなわち、CCF側）におけるIPアドレスとポート番号は、CCFに対して伝達される。その時、CCFは、その呼び出しの一部と同じオリジナルエンドポイントに対するパケット送信のための宛先アドレスとして、このIPアドレスとポート番号を利用する。この処理は、H.323、MGCP、SIP、及びH.248を含む電話法プロトコルの範囲に対して適用できる。これらのファイアウォールアドレスとポート番号は、従来通りエンドポイントによって割り当てられる。
【００１９】
ファイアウォールは、セキュア（30）及びインセキュア（20）のネットワークとのインターフェースから来るIPパケットを処理するフィルタを含む。この処理を実行するために、フィルタは、フィルタに接続されているコントロールインターフェース（10）の反対側の接続先となるファイアウォールコントローラーにより設定されたデータを用いる。特に、送信元のIPアドレスとポート番号、宛先のアドレスとポート番号、及びIPプロトコルは、ファイアウォールコントローラーにより設定される。
【００２０】
64000のポート番号は、IANA（一般的なポートとして以下を参照）によって割り当てられた16384のユーザー定義ポート及び49152ポートを含んで利用できる。
【００２１】
パケットが入ってきた時の最初のチェックは、ARPプロトコルを用いたパケットに対してのものであり、残りのパケットに対しては異なった処理が行われる。ARP（Address Resolution Protocol）パケットは、ネットワークインターフェース上でローカルに処理される。仮に、入ってきたパケットがARPでないならば、その時、次のテストが実行される。
【００２２】
チェックにより、パケットのIPバージョンがフィルタで動作中のものと同様であることが保証される。各フィルタは、一つのIPバージョンしか動作せず、かつ、両方のフィルタ方向に対して同様でなければならない。チェックは、IPヘッダの長さとプロトコルに関して実行される。チェックは、パケットヘッダ長が事前定義した最小値、すなわち20オクテット以上であることを保証するために、IPヘッダのフィールド長に関してフィルタによって実行される。そのフィルタはまた、IPプロトコルのパケットヘッダフィールドが、受信可能なプロトコルテーブルにおいて有効な入力に相当するかを確立するためにチェックを行う。
【００２３】
これらのチェックがルールテーブルに対してインデックスを通過するかどうかは、その位置でルールが存在するかを確立するのに用いられる。上記の全てのチェックを失敗するか、または、その位置がルールを含んでいない場合には、パケットについての統計表が記され、パケットが廃棄される。
【００２４】
チェックは、パケットがマルチキャストIPアドレスを持つかどうかを確立するために実行される。マルチキャストアドレスを持つならば、ルールインデックスが、マルチキャストIPアドレステーブルから引き抜かれる。マルチキャストIPアドレステーブルは、図２及び図３に示される（下記参照のこと）配置のように、フィルタを通じて、マルチキャストパケットの経路を定めるために用いられる２０ビットのインデックスを与える。マルチキャストパケットは通常、ファイアウォールコントローラーへ経路が定められる。パケットについての統計表が記され、その宛先への転送のために通過される。
【００２５】
ルール内のフラグは、パケットヘッダ内でどのデータ項目が変化するか、また、フィルタによってどの統計的情報の項目が更新されたかを決定する。パケットヘッダ内の宛先IPアドレスは、ルール上で蓄積されている変更後の宛先アドレスへ変化する。パケットヘッダ内の宛先ポート番号は、ルール上で蓄積されている変更後の宛先ポート番号へ変化する。送信元アドレスは、ルール上で蓄積されている変更後の送信元アドレスへ変化する。プロトコルヘッダ内の送信元ポート番号は、ルール上で蓄積されている変更後の送信元ポート番号へ変化する。
【００２６】
上記ヘッダの変化は、パケットがファーストエンドポイントからフィルタへ、かつ、フィルタからセカンドエンドポイントへ、かつ、逆の戻る道程が、正確に割り当てられていることを保証することが必要となる。ルールから区別されたサービス（diffserv）ビット、すなわち、パケットヘッダにおけるビットは、その設定により、ルーターが異なる優先事項等のパケットのクラス間を区別するのを許可し、適切な位置においてパケットヘッダに加えられることになる。パケットヘッダのチェックサムは、データ変換が行われた後、計算し直される。
【００２７】
図２から図４は、ルールインデックスが入力パケットの異なる型をどのように計算しているかを示す。図において、最下位ビット（ビット0）は、各フィールドの右手側である。
【００２８】
本発明の好ましい実施例では、ファイアウォールに対するIPアドレスとポート番号の割り当ては、特定の位置を発生させるように調整されたファイアウォールコントロールファンクションにより、次のパケットのために適切なルールを迅速に識別できるように同じ呼び出しの部分を作り上げる方法で実行される。本発明のさらに好ましい実施例としては、ファイアウォールフィルタに対するIPアドレスとポート番号の割り当ては、ファイアウォールに対する外部プラットフォームにより行われる。ファイアウォールは、同じ呼び出しの部分を作る次のパケットのために適切なルールの迅速な識別ができるように、ファイアウォールコントロールファンクションと協同で特定の位置を発生するように調整されている。優位性としては、本発明は、順番に各ルールをチェックする処理を用いていることよりもむしろ、ローカルに内容が設定されている受信パケットから、ファイアウォール（上述参照）までのフィールドの利用を提供しているところにある。これは、関連したルールに対して（すなわち、ルールテーブルにおいて関連する位置に対して）、直接的にインデックスを提供しており、エンドポイントが設定を行うこととは対照的である。この故に、適切なルールがインデックス値に設定されているかどうかが、直接のポイントとなる。インデックス値が有効なルールを指示していないならば、その時、関連パケットは拒否される。パケットを拒否する際にも、本発明は、更なる効果を提供する。この故に、本発明にでは、パケットの通過か拒否の決定は、常に、ルールテーブルへの単一のアクセスで達成される。
【００２９】
図２は、TCP/UDPでないプロトコルのためのルールの計算を示している。TCPまたはUDP以外のプロトコルのために、ルールインデックスは、IPアドレスと一緒に8ビットプロトコルID値によって指示されるIPプロトコルインデックステーブルにおける値に基づいて計算される。IPプロトコルインデックステーブルは、ファイアウォール上に与えられている。プロトコルフィールドにおいて指定された値は、プロトコルテーブルにインデックスとして用いられる。指示された入力は、プロトコルが有効かどうかを指示しているテーブルである。プロトコルが有効ならば、その時、ルールインデックスは、そのプロトコルに関してIPプロトコルインデックステーブルで指示された入力から下位14ビットを取り、これと一緒にIPアドレスから下位6ビットを取って作られる。
【００３０】
図３は、“よく知られたポート”のルールインデックスの計算を示している。プロトコルが、TCPまたはUDPであり、ポート番号が、16進表記で0000からBFFFの範囲にあるならば、ポート番号は、“よく知られたポート”テーブルに対するインデックスとして用いられる。“よく知られたポート”テーブルは、IANAによって定義（79＝finger等）されているような特定の一致のあるポート番号を含む。このテーブルは、ポートがこのフィルタに関してサポートされているかどうかを確立するために用いられる。ポートがサポートされているならば、ルールデータに対するインデックスは、IPアドレスと一緒に宛先ポート番号よって指示されたテーブルからの値に基づいている。ルールインデックスは、ポート番号により指示されたよく知られたポート番号テーブルにおける入力から下位14ビットを取り、これと一緒にIPアドレスから下位6ビットを取ることにより作られる。ポートがサポートされていないならば、その時、送信されたパケットは廃棄される。
【００３１】
図４は、ユーザポートのルールインデックスの計算を示している。TCP及びUDPプロトコルが、よく知られているポート（例えば、ポート番号が16進表記でC000からFFFFまでの範囲に存在する）でない場合、ルールインデックスは、ポート番号及びIPアドレスの一部から作られる。ルールインデックスは、ポート番号の下位14ビットと一緒にIPアドレスから最下位6ビットを取ることによって作られる。
【００３２】
上記の例外は、任意のIPSECに対して存在する。IPSECプロトコルタイプには二つバージョン、IPプロトコル50ESP（Encapsulating Security Payload）及びIPプロトコル51AH（Authentication Header）がある。これらのバージョンは、共に、Security Parameters Index(SPI)を含んでいる。セキュリティヘッダにおいて、ESPに対してのフィールドは、最初の32ビットにおいて存在し、AHに対してのフィールドは、二番目の32ビットに存在する。SPIは、宛先IPアドレス及びプロトコルと共にパケットを識別し特定する。これらのパケットルールインデックスの初期化は、SPIの下位14ビットとIPアドレスの下位6ビットを使用せずに、上述されたものに類似した処理をユーザポートに施すことによって達成される。ルールインデックスが公式化された後、ルールデータのコントロールフィールドにおける値に従い、フィルタはチェックを実行し、ファンクションを置き換えることに注意しなければならない。IPSECパケットにおいて、原理の違いは、送信元及び宛先のポート番号が、同じ位置に蓄積されていることもあるが、このことよりもむしろ、ただ単に一つの値であるSPIが存在することである。この値は、ルールによって割り当てられ、更に必要があれば、チェックされ置き換えられる。
【００３３】
ルールインデックスは、ルールコントロールによって定められるルール及びチェックにアクセスするのに用いられ、有効ワード（パケットをチェックするのに用いられる基準を決定するルールのある一部）が実行される。これらのチェックが通過するならば、パケットヘッダドレス及びポート等は、必要に応じて翻訳される。
【００３４】
必要があれば、変化したIPヘッダからIPアドレスに対して等、IPヘッダチェックサムは計算し直され、UDP/TCPヘッダチェックサムは調整される。その有効なパケットの統計的情報は、現在のパケットを取り込むために更新される。全チェックが失敗するならば、その時、そのパケットについての統計表が記され、パケットが廃棄される。
【００３５】
パケットは次の理由が、一つでも当てはまる時、廃棄される。
・IPv6動作時のIPv4等、パケット内のIPバージョンが、フィルタのバージョンと一致していない。
・不正確な宛先IPアドレス：各フィルタが、マルチキャストアドレス及び個々のIPアドレスを含んで動作するIPアドレスの範囲を持っている。フィルタの範囲において存在しないIPアドレスを持った全パケットは拒否される。
・パケットのヘッダの長さが、パケットが正当であることを照合するのに必要な最小サイズよりも短い。
・プロトコルがフィルタに受け付けられないものである場合。フィルタは受け入れるべきプロトコルを数多くサポートしており、パケットヘッダのプロトコルフィールドがこのリストに存在しないならば、パケットは拒否される。
・IPアドレスとポート番号（あるいは、IPSECのSPI）から計算されたルールインデックスは、パケットの転送を許可する開放状態でないルールを参照する。
・パケットヘッダにおける送信側のIPアドレスが、ルールデータにおいて、最初の送信元IPアドレスフィールドに一致していない。
・パケットヘッダからのプロトコルフィールドが、ルールデータにおいて、最初のプロトコルIDフィールドに一致していない。
・パケットヘッダからの送信元ポート番号が、ルールデータにおいて、最初の送信元ポート番号に一致していない。
・パケットヘッダにおいて、宛先ポート番号が、ルールデータ（IPSECパケットでない）からの最初の宛先ポート番号に一致していない。
・パケットヘッダにおいて、宛先SPIが、ルールデータ（IPSECパケット―以下参照）からの最初の宛先SPIに一致していない。
・宛先ポート番号が、入力の“よく知られたポート”テーブルが存在しない時を除いて、16進表記で'C000'より小さい（結果として“よく知られたポート”である）。
・パケットの宛先IPアドレスフィールドが、ルールデータの最初の宛先IPアドレスフィールドに一致していない。
・IPアドレス及びポート番号（あるいはSPSECのSPI）から計算されたルールインデックスが、設定されていないルールを参照している。
【００３６】
本発明は、ハードウェアまたはソフトウェアにおいて実行されるパケットフィルタに適用される。本発明は、イーサネット（登録商標）上のIPに対してのみに限定されることなく、SONET/SDH、及びATM AAL5上のパケットのような他のネットワークの型にも適用される。本発明は、安価なランダムアクセスメモリを用いるならば、最適なパフォーマンスに達する。
【００３７】
定義
Address Resolution Protocol (ARP)
ローカルネットワークで認識される物理アドレスに対してIPアドレスをマッピングするためのプロトコル
Gatekeeper
IP電話ネットワークにおける構成要素。a) ネットワークにおける他の構成要素のRAS、b) 個別呼び出しのためのアドレス翻訳、c) ゲートウェイのコントロール
H.225
パケットに基づくマルチメディア通信システムのためのプロトコル呼び出し信号とメディアストリームパケットを定義しているITU-T規格
H.323
パケットに基づくマルチメディア通信システムのためのITU-T規格
IANA
IANA
ITU-T
国際電気通信連合電気通信標準化部門
IETF
Internet Engineering Task Force
（インターネット関連技術の標準化のためのボランティアグループ）
Internet Protocol (IP)
IPネットワークためのネットワークレイヤープロトコルであり、データパケットの不信頼な二地点間転送を提供する。現在使用されている標準は、IETF RFC791で定義されているバージョン4（IPv4）である。これは、将来的には、IETF RFC2460で定義されているバージョン6（IPv6）に取って代わられる予定となっている。
IP Telephony, Voice over Internet, Multimedia over IP
IPプロトコルに基づくネットワークに関する電話学の技術
Media Gateway Control Protocol (MGCP)
ITU-T MEGACOワーキンググループで提案されているプロトコルであり、ゲートキーパーによるメディアゲートウェイのコントロールのためのものである。インターネットドラフトドキュメントdraft-huitemamegaco-mgcp-v0r1-05で定義されている。
MEGACO
MEGACOは、物理的に分離されているマルチメディアゲートウェイの要素間で利用されるプロトコルを定義している。MEGACOの構成は、IETFインターネットドラフトドキュメントdraft-ietf-megaco-protocol-04に記述されている。
Registration, Admission and Status (RAS)
ネットワーク上で、レジスタに実体を与えているH.323プロトコル内での信号ファンクションであり、IP電話呼び出しを作成しているユーザの認証を行い、また、レジスタ上でのステータス情報を持つ。RASはH.225通信を用いている。RASの信号路は、H.323エンドポイント間の他の全経路を確定に向けて事前に開放されている。
Transmission Control Protocol (TCP)
コネクション型の高信頼のトランスポート層プロトコルであり、IPプロトコル上で動作するように設計されている。IETF RFC 7932で定義されている。
User Datagram Protocol (DDP)
コネクションレス型の低信頼のトランスポート層プロトコルであり、IPプロトコル上で動作するように設計されている。IETF RFC 768で定義されている。
【図面の簡単な説明】
【００３８】
【図１】従来のファイアウォールフィルタの主な構成要素のブロック図を示す。
【図２】TCP/UDPでないプロトコルのためのルールの計算を示す。
【図３】“よく知られたポート”のルールインデックスの計算を示す。
【図４】ユーザポートのルールインデックスの計算を示す。
【０００１】
本発明は、一般的な通信分野、特にパケットコントロール手段に係る。
【背景技術】
【０００２】
通信ネットワークに基づいたパケットにおいては、セキュアネットワーク上のデータに対してアクセス権を与えないように、インセキュアなネットワーク間、すなわち、公開ネットワークと、商用組織における内部ネットワークのようなセキュアネットワークとの間で、パケットアクセスを制御する必要がある。アクセス制御は、いわゆるファイアウォールによって実施される。ファイアウォールはセキュアとインセキュアのネットワーク間のインターフェースを提供し、ファイアウォールコントローラーの制御下で、インターフェースを通過するパケットをチェックするためのパケットフィルタを含んでいる。チェックは、一連のルールに対して受信したパケット特性を対照することにより行われる。これは、保護されたネットワークへのIPの通過と保護されたネットワークからのIPの通過の制御を許可する。ルールがパケットと一致していると確認されれば、通過することを許可され、帯域幅が制限される。そうでなければ、そのパケットは拒否される。ファイアウォールのフィルタはハードウェアまたはソフトウェアにおいて必要な権限を与えることになる。実際上、両者の主な相違点は帯域幅にある。ソフトウェアフィルタは、処理能力が制限されるため、帯域幅は狭い。
【０００３】
前記フィルタは、保護されていない側であるインターネットと、保護されている側である仮想プライベートネットワークとの間のIPパケットのためのインターフェースを一任され提供する。前記フィルタは、保護されているネットワークと保護されていないネットワークとの間のIP境界線を横切って、どのパケットを伝送させるかを決定する責任を負っている。前記フィルタは、どのルールを設定するかという決定は行わない。これは、ファイアウォールを通る経路を要求するシステム内の要素の責任である。前記フィルタは、ルールを備えたパケットヘッダのデータを対照することにより、各パケットに対する決定を下す。パケットがフィルタに到達する時、宛先IPアドレス、宛先ポート番号、プロトコルかまたは他の要素により、パケットが拒否される場合には、パケットが廃棄され、有効なパケットとして受け付けられる場合には、伝送される。
【０００４】
【特許文献１】US5,951,651(Lakshman et al)は、各入力パケットに対するパケットフィルタで前記の適切なルールを発見することに関係している。WO 00/02114(Effnet)は、ルールのサブセットを識別するために２つのアドレス値（すなわち、前記パケットの送信元アドレスと宛先アドレス）に基づいてルックアップ動作を実行しているファイアウォールについて述べている。
【非特許文献１】Y-D Lin, et al "Orderd Lookup with Bypass Matching for Scalable pre-flows Classification", Networld+Interop 2000, 2000/5/11は、簡潔に、連続したルックアップ動作が実行されるプロトコルとポートに関して、複数のデータベースを用いているパケットとサービスとの間で調整してマッピングすることを述べている。
【０００５】
IP電話で用いられるパケットフィルタは、コールコントロールファンクション（CCF）かまたは"gatekeeper"（定義のリストは、記述の最後に提供されている）によって決定されており、迅速に多くのルール変更の設定を行う必要がある。これは、一般のデータファイアウォールと対比すると、一般のデータファイアウォールは、ルールがほとんど変化がなく、ネットワーク管理部によって制御され、利用は比較的少ない。この故に、IP電話呼び出し（IP telephony calls）は、遅延及び遅延の変量がサービスの質に対して重大であり、“リアルタイム”でIP電話パケットをチェックする必要があるため、従来のデータトラフィックとは違った扱いが必要となる。
【０００６】
今、我々は、二つの間のエンドポイント、つまりセキュアでないネットワークに位置するオリジナルエンドポイントと、セキュアネットワーク上に位置する宛先エンドポイントとの間のIP電話の場合を考慮している。ファイアウォールを経由するIP電話において、パケットは、ファイアウォール上にアドレス/ポート番号を割り当てられている。そのパケットとは、セキュアでないエンドポイントからセキュアでない側のファイアウォールまでのパケットと、セキュアなエンドポイントからセキュアな側までのパケットのことである。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来技術において、ファイアウォール上における、これらのIPアドレスの値とポート番号は、呼び出しのエンドポイントによって決定される。前記フィルタにより受け取ったそれぞれのパケットは、パケットを通過するルールが見つけ出されるか、または、パケットが廃棄されるまで、次に存在しているルールに対してチェックされる。ハッシングは、そのパケットに対して関連したルールの内、可能性の高いものを指示するのに使用され得る。ハッシングが存在すれば、そのインデックス値は、ある位置を指す。つまり、仮にその位置がルールを包含して無いならば、その時、パケットは廃棄される。もし、その位置がルールを包含するならば、パケットはそれに対してチェックする。一度、ルールとして評価されると、異なる位置にある２番目のルールに対する指標を含む場合にチェックは行われ、その２番目のルールに対しても、またパケットがチェックされる。この２番目の位置はまた、３番目のルールに対するもう一つの指標を包んでいることもあり、これに対してもチェックが行われる。このように、ルールチェック行為には決定性がない。個々のアクセスは、時には従来技術の組合せで十分であることが判明するかも知れないが、これは、特殊なパケットがルールテーブルに対して複数アクセスする処理を許可しており、このために従来技術でのファイアウォールの帯域幅が、制限されるので、その場合に対しては保証されない。
【０００８】
パケットチェックは、典型的には、利用されるプロトコルと送信元と宛先のIPアドレス及びポート番号をチェックすることを伴う。これは、本質的に、普通のデータファイアウォールによって利用されているのと同様な処理であり、ここでルールは、ネットワーク管理部により維持されている。類似した処理が、パケットルーターで起こるが、パケットルーターにおいては、どのインターフェースの出口をパケットの経路に定めるかをルールは最初に決定する。しかしながら、全てのこれらの従来技術における処理は、多くの処理能力/時間を必要とするか、または、並列に全ての位置に対してのアクセスを実行する連想記憶装置ような高価なハードウェアを必要とする。この時、フィルタ内でパケット通過するための最大帯域幅は効果的に制限される。
【課題を解決するための手段】
【０００９】
本発明は、複数のルールに従うパケットであって、各々がコントロール値と協働するパケットをチェックするパケットコントロール手段を備え、前記パケットコントロール手段が、パケットと協働する前記コントロール値からインデックス値を発生させるインデックス手段と、前記インデックス値を用いて前記複数のルールから前記パケットをチェックするルールにアクセスする手段とを含み、前記パケットが、常に、前記複数のルールに対して単一のアクセスを必要とすることを特徴とする通信システムを提供する。
さらに具体的な表現をすると、前記コントロール値は、前記パケットコントロール手段によって設定される。
【００１０】
さらに、具体的な表現をすると、前記通信システムは、前記パケットコントロール手段の外部にあるパケット値手段を含んでおり、前記コントロール値は、前記パケットコントロール手段と共同して、前記パケット値手段によって設定される。
【００１１】
本発明は、具体的な表現をすると、パケットコントロール手段がパケットを通過すべきか拒否すべきかを決定するのための手段を備えている通信システムを提供する。
【００１２】
本発明は、さらに、パケットコントロール手段を備えているパケットに基づく通信システムにおいて、前記コントロール手段でコントロール値を含んでいるパケットを受信するステップと、前記コントロール値を利用して、前記パケットのチェック機能の使用時に、複数のルールから一つのルールにアクセスするステップとを備え、前記パケットのチェックが、常に、前記複数のルールに対して単一のアクセスを必要とするパケットをフィルタ処理する方法を提供する。
【００１３】
さらに具体的な表現をすると、前記パケットコントロール手段は前記パケットに対して前記コントロール値を割り当てる。
【００１４】
本発明は、以下の図に従い、さらに具体的な表現をすると、パケット値手段を備えている、パケットに基づく通信システムにおけるパケットをフィルタ処理する方法を提供し、前記方法は、前記コントロール手段でコントロール値を含んでいるパケットを受信するステップと、チェック機能の使用時にルールを識別するために前記コントロール値を利用するステップとを有している。
【発明を実施するための最良の形態】
【００１５】
図１に、従来のファイアウォールフィルタの主な構成要素のブロック図を示す。
【００１６】
図２から図４に、本発明によるルールインデックスのさまざまな計算方法を示す。
【００１７】
次の具体的な説明では、IPバージョン4との関係について述べるが、本発明は、IPバージョン6を用いるシステムにも適用される。
【００１８】
図１より、IP電話をセットアップするために、オリジナルエンドポイントは、ファイアウォールのIPアドレスとポート番号に関係を持つ登録パケットを送信する。フィルタは、チェックのために適切な呼び出し制御ファンクション（H.323におけるgatekeeperで知られている）へ登録パケットを転送するファイアウォールコントローラーに対して登録パケットを振り向ける。登録パケットは、オリジナルエンドポイントのIPアドレスとポート番号を含んでいる。仮に、登録パケットがCCFにより実行されたチェックを通過するならば、CCFは、フィルタを経由してオリジナルエンドポイントへ応答パケットを送信する。その時、ファイアウォールコントローラーは、一般的には、前記呼び出しのためにフィルタにおいて２つのルールを設定する（各方向に対して一つのルール）。これらのルールは、通常、多くの同時読み出しを扱うために他のルールを含んでいる前記ファイアウォールで保持されている大きなテーブルの内の一部を作り上げる。フィルタのインセキュア側（すなわちオリジナル側）のIPアドレスとポート番号は、オリジナルエンドポイントに対して伝達される。この時、このIPアドレスとポート番号は、前記呼び出しの一部のように次のパケットの宛先アドレスとしてオリジナルエンドポイントによって利用される。同様に、フィルタの保護された側（すなわち、CCF側）におけるIPアドレスとポート番号は、CCFに対して伝達される。その時、CCFは、その呼び出しの一部と同じオリジナルエンドポイントに対するパケット送信のための宛先アドレスとして、このIPアドレスとポート番号を利用する。この処理は、H.323、MGCP、SIP、及びH.248を含む電話法プロトコルの範囲に対して適用できる。これらのファイアウォールアドレスとポート番号は、従来通りエンドポイントによって割り当てられる。
【００１９】
ファイアウォールは、セキュア（30）及びインセキュア（20）のネットワークとのインターフェースから来るIPパケットを処理するフィルタを含む。この処理を実行するために、フィルタは、フィルタに接続されているコントロールインターフェース（10）の反対側の接続先となるファイアウォールコントローラーにより設定されたデータを用いる。特に、送信元のIPアドレスとポート番号、宛先のアドレスとポート番号、及びIPプロトコルは、ファイアウォールコントローラーにより設定される。
【００２０】
64000のポート番号は、IANA（一般的なポートとして以下を参照）によって割り当てられた16384のユーザー定義ポート及び49152ポートを含んで利用できる。
【００２１】
パケットが入ってきた時の最初のチェックは、ARPプロトコルを用いたパケットに対してのものであり、残りのパケットに対しては異なった処理が行われる。ARP（Address Resolution Protocol）パケットは、ネットワークインターフェース上でローカルに処理される。仮に、入ってきたパケットがARPでないならば、その時、次のテストが実行される。
【００２２】
チェックにより、パケットのIPバージョンがフィルタで動作中のものと同様であることが保証される。各フィルタは、一つのIPバージョンしか動作せず、かつ、両方のフィルタ方向に対して同様でなければならない。チェックは、IPヘッダの長さとプロトコルに関して実行される。チェックは、パケットヘッダ長が事前定義した最小値、すなわち20オクテット以上であることを保証するために、IPヘッダのフィールド長に関してフィルタによって実行される。そのフィルタはまた、IPプロトコルのパケットヘッダフィールドが、受信可能なプロトコルテーブルにおいて有効な入力に相当するかを確立するためにチェックを行う。
【００２３】
これらのチェックがルールテーブルに対してインデックスを通過するかどうかは、その位置でルールが存在するかを確立するのに用いられる。上記の全てのチェックを失敗するか、または、その位置がルールを含んでいない場合には、パケットについての統計表が記され、パケットが廃棄される。
【００２４】
チェックは、パケットがマルチキャストIPアドレスを持つかどうかを確立するために実行される。マルチキャストアドレスを持つならば、ルールインデックスが、マルチキャストIPアドレステーブルから引き抜かれる。マルチキャストIPアドレステーブルは、図２及び図３に示される（下記参照のこと）配置のように、フィルタを通じて、マルチキャストパケットの経路を定めるために用いられる２０ビットのインデックスを与える。マルチキャストパケットは通常、ファイアウォールコントローラーへ経路が定められる。パケットについての統計表が記され、その宛先への転送のために通過される。
【００２５】
ルール内のフラグは、パケットヘッダ内でどのデータ項目が変化するか、また、フィルタによってどの統計的情報の項目が更新されたかを決定する。パケットヘッダ内の宛先IPアドレスは、ルール上で蓄積されている変更後の宛先アドレスへ変化する。パケットヘッダ内の宛先ポート番号は、ルール上で蓄積されている変更後の宛先ポート番号へ変化する。送信元アドレスは、ルール上で蓄積されている変更後の送信元アドレスへ変化する。プロトコルヘッダ内の送信元ポート番号は、ルール上で蓄積されている変更後の送信元ポート番号へ変化する。
【００２６】
上記ヘッダの変化は、パケットがファーストエンドポイントからフィルタへ、かつ、フィルタからセカンドエンドポイントへ、かつ、逆の戻る道程が、正確に割り当てられていることを保証することが必要となる。ルールから区別されたサービス（diffserv）ビット、すなわち、パケットヘッダにおけるビットは、その設定により、ルーターが異なる優先事項等のパケットのクラス間を区別するのを許可し、適切な位置においてパケットヘッダに加えられることになる。パケットヘッダのチェックサムは、データ変換が行われた後、計算し直される。
【００２７】
図２から図４は、ルールインデックスが入力パケットの異なる型をどのように計算しているかを示す。図において、最下位ビット（ビット0）は、各フィールドの右手側である。
【００２８】
本発明の好ましい実施例では、ファイアウォールに対するIPアドレスとポート番号の割り当ては、特定の位置を発生させるように調整されたファイアウォールコントロールファンクションにより、次のパケットのために適切なルールを迅速に識別できるように同じ呼び出しの部分を作り上げる方法で実行される。本発明のさらに好ましい実施例としては、ファイアウォールフィルタに対するIPアドレスとポート番号の割り当ては、ファイアウォールに対する外部プラットフォームにより行われる。ファイアウォールは、同じ呼び出しの部分を作る次のパケットのために適切なルールの迅速な識別ができるように、ファイアウォールコントロールファンクションと協同で特定の位置を発生するように調整されている。優位性としては、本発明は、順番に各ルールをチェックする処理を用いていることよりもむしろ、ローカルに内容が設定されている受信パケットから、ファイアウォール（上述参照）までのフィールドの利用を提供しているところにある。これは、関連したルールに対して（すなわち、ルールテーブルにおいて関連する位置に対して）、直接的にインデックスを提供しており、エンドポイントが設定を行うこととは対照的である。この故に、適切なルールがインデックス値に設定されているかどうかが、直接のポイントとなる。インデックス値が有効なルールを指示していないならば、その時、関連パケットは拒否される。パケットを拒否する際にも、本発明は、更なる効果を提供する。この故に、本発明にでは、パケットの通過か拒否の決定は、常に、ルールテーブルへの単一のアクセスで達成される。
【００２９】
図２は、TCP/UDPでないプロトコルのためのルールの計算を示している。TCPまたはUDP以外のプロトコルのために、ルールインデックスは、IPアドレスと一緒に8ビットプロトコルID値によって指示されるIPプロトコルインデックステーブルにおける値に基づいて計算される。IPプロトコルインデックステーブルは、ファイアウォール上に与えられている。プロトコルフィールドにおいて指定された値は、プロトコルテーブルにインデックスとして用いられる。指示された入力は、プロトコルが有効かどうかを指示しているテーブルである。プロトコルが有効ならば、その時、ルールインデックスは、そのプロトコルに関してIPプロトコルインデックステーブルで指示された入力から下位14ビットを取り、これと一緒にIPアドレスから下位6ビットを取って作られる。
【００３０】
図３は、“よく知られたポート”のルールインデックスの計算を示している。プロトコルが、TCPまたはUDPであり、ポート番号が、16進表記で0000からBFFFの範囲にあるならば、ポート番号は、“よく知られたポート”テーブルに対するインデックスとして用いられる。“よく知られたポート”テーブルは、IANAによって定義（79＝finger等）されているような特定の一致のあるポート番号を含む。このテーブルは、ポートがこのフィルタに関してサポートされているかどうかを確立するために用いられる。ポートがサポートされているならば、ルールデータに対するインデックスは、IPアドレスと一緒に宛先ポート番号よって指示されたテーブルからの値に基づいている。ルールインデックスは、ポート番号により指示されたよく知られたポート番号テーブルにおける入力から下位14ビットを取り、これと一緒にIPアドレスから下位6ビットを取ることにより作られる。ポートがサポートされていないならば、その時、送信されたパケットは廃棄される。
【００３１】
図４は、ユーザポートのルールインデックスの計算を示している。TCP及びUDPプロトコルが、よく知られているポート（例えば、ポート番号が16進表記でC000からFFFFまでの範囲に存在する）でない場合、ルールインデックスは、ポート番号及びIPアドレスの一部から作られる。ルールインデックスは、ポート番号の下位14ビットと一緒にIPアドレスから最下位6ビットを取ることによって作られる。
【００３２】
上記の例外は、任意のIPSECに対して存在する。IPSECプロトコルタイプには二つバージョン、IPプロトコル50ESP（Encapsulating Security Payload）及びIPプロトコル51AH（Authentication Header）がある。これらのバージョンは、共に、Security Parameters Index(SPI)を含んでいる。セキュリティヘッダにおいて、ESPに対してのフィールドは、最初の32ビットにおいて存在し、AHに対してのフィールドは、二番目の32ビットに存在する。SPIは、宛先IPアドレス及びプロトコルと共にパケットを識別し特定する。これらのパケットルールインデックスの初期化は、SPIの下位14ビットとIPアドレスの下位6ビットを使用せずに、上述されたものに類似した処理をユーザポートに施すことによって達成される。ルールインデックスが公式化された後、ルールデータのコントロールフィールドにおける値に従い、フィルタはチェックを実行し、ファンクションを置き換えることに注意しなければならない。IPSECパケットにおいて、原理の違いは、送信元及び宛先のポート番号が、同じ位置に蓄積されていることもあるが、このことよりもむしろ、ただ単に一つの値であるSPIが存在することである。この値は、ルールによって割り当てられ、更に必要があれば、チェックされ置き換えられる。
【００３３】
ルールインデックスは、ルールコントロールによって定められるルール及びチェックにアクセスするのに用いられ、有効ワード（パケットをチェックするのに用いられる基準を決定するルールのある一部）が実行される。これらのチェックが通過するならば、パケットヘッダドレス及びポート等は、必要に応じて翻訳される。
【００３４】
必要があれば、変化したIPヘッダからIPアドレスに対して等、IPヘッダチェックサムは計算し直され、UDP/TCPヘッダチェックサムは調整される。その有効なパケットの統計的情報は、現在のパケットを取り込むために更新される。全チェックが失敗するならば、その時、そのパケットについての統計表が記され、パケットが廃棄される。
【００３５】
パケットは次の理由が、一つでも当てはまる時、廃棄される。
・IPv6動作時のIPv4等、パケット内のIPバージョンが、フィルタのバージョンと一致していない。
・不正確な宛先IPアドレス：各フィルタが、マルチキャストアドレス及び個々のIPアドレスを含んで動作するIPアドレスの範囲を持っている。フィルタの範囲において存在しないIPアドレスを持った全パケットは拒否される。
・パケットのヘッダの長さが、パケットが正当であることを照合するのに必要な最小サイズよりも短い。
・プロトコルがフィルタに受け付けられないものである場合。フィルタは受け入れるべきプロトコルを数多くサポートしており、パケットヘッダのプロトコルフィールドがこのリストに存在しないならば、パケットは拒否される。
・IPアドレスとポート番号（あるいは、IPSECのSPI）から計算されたルールインデックスは、パケットの転送を許可する開放状態でないルールを参照する。
・パケットヘッダにおける送信側のIPアドレスが、ルールデータにおいて、最初の送信元IPアドレスフィールドに一致していない。
・パケットヘッダからのプロトコルフィールドが、ルールデータにおいて、最初のプロトコルIDフィールドに一致していない。
・パケットヘッダからの送信元ポート番号が、ルールデータにおいて、最初の送信元ポート番号に一致していない。
・パケットヘッダにおいて、宛先ポート番号が、ルールデータ（IPSECパケットでない）からの最初の宛先ポート番号に一致していない。
・パケットヘッダにおいて、宛先SPIが、ルールデータ（IPSECパケット―以下参照）からの最初の宛先SPIに一致していない。
・宛先ポート番号が、入力の“よく知られたポート”テーブルが存在しない時を除いて、16進表記で'C000'より小さい（結果として“よく知られたポート”である）。
・パケットの宛先IPアドレスフィールドが、ルールデータの最初の宛先IPアドレスフィールドに一致していない。
・IPアドレス及びポート番号（あるいはSPSECのSPI）から計算されたルールインデックスが、設定されていないルールを参照している。
【００３６】
本発明は、ハードウェアまたはソフトウェアにおいて実行されるパケットフィルタに適用される。本発明は、イーサネット（登録商標）上のIPに対してのみに限定されることなく、SONET/SDH、及びATM AAL5上のパケットのような他のネットワークの型にも適用される。本発明は、安価なランダムアクセスメモリを用いるならば、最適なパフォーマンスに達する。
【００３７】
定義
Address Resolution Protocol (ARP)
ローカルネットワークで認識される物理アドレスに対してIPアドレスをマッピングするためのプロトコル
Gatekeeper
IP電話ネットワークにおける構成要素。a) ネットワークにおける他の構成要素のRAS、b) 個別呼び出しのためのアドレス翻訳、c) ゲートウェイのコントロール
H.225
パケットに基づくマルチメディア通信システムのためのプロトコル呼び出し信号とメディアストリームパケットを定義しているITU-T規格
H.323
パケットに基づくマルチメディア通信システムのためのITU-T規格
IANA
IANA
ITU-T
国際電気通信連合電気通信標準化部門
IETF
Internet Engineering Task Force
（インターネット関連技術の標準化のためのボランティアグループ）
Internet Protocol (IP)
IPネットワークためのネットワークレイヤープロトコルであり、データパケットの不信頼な二地点間転送を提供する。現在使用されている標準は、IETF RFC791で定義されているバージョン4（IPv4）である。これは、将来的には、IETF RFC2460で定義されているバージョン6（IPv6）に取って代わられる予定となっている。
IP Telephony, Voice over Internet, Multimedia over IP
IPプロトコルに基づくネットワークに関する電話学の技術
Media Gateway Control Protocol (MGCP)
ITU-T MEGACOワーキンググループで提案されているプロトコルであり、ゲートキーパーによるメディアゲートウェイのコントロールのためのものである。インターネットドラフトドキュメントdraft-huitemamegaco-mgcp-v0r1-05で定義されている。
MEGACO
MEGACOは、物理的に分離されているマルチメディアゲートウェイの要素間で利用されるプロトコルを定義している。MEGACOの構成は、IETFインターネットドラフトドキュメントdraft-ietf-megaco-protocol-04に記述されている。
Registration, Admission and Status (RAS)
ネットワーク上で、レジスタに実体を与えているH.323プロトコル内での信号ファンクションであり、IP電話呼び出しを作成しているユーザの認証を行い、また、レジスタ上でのステータス情報を持つ。RASはH.225通信を用いている。RASの信号路は、H.323エンドポイント間の他の全経路を確定に向けて事前に開放されている。
Transmission Control Protocol (TCP)
コネクション型の高信頼のトランスポート層プロトコルであり、IPプロトコル上で動作するように設計されている。IETF RFC 7932で定義されている。
User Datagram Protocol (DDP)
コネクションレス型の低信頼のトランスポート層プロトコルであり、IPプロトコル上で動作するように設計されている。IETF RFC 768で定義されている。
【図面の簡単な説明】
【００３８】
【図１】従来のファイアウォールフィルタの主な構成要素のブロック図を示す。
【図２】TCP/UDPでないプロトコルのためのルールの計算を示す。
【図３】“よく知られたポート”のルールインデックスの計算を示す。
【図４】ユーザポートのルールインデックスの計算を示す。
Claims (29)
- 複数のルールに従うパケットであって、各々がコントロール値と協働するパケットをチェックするパケットコントロール手段を備え、
前記パケットコントロール手段が、
パケットと協働する前記コントロール値からインデックス値を発生させるインデックス手段と、
前記インデックス値を用いて前記複数のルールから前記パケットをチェックするルールにアクセスする手段とを含んでおり、
前記パケットが、常に、前記複数のルールに対して単一のアクセスを必要とする通信システム。 - 前記コントロール値が、前記パケットコントロール手段によって設定される請求項１の通信システム。
- 前記通信システムはまた、前記パケットコントロール手段の外部にあるパケット値手段を含んでおり、
前記コントロール値が、前記パケットコントロール手段と共同して、前記パケット値手段によって設定される請求項１の通信システム。 - 前記パケットコントロール手段が、前記パケットを通過すべきか拒否すべきかを決定する手段を備えている前記いずれか１つの請求項で請求した通信システム。
- 前記コントロール値が、アドレスかつポート番号（PN）、またはそのどちらか一方を備えている前記いずれか１つの請求項で請求した通信システム。
- 前記インデックス手段が、ルックアップテーブルに対する指標として前記PN値を用いる手段を備え、
前記PNによって指示される前記アドレス値及び前記ルックアップテーブル値の組み合わせから前記インデックス値を発生させる手段を備えている請求項５で請求した通信システム。 - 前記コントロール値が、アドレス値及びプロトコル値を備えている請求項１から４のいずれか１つの通信システム。
- 前記インデックス手段が、ルックアップテーブルに対する指標として前記プロトコル値を利用する手段を備え、
前記プロトコル値によって指示される前記アドレス値及び前記ルックアップテーブル値に基づいた前記インデックス値を発生させる手段を備えている請求項７の通信システム。 - 前記インデックス手段が、マルチキャストパケットを検出し、そのパケットの中から単一のルールを識別する手段を備えている前記いずれか１つの請求項で請求した通信システム。
- パケットが、特殊な送信元から受信された時、及び特殊な呼び出しに関連している時に、前記コントロール値が、一意に定まる前記いずれか１つの請求項で請求した通信システム。
- 前記アドレスが、インターネットプロトコルアドレスである前記いずれか１つの請求項で請求した通信システム。
- 前記PNが、User Datagram Protocol (UDP)PN、Transmission Control Protocol (TCP)PNかまたは、Stream Control Transmission Protocol (SCTP)PNである前記いずれか１つの請求項で請求した通信システム。
- 前記パケットコントロール手段が、ファイアウォールを備えている前記いずれか１つの請求項で請求した通信システム。
- 前記パケットが、Telephonyトラフィックを受け持つ前記いずれか１つの請求項で請求した通信システム。
- パケットコントロール手段を備えているパケットに基づく通信システムにおいて、
前記コントロール手段でコントロール値を含んでいるパケットを受信するステップと、
前記コントロール値を利用して、前記パケットのチェック機能の使用時に、複数のルールから一つのルールにアクセスするステップとを備え、
前記パケットのチェックが、常に、前記複数のルールに対して単一のアクセスを必要とするパケットをフィルタ処理する方法。 - 前記パケットコントロール手段が、前記パケットに対して前記コントロール値を割り当てる請求項１５の方法。
- 前記通信システムがパケット値手段を備えており、
前記パケット値手段が、前記パケットコントロール手段と共同して前記コントロール値を割り当てる請求項１５の方法。 - 前記パケットコントロール手段が、前記パケットを通過させるべきか、または拒否するべきかを決定するのステップを備えている請求項15から17の方法。
- 前記コントロール値が、PNかつアドレス、またはどちらか一方を備えている請求項15から18のいずれか１つの方法。
- 前記インデックス手段が、ルックアップテーブルに対する指標として前記PN値を利用すると共に、前記PNによって指示される前記アドレス値及び前記ルックアップテーブル値の組み合わせから前記インデックス値を発生させる請求項19の方法。
- 前記コントロール値が、アドレス値及びプロトコル値を備えている請求項15から18のいずれか１つの方法。
- 前記インデックス手段が、ルックアップテーブルに対する指標として前記プロトコル値を利用すると共に、前記プロトコル値によって指示される前記アドレス値及び前記ルックアップテーブル値に基づいて前記インデックス値を発生させる請求項21の方法。
- 前記インデックス手段が、マルチキャストパケットを検出し、そのパケットの中から単一のルールを識別する手段を備えている請求項15から22のいずれか１つにおいて請求した方法。
- パケットが、特殊な送信元から受信された時、及び特殊な呼び出しに関連している時、前記コントロール値が、任意のポイントで一意に定まる請求項15から23のいずれか１つにおいて請求した方法。
- 前記アドレスが、インターネットプロトコルアドレスである請求項15から24のいずれか１つにおいて請求した方法。
- 前記PNがUDP、TCP、またはSCTP PNである請求項15から25のいずれか１つにおいて請求した方法。
- 前記パケットコントロール手段が、ファイアウォールを備えている請求項15から26のいずれか１つにおいて請求した方法。
- 前記パケットが、テレフォニィトラフィックを受け持つ請求項15から27のいずれか１つにおいて請求した方法。
- 適切なルールを識別するためのルールテーブルに対するインデックスとして前記アドレス及び前記PNを利用するステップを備えている請求項15から28のいずれか１つにおいて請求した方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0100713A GB2371186A (en) | 2001-01-11 | 2001-01-11 | Checking packets |
| PCT/GB2002/000040 WO2002056562A1 (en) | 2001-01-11 | 2002-01-07 | Firewall with index to access rule |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004522335A true JP2004522335A (ja) | 2004-07-22 |
Family
ID=9906643
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002557096A Pending JP2004522335A (ja) | 2001-01-11 | 2002-01-07 | ルールにアクセスするためにインデックスを用いたファイアウォール |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US20040100972A1 (ja) |
| EP (1) | EP1352503A1 (ja) |
| JP (1) | JP2004522335A (ja) |
| CN (1) | CN1496642A (ja) |
| AU (1) | AU2002219332B2 (ja) |
| CA (1) | CA2434600A1 (ja) |
| GB (1) | GB2371186A (ja) |
| WO (1) | WO2002056562A1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010278638A (ja) * | 2009-05-27 | 2010-12-09 | Fujitsu Ltd | トンネル通信装置及び方法 |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7249379B2 (en) * | 2002-02-01 | 2007-07-24 | Systems Advisory Group Enterprises, Inc. | Method and apparatus for implementing process-based security in a computer system |
| US7062680B2 (en) * | 2002-11-18 | 2006-06-13 | Texas Instruments Incorporated | Expert system for protocols analysis |
| US8112482B1 (en) * | 2004-04-14 | 2012-02-07 | Sprint Spectrum L.P. | System and method for securing access to electronic mail |
| US8042170B2 (en) | 2004-07-15 | 2011-10-18 | Qualcomm Incorporated | Bearer control of encrypted data flows in packet data communications |
| US8265060B2 (en) | 2004-07-15 | 2012-09-11 | Qualcomm, Incorporated | Packet data filtering |
| CN1997010B (zh) * | 2006-06-28 | 2010-08-18 | 华为技术有限公司 | 一种包过滤的实现方法 |
| US8099774B2 (en) * | 2006-10-30 | 2012-01-17 | Microsoft Corporation | Dynamic updating of firewall parameters |
| IL181427A0 (en) * | 2007-02-19 | 2007-07-04 | Deutsche Telekom Ag | Novel dynamic firewall for nsp networks |
| DE102007053691A1 (de) * | 2007-11-10 | 2009-05-14 | Manroland Ag | Kommunikationsnetzwerk einer Druckmaschinensteuerung |
| US8102783B1 (en) | 2009-02-04 | 2012-01-24 | Juniper Networks, Inc. | Dynamic monitoring of network traffic |
| US9237128B2 (en) * | 2013-03-15 | 2016-01-12 | International Business Machines Corporation | Firewall packet filtering |
| WO2014077614A1 (en) * | 2012-11-19 | 2014-05-22 | Samsung Sds Co., Ltd. | Anti-malware system, method of processing data in the same, and computing device |
| US9444914B2 (en) * | 2013-09-16 | 2016-09-13 | Annapurna Labs Ltd. | Configurable parser and a method for parsing information units |
| US10944722B2 (en) | 2016-05-01 | 2021-03-09 | Nicira, Inc. | Using activities to manage multi-tenant firewall configuration |
| US11310202B2 (en) * | 2019-03-13 | 2022-04-19 | Vmware, Inc. | Sharing of firewall rules among multiple workloads in a hypervisor |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2248577C (en) * | 1996-04-24 | 2002-11-05 | Northern Telecom Limited | Internet protocol filter |
| US6147976A (en) * | 1996-06-24 | 2000-11-14 | Cabletron Systems, Inc. | Fast network layer packet filter |
| US6510151B1 (en) * | 1996-09-19 | 2003-01-21 | Enterasys Networks, Inc. | Packet filtering in connection-based switching networks |
| US6233686B1 (en) * | 1997-01-17 | 2001-05-15 | At & T Corp. | System and method for providing peer level access control on a network |
| US5951651A (en) * | 1997-07-23 | 1999-09-14 | Lucent Technologies Inc. | Packet filter system using BITMAP vector of filter rules for routing packet through network |
| US7143438B1 (en) * | 1997-09-12 | 2006-11-28 | Lucent Technologies Inc. | Methods and apparatus for a computer network firewall with multiple domain support |
| SE513828C2 (sv) * | 1998-07-02 | 2000-11-13 | Effnet Group Ab | Brandväggsapparat och metod för att kontrollera nätverksdatapakettrafik mellan interna och externa nätverk |
| US6341130B1 (en) * | 1998-02-09 | 2002-01-22 | Lucent Technologies, Inc. | Packet classification method and apparatus employing two fields |
| US6400707B1 (en) * | 1998-08-27 | 2002-06-04 | Bell Atlantic Network Services, Inc. | Real time firewall security |
| US6798777B1 (en) * | 2000-04-17 | 2004-09-28 | Juniper Networks, Inc. | Filtering and route lookup in a switching device |
| US7039053B1 (en) * | 2001-02-28 | 2006-05-02 | 3Com Corporation | Packet filter policy verification system |
| US6816455B2 (en) * | 2001-05-09 | 2004-11-09 | Telecom Italia S.P.A. | Dynamic packet filter utilizing session tracking |
| US7107609B2 (en) * | 2001-07-20 | 2006-09-12 | Hewlett-Packard Development Company, L.P. | Stateful packet forwarding in a firewall cluster |
-
2001
- 2001-01-11 GB GB0100713A patent/GB2371186A/en not_active Withdrawn
-
2002
- 2002-01-07 EP EP02729429A patent/EP1352503A1/en not_active Withdrawn
- 2002-01-07 CA CA002434600A patent/CA2434600A1/en not_active Abandoned
- 2002-01-07 CN CNA028063309A patent/CN1496642A/zh active Pending
- 2002-01-07 JP JP2002557096A patent/JP2004522335A/ja active Pending
- 2002-01-07 AU AU2002219332A patent/AU2002219332B2/en not_active Ceased
- 2002-01-07 WO PCT/GB2002/000040 patent/WO2002056562A1/en active Application Filing
- 2002-01-07 US US10/250,958 patent/US20040100972A1/en not_active Abandoned
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010278638A (ja) * | 2009-05-27 | 2010-12-09 | Fujitsu Ltd | トンネル通信装置及び方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1352503A1 (en) | 2003-10-15 |
| CN1496642A (zh) | 2004-05-12 |
| WO2002056562A9 (en) | 2003-11-13 |
| AU2002219332B2 (en) | 2006-12-21 |
| US20040100972A1 (en) | 2004-05-27 |
| GB2371186A (en) | 2002-07-17 |
| GB0100713D0 (en) | 2001-02-21 |
| CA2434600A1 (en) | 2002-07-18 |
| WO2002056562A1 (en) | 2002-07-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8116307B1 (en) | Packet structure for mirrored traffic flow | |
| US7730521B1 (en) | Authentication device initiated lawful intercept of network traffic | |
| US7782902B2 (en) | Apparatus and method for mapping overlapping internet protocol addresses in layer two tunneling protocols | |
| US7472411B2 (en) | Method for stateful firewall inspection of ICE messages | |
| US10171514B2 (en) | Method and system for routing media calls over real time packet switched connection | |
| US8339959B1 (en) | Streamlined packet forwarding using dynamic filters for routing and security in a shared forwarding plane | |
| US7380011B2 (en) | Methods and systems for per-session network address translation (NAT) learning and firewall filtering in media gateway | |
| US7406709B2 (en) | Apparatus and method for allowing peer-to-peer network traffic across enterprise firewalls | |
| US8391453B2 (en) | Enabling incoming VoIP calls behind a network firewall | |
| US7639668B2 (en) | Method for securing RTS communications across middleboxes | |
| US6674743B1 (en) | Method and apparatus for providing policy-based services for internal applications | |
| JP2004522335A (ja) | ルールにアクセスするためにインデックスを用いたファイアウォール | |
| US20070291734A1 (en) | Methods and Apparatus for Multistage Routing of Packets Using Call Templates | |
| WO2006129142A2 (en) | Apparatus and method creating virtual routing domains in an internet protocol network | |
| JP2012517161A (ja) | 拡縮可能なｎａｔ通過 | |
| US7715401B2 (en) | Router | |
| AU2002219332A1 (en) | Firewall with index to access rule | |
| US8103790B2 (en) | Apparatus and method for supporting multiple traffic categories at a single networked device | |
| US6922786B1 (en) | Real-time media communications over firewalls using a control protocol | |
| US20060140174A1 (en) | VoIP (voice over internet protocol) call processing | |
| US20070245412A1 (en) | System and method for a communication system | |
| JP2004533149A (ja) | ＩＰＱｏＳのサービス拒否攻撃に耐えるための仮想私設網を採用するシステム、方法および装置 | |
| Hei et al. | Open 6to4 relay router operation | |
| KatsuyukiYamazaki | Open 6to4 Relay Router Operation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040830 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060508 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060808 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060815 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061107 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070109 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20070201 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20070409 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20070416 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070910 |