PACKET TRANSFER DEVICE, PACKET TRANSFER SYSTEM, AND PACKET TRANSFER METHOD
外国特許コード | F160008714 |
---|---|
整理番号 | (TDU-252) |
掲載日 | 2016年4月13日 |
出願国 | 世界知的所有権機関(WIPO) |
国際出願番号 | 2015JP050618 |
国際公開番号 | WO 2015174100 |
国際出願日 | 平成27年1月13日(2015.1.13) |
国際公開日 | 平成27年11月19日(2015.11.19) |
優先権データ |
|
発明の名称 (英語) | PACKET TRANSFER DEVICE, PACKET TRANSFER SYSTEM, AND PACKET TRANSFER METHOD |
発明の概要(英語) | The purposes of the present invention are to discard packets that have fraudulently flowed in and to subsequently prevent attack packets and fraudulent packets flowing undetected into the Internet from flowing out to or flowing into the Internet. The packet transfer device according to the present invention is equipped with: multiple ports or multiple channels; a binding table for storing identification information on the ports or channels and the correspondence relation between physical source addresses and logical source addresses; a discard table that is generated or updated as requested; and a transfer unit that transfers a packet to the next hop node when a physical source address-logical source address pair for the packet is present in the binding table, or discards the packet when the pair is not present in the binding table or when the packet corresponds to the discard table. |
|
|
|
|
国際特許分類(IPC) |
|
指定国 |
National States: AE AG AL AM AO AT AU AZ BA BB BG BH BN BR BW BY BZ CA CH CL CN CO CR CU CZ DE DK DM DO DZ EC EE EG ES FI GB GD GE GH GM GT HN HR HU ID IL IN IR IS JP KE KG KN KP KR KZ LA LC LK LR LS LU LY MA MD ME MG MK MN MW MX MY MZ NA NG NI NO NZ OM PA PE PG PH PL PT QA RO RS RU RW SA SC SD SE SG SK SL SM ST SV SY TH TJ TM TN TR TT TZ UA UG US UZ VC VN ZA ZM ZW ARIPO: BW GH GM KE LR LS MW MZ NA RW SD SL SZ TZ UG ZM ZW EAPO: AM AZ BY KG KZ RU TJ TM EPO: AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR OAPI: BF BJ CF CG CI CM GA GN GQ GW KM ML MR NE SN ST TD TG |
日本語項目の表示
発明の名称 | パケット転送装置、パケット転送システム及びパケット転送方法 |
---|---|
発明の概要 | 本発明では、不正に流入したパケットを廃棄すること、さらに、すり抜けてインターネットに流入した攻撃パケットや不正パケットについて以後のインターネットへの流出又は流入を阻止することを目的とする。 本発明にかかるパケット転送装置は、複数のポート又は複数のチャネルと、ポート又はチャネルの識別情報と、送信元物理アドレスと送信元論理アドレスとの対応関係を記憶しておくバインディングテーブルと、要請に応じて生成又は更新する廃棄テーブルと、送信元物理アドレスと送信元論理アドレスとの対がバンディングテーブルに存在するときは、次ホップノードへ転送し、バインディングテーブルに存在しないときはパケットを廃棄し、廃棄テーブルに該当するときはパケットを廃棄する転送部と、を備える。 |
特許請求の範囲 |
[請求項1] 互いにパケットをフレームにカプセル化して送受信する少なくとも一つのノード又は少なくとも一つのエンティティを収容する複数のポート又は複数のチャネルと、 前記ポート又は前記チャネルの識別情報と前記ノード又は前記エンティティが送信する前記フレームの送信元物理アドレスと前記フレームをデカプセル化して取り出したパケットの送信元論理アドレスとの対応関係を記憶しておくマルチレイヤ・バインディングテーブルと、 前記フレームを受信した前記ポート又は前記チャネルをキーに前記マルチレイヤ・バインディングテーブルを検索し、前記フレームの送信元物理アドレスと送信元論理アドレスとの対が前記マルチレイヤ・バンディングテーブルに存在するときは、前記フレームから取り出されたパケットをフレームにカプセル化して前記パケットの送信先論理アドレスに向けて次ホップノードへ転送し、前記マルチレイヤ・バインディングテーブルに存在しないときは前記パケットを廃棄する転送部と、を備える ことを特徴とするパケット転送装置。 [請求項2] 互いにパケットをフレームにカプセル化して送受信する少なくとも一つのノード又は少なくとも一つのエンティティを収容する複数のポート又は複数のチャネルと、 前記ポート又は前記チャネルの識別情報と前記ノード又は前記エンティティが送信する前記フレームの送信元物理アドレスと前記フレームをデカプセル化して取り出したパケットの送信元論理アドレスとの対応関係を記憶しておくマルチレイヤ・バインディングテーブルと、 前記フレームを受信した前記ポート又は前記チャネルをキーに前記マルチレイヤ・バインディングテーブルを検索し、前記フレームの送信元物理アドレスと送信元論理アドレスとの対が前記バンディングテーブルに存在するときは、前記フレームから取り出されたパケットの送信先論理アドレスに向けて転送するルータへ転送し、前記マルチレイヤ・バインディングテーブルに存在しないときは前記パケットを廃棄する転送部と、を備える ことを特徴とするパケット転送装置。 [請求項3] 前記パケット転送装置は、 予め接続された他のパケット転送装置に備わる前記転送部から、受信したポート又はチャネルの識別情報とともに送られてきた認証要求パケット又はフレームについて、認証サーバーへの認証要求を仲介し、前記認証サーバーが認証した認証結果を取得し、前記認証結果に基づいて決定した通信サービス品質を前記マルチレイヤ・バインディングテーブルの記憶の対象にし、 前記ポート又は前記チャネルを介して前記認証要求の要求元のノード又はエンティティの実在確認を行って、前記マルチレイヤ・バインディングテーブルを更新し、 前記マルチレイヤ・バインディングテーブルを他のパケット転送装置に備わる前記転送部に伝達する制御部を備え、 前記転送部は、 前記制御部が伝達してきた前記マルチレイヤ・バインディングテーブルを更新する ことを特徴とする請求項1に記載のパケット転送装置。 [請求項4] 前記制御部は、 前記ポート又はチャネルに接続されるいずれかのノード又はエンティティからの廃棄要請を受け付け、或いは予め定められた所定のノード又はエンティティを定期的にアクセスし取得した廃棄要請に応じて前記転送部の廃棄テーブルを更新し、 前記転送部は、 前記廃棄テーブルに該当するフレーム又はパケットを廃棄する ことを特徴とする請求項1から3のいずれかに記載のパケット転送装置。 [請求項5] 前記転送部と前記制御部は、互いに連携して、 前記ノード又は前記エンティティがブロードキャスト送信した自装置宛アドレス解決要求フレームに呼応して、前記ノード又は前記エンティティに対してアドレス解決要求フレームを同じポート又はチャネルからブロードキャスト送信し、 前記ポート又は前記チャネルを介して返ってきたアドレス解決応答フレームの送信元物理アドレスと送信元論理アドレスの対と、前記自装置宛アドレス解決要求フレームの送信元物理アドレスと送信元論理アドレスの対とを照合することによって、前記ノード又は前記エンティティの物理アドレスと論理アドレスの真正性を検証し認証する ことを特徴とする請求項1から4のいずれかに記載のパケット転送装置。 [請求項6] 前記制御部及び前記転送部は、 前記ノード又は前記エンティティが固定のプロセス識別アドレスを有する場合、前記プロセス識別アドレスを前記マルチレイヤ・バインディングテーブルに記憶する対象にする ことを特徴とする請求項1から5のいずれかに記載のパケット転送装置。 [請求項7] DHCP(Dynamic Host Configuration Protocol)、レイヤ2スイッチ及びW-LAN(Wireless Local Area Network)各機能の一部又はすべてを含めた一体構造である ことを特徴とする請求項1から6のいずれかに記載のパケット転送装置。 [請求項8] 前記転送部または前記制御部は、 認証されたノード又はエンティティが送信したパケットを受信した場合、前記パケットの通信プロトコルに応じて予め定められた値を受信したパケットの所定のフィールドに書き込み、未認証のノード又はエンティティが送信したパケットを受信した場合、前記所定のフィールドをリセットする ことを特徴とする請求項1から7のいずれかに記載のパケット転送装置。 [請求項9] インターネット利用者側に配置されるパケット転送装置と、 請求項1から8のいずれかに記載のインターネット側に配置されるパケット転送装置と、を備え、インターネット側に配置される前記パケット転送装置は、インターネット利用者側に配置される前記パケット転送装置を迂回又はすり抜けてアドレス詐称パケットが送られても、インターネットへの流入を阻止する ことを特徴とするパケット転送システム。 [請求項10] 互いにパケットをフレームにカプセル化して送受信する少なくとも一つのノード又は少なくとも一つのエンティティを収容する複数のポート又は複数のチャネルの識別情報と前記ノード又は前記エンティティが送信する前記フレームの送信元物理アドレスと送信元論理アドレスとの対応関係を記憶しておくマルチレイヤ・バインディングテーブルを、フレームが送られてきたポート又はチャネルの識別情報をキーに検索し、 前記フレームの送信元物理アドレスと送信元論理アドレスとの対が前記バンディングテーブルに存在するときは、前記フレームから取り出したパケットをフレームにカプセル化して前記パケットの送信先論理アドレスに向けて次ホップノードへ転送し、前記マルチレイヤ・バインディングテーブルに存在しないときは前記パケットを廃棄する転送手順を有する ことを特徴とするパケット転送方法。 [請求項11] 互いにパケットをフレームにカプセル化して送受信する少なくとも一つのノード又は少なくとも一つのエンティティを収容する複数のポート又は複数のチャネルの識別情報と前記ノード又は前記エンティティが送信する前記フレームの送信元物理アドレスと送信元論理アドレスとの対応関係を記憶しておくマルチレイヤ・バインディングテーブルを、フレームが送られてきたポート又はチャネルの識別情報をキーに検索し、 前記フレームの送信元物理アドレスと送信元論理アドレスとの対が前記バンディングテーブルに存在するときは、前記フレームから取り出したパケットの送信先論理アドレスに向けて転送するルータへ転送し、前記マルチレイヤ・バインディングテーブルに存在しないときは前記パケットを廃棄する転送手順を有する ことを特徴とするパケット転送方法。 |
明細書 |
明 細 書 発明の名称 : パケット転送装置、パケット転送システム及びパケット転送方法 技術分野 [0001] 本発明は、パケット転送装置、パケット転送システム及びパケット転送方法に関する。 背景技術 [0002] 年々巧妙化・組織化しているサイバー攻撃は、2011年全世界で1兆米ドルの損害を与えたと言われるほど、地球規模での大きな脅威となってきた。とりわけ、ボットウィルスに感染した無数のPCでボットネットを形成し、それを操りWebサイトなどへ攻撃を仕掛けるDDoS攻撃は、これまでの「自分を守ろうとするセキュリティ技術」では防ぐことができず、インターネット全体での対策が必要となっている。 [0003] ところで、警察庁の発表によれば、2012年中に観測されたボットネットによる攻撃では、約97%がSYN(SYNchronize) flood攻撃とUDP(User Datagram Protocol) flood攻撃で、その大半が送信元IPアドレスを詐称(以下、IPアドレス詐称もしくはアドレス詐称)していたことが特徴となっている。IPアドレス詐称対策を行うことが、サイバー攻撃対策として大きな効果を挙げるものと期待される。 [0004] IPアドレス詐称が成功する背景には、インターネット上でのルーティングがパケットの宛先IPアドレスだけを見ていることにある。IPアドレス詐称パケットのインターネットへの流入を阻止しようとするイングレス・フィルタリング技術の一つに、受信したパケットの送信元アドレスが経路表に経路情報として存在するかを調べ、経路情報が見つかればそのパケットを転送し、見つからなければ廃棄するuRPF(Unicast Reverse Path Forwarding)があるが、経路表に記載されたネットワークアドレスのアドレス空間内でのアドレス詐称パケットを中継転送としてしまう不完全性のため、広く導入するまでには至っていない。 [0005] また、予め決められた端末以外がネットワークにアクセスしないように認証によってポートに疎通許可を与えるIEEE802.1X規格がある。これにMACアドレスベースのイングレス・フィルタング機能を付加して、たとえリピータハブを介して未認証端末からフレームが送信されても阻止できる製品もあるが、データリンク層での対策であるため、認証を受けた端末がボットウィルスなどに感染しIPアドレス詐称パケットを送信しても、認証LANスイッチはそれを阻止することはできない。 [0006] さらに、企業などの内部ネットワーク向けに、DHCP(Dynamic Host Configuration Protocol)によるアドレス割り当てを監視し、それと整合しないパケットをフィルタリングするDHCP snooping技術や、単一のポリシーのもとに情報へのアクセス認可などをコントロールするTrusted Network Connect技術、他にもIPアドレス詐称パケットの発信源を特定しようとするIP trace back技術など、様々な試みや製品が出回っているが、いずれもサイバー攻撃を根絶する有効な解決手段とはなっていない(例えば、特許文献1を参照。)。 先行技術文献 特許文献 [0007] 特許文献1 : 特開2003-289338号公報 特許文献2 : 国際公開第2012/077603号 特許文献3 : 特開2007-68190号公報 特許文献4 : US2003/0043853A1 発明の概要 発明が解決しようとする課題 [0008] ところで、関連技術のネットワーク機器では、これまでハードウェアとソフトウェアの両方をベンダーが開発し、それを組み合わせてネットワーク装置として提供していた。ベンダーごとに様々な機能や特徴を持った機器が存在する一方、機器のソフトウェアとハードウェアが一体となっているため、ベンダーが想定するアーキテクチャ以外のネットワーク構成や機能追加ができないのが実情であった。これに対して、SDN(Software Defined Network)は、ネットワークの構成や機能、性能などをソフトウェアの操作だけで動的に設定・変更できるようにしようとするネットワークや概念を指し、各所で開発が進められている。 [0009] 次に、インターネット文化とIPアドレス詐称対策との関わりにおける課題を説明する。インターネットは、様々なポリシーのもとにインターネットサービスプロバイダー(以下、ISP(Internet Service Provider))が自律的に運用しているネットワークを相互接続したものである。サイバー攻撃はインターネット全体の問題であり、IPアドレス詐称対策を部分的に導入してもその効果は微々たるものである。無数に存在するISPや様々な組織、一般利用者のほぼすべてに対策の導入を求めることは極めて困難なことのように思えよう。 [0010] しかしながら、インターネット文化には、TCP/IP(Transmission Control Protocol/Internet Protocol)やDNS(Domain Name System)、メールなどのインターネット基盤技術開発の原動力となった「情報は共有されるべき」や、民主主義の根幹をなす「情報は広く公開されるべき」、政府や官僚、大企業の介入を嫌う「権力は横暴で信用できない」、とともに「クラッキング行為は戒めよ」がある。 [0011] すなわち、民主主義に根ざしたインターネットは、利用者の良識ある行為・行動を前提としており、利用を監視したり制限したりするメカニズムや組織はない。あるのはプロトコルの標準化を行うIETF(Internet Engineering Task Force)や、ドメイン名やIPアドレスなどの有限なインターネット資源を管理するICANN(Internet Corporation for Assigned Names and Numbers)などのインターネットガバナンスだけである。すなわち、インターネットはオープンだが無防備であり、これを悪用したクラッキング行為は厳に戒めるべきとする考えが根底にある。 [0012] IPアドレス詐称パケットは、本人が認識しているか否かはともかく、何等かのクラッキング行為を意図したパケットであることは明らかである。すなわち、IPアドレス詐称パケットがインターネットに流入しないような対策を講じることは、インターネット文化の考え方に沿うものと言えよう。 [0013] そして、インターネットの世界は契約で成り立っており、限られた数の一次ISPの下に、二次/三次ISPさらに利用者が契約し接続している。従って、一次ISPが本発明の費用対効果を認識し導入を決断すれば、下位のISP/組織ユーザ/一般ユーザを含めた契約条項として導入を規定できる。 [0014] 図1及び図23に示すアドレス詐称対策の対象とすべきノードは(本明細書では、ユーザパケットを生成し送受信するホストと、ユーザパケットの生成は行わずパケットの中継転送を行うルータやスイッチを総称する用語として「ノード」を用いる)、利用者本人が意図としているか否かは別として、サイバー攻撃を行うもしくは加担させられるノードとして、いわゆる一般利用者が利用するPC26と、スマートフォン24及び携帯端末25や、サイバー攻撃の踏み台にされるサーバー13などの他に、最近では遠隔操作によって不正プログラムが埋め込まれサイバー攻撃に加担されるデジタルテレビ29や冷蔵庫、プリンタ、ITVカメラ、さらには既設の家庭用ブロードバンドルータなどがある。これらに加えて、IoT(Internet of Things)と呼ばれるセンサーや機器などの「モノ」が、2020年には全世界で260億台がインターネットに接続されると予想されている。これらがウィルスに感染したり、製造工程でマルウェアが埋め込まれ、電力網や鉄道などの社会インフラがサイバー攻撃に曝され、インターネットのみならず社会全体が大混乱に陥ることも懸念されている。 [0015] このようなノードは、アドレス詐称による被害において、インターネット10と接続して主としてマシン同士、すなわちM to M型(Machine to Machine)の端末が攻撃ターゲットとするIPアドレスに送信元IPアドレスを詐称してDRDoS(Distributed Reflection Denial of Service)攻撃に加担させられるケースも報告されている。さらにユーザ宅内に配置される家庭用ブロードバンドルータに当たる本発明のeMLBR12であっても、迂回(バイパス)あるいはWAN回線に直接パソコンを接続し攻撃パケットを送り込むなどの仕掛けが施されればアドレス詐称パケットを外部(インターネット10)に流出することになるため、これらもアドレス詐称対策の対象とすべきノードである。 [0016] また、ネットワークは、iMLBR11及びeMLBR12が含まれるノードの集合であるが、このノードの集合すなわちネットワークをノードと見なし、さらにその集合をネットワークとして扱える、すなわちインターネット10は階層的かつ回帰的な構造をなしている。したがって、上述の「なんでも繋がせる」ポリシーのネットワーク(Untrusted Internet21)が、本発明(iMLBR11又はeMLBR12)によらない既設ルータを介してインターネット10に接続しても、それを信頼できないノードの一つと捉えれば良いことになる。なお、インターネット10は、ホーム認証サーバーとして機能するHRS23(Home RADIUS(Remote Authentication Dial In User Service Server)を有する。 [0017] しかしながら、多様なポリシーのもとで運用しているISPや様々な組織、一般利用者の行為・行動を監視・制御したり、ポリシーの強制もしくはIP trace backに見られるようにISPのポリシーを抉り出したりするような対策は、受け入れられ難い。すなわち、発信元IPアドレスを詐称しているか否かを利用者側の出口とインターネット10の入り口とでチェックし、アドレス詐称パケットであればそれを確実に遮断する、さらにこうした対策をすり抜けてインターネットに流入しようとする攻撃パケットや不正パケットを遮断するための必要最小限にして汎用性のある、そして技術的に実現可能な対策であることが課題である。 [0018] これは、仮に「なんでも繋がせる」ポリシーのISPがいたとしても、その存在を否定するものではなく、同ISPが運用するネットワーク(Untrusted Internet21)や「オニオンルーティング」と呼ばれる仮想回線接続により、通信を複数のノードを経由させることによって接続経路の匿名化を行う匿名ネットワークなどがあっても、これらのネットワークとの接続点(iMLBR11)での検疫を強化し、さらに帯域を狭めることによって攻撃パケットや不正パケットのインターネット10への流入を抑制すれば良いことを意味する。すなわち、上述の課題を満たし得る対策であれば、国際法の制定などを待たずに、民間ベースの契約で地球規模での導入が可能と考えられる。 [0019] 前記課題を解決するために、本発明は、認証要求を行うサプリカントを有し、その真正性が認証された端末はもとより、サプリカントを有せずしかもOSのバージョンアップやファイアウォール機能を持たないまったく無防備な端末(デジタルテレビなどのスマート家電)から送出されるアドレス詐称パケットのインターネット10への流出並びにインターネット10への流入を阻止する。さらに、上記対策をすり抜けてインターネット10に流入した攻撃パケットや不正パケットについても、これを検出したノードからの要請によって、以後、インターネット10への流出並びにインターネット10への流入を阻止する。 課題を解決するための手段 [0020] 上記目的を達成するため、本発明では、パケット転送装置(iMLBR及びeMLBR)のポート又はチャネルの識別情報と送信元物理(所謂MAC)アドレスと送信元論理(所謂IP)アドレスとの対応関係を管理し、フレーム/パケットを受信したポート又はチャネルの識別情報をキーにこの対応関係が存在するかを調べ、対応関係が存在しないパケットをアドレス詐称パケットとみなして廃棄する。さらに、上記対策をすり抜けてインターネットに流入した攻撃パケットや不正パケットを検出したノードからの要請を受けて廃棄テーブルを生成・更新し、この廃棄テーブルに該当するパケットを廃棄する。 [0021] 具体的には、本発明に係るパケット転送装置は、 互いにパケットをフレームにカプセル化して送受信する少なくとも一つのノード又は少なくとも一つのエンティティを収容する複数のポート又は複数のチャネルと、 前記ポート又は前記チャネルの識別情報と前記ノード又は前記エンティティが送信する前記フレームの送信元物理アドレスと前記フレームをデカプセル化して取り出したパケットの送信元論理アドレスとの対応関係を記憶しておくマルチレイヤ・バインディングテーブルと、 前記フレームを受信した前記ポート又は前記チャネルをキーに前記マルチレイヤ・バインディングテーブルを検索し、前記フレームの送信元物理アドレスと送信元論理アドレスとの対が前記バンディングテーブルに存在するときは、前記フレームから取り出されたパケットをフレームにカプセル化して前記パケットの送信先論理アドレスに向けて次ホップノードへ転送し、前記マルチレイヤ・バインディングテーブルに存在しないときは前記パケットを廃棄する転送部と、を備える。 [0022] 具体的には、本発明に係るパケット転送装置は、 互いにパケットをフレームにカプセル化して送受信する少なくとも一つのノード又は少なくとも一つのエンティティを収容する複数のポート又は複数のチャネルと、 前記ポート又は前記チャネルの識別情報と前記ノード又は前記エンティティが送信する前記フレームの送信元物理アドレスと前記フレームをデカプセル化して取り出したパケットの送信元論理アドレスとの対応関係を記憶しておくマルチレイヤ・バインディングテーブルと、 前記フレームを受信した前記ポート又は前記チャネルをキーに前記マルチレイヤ・バインディングテーブルを検索し、前記フレームの送信元物理アドレスと送信元論理アドレスとの対が前記バンディングテーブルに存在するときは、前記フレームから取り出されたパケットの送信先論理アドレスに向けて転送するルータへ転送し、前記マルチレイヤ・バインディングテーブルに存在しないときは前記パケットを廃棄する転送部と、を備える。 [0023] 本発明に係るパケット転送装置は、 予め接続された他のパケット転送装置に備わる前記転送部から、受信したポート又はチャネルの識別情報とともに送られてきた認証要求パケット又はフレームについて、認証サーバーへの認証要求を仲介し、前記認証サーバーが認証した認証結果を取得し、前記認証結果に基づいて決定した通信サービス品質を前記マルチレイヤ・バインディングテーブルの記憶の対象にし、 前記ポート又は前記チャネルを介して前記認証要求の要求元のノード又はエンティティの実在確認を行って、前記マルチレイヤ・バインディングテーブルを更新し、 前記マルチレイヤ・バインディングテーブルを他のパケット転送装置に備わる前記転送部に伝達する制御部を備え、 前記転送部は、 前記制御部が伝達してきた前記マルチレイヤ・バインディングテーブルを更新してもよい。 [0024] 本発明に係るパケット転送装置では、 前記ポート又はチャネルに接続されるいずれかのノード又はエンティティからの廃棄要請を受け付け、或いは予め定められた所定のノード又はエンティティを定期的にアクセスし取得した廃棄要請に応じて前記転送部の廃棄テーブルを更新し、 前記転送部は、 前記廃棄テーブルに該当するフレーム又はパケットを廃棄してもよい。 [0025] 本発明に係るパケット転送装置では、 前記転送部と前記制御部は、互いに連携して、 前記ノード又は前記エンティティがブロードキャスト送信した自装置宛アドレス解決要求フレームに呼応して、前記ノード又は前記エンティティに対してアドレス解決要求フレームを同じポート又はチャネルからブロードキャスト送信し、 前記ポート又は前記チャネルを介して返ってきたアドレス解決応答フレームの送信元物理アドレスと送信元論理アドレスの対と、前記自装置宛アドレス解決要求フレームの送信元物理アドレスと送信元論理アドレスの対とを照合することによって、前記ノード又は前記エンティティの物理アドレスと論理アドレスの真正性を検証し認証してもよい。 [0026] 本発明に係るパケット転送装置では、 前記制御部及び前記転送部は、 前記ノード又は前記エンティティが固定のプロセス識別アドレスを有する場合、前記プロセス識別アドレスを前記マルチレイヤ・バインディングテーブルに記憶する対象にしてもよい。 [0027] 本発明に係るパケット転送装置では、 DHCP(Dynamic Host Configuration Protocol)、レイヤ2スイッチ及びW-LAN(Wireless Local Area Network)各機能の一部又はすべてを含めた一体構造であってもよい。 [0028] 本発明に係るパケット転送装置では、 前記転送部または前記制御部は、 認証されたノード又はエンティティが送信したパケットを受信した場合、前記パケットの通信プロトコルに応じて予め定められた値を受信したパケットの所定のフィールドに書き込みを行ってもよい。また、未認証のノード又はエンティティが送信したパケットを受信した場合、前記所定のフィールドをリセットしてもよい。 [0029] 具体的には、本発明に係るパケット転送システムは、 インターネット利用者側に配置されるパケット転送装置と、 インターネット側に配置されるパケット転送装置と、を備え、インターネット側に配置される前記パケット転送装置は、インターネット利用者側に配置される前記パケット転送装置を迂回又はすり抜けてアドレス詐称パケットが送られても、インターネットへの流入を阻止する。 [0030] 具体的には、本発明に係るパケット転送方法は、 互いにパケットをフレームにカプセル化して送受信する少なくとも一つのノード又は少なくとも一つのエンティティを収容する複数のポート又は複数のチャネルの識別情報と前記ノード又は前記エンティティが送信する前記フレームの送信元物理アドレスと送信元論理アドレスとの対応関係を記憶しておくマルチレイヤ・バインディングテーブルを、フレームが送られてきたポート又はチャネルの識別情報をキーに検索し、 前記フレームの送信元物理アドレスと送信元論理アドレスとの対が前記バンディングテーブルに存在するときは、前記フレームから取り出したパケットをフレームにカプセル化して前記パケットの送信先論理アドレスに向けて次ホップノードへ転送し、前記マルチレイヤ・バインディングテーブルに存在しないときは前記パケットを廃棄する転送手順を有する。 [0031] 具体的には、本発明に係るパケット転送方法は、 互いにパケットをフレームにカプセル化して送受信する少なくとも一つのノード又は少なくとも一つのエンティティを収容する複数のポート又は複数のチャネルの識別情報と前記ノード又は前記エンティティが送信する前記フレームの送信元物理アドレスと送信元論理アドレスとの対応関係を記憶しておくマルチレイヤ・バインディングテーブルを、フレームが送られてきたポート又はチャネルの識別情報をキーに検索し、 前記フレームの送信元物理アドレスと送信元論理アドレスとの対が前記バンディングテーブルに存在するときは、前記フレームから取り出したパケットの送信先論理アドレスに向けて転送するルータへ転送し、前記マルチレイヤ・バインディングテーブルに存在しないときは前記パケットを廃棄する転送手順を有する。 発明の効果 [0032] 本発明によるパケット転送装置を、インターネット10の端部に所謂エッジルータ(iMLBR11)として配備すれば、アドレス詐称パケットや攻撃パケット、不正パケットのインターネット10への流入を阻止する。さらに、本発明によるパケット転送装置を、インターネット利用者側で所謂ブロードバンドルータなど(eMLBR12)として配備すれば、アドレス詐称パケットや攻撃パケット、不正パケットのインターネット10への流出を阻止する。 図面の簡単な説明 [0033] [図1] 本実施形態に係るネットワークの構成図の一例を示す。 [図2] 本実施形態に係るeMLBRの構成図の一例を示す。 [図3] 本実施形態に係るiMLBRの構成図の一例を示す。 [図4] 本実施形態に係る複数の通信機能を有するネットワークの構成要素の一例を示す。 [図5] 本実施形態に係るARPリフレクションを用いたIEEE802.1X非対応ノードとeMLBR間の認証及び上りパケットの転送シーケンスの一例を示す。 [図6] 本実施形態に係る通信手順における構成図の一例を示す。 [図7] 本実施形態に係る通信手順におけるテーブルの一例を示す。 [図8] 本実施形態に係る通信手順におけるフローチャートの一例を示す。 [図9] 本実施形態に係るパケット転送方法を適用した評価結果を示す。 [図10] 本実施形態に係るパケット転送方法を適用した評価結果を示す。 [図11] 本実施形態に係る複数の通信機能を有するネットワークの構成の一例を示す。 [図12] 本実施形態に係るIEEE802.1X対応ノードとeMLBR間の認証及び上りパケットの転送シーケンスの一例を示す。 [図13] 本実施形態に係る複数の通信機能を有するネットワークの一例を示す。 [図14] 本実施形態に係るeMLBR-R(一般住宅向け)とiMLBR間の相互認証及び上りパケットの転送シーケンスの一例を示す。 [図15] 本実施形態に係る複数の通信機能を有するネットワークの構成の一例を示す。 [図16] 本実施形態に係る複数の通信機能を有するネットワークの構成の一例を示す。 [図17] 本実施形態に係る帯域制限によるTVオンラインデータサービスにおける応答性評価の評価環境の一例を示す。 [図18] 本実施形態に係るTVオンラインデータサービスの応答性評価のフローテーブルの一例を示す。 [図19] 本実施形態に係るTVオンラインデータサービスの応答性評価の評価結果を示す。 [図20] 本実施形態に係るTVオンラインデータサービスの応答性評価の評価結果を示す。 [図21] 本実施形態に係るIEEE802.1X対応端末とeMLBR12間のシーケンス動作の一例を示す。 [図22] 本実施形態に係るパケット転送システムにおけるIPv6の適応例の一例を示す。 [図23] 本実施形態に係るネットワークの構成図の一例を示す。 発明を実施するための形態 [0034] 以下、本発明の実施形態について、図面を参照しながら詳細に説明する。なお、本発明は、以下に示す実施形態に限定されるものではない。これらの実施の例は例示に過ぎず、本発明は当業者の知識に基づいて種々の変更、改良を施した形態で実施することができる。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。 [0035] さらに、各実施形態で用いる以下に説明する用語は、すべての実施形態に共通に適用される。 [0036] インターネット:一般的にデジタル伝送媒体を介してコンピュータ同士を相互接続したものをコンピュータネットワークもしくは物理ネットワークと呼び、コンピュータネットワークを、パケット転送装置(ルータやレイヤ3スイッチ)を介して相互接続したものをインターネットワークという。ISPが運用するコンピュータネットワークを相互接続した全世界に開かれたインターネットワークの固有名詞が、インターネット(The Internet)であり、TCP/IPプロトコル体系を用いてパケット通信サービスを提供する。インターネットのパケット通信サービスを利用するには、利用者側ネットワークに配備される家庭用ルータなど(eMLBR)と、専用回線または公衆アクセス回線(電話回線やISDN回線、ADSL回線、光回線、無線回線など)を介して、インターネットの端部に配備されるエッジルータ(iMLBR)に接続する必要がある。なお、移動体通信網では、これまでTCP/IPに準じた独自のプロトコル体系を用いていたが、スマートフォンなどの導入に伴ってTCP/IPを用いたIPネットワークが運用されるようになり、またNGN(Next Generation Network)でもTCP/IPベースのパケット通信サービスが提供されている。本明細書では、これらもインターネットの構成要素として含める。 [0037] パケット:エンドノード間の通信を行うためのレイヤ3(ネットワーク層)における転送単位(PDU: Protocol Data Unit)で、送信元論理アドレスと送信先論理アドレスや、パケットの種別、ユーザーデータを含む。RFC 791規格のIPパケットやITU-T勧告のX.25パケットなどを含む。 [0038] フレーム:デジタル伝送媒体を介して直接接続されている一つの物理ネットワーク内でのノード間の通信を行うためのレイヤ2(データリンク層)のPDUで、パケットを所定のフォーマットにカプセル化(MACヘッダやトレーラを付加したり、MACsecなどによるSecTAGの付加やペイロードの暗号化を含む)して送信する。受信側ではフレームをデカプセル(誤り検査、MACsecなどによるメッセージ認証、暗号化されたペイロードの復号を含む)してパケットを取り出す。MACフレームの他にPPP(Point to Point Protocol)フレーム、HDLC(High-Level Data Link Control)フレーム、ATM(Asynchronous Transfer Mode)セルなどを含む。 [0039] ノード:ユーザパケットを生成し送受信するホストと、ユーザパケットの生成は行わずパケットの中継転送を行うルータやレイヤ3スイッチを総称する用語として「ノード」を用いる。さらに、インターネットは階層的かつ回帰的な構造をなしているため、ノードの集合であるネットワークをノードとして扱うことができる。本明細書では、ネットワークも「ノード」の一つとして扱う。 [0040] エンティティ:利用者、プロセス、クライアント、サーバー、メールアカウントや、NETBOIS名、ホスト名などのなどのベンダー特有のエンティティ、およびそれらから構成されるグループ。 [0041] ポート:物理ポート(所謂LANやルータのスイッチポート)や既存の物理接続を用いてソフトウェア的に構成される仮想ポート、外部とデータを入出力するためのインターフェースなどで、それぞれの装置ごとに識別情報によって識別され管理される。 [0042] チャネル:MACsecのように共有鍵を用いて識別可能なセキュアチャネル(SCI:Secure Channel Identifier)などのチャネル識別情報や送信元MACアドレスをチャネル識別情報として用いてもよい。他に移動体通信などで用いられているTDMAやCDMA、OFDMAなどにおけるタイムスロットや拡散符号、リソースブロックを用いてノードやエンティティに割り当てられるチャネルやスロット、コネクション、セッション、フローラベルなどを含み、それぞれの装置もしくは複数の装置に跨って識別され管理される。 [0043] マルチレイヤ・バインディング・ルータ(MLBR): 本発明によるパケット転送装置の特徴を表す用語として用いるもので、さらに利用者側に配置されるアドレス詐称パケットや攻撃パケット、不正パケットの外部(インターネット)への流出を阻止するものをeMLBR(egress MLBR)、インターネットの端部に所謂エッジルータとして配置されアドレス詐称パケットや攻撃パケット、不正パケットのインターネットへの流入を阻止するものをiMLBR(ingress MLBR)と称する。さらに、eMLBRは家庭に配置されるものをeMLBR-R(Residence)、企業などの組織に配置されるものをeMLBR-O(Organization)、データセンターなどに配置されるものをeMLBR-C(Data Center)、無線LANスポットサービスなどに配置されるものをeMLBR-W(W-LAN Spot Service)、ワイヤレスセンサーネットワークやIoTに配置されるものをeMLBR-S(Sensor Network)、移動体通信網に配置されるものをeMLBR-M(Mobile Network)などと称し、様々な用途・形態に応じて適宜機能を取捨選択あるいは追加して適用することが可能である。 マルチレイヤ・バインディング・フィルタリング装置として、既設のルータの前段に配置しても同様の効果が得られる。 [0044] マルチレイヤ・バインディング(MLB)テーブル: ポート又はチャネルの識別情報と、送信元物理アドレス(所謂MACアドレスやATMで用いるVPI(Virtual Path Identifier)/VCI(Virtual Channel Identifier)などのレイヤ2(データリンク層)アドレス)と、送信元論理アドレス(所謂IPv4アドレスやIPv6アドレスや通信事業者固有のレイヤ3(ネットワーク層)アドレスなど)との対応関係を記憶しておくテーブルで、所定の有効期限(例:4時間)を有する。サーバーの場合は、上記に加え送信元プロセス識別アドレス(所謂well-knownポート番号)もMLBテーブルに加えてもよい。 [0045] 廃棄テーブル:主にサイバー攻撃を受けている被害者ノードReNから、もしくはサイバー攻撃を受けていると判断したノードReNもしくはサイバー攻撃パケットと思われるパケットを検出したノードReNから送られてきたパケットを分析して攻撃又は被害を認定するノードDeNから、もしくは廃棄要請情報をインターネット全体に配信するノードShNからの廃棄要請情報をもとに生成・更新されるテーブルで、送信先/送信元物理アドレスや送信先/送信元論理アドレス、送信先/送信元プロセス識別アドレスの一部又はすべての対、匿名アドレスとそれらの有効期間を管理するテーブル。 [0046] IEEE 802.1X:有線LANや無線LANへの接続時に使用する認証規格で、認証されたノードやエンティティ以外がネットワークに接続できないようにする規格。本発明では、IEEE 802.1Xによる認証をLANスイッチ(データリンク層)に限定するのではなく、レイヤ3スイッチやルータなどのパケット転送装置(ネットワーク層)へ適用する。IEEE802.1Xの認証方式には、本実施形態の説明の中で用いるTLS(Transport Layer Security)の他に、MD5(Message Digest Algorithm 5)やLEAP(Lightweight Extensible Authentication Protocol)、EAP-FAST(EAP-Flexible Authentication via Secure Tunneling)、TTLS(Tunneled Transport Layer Security)、PEAP(Protected EAP)があり、認証方法や認証レベルは異なるものの、これらを適用してもよい。 [0047] サプリカント:ネットワーク上のノードやエンティティの認証において、認証を要求する側、認証される側、クライアント側の機器やソフトウェア、エンティティ。なお、Windows(Windowsは登録商標) 2000(SP4)、Windows XP以降のWindows、及びMac OS XはIEEE802.1X対応のサプリカント機能を標準で内蔵している。 [0048] オーセンティケータ:サプリカントからの要求を受けて、認証サーバーとのやり取りを仲介し、サプリカントの接続可否や通信サービス品質のレベルを決めるプロキシの役割を担う。 [0049] 認証サーバー:クライアントIDとパスワードや、デジタル証明書を用いてノードもしくはエンティティの真正性を(相互に)検証し、クライアントからのアクセスを許可するかどうかをオーセンティケータに通知する。RADIUS(Remote Authentication Dial In User Service)、LDAP(Lightweight Directory Access Protocol)、移動体通信で用いられるHLR(Home Location Register )やMicrosoftのActive Directoryなどのベンダー特有の認証機構を含む [0050] 通信サービス品質(QoS(Quality of Service)):秘匿通信、帯域制限、帯域保証、遅延・ジッタ保証、検閲、送信先IPアドレスの制限、通信可能プロトコルの制限、接続拒否、通信内容記録など。 [0051] OpenFlow:ネットワーク構成や機能、性能などをソフトウェアで動的に設定・変更できるネットワークやコンセプトをSDN(Software Defined Network)と呼び、OpenFlowはクラウドコンピューティングにおける負荷分散などを意図に開発が進められているSDNを実現する技術規格の一つで、経路制御を司る「OpenFlowコントローラ」と、データ転送機能を司る「OpenFlowスイッチ」、そしてコントローラとスイッチがコミュニケーションをするための「OpenFlowプロトコル」からなる。 [0052] ARPリフレクション(ARPF):IEEE802.1Xに対応していないデジタルテレビなどの所謂スマート家電や既設の家庭用ルータ、IoTなど、IEEE802.1Xに非対応ノードもしくはエンティティの論理アドレスおよび物理アドレスの真正性を簡易的に検証し、アドレス詐称パケットを阻止するための本発明において定義する機能である。具体的には、ノードは他ネットワークとの通信を契機にデフォルトゲートウェイ(DGW)のポート又はチャネルを介してアドレス解決(ARP(Address Resolution Protocol))要求パケットを送信するが、ノードがアドレス詐称していなければ、DGWからのARP要求に対してARP応答を返すはずであることから、DGWとして機能するeMLBR又はiMLBRが、ARP要求を送ってきたノードに対して同じポート又はチャネルを介してARP要求を送信することをARPリフレクションと呼ぶ。 [0053] 本実施形態に係るイーグレス・マルチレイヤ・バインディング・パケット転送装置eMLBRの構成例を図2に示し、イングレス・マルチレイヤ・バインディング・パケット転送装置iMLBRの構成例を図3に示す。なお、本実施形態においてeMLBR12及びiMLBR11は、パケット転送装置として機能する。 [0054] 図2は、利用者側に配備されるeMLBR12に必要なほぼすべての機能を実装した例を示す図である。eMLBR-RやeMLBR-O、eMLBR-C、eMLBR-W、eMLBR-S、eMLBR-Mなどは、その用途によって取捨選択して実装される。また、本実施形態に係るパケット転送装置は、DHCPやW-LAN、レイヤ2/VLANなど各機能を有した一体型構造でもよい。この場合、容易なネットワーク管理を実現するパケット転送装置を提供することができる。一方で、ネットワーク管理は煩雑になるが、DHCPやW-LAN、レイヤ2/VLANなどは、別の装置として配備してもよい。さらに、ルーティング機能は既設のルータを使用するケースでは、ルーティング機能に係る機能部を実装しないもしくは当該機能部を停止したイーグレス・マルチレイヤ・バインディング・フィルタリング装置として既設のルータの前段に配置してもよい。具体的には、パケット転送装置として機能するeMLBR12の転送部14では、フレーム/パケットを受信したポート又はチャネルをキーにMLBテーブルを検索し、フレーム/パケットの送信元物理アドレスと送信元論理アドレスとの対がMLBテーブルに存在するときは、パケットの送信先論理アドレスに向けて転送するルータへ転送し、MLBテーブルに存在しないときはパケットを廃棄してもよい。 [0055] eMLBR12は、制御部15を備え、制御部15はさらに受信したポート又はチャネルの識別情報とともに転送部14から伝達されてきたDHCP要求やアドレス解決要求、認証要求などのパケットやフレームを受け付ける処理要求受付部、デジタルテレビやIoTなどのIEEE802.1X非対応ノードに対するARPリフレクションを用いた認証や、iMLBR11との間でデジタル証明書の交換などを行って相互に認証し合う認証部、オーセンティケータとして認証サーバーへの仲介を行う認証仲介部、前記認証部及び認証サーバーからの認証結果を取得する認証結果取得部、ポート又はチャネルの識別情報と送信元物理アドレスと送信元論理アドレスなどとの対応関係をMLBテーブルとして有効期間を附して生成し更新するMLBテーブル生成・更新部、通信を許可したノード又はエンティティの実在確認を行い上述のMLBテーブルの有効期間を更新する実在確認部、MACsecなどによる暗号鍵の生成・交換を行う暗号鍵生成・交換部、他のノードからの廃棄要請に基づいて有効期間を附して生成・更新する廃棄テーブル生成・更新部、認証結果(認証レベル)に基づいて通信サービス品質を決定するQoS決定部、DHCP要求を行ってきたノードに対してIPアドレスを割り当てたり、ネットマスクやDGWのIPアドレスなど、ネットワークの接続に必要な情報を提供するDHCP部、eMLBR12配下で用いられる論理アドレスやプロセス識別アドレスを外部ネットワークで用いる論理アドレスやプロセス識別アドレスに変換するためのNATテーブルを生成するNATテーブル生成部、これらの各機能部での処理結果や認証部で生成するARPリフレクション用のARP要求パケットや実在確認部で生成する実在確認用のパケットなどを転送部14に伝達するための処理結果伝達部、その他図には示していないが転送部15の例えばレイヤ2/VLANスイッチ部などの制御に必要な機能や、IPsecのトンネルモード対応機能、eMLBR12に不正侵入され制御プログラムやテーブルなどが改ざんされていなすかを検査するための完全性検査機能、実装後に発見されたセキュリティホールや新しい機能を追加するためのバージョンアップ機能などを有してもよい。 [0056] また、eMLBR12は、転送部14をさらに備え、転送部14はさらに有線系(Ethernet(Ethernetは登録商標)や光信号など)/無線系(無線LAN/移動体通信など)通信に必要な複数の物理ポートを提供するポート部、又は及び複数のチャネルを提供するチャネル部、物理信号受信・復号部、物理信号生成・送信部、暗号化/復号部、パケットもしくはフレームを一時的にバッファリングする受信バッファ部及び送信バッファ部、受信したフレームからパケットを取り出すフレームデカプセル化部、その逆を行うフレームカプセル化部、受信したフレーム及びパケットの送信元及び送信先物理アドレス、送信元及び送信先論理アドレス、送信元及び送信先プロセス識別アドレスを抽出するレイヤ2、3、4アドレス抽出部、ポート又はチャネルに対して指定された通信サービス品質を提供するQoS提供部、レイヤ2スイッチ及びVLAN機能を提供するレイヤ2/VLANスイッチ部、MLBテーブルを格納するMLBテーブル部、廃棄テーブルを格納する廃棄テーブル部、MLBテーブルや廃棄テーブルを検索してパケットを廃棄するパケット廃棄部、ルーティングテーブルを参照してパケットの転送処理を行うレイヤ3スイッチ部、DHCP要求やアドレス解決要求、認証要求などのフレームもしくはパケットを制御部15の前記受付部へ伝達し処理を要求する処理要求伝達部、制御部15から伝達されてきた処理結果を該当する各機能部に反映もしくは中継する処理結果受付部などを有してもよい。 [0057] 図3は、インターネット10側の端部に配備されるiMLBR11に必要なほぼすべての機能を実装した例を示す図である。各機能部の機能は図2のeMLBR12とほぼ同じであるので、詳しい説明は省略するが、NAT機能やレイヤ2/VLAN機能は原則不要である。また、本実施形態に係るパケット転送装置は、DHCPなど各機能を有した一体型構造でもよい。この場合、容易なネットワーク管理を実現するパケット転送装置を提供することができる。一方で、ネットワーク管理は煩雑になるが、DHCPなどは、別の装置として配備してもよい。さらに、ルーティング機能は既設のルータを使用するケースでは、ルーティング機能に係る機能部を実装しないもしくは当該機能部を停止したイングレス・マルチレイヤ・バインディング・フィルタリング装置として既設のルータの前段に配置してもよい。具体的には、パケット転送装置として機能するiMLBR11の転送部14では、フレーム/パケットを受信したポート又はチャネルをキーにMLBテーブルを検索し、フレーム/パケットの送信元物理アドレスと送信元論理アドレスとの対がバンディングテーブルに存在するときは、パケットの送信先論理アドレスに向けて転送するルータへ転送し、MLBテーブルに存在しないときはパケットを廃棄してもよい。 [0058] iMLBR11は、制御部15を備え、IEEE802.1X非対応ノードに対する認証や、eMLBR12とiMLBR11との間でデジタル証明書の交換などを行って相互認証を行う。また、iMLBR11は、転送部14を備え、物理信号受信・復号部/生成・送信部は、有線系(Ethernet(Ethernetは登録商標)や光信号など)/無線系(無線LAN/移動体通信など)に必要な機能を有する。 [0059] (実施形態1) 本実施形態では、ARPリフレクション(ARPF)によるデジタルテレビや、ファックスやスキャナー、プリンタなど複数の機能を搭載した複合機、さらにIoTなどのIEEE802.X非対応ホストのeMLBR12による認証及び上りパケットの転送シーケンスの動作例を説明する。本実施形態に係るネットワークの構成を図4に示す。図4に示すネットワーク構成は、iMLBR11を含んだインターネット10、IEEE802.1X非対応のノード及びeMLBR12で構成している。 [0060] 図5におけるシーケンス図は、ARPリフレクションを用いたデジタルテレビなどのIEEE802.1X非対応ノードとeMLBR12間の認証及び上りパケットの転送シーケンスを示した図である。図5では、ノードから外部ネットワーク(インターネット10)に向けて送信されるユーザMACフレーム/IPパケットに係わるものについて記述している。本実施形態におけるDHCPプロトコルのやり取りなどは、簡略化して記述している(例えば、DHCP Discover⇒DHCP Offer⇒DHCP Request⇒DHCP ACKと4回やり取りする)。また、図及び説明が煩雑になるのを避けるため、各ステップに係わる転送部14及び制御部15の機能部の記述も省略している。 [0061] 以下に、図5のシーケンス図の動作を説明する。IEEE802.1X非対応のノードが他ノードへ通信を開始する場合、DHCP要求パケットをブロードキャスト送信する(ステップS111)。DHCP要求を受信したeMLBR12は、受信したポートの識別情報と前記ノードのMACアドレスとプライベートIPアドレスとして割り当てるIPアドレスの対応関係を記憶しておく制御部15のMLBテーブルAに仮登録する(ステップS112)。ノードは、eMLBR12のネットマスクやDGWのIPアドレスなど、ネットワークへの接続に必要な情報とともにIPアドレスを割り当てる旨のDHCP応答パケットを受信する(ステップS113)。DHCP応答を受け取ったノードは、DGWのアドレスの解決要求する旨のARP要求パケットをブロードキャスト送信する(ステップS114)。 [0062] ARP要求パケットを受信したeMLBR12は、ノードがアドレス詐称していなければ、eMLBR12からのARP要求に対してARP応答を返すはずであることから、ARP要求パケット(ARPF要求)をノードにブロードキャスト送信し、ノードからのARP応答パケットを受け取る(ステップS115及びステップS116)。eMLBR12において、ARP応答パケットを受信したポートをキーに制御部15のMLBテーブルAを検索し、ARP応答の送信元IPアドレスと送信元MACアドレスの対が存在しない場合、MLBテーブルAから仮登録した前記対応関係を削除する(ステップS117及びステップS118)。一方、MLBテーブルAに存在する場合、QoS(後述するように、例えば上り帯域を10kbps)を決定し、さらに有効期間(例えば4時間)を設定の上、転送部14のMLBテーブルAに正登録する(ステップS119)。 [0063] 次に、eMLBR12がノードからの最初のARP要求(DGWのアドレス解決)(ステップS114)に対する応答として、ステップS120によるARP応答を返した以降、ノードが送信したユーザMACフレーム/IPパケットをeMLBR12が受け取ると(ステップS121)、eMLBR12は、受け取ったユーザMACフレーム/IPパケットの送信元IPアドレス及び送信元MACアドレスが転送部14のMLBテーブルAに存在するか調べ(ステップS122)、存在しない場合、ノードが送信したパケットを破棄する(ステップS123)。 [0064] 一方、転送部14のMLBテーブルAに存在する場合、ステップS119で決定したQoSで、かつNATテーブルを参照してプライベートIPアドレスからグローバルIPアドレスにアドレス変換して、次ホップノードであるiMLBR11にMACフレームにカプセル化して転送し、iMLBR11がMACフレーム/IPパケットを受け取る(ステップS124)。なお、ステップS120によるARP応答は、ステップS115のARP要求(ARPF要求)で既にノードがeMLBR12のMACアドレスを知っているので、行わなくてもよい。 [0065] また、本実施形態におけるeMLBR12が備える制御部15は、転送部14と連携してノードもしくはエンティティのポートもしくはチャネルでの実在確認を適宜(必ずしも定期的である必要はない)行い(ステップS128及びステップS129)、ステップS130で確認結果に応じてMLBテーブルAを更新(有効期間を延長)してもよい。 [0066] iMLBR11(ISPエッジルータ)は、ステップS124で転送されてきたパケットを受信したポートの識別情報をキーに、パケットのIPアドレス(eMLBR12に割り当てられたグローバルIPアドレス)と(eMLBR12の)MACアドレスとの対が転送部14のMLBテーブルBに存在するか調べ(ステップS125)、MLBテーブルBに存在しない場合、パケットを廃棄する(ステップS126)。一方、転送部14のMLBテーブルBに存在する場合、予めeMLBR12の認証の際に決定されたQoS(eMLBR12がiMLBR11によってIEEE802.1Xノードとして認証されていれば、帯域制限されずに)で次ホップノードに転送する(ステップS127)。 [0067] 本実施形態によるARPリフレクションで認証した場合は、IDやパスワード、あるいはデジタル証明書を用いるIEEE802.1X認証よりセキュアな端末とは言い切れない、すなわち認証レベルは低いため、QoSを例えばインターネット10へ向かう上り方向の帯域を10kbps程度に制限しても、下り方向は帯域制限しなければ、テレビの利用者はリモコン操作によるテレビ局とのデータ通信や画面の遷移、その他のテレビを介したインターネット接続サービスに、違和感を持つことはない。 [0068] したがって、OSのバージョンアップやファイアウォール機能を持たない無防備でサイバー攻撃の温床になりかねないスマート家電やIoTなどが、たとえボットウィルスに感染もしくは製造工程でマルウェアが埋め込まれ、送信元IPアドレスを攻撃ターゲットのIPアドレスに詐称して大量のパケットを送信するDRDoS攻撃、あるいは送信先IPアドレスを攻撃ターゲットのIPアドレスに設定し、送信元IPアドレスをランダムに変えながら大量のパケットを送信するDDoS攻撃などに加担させられても、アドレス詐称パケットのインターネット10への流出を阻止でき、たまたま端末の送信元IPアドレスに一致した攻撃パケットだけがインターネット10に流入するため、被害を最小限に抑えることができる。さらに、後述する実施形態5によって、攻撃パケットが長時間にわたってインターネット10に流出/流入することを阻止することもできる。 [0069] なお、本実施形態では、ノードからのARP要求に対してARPリフレクションを行うものとしているが、例えばノードがeMLBR12のIPアドレスとMACアドレスをキャッシュし、ICMPパケットを用いてeMLBR12へエコー要求(疎通確認)し、このパケット/フレームに対応するMLBテーブルをeMLBR12が保持していないとき、同ノードに対してエコー要求(エコーリフレクション)もしくはARP要求を送り、その応答パケット/フレームとノードからのエコー要求パケット/フレームの送信元IPアドレスと送信元MACアドレスを照合し、一致していれば、制御部15及び転送部14のMLBテーブルに登録するなど、色々なバリエーションでのIPアドレスおよびMACアドレスの真正性の検証による認証を用いてもよい。 [0070] ここで、OpenFlowを用いたARPリフレクションの通信動作の実験例を図6に示す。ホスト♯AはeMLBR12を介してホスト♯Bと通信しようとしている。eMLBR12は、OpenFlowを実行し、本実施形態に係るパケット転送装置として機能する。eMLBR12は制御部15であるOpenFlowコントローラ15と、転送部14であるOpenFlowスイッチ14との二つから構成される。OpenFlowスイッチ14はMLBテーブルを備えている。また、図6では、ホスト#AがDGWのアドレス解決のために送信するARP要求(ステップS211)はOpenFlowコントローラ15に送られ、同コントローラにてホスト#Aに対してARP要求(ARPF)が生成され、OpenFlowスイッチを介してホスト#Aに送られる(ステップS212)。これは、前述したように相手がアドレス詐称している場合ARP応答を返さないだろうという仮定に基づくもので、相手がアドレス詐称していない場合ARP応答を返し(ステップS213)、OpenFlowコントローラにてステップS211で送ってきたARP要求とステップS213で返してきたARP応答のIPアドレスMACアドレスを照合することによってその真正性を検証し、一致していればOpenFlowコントローラ15のMLBテーブルに仮登録し、Flow modにてOpenFlowスイッチ14のMLBテーブルに正登録する。 [0071] OpenFlowコントローラ15の開発フレームワークとしてTrema-edgeをパソコン(OS: Ubuntu 12.04 (X64)、CPU: Celeron 440@2.00 GHz、メモリ:2GB)に実装し、OpenFlowスイッチ14にはOpen vSwitch 2.0.0を同じ仕様の別のパソコンに実装し、レイヤ3スイッチとして動作させた。このプログラムでは、スイッチの各ポートが受け入れるIPアドレスとMACアドレスの対応関係をOpenFlowコントローラ15のMLBテーブルに仮登録し、OpenFlowスイッチ14のMLBテーブルに正登録する。 [0072] 次に、図6、図7及び図8を用いて、本実施形態の動作を説明する。フローテーブルの構成を図7、さらにフローテーブルの遷移を図8に示す。スイッチとして機能するOpenFlowスイッチ14に到着したARP要求やARPFに係わるパケットは、すべてOpenFlowコントローラ15へPacket-In(図7及び図8のテーブル:0)で処理方法を問い合わせるものとし、他のパケットは複数のフローテーブル遷移(パイプライン処理)を通過したもののみがルーティング処理されるか、Packet-Inとしてコントローラへの問い合わせが発生する(同テーブル:180)。 [0073] ホスト♯Aが送信したARP要求をポート1で受信したOpenFlowスイッチ14は、図7及び図8に示したテーブル:0において、OpenFlowコントローラ15に対しPacket-In動作を行う(ステップS211及びステップS311)。OpenFlowコントローラ15は受信したポート1をキーに、受信したARP要求フレーム/パケットの送信元IPアドレスと送信元MACアドレスの対をコントローラ内のMLBテーブルに仮登録する。次いで、OpenFlowコントローラ15は、ARPリフレクションとしてOpenFlowスイッチ14に対してARP要求をPacket-Outし、スイッチはこれをホスト♯Aへポート1から送る(ステップS212)。ホスト♯Aが返してきたARP応答をポート1で受け取ったOpenFlowスイッチ14は、再度コントローラへPacket-Inを発生させる(ステップS213及びステップS312)。コントローラは、ポート1をキーにコントローラ内のMLBテーブルを検索し、ホスト♯AからのARP応答の送信元IPアドレスと送信元MACアドレスの対が存在すれば、同対のノードが実在すると判定し認証する。コントローラはスイッチに対してFlow Mod動作を行って(ステップS214)、「ポート:1」をマッチ条件とするフローエントリを物理ポートテーブル(テーブル:60)に、同対をマッチ条件とするフローエントリをMLBテーブル(テーブル:101)に書き込む(正登録する)。これにより、ポート1に上記対以外のIPパケットが受信されたときは、廃棄されることになる。 以上の処理フローに則りホスト♯Aがコントローラによって認証され、各フローエントリがスイッチ内の該当テーブルに書き込まれたことを、フローエントリ確認コマンドを用いて確認した。 [0074] OpenFlowスイッチ14では、パイプライン処理を活用して、受信したパケットを処理する過程で受信したポートのMLBテーブルに遷移させる(図7及び図8のテーブル:60及び101)。同ポートのMLBテーブルに送信元IP/MACアドレスがあれば、ルーティング動作(図7 テーブル:180、ステップS316)に進めるが、MLBテーブルにないときは廃棄する(図7及び図8のテーブル:101及び102)。 [0075] 本実装例の有効性を検証するために、簡易攻撃ツールhping3を用いてSYN flood攻撃実験を行った。送信元IPアドレスをネットワークアドレス(192.168.2.0/24)の範囲内でランダムに変更しながら、10,000パケットを攻撃先に送信する実験を複数回行った。その結果、攻撃先に到達できたのは10,000パケット中、平均して約30パケット(≒10,000÷256;攻撃元ホスト本来のIPアドレス)で、残りの約9,970パケットは廃棄されたことがスイッチ上のログで確認できた。 [0076] また、ホスト#Aからホスト#B宛にICMPエコー要求パケットを2.5kppsから160kppsまで送信レートを変えて送信したところ、図9及び図10の各々に示すようにMLBテーブル機能オン(図7のすべてのテーブルを活性化)とオフ(図7のテーブル:180のみ活性化)共に、送信レートが高くなるほどホスト#AでのICMP応答パケットの未着率が増えることが観測されたが、OpenFlowスイッチ14のCPU使用率は1%未満で、スイッチでのパケットロスも観測されなかった。これは、ICMPエコー要求パケットを生成・送信しながら、応答パケットの受信を行おうとするホスト#Aが過負荷状態に陥り、応答パケットを取りこぼしているためである。 [0077] 以上から、本実装がIPアドレス詐称に対し有効に機能し、少なくとも家庭用のeMLBR12として十分な性能を有し得ることが確認できた。 [0078] また、図17には帯域制限によるTVオンラインデータサービスの応答性評価の評価環境を示し、図18にはTVオンラインデータサービスの応答性評価のフローテーブルを示す。図18では、NAPT交換は、Paket-Inが多発する。そこでスイッチ内に閉じたNAPT交換モジュールの実装が必要である。図19及び20は、TVオンラインデータサービスの応答性評価の評価結果を示す。図19は、帯域(Kbps)を縦軸とし時間(sec)を横軸として評価結果を示し、表示時間(sec)を縦軸とし帯域(Kbps)を横軸として評価結果を示した。 [0079] (実施形態2) 本実施形態では、IEEE802.1Xを用いたパソコンなどのIEEE802.1X対応ノードとeMLBR12間での認証及び上りパケットの転送シーケンスの動作例を説明する。本実施形態に係るネットワーク構成を図11に示した。図11に示すネットワーク構成は、iMLBR11とHRS23とを含んだインターネット10、ノード及びeMLBR12で構成している。なお、図1や図11、図23などでは、HRS23がインターネットの内部に配置されるように記されているが、不正侵入などによって認証データやプログラムなどが改ざんされないよう、ISPなど信頼できる機関がHRS23を厳重管理することを意味するものであって、iMLBR11やeMLBR12を介して、インターネットの外側に配置されてもよい。以下も同様である。 [0080] 図12は、パソコンなどのIEEE802.1X対応ノードとeMLBR12間のシーケンス動作の例を示す。なお、図12では、ノードから外部ネットワーク(インターネット10)に向けて送信されるMACフレーム/IPパケットに係わるものについて説明する。また、本実施形態におけるDHCPプロトコルや、オーセンティケータによるEAPメッセージとRADIUSメッセージの変換・中継処理などを含むEAP/RADIUSプロトコルのやり取り、MACsecによる鍵の生成/交換/MACフレームの暗号化/復号などは、簡略化もしくは省略している。また、各ステップに係わる転送部14及び制御部15の機能部の記述も省略している。なお、無線LAN機能を搭載したeMLBR-Wなども、基本シーケンスは同じである。 [0081] なお、EAPメッセージを含んだMACフレームはマルチキャストアドレスで送信されるため、EgERの配下にスイッチングハブが配置されている場合、オーセンティケータに届かない。EAPメッセージ用に特定のMACアドレスを割り当てるなど、IEEE802.1X規格の変更が必要である。 [0082] 以下に、図12のシーケンス図の動作を説明する。IEEE802.1X対応ノードのサプリカントは、拡張認証プロトコルである(EAP:Extensible Authentication Protocol)EAPOL(EAP over LAN)により、EAPメッセージフレームをeMLBR12のオーセンティケータに送る(ステップS411)。EAPOLを受け取ったeMLBR12は、EAP要求(TLS)をIEEE802.1X対応ノードに送出し(ステップS412)、ノードびeMLBR12間でEAPメッセージ交換を行い(ステップS413)、eMLBR12はこれをホーム認証サーバーとして機能するRADIUSサーバー23へ仲介する(ステップS414)。認証結果をRADIUSサーバーがeMLBR12へ送信する(ステップS415)。eMLBR12のオーセンティケータは、認証結果を判別(ステップS416)し、認証に失敗した場合はノードにEAP失敗を告げ処理を終了する(ステップS417)。 [0083] 認証に成功した場合、ノードにEAP成功を伝える(ステップS418)とともに、ノードとeMLBR12との間で、IEEE802.1Xで定められたMACsec Key Agreement(MKA)プロトコルによる共有鍵の生成・交換を行い、セキュアチャネルを確立する(ステップS419)。以下、ノードとeMLBR12との間の通信では、同規格の定める共有鍵暗号を用いた秘匿通信が行われるとともに、通信中にデータが改ざんされていないかを検査するメッセージ認証が行われる。 [0084] 認証に成功したノードがDHCP要求をブロードキャスト送信する(ステップS420)と、eMLBR12は、通信サービス品質(QoS)レベルを決定し、さらに有効期間(例えば4時間)を設定するとともに、セキュアチャネルの識別情報をキーに、ノードのMACアドレスとノードに固定的(前回と同じ)あるいは動的に割り当てる(プライベート)IPアドレスとの対応関係を、制御部15のMLBテーブルAに仮登録し(ステップS421)、さらに転送部14のMLBテーブルAに正登録する(ステップS422)。その上で、ノードに対して、ネットマスクやDGWのIPアドレスなど、ネットワークへの接続に必要な情報とともにIPアドレスを割り当てるDHCP応答を送信する(ステップS423)。 [0085] ノードは、以後、eMLBR12との間に確立したセキュアチャネルを介して、すなわちペイロード(ユーザパケット)を、上記共有鍵を用いて暗号化しMACフレームにカプセル化したユーザMACフレームを送信し(ステップS424)、eMLBR12は暗号化ユーザMACフレームをデカプセル化/復号/メッセージ認証を行った後、セキュアチャネルの識別情報をキーに、転送部14のMLBテーブルAを検索し(ステップS425)、送信元IPアドレス及びMACアドレスの対が存在しない場合、同フレーム/パケットを破棄する(ステップS426)。 [0086] 一方、MLBテーブルAに送信元IPアドレス及び送信元MACアドレス対が存在する場合、ステップS423で決定したQoSで、ステップS421でプライベートIPアドレスを割り当てた場合にはeMLBR12のグローバルIPアドレスに変換(NAT)してから、eMLBR12とiMLBR11間ですでに確立しているセキュアチャネルを介して、すなわちeMLBR12とiMLBR11間の共有鍵を用いてユーザパケットを暗号化しMACフレームにカプセル化してから次ホップノードであるiMLBR11に転送し、iMLBR11(ISPエッジルータ)が暗号化ユーザMACフレームを受け取る。 [0087] また、本実施形態におけるeMLBR12が備える制御部15と転送部14は連携して、ノード及びeMLBR12間で暗号鍵の更新による実在確認を適宜行い(ステップS432)、ステップS433で確認結果に応じてMLBテーブルAを更新、すなわちMLBテーブルAの有効期間を延長してもよい。 [0088] iMLBR11(ISPエッジルータ)は、ステップS427で転送されたMACフレームをデカプセル化/復号/メッセージ認証してから、eMLBR12とiMLBR11間のセキュアチャネル識別情報をキーに転送部14のMLBテーブルBを検索し、(ステップS428)、送信元IPアドレス及び送信元MACアドレスの対が存在しない場合、パケットを廃棄する(ステップS429)。一方、MLBテーブルBに送信元IPアドレス及び送信元MACアドレス対が存在する場合、指定されたQoSで宛先IPアドレスに向けて次ホップノードにユーザMACフレームを転送する(ステップS430及びステップS431)。 [0089] なお、本実施形態ではノード又はエンティティの認証にIEEE802.1X規格に基づき、認証サーバーとしてRADIUSサーバーを用いているが、LDAPなど他の認証サーバー/規格を用いて認証を行ってもよい。 [0090] さらに、ノード又はエンティティの認証もしくは実在確認の際に、OSのバージョンアップ状態や、ファイアウォールの設定状態、ウィルス検知ソフトウェアのパターンファイル、広く利用されサイバー攻撃の対象にされ易いパッケージ型のアプリケーションプログラムやJava仮想マシンなどのミドルウェアの更新状態などを調べ、認証レベルすなわち通信サービス品質の決定に反映させてもよい。この結果を利用者に伝えることによって、利用者に対して端末をよりセキュアな状態に保つよう促すことも可能になる。 [0091] (実施形態3) 本実施形態では、IEEE802.1Xに対応したeMLBR-R12(一般住宅向け)とiMLBR11間の相互認証及び上りパケットの転送シーケンスの動作例を説明する。本実施形態に係るネットワーク構成を図に示す。図13に示すネットワーク構成は、iMLBR11とHRS23とを含んだインターネット10、ホスト30及びeMLBR-R12で構成している。 [0092] ノードから外部ネットワーク(インターネット10)に向けて送信されるMACフレーム/パケットに係わるものについて説明する。なお、本実施形態におけるオーセンティケータによるEAPメッセージとRADIUSメッセージの変換・中継処理などを含むEAP/RADIUSプロトコルのやり取り、MACsecによる鍵の生成/交換/MACフレームの暗号化/復号などは、簡略化もしくは省略している。また、各ステップに係わる転送部14及び制御部15の機能部の記述も省略している。 [0093] 以下に、図14のシーケンス図の動作を説明する。ネットワークに接続したIEEE802.1X対応のeMLBR-R12のサプリカントは、まずEAPOLにより、EAPメッセージフレームをiMLBR11のオーセンティケータに送る(ステップS511)。EAPOLを受け取ったiMLBR11は、EAP要求(TLS)をeMLBR-R12に送出し(ステップS512)、eMLBR-R12及びiMLBR11間でEAPメッセージ交換を行い(ステップS513)、iMLBR11はこれをホーム認証サーバーとして機能するRADIUSサーバー23へ仲介する(ステップS514)。認証結果をRADIUSサーバーがiMLBR11へ送信する(ステップS515)。iMLBR11のオーセンティケータは、認証結果を判別(ステップS516)し、認証に失敗した場合はeMLBR-R12にEAP失敗を告げ処理を終了する(ステップS517)。 [0094] 認証に成功した場合、eMLBR-R12にEAP成功を伝える(ステップS518)とともに、eMLBR-R12とiMLBR11との間で、MKAプロトコルによる共有鍵の生成・交換を行い、セキュアチャネルを確立する(ステップS519)。以下、eMLBR-R12とiMLBR11との間の通信では、共有鍵暗号を用いた秘匿通信が行われるとともに、途中でデータが改ざんされていないかを検査するメッセージ認証が行われる。 [0095] 認証に成功したeMLBR-R12がDHCP要求をブロードキャスト送信する(ステップS520)と、iMLBR11は、通信サービス品質(QoS)レベルを決定し、さらに有効期間(例えば4時間)を設定するとともに、セキュアチャネルの識別情報をキーに、eMLBR-R12のMACアドレスと、eMLBR-R12に固定的あるいは動的に割り当てるIPアドレスとの対応関係を記憶しておく制御部15のMLBテーブルAに仮登録し(ステップS521)、さらに転送部のMLBテーブルAに正登録する(ステップS522)。その上で、eMLBR-R12に対して、ネットマスクやDGWのIPアドレスなど、ネットワークへの接続に必要な情報とともにIPアドレスを割り当てるDHCP応答を返す(ステップS523)。 [0096] 以後、IEEE802.1X対応ノード(パソコンなど)は、実施形態2で述べた方法で認証を受け、eMLBR-R12との間でセキュアチャネルを確立し、セキュアチャネル識別情報をキーにノードのIPアドレスとMACアドレス及びQoSの対を転送部14のMLBテーブルBに正登録されてから、eMLBR12に対し暗号化ユーザMACフレームを送信し(ステップS524)、eMLBR-R12ではセキュアチャネルの識別情報をキーに転送部14のMLBテーブルBを検索し、同フレーム/パケットの送信元IPアドレスと送信元MACアドレスの対が存在しない場合、eMLBR12は、ノードが送信したパケットを破棄する(ステップS526)。一方、MLBテーブルBに存在する場合、予め設定されたQoSで、また送信元プライベートIPアドレスをグローバルIPアドレスに変換し、eMLBR12とiMLBR11間のセキュアチャネルを介して、すなわちeMLBR12とiMLBR11間の共有鍵を用いてユーザパケットを暗号化しMACフレームにカプセル化してから次ホップノードであるiMLBR11に、指定されたQoSで転送する(ステップS527)。 [0097] iMLBR11は、ステップS527で転送されてきたフレーム/パケットについて、eMLBR12とiMLBR11間のセキュアチャネルの識別情報をキーに転送部14のMLBテーブルAを検索し(ステップS528)、MLBテーブルAに送信元IPアドレス及び送信元MACアドレスが存在しない場合、同フレーム/パケットを廃棄する(ステップS529)。一方、MLBテーブルAに存在する場合、指定されたQoSで次ホップノードに、ユーザMACフレームを転送する(ステップS530)。また、本実施形態におけるiMLBR11が備える制御部15及び転送部14は連携して、iMLBR11及びeMLBR12間で暗号鍵の更新による、実在確認を適宜行い(ステップS532)、ステップS533で確認結果に応じてMLBテーブルAを更新、すなわちMLBテーブルAの有効期間を延長してもよい。 [0098] (実施形態4) 上記実施形態では、eMLBR12はIEEE802.1Xに則ってiMLBR11を介してRADIUSサーバーで認証を受けることとしているが、図15に示す本実施形態では、eMLBR12とiMLBR11各々が予め信頼できる認証局(CA局)から認証を受け、その真正性を証明するデジタル証明書を取得していれば、これを直接交換し合い相互に認証してもよい。 [0099] 以上に述べた実施形態に基づいたアドレス詐称対策を適用することによって、たとえIPsecを用いたトランスポートモードあるいはトンネルモードによる暗号化通信が行われても、すべてのフレーム/パケットについてeMLBR12及びiMLBR11でポート又はチャネルをキーに送信元IPアドレスと送信元MACアドレスの対がMLBテーブルに存在するかチェックするため、インターネット10へのアドレス詐称パケットの流出/流入を阻止できる。そして、これを適用したネットワーク(プロバイダー)が広がっていくにつれてDDoSやDRDoSなど、様々なアドレス詐称を前提としたサイバー攻撃やサーバーなどへの不正侵入などが激減するものと思われる。 [0100] また、たとえ一部の「何でも繋がせる」プロバイダーもしくはネットワークや匿名ネットワークなどがあっても、これらのネットワークとの接続点に配備するiMLBR11ではMLBテーブルに記述されたネットワークアドレス空間から外れたパケットを遮断(前述のuRPFとして機能する)することができ、さらに廃棄要請と組み合わせることによって被害者IPアドレスなどと対で攻撃者のIPアドレスあるいはアドレス空間内でランダムにアドレス詐称しているパケットを遮断することができる。さらに、iMLBR11の収容ポートの通信サービス品質(帯域を狭め、検疫(アノマリ検出によるSYN flood攻撃パケットなどの廃棄や、ウィルス検知ソフトによるウィルス混入パケットの廃棄、暗号化パケットの廃棄、スパムメールの廃棄など)を強化するなど)を限定することによって、インターネット10全体の安心・安全性が格段に高まるものと考えられる。 [0101] しかし、クラッカーから見ればeMLBR12やiMLBR11が新たな攻撃対象となる。このためには、これらのパケット転送装置へ不正侵入されないよう頑健な作りにする必要がある。また、たとえ侵入されプログラムやルーティングテーブル、MLBテーブルなどが改ざんされてもそれを検出できるように完全性検査機能、またEAP flood攻撃やARP flood攻撃など、制御部15のソフトウェア処理系に対する攻撃が行われても、それらを転送部14で遮断するような自己防御機能を備えておく必要がある。さらに、eMLBR12やiMLBR11に新たなセキュリティホールが見つかった場合や、新たなサイバー攻撃の出現に対応した機能を制御部15や転送部14に追加できるようバージョンアップ機能を備えておく必要がある。 [0102] 本実施形態に係るパケット転送装置はIPv4に限定されるものではなく、IPv6も扱ってもよい。また、グローバルIPアドレス既得ユーザに対しては、届け出のあったアドレス空間を制御部15のMLBテーブルに仮登録しておき、IEEE802.1X認証を経てIPアドレス単位に、転送部14のMLBテーブルに正登録してもよい。 [0103] さらに、iMLBR11又はeMLBR12が、サーバー13を収容する場合には、サーバー13を収容するポートもしくはチャネルの識別情報をキーに、(別設置のDHCPもしくは自装置内のDHCPから、あるいはユーザが保有するアドレス空間から)サーバー13に割り当てられたIPアドレスとサーバー13のMACアドレスに加え、サーバー13上で起動するプロセスを識別する固定のプロセス識別アドレス(well-knownポート番号)もバインディングの対象にしてもよい。これによって、たとえ悪意ある攻撃者によって不正侵入用のポートが作られても、同ポートからの情報流失などを防ぐことが可能になる。 [0104] また、ARPリフレクションを適用する場合は、前述したように認証レベルが低いことから、例えば、当該端末を他のエンドノードから隔離したVLANを構成し、帯域制限を施したブリッジを介して外部ネットワークに接続する、またITV(Industrial TeleVision)などの監視カメラであれば、接続先は限定されるため、宛先IPアドレスをMLBテーブルに追加するなどの対策を施すことによって、インターネット10に不正パケットが流出することを阻止できる。 [0105] さらに、iMLBR11又はeMLBR12が備える制御部15は、ノードもしくはエンティティが収容されているポートもしくはチャネルでの実在確認を適宜(必ずしも定期的である必要はない)行い、通信サービス品質を維持更新(IEEE802.1XにおけるMACsecの使用、物理的接続の確認、共有鍵の更新、一定時間実在確認応答がなければMLBテーブルからエントリーを削除し通信サービスを停止する、ノードが別のポートもしくはチャネルに移動したときは元のポートもしくはチャネルでの不在を確認してから、新たに認証し直しMLBテーブルのポートもしくはチャネルのみ変更するなど)してもよい。 [0106] なお、一つのポート又はチャネルが収容するノードもしくはエンティティは複数であってもよい。この場合には、該ポート又はチャネルの識別情報をキーとするMLBテーブルには、複数の送信元IPアドレスと送信元MACアドレスの対が登録されることになる。 [0107] また、eMLBR12は、ユーザ側ネットワークにおいてインターネット10に向けて一台もしくは複数台が多段的に配備されてもよい。さらに、eMLBR12は、インターネット10の端部に配備されている複数台のiMLBR11に対して、接続(マルチホーミング)されてもよい。 [0108] (実施形態5) 上記の実施形態の導入によって、アドレス詐称パケットのインターネット10への流入、ひいてはサイバー攻撃が激減するものと考えられるが、アドレス詐称を伴わない攻撃(例えば、送信元IPアドレスをランダムに変えながらSYN food攻撃する場合には、一定の確率で真の送信元IPアドレスで攻撃パケットがインターネット10へ流出/流入する。また、ウィルスに感染したパソコンや遠隔操作されたデジタルテレビなどから、利用者が知らない間にアドレス詐称せずに攻撃に加担させられる。)は、防ぐことができない。さらに、DDoS攻撃などの首謀者が所謂C&C(Command and Control)サーバーを介してボットに指令を発信する際に、匿名ネットワーク(例えば、Tor:The Onion Routerなど)を経由して送信元IPアドレスを隠ぺい化(以下、匿名IPアドレスと呼ぶ)する行為が広く行われているが、匿名IPアドレスパケットはアドレス詐称パケットではないため、アドレス非詐称パケットと同様に、インターネット10への流出/流入を防ぐことができない。ただし、Torネットワークであれば、数千台あるとされているTorノードのアドレス(匿名IPアドレス)は、インターネット上で公開されており、ブラックリスト化が可能である。 [0109] 本実施形態は、上記問題に対する対策で、他のノードからの要請によってiMLBR11やeMLBR12が廃棄テーブルを生成・更新し、それに合致したパケットを廃棄する動作例について説明する。 [0110] 具体的には、図16に示すように、不正アクセス監視システム/侵入検知システムIDS(Intrusion Detection System)や侵入防止システムIPS(Intrusion Prevention System)、匿名ネットワークもしくは匿名IPアドレス検出システムなどを稼働させた対処要請ノードもしくは対処要請エンティティとして機能するReN40(Request Node)は、インターネット10の要所やサービスを提供しているデータセンターや組織内ネットワーク、DMZ(DeMilitarized Zone)、サーバー内でトラフィックを監視し、明確な攻撃や攻撃によると推定される輻輳、匿名IPアドレスを検知するとDeN42(Deliver Node)へ攻撃パケットと推測されるパケットを送り対処を要請するノードである。また、DeN42は、ReN40から送られた攻撃パケットを収集・分析・集約し、攻撃と判定したときに廃棄要請情報を発信する機関のノードである。ShN43(Share Node)は、DeN42が発信した廃棄要請情報を、廃棄対象パケットを中継転送しているiMLBR11又はeMLBR12へ、大規模な攻撃であればインターネット10全体に配送するノードである。なお、図16には、DeN42やShN43などが、インターネットの内部に配置されるように記されているが、前述のHRS23と同様に、不正侵入などによって廃棄要請情報やプログラムなどが改ざんされないよう、ISPなど信頼できる機関がこれらを厳重管理することを意味するものであって、iMLBR11やeMLBR12を介して、インターネットの外側に配置されてもよい。 [0111] DeN42が発信する廃棄要請情報には、廃棄対象(攻撃や匿名IPアドレス、情報漏洩など)パケットの送信元MACアドレス/送信元IPアドレス/ポート番号と送信先MACアドレス/送信先IPアドレス/ポート番号の一部又はすべての対と有効期間が、DeN42のデジタル証明書もしくは電子署名とともに記述されている。これを受取ったShN43は、廃棄要請情報に記述されている攻撃元IPアドレス及び被害者ノードのIPアドレスそれぞれまでの経路情報を調べるtracerouteコマンドなどを応用して廃棄要請先のiMLBR11やeMLBR12のIPアドレスを割り出(アドレス解決)し、該当するiMLBR11又はeMLBR12へ廃棄要請情報を配送する。具体的には、TTLを1ずつ増やしながらICMPエコー要求パケットを送信することによって経路情報を取得するが、TTLが1のICMPエコー要求パケットをMLBRが受信すると、ICMP時間超過パケットのオプションフィールドにMLBRの属性情報(例えば、エッジルータとして配備するiMLBR、MLBR未導入のプロバイダーとの境界に配備するiMLBR、家庭用のeMLBR-R、無線LAN用のeMLBR-W、データセンター用のeMLBR-Cなどの種別や、収容するノードやネットワークの属性など)を書き込んで経路情報の調査元(ShN43)に返すことによって、転送経路上に存在するiMLBR11やeMLBR12のIPアドレスとその属性情報を取得してもよい。その後、HTTPやSMTPなどの転送プロトコルを用いて当該iMLBR11やeMLBR12へ廃棄要請情報を送信してもよい。被害者ノードを収容するiMLBR11やeMLBR12についても、同様にすればよい。ICMPパケットとHTTPやSMTPなどの転送プロトコルを用いることによって、転送経路上にファイアウォールがあっても遮断されることなくファイアウォールを通過できる。 [0112] 廃棄要請情報を受取ったiMLBR11又はeMLBR12の制御部15では、添付されているデジタル証明書から廃棄要請情報の真正性を確認してから、廃棄要請情報に基づいて廃棄テーブルを生成・更新し、転送部14に伝達する。転送部14では、以後、受信したフレーム/パケットについてMLBテーブルと照会してアドレス詐称パケットでないことを確認した後、廃棄テーブルに該当する送信元IPアドレス/ポート番号と送信先IPアドレス/ポート番号などの対もしくはブラックリストとして登録されている匿名IPアドレスに該当しないかを調べ、該当する場合は廃棄する(廃棄テーブルと照合してからMLBテーブルに照会してもよい)。該当しない場合は、ルーティング処理に進む。 [0113] 本実施形態において、ReN41はIDS又はIPS相当の機能あるいはウィルス検知ソフトを実装したパソコン、タブレット端末、スマートフォン、デジタルテレビなどであってもよい。また、ReN40がDeN42及びShN43相当の攻撃パケットの分析機能や配送機能などを有し、攻撃者のIPアドレスを特定できる場合には、直接、前述のtracerouteコマンドを応用したICMPエコー要求パケットを用いることによって、ReN41から攻撃者までの転送経路上に存在するiMLBR11やeMLBR12のIPアドレスとその属性情報、さらにICMP時間超過パケットが返ってくる順序から、iMLBR11やeMLBR12の位置関係(被害者ノードを収容するMLBRか攻撃者ノードを収容するMLBRかの判別)を把握することができる。その後、HTTPやSMTPなどの転送プロトコルを用いて、当該iMLBR11又はeMLBR12へ廃棄要請情報を配送してもよい。さらに、攻撃元が限られた範囲である場合は、DeN42はShN43の機能を代行し直接該当するiMLBR11又はeMLBR12へ上述の方法で廃棄要請情報を配送してもよい。また、iMLBR11及びeMLBR12はReN40の機能を実装し、ReN40として機能してもよい。 加えて、上記実施形態では、iMLBR11及びeMLBR12はDeN23やShN43などからの廃棄要請によって廃棄テーブルを更新するとしているが、DeN23やShN43からの通知によってiMLBR11及びeMLBR12がDeN23やShN43などに廃棄要請情報を取りにいく、あるいは定期的にiMLBR11及びeMLBR12がDeN23やShN43などをアクセスし、自己に関係する新たな廃棄要請情報があればそれを取得してもよい。 [0114] 本実施形態によって、アドレス詐称を伴わない攻撃や、前述の匿名ネットワークの端部ノード(Torノード)のIPアドレスを、同ノードを収容するiMLBR11又はeMLBR12の廃棄テーブルに(ブラックリストとして)登録しておくことによって、「何でも繋がせる」ネットワークと匿名ネットワークを経由してきた攻撃パケットを廃棄することが可能になり、インターネット10への流入/流出を阻止することができる。さらに、被害者ノードのIPアドレスとL4ポート番号、送信先IPアドレスなどの対を、被害者ノードを収容するiMLBR11やeMLBR12の廃棄テーブルに登録しておくことによって、以後、情報漏洩パケットの流出やC&Cサーバーへのアクセスなどを阻止することができる。 [0115] (実施形態6) 本実施形態では、マルチレイヤ・バインディング・ルータ(MLBR)によるサイバー攻撃の対策について以下に述べる。まず、本実施形態では、クラッキング意図パケットを対策の対象とする。クラッキング意図パケットは、IPアドレス詐称(成りすましを含む)パケット、匿名IPアドレスパケット及びIPアドレス非詐称攻撃パケットを示す。 [0116] 本実施形態に係るMLBRの機能を以下(1)~(6)に示す。 (1)ノードもしくはエンティティからの接続要求があった時、その真正性と健全性を認証・検疫するとともに、認証・検疫レベルに応じて提供するQoSを決定する。 (2)物理ポートor(セキュア)チャネルをキーに、ノードもしくはエンティティのIPアドレスとMACアドレスとの対応関係をMLBテーブルに登録する。 (3)パケットを受信した物理ポート又はチャネルをキーにMLBテーブルを検索し、パケットの送信元IPアドレスとMACアドレスの対が存在するときは、次ホップノードへ指定されたQoSで転送し、存在しないときはアドレス詐称or成りすましパケットとみなして破棄する。 (4)物理ポートまたはチャネルを介して適宜ノードもしくはエンティティの実在及び健全性確認を行い、MLBテーブルを更新(有効期間を延長)する。 (5)他のノードからの正当な廃棄要請を受けて破棄テーブルを更新し、以後、廃棄テーブルに該当する匿名のアドレスパケットやアドレス非詐称攻撃パケットを廃棄する。 (6)利用者(egress)に配置するeMLBR12と、インターネット側(ingress)に配備するiMLBR11により、クラッキング意図パケットのインターネットへの流出及び流出を阻止する。 [0117] 本実施形態に係るMLBRにおけるサイバー攻撃の対策の対象となるノードをについて以下に具体的なノードを列挙する。 ・ホストとルータの総称をノードとしてもよい。この場合、ノードの集合であるネットワークもノードとなる。 ・IEEE802.1X対応端末(PCやスマートフォン等)この場合、認証・検疫におけるクラッキング行為の抑止と端末の健全性確保に有効である。しかし、匿名ネットワーク経由で悪事を行っても特定され難く、ボットに感染すればDDoS攻撃に加担し。また、遠隔操作や成りすましされ(見かけ上)アドレス詐称せずに悪事加担も考えられる。 ・IEEE802.1X非対応端末(テレビ等のスマート家電やIoT)。この場合OSのアップデートやFWはなく、サイバー攻撃の温床になることも考えられる。 ・家庭用ルータ。遠隔操作され、攻撃に加担も考えられる。 ・何でもつながせるポリシーのISP。この場合、すべてのISPが対策を導入することは考えにくい。 ・匿名ネットワーク及びTor等。この場合、匿名アドレスであって、アドレス詐称ではない。 ・成りすまし端末。 [0118] ここで、上述したIEEE802.1X対応端末とeMLBR12間のシーケンス動作の例を図21に示す。本実施形態に係る図21のシーケンスでは、実施形態2における図12のシーケンスとは、サーバーを2つ備える点で相違する。具体的には、サーバーは、検疫サーバー31及びRADIUSサーバー23を別々に備えてもよい。また、ステップS514では、eMLBR12はこれをホーム認証サーバーとして機能するRADIUSサーバー23又は検疫サーバー31へ仲介する際、健全性ステートメント交換も行う点で実施形態2における図12のシーケンスと相違する。また、上述の構成の違いにより、図14に対し図21では、ステップS515において、認証結果及び検疫結果をそれぞれのサーバーがeMLBR12へ送信することができる。 [0119] 以下に、具体的なケースを用いながら本実施形態に係るサイバー攻撃に対応策を説明する。第1のケースでは、標的型メール攻撃に対する対応策について以下に示す。標的型メール攻撃では、偽装メールを不用意に開封した社員の端末がコネクトバックで踏み台にされ、以後、C&Cサーバーを介して攻撃者が指令を送り複数の端末を巻き込みながら基幹サーバーにバックドアを作り、機密情報を盗み出す攻撃である。 [0120] 第1のケースに係る標的型メール攻撃に対し、本実施形態では4つの対応例を述べる。1つ目は、攻撃者の多くがC&Cサーバーに指令を送るときに匿名アドレスを用いるが、本対策では匿名ネットワークの使用を不能にする。2つ目は、基幹サーバーは、自己のポート番号を含めてMLBテーブルに登録しておくことによって、バックドアからの情報漏洩を防ぐ。 [0121] 3つ目は、IDSなどで組織ネットワーク内での攻撃若しくは攻撃の兆候を検出次第C&CサーバーのIPアドレスと自組織のIPアドレスを記述した廃棄要請を自組織のeMLBR12及びC&Cサーバーを収容しているeMLBR12とiMLBR11に送り、以後、C&Cサーバーとの間の指令パケットのやり取りを阻止する。4つ目は、漏洩情報の送信先IPアドレスを記述した廃棄要請を自組織のeMLBR12とiMLBR11に送り、以後の情報漏洩を阻止する。 [0122] 次に、第2のケースでは、ワイヤレスセンサーネットワーク攻撃に対する対応策について以下に示す。ワイヤレスセンサーネットワーク攻撃では、アドホック型のセンサーネットワークを形成しているIOTが次々にマルウェアに感染もしくはIoTの製造工程でマルウェアが埋め込まれ、攻撃者がC&Cサーバーを介してIOTに様々な指令を送り、データの改ざん、情報の盗み出し、機器や社会インフラの暴走などを行わせ、システムを制御不能状態にする攻撃である。 [0123] 第2のケースに係るワイヤレスセンサーネットワーク攻撃に対し、本実施形態では3つの対応例を述べる。1つ目は、匿名アドレスの使用を不能する。2つ目は、センサーネットワークを収容しているeMLBR12のQoSとして、インターネット接続先IPアドレスを限定しておけばIoTがC&Cサーバーなどへアクセスすることを阻止できる。3つ目は、QoSとして帯域制限しておけば、IoTの帯域攻撃等への使用を不能にする。 [0124] 次に、第3のケースでは、DNSキャッシュポイズニングに対する対応策について以下に示す。DNSキャッシュポイズニングでは、IPS、企業、大学などのキャッシュDNSサーバーに対して偽のDNS情報をキャッシュさせる攻撃である。偽のDNS情報をキャッシュさせることにより、そのキャッシュDNSサーバーを参照するISPの顧客、企業の社内ユーザ、大学の学生などクライアントを偽のサイトに誘導させるなどの行為が可能となる攻撃である。 [0125] 第3のケースに係るDNSキャッシュポイズニングに対する対応例を以下に述べる。ACL(Access Control List)が適切に施されていないISPや企業、大学などでは、本来クライアントではない外部からの問い合わせに対して応答を返してしまっている。こういったキャッシュDNSサーバーをオープンリゾルバと呼ぶ。オープンリゾルバは外部から任意の問い合わせができるため、毒を入れやすい状況にあるといえる。また、本来のクライアントであっても、ウイルスに感染してポット化されているようなケースでは任意の問い合わせが可能である。 [0126] 従って、適切な対応設定が施されていないキャッシュDNSサーバーは、これを利用するクライアントに1台でも悪意あるクライアント若しくは遠隔操作されたクライアントがいた場合にキャッシュポイズニング攻撃を受けて、成功するとそのキャッシュDNSサーバーを利用するすべてのクライアントに影響を与える可能性がある。 [0127] キャッシュポイズニングの具体的な手法としては、以下のようなものが挙げられる。例えば、カミンスキーメソッド、委任インジェクション攻撃、移転インジェクション攻撃である。現在行われている対策としては、キャッシュDNSサーバーに適切なACLを設定し、オープンリゾルバでなくすこと、外部へ問い合わせを行う際の送信元ポート番号を固定(又はインクリメンタル)せず、ランダマイズ化する実装若しくは設定を導入すること。 [0128] また、近年では、キャッシュDNSサーバー自身はランダマイズしていても、インターネットへ出ていく途中経路にNAT装置やFirewallが存在した場合、その装置がポート番号を固定若しくはインクリメンタルマッピングしてしまうケースも見られるため、そういった中継に介在する装置のケアも必要である。昨今のISPではIPアドレスの枯渇に対応するため、LSN(Large Scale NAT)を採用しているケースもあり、それらの実装の中にもポートのマッピングがきちんとランダマイズ化されない実装があるという。このように、現在行われている対策は、キャッシュDNSサーバーだけにとどまらず、ISPや企業、大学内のネットワーク全体にわたって、高度な専門知識を持ったネットワーク管理者が注意深く設定し管理運用しなければならないのが実情である。 [0129] これに対して、MLBRによる対策では、DNSキャッシュポイズニング、攻撃者が権威DNSサーバーのIPアドレスに詐称して直接キャッシャDNSサーバーに毒を入れるか、遠隔操作で善良な利用者のPCなどから権威DNSサーバーのIPアドレスに詐称して毒を入れることが考えられるが、その際に攻撃者はTorネットワークなどを使って送信元IPアドレスを匿名化する。MLBRでは、匿名アドレスパケットはインターネットへの流入/流出を阻止する。またIPアドレス詐称パケットはMLBR内で破棄するので、高度な設定など必要とせずにDNSキャッシュポイズニングを防ぐことができる。 [0130] 次に、第4のケースでは、DNSリフレクション攻撃(DNS Amp)に対する対応策について以下に示す。DNSリフレクション攻撃では、一般にはDNSは問い合わせよりも応答のほうがデータサイズが大きい。これを悪用し送信元アドレスをターゲットのアドレスに偽装して大量の問い合わせを行うことでターゲットのアドレスに向かって大量の応答が返る攻撃である。 [0131] 第4のケースに係るDNSリフレクション攻撃に対する対応例を以下に述べる。 どんな相手からの問い合わせでも応答するということから先ほどのオープンリゾルバが踏み台とされるケースは多い。また、家庭用ブロードバンドルータを代表とするCPE(Customer Premises Equipment)が踏み台とされるケースも多々ある。 [0132] これはオープンリゾルバ若しくはオープンフォワーダー(どこからの問い合わせでもその機器でフォワード設定しているDNSサーバーへ問い合わせフォワードする)となっているCPE実装が多く出回っており、攻撃者が悪用すると折り返しトラフィックなども含めてより大きなトラフィックを発生させることができる。 [0133] 対策として国内ISPやCATV業者が現在取り組みを始めつつあるものとして、IP53B(Inbound Port 53 Blocking)がある。これはISPから顧客のポート53へのトラフィックを遮断するというものである。これにより、オープンリゾルバやオープンフォワーダーへのトラフィックを抑止することができるが、これを実施した場合の弊害(顧客がDNSサーバーを立てていた場合にサービス妨害となる)を考慮して慎重な導入が進められている。これに対して、MLBRによる対策としては、DNSリフレクション攻撃(DNS Amp)では、アドレス詐称パケットがベースとなるので、これも高度な専門知識など必要とせずにMLBRで妨ぐことができる。 [0134] 第1の関連技術では(例えば、特許文献2参照。)、コンピュータシステム、コントローラ、及びネットワーク監視方法における、データセンターでのアドレス詐称対策が用いられている。具体的には、詐称アドレスを利用した不正アクセスや妨害に対するセキュリティ強度を向上させる。第1の関連技術によるコンピュータシステムは、コントローラと、コントローラによって設定されたフローエントリに適合する受信パケットに対し、当該フローエントリで規定された中継動作を行うスイッチと、スイッチに接続されたコントローラを具備する。 [0135] スイッチは、自身に設定されたフローエントリに適合しない受信パケットの送信元アドレス情報を、コントローラに通知(Packet-In)する。コントローラは、正当なホスト端末のアドレス情報と送信元アドレス情報とが一致しない場合、受信パケットの送信元アドレスが詐称されていると判定し、廃棄フローエントリをスイッチに設定する。したがって、本実施形態に係る発明と比べ、第1の関連技術では、新たなアドレス詐称パケットを受信するごとに処理負荷が重いPacket-Inが発生する。すなわち、この発明では大量のアドレス詐称パケット攻撃によって、スイッチは過負荷状態に陥り動作不能に陥る。 [0136] 第2の関連技術では、IPアドレスとMACアドレスを対応付けてテーブルに格納し、端末から送られたパケットのIPアドレスとMACアドレスがテーブルにない時は破棄する。具体的には、端末は、通信に先立って初段ルータのアドレス解決のため、ARP要求パケットを必ずブロードキャスト送信する。このARP要求パケットには、送信元のMACアドレスとIPアドレスとが記述されている。このため、悪人がたとえ異なる物理ポートからであってもARP要求パケットをWiresharkなどでキャプチャし、IPアドレスとMACアドレス対を盗み見、他人のPCに成りすますことができる。 [0137] 一方本実施形態に係る発明では、物理ポート又は(セキュア)チャネルをキーにIPアドレスとMACアドレス対をMLBテーブルで管理するため、他ポート又はチャネルからARP要求パケットを盗み見て成りすまししても、成りすまし端末からのパケットを破棄できる。なお、これまではNICの製造メーカで付与したMACアドレスを書き換えることは事実上不可能であったが、OpenFlowなどのSDN技術の出現によって、任意に書き換えられるようになった。したがって、本実施形態に係る発明と比べ、第2の関連技術では、物理ポートまたは(セキュア)チャネルをキーに管理する機能を有しない点でセキュリティ上の問題がある。 [0138] 第3の関連技術では(例えば、特許文献3及び特許文献4参照。)、MACアドレスとIPアドレスを合わせて記憶して、ユーザがISPから付与されたIPアドレスを端末に設定したり、故意に他の端末と同一のIPアドレスに改ざんするユーザに対して、予め付与されたIPアドレスを設定していない端末からのパケットは受信してもブリッジ内で破棄する。具体的には、MACアドレスとIPアドレスを対応付けて管理するテーブルを具備する。しかし、これは、IPアドレスが付与された端末に対してMACブリッジがARP要求パケットを送信し、返送されてきたARP応答パケットに記述されているMACアドレスを取得する際に生成される副産物であり、以後のフィルタリングで参照するのは送信元MACアドレスのみである。 [0139] したがって、例えば端末がマルウェアに感染しIPアドレス詐称パケットを送信しても阻止できず、第3の関連技術では、MACブリッジ(レイヤ2のパケット転送装置)であり、基本的にMACアドレスしか参照しないことによる問題が発生する。一方、本実施形態に係る発明では、物理ポート又は(セキュア)チャネルをキーにMACアドレスとIPアドレスの対がMLBテーブルに存在するか否かをチェックするもので、フィルタリングで参照する対象が異なる。これによって、たとえ端末の所有者がIPアドレスやMACアドレスの詐称を行っていなくても、マルウェアに感染しDDoS攻撃などに加担させられてIPアドレス詐称パケットを送信しても、インターネットへの流出と流入を阻止できる。 [0140] ここで、本実施形態に係るパケット転送システムにおけるARPリフレクションのIPv6版の適応を具体的に述べる。IPv6では、IPv4用のARP(Address Resolution Protocol)の代わりにNDP(Neighbor Discovery Protocol)を用いる。NDPには、リンク上に存在する近隣ノードのMACアドレスの判別やアドレスの変更・停止検出、近隣ノードへの到達性のチェック、リンク上にいるルータの検出及びパケットの転送先としての設定などの機能があり、各々で用いるパケットの呼称が異なる。また、NDPには、ブロード送信がないため、代わりにマルチキャスト送信を用いる。また、図22は、本実施形態に係るパケット転送システムにおけるIPv4版のARPリフレクションをIPv6の適応した場合の対比を示している。 [0141] IPv6版の適応で用いられる機能の用語を以下に挙げる。 ・RSパケット(ルータ要請パケット(RS:Router Solicitation)):ノードが初段ルータのアドレス解決に用いるパケット ・RAパケット(ルータ応答パケット(RA:Router Advertisement)):RSパケットに対してルータが返すパケット ・NSパケット(近隣要請パケット(NS:Neighbor Solicitation)):特定のノードのMACアドレスを解決するパケット。IPv4のARPパケットとほぼ同じ。 ・NAパケット(近隣通知パケット(NA:Neighbor Advertisement))NSパケットに対する応答パケット [0142] なお、前述したように本発明によるMLBRをインターネット全体並びにすべての利用者サイドに配備することは、事実上不可能である。このための対策として、eMLBR12を介して所定の認証や検疫を受けて接続を許可されたノードまたはエンティティが送信したパケットでeMLBR12で廃棄されなかったものについて、例えば転送部14または制御部15において、IPv4であれば例えばIPヘッダのサービスタイプフィールドの未定義ビット(最後方の2ビット)に、IPv6であればトラフィッククラスフィールドの所定ビット(最後方の2ビット)に認証フラグとして“1”を書き込むことによってその真正性を表示するようにしてもよい。さらに、未認証のノードまたは未認証のエンティティが送信したパケット、すなわちeMLBR12を通っていないパケットについては、これらのパケットを中継転送してきたネットワークとの境界に設置されるiMLBR11にて、前記所定ビットの認証フラグをリセット(“0”)するようにしてもよい。これによって、MLBR未導入のプロバイダのネットワークから送られてきたパケットや、eMLBR12をバイパスしてインターネットに流入させようとしたパケットは、これを受信したiMLBR11や、パケットの送信先ノードを収容するiMLBR11やeMLBR12でパケットが認証を受けたノードまたはエンティティから送信されたものか否かを確認することが可能になり、認証フラグが“0”のパケットについては検疫サイトに配送し、クラッキング意図パケットか否かを詳細に検査する、あるいはその扱い(廃棄するか詳細な検疫検査を行うなど)を受信者に委ねることが可能になる。なお、認証フラグが“1”のパケットは、認証を受けたノードまたはエンティティから送信されたことを示すものであって、同パケットがマルウェアに感染していない、すなわち安全性が保証されていることを意味するものではない。 産業上の利用可能性 [0143] 本発明は情報通信産業に適用することができる。 符号の説明 [0144] 10:インターネット 11:iMLBR 12:eMLBR 13:サーバー 14:転送部(Open Flow Switch) 15:制御部(Open Flow Controller) 20:Mobile Network 21:Untrusted Internet 22:HLR 23:HRS 24:スマートフォン 25:携帯電話 26:PC 27:タブレットPC 28:電話器 29:デジタルテレビ 30:ホスト 31:検疫サーバー 40:ReN(Request Node) 41:ホスト/ReN 42:DeN(Deliver Node) 43:ShN(Share Node) |
※
ライセンスご希望の方、またシーズの詳細に関することについては、下記「問合せ先」まで直接お問い合わせくださいますよう,お願い申し上げます。
『 PACKET TRANSFER DEVICE, PACKET TRANSFER SYSTEM, AND PACKET TRANSFER METHOD 』に関するお問合せ
- 学校法人 東京電機大学 研究推進社会連携センター(承認TLO)
- URL: https://www.dendai.ac.jp/
-
E-mail:
- Address: 〒120-8551 東京都足立区千住旭町5番
- TEL: 03-5284-5225
- FAX: 03-5284-5242