特許 7412363 データストリームのプロトコルの識別

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-28

(45)【発行日】2024-01-12

(54)【発明の名称】データストリームのプロトコルの識別

(51)【国際特許分類】

   H04L 43/18 20220101AFI20240104BHJP

【ＦＩ】

H04L43/18

【請求項の数】 9

(21)【出願番号】P 2020572750

(86)(22)【出願日】2019-07-05

(65)【公表番号】

(43)【公表日】2021-10-28

(86)【国際出願番号】 FR2019051682

(87)【国際公開番号】W WO2020008159

(87)【国際公開日】2020-01-09

【審査請求日】2022-06-20

(31)【優先権主張番号】1856240

(32)【優先日】2018-07-06

(33)【優先権主張国・地域又は機関】FR

(73)【特許権者】

【識別番号】518166243

【氏名又は名称】コスモス・テック

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】ジェローム・トレ

【審査官】宮島 郁美

(56)【参考文献】

【文献】米国特許出願公開第２０１６／０１４９７９２（ＵＳ，Ａ１）

【文献】米国特許第０９１１２９１５（ＵＳ，Ｂ２）

【文献】米国特許出願公開第２０１４／０２８２８２３（ＵＳ，Ａ１）

【文献】国際公開第２０１４／１５１５９１（ＷＯ，Ａ２）

【文献】特表２００５－５３７７０５（ＪＰ，Ａ）

【文献】米国特許出願公開第２００６／０１０６５８３（ＵＳ，Ａ１）

【文献】国際公開第２００４／０１７５９５（ＷＯ，Ａ２）

【文献】特表２００３－５２４３１７（ＪＰ，Ａ）

【文献】米国特許第０６６５１０９９（ＵＳ，Ｂ１）

【文献】欧州特許出願公開第０１７８８４８９（ＥＰ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ１２／００－１２／６６，１３／００，４１／００－４９／９０５７，６１／００－６５／８０，６９／００－６９／４０

(57)【特許請求の範囲】

【請求項1】

電気通信ネットワークの2つのエンティティ（111；112）間で交換されるデータストリームのプロトコルを識別するための方法であって、前記方法は、
前記データストリームのデータを受信するステップ（200）と、前記データストリームのプロトコルを識別するために前記データストリームを構文解析するステップ（202）と、
前記構文解析によって前記データストリームの前記プロトコルを識別することに失敗した場合（203）、プロトコルを対応するシグネチャと照合するシグネチャエンジンを参照するステップ（206）と、前記データストリームのプロトコルを識別するために前記データストリームに前記シグネチャを順次適用するステップ（207）と、を含む方法。

【請求項2】

前記シグネチャエンジンを参照することによって前記データストリームの前記プロトコルを識別することに失敗した場合（208）、前記データストリームの前記プロトコルを識別するために統計的プロトコル認識方法を適用するステップ（209）をさらに含む、請求項1に記載の方法。

【請求項3】

前記識別されたプロトコルはアプリケーションレベルのプロトコルである、請求項1または2に記載の方法。

【請求項4】

前記構文解析による前記データストリームの前記プロトコルの識別に成功した場合（203）、前記方法は、前記識別されたプロトコルに応じて前記データストリームのコンテキスト要素にワンパスアルゴリズムを適用することによってプロトコルデータを識別するステップ（204）をさらに含む、請求項1から3のいずれか一項に記載の方法。

【請求項5】

前記ワンパスアルゴリズムを適用することによってプロトコルデータを識別することに失敗した場合、前記方法は、プロトコルデータを対応するシグネチャと照合するシグネチャエンジンを参照するステップ（206）と、前記データストリームのプロトコルデータを識別するために前記シグネチャを前記データストリームに順次適用するステップ（207）と、をさらに含む、請求項4に記載の方法。

【請求項6】

前記データストリームの前記識別されたプロトコルに基づいて前記データストリームを処理するステップ（205）をさらに含む、請求項1から5のいずれか一項に記載の方法。

【請求項7】

