JP4764930B2 - 分散サービス妨害（ＤＤｏＳ）攻撃防御のための、挙動ベースのトラフィック識別（ＢＴＤ） - Google Patents

Description

本発明は、分散サービス妨害（ＤＤｏＳ）攻撃防御のための、挙動ベースのトラフィック識別（ＢＴＤ）に関する。

ｅビジネスアプリケーションやミッションクリティカルな軍事通信の普及によって、インターネット上のネットワークセキュリティが深刻に懸念されている。致命的なサービス妨害（ＤｏＳ）攻撃や、その進化形である分散ＤｏＳ（ＤＤｏＳ）攻撃の出現により、我々のインターネットの利用やインターネットへの信頼が迷惑にも侵害されている。Ｙａｈｏｏ、ＣＮＮ、Ｅｂａｙ、及びＡｍａｚｏｎといった知名度の高いサイトにおいてでさえ、ＤｏＳ／ＤＤｏＳ攻撃の悪影響が何度も生じている。

ＤＤｏＳ攻撃において、アタッカーは被害者に大量の悪質なトラフィックを送信する。例えば、ＤＤｏＳアタッカーは、インターネットに接続されたコンピュータシステムを介して、様々なデータセンターにおける１つ又は複数のコンピュータに侵入することもある。多くの場合、アタッカーはインターネットサービスプロバイダ（ＩＳＰ）を介してインターネットにアクセスするだろう。その後、アタッカーは、悪質なソフトウェアプログラムを用いてデータセンターの複数のコンピュータを制御下に置くことができる。アタッカーがコマンドを出すと、これらのコンピュータは様々なタイミングで大量のデータを一斉に被害者に送信できるため、被害者は正規のインターネットトラフィックやメッセージに応答できなくなってしまう。

現在、ＤＤｏＳ攻撃はインターネットの世界において最も恐ろしい脅威であろう。ＤＤｏＳ攻撃は、一見正常に見えるが実際には無用なパケットを送信することで、利用の限られたシステムリソースを悪用し、且つ消費して、被害者側のシステムを劣化／崩壊させるため、被害者側のシステムによる通常のクライアントサービスは著しく妨害される。典型的には、ネットワーク帯域幅、ターゲットホストのＣＰＵサイクル、及び、フラグメンテーションバッファやＴＣＰ ＳＹＮバッファ等の特定のＴＣＰ／ＩＰプロトコルスタック構造といったリソースがＤｏＳ／ＤＤｏＳ攻撃によって使い果たされてしまう。更に、容易にアクセス可能な攻撃スクリプトがインターネット上に氾濫しているため、ＤＤｏＳ攻撃を仕掛ける技術的ハードルは著しく下げられている。また、インターネットにおいてはアカウンティングが不十分であるため、クラッカーは、後でペナルティを課されることを全く心配することもなく、他者を攻撃してみようという気になってしまう。

ＤＤｏＳ攻撃は、仕掛けるのは比較的簡単だが、防御するのは難しいことがよく知られている。その根本的な理由として、（１）ＩＰスプーフィング（即ち、攻撃パケットは通常偽造された送信元ＩＰアドレスを有する。これによって、攻撃発信元の身元が効果的に隠され、検出、防御、追跡といった取り組みが阻まれてしまう）；（２）ＤＤｏＳ攻撃の分散性（即ち、膨大な数の送信元が攻撃トラフィックを一斉に発生させることで、攻撃がますます強力化していき、その攻撃に対処するためスケーラビリティの問題が生じることになるので、対応策に過大な負担がかかる）；及び（３）被害者が正常パケットと致命的な攻撃トラフィックとを容易に区別できるメカニズムが存在しないこと等が挙げられる。

以上より、ＤＤｏＳ攻撃を防御することでネットワークやホスト（特にサーバー）の持続可能性を向上させることは、当該技術分野における重要な目標である。ＤＤｏＳ防御における重要な問題は、如何にして攻撃トラフィックを正常トラフィックから分離するかということである。この問題は「トラフィック識別（ｔｒａｆｆｉｃ ｄｉｆｆｅｒｅｎｔｉａｔｉｏｎ）」と呼ばれ、極めて重要である。なぜなら、ＤＤｏＳ攻撃は、ターゲットホスト及びネットワークの性能を著しく劣化させることを、又は被害者からその正規クライアントへのサービス提供能力を完全に奪うことさえも目的としているからである。どれが「攻撃的」トラフィックで、どれが「正常な」トラフィックであるかを把握できれば、被害者は、トラフィックの種類（即ち、攻撃的なものか又は正常なものか）に従い対応を変えることによって、ＤＤｏＳ攻撃を阻止できるようになる。

更に、ＤＤｏＳ攻撃パターンの多様性を考えると、如何にしてできるだけ多くのＤＤｏＳ攻撃パターンを抑制するかがもう一つ重要な問題となる。ＤＤｏＳ攻撃パターンの例は、非特許文献１及び２に記載されている。

プロトコルの悪用という観点から見れば、ＤＤｏＳ攻撃はＴＣＰ、ＵＤＰ、ＩＣＭＰ、又はその他のプロトコルに基づいている。以下の表１に示すように、異なるプロトコルを組み合わせた攻撃もある。攻撃レートの観点から言えば、攻撃の多くは高速フラッドベースの攻撃であるが、非特許文献３及び４に記載されているような、新規のより巧妙な攻撃である低レートＤＤｏＳ攻撃もある。

残念ながら、攻撃方式とは対照的に、防御方式はＤＤｏＳ攻撃の進化に追い付いていない。背景技術であるＤＤｏＳ防御方式の多くは、１種又は２種のＤＤｏＳ攻撃に対処するものであり、考え得る広範なＤＤｏＳ攻撃パターンに対しては不十分であり、効果がない。
Ｃ．Ｄｏｕｌｉｇｅｒｉｓ ａｎｄ Ａ．Ｍｉｔｒｏｋｏｔｓａ，"ＤＤｏＳ ａｔｔａｃｋｓ ａｎｄ ｄｅｆｅｎｓｅ ｍｅｃｈａｎｉｓｍｓ：ｃｌａｓｓｉｆｉｃａｔｉｏｎ ａｎｄ ｓｔａｔｅ−ｏｆ−ｔｈｅ−ａｒｔ，"Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋｓ，ｖｏｌ．４４，ｐｐ．６４３−６６６，２００４ Ｊ．Ｍｉｒｋｏｖｉｃ ａｎｄ Ｐ．Ｒｅｉｈｅｒ，"Ａ ｔａｘｏｎｏｍｙ ｏｆ ＤＤｏＳ ａｔｔａｃｋ ａｎｄ ＤＤｏＳ ｄｅｆｅｎｓｅ ｍｅｃｈａｎｉｓｍｓ，"ＡＣＭ ＳＩＧＣＯＭＭ Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｒｅｖｉｅｗ，ｖｏｌ．３４，ｎｏ．２，ｐｐ．３９−５３，Ａｐｒ．２００４ Ｒ．Ｃｈａｎｇ，"Ｄｅｆｅｎｄｉｎｇ ａｇａｉｎｓｔ ｆｌｏｏｄｉｎｇ−ｂａｓｅｄ，Ｄｉｓｔｒｉｂｕｔｅｄ Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ ａｔｔａｃｋｓ：ａ ｔｕｔｏｒｉａｌ，"ＩＥＥＥ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｍａｇａｚｉｎｅ，ｖｏｌ．４０，ｎｏ．１０，ｐｐ．４２−５１，２００２ Ａ．Ｋｕｚｍａｎｏｖｉｃ ａｎｄ Ｅ．ｋｎｉｇｈｔｌｙ，"Ｌｏｗ−Ｒａｔｅ ＴＣＰ−Ｔａｒｇｅｔｅｄ Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ Ａｔｔａｃｋｓ（Ｔｈｅ Ｓｈｒｅｗ ｖｓ．ｔｈｅ Ｍｉｃｅ ａｎｄ Ｅｌｅｐｈａｎｔｓ），"ＡＣＭ ＳＩＧＣＯＭＭ ２００３，Ａｕｇ．２００３，ｐｐ．７５−８６

