JP2015050473A - トラヒック監視装置及びプログラム、並びに、通信装置 - Google Patents

Abstract

【課題】 トラヒックフローに係る通信アプリケーションを早期に精度良く推定できるトラヒック監視装置を提供する。
【解決手段】 本発明は、監視対象フローについて、複数種類の特徴量についてフロー開始からの値を保持する保持手段と、保持手段が保持している特徴量値の最新の値が、フロー開始から早期の段階の特徴量値の場合に、保持手段が保持している特徴量値に基づいて、所定パケット数が到来したときの特徴量値を予測する予測手段と、通信アプリケーションの種類毎に予め登録されている複数種類の特徴量値の組と、予測手段が予測した特徴量値を含む複数種類の特徴量値の組との照合により、監視対象フローに係る通信アプリケーションの種類を推定する推定手段とを有することを特徴とする。
【選択図】 図２

Description

本発明は、トラヒック監視装置及びプログラム、並びに、通信装置に関し、例えば、インターネットのようなデータ通信網のノードや端末装置において、トラヒックを監視し、暗号解読することなく流れるトラヒックに適用されている、任意の種類の暗号方式を使用している通信アプリケーション（の種類）を推定する場合に適用し得るものである。

ネットワークが加入者によってどのように利用されているか、各フローでどのような通信が行われているかを把握することは、ネットワークオペレータが設備投資の判断、フローの制御、異常監視を行う上で有用である。

しかしながら、今日の通信では、暗号化されたトラヒック（ここで、トラヒックとは通信回線を通じて送受信される情報を呼んでおり、以下、暗号化されたトラヒックを暗号トラヒックと呼ぶこととする）が増え、暗号文の中でどのような通信を行っているかの把握が困難になりつつある。また、プライバシ保護の観点から、ペイロードの内容を観測せずに、パケット長や到着間隔等の統計情報で、内容を推定したいという要求が存在する。

このような背景下で、特許文献１に記載の暗号化通信特徴抽出装置が提案されている。

この暗号化通信特徴抽出装置では、事前に、既知の暗号化方法で暗号化した暗号文を、この装置の外部通信部より発信し、この試験通信暗号データを暗号文データ収集部で収集して特徴を求めておく。次に、暗号判定機能部では、トラヒックの種別が不明な通信情報に対して、特徴情報を求め、求めた種別の不明な通信情報の特徴情報と、先に求めた既知の暗号文の特徴情報とを比較する。この比較結果が一致した場合、この種別不明なトラヒックを、どの種類の暗号化方法で暗号化された文章のトラフィックであると推定する。

この特許文献１の記載方法を用いれば、暗号化通信の種別として、使用される通信アプリケーション、暗号通信ソフト、及び暗号化プロトコルの組合せを示すことができる。使用可能な暗号化プロトコルとしては、ＷＥＢサービスの場合であればＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）を挙げることができ、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）の場合であれば、ＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）、３ＤＥＳ、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）等を挙げることができる。

また、適用できる特徴情報としては、（１）通信セッションの発生間隔、（２）通信セッション中のパケット発生間隔、（３）通信セッション中のパケットサイズ、（４）通信セッション中の総パケット数、（５）通信セッション中のパケット送受信方向の関係、（６）通信セッション中のパケット送受信数方向比、（７）通信セッション中のプロトコル占有率、（８）通信セッション開始時の各パケットサイズ、（９）通信セッション開始時の総パケット数、（１０）通信セッション開始時の総データサイズ、（１１）長期間の送信元／宛先ＩＰ分布、（１２）長期間の宛先ポート分布、（１３）長期間のＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバへの問合せの有無、（１４）通信アプリケーション側から何も通信していない時に送信されるデータの有無が挙げられる。

特開２００６−１４６０３９号公報

ところで、特許文献１の記載技術では、上述した１４種類のいずれか一つの特徴情報を用いた相関分析だけを開示し、複数の特徴情報を用いた相関分析について何も想定していない。複数の特徴情報を用いれば、判定精度が向上する可能性があるが、特許文献１は、特徴情報毎に異なる判定結果が出た場合、アプリケーションをどのように推定すれば良いかを開示も示唆もしていない。そのため、特許文献１の記載技術では、複数の特徴情報を用いた相関分析を実施することはできない。

複数の特徴情報を用いる手法として、ナイーブベイズ、すなわち、単純ベイズ判定器と呼ばれる条件付確率モデルを用いたものが提案されている。しかし、この提案手法を適用したとしても、精度には限界があった。

本発明は、以上のような課題に鑑みなされたものであり、トラヒックの特徴を早期に精度良く判定できるトラヒック監視装置及びプログラム、並びに、通信装置を提供しようとしたものである。