前記データストリームの前記処理（205）は、
前記識別されたプロトコルに応じてサービス品質ポリシーを適用するステップ、または
前記識別されたプロトコルに基づいて前記データストリームを許可もしくは禁止するステップ、のうちの少なくとも一方を含む、請求項6に記載の方法。

【請求項8】

プロセッサによって実行されると、請求項1から7のいずれか一項に記載の方法の実施を可能にするための命令を含むコンピュータプログラム記録媒体。

【請求項9】

電気通信ネットワークの2つのエンティティ間で交換されるデータストリームのプロトコルを識別するためのデバイスであって、前記デバイスは、
前記データストリームのデータを受信するように構成されたインターフェース（302）と、
プロセッサ（304）であって、
前記データストリームのプロトコルを識別するために前記データストリームを構文解析し、
前記構文解析によって前記データストリームの前記プロトコルを識別することに失敗した場合、プロトコルを対応するシグネチャと照合するシグネチャエンジンを参照し、前記データストリームのプロトコルを識別するために前記データストリームに前記シグネチャを順次適用する、ように構成されたプロセッサ（304）と、を含むデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、電気通信ネットワークにおけるデータの処理、特にデータストリームプロトコルの認識に関する。

【0002】

より具体的には、電気通信ネットワーク、例えばインターネットストリームを介して伝達されるデータストリームを監視および分類するためのアプリケーションに関する。

【0003】

以下、「データストリーム」とは、2つのネットワークエンティティの間、例えばクライアントとサーバーとの間、または2つのクライアントの間（ピアツーピアまたはP2Pストリームとして知られている）で交換されるデータのセットを意味する。

【背景技術】

【0004】

データストリームをフィルタリングし、ストリームを分類して、データストリームをその分類に基づいて処理できるようにするために、データフォーマットまたは前記データを搬送するために使用されるプロトコルを検出するために様々なデータストリーム分類方法を適用することは、公知の実施である。

【0005】

この目的のために、ストリームアナライザは、Wi－Fiホットスポット、ファイアウォール、プロキシサーバーなどのネットワークアクセスポイントでの傍受用に配置され得る。

【0006】

ファイアウォールでは、セキュリティシステムの構成は、特定の種類の転送を防ぐために、特定のプロトコルのプロパティの認識に基づくことができる。したがって、データストリームアナライザは、認識されたプロトコルに基づいてデータストリームの分類をファイアウォールに提供することを可能にする。

【0007】

例えば、図1を参照すると、2つの（クライアントおよび／またはサーバー）エンティティ間のトラフィックを解析するためのシステムは、（例えば、クライアントタイプの）第1のエンティティ112を含む第1のネットワーク100を含み、通信リンク120によって、（例えば、サーバタイプの）第2のエンティティ111を含む第2のネットワーク110に接続されている。リンク120は、第1のネットワーク100と第2のネットワーク110との間の両方向または単一方向のトラフィックを測定および解析するアナライザ300によって解析される。ネットワーク100とネットワーク110との間のトラフィックは、社内ネットワークではギガビット／秒、Gbpsのオーダーであり得るが、事業者のネットワークのコアでは約10Gbpsに達する可能性がある。

【0008】

さらに、電気通信ネットワークを介して伝達されるデータの量は、リソースの観点から解析と分類にコストをかける。

【0009】

アナライザ300の測定および解析能力は、同時ストリームの数Nおよび各ストリームのビットレートTによって決定される。Nは記録されたストリームのコンテキストを管理するために必要なメモリの量に直接影響するが、Tは重大なパケット損失やストリームの遅延なしに、解析と分類を実装するために必要な計算能力に直接影響する。Tは、特定の期間内に処理されるパケットの量を定義し、したがって、各パケットに割り当てられ得る処理リソースの量を定義する。

【0010】

公知のシステムでは、処理リソースの量はストリームNの増加に比例して増加する。固定リソースの場合、データインフラストラクチャはTを減らすことによってNを増やすか、Nを減らすことによってTを増やすことができる。つまり、N＊Tの積は実質的に一定のままである。

【0011】

しかし、実際には、既存のコンピュータネットワークではNとTの両方が比例して増加する。

