JP2005064583A

JP2005064583A - Data relaying apparatus and data relaying method

Info

Publication number: JP2005064583A
Application number: JP2003207396A
Authority: JP
Inventors: Hidetoshi Ueno; 英俊上野; Hidemoto Suzuki; 偉元鈴木; Kiyoko Tanaka; 希世子田中; Akira Kitahara; 亮北原; Norihiro Ishikawa; 憲洋石川
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2003-08-12
Filing date: 2003-08-12
Publication date: 2005-03-10

Abstract

<P>PROBLEM TO BE SOLVED: To provide a data relaying apparatus and a data relaying method which can detect a participation request to a multicast group and a retire request from the multicast group strong in possibility to be ineffective (illegitimate). <P>SOLUTION: The data relaying apparatus for relaying prescribed multicast data distributed to a prescribed terminal is provided with: a reception means for receiving distribution period information including a distribution start time when the distribution of the prescribed multicast data is started and a distribution end time when the distribution of the prescribed multicast data is finished; and a discrimination means for discriminating whether or not the participation request to the multicast group or the retire request from the multicast group is accepted on the basis of the distribution period information. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、所定の端末に対して配信される所定のマルチキャストデータを中継するデータ中継装置、及び、データ中継方法に関する。
【０００２】
【従来の技術】
インターネット等を利用した所定のデータの配信方法として、データ配信装置（送信者）とデータ受信装置（受信者）との関係に従って分類されるユニキャスト配信・ブロードキャスト配信・マルチキャスト配信が広く知られている。
【０００３】
ユニキャスト配信とは、１つのデータ配信装置（送信者）が１つのデータ受信装置（受信者）に所定のデータを配信する１対１の通信である。このとき、データ配信装置（送信者）によって配信されるデータ量は、データ受信装置（受信者）の数に比例して大きくなるため、データ受信装置（受信者）の数が増加すると、データ配信装置や通信回線網において所定のデータを配信する負荷が大きくなるという問題がある。
【０００４】
これに対し、ブロードキャスト配信及びマルチキャスト配信は、１つのデータ配信装置（送信者）が多数のデータ受信装置（受信者）に所定のデータを配信する１対多の通信であるため、上述の問題は生じない。また、マルチキャスト配信は、ブロードキャスト配信と異なり、特定のグループ（マルチキャストグループ）に属するデータ受信装置（受信者）に対して所定のデータを一回の操作で配信する配信方法である。
【０００５】
マルチキャスト配信の一例としては、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）を用いてマルチキャスト配信を実現するＩＰマルチキャストが広く知られている。ＩＰマルチキャストでは、同一のデータを受信するデータ受信装置（受信者）に対してマルチキャスト用のＩＰアドレスが割り当てられることによって、マルチキャストグループが構成される。このマルチキャストグループに割り当てられるＩＰアドレス（以下、マルチキャストアドレス）は、マルチキャストグループに固有のアドレスである。所定のマルチキャストグループに属するデータ受信装置（受信者）は、当該データ受信装置に隣接しているデータ中継装置（例えば、ルータ）に、当該所定のマルチキャストグループに属するデータ受信装置（受信者）があることを示す情報を送信する（記憶させる）。これにより、所定のマルチキャストグループに属するデータ受信装置（受信者）は、データ配信装置（送信者）から当該所定のマルチキャストグループ宛に配信される所定のマルチキャストデータを、データ中継装置等を介して受信することができる。
【０００６】
ここで、所定のマルチキャストデータを受信するデータ受信装置（受信者）とデータ中継装置との間において、マルチキャストグループを管理するためのプロトコルとしては、ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）が用いられている。このＩＧＭＰに対応したデータ中継装置には、所定のマルチキャストグループに属するデータ受信装置（受信者）が当該データ中継装置の配下に存在するか否かを判別する機能が実装されている。なお、各データ中継装置間のマルチキャスト経路制御プロトコルとしては、ＤＶＭＲＰ（ＤｉｓｔａｎｃｅＶｅｃｔｏｒＭｕｌｔｉｃａｓｔＲｏｕｔｉｎｇＰｒｏｔｏｃｏｌ）・ＭＯＳＰＦ（ＭｕｌｔｉｃａｓｔＯｐｅｎＳｈｏｒｔｅｓｔＰａｔｈＦｉｒｓｔ）・ＰＩＭ−ＤＭ（ＰｒｏｔｏｃｏｌＩｎｄｅｐｅｎｄｅｎｔＭｕｌｔｉｃａｓｔＤｅｎｓｅＭｏｄｅ）・ＰＩＭ−ＳＭ（ＰｒｏｔｏｃｏｌＩｎｄｅｐｅｎｄｅｎｔＭｕｌｔｉｃａｓｔＳｐａｒｓｅＭｏｄｅ）、ＢＧＭＰ（ＢｏｒｄｅｒＧａｔｅｗａｙ
ＭｕｌｔｉｃａｓｔＰｒｏｔｏｃｏｌ）等が知られている。
【０００７】
ＩＧＭＰを用いてマルチキャストグループを管理する方法において、データ受信装置（受信者）は、所定のマルチキャストアドレス宛に配信されるマルチキャストデータを受信しようとする場合には、マルチキャストグループへの加入要求である「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ」をデータ中継装置に送信する。「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ」を受信したデータ中継装置は、上述のマルチキャスト経路制御プロトコルを用いてマルチキャストデータの配信経路（マルチキャストツリー）を構築する。これにより、データ中継装置は、マルチキャストデータを受信するとともに、データ受信装置（受信者）が存在するネットワーク上に当該マルチキャストデータを送出する。以上の動作により、データ受信装置（受信者）は、マルチキャストデータを受信することができる。
【０００８】
なお、データ中継装置が、所定のデータ受信装置（受信者）から「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ」を受信した際に、当該データ中継装置の配下に存在する他のデータ受信装置（受信者）から「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ」を受信することによって、マルチキャストデータを既に受信している場合には、所定のデータ受信装置（受信者）は、「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ」をデータ中継装置に送信した直後からマルチキャストデータを受信することができる。
【０００９】
また、データ受信装置（受信者）は、所定のマルチキャストアドレス宛に配信されるマルチキャストデータの受信を終了しようとする場合には、マルチキャストグループからの離脱要求である「ＩＧＭＰＬｅａｖｅＧｒｏｕｐメッセージ」をデータ中継装置に送信する。「ＩＧＭＰＬｅａｖｅＧｒｏｕｐメッセージ」を受信したデータ中継装置は、マルチキャストデータを受信する他のデータ受信装置（受信者）が存在するか否かを確認するための「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＱｕｅｒｙ」を、マルチキャストグループに属するデータ受信装置（受信者）に送信する。なお、この「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＱｕｅｒｙ」は、特に「ＩＧＭＰＧｒｏｕｐＳｐｅｃｉｆｉｃＭｅｍｂｅｒｓｈｉｐＱｕｅｒｙ」と呼ばれる。
【００１０】
ここで、データ中継装置は、「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＱｕｅｒｙ」を受信したデータ受信装置（受信者）から「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ」を受信すると、マルチキャストデータを受信しているデータ受信装置（受信者）が当該データ中継装置の配下に存在するものと判断するためマルチキャスト配信経路（マルチキャストツリー）を削除しない。また、データ中継装置は、「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＱｕｅｒｙ」をマルチキャストグループに属するデータ受信装置（受信者）に送信してから予め決められた時間（タイマにセットされた時間）が経過しても、「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ」を受信しないと、マルチキャストデータを受信しているデータ受信装置（受信者）が当該データ中継装置の配下に存在しないものと判断するためマルチキャスト配信経路（マルチキャストツリー）を削除する。以上の動作により、データ受信装置（受信者）は、マルチキャストデータの受信を終了することができる。
【００１１】
上述のように、ＩＧＭＰを用いてマルチキャストグループを管理する方法（プロトコル）においては、データ中継装置は、マルチキャストグループへの加入要求（「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ」）、又は、マルチキャストグループからの離脱要求（「ＩＧＭＰＬｅａｖｅＧｒｏｕｐメッセージ」）をデータ受信装置（受信者）から受信することによって、マルチキャスト配信経路（マルチキャストツリー）の構築又は削除に関する所定の処理を行う（例えば、非特許文献１〜３）。
【００１２】
なお、上述のＩＧＭＰに関する説明は、「ＩＧＭＰＶｅｒｓｉｏｎ２」に関する説明であり、これ以外に「ＩＧＭＰＶｅｒｓｉｏｎ３」が存在する。「ＩＧＭＰＶｅｒｓｉｏｎ３」によれば、データ中継装置は、マルチキャストデータの配信元（データ配信装置）を特定する機能を備えている。なお、「ＩＧＭＰＶｅｒｓｉｏｎ３」は、「ＩＧＭＰＶｅｒｓｉｏｎ２」を拡張したものであり、その基本的な動作は、「ＩＧＭＰＶｅｒｓｉｏｎ２」と同じであるため、「ＩＧＭＰＶｅｒｓｉｏｎ３」に関する詳細な説明は省略する。
【００１３】
以下において、データ配信装置からデータ受信装置にＩＰマルチキャストを用いてマルチキャストデータが配信される場合におけるＤｏＳアタック（ＤｅｎｉａｌｏｆＳｅｒｖｉｃｅＡｔｔａｃｋ）の方法及びその対処方法に関する既存技術について、図面を参照しながら説明する。図５は、ＤｏＳアタック（ＤｅｎｉａｌｏｆＳｅｒｖｉｃｅＡｔｔａｃｋ）の方法及びその対処方法に関する既存技術について説明するための図である。
【００１４】
同図に示すように、正当なデータ配信装置２０１（正当送信者）、及び、不正なデータ配信装置２１０（不正送信者）は、正当なデータ受信装置４０１・４０２（正当受信者）、及び、不正なデータ受信装置４１０（不正受信者）と通信回線網５００を介して接続されている。また、通信回線網５００は、複数のデータ中継装置（ルータ３０１〜３０４）によって構成されている。
【００１５】
まず、不正送信者（データ配信装置２１０）によるＤｏＳアタックの方法について説明する。ＩＰマルチキャストにおいては、データ配信装置（送信者）は、必ずしもマルチキャストグループに属する必要がないため、データ配信装置２１０（不正送信者）は、任意のマルチキャストグループ宛に不正なデータを配信することができてしまう。
【００１６】
この対処方法としては、送信者アクセス制御方法とメッセージ認証方法とが知られている。
【００１７】
送信者アクセス制御方法とは、データ中継装置（例えば、ルータ３０２・３０４）が、ＳＳＭ（ＳｏｕｒｃｅＳｐｅｃｉｆｉｃＭｕｌｔｉｃａｓｔ）の利用を前提として、データ送信端末（送信者）のアドレスをフィルタリングすることによって、データ配信装置２１０（不正送信者）による不正データの配信を防止する方法、データ配信装置２１０（不正送信者）に隣接するデータ中継装置（ルータ３０３（入り口ルータ））が、データ制御装置（送信者）を認証することによって、データ配信装置２１０（不正送信者）による不正データの配信を防止する方法などである（例えば、非特許文献４〜５）。また、双方向マルチキャストツリーの利用を前提とする送信者アクセス制御方法も知られている（例えば、非特許文献６）。
【００１８】
これらの送信者アクセス制御方法によれば、データ配信装置（送信者）とデータ受信装置（受信者）とがルータを介して接続されているマルチキャスト配信においては、不正送信者（不正なデータ配信装置）によるＤｏＳアタックを防止することができるが、データ配信装置（送信者）とデータ受信装置（受信者）とが同一のサブネットワーク上に存在するマルチキャスト配信においては、不正送信者（不正なデータ配信装置）によるＤｏＳアタックを防止することができない。
【００１９】
一方、メッセージ認証方法とは、データ受信装置（受信者）は、ＨＭＡＣ−ＳＨＡ１やＴＥＳＬＡなどを用いてメッセージ認証を行うことにより、不正なメッセージ（データ）を検出する方法である（非特許文献７）。
【００２０】
このメッセージ認証方法によれば、データ受信装置（受信者）は、データ配信装置（送信者）によって送信された不正なマルチキャストデータを検出することができるが、不正なマルチキャストデータがデータ受信装置（受信者）に到達するため、通信回線などの通信リソースが有効に利用されない。
【００２１】
次に、不正受信者（データ受信装置４１０）によるＤｏＳアタックの方法について説明する。
【００２２】
ＩＰマルチキャストにおいては、ＩＧＭＰプロトコルを処理するデータ中継装置（例えば、ルータ３０４）は、マルチキャストグループへの加入要求である「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ（以下、「Ｊｏｉｎ」）」を無条件に受け入れるため、不正受信者（データ受信装置４１０）からの「Ｊｏｉｎ」によってマルチキャストツリーが構築されてしまう。
【００２３】
この対処方法としては、データ受信装置（受信者）の認証に基づくアクセス制御方法（例えば、非特許文献８・９）や一定の期間に急増した「Ｊｏｉｎ」をデータ中継装置（ルータ３０４）が無視する手法などが知られている。
【００２４】
また、ＩＧＭＰプロトコルを処理するデータ中継装置（例えば、ルータ３０４）は、マルチキャストからの離脱要求である「ＩＧＭＰＬｅａｖｅＧｒｏｕｐメッセージ（以下、「Ｌｅａｖｅ」）」を無条件に受け入れるため、不正受信者（データ受信装置４１０）からの「Ｌｅａｖｅ」に応じた「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＱｕｅｒｙ（以下、「Ｑｕｅｒｙ」）」が正当受信者（データ受信装置４０１・４０２）に送信されるとともに、当該「Ｑｕｅｒｙ」に応じた「Ｊｏｉｎ」がデータ中継装置（ルータ３０４）に送信されてしまう。すなわち、マルチキャストグループに属するデータ受信装置（メンバー）が存在するか否かを確認するための通信が発生するため、通信リソースが無駄に使用されてしまう。また、この影響は、データ中継装置（ルータ３０４）によって区切られるサブネットワーク上の全てのデータ受信端末に及んでしまう。
【００２５】
なお、不正受信者（データ受信装置４１０）が「Ｌｅａｖｅ」をデータ中継装置（ルータ３０４）に送信したとしても、正当受信者（データ受信装置４０１・４０２）が「Ｑｕｅｒｙ」に応じた「Ｊｏｉｎ」をデータ中継装置（ルータ３０４）に送信するため、マルチキャストツリーが削除されることはない。
【００２６】
この対処方法としては、不正受信者（データ受信装置４１０）からの「Ｊｏｉｎ」によってマルチキャストツリーが構築されてしまう場合と同様に、データ受信装置（受信者）の認証に基づくアクセス制御方法（例えば、非特許文献８・９）や一定の期間に急増した「Ｌｅａｖｅ」をデータ中継装置（ルータ３０４）が無視する手法などが知られている。
【００２７】
さらに、ＩＰマルチキャストにおいては、不正受信者（データ受信装置４１０）は、正当受信者（データ受信装置４０１・４０２）によって「Ｑｕｅｒｙ」に応じて送信される「Ｊｏｉｎ」が送信されないようにすることができてしまう。
【００２８】
具体的には、不正受信者（データ受信装置４１０）は、データ中継装置（ルータ３０４）からの「Ｑｕｅｒｙ」に応じて、マルチキャストグループに属する正当受信者（データ受信装置４０１・４０２）に「Ｊｏｉｎ」をそれぞれ送信する。このとき、不正受信者（データ受信装置４１０）は、正当受信者（データ受信装置４０１・４０２）に固有のＭＡＣアドレスを用いて「Ｊｏｉｎ」を送信する。なお、ＩＰヘッダ及びＩＧＭＰヘッダは、通常の「Ｊｏｉｎ」と同じものである。不正受信者（データ受信装置４１０）から「Ｊｏｉｎ」を受信した正当受信者（データ受信装置４０１・４０２）は、マルチキャストグループに属する他の受信者（データ受信装置）が存在するものと判断（誤解）するため、「Ｊｏｉｎ」の送信を抑制してしまう。これにより、データ中継装置（ルータ３０４）は、「Ｑｕｅｒｙ」に応じた「Ｊｏｉｎ」を１つも受信しないため、マルチキャストツリーを削除する。
【００２９】
すなわち、不正受信者（データ受信装置４１０）は、マルチキャストデータがデータ中継装置（ルータ３０４）によって中継されないようにすることができる。
【００３０】
この対処方法としては、「Ｊｏｉｎ」の宛先アドレスがマルチキャストアドレスとなっているか否かを受信者（データ受信装置）が確認する方法が知られている。なお、この対処方法を実現するために、ＬｉｎｕｘＯＳ用のパッチも作成されている（非特許文献１０）。
【００３１】
上述の記載において説明したＤｏＳアタックの対処方法は、ＤｏＳアタックを防止する対処方法として一定の効果を奏するが、根本的な対処方法とはならない。また、複数の対処方法を組み合わせればＤｏＳアタックを防止することができるが、複数の対処方法を組み合わせるためには、多くのコストが必要となる。
【００３２】
また、不正受信者によるＤｏＳアタックの対処方法として最も効果的な受信者認証による対処方法については、受信者の認証手順を手当たり次第に発生させるＤｏＳアタックが考えられる。なお、このＤｏＳアタックを効果的に防止する対処方法は存在しない。また、受信者認証による対処方法は、受信者の認証が本来必要ではない場合には、通信コストが増加してしまう。
【００３３】
従って、ＤｏＳアタックそのものを防止するよりも、ＤｏＳアタックを検出するとともに、法的手段等の運用上の対策を講じることによって、ＤｏＳアタックを間接的に防止することが効果的である。
【００３４】
以下において、ＩＧＭＰルータにおける認証モードを切り替えることによって、不正受信者からの「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）によるＤｏＳアタックを検出する既存技術について説明する。
【００３５】
ＩＧＭＰルータにおける認証モードには、「Ｎｏｒｍａｌモード」と「Ａｌｅｒｔモード」という二つの認証モードが含まれている。
【００３６】
「Ｎｏｒｍａｌモード」とは、ＩＧＭＰルータが、データ受信装置（受信者）からの「Ｊｏｉｎ」や「Ｌｅａｖｅ」を受信した際に、通常の処理を行う認証モードである。一方、「Ａｌｅｒｔモード」とは、ＩＧＭＰルータが、データ受信装置（受信者）からの「Ｊｏｉｎ」や「Ｌｅａｖｅ」を受信した際に、非特許文献８・９において提案されている受信者認証を行う認証モードである。
【００３７】
ＩＧＭＰルータは、「Ａｌｅｒｔモード」において受信者認証に失敗した場合に、ＤｏＳアタックを受けた可能性があると判断する（ＤｏＳアタックである可能性がある「Ｊｏｉｎ」又は「Ｌｅａｖｅ」を検出する）。なお、ＩＧＭＰルータが「Ｎｏｒｍａｌモード」から「Ａｌｅｒｔモード」に認証モードを切り替える方法については、以下に示すように複数の方法がある。
【００３８】
まず、ＩＧＭＰルータが、データ受信装置（受信者）からの「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）の受信間隔をモニタリングすることによって、認証モードを切り替える方法について説明する。具体的には、ＩＧＭＰルータは、データ受信装置（受信者）からの「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）の単位時間における受信回数（以下、受信率）が閾値を超えた際に、「Ｎｏｒｍａｌモード」から「Ａｌｅｒｔモード」に認証モードを切り替える。なお、ＩＧＭＰルータは、ＩＧＭＰヘッダを調査することによって、データ受信装置のアドレス（「Ｊｏｉｎ」の送信元アドレス）やマルチキャストアドレス毎の受信率を利用してもよい。
【００３９】
次に、ＩＧＭＰルータが、マルチキャストデータを中継していない（マルチキャストツリーを構築していない）マルチキャストグループ宛の「Ｌｅａｖｅ」に基づいて、認証モードを切り替える方法について説明する。具体的には、ＩＧＭＰルータは、「非特許文献８・９において提案されている方法」や「ＩＧＭＰｖｅｒｓｉｏｎ３」の利用して、マルチキャストグループへの受信者の加入状況をマルチキャストグループ毎に管理することを前提として、マルチキャストデータを中継していないマルチキャストグループ宛の「Ｌｅａｖｅ」を受信した際に、「Ｎｏｒｍａｌモード」から「Ａｌｅｒｔモード」に認証モードを切り替える。
【００４０】
最後に、ＩＧＭＰルータが、「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）を受信した際に、ランダムに受信者の認証を行うことによって、認証モードを切り替える方法について説明する。具体的には、ＩＧＭＰルータが、受信者認証方法（非特許文献８・９）の利用を前提として、「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）を受信した際にランダムに行われる受信者の認証に失敗した場合に、「Ｎｏｒｍａｌモード」から「Ａｌｅｒｔモード」に認証モードを切り替える。
【００４１】
【非特許文献１】
ＴｈｏｍａｓＭａｕｆｅｒ著，楠本博之訳，「ＩＰマルチキャスト入門」，初版，共立出版株式会社，２００１年１１月
【００４２】
【非特許文献２】
ＤａｖｅＫｏｓｉｕｒ著，苅田幸雄監訳，「マスタリングＴＣＰ／ＩＰマルチキャスト編」，第１版，第２刷，平成１２年１１月
【００４３】
【非特許文献３】
ＢｅａｕＷｉｌｌｉａｍｓｏｎ著，コムサス訳，シスコシステムズ監訳，「ＩＰマルチキャストネットワーク開発ガイドＶｏｌ．１」，初版，２００１年７月
【００４４】
【非特許文献４】
Ａ．Ｂａｌｌａｒｄｉｅ他著，「Ｍｕｌｔｉｃａｓｔ−ｓｐｅｃｉｆｉｃｓｅｃｕｒｉｔｙｔｈｒｅａｔｓａｎｄｃｏｕｎｔｅｒ−ｍｅａｓｕｒｅｓ」ＩＳＯＣＮＤＳＳ，１９９５年
【００４５】
【非特許文献５】
Ｒ．Ｌｅｈｔｏｎｅｎ他著，「Ｃｏｎｔｒｏｌｌｅｄｍｕｌｔｉｃａｓｔｆｒａｍｅｗｏｒｋ」ＩＥＥＥＬｏｃａｌＣｏｍｐｕｔｅｒＮｅｔｗｏｒｋｓ（ＬＣＮ）０２，２００２年
【００４６】
【非特許文献６】
Ｎ．Ｗａｎｇ他著，「Ｔｏｗａｒｄｓｄｙｎａｍｉｃｓｅｎｄｅｒａｃｃｅｓｓｃｏｎｔｒｏｌｆｏｒｂｉ−ｄｉｒｅｃｔｉｏｎａｌｍｕｌｔｉｃａｓｔｔｒｅｅｓ」ＩＥＥＥＧＬＯＢＥＣＯＭ，Ｖｏｌ．３，２００１年
【００４７】
【非特許文献７】
Ａ．Ｐｅｒｒｉｇ他著，「ＥｆｆｉｃｉｅｎｔａｎｄＳｅｃｕｒｅＳｏｕｒｃｅＡｕｔｈｅｎｔｉｃａｔｉｏｎｆｏｒＭｕｌｔｉｃａｓｔ」ＩＳＯＣＮＤＳＳ，２００１年
【００４８】
【非特許文献８】
上野英俊他著，「マルチキャスト通信のためのアクセス制御＆グループ鍵配信プロトコル」ＦＩＴ２００３，２００３年
【００４９】
【非特許文献９】
林經正他著，「ユーザ認証を可能とするグループマネジメントプロトコルＩＧＡＰ」信学技報，ＮＳ２００２−２７８，２００３年
【００５０】
【非特許文献１０】
Ｋ．Ｒａｍａｃｈａｎｄｒａｎ，「ＳｐｏｏｆｅｄＩＧＭＰＲｅｐｏｒｔＤｅｎｉａｌｏｆＳｅｒｖｉｃｅＶｕｌｎｅｒａｂｉｌｉｔｙ」ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｕｃｓｂ．ｅｄｕ／￣ｋｒｉｓｈｎａ／ｉｇｍｐ＿ｄｏｓ／
【００５１】
【発明が解決しようとする課題】
ところで、放送型のデータ配信サービスにおいては、データの配信期間が予め決められていることが多い。例えば、ＩＰマルチキャストを用いて、データ配信装置によって所定の番組（マルチキャストデータ）が配信される配信期間は、所定の開始時刻（例えば、２００３年１月１日０：３０ＡＭ）から所定の終了時刻（例えば、２００３年１月１日０：４０ＡＭ）までといったように、予め決められているのが一般的である。
【００５２】
しかしながら、上述のＤｏＳアタックの対処方法や認証モード切り替えにおいて、マルチキャストデータの配信期間と受信者からの「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）を受信した時刻（「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）の発生時刻）とを比較することによって、当該「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）の有効性を判断するシステム（方法）は存在しない。
【００５３】
具体的には、予め決められた配信期間（２００３年１月１日０：３０ＡＭ〜０：４０ＡＭ）に配信される所定の番組（マルチキャストデータ）について、データ受信装置（受信者）から２００３年１月２日１２：３０ＰＭに「Ｊｏｉｎ」をデータ中継装置（例えば、ＩＧＭＰルータ）が受信した場合には、当該データ中継装置は、上述のＤｏＳアタックの対処方法や認証モード切り替えを行っていても、当該「Ｊｏｉｎ」を受け付けてしまうという問題があった。また、データ受信装置（受信者）から２００２年１２月３１日１２：３０ＰＭに「Ｌｅａｖｅ」をデータ中継装置が受信した場合にも、当該データ中継装置は、上述のＤｏＳアタックの対処方法や認証モード切り替えを行っていても、当該「Ｌｅａｖｅ」を受け付けてしまうという問題があった。
【００５４】
そこで本発明は、上述の問題を解決すべくなされたものであり、データの配信期間とデータ受信装置（受信者）からの「Ｊｏｉｎ」（又は、「Ｌｅａｖｅ」）の受信時刻とを比較することによって、無効（不正）なものである可能性が高い「Ｊｏｉｎ」（又は、「Ｌｅａｖｅ」）を検出することができるデータ中継装置、及び、データ中継方法を提供することを目的とする。
【００５５】
【課題を解決するための手段】
本発明の第１の特徴は、所定の端末に対して配信される所定のマルチキャストデータを中継するデータ中継装置が、所定のマルチキャストデータの配信を開始する配信開始時刻と所定のマルチキャストデータの配信を終了する配信終了時刻とを含む配信期間情報を受信する受信手段と、マルチキャストグループへの加入要求又はマルチキャストグループからの離脱要求を受け付けるか否かを、配信期間情報に基づいて判断する判断手段とを具備することを要旨とする。
【００５６】
かかる特徴によれば、データ中継装置が、所定のマルチキャストデータの配信期間情報に基づいて、データ受信装置から受信したマルチキャストグループへの参加要求又はマルチキャストグループからの離脱要求を受け付けるか否かを判断することにより、データ中継装置３０は、ＤｏＳアタックである可能性が高い「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）を検出することができる。
【００５７】
これにより、データ中継装置３０は、ＤｏＳアタックである可能性が高いマルチキャストグループへの参加要求又はマルチキャストグループからの離脱要求を無視することによって、不正なマルチキャストグループへの参加要求又はマルチキャストグループからの離脱要求によるＤｏＳアタックの弊害を軽減することができる。また、データ配信装置やデータ中継装置などを管理する管理者等は、データ中継装置に受信者を認証する機能が具備されていなくても、ＤｏＳアタックに対する対策を容易に講じることができる。なお、ＤｏＳアタックに対する対策とは、ログを記録することによって管理者が法的手段などに訴えることなどである。さらに、データ中継装置は、「Ｎｏｒｍａｌモード」から「Ａｌｅｒｔモード」に認証モードを切り替える契機として、マルチキャストデータの配信期間情報に基づく判断結果を利用することにより、効果的に認証モード切り替えることができる。
【００５８】
また、本発明の第１の特徴において、判断手段は、配信期間情報に含まれる配信開始時刻よりも所定時間前から配信終了時刻まで、マルチキャストグループへの加入要求を受け付けるものと判断することが好ましい。
【００５９】
さらに、本発明の第１の特徴又は第２の特徴において、判断手段は、配信期間情報に含まれる配信開始時刻から配信終了時刻よりも所定時間後まで、マルチキャストグループからの離脱要求を受け付けるものと判断することが好ましい。
【００６０】
本発明の第２の特徴は、所定の端末に対して配信される所定のマルチキャストデータを中継するデータ中継方法が、所定のマルチキャストデータの配信を開始する配信開始時刻と所定のマルチキャストデータの配信を終了する配信終了時刻とを含む配信期間情報を受信するステップと、マルチキャストグループへの加入要求又はマルチキャストグループからの離脱要求を受け付けるか否かを、配信期間情報に基づいて判断するステップとを具備することを要旨とする。
【００６１】
【発明の実施の形態】
本実施形態におけるデータ中継装置（例えば、ＩＧＭＰルータ）は、データ配信装置によって配信される所定の番組（マルチキャストデータ）の配信期間に基づいて、マルチキャストグループへの加入要求（又は、マルチキャストグループからの離脱要求）が有効なものであるか否かを判断するものである。また、本実施形態におけるデータ中継装置は、マルチキャストグループへの加入要求（又は、マルチキャストグループからの離脱要求）が有効なものであるか否かを示す判断結果に基づいて、ＤｏＳアタックの検出、及び、認証モード（「Ｎｏｒｍａｌモード」・「Ａｌｅｒｔモード」）の切り替えを行う。
【００６２】
なお、本実施形態において、マルチキャストグループを管理するプロトコルは、ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）であるものとして説明する。
【００６３】
（データ中継装置の構成）
以下において、本実施形態におけるデータ中継装置の構成について、図面を参照しながら説明する。図１は、本実施形態におけるデータ中継装置が設置されている環境を示す図である。図１に示すように、本実施形態におけるデータ中継装置３０ａ〜３０ｉは、データ配信装置２０によって所定のマルチキャストグループ宛（データ受信装置４０ａ〜４０ｃ）に配信される所定のデータ（以下、マルチキャストデータ）を中継する。また、データ中継装置３０ａ〜３０ｉは、ネットワーク５０を構成する。
【００６４】
なお、本実施形態において、マルチキャストデータは、データ配信装置２０によって配信される期間（以下、配信期間）が予め決められている（配信開始時刻と配信終了時刻とが予め決められている）データである。
【００６５】
データ配信装置２０は、マルチキャストデータ（例えば、放送型のデータ配信サービスにおける所定の番組）を配信する装置であり、ＣＰＵ・ＲＯＭ・ＲＡＭなどのハードウェア資源を備えたコンピュータやサーバなどである。
【００６６】
データ受信装置４０ａ〜４０ｃ（以下、データ受信装置４０）は、データ配信装置２０によって配信されたマルチキャストデータを受信する装置であり、ＣＰＵ・ＲＯＭ・ＲＡＭなどのハードウェア資源を備えたコンピュータなどである。
また、データ受信装置４０は、同一のマルチキャストグループに属しているものとする。
【００６７】
データ中継装置３０ａ〜３０ｉ（以下、データ中継装置３０）は、データ配信装置２０によって配信されたマルチキャストデータをデータ受信装置４０に中継する装置であり、ＩＧＭＰに従って所定の処理を行う機能を備えたＩＧＭＰルータである。
【００６８】
データ中継装置３０の具体的な説明は、以下に示す通りである。図２は、データ中継装置３０の構成を示すブロック図である。
【００６９】
図２に示すように、データ中継装置３０は、通信部３１と、セッション情報処理部３２と、データベース３３と、グループ管理処理部３４と、データ中継処理部３５と、判断部３６とを具備する。
【００７０】
通信部３１は、データ配信装置２０によって所定のマルチキャストグループ宛（データ受信装置４０）に配信されたマルチキャストデータ、及び、当該マルチキャストグループに関するマルチキャストセッション情報を受信する。また、通信部３１は、データ配信装置２０から受信したマルチキャストデータを、マルチキャストセッション情報に基づいてデータ受信装置４０に送信する。
【００７１】
ここで、マルチキャストセッション情報とは、マルチキャストに関連するメタ情報であり、マルチキャストグループのアドレス情報とデータの配信期間に関する情報（以下、配信期間情報）とを含む情報である。なお、マルチキャストセッション情報には、配信ポート番号情報、送信元アドレス情報、セッション識別子情報、送信者情報等が含まれている。また、マルチキャストセッション情報は、データ配信装置２０などによって生成される情報である。
【００７２】
具体的には、ＳＤＰ（ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ）やＩＭＧ（ＩｎｔｅｒｎｅｔＭｅｄｉａＧｕｉｄｅ）やＥＰＧ（ＥｌｅｃｔｒｉｃＰｒｏｇｒａｍＧｕｉｄｅ）等がマルチキャストセッション情報の例である。
【００７３】
なお、通信部３１は、マルチキャストセッション情報が予め決められたマルチキャストアドレス宛に配信されている場合には、当該マルチキャストアドレス宛に配信されるマルチキャストデータとともに、マルチキャストセッション情報を受信する。また、通信部３１は、ユニキャストのプロトコル（例えば、ＨＴＴＰ）を用いて、マルチキャストセッション情報を管理する装置から当該マルチキャストセッション情報を受信するように構成されていてもよい。なお、マルチキャストセッション情報を管理する装置は、データ配信装置２０であることが多い。
【００７４】
通信部３１は、マルチキャストグループへの加入要求（ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＲｅｐｏｒｔメッセージ（以下、「Ｊｏｉｎ」））やマルチキャストグループからの離脱要求（ＩＧＭＰＬｅａｖｅＧｒｏｕｐメッセージ（以下、「Ｌｅａｖｅ」））をデータ受信装置４０から受信すると、当該「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）をグループ管理処理部３４に送信する。
【００７５】
セッション情報処理部３２は、通信部３１を通じてマルチキャストセッション情報を取得すると、当該マルチキャストセッション情報に含まれるマルチキャストグループのアドレス情報と配信期間情報（配信開始時刻・配信終了時刻）とを関連付けてデータベース３３に登録（格納）する。
【００７６】
データベース３３は、セッション情報処理部３２によって登録（格納）される情報（以下、マルチキャスト配信情報テーブル）を記憶するデータベースである。マルチキャスト配信情報テーブルの具体的な説明は、以下に示す通りである。
図４は、マルチキャスト配信情報テーブルの一例を示す図である。
【００７７】
図４に示すように、マルチキャスト配信情報テーブルには、マルチキャストグループのアドレス情報と配信期間情報（配信開始時刻・配信終了時刻）とが含まれている。また、マルチキャスト配信情報テーブルには、これらの情報に加え、送信元アドレス情報やセッション識別子情報などが含まれていてもよい。
【００７８】
グループ管理処理部３４は、一般的なＩＧＭＰに従った所定の処理を行うものである。グループ管理処理部３４は、通信部３１を通じて受信した要求（「Ｊｏｉｎ」又は「Ｌｅａｖｅ」）について、その要求種別（「Ｊｏｉｎ」又は「Ｌｅａｖｅ」）と、マルチキャストグループのアドレス情報とを判断部３６に送信する。また、グループ管理処理部３４は、要求種別とマルチキャストグループのアドレス情報とに加え、送信元アドレス情報などを判断部３６に送信するように構成されていてもよい。
【００７９】
また、グループ管理処理部３４は、判断部３６による判断結果（「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）が有効（正当）なものであるか否かを示す判断結果）に基づいて、通信部３１を通じて受信した要求（「Ｊｏｉｎ」又は「Ｌｅａｖｅ」）に応じた処理を行うように指示する要求処理指示をデータ中継処理部３５に送信する。
【００８０】
データ中継処理部３５は、グループ管理処理部３４から受信した要求処理指示が「Ｊｏｉｎ」に応じた処理を行うように指示するものである場合には、マルチキャストデータの配信経路（マルチキャストツリー）を構築する。また、データ中継処理部３５は、グループ管理処理部３４から受信した要求処理指示が「Ｌｅａｖｅ」に応じた処理を行うように指示するものである場合には、マルチキャストデータを受信する他のデータ受信装置４０が存在するか否かを確認するための「ＩＧＭＰＭｅｍｂｅｒｓｈｉｐＱｕｅｒｙ（以下、「Ｑｕｅｒｙ」）をマルチキャストグループに属するデータ受信装置４０に送信する。なお、データ中継処理部３５は、マルチキャストグループに属するデータ受信装置４０に「Ｑｕｅｒｙ」を送信して予め決められた時間を経過しても、当該「Ｑｕｅｒｙ」に応じた「Ｊｏｉｎ」を受信しない場合には、マルチキャストツリーを削除する。
【００８１】
判断部３６は、要求種別（「Ｊｏｉｎ」又は「Ｌｅａｖｅ」）とマルチキャストグループのアドレス情報とをグループ管理処理部３４から受信すると、データベース３３を参照して、当該マルチキャストグループのアドレス情報が登録（格納）されているか否かを確認する。
【００８２】
また、判断部３６は、要求種別（「Ｊｏｉｎ」又は「Ｌｅａｖｅ」）とマルチキャストグループのアドレス情報とをグループ管理処理部３４から受信すると、当該「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）が有効（正当）なものであるか否かを判断する。
【００８３】
具体的には、グループ管理処理部３４から受信した要求種別が「Ｊｏｉｎ」である場合には、判断部３６は、データベース３３を参照して、配信期間情報に含まれる配信開始時刻と現在時刻とを比較する。また、判断部３６は、配信開始時刻と現在時刻との差異が所定の閾値よりも小さい値であれば、「Ｊｏｉｎ」が有効（正当）なものであると判断し、配信開始時刻と現在時刻との差異が所定の閾値よりも大きい値であれば、「Ｊｏｉｎ」が無効（不正）なものであると判断する。
【００８４】
一方、グループ管理処理部３４から受信した要求種別が「Ｌｅａｖｅ」である場合には、判断部３６は、データベース３３を参照して、配信期間情報に含まれる配信終了時刻と現在時刻とを比較する。また、判断部３６は、配信終了時刻と現在時刻との差異が所定の閾値よりも小さい値であれば、「Ｌｅａｖｅ」が有効（正当）なものであると判断し、配信終了時刻と現在時刻との差異が所定の閾値よりも大きい値であれば、「Ｌｅａｖｅ」が無効（不正）なものであると判断する。
【００８５】
判断部３６は、「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）が有効（正当）なものであるか否かを示す判断結果をグループ管理処理部３４に送信する。
【００８６】
なお、本実施形態において、通信部３１は、所定のマルチキャストデータの配信を開始する配信開始時刻と所定のマルチキャストデータの配信を終了する配信終了時刻とを含む配信期間情報を受信する受信手段を構成する。
【００８７】
また、本実施形態において、判断部３６は、マルチキャストグループへの加入要求又はマルチキャストグループからの離脱要求を受け付けるか否かを、配信期間情報に基づいて判断する判断手段を構成する。
【００８８】
（データ中継装置の動作）
以下において、本実施形態におけるデータ中継装置の動作について図面を参照しながら説明する。図４は、本実施形態におけるデータ中継装置３０に具備される判断部３６の動作について示すフロー図である。
【００８９】
図４に示すように、ステップ１１において、判断部３６は、グループ管理処理部３４から処理要求（要求種別（「Ｊｏｉｎ」又は「Ｌｅａｖｅ」）及びマルチキャストグループのアドレス情報）を受信する。
【００９０】
ステップ１２において、判断部３６は、データベース３３を参照して、グループ管理処理部３４から受信したマルチキャストグループのアドレス情報がデータベース３３に登録（格納）されているか否かを確認する。また、判断部３６は、マルチキャストグループのアドレス情報が登録（格納）されている場合には、ステップ１３の処理に移り、マルチキャストグループのアドレス情報が登録（格納）されていない場合には、ステップ１６の処理に移る。
【００９１】
ステップ１３において、判断部３６は、グループ管理処理部３４から受信した要求種別が「Ｊｏｉｎ」である場合には、データベース３３を参照して、配信期間情報に含まれる配信開始時刻と現在時刻とを比較する。また、判断部３６は、配信開始時刻と現在時刻との差異が所定の閾値よりも小さい値であれば、ステップ１４の処理に移り、配信開始時刻と現在時刻との差異が所定の閾値よりも大きい値であれば、ステップ１５の処理に移る。
【００９２】
一方、判断部３６は、グループ管理処理部３４から受信した要求種別が「Ｌｅａｖｅ」である場合には、データベース３３を参照して、配信期間情報に含まれる配信終了時刻と現在時刻とを比較する。また、判断部３６は、配信終了時刻と現在時刻との差異が所定の閾値よりも小さい値であれば、ステップ１４の処理に移り、配信開始時刻と現在時刻との差異が所定の閾値よりも大きい値であれば、ステップ１５の処理に移る。
【００９３】
ステップ１４において、判断部３６は、グループ管理処理部３４が通信部３１を通じて受信した「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）が有効（正当）なものであることを示す判断結果をグループ管理処理部３４に送信する。
【００９４】
ステップ１５において、判断部３６は、グループ管理処理部３４が通信部３１を通じて受信した「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）が無効（不正）なものであることを示す判断結果をグループ管理処理部３４に送信する。
【００９５】
ステップ１６において、判断部３６は、グループ管理処理部３４が通信部３１を通じて受信した「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）に含まれるマルチキャストグループのアドレス情報がデータベース３３に登録されていないことを示す情報をグループ管理処理部３４に送信する。
【００９６】
（データ中継装置の作用、及び、効果）
本実施形態におけるデータ中継装置３０によれば、データ中継装置３０が、マルチキャストデータの配信期間情報に基づいて、データ受信装置４０から受信したマルチキャストグループへの参加要求（「Ｊｏｉｎ」）（又はマルチキャストグループからの離脱要求（「Ｌｅａｖｅ」））が有効（正当）なものであるか否かを判断することにより、データ中継装置３０は、ＤｏＳアタックである可能性が高い「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）を検出することができる。
【００９７】
これにより、データ中継装置３０は、ＤｏＳアタックである可能性が高い「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）を無視することによって、不正な「Ｊｏｉｎ」（又は「Ｌｅａｖｅ」）によるＤｏＳアタックの弊害を軽減することができる。また、データ配信装置２０やデータ中継装置３０などを管理する管理者等は、データ中継装置３０に受信者を認証する機能が具備されていなくても、ＤｏＳアタックに対する対策を容易に講じることができる。なお、ＤｏＳアタックに対する対策とは、ログを記録することによって管理者が法的手段などに訴えることなどである。
【００９８】
また、データ中継装置３０は、「Ｎｏｒｍａｌモード」から「Ａｌｅｒｔモード」に認証モードを切り替える契機として、マルチキャストデータの配信期間情報に基づく判断結果を利用することにより、データ中継装置３０に受信者を認証する機能が具備されていなくても、効果的に認証モードを切り替えることができる。
【００９９】
（変更例）
以下において、本変更例におけるデータ中継装置について説明する。なお、以下においては、上述の実施形態におけるデータ中継装置と本変更例におけるデータ中継装置との相違点についてのみ説明する。
【０１００】
上述の実施形態においては、データ中継装置３０は、ＩＧＭＰルータであるものとして説明したが、本変更例におけるデータ中継装置３０は、ＩＧＭＰルータではないルータであるものとする。
【０１０１】
すなわち、上述の実施形態においては、データ中継装置３０（ＩＧＭＰルータ）は、データ受信装置４０から受信したマルチキャストグループへの参加要求（「Ｊｏｉｎ」）又はマルチキャストグループからの離脱要求（「Ｌｅａｖｅ」）が有効（正当）なものであるか否かを判断しているが、本変更例において、データ中継装置３０（ＩＧＭＰルータではないルータ）は、他のデータ中継装置３０から受信したマルチキャストツリーの構築要求又はマルチキャストツリーの削除要求が有効（正当）なものであるか否かを判断する。
【０１０２】
なお、データ中継装置３０は、マルチキャスト経路制御プロトコルに基づいて、マルチキャストツリーを構築（又は削除）する。ここで、マルチキャスト経路制御プロトコルとは、ＤＶＭＲＰ、ＭＯＳＰＦ、ＰＩＭ−ＳＭ、ＢＧＭＰなどのプロトコルである。
【０１０３】
以下において、マルチキャスト経路制御プロトコルがＰＩＭ−ＳＭである場合を例に説明する。
【０１０４】
データ中継装置３０は、他のデータ中継装置３０からマルチキャストツリーの構築要求（「ＰＩＭＪｏｉｎメッセージ」）を受信すると、マルチキャストツリーを構築する。このとき、データ中継装置３０は、「ＰＩＭＪｏｉｎメッセージ」を受信した時刻と配信開始時刻とを比較することによって、当該「ＰＩＭＪｏｉｎメッセージ」が有効（正当）なものであるか否かを判断する。また、データ中継装置３０は、マルチキャストツリーの削除要求（「ＰＩＭＰｒｕｎｅメッセージ」）を受信した時刻と配信終了時刻とを比較することによって、当該「ＰＩＭＰｒｕｎｅメッセージ」が有効（正当）なものであるか否かを判断する。
【０１０５】
本変更例におけるデータ中継装置３０によれば、データ中継装置３０がＩＧＭＰルータではないルータであっても、ＤｏＳアタックである可能性が高い「ＰＩＭＪｏｉｎメッセージ」（又は「ＰＩＭＰｒｕｎｅメッセージ」）を検出することができる。
【０１０６】
【発明の効果】
本発明は、無効（不正）なものである可能性が高いマルチキャストグループへの参加要求及びマルチキャストグループからの離脱要求を検出するデータ中継装置、及び、データ中継方法を提供することができる。
【図面の簡単な説明】
【図１】本実施形態におけるデータ中継装置が設置されている環境を示す図である。
【図２】本実施形態におけるデータ中継装置の構成を示すブロック図である。
【図３】本実施形態におけるデータ中継装置に格納されている情報を示す図である。
【図４】本実施形態におけるデータ中継装置の動作を示すフロー図である。
【図５】ＤｏＳアタックの方法及びその対処方法に関する従来技術について説明するための図である。
【符号の説明】
２０…データ配信装置、３０ａ〜３０ｉ…データ中継装置、３１…通信部、３２…セッション情報処理部、３３…データベース、３４…グループ管理処理部、３５…データ中継処理部、３６…判断部、４０ａ〜４０ｃ…データ受信装置、５０…ネットワーク、２０１…データ配信装置、２１０…データ配信装置、３０１〜３０４…ルータ、４０１・４０２…データ受信装置、４１０…データ受信装置、５００…通信回線網[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a data relay apparatus that relays predetermined multicast data distributed to a predetermined terminal, and a data relay method.
[0002]
[Prior art]
As a predetermined data distribution method using the Internet or the like, unicast distribution / broadcast distribution / multicast distribution classified according to the relationship between the data distribution apparatus (sender) and the data reception apparatus (receiver) is widely known. .
[0003]
Unicast distribution is one-to-one communication in which one data distribution apparatus (sender) distributes predetermined data to one data reception apparatus (receiver). At this time, since the amount of data distributed by the data distribution device (sender) increases in proportion to the number of data reception devices (recipients), if the number of data reception devices (recipients) increases, data distribution There is a problem that a load for distributing predetermined data in a device or a communication network increases.
[0004]
In contrast, broadcast distribution and multicast distribution are one-to-many communication in which a single data distribution device (sender) distributes predetermined data to a large number of data reception devices (recipients). Does not occur. Also, unlike broadcast distribution, multicast distribution is a distribution method in which predetermined data is distributed to a data receiving device (recipient) belonging to a specific group (multicast group) by a single operation.
[0005]
As an example of multicast distribution, IP multicast that realizes multicast distribution using IP (Internet Protocol) is widely known. In IP multicast, a multicast group is configured by assigning a multicast IP address to a data receiving device (receiver) that receives the same data. An IP address (hereinafter referred to as a multicast address) assigned to this multicast group is an address unique to the multicast group. A data receiving device (receiver) belonging to a predetermined multicast group is a data receiving device (receiver) belonging to the predetermined multicast group in a data relay device (for example, a router) adjacent to the data receiving device. Information indicating this is transmitted (stored). Thereby, the data receiving device (receiver) belonging to the predetermined multicast group receives the predetermined multicast data distributed to the predetermined multicast group from the data distribution device (sender) via the data relay device or the like. can do.
[0006]
Here, IGMP (Internet Group Management Protocol) is used as a protocol for managing a multicast group between a data receiving apparatus (receiver) that receives predetermined multicast data and a data relay apparatus. The data relay device corresponding to the IGMP is equipped with a function for determining whether or not a data receiving device (recipient) belonging to a predetermined multicast group exists under the data relay device. The multicast routing control protocol between each data relay device includes DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast Open Shortest Path First), PIM-DM (Protocol Independent MultPinMendMintDPI). Multicast Sparse Mode), BGMP (Border Gateway)
Multicast Protocol) and the like are known.
[0007]
In the method of managing a multicast group using IGMP, when a data receiving device (recipient) intends to receive multicast data distributed to a predetermined multicast address, it is a request for joining the multicast group. An “IGMP Membership Report message” is transmitted to the data relay apparatus. The data relay apparatus that has received the “IGMP Membership Report message” constructs a multicast data distribution path (multicast tree) using the above-described multicast path control protocol. As a result, the data relay apparatus receives the multicast data and transmits the multicast data on the network where the data receiving apparatus (recipient) exists. With the above operation, the data receiving device (recipient) can receive the multicast data.
[0008]
When the data relay apparatus receives an “IGMP Membership Report message” from a predetermined data receiving apparatus (recipient), the data relay apparatus receives “IGMP from other data receiving apparatuses (recipients) under the data relay apparatus. If the multicast data has already been received by receiving the “Membership Report message”, the predetermined data receiving device (recipient) sends the multicast data immediately after sending the “IGMP Membership Report message” to the data relay device. Can be received.
[0009]
Further, when the data receiving device (recipient) intends to end the reception of multicast data distributed to a predetermined multicast address, the data receiving device transmits an “IGMP Leave Group message” which is a request to leave the multicast group. Send to device. The data relay device that has received the “IGMP Leave Group message” belongs to the multicast group “IGMP Membership Query” for confirming whether there is another data receiving device (receiver) that receives the multicast data. Sent to data receiver (recipient). The “IGMP Membership Query” is particularly called “IGMP Group Specific Membership Query”.
[0010]
Here, when the data relay device receives the “IGMP Membership Report message” from the data receiving device (receiver) that has received the “IGMP Membership Query”, the data receiving device (receiver) that has received the multicast data receives the “IGMP Membership Report message”. The multicast distribution route (multicast tree) is not deleted because it is determined to exist under the data relay device. In addition, the data relay device does not receive the “IGMP Membership Query” even after a predetermined time (time set in the timer) has elapsed since the transmission of “IGMP Membership Query” to the data reception device (recipient) belonging to the multicast group. If the “Membership Report message” is not received, the multicast receiving route (multicast tree) is deleted because it is determined that the data receiving device (recipient) receiving the multicast data does not exist under the data relay device. With the above operation, the data receiving device (recipient) can end the reception of the multicast data.
[0011]
As described above, in a method (protocol) for managing a multicast group using IGMP, the data relay device can request to join the multicast group (“IGMP Membership Report message”) or a request to leave the multicast group (“MPMP Membership Report message”). By receiving an “IGMP Leave Group message”) from the data receiving device (recipient), predetermined processing relating to the construction or deletion of the multicast distribution route (multicast tree) is performed (for example, Non-Patent Documents 1 to 3).
[0012]
Note that the above description related to IGMP is related to “IGMP Version 2”, and “IGMP Version 3” exists in addition to this. According to “IGMP Version 3”, the data relay device has a function of specifying a multicast data distribution source (data distribution device). Note that “IGMPVersion 3” is an extension of “IGMP Version 2”, and the basic operation thereof is the same as “IGMP Version 2”, and therefore detailed description regarding “IGMP Version 3” is omitted.
[0013]
In the following, an existing technique relating to a DoS attack (Denial of Service Attack) method and a coping method when multicast data is distributed from a data distribution device to a data reception device using IP multicast will be described with reference to the drawings. . FIG. 5 is a diagram for explaining an existing technique related to a DoS attack (Denial of Service Attack) method and a coping method thereof.
[0014]
As shown in the figure, the legitimate data distribution device 201 (legitimate sender) and the fraudulent data delivery device 210 (illegal sender) are the legitimate data reception devices 401 and 402 (legitimate receiver), and It is connected to an unauthorized data receiving device 410 (unauthorized recipient) via the communication network 500. The communication network 500 includes a plurality of data relay devices (routers 301 to 304).
[0015]
First, a DoS attack method by an unauthorized sender (data distribution apparatus 210) will be described. In IP multicast, a data distribution device (sender) does not necessarily belong to a multicast group, so the data distribution device 210 (illegal sender) can distribute illegal data to any multicast group. End up.
[0016]
As this coping method, a sender access control method and a message authentication method are known.
[0017]
The sender access control method means that data relay devices (for example, routers 302 and 304) perform data distribution by filtering the address of a data transmission terminal (sender) on the premise of using SSM (Source Specific Multicast). Method of preventing unauthorized data delivery by device 210 (illegal sender), data relay device (router 303 (entry router)) adjacent to data delivery device 210 (illegal sender) controls data control device (sender) This is a method for preventing the distribution of unauthorized data by the data distribution apparatus 210 (illegal sender) by performing authentication (for example, Non-Patent Documents 4 to 5). A sender access control method based on the use of a bidirectional multicast tree is also known (for example, Non-Patent Document 6).
[0018]
According to these sender access control methods, in multicast delivery in which a data delivery device (sender) and a data reception device (recipient) are connected via a router, an unauthorized sender (unauthorized data delivery device) DoS attack can be prevented, but in multicast distribution in which the data distribution device (sender) and the data reception device (recipient) exist on the same subnetwork, an unauthorized sender (illegal data distribution) DoS attack by the device cannot be prevented.
[0019]
On the other hand, the message authentication method is a method in which a data receiving device (recipient) detects an invalid message (data) by performing message authentication using HMAC-SHA1 or TESLA (Non-Patent Document 7). ).
[0020]
According to this message authentication method, the data receiving device (recipient) can detect the illegal multicast data transmitted by the data distribution device (sender), but the illegal multicast data is received by the data receiving device (receiver). Communication resources such as communication lines are not used effectively.
[0021]
Next, a DoS attack method by an unauthorized recipient (data receiving apparatus 410) will be described.
[0022]
In IP multicast, a data relay device (for example, the router 304) that processes the IGMP protocol unconditionally accepts an “IGMP Membership Report message (hereinafter“ Join ”)” that is a request to join a multicast group. A multicast tree is constructed by “Join” from the receiver (data receiving apparatus 410).
[0023]
As a coping method, the data relay device (router 304) ignores the access control method (for example, Non-Patent Documents 8 and 9) based on the authentication of the data receiving device (recipient) or “Join” that has increased rapidly over a certain period There are known methods to do this.
[0024]
In addition, a data relay device (for example, the router 304) that processes the IGMP protocol unconditionally accepts an “IGMP Leave Group message (hereinafter,“ Leave ”)” that is a request to leave the multicast. The “IGMP Membership Query (hereinafter“ Query ”)” corresponding to “Leave” from the receiving device 410) is transmitted to the legitimate receiver (data receiving devices 401 and 402), and the “Query” corresponding to “Query” is transmitted. Join "is transmitted to the data relay device (router 304). That is, since communication for confirming whether there is a data receiving device (member) belonging to the multicast group occurs, communication resources are wasted. In addition, this influence affects all the data receiving terminals on the sub-network divided by the data relay device (router 304).
[0025]
Even if the unauthorized receiver (data receiving apparatus 410) transmits “Leave” to the data relay apparatus (router 304), the legitimate receiver (data receiving apparatuses 401 and 402) “Join” corresponding to “Query”. Is transmitted to the data relay device (router 304), the multicast tree is not deleted.
[0026]
As a coping method, an access control method based on authentication of the data receiving device (recipient) (for example, as in the case where the multicast tree is constructed by “Join” from the unauthorized recipient (data receiving device 410) (for example, Non-Patent Documents 8 and 9) and methods in which the data relay device (router 304) ignores “Leave” that has increased rapidly over a certain period are known.
[0027]
Further, in IP multicast, an unauthorized receiver (data receiving apparatus 410) may prevent “Join” transmitted in response to “Query” from being transmitted by a legitimate receiver (data receiving apparatuses 401 and 402). I can do it.
[0028]
Specifically, the unauthorized recipient (data reception device 410) sends “Join” to the valid recipients (data reception devices 401 and 402) belonging to the multicast group in response to “Query” from the data relay device (router 304). "Is sent to each. At this time, the unauthorized recipient (data receiving device 410) transmits “Join” using a unique MAC address to the authorized recipient (data receiving device 401/402). The IP header and the IGMP header are the same as the normal “Join”. A legitimate receiver (data receiver 401 or 402) that has received “Join” from an unauthorized receiver (data receiver 410) determines that there is another receiver (data receiver) belonging to the multicast group (misunderstanding) Therefore, transmission of “Join” is suppressed. As a result, the data relay apparatus (router 304) does not receive any “Join” corresponding to “Query”, and therefore deletes the multicast tree.
[0029]
That is, the unauthorized recipient (data receiving device 410) can prevent the multicast data from being relayed by the data relay device (router 304).
[0030]
As a coping method, a method is known in which a receiver (data receiving apparatus) confirms whether or not the destination address of “Join” is a multicast address. In order to realize this coping method, a patch for Linux OS has also been created (Non-Patent Document 10).
[0031]
The DoS attack handling method described in the above description has a certain effect as a handling method for preventing the DoS attack, but is not a fundamental handling method. Further, a combination of a plurality of countermeasures can prevent a DoS attack, but in order to combine a plurality of countermeasures, a lot of cost is required.
[0032]
As a countermeasure method by recipient authentication that is most effective as a countermeasure method against a DoS attack by an unauthorized recipient, a DoS attack in which a recipient authentication procedure is randomly generated can be considered. There is no coping method that effectively prevents this DoS attack. In addition, the coping method by the recipient authentication increases the communication cost when the recipient authentication is not originally necessary.
[0033]
Therefore, rather than preventing the DoS attack itself, it is more effective to indirectly prevent the DoS attack by detecting the DoS attack and taking countermeasures such as legal measures.
[0034]
In the following, an existing technique for detecting a DoS attack by “Join” (or “Leave”) from an unauthorized receiver by switching authentication modes in the IGMP router will be described.
[0035]
The authentication mode in the IGMP router includes two authentication modes, “Normal mode” and “Alert mode”.
[0036]
The “Normal mode” is an authentication mode in which normal processing is performed when the IGMP router receives “Join” or “Leave” from the data receiving apparatus (recipient). On the other hand, “Alert mode” means that when the IGMP router receives “Join” or “Leave” from the data receiving device (recipient), the recipient authentication proposed in Non-Patent Documents 8 and 9 is performed. The authentication mode to perform.
[0037]
When the receiver authentication fails in the “Alert mode”, the IGMP router determines that there is a possibility of receiving a DoS attack (detects “Join” or “Leave” that may be a DoS attack). . There are a plurality of methods for the IGMP router to switch the authentication mode from “Normal mode” to “Alert mode” as described below.
[0038]
First, a method will be described in which the IGMP router switches the authentication mode by monitoring the reception interval of “Join” (or “Leave”) from the data reception device (recipient). Specifically, when the number of times of reception (hereinafter referred to as “reception rate”) per unit time of “Join” (or “Leave”) from the data receiving device (recipient) exceeds the threshold value, the IGMP router performs “Normal mode”. The authentication mode is switched from “Alert mode”. Note that the IGMP router may use the data reception device address ("Join" transmission source address) or the reception rate for each multicast address by examining the IGMP header.
[0039]
Next, a method for switching the authentication mode based on “Leave” addressed to a multicast group in which the IGMP router does not relay multicast data (no multicast tree is constructed) will be described. Specifically, the IGMP router uses the “method proposed in Non-Patent Documents 8 and 9” and “IGMP version 3” to manage the subscription status of receivers to the multicast group for each multicast group. As a premise, when “Leave” addressed to a multicast group that is not relaying multicast data is received, the authentication mode is switched from “Normal mode” to “Alert mode”.
[0040]
Finally, a method for switching the authentication mode by randomly authenticating the recipient when the IGMP router receives “Join” (or “Leave”) will be described. Specifically, the receiver authenticates the recipient at random when the IGMP router receives “Join” (or “Leave”) on the assumption that the receiver authentication method (Non-Patent Documents 8 and 9) is used. In the case of failure, the authentication mode is switched from “Normal mode” to “Alert mode”.
[0041]
[Non-Patent Document 1]
By Thomas Maufer, translated by Hiroyuki Enomoto, “Introduction to IP Multicast”, first edition, Kyoritsu Publishing Co., Ltd., November 2001
[0042]
[Non-Patent Document 2]
Dave Kosiur, translated by Yukio Hamada, “Mastering TCP / IP Multicast”, 1st edition, 2nd edition, November 2000
[0043]
[Non-Patent Document 3]
Beau Williamson, Comsus Translation, Cisco Systems Translation, “IP Multicast Network Development Guide Vol. 1”, first edition, July 2001
[0044]
[Non-Patent Document 4]
A. Ballardie et al., “Multicast-specific security threats and counter-measures”, ISOC NDSS, 1995.
[0045]
[Non-Patent Document 5]
R. Lehtonen et al., “Controlled multicast frame framework” IEEE Local Computer Networks (LCN) 02, 2002
[0046]
[Non-Patent Document 6]
N. Wang et al., “Towards dynamic sender access control for bi-directional multicast trees”, IEEE GLOBECOM, Vol. 3, 2001
[0047]
[Non-Patent Document 7]
A. Perrig et al., "Efficient and Secure Source Authentication for Multicast", ISOC NDSS, 2001
[0048]
[Non-Patent Document 8]
Hidetoshi Ueno et al., “Access Control & Group Key Distribution Protocol for Multicast Communication” FIT 2003, 2003
[0049]
[Non-patent document 9]
Hayashi Masamasa et al., “Group Management Protocol IGAP that Enables User Authentication” IEICE Technical Report, NS 2002-278, 2003
[0050]
[Non-Patent Document 10]
K. Ramachandran, “Spoofed IGMP Report Denial of Service Vulnerability”, http: // www. cs. ucsb. edu / ￣krishna / igmp_dos /
[0051]
[Problems to be solved by the invention]
By the way, in a broadcast-type data distribution service, a data distribution period is often determined in advance. For example, a distribution period in which a predetermined program (multicast data) is distributed by a data distribution apparatus using IP multicast is a predetermined end time (for example, January 1, 2003 0:30 AM). For example, it is generally determined in advance, for example, until January 1, 2003, 0:40 AM).
[0052]
However, in the above-described DoS attack handling method and authentication mode switching, the multicast data distribution period and the time of receiving “Join” (or “Leave”) from the receiver (“Join” (or “Leave”) are generated. There is no system (method) for judging the effectiveness of the “Join” (or “Leave”) by comparing the time).
[0053]
Specifically, for a predetermined program (multicast data) distributed during a predetermined distribution period (January 1, 2003, 0:30 AM to 0:40 AM), the data receiving apparatus (recipient) receives a 20031 If the data relay device (for example, IGMP router) receives “Join” at 12:30 PM on February 2, the data relay device may perform the above-described DoS attack handling method or authentication mode switching. There was a problem of accepting the “Join”. In addition, even when the data relay device receives “Leave” at 12:30 PM on December 31, 2002 from the data receiving device (recipient), the data relay device also handles the above-described DoS attack handling method and authentication mode. Even when switching is performed, there is a problem that the “Leave” is accepted.
[0054]
Therefore, the present invention has been made to solve the above-described problem, and compares the data distribution period with the reception time of “Join” (or “Leave”) from the data receiving device (recipient). It is an object of the present invention to provide a data relay apparatus and a data relay method that can detect “Join” (or “Leave”) that is likely to be invalid (unauthorized).
[0055]
[Means for Solving the Problems]
A first feature of the present invention is that a data relay device that relays predetermined multicast data distributed to a predetermined terminal performs distribution start time at which distribution of predetermined multicast data is started and distribution of predetermined multicast data. Receiving means for receiving distribution period information including a distribution end time to be ended, and determination means for determining whether to accept a request to join or leave a multicast group based on the distribution period information. The gist is to provide.
[0056]
According to such a feature, the data relay device determines whether to accept a request for joining or leaving the multicast group received from the data receiving device based on predetermined multicast data distribution period information. As a result, the data relay device 30 can detect “Join” (or “Leave”) that is highly likely to be a DoS attack.
[0057]
As a result, the data relay device 30 ignores a request to join a multicast group or a request to leave the multicast group that are likely to be a DoS attack, thereby leaving the illegal multicast group or leaving the multicast group. The adverse effects of DoS attacks due to requests can be reduced. In addition, an administrator who manages a data distribution device, a data relay device, or the like can easily take measures against a DoS attack even if the data relay device does not have a function of authenticating a receiver. Note that the countermeasure against DoS attack is that an administrator appeals to legal means by recording a log. Furthermore, the data relay device can effectively switch the authentication mode by using the determination result based on the distribution period information of the multicast data as an opportunity to switch the authentication mode from “Normal mode” to “Alert mode”.
[0058]
Further, in the first feature of the present invention, it is preferable that the determining means determines that a request for joining the multicast group is received from a predetermined time before the distribution start time included in the distribution period information to the distribution end time. .
[0059]
Furthermore, in the first feature or the second feature of the present invention, the judging means accepts a request for leaving the multicast group from a delivery start time included in the delivery period information to a predetermined time after the delivery end time. It is preferable to judge.
[0060]
According to a second aspect of the present invention, there is provided a data relay method for relaying predetermined multicast data distributed to a predetermined terminal, including a distribution start time for starting distribution of predetermined multicast data and distribution of predetermined multicast data. Receiving distribution period information including an end distribution end time, and determining whether to accept a request to join or leave a multicast group based on the distribution period information. This is the gist.
[0061]
DETAILED DESCRIPTION OF THE INVENTION
The data relay device (for example, IGMP router) in the present embodiment is configured to request to join the multicast group (or leave the multicast group based on the distribution period of a predetermined program (multicast data) distributed by the data distribution device. Request) is valid. In addition, the data relay device according to the present embodiment detects a DoS attack based on a determination result indicating whether a request to join a multicast group (or a request to leave the multicast group) is valid, and , The authentication mode (“Normal mode” / “Alert mode”) is switched.
[0062]
In the present embodiment, the protocol for managing the multicast group is described as being IGMP (Internet Group Management Protocol).
[0063]
(Configuration of data relay device)
Hereinafter, the configuration of the data relay apparatus according to the present embodiment will be described with reference to the drawings. FIG. 1 is a diagram illustrating an environment in which a data relay device according to the present embodiment is installed. As shown in FIG. 1, the data relay devices 30a to 30i in the present embodiment are predetermined data (hereinafter referred to as multicast data) distributed by the data distribution device 20 to a predetermined multicast group (data reception devices 40a to 40c). Relay. Further, the data relay devices 30 a to 30 i constitute a network 50.
[0064]
In the present embodiment, the multicast data is data in which a period for distribution by the data distribution apparatus 20 (hereinafter, distribution period) is determined in advance (a distribution start time and a distribution end time are determined in advance). is there.
[0065]
The data distribution device 20 is a device that distributes multicast data (for example, a predetermined program in a broadcast-type data distribution service), and is a computer or server that includes hardware resources such as a CPU, a ROM, and a RAM.
[0066]
The data receiving devices 40a to 40c (hereinafter, the data receiving device 40) are devices that receive multicast data distributed by the data distribution device 20, and are computers equipped with hardware resources such as CPU, ROM, and RAM. .
Further, it is assumed that the data receiving device 40 belongs to the same multicast group.
[0067]
The data relay devices 30a to 30i (hereinafter, data relay device 30) are devices that relay multicast data distributed by the data distribution device 20 to the data reception device 40, and are provided with a function of performing predetermined processing according to IGMP. It is a router.
[0068]
A specific description of the data relay device 30 is as follows. FIG. 2 is a block diagram showing a configuration of the data relay device 30.
[0069]
As shown in FIG. 2, the data relay device 30 includes a communication unit 31, a session information processing unit 32, a database 33, a group management processing unit 34, a data relay processing unit 35, and a determination unit 36. .
[0070]
The communication unit 31 receives multicast data distributed to a predetermined multicast group (data reception device 40) by the data distribution device 20 and multicast session information related to the multicast group. In addition, the communication unit 31 transmits the multicast data received from the data distribution device 20 to the data reception device 40 based on the multicast session information.
[0071]
Here, the multicast session information is meta information related to multicast, and is information including address information of the multicast group and information related to the data distribution period (hereinafter, distribution period information). The multicast session information includes distribution port number information, source address information, session identifier information, sender information, and the like. The multicast session information is information generated by the data distribution device 20 or the like.
[0072]
Specifically, SDP (Session Description Protocol), IMG (Internet Media Guide), EPG (Electric Program Guide), etc. are examples of multicast session information.
[0073]
When the multicast session information is distributed to a predetermined multicast address, the communication unit 31 receives the multicast session information together with the multicast data distributed to the multicast address. The communication unit 31 may be configured to receive the multicast session information from a device that manages the multicast session information using a unicast protocol (for example, HTTP). Note that a device that manages multicast session information is often the data distribution device 20.
[0074]
The communication unit 31 sends a request to join a multicast group (IGMP Membership Report message (hereinafter “Join”)) or a request to leave the multicast group (IGMP Leave Group message (hereinafter “Leave”)) from the data receiving device 40. When received, “Join” (or “Leave”) is transmitted to the group management processing unit 34.
[0075]
When the session information processing unit 32 acquires the multicast session information through the communication unit 31, the session information processing unit 32 associates the multicast group address information included in the multicast session information with the distribution period information (distribution start time / distribution end time) in the database 33. Register (store).
[0076]
The database 33 is a database that stores information registered (stored) by the session information processing unit 32 (hereinafter, a multicast distribution information table). The specific description of the multicast distribution information table is as follows.
FIG. 4 is a diagram illustrating an example of the multicast distribution information table.
[0077]
As shown in FIG. 4, the multicast distribution information table includes multicast group address information and distribution period information (distribution start time / distribution end time). In addition to these pieces of information, the multicast distribution information table may include source address information and session identifier information.
[0078]
The group management processing unit 34 performs predetermined processing according to general IGMP. For the request (“Join” or “Leave”) received through the communication unit 31, the group management processing unit 34 sends the request type (“Join” or “Leave”) and the multicast group address information to the determination unit 36. Send. Further, the group management processing unit 34 may be configured to transmit source address information and the like to the determination unit 36 in addition to the request type and the multicast group address information.
[0079]
Further, the group management processing unit 34 uses the communication unit 31 based on the determination result by the determination unit 36 (determination result indicating whether “Join” (or “Leave”) is valid (valid)). A request processing instruction that instructs to perform processing according to the received request (“Join” or “Leave”) is transmitted to the data relay processing unit 35.
[0080]
If the request processing instruction received from the group management processing unit 34 instructs to perform processing according to “Join”, the data relay processing unit 35 constructs a multicast data distribution route (multicast tree). To do. Further, when the request processing instruction received from the group management processing unit 34 instructs to perform processing according to “Leave”, the data relay processing unit 35 receives other data that receives multicast data. “IGMP Membership Query (hereinafter,“ Query ”) for confirming whether or not the device 40 exists is transmitted to the data receiving device 40 belonging to the multicast group. When the data relay processing unit 35 does not receive “Join” corresponding to the “Query” even after a predetermined time has elapsed after transmitting “Query” to the data receivers 40 belonging to the multicast group. Delete the multicast tree.
[0081]
Upon receiving the request type (“Join” or “Leave”) and the multicast group address information from the group management processing unit 34, the determination unit 36 refers to the database 33 and registers (stores) the multicast group address information. ) Is confirmed.
[0082]
Further, when the determination unit 36 receives the request type (“Join” or “Leave”) and the multicast group address information from the group management processing unit 34, the “Join” (or “Leave”) is valid (valid). It is judged whether it is a thing.
[0083]
Specifically, when the request type received from the group management processing unit 34 is “Join”, the determination unit 36 refers to the database 33 and determines the distribution start time and the current time included in the distribution period information. Compare If the difference between the distribution start time and the current time is a value smaller than a predetermined threshold, the determination unit 36 determines that “Join” is valid (valid), and determines the distribution start time and the current time. If the difference between the two is larger than a predetermined threshold value, it is determined that “Join” is invalid (unauthorized).
[0084]
On the other hand, when the request type received from the group management processing unit 34 is “Leave”, the determination unit 36 refers to the database 33 and compares the distribution end time included in the distribution period information with the current time. . If the difference between the distribution end time and the current time is a value smaller than a predetermined threshold, the determination unit 36 determines that “Leave” is valid (valid), and determines the distribution end time and the current time. If the difference between the two is larger than a predetermined threshold value, it is determined that “Leave” is invalid (unauthorized).
[0085]
The determination unit 36 transmits a determination result indicating whether “Join” (or “Leave”) is valid (valid) to the group management processing unit 34.
[0086]
In the present embodiment, the communication unit 31 constitutes reception means for receiving distribution period information including a distribution start time for starting distribution of predetermined multicast data and a distribution end time for ending distribution of predetermined multicast data. To do.
[0087]
In the present embodiment, the determination unit 36 constitutes a determination unit that determines whether to accept a request to join a multicast group or a request to leave a multicast group based on distribution period information.
[0088]
(Operation of data relay device)
Hereinafter, the operation of the data relay apparatus according to the present embodiment will be described with reference to the drawings. FIG. 4 is a flowchart showing the operation of the determination unit 36 provided in the data relay device 30 in the present embodiment.
[0089]
As shown in FIG. 4, in step 11, the determination unit 36 receives a processing request (request type (“Join” or “Leave”) and multicast group address information) from the group management processing unit 34.
[0090]
In step 12, the determination unit 36 refers to the database 33 to check whether or not the multicast group address information received from the group management processing unit 34 is registered (stored) in the database 33. If the multicast group address information has been registered (stored), the determination unit 36 proceeds to the processing of step 13. If the multicast group address information has not been registered (stored), the determination unit 36 proceeds to step 16. Move on to processing.
[0091]
In step 13, when the request type received from the group management processing unit 34 is “Join”, the determination unit 36 refers to the database 33 to determine the distribution start time and the current time included in the distribution period information. Compare. If the difference between the distribution start time and the current time is smaller than a predetermined threshold, the determination unit 36 proceeds to the process of step 14 and the difference between the distribution start time and the current time is smaller than the predetermined threshold. If the value is larger, the process proceeds to step 15.
[0092]
On the other hand, when the request type received from the group management processing unit 34 is “Leave”, the determination unit 36 refers to the database 33 and compares the distribution end time included in the distribution period information with the current time. . If the difference between the distribution end time and the current time is smaller than a predetermined threshold, the determination unit 36 proceeds to the processing of step 14 and the difference between the distribution start time and the current time is smaller than the predetermined threshold. If the value is larger, the process proceeds to step 15.
[0093]
In step 14, the determination unit 36 displays a determination result indicating that “Join” (or “Leave”) received by the group management processing unit 34 through the communication unit 31 is valid (valid). Send to.
[0094]
In step 15, the determination unit 36 displays a determination result indicating that the “Join” (or “Leave”) received by the group management processing unit 34 via the communication unit 31 is invalid (unauthorized). Send to.
[0095]
In step 16, the determination unit 36 is information indicating that the multicast group address information included in “Join” (or “Leave”) received by the group management processing unit 34 through the communication unit 31 is not registered in the database 33. Is transmitted to the group management processing unit 34.
[0096]
(Operation and effect of data relay device)
According to the data relay device 30 in the present embodiment, the data relay device 30 requests to join the multicast group (“Join”) (or multicast group) received from the data reception device 40 based on the multicast data distribution period information. By determining whether or not the request to leave (“Leave”) is valid (valid), the data relay device 30 is more likely to be a DoS attack, “Join” (or “Leave”). ) Can be detected.
[0097]
As a result, the data relay device 30 ignores “Join” (or “Leave”) that is highly likely to be a DoS attack, thereby reducing the adverse effects of DoS attack caused by an illegal “Join” (or “Leave”). can do. In addition, an administrator who manages the data distribution apparatus 20 and the data relay apparatus 30 can easily take measures against the DoS attack even if the data relay apparatus 30 does not have a function of authenticating the receiver. . Note that the countermeasure against DoS attack is that an administrator appeals to legal means by recording a log.
[0098]
Further, the data relay device 30 authenticates the receiver to the data relay device 30 by using the determination result based on the distribution period information of the multicast data as an opportunity to switch the authentication mode from “Normal mode” to “Alert mode”. Even if the function to perform is not provided, the authentication mode can be switched effectively.
[0099]
(Example of change)
In the following, the data relay apparatus according to this modification will be described. In the following, only the differences between the data relay device in the above-described embodiment and the data relay device in the present modification will be described.
[0100]
In the above-described embodiment, the data relay device 30 is described as being an IGMP router. However, the data relay device 30 in the present modification is assumed to be a router that is not an IGMP router.
[0101]
That is, in the above-described embodiment, the data relay device 30 (IGMP router) receives a request to join the multicast group (“Join”) or a request to leave the multicast group (“Leave”) received from the data receiving device 40. Although it is determined whether or not it is valid (valid), in this modification, the data relay device 30 (router that is not an IGMP router) requests to build a multicast tree received from another data relay device 30. Alternatively, it is determined whether or not the multicast tree deletion request is valid (valid).
[0102]
The data relay device 30 constructs (or deletes) the multicast tree based on the multicast routing protocol. Here, the multicast routing protocol is a protocol such as DVMRP, MOSPF, PIM-SM, or BGMP.
[0103]
Hereinafter, a case where the multicast routing protocol is PIM-SM will be described as an example.
[0104]
When receiving a multicast tree construction request (“PIM Join message”) from another data relay apparatus 30, the data relay apparatus 30 constructs a multicast tree. At this time, the data relay device 30 determines whether or not the “PIM Join message” is valid (valid) by comparing the time when the “PIM Join message” is received with the distribution start time. . Further, the data relay device 30 compares the time when the multicast tree deletion request (“PIM Prune message”) is received with the distribution end time, so that the “PIM Prune message” is valid (valid). Determine whether or not.
[0105]
According to the data relay device 30 in this modification, even if the data relay device 30 is a router that is not an IGMP router, a “PIM Join message” (or “PIM Prune message”) that is highly likely to be a DoS attack is detected. can do.
[0106]
【The invention's effect】
The present invention can provide a data relay apparatus and a data relay method for detecting a request to join a multicast group and a request to leave the multicast group that are likely to be invalid (unauthorized).
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an environment in which a data relay device according to an embodiment is installed.
FIG. 2 is a block diagram illustrating a configuration of a data relay device according to the present embodiment.
FIG. 3 is a diagram illustrating information stored in a data relay device according to the present embodiment.
FIG. 4 is a flowchart showing the operation of the data relay device in the present embodiment.
FIG. 5 is a diagram for explaining a conventional technique related to a DoS attack method and a coping method thereof;
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 20 ... Data delivery apparatus, 30a-30i ... Data relay apparatus, 31 ... Communication part, 32 ... Session information processing part, 33 ... Database, 34 ... Group management process part, 35 ... Data relay process part, 36 ... Judgment part, 40a ˜40c, data receiving device, 50, network, 201, data distribution device, 210, data distribution device, 301-304, router, 401, 402, data reception device, 410, data reception device, 500, communication network

Claims

A data relay device that relays predetermined multicast data distributed to a predetermined terminal,
Receiving means for receiving distribution period information including a distribution start time for starting distribution of the predetermined multicast data and a distribution end time for ending distribution of the predetermined multicast data;
A data relay apparatus comprising: a determination unit that determines whether to accept a request to join a multicast group or a request to leave a multicast group based on the distribution period information.

2. The determination unit according to claim 1, wherein the determination unit determines that a request for joining the multicast group is received from a predetermined time before the distribution start time included in the distribution period information to the distribution end time. The data relay device described.

2. The determination unit according to claim 1, wherein the determination unit determines to accept a withdrawal request from the multicast group from the distribution start time included in the distribution period information to a predetermined time after the distribution end time. The data relay device according to claim 2.

A data relay method for relaying predetermined multicast data distributed to a predetermined terminal,
Receiving distribution period information including a distribution start time for starting distribution of the predetermined multicast data and a distribution end time for ending distribution of the predetermined multicast data;
Determining whether to accept a request to join a multicast group or a request to leave a multicast group based on the distribution period information.