第１の本発明は、ネットワーク通信のトラヒックを監視するトラヒック監視装置において、（１）監視対象フローについて、複数種類の特徴量についてフロー開始からの値を保持する特徴量値保持手段と、（２）上記特徴量値保持手段が保持している特徴量値の最新の値が、所定のパケット数のパケットが到来して得た特徴量値になっていない、フロー開始から早期の段階の特徴量値の場合に、上記特徴量値保持手段が保持している特徴量値に基づいて、所定のパケット数のパケットが到来したときの特徴量値を予測する所定タイミング特徴量値予測手段と、（３）通信アプリケーションの種類毎に予め登録されている複数種類の特徴量値の組と、所定タイミング特徴量値予測手段が予測した特徴量値を含む複数種類の特徴量値の組との照合により、上記監視対象フローに係る通信アプリケーションの種類を推定するアプリケーション種類推定手段とを有することを特徴とする。

第２の本発明は、ネットワーク通信のトラヒックを中継する通信装置において、第１の本発明のトラヒック監視装置を実装していることを特徴とする。

第３の本発明のトラヒック監視プログラムは、ネットワーク通信のトラヒックを監視できるネットワーク上の位置に設けられたコンピュータを、（１）監視対象フローについて、複数種類の特徴量についてフロー開始からの値を保持する特徴量値保持手段と、（２）上記特徴量値保持手段が保持している特徴量値の最新の値が、所定のパケット数のパケットが到来して得た特徴量値になっていない、フロー開始から早期の段階の特徴量値の場合に、上記特徴量値保持手段が保持している特徴量値に基づいて、所定のパケット数のパケットが到来したときの特徴量値を予測する所定タイミング特徴量値予測手段と、（３）通信アプリケーションの種類毎に予め登録されている複数種類の特徴量値の組と、所定タイミング特徴量値予測手段が予測した特徴量値を含む複数種類の特徴量値の組との照合により、上記監視対象フローに係る通信アプリケーションの種類を推定するアプリケーション種類推定手段として機能させることを特徴とする。

本発明によれば、トラヒックフローに係る通信アプリケーションを早期に精度良く推定することができる。

実施形態のトラヒック監視装置とネットワークとの関係を示す説明図である。 実施形態のトラヒック監視装置の機能的な構成を示すブロック図である。 実施形態のトラヒック監視装置における特徴量保持部が保持しているデータの構成を示す説明図である。 実施形態のトラヒック監視装置が適用しているパラメタ例の説明図である。 実施形態のトラヒック監視装置における特徴量収束予測部からアプリケーション推定部に引き渡される情報の説明図である。 実施形態のトラヒック監視装置における特徴量収束予測部による所定パケット数到来時のパラメタ値の予測方法の説明図である。 実施形態のトラヒック監視装置におけるフロー制御変更指令部に記憶されているアプリケーションの種類毎の変更制御内容の例を示す説明図である。 実施形態のトラヒック監視装置における通信制御部が内部管理する制御内容を変更するフローに関する情報を示す説明図である。 実施形態のトラヒック監視装置における特徴量収束予測部の予測処理の流れを示すフローチャートである。

（Ａ）主たる実施形態
以下、本発明によるトラヒック監視装置及びプログラム、並びに、通信装置の一実施形態を、図面を参照しながら説明する。実施形態に係るトラヒック監視装置は、主として、暗号トラヒックを監視するものである。

（Ａ−１）実施形態の構成
図１は、実施形態に係るトラヒック監視装置１と、ネットワークとの関係を示す説明図である。実施形態に係るトラヒック監視装置１は、データパケット（以下、ＩＰパケットとする）を転送する通信装置に関連して設けられる。例えば、ネットワークＮＡ〜ＮＺ間の境界に位置するゲートウェイ装置に、実施形態のトラヒック監視装置１が搭載される通信装置である。

図２は、実施形態のトラヒック監視装置１の機能的な構成を示すブロック図である。ここで、実施形態のトラヒック監視装置１は、ハードウェア的に各種回路を接続して構築されたものであっても良く、また、ＣＰＵ、ＲＯＭ、ＲＡＭなどを用いてトラヒック監視プログラムを実行することで該当するトラヒック監視機能を実現するように構築されたものであっても良く（この場合であっても、後述する通信入力部１０や通信出力部１３の一部はハードウェアで構成することを要する）、いずれの構築方法が適用された場合であっても、機能的には、図２で表すことができる。