【0012】

このような欠点を克服するために、同じ出願人による特許、欧州特許出願公開第1722509号明細書は、明示的な認識が不可能な場合には、最初は明示的で、後で暗黙的なプロトコル認識に基づく階層解析を提案している。

【0013】

明示的な認識は、所与のレベルの層が、カプセル化する上位レベルの層に使用されるプロトコルを明示的に示している場合に特に実装される。例えば、イーサネット層は上位層がIPv4かIPv6かを明示的に示し、IPは上位層がTCPかUDPかを示す。このような認識は簡単で、計算能力はほとんど必要ない。

【0014】

アプリケーションレベルの層に関しては、通常、暗黙の認識方法によって識別され、これは、下位レベルのトランスポート層によって明示的に示されないため、リソースの点でコストがかかる。

【0015】

さらに、このレベルでのプロトコルの様々なエンコーディングと通信暗号化の出現は、新しいプロトコル認識方法を必要としている。

【0016】

例えば、SMTPやHTTPなどのプロトコルの識別は、データが暗号化されているBitTorrentなどのプロトコルの識別よりも簡単でリソースを消費しない。したがって、信頼性を低下させることなく複雑さを軽減することにより、データストリームの分類を最適化する必要がある。

【先行技術文献】

【特許文献】

【0017】

【文献】欧州特許出願公開第1722509号明細書

【発明の概要】

【0018】

本発明は状況を改善する。

【課題を解決するための手段】

【0019】

この目的のために、本発明は、電気通信ネットワークの2つのエンティティ間で交換されるデータストリームのプロトコルを識別するための方法を提案し、本処理方法は、
データストリームのデータを受信するステップと、データストリームのプロトコルを識別するためにデータストリームを構文解析するステップと、
構文解析によってデータストリームのプロトコルを識別することに失敗した場合、プロトコルを対応するシグネチャと照合するシグネチャエンジンを参照するステップと、データストリームのプロトコルを識別するためにデータストリームにシグネチャを順次適用するステップと、を含む。

【0020】

構文解析は、計算リソースの観点からはそれほどリソースを消費せず、明示的に識別できないほとんどのプロトコルを識別することができる。計算リソースの点でより多くのリソースを消費するシグネチャに基づく解析方法は、構文解析が失敗した場合にのみ実施され、これにより、プロトコルの暗黙的な識別中にリソースの使用を最適化することができる。

【0021】

一実施形態によれば、本発明は、シグネチャエンジンを参照することによってデータストリームのプロトコルを識別することに失敗した場合、データストリームのプロトコルを識別するために統計的プロトコル認識方法を適用するステップをさらに含んでもよい。

【0022】

このような方法は、計算リソースの点でもリソースを大量に消費し、完全に信頼できるわけではない。したがって、それは最初の2つの方法が失敗した場合に有利に実施される。さらに、前の2つの方法では認識できないBitTorrentなどの暗号化されたプロトコルを認識することを可能にする。

【0023】

一実施形態によれば、識別されたプロトコルは、アプリケーションレベルのプロトコルであってもよい。

【0024】

アプリケーションレベルのプロトコル、より一般的にはOSIモデルの層5から7のプロトコルは、下位レベルの層によって明示的に示されていないので、この実施形態によれば、この方法は有利に適用される。

【0025】

一実施形態によれば、構文解析によるデータストリームのプロトコルの識別に成功した場合、本方法は、識別されたプロトコルに応じてデータストリームのコンテキスト要素にワンパスアルゴリズムを適用することによってプロトコルデータを識別するステップをさらに含んでもよい。

【0026】

このようなアルゴリズムは、リソースをあまり消費しないので、所与の識別されたプロトコルについて、それによって異なるタイプのプロトコルデータ間で転送されるデータを区別することを可能にする。

【0027】

さらに、ワンパスアルゴリズムを適用することによってプロトコルデータを識別することに失敗した場合、本方法は、プロトコルデータを対応するシグネチャと照合するシグネチャエンジンを参照するステップと、データストリームのプロトコルデータを識別するためにデータストリームにシグネチャを順次適用するステップと、をさらに含んでもよい。