実施形態は、背景技術が直面する上記問題、及びその他の問題を克服することを目的とする。特に、挙動ベースのトラフィック識別（ＢＴＤ）の実施形態は、悪質な攻撃トラフィックの大半をプロアクティブに特定且つ阻止し、更に様々なＤＤｏＳ攻撃パターンに対処する新規なフレームワークを提供する。当該フレームワークにおける２つの構成要素は、トラフィック分類及びトラフィック識別である。トラフィック分類は非ＴＣＰフラッド攻撃に対処することを目的とし、トラフィック識別は悪質なＴＣＰフローを特定するのに使用される。ＢＴＤの実施形態は、例えばｎｓ−２で実装されてもよいが、これに限定されることはない。実験結果から、トラフィック分類によりＴＣＰトラフィックのスループットは著しく向上し（即ち、７０％を上回る）、トラフィック識別により悪質な攻撃トラフィックは速やかにブロックされることが示される。ＢＴＤの当該実施形態が有するその他の有益性としては、以下に限定されないが、（１）機器／システムの変更が最小限で済むこと；（２）実用的に配備できること；（３）受信側にのみ配備すればよいのでスケーラビリティの問題が起こらないこと；及び（４）本方式における配備は当該ネットワーク及びホストを保護するためにのみ使用され、他のものは対象外であるので、インセンティブ欠如の問題がないこと等が挙げられる。

ＢＴＤの実施形態は、攻撃トラフィックを分離し、できるだけ多くのＤＤｏＳ攻撃方式を抑制しようとするものである。ＤＤｏＳ攻撃はリソース管理の問題であるので、実施形態はＱｏＳ手法を採用してＤＤｏＳ攻撃に対抗する。ＢＴＤの実施形態は、背景技術のように１種か２種の攻撃方式だけではなく、様々なＤＤｏＳ攻撃方式を効率的且つ効果的に抑制する統合された方式を用いる。ＢＴＤの実施形態は、悪質な攻撃トラフィックと正常トラフィックとを識別可能であり、悪質な攻撃トラフィックにペナルティを課すことが可能である。ＢＴＤの実施形態は少なくとも２つの構成要素からなる。第１の構成要素は、使用されたプロトコルに基づいて各種トラフィックを分類し、それらのレートを帯域幅割り当てによって適宜制限する。この方法は、ＵＤＰ、ＩＣＭＰ、及びその他のトラフィックをＴＣＰから分離するためのものであり、帯域幅割り当てを非ＴＣＰトラフィックに制限することにより、ＵＤＰ及びＩＣＭＰに基づく幾らかのフラッド攻撃を軽減する上で有用である。

ＴＣＰはインターネット上の主要トラフィックであり、ほとんどのＤＤｏＳ攻撃はＴＣＰに基づいている。従って、次のステップでは、本質的に異なるＴＣＰトラフィックを識別する。全てのＴＣＰトラフィックは接続確立の状態によって２つのグループに分けられる。接続が確立している全てのＴＣＰトラフィックについて、ＢＴＤの実施形態は、フローの特性、即ち良性か悪性かを、その挙動に従って特定しようとする。同じ接続の他方のエンドポイントの制御信号に対して適切に応答すれば、フローは「良性」即ち「正常」であると定められる。これに対し、「悪性」即ち「攻撃」フローは、ＴＣＰ輻輳制御の原則に従わず、攻撃的に振る舞う。

ＴＣＰに不都合なフローを致命的フローとして分類し、ＢＴＤ方式の実施形態によりペナルティを課す可能性もある。即ち、ＢＴＤの実施形態には、目下、ＴＣＰに不都合なフローと攻撃フローとを区別しないという副次的作用がある。区別に基づき、不都合なフローのうち攻撃性のあるフローに対して所定のペナルティが課される。

更に、ＢＴＤの実施形態は「被害者中心」であり、送信元エンドポイント又は中間ルータの変更を全く必要としない。このようなＢＴＤの特性により、スケーラビリティ、各ドメイン間の協調、及びインセンティブ欠如といった問題が回避される。広範なシミュレーションが実施され、ＢＴＤの実施形態の設計が有効であることを実証する実験結果がもたらされている。

防御方式としては、攻撃フローと正常フローとを区別し、それに応じて有害なトラフィックを分離できることが理想的であろう。しかしながら、そのような区別を行うのは決して簡単ではない。ＢＴＤの実施形態では、悪質な攻撃トラフィックをその挙動により特定する。ＤＤｏＳトラフィックに顕著な特徴／挙動としては、ＩＰスプーフィングの他に攻撃性が挙げられる。攻撃的挙動の一例として、攻撃発信元が被害者からの応答の受信の有無に関して反応しないという点がある。そのような場合、アタッカーは、応答受信の有無に関係なく、ターゲットに途方もない量の無用なパケットを殺到させて、引き続き攻撃を実行し得る。図１に示されるような、オン−オフモデルを用いて散発的に攻撃パケットを仕掛ける低レートＤｏＳ攻撃でさえ、「オン」の段階中にはそのような攻撃的特徴を示す。

「攻撃性」は、「高レート」と等価ではないことに留意されたい。高レートフローが正常なＴＣＰフローである可能性もある。受信者が、受信者からの所定の制御信号に対して送信元がどのように応答するかを意図的にテストすることで、攻撃的挙動を特定できることがある。そのようなテストに失敗する送信元を致命的な攻撃発信元と見なして、その送信元にペナルティを課すことができる。