図２において、実施形態のトラヒック監視装置１は、通信入力部１０、推定対象フロー抽出部１１、通信制御部１２、通信出力部１３、特徴量保持部１４、特徴量収束予測部１５、アプリケーション推定部１６及びフロー制御変更指令部１７を有する。

通信入力部１０は、ネットワークに接続されていて、トラヒックが入力され、入力されたトラヒックを推定対象フロー抽出部１１に渡すものである。

推定対象フロー抽出部１１は、暗号化フローと非暗号化フローを選別し、各暗号化フローに関する特徴量（パラメタ）を計測し、暗号化フローに関するフローの特定情報と特徴量を特徴量保持部１４に与え、特徴量が計測された暗号化フローの情報を通信制御部１２に与えるものである。

ここで、暗号化フローとは、そのフローのデータパケットにおけるヘッダ及びペイロード（あるいはその一部）が暗号化されているフローを呼び、非暗号化フローとは、そのフローのデータパケットが暗号化されていないフローを呼ぶこととする。さらに、ここで暗号化とは、必ずしも良く知られた暗号を用いた符号化処理でなくても良く、一般的な通信で利用されるヘッダとペイロードを含んだパケットの難読化処理、あるいは独自符号化のような処理を加えることによって本来の通信内容がわからないように加工された処理のことも含むものとする。

トラフィック監視装置１は、非暗号化フローのトラヒックをも監視するものであるが、非暗号化フローのトラヒックの監視機能は、従来装置と同様であるので、以下では、暗号化フローのトラフィックについての機能を説明する。

推定対象フロー抽出部１１は、新たな暗号化フローを認識した場合には、フローの識別情報（ＩＤ；数字列に限定されない）の採番を行い、フローの両端ノードのＩＰアドレスとフローＩＤをフローの特定情報とし、所定情報を特徴量保持部１４及び通信制御部１２に与える。

なお、推定対象フロー抽出部１１が、非暗号化フローの特徴量を計測して特徴量保持部１４に与え、後述する暗号化フローに対する処理を、非暗号化フローに対して行うようにしても良いことは勿論である。

特徴量保持部１４は、暗号化フローのそれぞれに対して、フローの特定情報に対応付けて特徴量を管理するものである。図３は、特徴量保持部１４が保持しているデータの構成を示す説明図である。特徴量保持部１４は、例えば、フローＩＤに対応付けて、フローの一方のノードのＩＰアドレス、他方のノードのＩＰアドレス、フロー開始時刻、フロー開始からのパケット数、複数種類のパラメタのフロー開始からの値を管理する（パラメタ値に関してはその代表値をも管理するようにしても良い）。特徴量保持部１４は、例えば、図３に示すように、表形式で各暗号化フローの特定情報と特徴量を管理し、フローの終了後にはエントリーを削除する（フローの終了判定の一例としては、フローの開始時間から十分に時間が経過していてデータパケットが到来しないことを挙げられる）。

図４は、この実施形態のトラヒック監視装置１が適用しているパラメタの説明図である。図４は、計４９種類のパラメタを示しているが、パラメタの組はこれに限定されるものではない。

パラメタは、大きくは、パケットサイズと、パケット到着間隔と、フロー情報とに関するものである。

パケットサイズについては、一方の転送方向（以下、順方向と呼ぶ）のデータパケットについてのパケットサイズのパラメタと、他方の転送方向（以下、逆方向と呼ぶ）のデータパケットについてのパケットサイズのパラメタと、両転送方向（以下、両方向と呼ぶ）のデータパケットについてのパケットサイズのパラメタとがある。パケットサイズのパラメタは、最小値、２５％値、５０％値、平均値、７５％値、最大値及び分散値がある。ここで、２５％値、５０％値、７５％値はそれぞれ、全てのパケットサイズの値を小さい順に並べた場合において、小さい方から２５％、５０％、７５％に位置するパケットサイズの値である。従って、５０％値は、中央値（メディアン）と同じものである。

パケット到着間隔についても、順方向、逆方向、両方向のデータパケットについてのパラメタがある。パケット到着間隔のパラメタは、最小値、２５％値、５０％値、平均値、７５％値、最大値及び分散値がある。

フロー情報についてのパラメタは、順方向及び逆方向については、合計パケット数、合計バイト数及び転送時間であり、両方向については転送時間である。ここで、転送時間とは、該当する方向（両方向を含む）のフローの開始時刻から最新のパケットが当該トラヒック監視装置１に到着した時刻までの時間である。