【0028】

このように、計算リソースの点でより多くのリソースを消費するシグネチャに基づく解析方法は、構文解析が失敗した場合にのみ実施され、これにより、プロトコルデータの暗黙的な識別中にリソースの使用を最適化することができる。

【0029】

一実施形態によれば、本方法は、データストリームの識別されたプロトコルに基づいてデータストリームを処理するステップをさらに含んでもよい。

【0030】

したがって、プロトコルで区別された処理が適用されてもよい。

【0031】

さらに、データストリームの処理は、
識別されたプロトコルに応じてサービス品質ポリシーを適用するステップ、または
識別されたプロトコルに基づいてデータストリームを許可もしくは禁止するステップ、のうちの少なくとも一方を含んでもよい。

【0032】

本発明の第2の態様は、本プログラムがプロセッサによって実行されるときに本発明の第1の態様による方法を実施するための命令を含むコンピュータプログラム製品に関する。

【0033】

本発明の第3の態様は、電気通信ネットワークの2つのエンティティ間で交換されるデータストリームのプロトコルを識別するためのデバイスに関し、デバイスは、
データストリームのデータを受信するように構成されたインターフェースと、
プロセッサであって、
データストリームのプロトコルを識別するためにデータストリームを構文解析し、
構文解析によってデータストリームのプロトコルを識別することに失敗した場合、プロトコルを対応するシグネチャと照合するシグネチャエンジンを参照し、データストリームのプロトコルを識別するためにデータストリームにシグネチャを順次適用する、ように構成されたプロセッサと、を含む。

【0034】

本発明の他の特徴および利点は、以下の詳細な説明および以下の添付の図面を検討することで明らかになるであろう。

【図面の簡単な説明】

【0035】

【図1】本発明の一実施形態によるシステムの一般的なアーキテクチャを示す図である。

【図2】本発明の一実施形態による処理方法のステップを提示する図である。

【図3】本発明の一実施形態によるデータ処理デバイスの構造を示す図である。

【発明を実施するための形態】

【0036】

本発明は、図1に示すアナライザ300などのプロトコル識別デバイスに実装され得る。識別デバイスは、図3を参照してより詳細に提示される。

【0037】

図2は、本発明の一実施形態によるプロトコル識別方法のステップを提示する。

【0038】

ステップ200では、ストリームの1つまたは複数のパケットは、例えば、通信リンク200上のアナライザ300によるパケットの傍受後に、識別デバイスによって受信される。

【0039】

ステップ201では、受信されたデータパケットは、既存のストリームに関連付けられるために、または現在のデータストリームをリストするテーブルに新しいエントリを作成するために識別され得る。例えば、送信元エンティティのIPアドレス（および任意選択でポート番号）と受信元エンティティのIPアドレス（および任意選択でポート番号）を考慮して、パケットに対応するストリームを識別することができる。このような手法はよく知られており、詳細には説明しない。

【0040】

送信元エンティティまたは受信元エンティティは、クライアントまたはサーバーのいずれかを参照してもよい。クライアントは、ラップトップまたはデスクトップコンピュータ、タッチスクリーンタブレット、スマートフォン、またはネットワーク100または110、例えばインターネットで通信することを可能にするインターフェースを含む任意の電子デバイスであってもよい。本発明によれば、2つの通信エンティティは、図1に示すように、2つの別個のネットワーク内にあってもよいし、または同じネットワークに属してもよい。

【0041】

データストリームの低層プロトコルは、ステップ201で明示的な認識によって決定され得る。上記のように、明示的な認識は、所与のレベルの層のプロトコルがそのすぐ下のレベルの層によって明示的に示す可能性があるという点で、ほとんど計算能力を必要としない。

【0042】

したがって、例えば、イーサネット層データに基づいて、IPv4またはIPv6プロトコルが使用されていると判断され得る。同様に、IP層は、UDPプロトコルとTCPプロトコルのどちらが使用されているかを示す。

【0043】