しかしながら、上記テストに合格する送信元が良性であるとは限らない。受信者（通常はサーバー）は、接続のリクエスト／要求を受信した際には必ず上記テストを実施するよう促される。即ち、巧妙なアタッカーは、最初は正常に挙動して初めのテストに合格し、後に有害な攻撃動作を実行するかもしれない。このような状況に対処するため、受信者は、攻撃フローを検出するのに使用される上記テストの頻度を高めてもよい。別の解決策として、テストに動力学を幾らか導入し、各フロー、特に高レートフローに対するテストの頻度及び間隔をランダムに決定することも挙げられる。

高レートの正規トラフィックに更に適切に対応するために、フローが合格したテストの最大回数を規定する閾値が設定される。フローが特定回数のテストに合格したら、そのフローからのパケットにはそれ以上テストは行われない。送信元を積極的にテストすることにより、受信者は、その送信元からのフローの特性（即ち、正常か、又は攻撃か）に対して信頼性の高い判定を行い、それに応じて対応することができる。

挙動ベースのフィルタリングによって攻撃発信元はジレンマに陥り、（１）特定され且つペナルティを受ける危険性があってもパケットを強引に送信するか、又は（２）受信者の要求に応じるように攻撃レートを下げるので、攻撃の効力が減退する。攻撃発信元にこのようなジレンマを起こさせる中で、ＢＴＤの実施形態により、受信者は起こり得る攻撃の範囲及び影響を抑制することができる。

上記設計はＴＣＰでのみ実施可能であるが、それは、ＴＣＰが輻輳制御と信頼性のある送信メカニズムとを備えているためである。ＴＣＰはインターネット上の主要トラフィックであり、ＤＤｏＳトラフィックの９０％程がＴＣＰを扱うものであることに留意されたい。一般的に、ＴＣＰはフロー数で言えば８０％を占め、パケット数で言えば９０％を占める。従って、ＤＤｏＳ防御方式において、ＴＣＰトラフィックに効果的且つ効率的に対応することが必須である。

しかしながら、ＵＤＰやＩＣＭＰ等の他のトラフィックには、本発明のフレームワークが利用可能な代替メカニズムがない。ＢＴＤの実施形態は、トラフィック分類によって、非ＴＣＰトラフィックを処理する。トラフィック分類は、ＵＤＰ及びＩＣＭＰに基づくフラッド攻撃を処理する上で単純で且つ効率的な解決策である。ＵＤＰ及びＩＣＭＰトラフィックに割り当てられるリソースを制限することにより、受信者がＵＤＰ及びＩＣＭＰフラッド攻撃を著しく軽減できる場合もある。

トラフィック分類の別の利点として、ＵＤＰトラフィックがＴＣＰトラフィックよりはるかに攻撃的である点も挙げられる。ＵＤＰトラフィックがＴＣＰトラフィックと帯域幅を競合する場合、ＵＤＰが、任意の輻輳制御メカニズムを持たないこと、及び、より攻撃的な特性を持つことから、使用可能な帯域幅のほとんどを獲得可能であるということが十分に立証されている。従って、ＵＤＰトラフィックを送信すると、ＴＣＰトラフィックから帯域幅の公平な割り当て分を効果的に奪い取り、ＴＣＰストリームのパフォーマンスを劣化させてしまう場合がある。よって、ＵＤＰはＤＤｏＳ攻撃にとって優れた手段であることが分かる。これは、様々な種類のＤＤｏＳ攻撃パターンを１種の方式で抑制することの難しさを示しており、更にトラフィック分類を実施する必要があることを理由づけるものである。

その他の考慮すべき問題として、以下に限定されるわけではないが、（１）ＩＰスプーフィングに対処する方法、及び（２）実施形態のフレームワークがどのレベルで実行されるべきかを判定する方法（例えば、パケットレベル又はフローレベル）が挙げられる。まず、偽造された送信元ＩＰアドレスを持つ攻撃トラフィックを特定し、次に、本物のＩＰアドレスを持つ正常トラフィックを、それらの挙動を観察することにより見分ける。スプーフィングは、検証（ｖｅｒｉｆｉｃａｔｉｏｎ）によって対処できることがあり、攻撃的挙動は、ＴＣＰトラフィックの受信側で返信ＡＣＫのレートを操作することによって特定できることがある。この方法で、より微妙且つ巧妙な低レートＤＤｏＳ攻撃も特定することができる。

図２は、ＢＴＤフレームワークの実施形態のフローチャート例を示す。図２のステップ２．１において、入力パケット（ｉｎｃｏｍｉｎｇ ｐａｃｋｅｔｓ）は、ＢＴＤフレームワークに受信される。ステップ２．２において、トラフィック分類方法が実行される。ステップ２．３において、帯域幅分割／割り当て方法が実行される。ステップ２．４において、ＴＣＰ接続が確立されているか否か判定される。ＴＣＰ接続が確立されていなければ、ステップ２．５において、レート制限、ハーフオープン（ｈａｌｆ−ｏｐｅｎ）接続における待ち時間短縮、及びバックログキューサイズのインクリメントのうち少なくとも１つが実行される。また、ＴＣＰ接続が確立されていれば、ステップ２．６において、トラフィック識別方法が実行される。

トラフィック識別方法の結果、ステップ２．７（ａ）及びステップ２．７（ｂ）において、パケットが正常トラフィックであるか、又は攻撃トラフィックであるかが判定される。ステップ２．７（ａ）において正常トラフィックが受信されていると判定されると、ステップ２．８（ａ）において、受信パケットはＢＴＤフレームワークによって許可される。あるいは、ステップ２．７（ｂ）において攻撃トラフィックが受信されていると判定されると、ステップ２．８（ｂ）において、受信パケットはＢＴＤフレームワークによって破棄され、侵入は拒否される。様々な送信元からの膨大な量のパケットを取り扱うことで重い負荷がかかる受信者（例えばサーバー）のために、ＢＴＤの実施形態は、入力パケットを許可するか破棄するかを迅速且つ賢明に判断しよう。リンク速度が絶えず高速化しているため、フローレベルでの対応策の考案が求められている。

以下、トラフィック分類方法及び帯域幅割り当て方法について更に説明する。特に、ＢＴＤの実施形態におけるトラフィック分類方法を以下に説明する。上述したように、ＵＤＰには輻輳制御メカニズムが組み込まれておらず、且つ攻撃性が高いので、ＢＴＤの実施形態はまずプロトコルに基づいてトラフィックを分類して、ＴＣＰトラフィックと非ＴＣＰトラフィックとを分離する。具体的に、ＢＴＤの実施形態はトラフィックをＴＣＰ、ＵＤＰ、ＩＣＭＰ、及びその他という４つのグループに分類する。ＢＴＤの実施形態は、少なくともＩＰ層におけるプロトコルフィールドをチェックすることにより、この分類を実行する。帯域幅分割／割り当てに関しては、以下の例に限定されるわけではないが、例えば、システム管理者がネットワークを構築し、次のように帯域幅を割り当ててもよい。ＴＣＰ：８５％、ＵＤＰ：１３％、ＩＣＭＰ１％、その他１％。このような具体的な構成はサイトのプロファイルによって決定されるものであり、動的に変更されてもよい。