特徴量収束予測部１５は、各種類のパラメタについて、特徴量保持部１４が管理しているフロー開始時点からのパラメタ値を基に、パラメタの変化傾向を捉えて、収束状態になっていると思われる所定パケット数（例えば、１８０パケット目）のパケットが到来したと仮定したときのパラメタ値を予測し、フローの特定情報と共に、アプリケーション推定部１６に与えるものである。なお、当該トラヒック監視装置１に既に所定パケット数のパケットが到来した以降においては、特徴量収束予測部１５は、実測したパラメタ値をアプリケーション推定部１６に与える。

図５は、特徴量保持部１４が上述した図３の情報を保持している場合において、特徴量収束予測部１５からアプリケーション推定部１６に引き渡される情報の説明図である。各パラメタについて、予測されたパラメタ値若しくは実測されたパラメタ値が特徴量収束予測部１５からアプリケーション推定部１６に引き渡される。図５の例の場合、フローＩＤが「１」のフローは到来パケット数が２０であり、フローＩＤが「２」のフローは到来パケット数が３０であるので、両フロー共に、予測されたパラメタ値が特徴量収束予測部１５からアプリケーション推定部１６に引き渡される。なお、文字列「ｐａｒａｍｅｔｅｒ」と数字列「１」、「２」、…でなるパラメタを区別する名称の最後に「＃」を付与することにより、引き渡されたパラメタ値が予測値であることをアプリケーション推定部１６が認識し得るようになされている。

図６は、特徴量収束予測部１５における所定パケット数でのパラメタ値の予測方法の説明図である。パラメタ値は、そのパラメタ値を算出するパケット数がある程度のパケット数より多くなると同じような値をとる収束状態になる。収束状態に至るまでは、算出に供するパケット数が多くなるについてパラメタ値は変化する。図６（Ａ）は、パケット数が１０パケット増える毎にパラメタ値をプロットした図であり、パケット数が多くなるについてパラメタ値の増加率が大きくなる変化傾向を有している。図６（Ｂ）に示すように、複数の予測用関数（図６は７つの例を示している）を用意しておき、今回のパラメタ値の変化にフィットする予測用関数を選択すると共に、図６（Ｃ）に示すように、その関数の係数などをアレンジし、その後、予測用関数に収束状態を捉えるためのパケット数Ｂを入力して、所定パケット数（収束状態）におけるパラメタ値Ａを予測する。

なお、図６（Ｂ）は収束状態に至るまでの変化傾向を示しており、図示は省略しているが、収束状態では、図６（Ｂ）における右端の値と同様な値を維持する。

タイプ１〜タイプ３の予測用関数は、算出パケット数が多くなるに従って、算出されるパラメタ値が大きくなる場合に適用して好適な関数であり、それぞれ、増加率が、一定、漸増、漸減の関数である。タイプ４〜タイプ６の予測用関数は、算出パケット数が多くなるに従って、算出されるパラメタ値が小さくなる場合に適用して好適な関数であり、それぞれ、減少率が、一定、漸減、漸増の関数である。タイプ７の予測用関数は、先頭の数パケットではそのパラメタ値が不安定であるが、その後、安定した値をとるパラメタに適用して好適な関数であり、先頭の数パケットを除外させる関数である。図４の例とは合致しないが、例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）の３ウェイハンドシェイクに係る当初の数パケットは、特定の統計量（特徴量）を乱すものとなっている。

特徴量収束予測部１５は、適用する予測用関数を選別することを行うものであるが、パラメタの種類によっては、適用する予測用関数を予め定めておくようにしても良い。パラメタ値の収束値を予測するパケット数（図６（Ｃ）のＢ参照）も、パラメタの種類を問わず、同じパケット数を適用しても良く、また、パラメタの種類に応じて変えるようにしても良い。

図６は、予測用関数として７タイプを用意しておく場合を示したが、予測用関数の対応数はこれより多くても少なくても良い。また、増加率や減少率の変化傾向が途中で切り替わるような予測用関数を用意しておいても良い。例えば、前半が図６（Ｂ）のタイプ１でそれより先がタイプ３のような変化傾向を有する予測用関数を用意しておくようにしても良い。

アプリケーション推定部１６は、フローの特定情報と共に、所定パケット数に係る予測された若しくは実測されたパラメタ値の組が与えられたとき、各アプリケーションについて予め登録されている所定パケット数におけるパラメタ値の組（以下、教師データと呼ぶこともある）と照合し、照合結果が最も良好なアプリケーションの種類を、そのフローで適用されているアプリケーションの種類と推定し、フローの特定情報と推定したアプリケーションの種類の識別情報（ＩＤ）の対をフロー制御変更指令部１７に通知するものである。通知するフローの特定情報は、例えば、フローＩＤである。