ステップ202以降、本発明による方法の目的は、下位レベルの層によって明示的に示されていないプロトコルを識別することである。したがって、そのような識別は暗黙的である。例えば、OSIレベルのレベル5から7の層、特にレベル7（アプリケーション）のプロトコルの認識が考慮される。

【0044】

ステップ203では、識別デバイスは、データストリームのプロトコルを識別するために、データストリームの1つまたは複数のパケットに含まれるデータストリームのデータの構文解析を実施する。実際、アプリケーションレベルの特定のプロトコルは、低い計算能力を使用することで簡単に識別できる文法を有する。これは、例えば、SMTPおよびHTTPプロトコルの場合である。そのようなプロトコルは、その認識に役立つコンテキスト要素を有する。例えば、どちらも「ハンドシェイク」プロセスを使用してストリームを設定する。SSLやSIPなどの他のプロトコルも、文法を認識することで識別され得る。統計的に、分類されるストリームのアプリケーションプロトコルの90％は、ステップ203を使用することによって認識され得ることに留意されたい。したがって、そのような認識方法の優先された最初の使用は、低い計算能力で多数のプロトコルを認識することを可能にする。

【0045】

ステップ203では、データストリームのプロトコルが構文解析によって首尾よく識別されたかどうかがチェックされる。

【0046】

構文解析によってデータストリームのプロトコルを識別することに成功した場合、本方法は、識別されたプロトコルに応じてデータストリームのコンテキスト要素にワンパス（または「シングルパス」）アルゴリズムを適用することによって、プロトコルデータを識別するステップ204をさらに含んでもよい。ワンパスアルゴリズムは、識別されたプロトコルに依存してもよい。

【0047】

プロトコルデータの識別は、ステップ203で識別されたプロトコルの層よりも上位の層のアプリケーションまたはサブアプリケーションの識別であると見なされ得る。例えば、プロトコルがHTTPであると識別された場合には、上位層のサブアプリケーションまたはプロトコルデータは、例えばFacebook（商標）データであってもよい。

【0048】

ワンパスアルゴリズムの適用は、ストリームのコンテキスト要素（例えば、HTTPの場合、コンテキスト要素はURL、User Agentなどの要素であってもよい）をルールエンジンに入力することで構成されてもよい。「ストリームのコンテキスト要素」とは、データストリームのヘッダーまたはペイロード要素を指す。ワンパスアルゴリズムの使用は、計算リソースの点でそれほどコストがかからず、処理時間は固定されており、入力の数に依存しない。

【0049】

コンテキスト要素の入力に応答して、ルールエンジンは、プロトコルデータを識別するために、ステップ102で識別されたプロトコルのデータでテストされ得るルールのセットを返すことができる。例えば、ステップ202でHTTPプロトコルを識別した後に、プロトコルデータは、Facebook（商標）データであると識別され得る。

【0050】

ステップ212では、プロトコルデータがワンパスアルゴリズムによってステップ204で識別されたかどうかがチェックされる。成功した場合、本方法はステップ205に続く。失敗した場合、本方法は以下に説明するステップ206に進む。

【0051】

ステップ204およびステップ205は任意であり、本方法は、ステップ203での確実な識別の場合に、ステップ203からステップ205に直接移動することができる。

【0052】

プロトコルおよび、任意選択でプロトコルデータが識別されると、この方法は、識別されたプロトコルに基づいて、および任意選択で、アプリケーションデータに基づいてデータストリームを処理するステップ205を適用することを含んでもよい。ストリームの処理は、例えば、識別されたプロトコルに応じてサービス品質ポリシーを適用すること、または識別されたプロトコルに基づいてデータストリームを許可または禁止することで構成されてもよいし、またはより一般的には、識別されたプロトコルに基づいてストリームを分類することで構成されていてもよい。分類は、プロトコル識別デバイスの外部の処理デバイスに送信されてもよい。

【0053】

ステップ202の構文解析によってデータストリームのプロトコルを識別できない場合、本発明による方法は、プロトコルを対応するシグネチャと照合するシグネチャエンジンを参照するステップ206を含む。ステップ207では、データストリームのアプリケーションレベルのプロトコルを識別するために、シグネチャがデータストリームに順次適用される。そのような順次適用は、リソースの点でコストがかかるため、ステップ202の構文解析が失敗した場合にのみ有利に適用される。