ＢＴＤの実施形態におけるトラフィック分類方法の目的は、正常トラフィックのプロファイルに従って、起こり得るＵＤＰ及びＩＣＭＰフラッド攻撃の影響を軽減する防御策を実行する必要があるか否かを判定することである。特性を挙動によって特定できるＴＣＰトラフィックとは異なり、ＵＤＰは攻撃性が高い。より「信頼性」が低いプロトコルであるため、正常ＵＤＰトラフィックと攻撃ＵＤＰトラフィックとを容易に区別することができない場合もあることが分かる。しかしながら、ＢＴＤの実施形態は、帯域幅制限を課すことで、これら２つのトラフィックを区別する単純だが効果的な方策を提供し、ほとんどの場合、ネットワークの性能に影響を及ぼさない。

更に、ネットワーク中に許容されるＩＣＭＰトラフィックの量を制限するのも良いやり方である。なぜなら、ＩＣＭＰが診断を目的としたものでしかなく、ＩＣＭＰベースのＤＤｏＳ攻撃が一般的であるからである。

図３は、保護されたネットワーク又はシステムのエントリーポイントにおいて、即ちファイアウォール３．１又はエッジルータ３．２で、トラフィック分類が如何にして実行されるかを示す。特に、分類を目的として設計されたネットワークプロセッサ及びその他のＡＳＩＣの可用性によって、ＢＴＤの実施形態は回線レートで動作可能である。

ＢＴＤの実施形態の帯域幅割り当て／分割機能としては、各プロトコルに対するクォータが設定可能であって、これは通常、一サイトにおけるルーチンのトラフィックプロファイルによって決定される。上述したように、また最近の測定によっても、現在インターネットで主要なトラフィックは依然としてＴＣＰである。従って、ウェブ、ｅメール、テルネット、及びＦＴＰ等の大半のキラーアプリケーションは全てＴＣＰを使用しているので、通常のサイトにおいては大半の帯域幅をＴＣＰトラフィックに割り当てるのが妥当である。例えば、各プロトコルの帯域幅割り当て／分割としては、ＴＣＰ：８８％、ＵＤＰ：１０％、ＩＣＭＰ：１％、及びその他：１％となるものが考えられる。将来トラフィックパターンが変化した場合には、ＢＴＤの実施形態は、新しいトラフィックモデルに従って帯域幅割り当て率を調整可能な可変帯域幅割り当てを提供する。従って、ＢＴＤの実施形態は将来的なトラフィック変化に容易に適応できる。

以下、ＢＴＤの実施形態におけるＴＣＰフロー識別方法について説明する。接続の確立とは、接続が確立されているか否かを判定することであり、受信者にとっては大きな意味がある。接続がうまく確立されていれば、両エンドは３ウェイハンドシェイクの手順を完了している。

ＤＤｏＳ防御においてよりいっそう重要なのは、送信元がＩＰスプーフィングを使用しているか否かを判定することである。それに対し、不完全な接続については、受信者は警戒し、リソース消費を抑えるべきであろう。起こり得る攻撃を軽減するための処置としては、以下に限定されないが、（１）全ての不完全な接続に対し、帯域幅割り当て総数を制限すること、（２）バッファがハーフオープン接続に長時間占有されないよう、タイムアウト値を著しく短くすること、又はハーフオープン接続に対してバッファ割り当てを全く行わないこと、及び（３）バックログ用のバッファサイズを増加することが考えられる。これらの選択肢は図２のステップ２．５に示されると共に上記されている。

以下、正常即ち良性フローと致命的即ち攻撃フローの分析について説明する。各プロトコルに対してクォータを割り当てたら、次に、致命的即ち攻撃ＴＣＰフローを良性即ち正常ＴＣＰフローから分離するタスクを行う。保護されたネットワークにおける帯域幅の大半をＴＣＰが消費するため、このタスクは簡潔に行われる。上述したように、トラフィックの大多数が攻撃ストリームである場合、フラッドベースのＤＤｏＳ攻撃に際して安易に公平パケットキューイングを採用することは実用的でない。ＴＣＰは、送信者と受信者との間に密接なオーケストレーションを要求するエンド・ツー・エンド（ｅｎｄ−ｔｏ−ｅｎｄ）ソリューションである。（接続確立後に）ＴＣＰフローの特性を特定するため、受信者はＡＣＫパケットを意図的に遅延させて、送信者の反応を積極的にテストすることができる。送信者は、正常な場合には、それに応じて対応し、送信レートを下げる。

対して、ＤＤｏＳ攻撃に関しては２つのケースが考えられる。一つは、送信者が偽造された送信元ＩＰアドレスを使用しており、従って受信者からのレート低減メッセージを受信できないケースである。この場合、送信者は適正な送信レートが全く分からない。もう一つは、送信者が通知を受信はしたものの、それを無視してパケットを送り続けるばかりであるため、プロトコルに違反し、割り当て分を減らされたり、更にはトラフィックをブロックされたりして、受信者によりペナルティを課されるケースである。上記手段は動的である。保護されたサイトは、加害者からのトラフィックが正常なものであるとシステムが間違って簡単に信じてしまわないよう、レート低減の頻度及び程度を決定することができる。

図４は、ＢＴＤの実施形態におけるトラフィック識別方法のフローチャート例を示す。ステップ４．１において新規入力パケットが到着すると、同じく図４のステップ４．１において、受信者はまず（送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号の）タプルをチェックすることで、現パケットのフローがどこに属するかを判定する。ステップ４．２において、上記方法によりパケットが新規フローの最初のパケットであると判定された場合、ステップ４．３において、受信者は、適正なサービス品質を確実に提供するために受信者が設定する閾値に対して、許可されたフローの数が最大フローカウントに到達したか否かを検査する。最大フローカウントとなっている場合、ステップ４．５においてパケットは破棄される。そうでない場合は、ステップ４．７において、受信者が維持しているフローテーブルを更新し、フローカウントを１だけインクリメントし、テスト合格数やテスト失敗数など幾つかのカウンタを初期設定した後、ステップ４．９において新規パケットを許可する。

既存フローのパケットに対しては、受信者はフローの挙動履歴をチェックする。図４のステップ４．３において、テスト失敗数が閾値ｆ以上の場合、ステップ４．５においてパケットは破棄されるだろう。ＢＴＤの実施形態がフローの挙動を誤って特定しないように、１より大きい整数が選択される。ｆが小さい値であると、パケット破棄に悪影響を及ぼすことがある。誤って特定された場合、無害なフローからの後続パケットがブロックされてしまうだろう。値が大きすぎるのも賢明な選択ではない。ｆが大きい値であるとパケットの破棄判定が遅延して、悪質なストリームの後続パケットがシステムリソースを更に消費することがある。実験結果によれば、ｆ＝３の場合、特定レートが適正で、且つ、性能への影響も容認でき、バランスが良い。

