(57)【特許請求の範囲】
【請求項１】
アプリケーションプロトコルを識別する方法であって、
Ａ．受信されたデータパケットを個々のトラフィックフローに分類するステップと、
Ｂ．キーワードの重みがトラフィックフローの有効なペイロード内のキーワードの位置に関連し、識別可能なアプリケーションプロトコルのキーワードデータベースに基づいてトラフィックフローの有効なペイロード内でキーワードを探索し、トラフィックフローのキーワード重みベクトルを決定するステップと、
Ｃ．トラフィックフローのキーワード重みベクトルと識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルの間の類似度を決定するステップと、
Ｄ．所定の条件が満たされる場合に、トラフィックフローのキーワード重みベクトルへの最も高い類似度を有する特徴キーワード重みベクトルに対応するアプリケーションプロトコルをトラフィックフローのアプリケーションプロトコルとして決定するステップと
を備える、方法。
【請求項２】
トラフィックフローの有効なペイロードにおいてより早く最初に現れるキーワードが、ステップＢにおいてより大きな重みを有する、請求項１に記載の方法。
【請求項３】
トラフィックフローｆｄのキー重みベクトルにおける第ｉのキーワードの重みがωｉｄ＝ｉｔｐｉｄ×ｉｄｆｉで表され、
ｉｔｐｉｄ＝１／ｏｉｄであり、ｏｉｄは第ｉのキーワードがトラフィックフローｆｄ内で最初に現れる位置を表し、
【数１】
0005536280.tif 000010
であり、｜Ｆ｜はトラフィックフローの総量を表し、｜｛ｆ：ｋｉ∈ｆ｝｜は第ｉのキーワードｋｉを含むトラフィックフローの量を表す、
請求項２に記載の方法。
【請求項４】
ステップＡの前に、
ａ．識別可能なアプリケーションプロトコルのキーワードデータベースに基づいて複数の訓練トラフィックフローの有効なペイロードでキーワードを探索し、複数の訓練トラフィックフローのキーワード重みベクトルを決定するステップと、
ｂ．複数の訓練トラフィックフローのキーワード重みベクトルにしたがって各々の識別可能なアプリケーションプロトコルに対応する特徴キーワード重みベクトルを決定するステップと
をさらに備える、請求項１から３のいずれか一項に記載の方法。
【請求項５】
複数の訓練トラフィックフローのキーワード重みベクトルが、ステップＢにおけるのと同じアルゴリズムを使用してステップａで決定され、
第ｊのトラフィックフローのキー重みベクトルにおける第ｉのキーワードの重みがωｉｊ＝ｉｔｐｉｊ×ｉｄｆｊで表され、
ｉｔｐｉｊ＝１／ｏｉｊであり、ｏｉｊが、第ｉのキーワードが第ｊのトラフィックフロー内で最初に現れる位置を表し、
【数２】
0005536280.tif 000011
であり、｜Ｆ｜がトラフィックフローの総量を表し、｜｛ｆ：ｋｉ∈ｆ｝｜が第ｉのキーワードｋｉを含むトラフィックフローの量を表す、
請求項４に記載の方法。
【請求項６】
受信されたデータパケットがステップＡにおいて、受信されたデータパケットの５タプルにしたがって分類され、５タプルはソースアドレス、宛先アドレス、ソースポート番号、宛先ポート番号および転送プロトコルタイプを含み、ステップＣにおける類似度がコサイン類似度を含む、請求項１から３のいずれか一項に記載の方法。
【請求項７】
所定の条件が、最も高い類似度が所定の値を上回ることを含む、請求項１から３のいずれか一項に記載の方法。
【請求項８】
アプリケーションプロトコルを識別するための装置であって、
受信されたデータパケットを個々のトラフィックフローに分類するように構成された第１のデバイスと、
キーワードの重みがトラフィックフローの有効なペイロード内のキーワードの位置に関連し、識別可能なアプリケーションプロトコルのキーワードデータベースに基づいてトラフィックフローの有効なペイロードでキーワードを探索し、トラフィックフローのキーワード重みベクトルを決定するように構成された、第２のデバイスと、
トラフィックフローのキーワード重みベクトルと識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルの間の類似度を決定するように構成された、第３のデバイスと、
所定の条件が満たされる場合に、トラフィックフローのキーワード重みベクトルへの最も高い類似度を有する特徴キーワード重みベクトルに対応するアプリケーションプロトコルをトラフィックフローのアプリケーションプロトコルとして決定するように構成された、第４のデバイスと
を備える、装置。
【請求項９】
トラフィックフローの有効なペイロードでより早く最初に現れるキーワードが、第２のデバイスにおいてより大きな重みを有する、請求項８に記載のプロトコル識別装置。
【請求項１０】
トラフィックフローｆｄのキー重みベクトルにおける第ｉのキーワードの重みがωｉｄ＝ｉｔｐｉｄ×ｉｄｆｉとして表され、
ｉｔｐｉｄ＝１／ｏｉｄであり、ｏｉｄが第ｉのキーワードがトラフィックフローｆｄ内で最初に現れる位置を表し、
【数３】
0005536280.tif 000012
であり、｜Ｆ｜がトラフィックフローの総量を表し、｜｛ｆ：ｋｉ∈ｆ｝｜が第ｉのキーワードｋｉを含むトラフィックフローの量を表す、
請求項９に記載のプロトコル識別装置。
【請求項１１】
ステップＡの前に、第２のデバイスが、
−  識別可能なアプリケーションプロトコルのキーワードデータベースに基づいて複数の訓練トラフィックフローの有効なペイロードでキーワードを探索し、複数の訓練トラフィックフローのキーワード重みベクトルを決定するように、および、
−  複数の訓練トラフィックフローのキーワード重みベクトルにしたがって各々の識別可能なアプリケーションプロトコルに対応する特徴キーワード重みベクトルを決定するように
さらに構成された、請求項８から１０のいずれか一項に記載のプロトコル識別装置。
【請求項１２】
第２のデバイスが、同じアルゴリズムを使用して、複数の訓練トラフィックフローおよび受信されたデータパケットのトラフィックフローのキーワード重みベクトルを決定し、
第ｊのトラフィックフローのキー重みベクトルにおける第ｉのキーワードの重みがωｉｊ＝ｉｔｐｉｊ×ｉｄｆｉで表され、
ｉｔｐｉｊ＝１／ｏｉｊであり、ｏｉｊが第ｉのキーワードが第ｊのトラフィックフロー内で最初に現れる位置を表し、
【数４】
0005536280.tif 000013
であり、｜Ｆ｜がトラフィックフローの総量を表し、｜｛ｆ：ｋｉ∈ｆ｝｜が第ｉのキーワードｋｉを含むトラフィックフローの量を表す、
請求項１１に記載のプロトコル識別装置。
【請求項１３】
第１のデバイスが、受信されたデータパケットの５タプルにしたがって、受信されたデータパケットを分類し、５タプルがソースアドレス、宛先アドレス、ソースポート番号、宛先ポート番号および転送プロトコルタイプを含み、第３のデバイスにおける類似度がコサイン類似度を含む、請求項８から１０のいずれか一項に記載のプロトコル識別装置。
【請求項１４】
所定の条件が、最も高い類似度が所定の値を上回ることを含む、請求項８から１０のいずれか一項に記載のプロトコル識別装置。
【請求項１５】
請求項８から１４のいずれか一項に記載のプロトコル識別装置を備える、ネットワーク機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、ネットワーク通信技術に関し、特に、プロトコル識別技術に関する。
【背景技術】
【０００２】
本発明は、ＴＣＰ／ＩＰネットワークなどのデータネットワーク内のアクセスゲートウェイまたは他のデバイスによって受信されるトラフィック内のアプリケーション層のプロトコルタイプを識別および分類するための方法を提案する。
【０００３】
アプリケーションプロトコル識別は、ネットワークを介して運ばれるトラフィックのプロトコルタイプを判定することを意図するものである。これは、たとえば、効果的なネットワーク計画および設計、法的なモニタリングおよびネットワークブロッキングなどのセキュリティポリシ、トラフィックシェーピングおよびサービスの差別化などのサービスの質（ＱｏＳ）の実施、課金ポリシ設計など、様々な場合に欠かせない、ネットワークトラフィックの情報伝達特性を提供するための重要な技術である。
【０００４】
今日の通信ネットワークは、概して、階層化モデル、たとえばＯＳＩ参照モデルまたはＴＣＰ／ＩＰ参照モデルに従う。ＴＣＰ／ＩＰ参照モデルは、ほとんどのデータネットワークによって採用され、以下の５つの層から成る：物理層、データリンク層、ネットワーク層、トランスポート層およびアプリケーション層。中継ノード、たとえばアクセスゲートウェイ、は一般に、ＩＰ層での転送および中継のみを含み、上層（トランスポート層およびアプリケーション層）で運ばれる内容の知識を有さない。しかし、一部のシナリオでは、たとえば、ある特定のタイプのアプリケーションがブロックされる場合、中継ノードがアプリケーション層で運ばれるプロトコルタイプを識別および判定するための効率的方法を見つけることが必要である。
【発明の概要】
【課題を解決するための手段】
【０００５】
アプリケーションプロトコルを識別する代表的な解決法は、概して、以下の３つの分類に分かれる：
ポートに基づくプロトコル識別
ポート番号によるプロトコル分類は、最も単純で、最も伝統的な方法である。この方法は、トランスポート層ヘッダで運ばれるポート番号からプロトコルまたはアプリケーションタイプを識別する。標準プロトコルでは、ポート番号とプロトコルの間の対応は、インターネットアサインドナンバオーソリティ（ＩＡＮＡ）によって定義され、たとえば、ＨＴＴＰプロトコルは通常はポート８０を使用し、ＳＭＴＰプロトコルはポート２５を使用する。所有権を主張できるプロトコルでは、ポート番号は通常は、プロトコルまたはアプリケーション自体によって定義される。プロトコルとポート番号の間のそのような対応により、プロトコルタイプは、アプリケーション層プロトコルヘッダ、たとえばＴＣＰヘッダ、内のソースポートおよび宛先ポート欄内のポート番号から判定可能である。
【０００６】
ポート番号に基づくプロトコル識別は効率的であり、実装が容易であるが、それはいくつかの明らかな欠点を有する。１）いくつかのプロトコルでは、実際に使用されるポート番号が実行プロセス中に動的に割り当てられる。２）ファイアウォールの広範囲に及ぶ使用は、いくつかのポートが他のいくつかよりも簡単にファイアウォールを通り抜けることを可能にし、それにより、接続性を確保するために、直接にまたはオリジナルプロトコルにそれらをカプセル化することによってのいずれかで、所有権を主張できるプロトコルのためによく知られているポートを使用する傾向が増している。３）一部のプロトコルは、識別されることを避けるために、非標準ポートを明示的に使用し、一部のＰ２Ｐアプリケーションにさえもユーザがデフォルトポートを変更することを許すものがあり、他のいくつかは、検出されることを回避するために、トンネリングおよび動的ポート選択を組み合わせて使用する。したがって、単にポート番号に基づいてプロトコルを識別することはもはや信頼性がない。
【０００７】
ペイロードに基づくプロトコル識別
ペイロードに基づく分類は、ディープパケットインスペクション（ＤＰＩ）技術でトラフィックデータパケット内のプロトコルのペイロードを検査することである。この方法は、アプリケーション層データパケット内の決定性の文字列を見つけることを含み、たとえば文字列「ｈｔｔｐ／１」はアプリケーションＨＴＴＰに対応し、文字列「０ｘｅ３１９０１００００」はｅＤｏｎｋｅｙアプリケーションに対応する。しかし、単一の署名は、プロトコルタイプを判定するのには十分信頼できるものではなく、たとえば、文字列「ｈｔｔｐ／１」はＫａｚｚａプロトコルにも現れることもある。
【０００８】
マッチングの精度を改善するために、ある人はマッチングの正規表現を使用することを提案した。正規表現は、柔軟で強力な表現形式を提供し、高い精度でプロトコル識別を提供することができる。実際のアプリケーションでは、決定性有限オートマン（ＤＦＡ）が通常は、正規表現を実装するために使用される。しかし、決定性有限オートマンへの正規表現の完全なコンパイルは、特定のパターンに依存するＤＦＡ状態の指数関数的数をもたらし、それによって性能を下げることがある。
【０００９】
挙動に基づくプロトコル識別
挙動に基づくプロトコル識別は、トラフィックの内容をチェックしないが、代わりに、たとえば、データパケットのサイズ、接続の数など、トラフィックの観測される挙動または特性からプロトコルを識別する。一般的な挙動に基づくプロトコル識別は、統計的プロパティを使用してアプリケーションに関するトラフィックを識別および分類することである。たとえば、ある文献は、教師あり機械学習を採用してインターネットトラフィックを識別することを提案しており、基本的な分類されるオブジェクトは、所与の対のホストの間の１つまたは複数のデータパケットとして表されるトラフィックフローである。各トラフィックフローは、その挙動を説明するいくつかの特性（パラメータ）を有する。これらのパラメータは、アプリケーション識別のための入力弁別子を構成する。たとえば、フロー持続期間、パケット到着間の時間、有効なペイロードサイズ、パケット到着間の時間のフーリエ変換などは、弁別子の機能を果たすことができる。前記文献が主張するように、ベイジアン機械学習は６５％の識別率を達成したが、２つの改良、すなわちカーネル密度推定（Ｋｅｒｎｅｌ  Ｄｅｎｓｉｔｙ  Ｅｓｔｉｍａｔｉｏｎ、ＫＤＥ）および高速相関に基づくフィルタ（Ｆａｓｔ  Ｃｏｒｒｅｌａｔｉｏｎ−Ｂａｓｅｄ  Ｆｉｌｔｅｒ、ＦＣＢＦ）の導入のおかげで９５％の識別率を達成した。またある人は、いくつかの他の統計に基づく識別機構を提案した。
【００１０】
挙動に基づくプロトコル識別は、内容に基づくプロトコル識別に比べてより少ない性能オーバヘッドをもたらすが、いくつかの限界を被る。１）挙動に基づくプロトコル識別は通常は、内容に基づくプロトコル識別のそれよりも低い精度を有する。それは主に統計的記述子に依存するので、それはペイロードに基づく決定性アプローチに比べて不安定な精度を有する。２）加えて、観測される挙動は、たとえば、ネットワークタイプ、ホスト処理能力など、外部環境に常に依存する。たとえば、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）におけるパケット到着間の時間は、イーサネット（登録商標）ネットワークにおけるそれとは異なり得る。３）パディングでパケットの長さを変えること、またはパケットを遅らせることによってパケット到着間の時間を課することなど、前述のトラフィックパラメータを修正することによって、悪意のあるユーザは識別されることを回避することが比較的容易である。
【００１１】
先行技術の前述の欠点を克服するために、本発明は、キーワードベクトルマッチングに基づくアプリケーションプロトコルを識別するための方法および装置を提案する。
【００１２】
本発明の一実施形態では、アプリケーションプロトコルを識別する方法が提供され、本方法は以下のステップを備える：Ａ．検出されることになるデータパケットを個々のトラフィックフローに分類するステップと、Ｂ．キーワードの重みがトラフィックフローの有効なペイロード内のキーワードの位置に関連し、識別可能なアプリケーションプロトコルのキーワードデータベースに基づいてトラフィックフローの有効なペイロード内でキーワードを探索し、トラフィックフローのキーワード重みベクトルを判定するステップと、Ｃ．トラフィックフローのキーワード重みベクトルと識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルの間の類似度を判定するステップと、Ｄ．所定の条件が満たされる場合に、トラフィックフローのキーワード重みベクトルへの最も高い類似度を有する特徴キーワード重みベクトルに対応するアプリケーションプロトコルをトラフィックフローのアプリケーションプロトコルとして判定するステップ。
【００１３】
本発明のもう１つの実施形態では、ステップＡの前に、アプリケーションプロトコルを識別する本方法はさらに以下を備える：ａ．識別可能なアプリケーションプロトコルのキーワードデータベースに基づいて複数の訓練トラフィックフローの有効なペイロードのキーワードを探索し、複数の訓練トラフィックフローのキーワード重みベクトルを判定するステップと、ｂ．複数の訓練トラフィックフローのキーワード重みベクトルにしたがって各々の識別可能なアプリケーションプロトコルに対応する特徴キーワード重みベクトルを判定するステップ。
【００１４】
本発明の一実施形態では、アプリケーションプロトコルを識別するための装置が提供され、本装置は以下を備える：検出されることになるデータパケットを個々のトラフィックフローに分類するように構成された第１のデバイスと、キーワードの重みがトラフィックフローの有効なペイロード内のキーワードの位置に関連し、識別可能なアプリケーションプロトコルのキーワードデータベースに基づいてトラフィックフローの有効なペイロード内でキーワードを探索し、トラフィックフローのキーワード重みベクトルを判定するように構成された第２のデバイスと、トラフィックフローのキーワード重みベクトルと識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルの間の類似度を判定するように構成された第３のデバイスと、所定の条件が満たされる場合に、トラフィックフローのキーワード重みベクトルへの最も高い類似度を有する特徴キーワード重みベクトルに対応するアプリケーションプロトコルをトラフィックフローのアプリケーションプロトコルとして判定するように構成された第４のデバイス。
【００１５】
本発明の一実施形態では、本発明の前述のプロトコル識別装置を含むネットワーク機器が提供される。
【００１６】
本発明の方法および装置で、プロトコル識別の精度は、任意の有意な性能オーバヘッドを導入することなしに改善可能である。
【００１７】
本システムは、以下の図面および説明を参照してさらによく理解されよう。図面内の要素は、必ずしも原寸に比例せず、典型的なモデルの原理に重点が置かれている。図面において、同様の参照番号は、様々な図面を通して対応する特徴を示す。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態によるアプリケーションプロトコルを識別する方法の流れ図である。
【図２】本発明の一実施形態によるアプリケーションプロトコルを識別する方法における特徴キーワード重みベクトルを判定するステップの流れ図である。
【図３】本発明の一実施形態によるプロトコル識別装置の構造図である。
【発明を実施するための形態】
【００１９】
一般性の喪失なしに、本発明の以下のすべての実施形態は、データ通信ネットワーク、たとえばインターネットネットワークに適用されることになる。
【００２０】
本発明において、識別されることになる各アプリケーションプロトコルについて、そのプロトコルに現われ得る１セットのキーワードが選択されることになる。一例として、但し限定ではなく、ハイパーテキスト転送プロトコルのキーワードは「ｈｔｔｐ／」を含み、ファイル転送プロトコルのキーワードは「ｆｔｐ／」を含むなど。受信されたデータパケットは、５タプルにより個々のトラフィックフローに分類される。その５タプルは、ソースアドレス、宛先アドレス、ソースポート番号、宛先ポート番号および転送プロトコルタイプを含む。各個々のトラフィックフローについて、キーワード重みベクトルは、そのトラフィックフローの有効なペイロード内でキーワードを検出することによって取得可能であり、識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルと突き合わされて、それによってこの個々のトラフィックフローのプロトコルを識別することができる。
【００２１】
図１は、本発明の一実施形態によるアプリケーションプロトコルを識別する方法の流れ図である。この方法は通常は、データ通信ネットワークのネットワーク機器に適用可能である。図１に示すように、アプリケーションプロトコルを識別する本方法は、この実施形態において、４つのステップＳ１１、Ｓ１２、Ｓ１３およびＳ１４を含む。
【００２２】
ステップＳ１１で、検出されることになるデータパケットが、個々のトラフィックフローに分類される。
【００２３】
ステップＳ１２で、トラフィックフローの有効なペイロードは識別可能なアプリケーションプロトコルのキーワードデータベースに基づいてキーワードを探索され、そのトラフィックフローのキーワード重みベクトルが判定され、キーワードの重みは、トラフィックフローの有効なペイロード内のキーワードの位置に関連する。
【００２４】
具体的には、一例として、但し限定ではなく、識別可能なアプリケーションプロトコルのキーワードデータベース内に合計でＭ個の異なるキーワードが存在し、各識別可能なプロトコルについて、いくつかのキーワードｋｍ，ｍ∈｛１，…，Ｍ｝がそのプロトコル内に現われ得る。一例として、但し限定ではなく、ハイパーテキスト転送プロトコルのキーワードは「ｈｔｔｐ／」を含み、ファイル転送プロトコルのキーワードは「ｆｔｐ／」を含むなど。たとえば、トラフィックフローｆｄのキーワード重みベクトルは、ｖｄとして表すことができる。
【００２５】
ステップＳ１３で、トラフィックフローのキーワード重みベクトルと識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルの間の類似度が判定される。
【００２６】
具体的には、一例として、但し限定ではなく、合計Ｎ個の識別可能なプロトコルが存在し、各識別可能なプロトコルの特徴キーワード重みベクトルは、Ｖｎ，ｎ∈｛１，…，Ｎ｝として表すことができる。
【００２７】
ステップＳ１４で、トラフィックフローのキーワード重みベクトルへの最も高い類似度を有する特徴キーワード重みベクトルに対応するアプリケーションプロトコルが、所定の条件が満たされる場合に、そのトラフィックフローのアプリケーションプロトコルとして判定される。
【００２８】
異なる識別可能なプロトコルが同じキーワードを有し得る、または別法として互いに重複しないキーワードを有し得ることが、当業者には理解されよう、そして、ＮおよびＭの値はそれらの大きさに関して必要な関係を有さなくてもよい。好ましくは、各識別可能なアプリケーションプロトコルは、少なくとも１つの一義的キーワードを有し、そうして、Ｍ≧Ｎであり、それによるそれらの異なるプロトコル間の区別が改善され得る。
【００２９】
本発明の一実施形態では、具体的には、検出されることになるデータパケットは、ステップＳ１１で５タプルによる個々のトラフィックフローに分類され、その５タプルは、ソースアドレス、宛先アドレス、ソースポート番号、宛先ポート番号および転送プロトコルタイプを含む。ソース（ノード）と宛先（ノード）の間で同アプリケーションのデータを運ぶためのデータパケットは、同じソースアドレス、宛先アドレス、ソースポート番号、宛先ポート番号および転送プロトコルタイプを有することになることが理解されよう。通常は、異なるアプリケーションのデータパケットは異なるソースポート番号および宛先ポート番号を有し、異なるソース（ソースノード）と宛先（宛先ノード）の間のデータパケットは異なるソースアドレスおよび宛先アドレスを有する。したがって、同じ５タプル内容を有する異なるデータパケットは、一対のソースと宛先の間の同アプリケーションに属することになり、同じ個々のトラフィックフローに分類されることになる。
【００３０】
本発明の一実施形態では、具体的には、ステップ１３での類似度は、コサイン類似度を含む。たとえば、トラフィックフローｆｄのキーワード重みベクトルｖｄと任意の識別可能なプロトコルの特徴キーワード重みベクトルの間のコサイン類似度は、場合により以下の公式で、それぞれ計算されることになる：
【００３１】
【数１】
0005536280.tif 000002
本発明の一実施形態では、具体的には、所定の条件は、ステップＳ１４での最も高い類似度が所定の値を上回ることを含む。たとえば、トラフィックフローｆｄのキーワード重みベクトルｖｄと特徴キーワード重みベクトルＶ２の間のコサイン類似度は最も高く、そして、その場合に、その最も高い類似度が所定の値を上回るときに、Ｖ２によって表されるアプリケーションプロトコルはそのトラフィックフローｆｄのアプリケーションプロトコルとして判定されることになり、そして、その場合に、最も高い類似度が所定の値を下回るときに、トラフィックフローｆｄが知られていないアプリケーションとして識別されることになる、すなわち、トラフィックフローｆｄは、任意の識別可能なプロトコルに属していないものとして判定されることになる。
【００３２】
本発明の一実施形態では、具体的には、トラフィックフローの有効なペイロードにおいてより早く最初に現れるキーワードは、ステップＳ１２で、より大きな重みを有する。
【００３３】
通常は、識別プロセスは、前述のステップＳ１１、Ｓ１２、Ｓ１３およびＳ１４を含み、各識別可能なプロトコルの特徴キー重みベクトルは、その識別プロセスに先立つ訓練プロセスで判定されることになる。図２は、本発明の一実施形態によるアプリケーションプロトコルを識別する方法で特徴キーワード重みベクトルを判定するステップ、すなわち訓練プロセス、の流れ図である。図示するように、この訓練プロセスは、２つのステップＳ２１およびＳ２２を含む。
【００３４】
ステップＳ２１で、複数の訓練トラフィックフローの有効なペイロードは、識別可能なアプリケーションプロトコルのキーワードデータベースに基づいてキーワードについて探索され、そして、その複数の訓練トラフィックフローのキーワード重みベクトルが判定される。
【００３５】
ステップＳ２２で、各識別可能なアプリケーションプロトコルに対応する特徴キーワード重みベクトルが、複数の訓練トラフィックフローのキーワード重みベクトルにしたがって判定される。具体的には、各訓練トラフィックフローのアプリケーションプロトコルは、事前に知られていて、したがって、同じアプリケーションプロトコルに属するすべての訓練トラフィックフローのキーワード重みベクトルが、平均化されて、アプリケーションプロトコルに対応する特徴キーワード重みベクトルを判定することができる。
【００３６】
本発明の一実施形態では、具体的には、トラフィックフローの有効なペイロードにおいてより早く最初に現れるキーワードは、ステップＳ２１で、より大きな重みを有する。
【００３７】
より具体的には、キーワードの重みは、本発明の一実施形態のステップＳ２１で、以下のｉｔｐ−ｉｄｆ（逆テキスト位置−逆文書頻度）アルゴリズムによって検出され、第ｊの訓練トラフィックフローの第ｉのキーワードの重みは以下のように表される：
ωｉｊ＝ｉｔｐｉｊ×ｉｄｆｉ  （１）
但し、ｉｔｐｉｊは逆テキスト位置のメトリクであり、ｉｄｆｉは逆文書頻度のメトリクであり、そして、
ｉｔｐｉｊ＝１／ｏｉｊ  （２）
但し、ｏｉｊは、第ｉのキーワードｋｉが第ｊの訓練トラフィックフローで最初に現れる位置を表し、そして、この位置はビット位置またはバイト位置でもよく、ｉｔｐｉｊは、ｏｉｊの逆数を表し、第ｉのキーワードｋｉが第ｊの訓練トラフィックフローで現れない場合、０の値を取ることになり
【００３８】
【数２】
0005536280.tif 000003
但し、｜Ｆ｜は訓練トラフィックフローの総量を表し、そして、｜｛ｆ：ｋｉ∈ｆ｝｜は、第ｉのキーワードｋｉを含むトラフィックフローの量を表し、その場合、第ｊの訓練トラフィックフローのキーワード重みベクトルは以下で表すことができる：
ｖｊ＝（ω１ｊ，ω２ｊ，．．．，ωＭｊ）  （４）
但し、Ｍは、キーワードデータベースにおけるキーワードの総量を表す。
【００３９】
ステップＳ２２で、各識別可能なアプリケーションプロトコルに対応する特徴キーワード重みベクトルが、複数の訓練トラフィックフローのキーワード重みベクトルにしたがって、判定される。特定の識別可能なアプリケーションプロトコルｐについて、特徴キーワード重みベクトルは、所与の訓練トラフィックフローから計算され得る、または、以下のように表される重心ベクトルと称され得る：
【００４０】
【数３】
0005536280.tif 000004
但し、Ｆｐは、プロトコルｐに属する訓練トラフィックフローのセットを表し、｜Ｆｐ｜はプロトコルｐに属する訓練トラフィックフローの量を表し、ｖｊはセットＦｐにおけるトラフィックフローのキーワード重みベクトルを表す。Ｖｐは、セットＦｐ内のそれぞれの訓練トラフィックフローのキーワード重みベクトルで現れるそれぞれのキーワードの重みを平均化することによって導出され得る。
【００４１】
各識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルは、この実施形態のステップＳ２１およびＳ２２で前述の公式（１）から（５）で訓練トラフィックフローに基づいて容易に計算され得る。
【００４２】
訓練トラフィックフローはまた、５タプルにしたがって多数の訓練データパケットを分類することによって導出され、その訓練トラフィックフローは各識別可能なアプリケーションのいくつかのトラフィックフローを含むことになることが、当業者には理解されよう。
【００４３】
前述の訓練プロセス、すなわちステップＳ２１およびステップＳ２２、は、識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルを更新するために、各更新された訓練トラフィックフローについて、定期的にまたは非定期的に繰り返され得ることが、当業者には理解されよう。新しい識別可能なアプリケーションプロトコルは、更新のために特定の訓練プロセスで導入可能であり、したがって、キーワードデータベース内のキーワードの数は増やすことができ、更新された訓練トラフィックフローは新しく導入された識別可能なアプリケーションプロトコルのいくつかのトラフィックフローをさらに含むことになり、更新結果は、新たに導入された識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルをさらに含み得る。
【００４４】
トラフィックフローのキーワード重みベクトルは、訓練プロセスのステップＳ２１と同じアルゴリズムでステップＳ１２の識別プロセスで判定されることになることが、当業者には理解されよう。
【００４５】
本発明の一実施形態では、具体的には、トラフィックフローｆｄのキーワード重みベクトルｖｄは、ステップ１２で以下のｉｔｐ−ｉｄｆアルゴリズムによって検出され、トラフィックフローｆｄの第ｉのキーワードの重みはωｉｄ＝ｉｔｐｉｄ×ｉｄｆｉで表され、但し、ｉｔｐｉｄ＝１／ｏｉｄであり、ｏｉｄは、第ｉのキーワードｋｉがトラフィックフローｆｄで最初に現れる位置を表し、この位置は、ビット位置またはバイト位置でもよく、ｉｔｐｉｄはｏｉｄの逆数を表し、第ｉのキーワードｋｉがトラフィックフローｆｄで現れない場合、０の値を取ることになり：
【００４６】
【数４】
0005536280.tif 000005
但し、｜Ｆ｜は訓練トラフィックフローの総量を表し、｜｛ｆ：ｋｉ∈ｆ｝｜は第ｉのキーワードｋｉを含むトラフィックフローの量を表し、その場合、トラフィックフローｆｄのキーワード重みベクトルはｖｄ＝（ω１ｄ，ω２ｄ，．．．，ωＭｄ）で表すことができ、但し、Ｍはキーワードデータベースにおけるキーワードの総量を表す。
【００４７】
トラフィックフローについて、トラフィックフローのプロトコルの識別において重要な役割をするキーワードは通常は、トラフィックフローの有効なペイロードのヘッダ内に置かれる。本発明の一実施形態では、具体的には、トラフィックフローまたは訓練トラフィックフローのキーワード重みベクトルは、ステップＳ１２またはステップＳ２１で、トラフィックフローの有効なペイロードのヘッダ内の所定の長さの内容から判定されることになり、ただ有効なペイロードのヘッダ内の所定の長さの内容がキーワードについて探索されさえすれば十分になり、重みはその内容のみから計算される。一例として、但し限定ではなく、所定の長さは１２８バイトまたは２５６バイトである。有効なペイロードのヘッダ内の所定の長さの内容は、１つまたは複数のデータパケットで運ばれ得ることが、当業者には理解されよう。
【００４８】
図３は、本発明の一実施形態によるプロトコル識別装置の構造図である。図示するように、この実施形態におけるプロトコル識別装置１０は、第１のデバイス１１、第２のデバイス１２、第３のデバイス１３および第４のデバイス１４を含む。プロトコル識別装置１０は通常は、データ通信ネットワーク内のネットワーク機器内に配置される。
【００４９】
第１のデバイス１１は、検出されることになるデータパケットを個々のトラフィックフローに分類するように構成される。
【００５０】
第２のデバイス１２は、識別可能なアプリケーションプロトコルのキーワードデータベースに基づいてキーワードについてトラフィックフローの有効なペイロードを探索し、トラフィックフローのキーワード重みベクトルを判定するように構成され、キーワードの重みはトラフィックフローの有効なペイロード内のキーワードの位置に関連する。
【００５１】
具体的には、一例として、但し限定ではなく、識別可能なアプリケーションプロトコルのキーワードデータベース内に合計でＭ個の異なるキーワードが存在し、各識別可能なプロトコルについて、いくつかのキーワードｋｍ，ｍ∈｛１，…，Ｍ｝がそのプロトコル内に現われ得る。一例として、但し限定ではなく、ハイパーテキスト転送プロトコルのキーワードは「ｈｔｔｐ／」を含み、ファイル転送プロトコルのキーワードは「ｆｔｐ／」を含むなど。たとえば、トラフィックフローｆｄのキーワード重みベクトルは、ｖｄとして表すことができる。
【００５２】
第３のデバイス１３は、トラフィックフローのキーワード重みベクトルと識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルの間の類似度を判定するように構成される。
【００５３】
具体的には、一例として、但し限定ではなく、合計でＮ個の識別可能なプロトコルが存在し、各識別可能なプロトコルの特徴キーワード重みベクトルはＶｎ，ｎ∈｛１，．．．，Ｎ｝として表すことができる。
【００５４】
第４のデバイス１４は、所定の条件が満たされる場合、トラフィックフローのキーワード重みベクトルへの最も高い類似度を有する特徴キーワード重みベクトルに対応するアプリケーションプロトコルをそのトラフィックフローのアプリケーションプロトコルとして判定するように構成される。
【００５５】
異なる識別可能なプロトコルは、同じキーワードを有することができ、または、別法として、互いに重複しないキーワードを有することができ、ＮおよびＭの値はそれらの大きさに関して必要な関係を有さなくてもよいことが、当業者には理解されよう。好ましくは、各識別可能なアプリケーションプロトコルは、少なくとも１つの一義的キーワードを有し、そうしてＭ≧Ｎであり、したがって、それらの異なるプロトコル間の区別は改善され得る。
【００５６】
本発明の一実施形態では、具体的には、検出されることになるデータパケットは、第１のデバイス１１内で５タプルによる個々のトラフィックフローに分類され、その５タプルは、ソースアドレス、宛先アドレス、ソースポート番号、宛先ポート番号および転送プロトコルタイプを含む。ソース（ノード）と宛先（ノード）の間で同じアプリケーションのデータを運ぶためのデータパケットは、同じソースアドレス、宛先アドレス、ソースポート番号、宛先ポート番号および転送プロトコルタイプを有することになることが理解されよう。通常は、異なるアプリケーションのデータパケットは異なるソースポート番号および宛先ポート番号を有し、そして、異なるソース（ソースノード）と宛先（宛先ノード）の間のデータパケットは異なるソースアドレスおよび宛先アドレスを有する。したがって、同じ５タプル内容を有する異なるデータパケットは、一対のソースおよび宛先の間の同じアプリケーションに属することになり、同じ個々のトラフィックフローに分類されることになる。
【００５７】
本発明の一実施形態では、具体的には、第３のデバイス１３によって判定される類似度は、コサイン類似度を含む。たとえば、トラフィックフローｆｄのキーワード重みベクトルｖｄと任意の識別可能なプロトコルの特徴キーワード重みベクトルの間のコサイン類似度は、場合により以下の公式で、それぞれ計算されることになる：
【００５８】
【数５】
0005536280.tif 000006
本発明の一実施形態では、具体的には、第４のデバイス１４における所定の条件は、所定の値を上回る最も高い類似度を含む。たとえば、トラフィックフローｆｄのキーワード重みベクトルｖｄと特徴キーワード重みベクトルＶ２の間のコサイン類似度が最も高く、そして、その場合に、Ｖ２によって表されるアプリケーションプロトコルは、最も高い類似度が所定の値を上回るときに、トラフィックフローｆｄのアプリケーションプロトコルとして判定されることになり、そして、その場合に、トラフィックフローｆｄは、最も高い類似度が所定の値を下回るときに、知られていないアプリケーションとして識別されることになる、すなわち、トラフィックフローｆｄは、任意の識別可能なプロトコルに属さないものとして第４のデバイス１４によって判定されることになる。
【００５９】
本発明の一実施形態では、具体的には、トラフィックフローの有効なペイロードにおいてより早く最初に現れるキーワードは、第２のデバイス１２においてより大きな重みを有する。
【００６０】
通常は、識別プロセスは、前述の第１のデバイス１１、第２のデバイス１２、第３のデバイス１３および第４のデバイス１４によってそれぞれに実行される動作を含み、各識別可能なプロトコルの特徴キー重みベクトルは、識別プロセスに先立って訓練プロセスで判定されることになる。
【００６１】
訓練プロセスは、第２のデバイス１２によって実行され、２つのサブ動作２１および２２（図示せず）を含む。
【００６２】
サブ動作２１において、第２のデバイス１２は、識別可能なアプリケーションプロトコルのキーワードデータベースに基づいて複数の訓練トラフィックフローの有効なペイロード内のキーワードを探索し、複数の訓練トラフィックフローのキーワード重みベクトルを判定する。
【００６３】
サブ動作２２において、第２のデバイス１２は、複数の訓練トラフィックフローのキーワード重みベクトルにしたがって各識別可能なアプリケーションプロトコルに対応する特徴キーワード重みベクトルを判定する。具体的には、各訓練トラフィックフローのアプリケーションプロトコルは、事前に知られていて、そうして、同じアプリケーションプロトコルに属するすべての訓練トラフィックフローのキーワード重みベクトルが平均化されてそのアプリケーションプロトコルに対応する特徴キーワード重みベクトルを判定することができる。
【００６４】
本発明の一実施形態では、具体的には、トラフィックフローの有効なペイロードにおいてより早く最初に現れるキーワードは、第２のデバイス１２によって実行されるサブ動作２１においてより大きな重みを有する。
【００６５】
より具体的には、本発明の一実施形態では、キーワードの重みは、第２のデバイス１２によって実行されるサブ動作２１で以下のｉｔｐ−ｉｄｆ（逆テキスト位置−逆文書頻度）アルゴリズムによって検出され、第ｊの訓練トラフィックフローの第ｉのキーワードの重みは、以下のように表される：
ωｉｊ＝ｉｔｐｉｊ×ｉｄｆｉ  （１）
但し、ｉｔｐｉｊは逆テキスト位置のメトリクであり、ｉｄｆｉは逆文書頻度のメトリクであり、そして、
ｉｔｐｉｊ＝１／ｏｉｊ  （２）
但し、ｏｉｊは、第ｉのキーワードｋｉが第ｊの訓練トラフィックフローで最初に現れる位置を表し、この位置はビット位置またはバイト位置でもよく、ｉｔｐｉｊはｏｉｊの逆数を表し、第ｉのキーワードｋｉが第ｊの訓練トラフィックフローで現れない場合、０の値を取ることになり
【００６６】
【数６】
0005536280.tif 000007
但し、｜Ｆ｜は訓練トラフィックフローの総量を表し、｜｛ｆ：ｋｉ∈ｆ｝｜は第ｉのキーワードｋｉを含むトラフィックフローの量を表し、そして、その場合、第ｊの訓練トラフィックフローのキーワード重みベクトルは以下のように表すことができる：
Ｖｊ＝（ω１ｊ，ω２ｊ，．．．，ωＭｊ）  （４）
但し、Ｍはキーワードデータベースにおけるキーワードの総量を表す。
【００６７】
サブ動作２２で、第２のデバイス１２は、複数の訓練トラフィックフローのキーワード重みベクトルにしたがって各識別可能なアプリケーションプロトコルに対応する特徴キーワード重みベクトルを判定する。特定の識別可能なアプリケーションプロトコルｐについて、特徴キーワード重みベクトルは、所与の訓練トラフィックフローから計算可能であり、または以下のように表される重心ベクトルと称され得る：
【００６８】
【数７】
0005536280.tif 000008
但し、Ｆｐはプロトコルｐに属する訓練トラフィックフローのセットを表し、｜Ｆｐ｜はプロトコルｐに属する訓練トラフィックフローの量を表し、ｖｊは、そのセットＦｐ内のトラフィックフローのキーワード重みベクトルを表す。ＶｐはそのセットＦｐ内のそれぞれの訓練トラフィックフローのキーワード重みベクトルで現れるそれぞれのキーワードの重みを平均化することによって導出することができる。
【００６９】
この実施形態では、各識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルは、第２のデバイス１２によって実行されるサブ動作２１および２２で前述の公式（１）から（５）における訓練トラフィックフローに基づいて容易に計算することができる。
【００７０】
訓練トラフィックフローはまた、５タプルにしたがって多数の訓練データパケットを分類することによって生成され、その訓練トラフィックフローは各識別可能なアプリケーションのいくつかのトラフィックフローを含むことになることが、当業者には理解されよう。
【００７１】
前述の訓練プロセス、すなわち第２のデバイス１２によって実行されるサブ動作２１およびサブ動作２２、は、更新された訓練トラフィックフローが識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルを更新するたびに、定期的にまたは非定期的に繰り返され得ることが、当業者には理解されよう。新しい識別可能なアプリケーションプロトコルが更新のために特定の訓練プロセスに導入可能であり、それに応じて、キーワードデータベース内のキーワードの数は増やすことができ、更新された訓練トラフィックフローは、新たに導入された識別可能なアプリケーションプロトコルのいくつかのトラフィックフローをさらに含むことになり、そして、更新結果は新たに導入された識別可能なアプリケーションプロトコルの特徴キーワード重みベクトルをさらに含み得る。
【００７２】
第２のデバイス１２は、訓練プロセスにおけるサブ動作２１と同じアルゴリズムで識別プロセスにおいてトラフィックフローのキーワード重みベクトルを判定することになることが、当業者には理解されよう。
【００７３】
本発明の一実施形態では、具体的には、第２のデバイス１２が、識別プロセスで以下のｉｔｐ−ｉｄｆアルゴリズムによってトラフィックフローｆｄのキーワード重みベクトルｖｄを検出し、そのトラフィックフローｆｄの第ｉのキーワードの重みはωｉｄ＝ｉｔｐｉｄ×ｉｄｆｉとして表され、但し、ｉｔｐｉｄ＝１／ｏｉｄであり、ｏｉｄは第ｉのキーワードｋｉがトラフィックフローｆｄで最初に現れる位置を表し、この位置はビット位置またはバイト位置でもよく、ｉｔｐｉｄはｏｉｄの逆数を表し、第ｉのキーワードｋｉがトラフィックフローｆｄ内で現れない場合、０の値を取ることになり、但し：
【００７４】
【数８】
0005536280.tif 000009
但し、｜Ｆ｜は訓練トラフィックフローの総量を表し、｜｛ｆ：ｋｉ∈ｆ｝｜は第ｉのキーワードｋｉを含むトラフィックフローの量を表し、その場合、トラフィックフローｆｄのキーワード重みベクトルはｖｄ＝（ω１ｄ，ω２ｄ，．．．，ωＭｄ）で表すことができ、但し、Ｍはキーワードデータベースにおけるキーワードの総量を表す。
【００７５】
トラフィックフローについて、トラフィックフローのプロトコルの識別において重要な役割をするキーワードは通常は、トラフィックフローの有効なペイロードのヘッダ内に置かれる。本発明の一実施形態では、具体的には、トラフィックフローのキーワード重みベクトルまたは訓練トラフィックフローは、トラフィックフローの有効なペイロードのヘッダ内の所定の長さの内容から識別プロセスでキーワード重みベクトルを判定する動作または第２のデバイス１１の訓練プロセスにおいてサブ動作２１で判定されることになり、第２のデバイス１２がキーワードについて有効なペイロードのヘッダ内の所定の長さの内容のみを探索し、その内容のみから重みを計算すれば十分になろう。一例として、但し限定ではなく、所定の長さは１２８バイトまたは２５６バイトである。有効なペイロードのヘッダ内の所定の長さの内容は１つまたは複数のデータパケットで運ばれ得ることが、当業者には理解されよう。
【００７６】
本発明の一実施形態では、その中に前述のプロトコル識別装置１０が配置されたネットワークデバイスが提供される。本ネットワークデバイスは、たとえば、スイッチ、ルータ、ゲートウェイ、端末デバイスなどであるが、これらに限定されない。
【００７７】
本発明で、装置は、ソフトウェア機能モジュール、ハードウェアモジュールまたはそれらの組合せを含み得ることが、当業者には理解されよう。
【００７８】
前述の実施形態は例示的であり限定的ではないことが、当業者には理解されよう。異なる実施形態に現れる異なる技術的特徴は有利に組み合わせ可能である。当業者は、本図面、本明細書、および本特許請求の範囲を検討して、開示された実施形態の他の変形実施形態を理解および実装することになろう。本特許請求の範囲において、「備える」という用語は、別の１つまたは複数のデバイスあるいは１つまたは複数のステップを排除せず、不定冠詞「ａ／ａｎ」は複数形を排除せず、「第１の」、「第２の」などの用語は名前を指定するものであり任意の特定の順番を表さない。本特許請求の範囲のいずれの参照番号も、本発明の範囲を限定するものとして解釈されない。特許請求に現れる複数の部分の機能は、ハードウェアまたはソフトウェア内の別個のモジュールによって実行可能である。単にいくつかの技術的特徴が異なる従属請求項に現れるという事実が、これらの技術的特徴が有利に結合され得ないことを意味することはない。
【図１】
0005536280.tif 000014
【図２】
0005536280.tif 000015
【図３】
0005536280.tif 000016