【0054】

統計的には、このようなシグネチャ検索方法は、構文解析方法では識別できなかったアプリケーションプロトコルの10％の半分（つまり、プロトコルの5％）にアクセスすることを可能にする。計算リソースの点ではコストがかかるが、それでもシグネチャ検索方法は信頼性がある。

【0055】

ステップ204で識別が失敗した場合には、ステップ206およびステップ207がまたプロトコルデータに適用され得る。この場合、プロトコルデータは、それらを識別するためにシグネチャと比較される。

【0056】

ステップ208では、データストリームのプロトコルがシグネチャ検索方法によって首尾よく識別されたかどうかがチェックされる。

【0057】

成功した場合、本方法は上述したステップ205に戻る。

【0058】

失敗した場合、本発明の一実施形態は、データストリーム（またはプロトコルデータ）のアプリケーションプロトコルを識別するために、統計的プロトコル認識方法を適用する追加のステップ209を提供してもよい。特にそのような方法は、BitTorrentなどの暗号化されたプロトコルを識別することを可能にする。そのような方法は、計算能力（順次検索）の点でコストがかかり、完全に信頼できるわけではない。しかし、それは、以前に実施された方法では識別されなかったプロトコルまたはプロトコルデータの1～2％を識別することを可能にする。

【0059】

ステップ210では、データストリームのプロトコルが統計的方法によって首尾よく識別されたかどうかがチェックされる。

【0060】

成功した場合、本方法は上述したステップ205に戻る。

【0061】

失敗した場合（統計的には約3％の場合）、本方法はデータストリームのアプリケーションプロトコルを識別することができずに終了する。障害が発生した場合、ステップ211で、予め定義された処理操作が適用され得る。例えば、予防措置として、データストリームがブロックされ得る。

【0062】

本発明はまた、計算能力に関して最も信頼性が高く最も費用がかからない方法から、最も信頼性が低く最も資源集約的である方法まで、プロトコル認識方法の漸進的な適用を提供する。したがって、アプリケーションレベルのプロトコルの検索を最適化する。

【0063】

図3は、本発明の一実施形態によるプロトコル識別デバイス301を示している。

【0064】

識別デバイス301は、図1のネットワーク100と110との間の傍受のために配置されたアナライザ300に実装され得る。より一般的には、2つのネットワークエンティティ間で伝達されるデータストリームのデータを受信することができる。

【0065】

識別デバイスは、ランダムアクセスメモリ305およびプロセッサ304、ならびに図2を参照して上述した方法のステップを実施することを可能にする命令を格納するためのメモリ301も含む。プロセッサは、サブエンティティ304．1～304．3を含んでもよく、これらはそれぞれ上記の3つの認識方法に特化している。

【0066】

メモリ301は、本方法、特に、
シグネチャを対応するプロトコルと照合するシグネチャエンジン、
プロトコルデータを認識するための、所与のプロトコルに関連するルールのセット、
統計的プロトコル認識方法のルールを実装するためにプロセッサによって使用されるデータをさらに格納することができる。

【0067】

識別デバイス301は、通信リンク200を介して、または所与のネットワーク内で伝達されるデータストリームのデータを受信することを目的とした入力インターフェース302をさらに含む。

【0068】

識別デバイス301は、プロトコル識別結果、または識別されたプロトコルに基づいて決定されたコマンドを提供することができる出力インターフェース303をさらに含む。

【0069】

もちろん、本発明は、例として上述した実施形態に限定されず、それは他の変形例にも拡張される。

【符号の説明】

【0070】

100 第1のネットワーク
110 第2のネットワーク
111 第2のエンティティ
112 第1のエンティティ
120 通信リンク
300 アナライザ
301 プロトコル識別デバイス／メモリ
302 入力インターフェース
303 出力インターフェース
304 プロセッサ
304．1～304．3 サブエンティティ
305 ランダムアクセスメモリ

【図1】

【図2】

【図3】