また、受信者がこの時点で送信元にペナルティを課すための選択肢を幾つか持つことは言及に値する。選択肢の一つは、ＤＵＰＡＣＫを意図的に送信して、送信元を強制的にスロースタート段階へ導くことである。別の選択肢として、ＲＳＴを送信して接続を中止させることで、リソースが不正送信元によって浪費されないようにすることも挙げられる。図４には、パケット破棄のオペレーションのみが示されており、その他のペナルティは示されていない。

過去の挙動がそれほど悪くないフローに対しては、図４のステップ４．６に示されるように、ＢＴＤの実施形態は、フローが所定回数ｈのテストに合格したか否かを検査する。ｈ回のテストに合格したフローのパケットであれば、受信者は直ちに許可しよう（例えば、ｈの適正値を決定するには何らかのトレードオフを行う必要がある。ｈに大きい値を選択すると、正常だが高レートであるフローのパフォーマンスを損なうことがあり、小さい値を使用すると、巧妙なアタッカーがテストを容易にかわしてしまうことがある。ステップ４．６においては、広範なシミュレーションの結果、ｈは６に設定された）。

その他のフローに対しては、図４のステップ４．８において、ＢＴＤの実施形態は更にフローの現在の状態をチェックする。フローがテスト中であれば、現レートはその前のレートの半分を超えることはないはずである（即ち、受信者はリバースＡＣＫレートを操作することでこの制限を強いる）。フローが当該制限に従う場合、ステップ４．１３においてフローは現テストに合格し、ステップ４．１４においてｐａｓｓ＿ｎｕｍが１だけインクリメントされ、ステップ４．１６においてパケットが許可される。そうでない場合、ステップ４．１３においてフローは１つのテストに失敗し、ステップ４．１５においてｆａｉｌ＿ｎｕｍが１だけインクリメントされ、ステップ４．１７においてパケットは破棄される。

ステップ４．８においてフローがテスト中でないと判定される場合、送信レートが各フローの公平な割り当て分のレートと比較される。比較の結果から、ステップ４．１０において当該フローのテスト確率が決定される。ステップ４．１２において、テストが必要か否か判定される。帯域幅が狭いと想定されるフローに対しては実施されるテストの回数が少ないことは明らかである。ステップ４．１において、テスト間の待ち時間が判定される。（公平な割り当て分を超える）高レートフローに対するテスト確率ｐは、１／（ｐａｓｓ＿ｎｕｍ＋１）である。最初は、全てのフローに対してｐａｓｓ＿ｎｕｍは０である。従って、高レートフローはテストに合格しない限り、テストされる可能性は１００％である。

フローのテスト合格数が増えるにつれ、そのテスト確率は減少する。リソース消費が少ないフローに対するテスト確率ｐは、１／ｍａｘ（ｍ，２＊ｈ）（式中、ｍはフローの総数である）である。通常の場合、ｍ＞＞２ｈであり、従ってｐ＝１／ｍである。システム内に数フローしか存在しない場合にも対応できるようｍａｘ（．）関数を使用し、低レートフローに対するテスト確率が最大で高レートフローに対するそれの１／２には確実になるようにする。

フローのレートは下記式によって計算される。
（ｎｕｍ＿ｐｋｔ＊ｓｚ＿ｐｋｔ）／ｔ （１）
式中、ｔは時間間隔（窓）であり、ｎｕｍ＿ｐｋｔは当該期間中に受信したパケット数であり、ｓｚ＿ｐｋｔはパケットサイズである。フローが一旦テストに合格するとフローの開始時間が更新されるので、上記式で計算されるフローレートは、通常他者が使用するようなフローの平均レートではないということは言及に値する。そのようにして、攻撃パケットを突発的に送信して輻輳を誘発するものの、非常に長い時間沈黙を保って平均レートを著しく下げることによって検出及びフィルタリングを逃れる低レートＤｏＳ攻撃を効果的に阻むことができる。

以下の４つのシナリオが考えられる。（１）攻撃発信元は常に正常に挙動し、よって攻撃の影響が大幅に軽減される。（２）攻撃発信元は、最初は正常に挙動し、後に不正な挙動をみせる。この場合、テスト状態において現レートは前レートの１／２を超えない、という制限が満たされることはなく、発信元はテストに失敗する。（３）攻撃発信元は常に不正な挙動をみせ、失敗数によって容易に阻まれる。及び（４）攻撃発信元は、最初は不正な挙動をみせるが、後に正常に挙動する。シナリオ（４）では、一旦テストに失敗すればｆａｉｌ＿ｎｕｍによってｐａｓｓ＿ｎｕｍが相殺されるので、攻撃発信元にとって、テストされる可能性が高まる。本発明の設計において、確率は低いものの低レートフローもテストされるということに注目されたい。時間の経過と共に、低レートフローが受信者によって一度もテストされない可能性は極めて低くなる。ＢＴＤの実施形態は上記方法を実施して、低レートストリームが悪質なケースも抑制する。

以下、悪質なＴＣＰフローに対するペナルティを説明する。受信者は、送信元にペナルティを課すために幾つかの選択肢を持つ。選択肢の一つは、ＤＵＰＡＣＫを意図的に送信することで、発信元を強制的にスロースタート段階に導くことである。別の選択肢として、ＲＳＴを送信して接続を中止させることで、リソースが不正発信元によって浪費されないようにすることも挙げられる。ＢＴＤの実施形態は、フローがテストに３回失敗すると、ＲＳＴを送信する。図４には、パケット破棄のオペレーションのみが示されており、その他のペナルティは示されていない。

以下、トラフィック分類に関する実験結果を説明する。トラフィック分類の有効性をテストするため、図５に示すように、１つのＦＴＰ送信元及びシンク（ＴＣＰ使用）と、１つのＣＢＲ送信元及びシンク（ＵＤＰ使用）とを含む簡単なシミュレーションシナリオを設定した。これらのフローは同じボトルネックリンクを通過する。ＦＴＰ送信元〜チェックポイント間、ＣＢＲ送信元〜チェックポイント間、宛先〜ＣＢＲシンク間、及び、宛先〜ＦＴＰシンク間のリンクパラメータは全て、帯域幅１０Ｍｂ、遅延２ｍｓとする。チェックポイント〜宛先間のボトルネックリンクは、１Ｍｂ、１０ｍｓに設定する。ＣＢＲレートは１０Ｍｂとする。チェックポイントでのトラフィック分類において、ＴＣＰが９０％、ＵＤＰが１０％である。シミュレーションの比較上、エントリーポイントがトラフィック分類を実行するか否かを除き、全て同じとする。ＦＴＰトラフィックのスループットを図６（ａ）及び図６（ｂ）に示す。