アプリケーション推定部１６として、例えば、ＳＶＭ（Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ）等の汎用的な教師有り学習・識別器を適用することができる。教師データは、アプリケーションが既知な状態で、特徴量収束予測部１５に予測動作させて得られた所定パケット数におけるパラメタ値の組であり、アプリケーションの種類情報に対応付けられて、アプリケーション推定部１６に入力されて登録されたものである。

図４では、パラメタの種類数が４９種類の例を示したが、アプリケーション推定部１６がアプリケーションの推定に用いるパラメタは４９種類全てであっても良く、４９種類の一部（例えば２０種類程度）のパラメタをアプリケーションの推定に用いるようにしても良い。アプリケーションの種類によって、推定（教師データとの照合）に用いるパラメタの数や種類を切り替えるようにしても良い。このような場合であれば、照合するパラメタの種類を特定できるように、教師データを構成しておくことを要する。

ここで、アプリケーションとは、転送しようとするデータからＩＰパケットを組み立てる処理、及び、その逆処理を行う通信アプリケーションであり、暗号化処理だけでなく、その他の処理（例えば、誤り訂正処理など）を行うものである。適用している暗号化の種類や、他の処理の種類や、取り扱うデータの種類（音声、画像、データ）等によって、アプリケーションは様々である。

フロー制御変更指令部１７は、アプリケーションの識別情報（ＩＤ）毎にフローに対する制御内容を記憶しており、アプリケーション推定部１６から、フローＩＤと推定したアプリケーションのＩＤとが与えられたとき、通信制御部１２に、そのフローＩＤのフローに対して適用するアプリケーションの種類を特定するアプリケーションＩＤを通知するものである。フロー制御変更指令部１７は、デフォルトの制御内容から変更する内容だけを記述している。

例えば、ストリーミング系のアプリケーションと、音声通信のアプリケーションとでは、パケットロスによる影響度が異なる。ネットワーク仮想化に対応しているアプリケーションは、転送するネットワークも仮想化対応ものであることが好ましい。Ｐ２Ｐのアプリケーションは通信速度が低くても構わない。このようにアプリケーションの種類により要求事項が異なっており、推定されたアプリケーションの種類に好適な通信制御を通信制御部１２が実行し得るように、フロー制御変更指令部１７が制御内容を見直すこととした。

図７は、アプリケーションの種類と、その種類に対する通信制御の内容の例（制御ルール）を示す説明図である。通信制御の内容は、優先度付け、帯域制御、パケット破棄、転送先の設定等である。

例えば、推定されたアプリケーションの種類が、アプリケーションＩＤが「１」のアプリケーション種類であれば（条件部）、フローの優先度を「Ａ」に高めると共に、転送先のネットワークを「ＮｅｔｗｏｒｋＡ」にする（アクション部）制御ルールを適用する。また、例えば、推定されたアプリケーションの種類が、アプリケーションＩＤが「３」のアプリケーション種類であれば、フローの優先度を「Ｚ」に低めると共に、そのフローのパケットを１０，０００パケット毎に１パケットずつ強制廃棄する（廃棄率は０．０１％）制御ルールを適用する。さらに、例えば、推定されたアプリケーションの種類が、アプリケーションＩＤが「４」のアプリケーション種類であれば、上限帯域（可用帯域）を２００ｋｂｐｓとするシェーピングを行うと共に、転送先のネットワークを「ＮｅｔｗｏｒｋＣ」にする制御ルールを適用する。さらにまた、例えば、推定されたアプリケーションの種類が、アプリケーションＩＤが「５」のアプリケーション種類であれば、優先度の変更等をなにもせずに、デフォルトの制御をそのまま適用する制御ルールを適用する。なお、デフォルトの制御を適用する場合であれば、フロー制御変更指令部１７が、通信制御部１２に制御指令を与えないようにすれば良い。

通信制御部１２は、推定対象フロー抽出部１１からフロー（のパケット）を受け取り、そのフローが、フロー制御変更指令部１７が制御内容の変更を指令したフローチャートであるか確認し、制御内容を変更するフローである場合には、そのフローについて推定されたアプリケーションの種類の通信制御を行うものである。

図８は、通信制御部１２が内部管理する制御内容を変更するフローに関する情報を示す説明図である。

通信制御部１２は、フローのＩＤに対応付けて、そのフローについて推定されたアプリケーションのＩＤと、当該エントリーを削除するまでの残り時間とを管理している。通信制御部１２は、入力されたフローが、管理しているＩＤを有するとき、それに対応付けられたアプリケーションＩＤを取出し、取出したアプリケーションＩＤをフロー制御変更指令部１７に与えて、推定アプリケーションに対する制御内容を取り込んで、入力されたフローに対して、取り込んだ制御内容の通信制御を行う。通信制御には直接関係しないが、通信制御部１２は、残り時間が０になると、当該エントリーを削除する。

