(57)【要約】  サービス拒絶攻撃による混乱のリスクを軽減するように、経路キャッシュを管理するためのシステムおよび方法。ローカル（オンリンク）ノード（例えば、隣接ノード）からフロントインターフェースに到達する全てのトラフィックは正常に処理することができる。しかしながら、所定の宛先ＩＰアドレスにアドレス指定されたリモート（オフリンク）ソースから受信したパケットには、単一かつ共有の経路キャッシュエントリを用いることができる。このエントリにおけるソースアドレスフィールドは、どのソースから受信したトラフィックにも用いられないためゼロ設定されてもよい。同様に、フロントインターフェースを通じてオフリンク宛先に向かう全てのパケットには、別の単一かつ共有の経路キャッシュエントリが生成され、用いることができる。このエントリにおける宛先アドレスフィールドは、いかなる宛先に向かうトラフィックにも用いられないため、ゼロ設定することができる。
2013503572.tif 000002
【特許請求の範囲】
【請求項１】
パケットソースアドレスおよびパケット宛先アドレスを有するネットワークパケットを送信するための方法であって、
少なくともエントリソースアドレス、エントリ宛先アドレス、およびネットワークインターフェースへのエントリ参照を含むエントリを経路キャッシュが含むことと、
フロントインターフェースとして前記ネットワークインターフェースを指定することと、
前記ネットワークインターフェースをフロントインターフェースＩＰアドレスと関連付けることと、
前記フロントインターフェースＩＰアドレスと同一のエントリソースアドレスを含むが、前記経路キャッシュ内のオフリンク宛先エントリ、および転送先アドレスを生成することであって、前記オフリンクアドレスは前記パケット宛先アドレスを含まない、生成することと、
前記パケット宛先アドレスがオフリンクアドレスであるか否かを決定することと、
前記パケット宛先アドレスがオフリンクアドレスであると決定された場合に、前記経路キャッシュ内で、前記パケットソースアドレスとして前記同一のソースアドレス、および前記転送先アドレスを有する前記オフリンク宛先エントリを検索することと、
前記フロントインターフェースを介して、前記パケットを前記転送先アドレスに送信することと、を含む、方法。
【請求項２】
前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
少なくとも前記パケットソースアドレスに基づいて検索ハッシュ値を算出することと、
前記経路キャッシュ内で前記検索ハッシュ値と同一のハッシュ値を含むエントリを検索することと、を含む、請求項１に記載の方法。
【請求項３】
前記オフリンク宛先エントリがエントリサービスタイプ識別子を含み、前記ネットワークパケットがパケットサービスタイプ識別子を含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリサービスタイプ識別子が前記パケットサービスタイプ識別子と同一であることを保証することをさらに含む、請求項１に記載の方法。
【請求項４】
前記オフリンク宛先エントリが前記エントリプロトコル識別子を含み、前記ネットワークパケットがパケットプロトコル識別子を含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリプロトコル識別子が前記パケットプロトコル識別子と同一であることを保証することをさらに含む、 請求項１に記載の方法。
【請求項５】
前記オフリンク宛先エントリがエントリ差別化サービスコードポイントを含み、前記ネットワークパケットがパケット差別化サービスコードポイントを含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリ差別化サービスコードポイントが前記パケット差別化サービスコードポイントと同一であることを保証することをさらに含む、請求項１に記載の方法。
【請求項６】
前記ネットワークパケットは関連するソケット接続状態を有するソケットから作成され、オペレーティングシステムにより制御され、
前記経路キャッシュにおいて前記ソケット接続状態が利用できないことを決定し、
前記オペレーティングシステムから、前記前記ソケットの前記接続状態をリクエストする、請求項１に記載の方法。
【請求項７】
前記ソケットはＴＣＰ接続を形成する、請求項６に記載の方法。
【請求項８】
パケットソースアドレスおよびパケット宛先アドレスを有するネットワークパケットを受信するための方法であって、
少なくともエントリソースアドレス、エントリ宛先アドレス、および物理ネットワークインターフェースへのエントリ参照を含むエントリを経路キャッシュが含むことと、
フロントインターフェースとして前記物理ネットワークインターフェースを指定することと、
前記物理ネットワークインターフェースをフロントインターフェースＩＰアドレスと関連付けることと、
前記フロントインターフェースＩＰアドレスと同一のエントリ宛先アドレスを含む、前記経路キャッシュ内のオフリンクソースエントリを生成することであって、前記オフリンクソースエントリは前記パケットソースアドレスを含まない、生成することと、
前記パケットソースアドレスがオフリンクアドレスであるか否かを決定することと、
前記パケットソースアドレスがオフリンクアドレスであると決定された場合に、前記経路キャッシュ内で前記パケット宛先アドレスとして前記同一の宛先アドレスを有する前記オフリンクソースエントリを検索することと、
前記パケットをローカルソケットに転送することと、を含む、方法。
【請求項９】
前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
少なくとも前記パケット宛先アドレスに基づいて検索ハッシュ値を算出することと、
前記経路キャッシュ内で前記検索ハッシュ値と同一のハッシュ値を含むエントリを検索することと、を含む、請求項８に記載の方法。
【請求項１０】
前記オフリンクソースエントリがエントリサービスタイプ識別子を含み、前記ネットワークパケットがパケットサービスタイプ識別子を含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリサービスタイプ識別子が前記パケットサービスタイプ識別子と一致することを保証することをさらに含む、請求項８に記載の方法。
【請求項１１】
前記オフリンクソースエントリがエントリプロトコル識別子を含み、前記ネットワークパケットがパケットプロトコル識別子を含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリプロトコル識別子が前記パケットプロトコル識別子と一致することを保証することをさらに含む、請求項８に記載の方法。
【請求項１２】
前記オフリンクソースエントリがエントリ差別化サービスコードポイントを含み、前記ネットワークパケットがパケット差別化サービスコードポイントを含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリ差別化サービスコードポイントが前記パケット差別化サービスコードポイントと一致することを保証することをさらに含む、請求項８に記載の方法。
【請求項１３】
前記ネットワークパケットが関連するソケット接続状態を有するソケットから作成され、オペレーティングシステムにより制御され、
前記経路キャッシュにおいて前記ソケット接続状態が利用できないことを決定し、
前記オペレーティングシステムから、前記ソケットの前記接続状態をリクエストする、請求項８に記載の方法。
【請求項１４】
前記ソケットはＴＣＰ接続を形成する、請求項１３に記載の方法。
【請求項１５】
パケットソースアドレスおよびパケット宛先アドレスを有するネットワークパケットを転送するための方法であって、
パケットの処理方法に関する情報を含むエントリであって、エントリソースアドレス、エントリ宛先アドレス、および物理ネットワークインターフェースへのエントリ参照を含む少なくとも１つのエントリを経路キャッシュが含むことと、
前記経路キャッシュにオフリンクソースエントリを生成することであって、前記オフリンクエントリが前記パケットソースアドレスを含まず、かつ前記オフリンクソースエントリが前記パケット宛先アドレスを含まない、生成することと、
前記パケットソースアドレスがオフリンクアドレスであるか否かを決定することと、
前記パケットソースアドレスがオフリンクアドレスであると決定された場合に、前記経路キャッシュ内で前記オフリンクソースエントリを検索することと、
前記パケットを前記パケット宛先アドレスに転送することと、を含む、方法。
【請求項１６】
前記経路キャッシュ内にオフリンクソースエントリを生成することが、前記パケット宛先アドレスがオンリンクアドレスである場合にのみパケットに用いられるように、前記エントリをマーキングすることをさらに含み、
前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、前記パケット宛先アドレスがオンリンクアドレスであることを決定することを含む、請求項１５に記載の方法。
【請求項１７】
前記オフリンクソースエントリがエントリサービスタイプ識別子を含み、前記ネットワークパケットがパケットサービスタイプ識別子を含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリサービスタイプ識別子が前記パケットサービスタイプ識別子と一致することを保証することをさらに含む、請求項１５に記載の方法。
【請求項１８】
前記オフリンクソースエントリがエントリプロトコル識別子を含み、前記ネットワークパケットがパケットプロトコル識別子を含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリプロトコル識別子が前記パケットプロトコル識別子と一致することを保証することをさらに含む、請求項１５に記載の方法。
【請求項１９】
前記オフリンクソースエントリがエントリ差別化サービスコードポイントを含み、前記ネットワークパケットがパケット差別化サービスコードポイントを含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリ差別化サービスコードポイントが前記パケット差別化サービスコードポイントと一致することを保証することをさらに含み、請求項１５に記載の方法。
【請求項２０】
前記ネットワークパケットが関連するソケット接続状態を有するソケットから作成され、オペレーティングシステムにより制御され、
前記経路キャッシュにおいて前記ソケット接続状態が利用できないことを決定し、
前記オペレーティングシステムから、前記ソケット接続状態をリクエストする、請求項１５に記載の方法。
【請求項２１】
前記ソケットはＴＣＰ接続を形成する、請求項２０に記載の方法。
【請求項２２】
パケットソースアドレスおよびパケット宛先アドレスを有するネットワークパケットを転送するための方法であって、
パケットの処理方法に関する情報を含むエントリであって、エントリソースアドレス、エントリ宛先アドレス、および物理ネットワークインターフェースへのエントリ参照を含む少なくとも１つのエントリを経路キャッシュが含むことと、
前記経路キャッシュ内にオフリンク宛先エントリを生成することであって、前記オフリンクエントリは前記パケットソースアドレスを含まず、かつ前記オフリンク宛先エントリは前記パケット宛先アドレスを含まない、生成することと、
前記パケット宛先アドレスがオフリンクアドレスであるか否かを決定することと、
前記パケット宛先アドレスがオフリンクアドレスであると決定された場合に、前記経路キャッシュ内で前記オフリンク宛先エントリを検索することと、
前記パケットを前記パケット宛先アドレスに転送することと、を含む、方法。
【請求項２３】
前記経路キャッシュ内でオフリンクソースエントリを生成することが、前記パケットソースアドレスがオンリンクアドレスである場合にのみパケットに用いられるように、前記エントリをマーキングすることをさらに含み、
前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、前記パケットソースアドレスがオンリンクアドレスであることを検証することを含む、請求項２２に記載の方法。
【請求項２４】
前記オフリンク宛先エントリがエントリサービスタイプ識別子を含み、前記ネットワークパケットがパケットサービスタイプ識別子を含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリサービスタイプ識別子が前記パケットサービスタイプ識別子と一致することを保証することをさらに含む、請求項２２に記載の方法。
【請求項２５】
前記オフリンク宛先エントリがエントリプロトコル識別子を含み、前記ネットワークパケットがパケットプロトコル識別子を含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリプロトコル識別子が前記パケットプロトコル識別子と一致することを保証することをさらに含む、請求項１に記載の方法。
【請求項２６】
前記オフリンク宛先エントリがエントリ差別化サービスコードポイントを含み、前記ネットワークパケットがパケット差別化サービスコードポイントを含み、前記経路キャッシュ内で前記オフリンクソースエントリを検索することが、
前記エントリ差別化サービスコードポイントが前記パケット差別化サービスコードポイントと一致することを保証することをさらに含む、請求項１に記載の方法。
【請求項２７】
前記ネットワークパケットが関連するソケット接続状態を有するソケットから作成され、オペレーティングシステムにより制御され、
前記経路キャッシュにおいて前記ソケット接続状態が利用できないことを決定し、
前記オペレーティングシステムから、前記ソケットの前記接続状態をリクエストする、請求項１に記載の方法。
【請求項２８】
前記ソケットはＴＣＰ接続を形成する、請求項６に記載の方法。
【請求項２９】
少なくともエントリソースアドレス、エントリ宛先アドレス、ソース物理ネットワークインターフェースへのエントリ参照、および宛先物理ネットワークインターフェースへのエントリ参照を含むエントリを有する経路キャッシュを用いて、パケットソースアドレスおよびパケット宛先アドレスを有するネットワークパケットを転送するための方法であって、
ソース物理ネットワークインターフェースへのエントリ参照、および宛先ＩＰアドレスが前記エントリにマッチしたか否かを決定するためのデータを含む第１の共有のエントリを、前記経路キャッシュ内に生成することであって、前記第１の共有のエントリは、パケット宛先アドレスを含まず、かつパケットソースアドレスを含まない、生成することと、
物理ネットワークインターフェースにおける宛先ＩＰアドレスを含むパケットを受信することと、
前記ソース物理ネットワークインターフェースに対して前記パケットがその上で受信されたエントリ参照を含み、かつ前記パケット宛先ＩＰアドレスが前記エントリにマッチすることを示すデータを含むエントリを、前記経路キャッシュ内で検索することと、を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、サーバの経路キャッシュに膨大な数のエントリを殺到させる、稼働中のサーバへの攻撃を阻止するための方法に関するものである。
【背景技術】
【０００２】
インターネットプロトコル（ＩＰ）ネットワーク上でデータパケットを送信する際に、多くの場合に、転送情報ベース（ＦＩＢ）と呼ばれるデータベースに種々のパケットを運ぶ経路が加えられる。ＦＩＢは経路指定テーブルとも呼ばれる。経路指定テーブルはパケットが正確な宛先に届くようなパケットの適切な転送方法を指定する。Ｌｉｎｕｘ（登録商標）を含む一部のオペレーティングシステムは、複数のＦＩＢをサポートする。一部のＦＩＢは種々のネットワークインターフェースに関連することができる。ＦＩＢ規則データベースは、所定のＩＰパケットを処理する際に、どのＦＩＢを用いるべきかを指定する規則を含む。パケットの受信、送信、または転送処理の際に、オペレーティングシステムはどのＦＩＢを用いるべきかを追跡しなければならないだけでなく、どの経路を用いるべきか、どの一連の機能がパケットを処理するべきか、どの隣人にパケットを送信するべきかなども決定する。オペレーティングシステムはさらに、サービス拒絶攻撃を阻止するために、パケットのソースおよび宛先ＩＰアドレスについてのいくつかの検証を行う。パケットの取り扱い能力を改善するために、最新に観測したパケットのフロー、およびそれらがどのように処理されたかを追跡するいくつかのキャッシュを保持することが周知となっている。これはフローに含まれる潜在的に多数のパケットにわたるパケットごとの検証、および内部パケット操作パスに関して高コストを配分するのに役立つ。キャッシング目的のために、このフローは、同じＩＰソースアドレス、ＩＰ宛先アドレス、受信／送信インターフェース、およびサービスタイプ（ＴｏＳ）マーキングを有するパケットとすることができる。
【０００３】
Ｌｉｎｕｘ（登録商標）ＩＰスタックは３つの異なるキャッシュ、すなわち経路キャッシュ、隣接キャッシュ、およびハードウェアヘッダキャッシュを利用する。これらは全て特殊化された標準の宛先キャッシュである。宛先キャッシュは、プロトコルと関係がない形態において宛先アドレスおよび機能に関する情報を保持する。隣接キャッシュは、所定のノードに隣接する全てのＩＰアドレスとＭＡＣアドレスとの間のマッピングを保持する。所与のノードに隣接するもの（「オンリンク」ノードとしても周知である）は、例えば、イーサネット（登録商標）リンク上で、所与のノードからローカルで達することができるものである。所与のノードからローカルで達することができない場合があるノードは、所与のノードに関連する「オフリンク」ノードとして周知である可能性がある。隣接キャッシュは、ＩＰｖ４プロトコルに関するアドレス解決プロトコル（ＡＲＰ）テーブルとも呼ばれる。ハードウェアヘッダキャッシュは、ＭＡＣ層ヘッダおよびこれらのヘッダの操作に利用される機能を保持する。経路キャッシュは、ＩＰパケットの特性に関する情報、それらの操作に用いられる機能、適合パケットを受信するべき隣接するものに関する情報を保持する。
【０００４】
経路キャッシュは、一般的に、設備の起動時に初期化されるハッシュ表としても実現される。システム内のメモリ容量に基づいて、ハッシュバケット数が起動時に自動的に計算される。経路キャッシュが記憶可能な最大エントリ数は、オペレーティングシステムパラメータにより制御可能である。
【０００５】
ＩＰｖ４スタックにより取り扱われる全てのパケットにわたるＩＰｖ４ソースおよび宛先アドレスの一意の組み合わせ各々について、生成される経路キャッシュエントリは、通常は１つである。これは攻撃ベクトルとして用いられる可能性がある。攻撃者はランダムのソースアドレスを用いて被害者にパケットを送信する可能性がある。攻撃者はいかなる応答も受信する必要がない。被害者がパケットを取り扱うと、再利用が望まれる、エントリを含む経路キャッシュの投入を維持し続けるが、攻撃に用いられるソースアドレスは一意であるため、それは決して再利用されない。数１０万以内のパケットによって被害者の経路キャッシュが満たされる可能性があり、その性能が著しく低下する可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の実施形態は、経路キャッシュの利用法を変更することにより、この攻撃ベクトルを除去することができる。
【課題を解決するための手段】
【０００７】
本発明の実施形態は、経路キャッシュを管理するための手段を変更できる。少なくとも１つのネットワークインターフェースは、「フロントインターフェース」として識別することができる。ローカル（オンリンク）ノード（例えば、隣接ノード）からこのフロントインターフェースに到達する全てのトラフィックは正常に処理することができる。このようなオンリンクパケットの処理は、ローカル宛先アドレスをともなう一意の経路キャッシュエントリをもたらす可能性がある。しかしながら、所与の宛先ＩＰアドレスにアドレス指定されたリモート（オフリンク）ソースから到達したパケットには、単一の共有の経路キャッシュエントリを用いることができる。このエントリにおけるソースアドレスフィールドは、いかなる１つのソースから受信したトラフィックにも用いられないためゼロ設定される可能性がある。同様に、フロントインターフェースを通じてオフリンク宛先に向かう全てのパケットには、別の単一の共有の経路キャッシュエントリが生成され、用いられる可能性がある。このエントリにおける宛先アドレスフィールドは、いかなる１つの宛先に向かうトラフィックにも用いられないためゼロ設定される。
【０００８】
サーバからオフリンク宛先に移動する全てのパケットは、単一のルータを通じて送られてもよい。オフリンク宛先にパケットが送信される場合には、経路キャッシからの必要な情報は、通常ではルータアドレスのみであるため、オフリンク宛先に向かう全てのトラフィックに単一の経路キャッシュエントリを用いることができる。これは仮想ルータ冗長プロトコル（ＶＲＲＰ）またはシスコホストスタンバイルータプロトコル（ＨＳＲＰ）を含む、ノードへの単一のルータとしてルータ群を実現し得る特定のプロトコルを用いてルータ冗長が実現される場合でも用いられる。多重ルータを用いる場合には、冗長または別の方法のために、なおも経路キャッシュの最適化を利用することができるが、３つ以上の共有のエントリを用いるか、共有のエントリにおけるさらなる情報を組み込む必要が生じることがある。
【０００９】
同様に、オフリンクソースから受信した全てのトラフィックが、概して、経路キャッシュからの同じ情報を信頼する場合には、オフリンクソースからの全ての受信トラフィックに単一のキャッシュエントリを用いることができる。
【００１０】
新規のリモートＩＰアドレスからのリクエストが、経路キャッシュ内の新規のエントリの生成をもはや引き起こさない場合には、サーバが多数のソースＩＰアドレスからのリクエストを受信する際に、これらのリクエストが合法でもいたずらでも、これは経路キャッシュの殺到を阻止する。
【００１１】
これら並びに他の利点および特徴は、添付図面と関連して提供される本発明の実施形態の以下の詳細な説明により、より容易に理解される。
【００１２】
添付図面において、同様の構成要素には同じ番号が付される例示的な図面を参照する。
【図面の簡単な説明】
【００１３】
【図１】正常の経路キャッシュを実現する、第１のコンピュータの経路キャッシュの関連するエントリを示す、ルータを通じて通信する２つのネットワークノードを示す図である。
【図２】経路キャッシュを最適化するための本発明の実施形態を実行する、第１のコンピュータの経路キャッシュの関連するエントリを示す、ルータを通じて通信する２つのネットワークノードを示す図である。
【図３】経路キャッシュを最適化するための本発明の実施形態を実行する、ルータにおける経路キャッシュの関連するエントリを示す、ルータを通じて通信する２つのネットワークノードを示す図である。
【図４】正常の経路キャッシュを実施するネットワークノードにおける経路キャッシュからの抽出を示す図である。
【図５】経路キャッシュを最適化するための本発明の実施形態を実行する、ネットワークノードにおける経路キャッシュからの抽出を示す図である。
【図６】経路キャッシュを最適化するための本発明の実施形態を実行する、ルータにおける経路キャッシュからの抽出を示す図である。
【図７】複数の種々のリンクを介して接続された複数のネットワークノードを示す図である。ノード１、２、３、およびルータのネットワークインターフェース１が全て同じリンクに接続されており、それ故、互いの観点から見ると全てオンリンクノードである。
【図８】ルータを介してノード１からノード２に送信されたパケット、およびノード１におけるパケットに関連する経路キャッシュエントリを示す図である。本発明ではノードを実装しない。経路キャッシュエントリは生成されたものとして示される。
【図９】ルータを介してノード２からノード１に送信されたパケット、およびノード１におけるパケットに関連する経路キャッシュエントリを示す図である。本発明ではノードを実装しない。経路キャッシュエントリは生成されたものとして示される。
【図１０】ルータを介してノード１からノード２に送信されたパケット、およびノード１におけるパケットに関連する経路キャッシュエントリを示す図である。ノード１は本発明の実施形態を実行する。パケット伝送の結果、経路キャッシュエントリが全く生成されないため、共有のエントリのみが関連して示される。
【図１１】ルータを介してノード２からノード１に送信されたパケット、およびノード１におけるパケットに関連する経路キャッシュエントリを示す図である。ノード１は本発明の実施形態を実行する。パケット伝送の結果、経路キャッシュエントリが全く生成されないため、共有のエントリのみが関連して示される。
【発明を実施するための形態】
【００１４】
本発明の実施形態は、異なるＩＰアドレスを有する多数のネットワークパケットが、多数のオフリンクネットワークノードからサーバに送信される際に、経路キャッシュ（１１０）へのエントリの殺到を阻止するサーバ（７１１）またはルータ（７７１）において経路キャッシュを管理するための方法に関する。
【００１５】
本発明の一実施形態では、サーバ（７１１）は少なくとも１つの物理ネットワークインターフェース（７１２）を用いてイーサネット（登録商標）リンク（７０１）と接続する。このイーサネット（登録商標）リンクは、他のコンピュータおよびルータ（７７１）を含む複数のノードと接続されてもよく、これにより、ルータの援助がなくとも、サーバはイーサネット（登録商標）を通してこれらと直接に通信可能である。これらのノードはサーバに隣接するものまたはオンリンクノードとして周知である。他のノードはオフリンクノードと呼ばれる。図７に示すノード１（７１１）から見ると、ネットワークインターフェース１（７７３）を介してアクセスするノード２（７２１）、ノード ３（７３１）、およびルータ（７７１）は、これらがイーサネット（登録商標）リンク（７０１）上で直接アクセスされ得るため、オンリンクノードである。ノード４（７４１）、ノード５（７５１）、およびノード６（７６１）は、ルータ（７７１）を通じてのみアクセスすることができるため、オフリンクノードである。
【００１６】
サーバはインターネットプロトコル（ＩＰ）スタックを含み、これにより、オンリンク（７２１，７３１）およびオフリンクノード（７４１，７５１，７６１）の両方との通信が可能になる。少なくとも１つの物理ネットワークインターフェース（７１２）は、ＩＰアドレス（７１３）が割り当てられる。オンリンクノードと通信する場合には、パケット（１２０，１３０）はイーサネット（登録商標）リンク（７０１）を通して宛先ノードに直接送信される。オフリンクノードと通信する場合には、パケットは一旦オンリンクルータ（７７１）に送信されて、次に最終的な宛先に転送される。
【００１７】
サーバはそれが用いるエントリ（１１１０，１１２０，１１３０，１１４０）を含む経路キャッシュ（１１００）を維持し、特定のエントリ（１１１０）にマッチするＩＰパケット（１２０）の処理方法を決定する。
【００１８】
経路キャッシュ内のエントリ（１１１０）は、適合パケットの識別に関連するデータ、およびそれらの処理方法に関する命令を含む。パケットは、通常、ソースＩＰアドレス（１２１）、宛先ＩＰアドレス（１２２）、物理ネットワークインターフェース（７１２）へのポインタにより識別される。それ故、経路キャッシュエントリは、ソースアドレス（１１１１）および宛先アドレス（１１１２）を含む。オフリンクノードから受信した、またはそれに向かうパケットにおいては、エントリは通常、転送先（１１１４）の識別に用いられるルータＩＰアドレスを含む。ただし、キャッシュエントリは、識別目的および処理目的でより詳細な情報を含むことができる。
【００１９】
一部の例では、異なるプロトコルに対するパケットは異なって処理され、それ故、プロトコルごとにエントリがあってもよい。これは差別化サービスコードポイント（ＤＳＣＰ）に応じて差別化することができる。一実施形態では、優先順位の高いＤＳＣＰを有するパケットが単一のルータに転送される場合があり、優先順位の低いＤＳＣＰを有するパケットが第２のルータに転送される。
【００２０】
経路キャッシュエントリは、多くの場合に、ソケット状態に関する情報を含む。本明細書で使用される場合、「ソケット」は、ネットワーク内でそこに情報を伝送するか、またはそこから情報を伝達される、一意の識別とすることができる。例えば、ＲＦＣ１４７を参照されたい。エントリが伝送制御プロトコル（ＴＣＰ）における通信に関連する場合には、ソケット接続状態に関する情報を含んでもよい。
【００２１】
ソースおよび宛先ＩＰアドレスは、通常、ソースＩＰアドレスおよびＩＰパケットの宛先ノードを示す。ネットワークインターフェースに対するポインタは、どのネットワークインターフェースがエントリに関連するかを識別する。ルータＩＰアドレスは、通常、エントリにマッチするトラフィックの取り扱いに関与するルータを示す。
【００２２】
本発明の一実施形態では、サーバと隣接するものとの間のトラフィックに関連するエントリは、ソースおよび宛先ＩＰアドレスを含む。サーバからノードへのトラフィックに関連して使用されるエントリは、ソースＩＰアドレスとしてサーバのＩＰアドレス、および宛先ＩＰアドレスとしてノードのＩＰアドレスを有することになる。これらのアドレスはノードからサーバへのトラフィックに関連するエントリと交換される。
【００２３】
サーバがパケットを処理する必要がある場合には、パケットの関連する特性にマッチする、経路キャッシュにおけるエントリを検索してもよい。
【００２４】
一実施形態では、この検索は少なくともパケットソースアドレスおよびパケット宛先アドレスに基づいてハッシュ値を算出することにより実行される。ハッシュ値は、プロトコルタイプ、サービスタイプ、差別化サービスコードポイント、または任意の他のパケット特性を含む他の特性に基づいてもよい。続いて、経路キャッシュは、ハッシュ値にマッチするエントリを検索する。
【００２５】
本発明の実施形態に従う、サーバとオフリンクノードとの間のトラフィックに関するエントリは、ソースＩＰアドレスまたは宛先ＩＰアドレスの両方ではなくいずれかにより生成することができる。具体的には、オフリンクノードからサーバへのトラフィックに関連して使用されるエントリ（１１４０）は、物理ネットワークインターフェースのＩＰアドレスと同じ宛先アドレスを含むことができるが、有効なソースＩＰアドレスを含まない。他方、他の方向（サーバからオフリンク宛先）に向かうトラフィックに関連して使用されるエントリ（１１３０）は、物理ネットワークインターフェースのＩＰアドレスと同じソースアドレスを含むことができるが、有効な宛先ＩＰアドレスではない。複数の異なるオフリンクノードからサーバに流れるトラフィックに対して単一のエントリ（１１４０）を用いることができる一方で、サーバから複数の異なるオフリンクノードに流れるトラフィックに対しては別の単一のエントリ（１１３０）を用いることができる。
【００２６】
これは多くのサーバにおいて、特定の物理ネットワークインターフェースからオフリンクノードに向かう全てのパケットが同様に処理され得るため可能であり、それ故、これらのパケットの取り扱い方法に関する情報を記憶するためには、経路キャッシュにおいて単一の共有のエントリを用いれば十分である。同様に、オフリンクノードから特定の物理ネットワークインターフェースへのパケットは同じ方法で取り扱うことができる。本発明の一実施形態では、オフリンクパケットに関する全てのエントリは、２つの共有のエントリ、すなわち、送信トラフィックと受信トラフィックとに置換される。
【００２７】
経路キャッシュの構造に応じて、ソースまたは宛先ＩＰアドレスの欠如は異なるように示されてもよい。一実施形態では、これはＩＰアドレスの欠如（０．０．０．０）に対して値０を用いて示されてもよい。別の実施形態では、このようなアドレスの欠如を示すフラグであってもよい。換言すれば、このエントリは特定のオフリンクノードに関係する必要はなく、本発明に含まれる複数の方法により達成することができることを当業者は理解するであろう。前述の例は例示を意味するものであり、網羅するものではない。
【００２８】
全てのオフリンクトラフィックを同じ様に取り扱うことは、しばしば適切ではない。一部のトラフィックは優先順位が高い場合があり、それ故、別個のルータに導かれるべきである。別の実施形態では、異なるプロトコルに関連するトラフィックは異なる経路をとるべきである。ドメイン名システム（ＤＮＳ）サーバは、通常、ユーザデータグラムプロトコル（ＵＤＰ）におけるリクエストを受信し、かつそれに応答し、単一のルータを用いてこのプロトコルにおける全てのトラフィックを処理し、かつ異なるルータを用いて他のプロトコルにおける全てのトラフィックを処理することが適切である場合がある。
【００２９】
本発明の実施形態では、それ故、オフリンク送信トラフィックに関連する複数の共有の経路キャッシュエントリと、オフリンク受信トラフィックに関連する複数の共有の経路キャッシュエントリとが存在することができる。送信エントリ各々は異なるプロトコルに用いることができ、それ故、適合パケットに対する種々のパラメータと、処理パケットに対する種々のパラメータとを含む。特定のインターフェースにおける送信トラフィックに関する全てのエントリは、ソースアドレスとして物理インターフェースのＩＰアドレスを有するが、宛先アドレスを含まないパケットにマッチする。各エントリは種々のプロトコルに関連するパケットにマッチする。
【００３０】
特定の共有のエントリにマッチするパケットを指定する多くの方法がある。本発明が前述のパラメータに限定されないことを当業者は理解する。また、各パケットに正確にマッチする固定された一組のパラメータを用いることに限定されない。単純な論理機能を含む、より複雑な規則を用いることもできる。
【００３１】
オンリンクノードから受信したパケットを処理する際、またはオフリンクノードからのパケットを処理する際に、サーバはそれぞれのパケットに関連する特性にマッチする、経路キャッシュにおけるエントリを検索する。
【００３２】
一実施形態では、この検索は少なくともパケットソースアドレスおよびパケット宛先アドレスに基づいてハッシュ値を算出することにより実行される。ハッシュ値を算出する際に、パケットソースアドレスにマッチする、経路キャッシュにおけるエントリが無い場合では、ソースアドレスはアドレス０．０．０．０によって置換することができ、続いて、経路キャッシュは、マッチするハッシュ値をともなうエントリが検索される。関連するエントリがアドレス０．０．０．０を含まない場合には、ハッシュは種々のまたは動的な１組のパラメータに基づくことができ、そうでなければ別の方法で検索が実行されなければならない。
【００３３】
一実施形態では、オフリンクノードからのパケットが受信されたことをサーバは検出し、マッチするエントリに関する経路キャッシュを検索する際に、特別な検索手段を起動する。例えば、ネットワークの混雑度が低い期間に所与の１組のパラメータを有するパケットが処理される場合には、パケットは第１の経路キャッシュエントリにマッチする。一方、ネットワークの混雑が高い期間にパケットが処理される場合には、パケットは第２の異なる経路キャッシュエントリにマッチすることができる。任意の適切な外部または他のデータ（例えば、地理位置、時刻、他のパケットの処理履歴など）を、マッチする経路キャッシュエントリの選択に用いることができる。
【００３４】
本発明は、多数のＩＰアドレスを用いてリクエストを送信するハッカ、または多数の偽のオフリンクＩＰアドレスを用いてリクエストを送信するハッカからサーバを保護する。多数のオンリンクアドレスから多数のリクエストを受信する際に、サーバはオンリンクアドレスについての正常のキャッシング方法をなおも利用するため、キャッシュの殺到に対して弱い。オンリンクＩＰアドレスの数は、その一部にノードを含むサブネットの大きさに応じて制限される。本発明がエンドノードにおいて実施される場合には、攻撃されたものが経路キャッシュに加えさせることができるエントリの数は、サブネットの大きさの倍数に制限される。それは通常、サブネットの大きさの２倍である。ハッカは多数のオンリンクアドレスを偽造することにより、この脆弱性に付け込むことができる。このような攻撃から保護するために、本発明の実施形態に従い、経路キャッシュにエントリを生成する前に、偽のオンリンクアドレスを有するパケットを捨てるための測定を実施することができる。
【００３５】
本発明の実施形態では、共有のエントリにより処理されるルータ取り扱いトラフィックは、サーバにパケットを転送する前に、各パケットを検査し、それに偽のオンリンクＩＰアドレスが含まれていないか否かを確認することができる。別の実施形態では、サーバにこのような検証を実行する機能性を実装することができる。
【００３６】
本発明の一実施形態では、物理インターフェースにおいて受信された一部のパケットがサーバ自体には向かわずに、別のノードに転送されるべきである。これは例えば、本発明がルータに実装される場合である。
【００３７】
オフリンクノードとオンリンクノードとの間のルータ処理トラフィックは、複数の異なる宛先ＩＰアドレスおよび複数の異なるソースＩＰアドレスを有するパケットを受信することができる。これらのパケットの全て、またはこれらのパケットのサブセットを同様に取り扱うことは、適切であるかもしれない。続いて、これらのパケットの全てまたは一部にマッチする共有のエントリを用いることができる。
【００３８】
本発明の一実施形態では、同様に取り扱われる全てのパケットが、ソースアドレスまたは宛先アドレスを共有しない。それ故、共有のエントリについてのマッチング基準には、パケットのソースまたは宛先ＩＰアドレスが特定のアドレスにマッチするか否かのチェックは含まれない。
【００３９】
本発明の別の実施形態では、ルータにおける経路キャッシュのエントリは、最終的な宛先ではなく、パケットの次の転送先のソースまたは宛先アドレスを含む。これにより、他のパラメータではなく、そのソースまたは宛先アドレスに基づいて経路キャッシュエントリにマッチさせることができる。
【００４０】
本発明の実施形態では、ルータは少なくとも１つの物理ネットワークインターフェースを用いて、第１のネットワークリンクに接続する。このイーサネット（登録商標）リンクは、他のルータおよびコンピュータを含む複数のノードと接続してもよく、このルータはイーサネット（登録商標）上でこれらと直接通信することができる。ルータは第２のネットワークリンクにも接続する。第２のネットワークリンクは他のルータおよびコンピュータを含む複数のノードにも接続されてもよい。３つ以上のネットワークリンクが存在してもよい。ネットワークリンクは、イーサネット（登録商標）リンク、フレームリレーリンク、トークンリングリンク、または他の種類のネットワークリンクであってもよい。リンク（複数）は同じ種類である必要はない。ルータは、ホストをこれらのリンク上でＯＳＩ層２にアドレス指定することができる場合がある。
【００４１】
ルータは第１のネットワークリンク上の第１のノードからＩＰパケットを受信し、かつ第２のネットワークリンク上の第２のノードに受信したパケットを転送することができる。第１および第２のネットワークリンクは同じリンクでもよい。
【００４２】
本発明の一実施形態では、ルータは（ローカルリンクとして周知の）イーサネット（登録商標）リンクおよび（インターネットリンクとして周知の）フレームリレーリンクである第１のネットワークリンクに接続する。
【００４３】
ルータは、それ自体がオンリンクおよびオフリンクノードの両方と通信することを可能にする、インターネットプロトコル（ＩＰ）スタックを含む。ＩＰアドレスには少なくとも１つの物理ネットワークインターフェースが割り当てられる。ローカルリンクに関連するオンリンクであるノードにパケットを送信、かつそれからパケットを受信する場合には、パケットはイーサネット（登録商標）リンク上で直接宛先ノードに送信される。オフリンクノードと通信する場合には、インターネットリンクに関してオンリンクであるノードにパケットが送信される。このノードは、最終的な宛先でもよいし、最終的な宛先にパケットを転送する別のルータでもよい。
【００４４】
ルータはそれ自体に用いられるエントリを含む経路キャッシュを維持し、これにより、特定のエントリにマッチするＩＰパケットの処理方法を決定する。
【００４５】
パケットは、通常、ソースＩＰアドレス、宛先ＩＰアドレス、ソース物理ネットワークインターフェースに対するポインタ、および宛先物理ネットワークインターフェースに対するポインタにより識別される。
【００４６】
一部の例では、プロトコルが異なるパケットは、異なるように処理されるべきであり、それ故、プロトコルごとのエントリが存在してもよい。これはＤＳＣＰに応じて異なることも可能である。一実施形態では、優先順位の高いＤＳＣＰを有するパケットが単一のルータに転送されてもよく、優先順位の低いＤＳＣＰを有するパケットが第２のルータに転送されてもよい。ＤＳＣＰが異なるパケットは、ルータにより異なる優先順位で処理されてもよい。一実施形態では、転送待ちである、優先順位がより高いＤＳＣＰであるパケットが他に無くなるまで、特定のＤＳＣＰを有する全てのパケットは引き止められる。
【００４７】
一実施形態では、ルータは２つのネットワークノード間のソケットの状態に関する情報を維持する。経路キャッシュエントリが伝送制御プロトコル（ＴＣＰ）における通信に関連する場合には、それはソケット接続状態に関する情報を含む場合がある。
【００４８】
ソースおよび宛先ＩＰアドレスは、通常、ソースＩＰアドレスおよびＩＰパケットの宛先ノードを意味する。本発明がルータに実装される場合には、多くのパケットについて、これらのアドレスのどれも、ルータにおける物理インターフェースに割り当てられたアドレスにマッチしない。ソースおよび宛先ネットワークインターフェースに対するポインタは、どのネットワークインターフェースがエントリに関連するかを識別する。
【００４９】
本発明の一実施形態では、インターネットリンク上で達することが可能なノード（インターネットノード）と、ローカルリンク上で達することが可能なノード（ローカルノード）との間のトラフィックに関連するエントリは、ソースおよび宛先ＩＰアドレスを含む。インターネットからノードへのトラフィックに関連して利用されるエントリは、ソースＩＰアドレスとしてインターネットノードのＩＰアドレス、および宛先ＩＰアドレスとしてローカルノードのＩＰアドレスを含む。これらのアドレスは、ローカルノードからインターネットノードへのトラフィックに関連するエントリに対して入れ替えられる。
【００５０】
パケットを処理する必要がある場合には、ルータは、パケットに関連する特性にマッチする、経路キャッシュにおけるエントリを検索する場合がある。
【００５１】
一実施形態では、この検索は少なくともパケットソースアドレスおよびパケット宛先アドレスに基づいてハッシュ値を算出することにより実行される。ハッシュ値は、プロトコルタイプ、サービスタイプ、差別化サービスコードポイント、または任意の他のパケット特性を含む他の特性に基づいた値でもよい。続いて、経路キャッシュはマッチするハッシュ値をともなうエントリを検索される。
【００５２】
本発明の実施形態に従い、インターネットノードとローカルノードとの間のトラフィックに関連するエントリは、ソースＩＰアドレスまたは宛先ＩＰアドレスのどちらも無くても生成することができる。具体的には、インターネットノードからローカルノードへのトラフィックに関連して利用されるエントリは、ソースＩＰアドレスまたは宛先ＩＰアドレスのどちらも含まなくてもよいが、インターネットインターフェースからのトラフィックのためにのみエントリが用いられるように、かつ特定の範囲内の宛先アドレスをともなって、マークされる可能性がある。一方、他の方向（ローカルノードからインターネットノード）に向かうトラフィックに関連して使用されるエントリは、ローカルインターフェースからのトラフィックに関連してのみエントリが用いられるように、かつ特定の範囲内の宛先アドレスをともなって、マークされる可能性がある。どの共有のエントリを用いるかを決定するために、特定のパケットに対する転送先アドレスを用いることもできる。複数の異なるインターネットノードから複数の異なるローカルノードへ流れるトラフィックに対して、単一のエントリを用いることもでき、一方、複数の異なるローカルノードから複数の異なるインターネットノードへ流れるトラフィックに対して、別の単一のエントリを用いることもできる。
【００５３】
多くのルータ上で、インターネットノードに向かう、特定の物理ネットワークインターフェースにおいて受信された全てのパケットを同じように処理することができるため、これは可能であり、そしてそれ故、これらのパケットの処理方法に関する情報を記憶するためには、経路キャッシュにおいて単一の共有のエントリを用いれば十分である。本発明の一実施形態では、インターネットパケットに関連する全てのエントリは、２つの共有のエントリ、すなわちインターネットノードで生成され、ローカルノードに向かうトラフィックに対するエントリと、ローカルノードで生成され、インターネットノードに向かうトラフィックに対するエントリとによって置換される。
【００５４】
経路キャッシュの構造に応じて、ソースおよび宛先ＩＰアドレスの両方の欠如はことなるように示されてもよい。一実施形態では、これはＩＰアドレスの欠如（０．０．０．０）に対する値０を用いて示される場合がある。別の実施形態では、このようなアドレスの欠如を示すフラグが存在してもよい。換言すれば、このエントリは特定のオフリンクノードに関係する必要はなく、本発明に含まれる複数の方法により達成され得ることを当業者は理解する。前述の例は例示を意図するものであり、網羅的なものではない。
【００５５】
本発明がルータに実装される場合には、特定の所定の値にマッチするパケットの特定の特性の識別よりも、パケットのマッチングに対してより複雑な方法を用いる必要が生じることがある。特定の共有のエントリにマッチするパケットを指定する多くの方法がある。本発明が前述のパラメータに限定されないことを当業者は理解するであろう。一実施形態では、どのパケットがエントリにマッチするかの決定に外部ファクタが用いられる。例えば、マッチングはネットワーク状態またはＩＰアドレスの地理的位置に基づいて決定することができる。
【００５６】
本発明の実施形態は、負荷分散装置の経路キャッシュを最適化する。負荷分散装置は、複数の処理ノードのうちの１つにおいて受信されたパケットを転送することができる。負荷分散装置は、特定の処理ノードへの、またはそこからの全てのトラフィックに関連する１つ以上の共有のエントリを利用してもよい。
【００５７】
本発明を例示の実施形態を参照して記述してきたが、本発明の範囲から逸脱することなく、種々の変形がなされてもよく、その要素を均等物で代用してもよいことは、当業者によって理解されるであろう。さらに、その本質的な範囲から逸脱することなく、本発明の教示に対して、特定の状況または材料に適応するような多くの変形がなされてもよい。それ故、本発明は、本発明を実行することが意図された最良の形態または唯一の形態として開示された特定の実施形態に限定されないが、しかし本発明は、添付請求項の範囲に収まる全ての実施形態を含むように意図される。また、図面および説明において、本発明の例示の実施形態を開示し、そこでは特定の用語が用いられる場合があるが、別途述べられない限り、単に標準的かつ字義通りのみの用語であり、制限を目的とするものではなく、それ故、本発明の範囲はこれにより限定されない。さらに、「第１」、「第２」などの用語の使用は、いかなる順序または重要性を示すものではなく、それらはむしろ、１つの要素と他の要素とを区別するために用いられる。さらに、「１つ（ａ、ａｎ）」などの用語の使用は数量の制限を示すものではなく、むしろ参照される項目が「少なくとも１つ」あることを示す。
【符号の説明】
【００５８】
７１１  ノード１
７１２  ネットワークインターフェース
７１３  ＩＰアドレス
７２１  ノード２
７３１  ノード３
７４１  ノード４
７５１  ノード５
７６１  ノード６
７７１  ルータ
７７２  ネットワークインターフェース２
７７３  ネットワークインターフェース１
【図１】
2013503572.tif 000003
【図２】
2013503572.tif 000004
【図３】
2013503572.tif 000005
【図４】
2013503572.tif 000006
【図５】
2013503572.tif 000007
【図６】
2013503572.tif 000008
【図７】
2013503572.tif 000009
【図８】
2013503572.tif 000010
【図９】
2013503572.tif 000011
【図１０】
2013503572.tif 000012
【図１１】
2013503572.tif 000013
【国際調査報告】
2013503572.tif 000014