図６（ａ）は、トラフィック分類方法を実行しない場合の、ＴＣＰフローに対するＴＣＰグッドプット及びＴＣＰスループット、並びにＵＤＰスループットを示す。図６（ａ）及び図６（ｂ）において、ＴＣＰトラフィックは０秒の時点から開始され、ＵＤＰトラフィックは１秒後に開始される。０〜１秒の間、ＴＣＰはリンク内で唯一のトラフィックであり、そのグッドプット及びスループットは最大値で０．１秒当たり１２パケットに達する（ボトルネックリンクの帯域幅は１ｍｂ／秒、各パケットは１０００＊８＝８０００ビット、１ｍｂ＊０．１／８０００＝１２）。１．２秒以降、ＵＤＰトラフィックが合流し始め、使用可能な帯域幅を速やかに捕捉するので、ＴＣＰスループットは１．３〜１．８秒の間に１パケットまで減少し、１．９秒以降は枯渇してしまう。これに対して、トラフィック分類を行う場合、ＴＣＰスループットは１．９秒以降でも０．１秒当たり３パケットを保ち、ＵＤＰトラフィックは０．１秒当たり９パケット以下である。送信パケット総数は、図６（ａ）においては１２７、図６（ｂ）においては２３４である（図６（ｂ）においては比較のため１．９秒までのスループットしか示していない）。従って、ＴＣＰトラフィックのスループットはトラフィック分類によって７０．８％増加する。ＵＤＰトラフィックは依然としてＴＣＰより多くの割り当て分を獲得しているが、上述したように、これはＴＣＰに輻輳制御メカニズムが組み込まれているためである。

以下、ＴＣＰフロー識別を説明する。トラフィックフロー識別の有効性をテストするため、図７に示すように、ＦＴＰ送信元と攻撃発信元とを含むシミュレーションシナリオを設定した。これらのフローは同じボトルネックリンクを通過する。相違点として、一方のシミュレーションでは両フローからのパケットを受信するのに標準ＦＴＰシンクを使用し、もう一方では、本発明者らが開発した、ＴＣＰスマートシンクと呼ばれるＴＣＰシンクを使用している。シミュレーション結果を図８（ａ）及び図８（ｂ）に示す。

図８（ａ）は、ＦＴＰシンクを使用した場合の攻撃トラフィックのスループットを表し、図８（ｂ）は、ＢＴＤの実施形態におけるＴＣＰスマートシンクを使用した場合の攻撃トラフィックのスループットを示す。３．２秒の時点で、攻撃トラフィックのスループットは大幅に低下している。４２．３秒後、攻撃トラフィックは完全にブロックされている。対して、背景技術のＦＴＰシンクを受信者として使用した場合、送信者はその存続期間中最大スループットを保持することもある。当該結果により、ＢＴＤの実施形態におけるトラフィック識別手法の有効性が示される。

以上説明したように、ＢＴＤの実施形態は、トラフィック分類とトラフィック識別という２つの構成要素を備える。前者は非ＴＣＰトラフィックの量を低減するのに使用され、後者はプロアクティブテストを介して悪質なＴＣＰフローを特定することができる。以下、ＢＴＤの実施形態の顕著な利点を列挙する。
・ＢＴＤはプロアクティブテストを介して攻撃フローを効果的且つ効率的に特定且つブロックすることができる。
・ＢＴＤは多数のＤＤｏＳ攻撃パターンを抑制できる。
・ＢＴＤにおいては最小限の変更しか要求されない。
・ＢＴＤにはスケーラビリティやインセンティブ欠如等の問題がない。

シミュレーション及び上述の実験結果により、本発明の設計の有効性が証明された。更に、ＢＴＤの実施形態のその他の態様として以下が挙げられる。（１）ネットワーク状態を自動的に特定すること；（２）プロアクティブテストに合わせて使用される様々なパラメータを選択すること；及び（３）以下に限定はされないが、Ｌｉｎｕｘカーネル等のオペレーティングシステム環境においてフレームワークを実装することである。

以上をまとめると、ＢＴＤの実施形態は、まずトラフィック分類によって非ＴＣＰトラフィックの量を低減して、一般的なＵＤＰ及びＩＣＭＰフラッド攻撃を軽減しようとする。ＴＣＰフローに対しては、挙動を観察することによりそれらの特性を区別しようとする。表２は、正常トラフィックを受け入れ、攻撃トラフィックを制限するために、ＢＴＤの実施形態のフレームワークに採用される方法を列挙したものである。

以上、特定の実施形態のみが記載されているが、特許請求の範囲に記載の主題はその範囲を特定の実施形態又は実装に限定されないことが当然理解されよう。例えば、一実施形態は、例えばデバイス又はデバイスを組み合わせたものにおいて動作するよう実装されるような、ハードウェアにおけるものであってもよく、別の実施形態に関しては、ソフトウェアにおけるものであってもよい。同様に、ある実施形態はファームウェアにおいて、あるいは、例えばハードウェア、ソフトウェア、及び／又はファームウェアを任意に組み合わせたものとして実装されてもよい。同様に、一実施形態は１つ以上の物品、例えば１つ又は複数の記憶媒体から成っていてもよいが、特許請求の範囲に記載の主題は、その範囲をこの点において限定されない。例えば１つ以上のＣＤ−ＲＯＭ及び／又はディスクといった上記記憶媒体はそこに命令を記憶していてもよく、この命令が、例えばコンピュータシステム、コンピューティングプラットフォーム、又はその他のシステムといったシステムで実行された場合、特許請求の範囲に記載の主題に係る方法又は装置の一実施形態、例えば上述の実施形態の１つが実施されてもよい。
考えられる一例として、コンピューティングプラットフォームには、１つ以上の処理装置若しくはプロセッサ、１つ以上の入／出力デバイス（ディスプレイ、キーボード、及び／又はマウス等）、及び／又は１つ以上のメモリ（スタティックランダムアクセスメモリ、ダイナミックランダムアクセスメモリ、フラッシュメモリ、及び／又はハードドライブ等）、及びファイアウォール型機器の１つ以上のルータを実装するための装置又は方法が含まれてもよい。例えば、ディスプレイを用いて、１つ以上のクエリー（相関を持ったもの等）及び／又は１つ以上の木表現を表示してもよいが、ここでも、特許請求の範囲に記載の主題は、その範囲をこの例に限定されない。同様に、実施形態はシステムとして実装されてもよいし、或いは、コンピュータシステム及びコンピュータシステムに対するインターフェース（以下に限定されないが、ルータやファイアウォール等）、移動通信システム及び／又はその他の種類の通信システム、及びその他周知の電子システム等の構成要素を任意に組み合わせたものとして実装されてもよい。