なお、通信制御部１２が、アプリケーション種類毎の制御内容をも管理しておき、フローＩＤが入力された際に、フロー制御変更指令部１７に問い合わせを行うことなく、該当する通信制御を行うようにしても良い。

通信出力部１３は、１つ以上の外部ネットワークに接続され、通信入力部１０に入力されたフローを、転送するネットワークを選択して出力するものである。通信出力部１３は、フローの送信先ＩＰアドレスで定まるネットワークを選択することを基本としながら、制御内容で転送先となるネットワークが規定されている場合には、規定されているネットワークにフローを出力する。

（Ａ−２）実施形態の動作
次に、以上のような構成を有する実施形態のトラヒック監視装置１の動作を説明する。

当該トラヒック監視装置１は、ネットワークに接続されるとトラヒック監視装置として動作を開始し、パケットを受信し始める。

受信されたパケットは、通信入力部１０に入力され、当該トラヒック監視装置１を搭載した通信装置が中継する適切なパケットであれば、推定対象フロー抽出部１１に与えられる。

推定対象フロー抽出部１１においては、暗号化フローと非暗号化フローとが選別され、暗号化フローに関するパラメタが計測され（算出動作を伴うこともある）、各種のパラメタ値が、フローの特定情報と共に特徴量保持部１４に与えられる。例えば、入力されたフローのヘッダ情報を用いてペイロードが判別できないフローは、推定対象フロー抽出部１１によって、暗号化フローと判定される。また例えば、単純な分類手法（例えば、統計学的クラス分類器とみなされているＣ４．５決定木等を利用する）によって、フロー情報を元に暗号化の有無を判別し、暗号化フローを認識する。

フロー開始時点からの暗号化フローについてのパラメタ値は、フロー毎に、特徴量保持部１４において保持される。なお、パケットが所定時間の送られてこないエントリー（フローのパラメタ値群）や開始時間から十分な時間がたったエントリー（フローのパラメタ値群）については、特徴量保持部１４から削除される。なお、フローの開始時点から所定パケット数（例えば、１８０パケット程度）のパケットが到来したフローについては、特徴量保持部１４を、実測値のみ保持するように切り替える。

所定パケット数でのパラメタ値を予測するために、統計量保持部１４がフロー開始からさほど経過していない段階のパラメタ値を保持しているときには、特徴量収束予測部１５によって、所定パケット数でのパラメタ値が予測される。

図９は、ある一つのパラメタに対する、特徴量収束予測部１５の処理を示すフローチャートである。特徴量収束予測部１５は、そのフローに係る新たなパケットが到来する毎に図９に示す処理を実行するようにしても良く、また、複数パケット（例えば、１０パケットや２０パケット）の到来毎に、図９に示す処理を実行するようにしても良い。

特徴量収束予測部１５は、新たなパラメタ値の予測処理（予測しない場合を含む）が必要となると、図９に示す処理を開始し、予測が不要なパラメタか否かを判別する（ステップ１００）。

予測が不要なパラメタであれば、特徴量収束予測部１５は、図９に示す一連の処理を直ちに終了する。

予測が必要なパラメタであれば、特徴量収束予測部１５は、先頭ｙパケットを除外するパラメタか否かを判別する（ステップ１０１）。すなわち、図６（Ｂ）のタイプ７のパラメタか否かを判別する。先頭ｙパケットを除外するパラメタであれば、特徴量収束予測部１５は、今回の到来パケットが先頭ｙパケットを超えているか否かを判別する（ステップ１０２）。今回の到来パケットが先頭ｙパケットを超えていなければ、特徴量収束予測部１５は、今回の到来パケットを除外した後（ステップ１０３）、図９に示す一連の処理を終了し、一方、今回の到来パケットが先頭ｙパケットを超えていれば、特徴量収束予測部１５は、アプリケーション推定部１６が参照するパラメタ値を、先頭ｙパケットを超えた以降のパケットの情報を基に算出したパラメタ値に更新し（ステップ１０４）、図９に示す一連の処理を終了する。

先頭ｙパケットを除外するパラメタでなければ、特徴量収束予測部１５は、今回のパケットを含めたフローの到来パケット数が、実測値を適用する境界パケット数（先頭ｚパケット）を超えているか否かを判別する（ステップ１０５）。今回の到来パケットが先頭ｚパケットを超えていなければ、特徴量収束予測部１５は、アプリケーション推定部１６が参照するパラメタ値を、図６を用いて上述した予測処理で得たパラメタ値に更新した後（ステップ１０６）、図９に示す一連の処理を終了し、一方、今回の到来パケットが先頭ｚパケットを超えていれば、特徴量収束予測部１５は、アプリケーション推定部１６が参照するパラメタ値を、実測したパラメタ値に更新し（ステップ１０７）、図９に示す一連の処理を終了する。

図９の処理における先頭ｙパケットの「ｙ」は、例えば、１８０より小さい値であって、例えば、１０程度の値を適用できる。また、図９の処理における先頭ｚパケットの「ｚ」は、例えば、１８０程度の値を適用できる。先頭ｚパケットは、パラメタの種類によって異なるようにしても良い。同様に、先頭ｙパケットも、同じタイプ７のパラメタではあるがパラメタの種類によって異なるようにしても良い。

ステップ１０６で、パラメタ値を予測する方法は、上述した通りである（図６参照）。

以上のようにして、今回の受信パケットに係るフローについて、複数種類のパラメタ値（予測値若しくは実測値）が得られると、アプリケーション推定部１７によって、学習されたパラメタ値群と照合され、フローに対応するアプリケーションの種類が推定される。そして、推定されたアプリケーションの種類に適する制御内容が、フロー制御変更指令部１７によって認識され、通信制御部１２によって、今回の受信パケットに係るフローに対して、認識された通信制御が実行される。

なお、パラメタ値の更新やアプリケーション種類の推定が、所定数のパケットの到来毎に行われる場合であれば、更新や推定が実行されないタイミングで到来したパケットは、直前に推定されたアプリケーションの種類に応じて、通信制御部１２による通信制御が施される。

通信制御部１２により通信制御されたトラヒック（パケット；但し、廃棄されたパケットを除く）は、通信出力部１３によって、適切な外部ネットワークに向けて送出される。

（Ａ−３）実施形態の効果
上記実施形態によれば、暗号トラフィックを取扱うアプリケーションの種類を推定することにより、アプリケーションの種類に適した通信制御を適切に実施することができる。すなわち、優先度付けや帯域制御を行うことができ、オペレーティングにかかるコストや、設備投資にかかるコストを削減することができる。

この際、パケットの到来数が少ないフローの開始からさほど期間が経過していない段階でも、各種類のパラメタの収束値を予測してアプリケーションの種類を推定するようにしたので、フロー開始から早い段階でフローの制御を行うことができる。このような迅速な制御により（例えば、優先度の低いフローを早期に判別して優先度の高いフローを早期に優先させることにより）、ユーザの体感品質を早期に向上させることができる。

アプリケーションの種類を早期に推定するようにしても、推定に供するパラメタの種類が多い上、予測用関数のタイプとしても種々のものを用意して選別できるようにしたので、アプリケーションの種類の推定精度を十分高いものとすることができる。

（Ｂ）他の実施形態
上記実施形態の説明においても、種々変形実施形態に言及したが、さらに、以下に例示するような変形実施形態を挙げることができる。

上記実施形態では、アプリケーションの種類を推定した後、推定したアプリケーションの種類に応じた通信制御を実行するものを示したが、アプリケーションの種類の推定結果を得る装置として、トラヒック監視装置を構築するようにしても良い。例えば、どのようなトラヒックが流れているかをモニタリングする装置であれば、通信制御を行う機能を持っていなくても良い。また、トラヒック情報を収集する装置が複数あり、それらから、一つのトラヒック監視装置に収集情報を転送してトラヒックの監視を行うようにしても良い。

上記実施形態では、トラヒック監視装置がパケットを転送する通信装置に搭載される場合を示したが、トラヒック監視装置が通信装置と異なる装置として構築され、通信装置からトラヒック情報が与えられてトラヒックを監視するものであっても良い。この場合、監視のリアルタイム性は損なわれるが、例えば、どのようなトラヒックが流れているかをモニタリングする場合であれば、リアルタイム性が多少損なわれても問題となることはない。

以上から明らかなように、アプリケーションの推定結果の利用の仕方は、実施形態の方法に限定されるものではない。

上記実施形態では、アプリケーションの種類の推定対象のフローについて、十分な数のパケットが到来していない段階では、タイプ別の予測用関数を用いて、到来数より多い所定パケット数でのパラメタの予測値を求め、それを適用して、アプリケーションの種類を推定するものを示したが、タイプ情報そのものを利用して、アプリケーションの種類を推定するようにしても良い。例えば、タイプ１〜タイプ７をそれぞれ数値化し、今までに到来したパケット数から求めたＮ個のパラメタのタイプの組み合わせをベクトル表記し、そのベクトルを、予め登録されている教師データとしてのベクトルと照合することにより、アプリケーションの種類を推定するようにしても良い。