先の記載には、特許請求の範囲に記載の主題の様々な態様が記載されている。特許請求の範囲に記載の主題が十分に理解されるように、説明上、特定の数値、システム、及び／又は構成を示した。しかしながら、上記の具体的な詳細通りでなくとも特許請求の範囲に記載の主題が実施されることは、本開示の恩恵を受ける当業者にとって明白であろう。その他、特許請求の範囲に記載の主題が不明確にならないよう、周知の特徴を省略及び／又は簡略化した場合もある。特定の特徴が本明細書に図示及び／又は記載されているが、多くの変形例、置換例、変更例、及び／又は均等物が当業者には想到されよう。従って、添付の特許請求の範囲は、そのような変形及び／又は変更の全てを、特許請求の範囲に記載の主題の趣旨に入るものとして包含するものであると理解されたい。

オン−オフモデルを使用して攻撃パケットを散発的に送信することにより低レートＤｏＳ攻撃を仕掛けるタイミングの一例を示す。 ＢＴＤフレームワークの一実施形態のフローチャート例を示す。 ファイアウォール又はエッジルータにおいて保護されたネットワーク又はシステムのエントリーポイントにおいて、如何にしてトラフィック分類が実行されるかを表す一例を示す。 ＢＴＤの実施形態におけるトラフィック識別方法のフローチャート例である。 １つのＦＴＰ送信元及びシンク（ＴＣＰ使用）、並びに１つのＣＢＲ送信元及びシンク（ＵＤＰ使用）を含むシミュレーションシナリオの一例を示す。 （ａ）は、トラフィック分類方法を実行しない場合の、ＴＣＰフローに対するＴＣＰグッドプット及びＴＣＰスループット、並びにＵＤＰスループットの一例を示し、（ｂ）は、トラフィック分類方法を実行する場合の、ＴＣＰフローに対するＴＣＰグッドプット及びＴＣＰスループット、並びにＵＤＰスループットの一例を示す。 １つのＦＴＰ送信元及び攻撃発信元を含むシミュレーションシナリオにおけるトラフィック識別の有効性を表す実験結果の一例を示す。 （ａ）は、ＢＴＤの実施形態においてＦＴＰシンクを用いた場合の攻撃トラフィックのスループットを表す実験結果の一例であり、（ｂ）は、ＢＴＤの実施形態においてＴＣＰスマートシンクを用いた場合の攻撃トラフィックのスループットを表す実験結果の一例である。

Claims (24)

1. 第一入力パケットを検査して前記第一入力パケットが許可されたＴＣＰ接続に関連付けられているか否かを判定するステップと、
   前記第一入力パケットは許可されたＴＣＰ接続に関連付けられているとの判定に応じて、前記ＴＣＰ接続に関連付けられたテスト確率に基づいて、前記ＴＣＰ接続は攻撃フローを表すかまたは良性フローを表すかを判定するように前記ＴＣＰ接続をテストすべきであるか否かを判定するステップと、
   前記ＴＣＰ接続をテストすべきであるとの判定に応じて、前記ＴＣＰ接続は攻撃フローを表すかまたは良性フローを表すかを判定するように前記ＴＣＰ接続をテストするステップであって、
   前記ＴＣＰ接続の送信元への前記入力パケットの確認応答の送信を遅延させるステップと、
   前記ＴＣＰ接続に関連付けられた少なくとも１つの更なる入力パケットに基づいて、前記ＴＣＰ接続の前記送信元が前記遅延に応じてその送信レートを調整するか否かを判定するステップとを含む、ステップと、
   前記ＴＣＰ接続の前記送信元が前記遅延に応じてその送信レートを調整する場合、前記第一入力パケットを許可するステップと、
   を含む方法。
2. 前記第一入力パケットは許可されたＴＣＰ接続に関連付けられていないとの判定に応じて、許可されたＴＣＰ接続の既存数が第一所定閾値より小さいか否かを判定するステップと、
   許可されたＴＣＰ接続の前記既存数が前記第一所定閾値より小さいとの判定に応じて、更なるＴＣＰ接続を許可しおよび前記第一入力パケットを許可するステップと、
   を更に含む、請求項１に記載の方法。
3. 前記更なるＴＣＰ接続を許可するステップは、前記更なるＴＣＰ接続に関連付けられたテスト確率を１に初期化するステップを含む、請求項２に記載の方法。
4. 各ＴＣＰ接続に対して、前記各ＴＣＰ接続の前記送信元が前記遅延に応じてその送信レートを下げる回数を、合格数として維持するステップと、前記各ＴＣＰ接続の前記送信元が前記遅延に応じてその送信レートを下げない回数を、失敗数として維持するステップと、を更に含む、請求項１に記載の方法。
5. 前記第一入力パケットが、その失敗数が第二所定閾値を超える許可されたＴＣＰ接続に関連付けられる場合、前記第一入力パケットを破棄するステップと、
   前記第一入力パケットが、その合格数が第三所定閾値を超える許可されたＴＣＰ接続に関連付けられる場合、前記第一入力パケットを許可するステップと、
   を更に含む、請求項４に記載の方法。
6. 各ＴＣＰ接続の前記テスト確率は１に初期化され、
   各ＴＣＰ接続に対し窓ベースのフローレートを計算するステップと、
   前記各ＴＣＰ接続の前記フローレートに応じて、前記各ＴＣＰ接続の前記フローレートに基づいて、前記各ＴＣＰ接続が高レート接続であるかまたは低レート接続であるかを判定するステップと、
   前記各ＴＣＰ接続は高レート接続であるとの判定に応じて、前記各ＴＣＰ接続に関連付けられた前記合格数に基づいて前記各ＴＣＰ接続の前記テスト確率を調整するステップとを、
   更に含む、請求項４に記載の方法。
7. 前記各ＴＣＰ接続が低レート接続であるとの判定に応じて、前記各ＴＣＰ接続の前記テスト確率を、ＴＣＰ接続の総数および前記第三所定閾値の少なくとも１つに少なくとも部分的に基づいた値に設定するステップを更に含む、請求項６に記載の方法。
8. 前記ＴＣＰ接続のテスト間の待ち時間を計算するステップと、
   前記ＴＣＰ接続をテストすべきであるとの判定に応じて、前記ＴＣＰ接続の前記待ち時間が超えた場合にのみ前記遅延を実行し、そうでなければ前記第一入力パケットを許可するステップと、
   を更に含む、請求項１に記載の方法。
9. １つ以上の受信した入力パケットの各々のプロトコルを判定するように構成されたトラフィック分類を実行するステップと、
   前記入力パケットの可能なプロトコルについての所定の帯域幅割り当てに基づいて前記１つ以上の受信した入力パケットの非ＴＣＰパケットを許可するステップと、
   １つ以上の入力パケットがＴＣＰパケットである場合、かつ、前記ＴＣＰパケットの前記所定の帯域幅割り当てにおいて十分な帯域幅がある場合、ＴＣＰ接続が確立しているか否かを判定し、ＴＣＰ接続が確立していない場合、レート制限、ハーフオープン接続における待ち時間短縮、又はバックログキューサイズのインクリメントのうち少なくとも１つを実行し、ＴＣＰ接続が確立している場合、ＴＣＰパケットを前記第一入力パケットとして転送するステップを更に含む、請求項１に記載の方法。