上記実施形態では、パラメタの多くが統計量であるものを示したが、アプリケーションの推定に利用するパラメタは統計量に限定されるものではなく、統計量以外でも、アプリケーション毎の特徴を表すものであればパラメタとして用いることができる。また、パラメタは時間と共に変化しないものであっても良い。例えば、送信元又は宛先のＩＰアドレスが属するドメイン名などをアプリケーションの推定に利用することもできる。到来数より多い所定パケット数での予測値を求めるパラメタ以外のパラメタも、アプリケーションの種類の推定に用いるようにしても良い。

上記実施形態では、各フローについて、パケットが到来する毎にパラメタ値を得て保持するものを示したが、パラメタ値を得る間隔はこれより長くても良い。例えば、２パケット毎にパラメタ値を得て保持するようにしても良い。また例えば、ある閾値のパケット数までは、パケットが到来する毎にパラメタ値を得て保持し、閾値のパケット数を超えた以降は、２パケット毎にパラメタ値を得て保持するようにしても良い。

本発明は、フローのパケットの中身を解析することなく、そのフローのアプリケーションの種類を推定することを特徴とするものである。そのため、非暗号化フローの中身を解析しないでアプリケーションの種類を推定する場合にも、本発明を適用することができる。

１…トラヒック監視装置、１０…通信入力部、１１…推定対象フロー抽出部、１２…通信制御部、１３…通信出力部、１４…特徴量保持部、１５…特徴量収束予測部、１６…アプリケーション推定部、１７…フロー制御変更指令部。

Claims (6)

1. ネットワーク通信のトラヒックを監視するトラヒック監視装置において、
   監視対象フローについて、複数種類の特徴量についてフロー開始からの値を保持する特徴量値保持手段と、
   上記特徴量値保持手段が保持している特徴量値の最新の値が、所定のパケット数のパケットが到来して得た特徴量値になっていない、フロー開始から早期の段階の特徴量値の場合に、上記特徴量値保持手段が保持している特徴量値に基づいて、所定のパケット数のパケットが到来したときの特徴量値を予測する所定タイミング特徴量値予測手段と、
   通信アプリケーションの種類毎に予め登録されている複数種類の特徴量値の組と、所定タイミング特徴量値予測手段が予測した特徴量値を含む複数種類の特徴量値の組との照合により、上記監視対象フローに係る通信アプリケーションの種類を推定するアプリケーション種類推定手段と
   を有することを特徴とするトラヒック監視装置。
2. 暗号化フローを監視対象フローとして抽出するフロー抽出手段をさらに備えることを特徴とする請求項１に記載のトラヒック監視装置。
3. 通信アプリケーションの種類と、フローに対する通信制御の内容とを対応付けて管理する制御内容管理手段と、
   上記アプリケーション種類推定手段によって種類が推定された通信アプリケーションのフローに対し、上記制御内容管理手段で管理されている内容の通信制御を実行する通信制御手段をさらに備えることを特徴とする請求項１又は２に記載のトラヒック監視装置。
4. 上記所定タイミング特徴量値予測手段は、上記特徴量値保持手段が保持している特徴量値の最新の値が、所定のパケット数より多いパケットが到来して得た特徴量値になっている場合に、その特徴量値を、上記アプリケーション種類推定手段が用いるようにすることを特徴とする請求項１〜３のいずれかに記載のトラヒック監視装置。
5. ネットワーク通信のトラヒックを中継する通信装置において、
   請求項１〜４のいずれかに記載のトラヒック監視装置を実装していることを特徴とする通信装置。
6. ネットワーク通信のトラヒックを監視できるネットワーク上の位置に設けられたコンピュータを、
   監視対象フローについて、複数種類の特徴量についてフロー開始からの値を保持する特徴量値保持手段と、
   上記特徴量値保持手段が保持している特徴量値の最新の値が、所定のパケット数のパケットが到来して得た特徴量値になっていない、フロー開始から早期の段階の特徴量値の場合に、上記特徴量値保持手段が保持している特徴量値に基づいて、所定のパケット数のパケットが到来したときの特徴量値を予測する所定タイミング特徴量値予測手段と、
   通信アプリケーションの種類毎に予め登録されている複数種類の特徴量値の組と、所定タイミング特徴量値予測手段が予測した特徴量値を含む複数種類の特徴量値の組との照合により、上記監視対象フローに係る通信アプリケーションの種類を推定するアプリケーション種類推定手段と
   して機能させることを特徴とするトラヒック監視プログラム。

Images