10. 前記トラフィック分類は、各入力パケットに対してパケット分類を判定するように前記入力パケットの少なくとも１つのインターネットプロトコル（ＩＰ）関連フィールドをチェックするステップを更に含む、請求項９に記載の方法。
11. 前記入力パケットのパケット分類に基づいて確立されたトラフィックプロファイルに基づいて前記所定の帯域幅割り当てを設定するステップを更に含む、請求項１０に記載の方法。
12. 前記トラフィック分類は、ファイアウォール又はエッジルータで実装される、
    請求項１１に記載の方法。
13. プロセッサによって実行される場合、前記プロセッサに、
    第一入力パケットを検査して前記第一入力パケットが許可されたＴＣＰ接続に関連付けられているか否かを判定するステップと、
    前記第一入力パケットは許可されたＴＣＰ接続に関連付けられているとの判定に応じて、前記ＴＣＰ接続に関連付けられたテスト確率に基づいて、前記ＴＣＰ接続は攻撃フローを表すかまたは良性フローを表すかを判定するように前記ＴＣＰ接続をテストすべきであるか否かを判定するステップと、
    前記ＴＣＰ接続をテストすべきであるとの判定に応じて、前記ＴＣＰ接続は攻撃フローを表すかまたは良性フローを表すかを判定するように前記ＴＣＰ接続をテストするステップであって、
    前記ＴＣＰ接続の送信元への前記入力パケットの確認応答の送信を遅延させるステップと、
    前記ＴＣＰ接続に関連付けられた少なくとも１つの更なる入力パケットに基づいて、前記ＴＣＰ接続の前記送信元が前記遅延に応じてその送信レートを調整するか否かを判定するステップとを含む、ステップと、
    前記ＴＣＰ接続の前記送信元が前記遅延に応じてその送信レートを調整する場合、前記第一入力パケットを許可するステップと、
    を含むオペレーションを実行させるソフトウェアコードを含むコンピュータ可読記憶媒体。
14. 前記オペレーションは、
    前記第一入力パケットは許可されたＴＣＰ接続に関連付けられていないとの判定に応じて、許可されたＴＣＰ接続の既存数が第一所定閾値より小さいか否かを判定するステップと、
    許可されたＴＣＰ接続の前記既存数が前記第一所定閾値より小さいとの判定に応じて、更なるＴＣＰ接続を許可しおよび前記第一入力パケットを許可するステップと、
    を更に含む、請求項１３に記載のコンピュータ可読記憶媒体。
15. 前記更なるＴＣＰ接続を許可するステップは、前記更なるＴＣＰ接続に関連付けられたテスト確率を１に初期化するステップを含む、請求項１４に記載のコンピュータ可読記憶媒体。
16. 前記オペレーションは、
    各ＴＣＰ接続に対して、前記各ＴＣＰ接続の前記送信元が前記遅延に応じてその送信レートを下げる回数を、合格数として維持するステップと、前記各ＴＣＰ接続の前記送信元が前記遅延に応じてその送信レートを下げない回数を、失敗数として維持するステップと、を更に含む、請求項１３に記載のコンピュータ可読記憶媒体。
17. 前記オペレーションは、
    前記第一入力パケットが、その失敗数が第二所定閾値を超える許可されたＴＣＰ接続に関連付けられる場合、前記第一入力パケットを破棄するステップと、
    前記第一入力パケットが、その合格数が第三所定閾値を超える許可されたＴＣＰ接続に関連付けられる場合、前記第一入力パケットを許可するステップと、
    を更に含む、請求項１６に記載のコンピュータ可読記憶媒体。
18. 各ＴＣＰ接続の前記テスト確率は１に初期化され、
    前記オペレーションは、
    各ＴＣＰ接続に対し窓ベースのフローレートを計算するステップと、
    前記各ＴＣＰ接続の前記フローレートに応じて、前記各ＴＣＰ接続の前記フローレートに基づいて、前記各ＴＣＰ接続が高レート接続であるかまたは低レート接続であるかを判定するステップと、
    前記各ＴＣＰ接続は高レート接続であるとの判定に応じて、前記各ＴＣＰ接続に関連付けられた前記合格数に基づいて前記各ＴＣＰ接続の前記テスト確率を調整するステップとを、
    更に含む、請求項１６に記載のコンピュータ可読記憶媒体。
19. 前記オペレーションは、
    前記各ＴＣＰ接続が低レート接続であるとの判定に応じて、前記各ＴＣＰ接続の前記テスト確率を、ＴＣＰ接続の総数および前記第三所定閾値の少なくとも１つに少なくとも部分的に基づいた値に設定するステップを更に含む、請求項１８に記載のコンピュータ可読記憶媒体。
20. 前記オペレーションは、
    前記ＴＣＰ接続のテスト間の待ち時間を計算するステップと、
    前記ＴＣＰ接続をテストすべきであるとの判定に応じて、前記ＴＣＰ接続の前記待ち時間が超えた場合にのみ前記遅延を実行し、そうでなければ前記第一入力パケットを許可するステップと、
    を更に含む、請求項１３に記載のコンピュータ可読記憶媒体。
21. 前記オペレーションは、
    １つ以上の受信した入力パケットの各々のプロトコルを判定するように構成されたトラフィック分類を実行するステップと、
    前記入力パケットの可能なプロトコルについての所定の帯域幅割り当てに基づいて前記１つ以上の受信した入力パケットの非ＴＣＰパケットを許可するステップと、
    １つ以上の入力パケットがＴＣＰパケットである場合、かつ、前記ＴＣＰパケットの前記所定の帯域幅割り当てにおいて十分な帯域幅がある場合、ＴＣＰ接続が確立しているか否かを判定し、ＴＣＰ接続が確立していない場合、レート制限、ハーフオープン接続における待ち時間短縮、又はバックログキューサイズのインクリメントのうち少なくとも１つを実行し、ＴＣＰ接続が確立している場合、ＴＣＰパケットを前記第一入力パケットとして転送する、請求項１３に記載のコンピュータ可読記憶媒体。
22. 前記トラフィック分類は、各入力パケットに対してパケット分類を判定するように前記入力パケットの少なくとも１つのインターネットプロトコル（ＩＰ）関連フィールドをチェックするステップを更に含む、請求項２１に記載のコンピュータ可読記憶媒体。
23. 前記チェックされたフィールドによって、前記パケットがＴＣＰ、ＵＤＰ、ＩＣＭＰ、及びその他のパケットのうちの１つとして分類されるか否かを判定する、請求項２２に記載のコンピュータ可読記憶媒体。
24. 前記オペレーションは、前記入力パケットのパケット分類に基づいて確立されたトラフィックプロファイルに基づいて前記所定の帯域幅割り当てを設定するステップを更に含む、請求項２２に記載のコンピュータ可読記憶媒体。

Images