JP6896264B2 - 通信装置、通信方法、及びプログラム - Google Patents
通信装置、通信方法、及びプログラム Download PDFInfo
- Publication number
- JP6896264B2 JP6896264B2 JP2017002110A JP2017002110A JP6896264B2 JP 6896264 B2 JP6896264 B2 JP 6896264B2 JP 2017002110 A JP2017002110 A JP 2017002110A JP 2017002110 A JP2017002110 A JP 2017002110A JP 6896264 B2 JP6896264 B2 JP 6896264B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- flag
- reliability
- communication
- risk
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
本発明の実施形態は、通信装置、通信方法、及びプログラムに関する。
従来、複数のノードを含んで構成されるネットワークにおける通信を、そのネットワークの管理者が定める通信規則に従って通信する通信装置が知られている。関連するＯｐｅｎＦｌｏｗ（登録商標）という技術がある。ＯｐｅｎＦｌｏｗでは、コントローラが各ノードのスイッチを一元管理する（特許文献１、非特許文献１参照）。
ところで、ネットワークに接続される機器やシステムに対するサイバー攻撃が増加し、地球規模での大きな脅威になっている。このようなサイバー攻撃を目的とするパケットには、接続経路の隠ぺい化を意図的に図ったものが多く含まれることが知られている。
ところで、ネットワークに接続される機器やシステムに対するサイバー攻撃が増加し、地球規模での大きな脅威になっている。このようなサイバー攻撃を目的とするパケットには、接続経路の隠ぺい化を意図的に図ったものが多く含まれることが知られている。
"OpenFlow Switch Specification Version 1.3.1,"The Open Networking Foundation,(2013),［ｏｎｌｉｎｅ］、［平成２８（２０１６）年１月７日検索］、インターネット〈https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.1.pdf〉
しかしながら、接続経路が隠ぺい化されたパケットが、必ずしもサイバー攻撃を目的とするパケットとは限らない。ネットワークセキュリティを維持するために、接続経路が隠ぺい化されたパケットの全てを遮断することにより、それらを受信しないようにしてしまうと、例えば人権擁護関係のメール等、サイバー攻撃を目的とするものではないパケットまでも遮断してしまうことになる。
本発明が解決しようとする課題は、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信者側へ通知する通信装置、通信方法、及びプログラムを提供することである。
上記目的を達成するため、本発明の一態様に係る通信装置は、パケットにより、ネットワークを介して通信する通信装置であって、前記通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部が、前記パケットのパケットヘッダの所定位置に設けられており、前記ネットワークから受信したパケットに付与されているアドレス情報がブラックリストに非該当であり、かつ匿名ＩＰアドレスに該当している場合に、前記パケットの匿名性を示す所定値を前記信頼度情報の一部に設定し、前記信頼度情報に基づいて、当該パケットの信頼度が比較的高い又は当該パケットが匿名性を有することと、当該パケットのリスクが比較的高いことと、の内から１又は複数を選択し、前記１又は複数を選択した結果に基づいて当該パケットの前記信頼度情報を設定し、又は、前記１又は複数を選択した結果に基づいて前記信頼度が不明なパケットを選択して、前記選択されたパケットの前記信頼度情報を維持する信頼度情報設定手段を備える通信装置である。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、当該パケットに関する情報に基づいて、前記ネットワークにおける所定の信頼度基準を満たす送信元から送信されたパケットの前記信頼度情報を、当該パケットの信頼度が比較的高いことを示すように設定する。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、当該パケットに関する情報に基づいて、送信元又は宛先が隠ぺいされたパケットの前記信頼度情報の一部に、前記所定値を設定する。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、当該パケットに関する情報に基づいて、前記ネットワークにおける所定の信頼度基準から外れた送信元から送信されたパケット又は前記信頼度が不明な送信元から送信されたパケットの信頼度情報の一部が前記所定値でないパケット又は信頼できないネットワークから転送されてきたパケットの信頼度情報の一部が前記所定値ではないパケットの前記信頼度情報を、当該パケットのリスクが比較的高いことを示すように設定する。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、前記信頼度が不明な送信元から送信されたパケットの信頼度情報の一部が前記所定値であるパケット又は信頼できないネットワークから到来したパケットの信頼度情報の一部が前記所定値であるパケットの前記信頼度情報を維持する。
また、本発明の一態様に係る通信装置は、パケットにより、ネットワークを介して通信する通信装置であって、前記通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部が、前記パケットのパケットヘッダの所定位置に設けられており、信頼度が不明であることを示す所定値が格納部に格納されたパケットに対し、当該パケットの信頼度が比較的高いこと、当該パケットが匿名性を有すること、当該パケットのリスクが比較的高いこと、の内から１又は複数を選択して、前記選択の結果に基づいて当該パケットの前記信頼度情報を設定し、又は、前記選択の結果に基づいて前記信頼度が不明なパケットを選択して、前記選択されたパケットの前記信頼度情報を維持する信頼度情報設定手段を備え、前記パケットのパケットヘッダの所定位置は、ＩＰｖ４パケットヘッダのサービス種別(Type of Service)フィールド内の予備ビットまたはＩＰｖ６パケットヘッダのトラフィッククラスフィールド内の予備ビットであり、前記信頼度情報設定手段は、前記パケットのパケットヘッダの所定位置に、パケットの信頼度情報とリスク情報の双方を含む属性を識別するためのフラグを前記信頼度情報として設定し、前記フラグが設定されてから前記パケットを前記ネットワークに送信する通信装置である。
また、本発明の一態様に係る通信装置において、前記信頼度情報には、信頼度が不明なパケット、信頼度が高いパケット、送信元又は宛先を隠ぺいしたパケット、及び明白な不正なパケットのうちの少なくとも何れかに対応付けられた情報が含まれる。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、前記信頼度が不明なパケットの前記信頼度情報を維持する。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、前記信頼度が高いパケットの前記信頼度情報を、当該パケットの前記信頼度が高いことを示す第１の所定の情報に変更する。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、前記送信元又は宛先を隠ぺい又は詐称したパケットの前記信頼度情報を、前記送信元又は宛先の匿名性を示す第２の所定の情報に変更する。
また、本発明の一態様に係る通信装置において、前記明白な不正なパケットは、前記信頼度情報が規定外の情報に設定されているパケット、所定の認証条件を満たしていないパケット、及び、前記パケットの信頼度が補償されない通信経路を経て到来したものであると判定されたパケットのうちの何れかであって、前記信頼度情報設定手段は、前記明白な不正なパケットの前記信頼度情報を、当該パケットが前記明白な不正なパケットであることを示す第３の所定の情報に変更する。
また、本発明の一態様に係る通信装置において、前記格納部には、前記通信によるネットワークセキュリティ上のリスクが比較的低いパケットであることを示す認証フラグと、前記リスクが比較的高いパケットであることを示すリスクフラグの少なくとも何れかのフラグが前記信頼度情報を示すものとして設けられ、前記信頼度情報設定手段は、前記認証フラグが設けられているパケットであって所定の信頼度基準を満たした送信元から送信されたパケットに対しては前記リスクが比較的低いことを示すように前記認証フラグを設定し、前記リスクフラグが設けられているパケットであって送信元又は宛先を隠ぺい又は詐称したパケット又は信頼度が不明なパケットに対しては前記リスクが比較的高いことを示すように前記リスクフラグを設定する。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、前記認証フラグとして、通信の接続要求元が認証されていること又は接続要求元が検疫されていることを示す第１フラグが設けられ、通信の接続要求に対する判定の結果により前記第１フラグの状態を設定する第１フラグ設定手段を含む。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、前記リスクフラグとして、接続経路を隠ぺいするように前記パケットの送信元ＩＰアドレス又は宛先ＩＰアドレスが設定されたパケットであることを示す第２フラグを当該パケットに設定する第２フラグ設定手段を含む。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、前記通信がメール又はメッセージを送るものである場合には、前記リスクフラグとして、前記通信の送信元メールアドレスと、宛先メールアドレスと、電話番号との何れかが隠ぺい化、匿名化、又は詐称されたものであることを示す第３フラグを当該パケットに設定する第３フラグ設定手段を含む。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、所定の判定基準に基づいた前記リスクの有無についての判定を含む所定の手続きにより、前記パケットの送信元ＩＰアドレスの詐称の有無を検査し、前記判定の結果により、前記リスクフラグとして、前記送信元ＩＰアドレスが詐称されたもの又は不正なものであることを示す第４フラグを当該パケットに設定する第４フラグ設定手段を含む。
また、本発明の一態様に係る通信装置は、受信したパケットのパケットヘッダに前記リスクが比較的低いことを示すように前記認証フラグが設定されたパケットを選択的に受信するパケット受信手段を備える。
また、本発明の一態様に係る通信装置は、受信したパケットのパケットヘッダに前記リスクが比較的低いことを示すように前記認証フラグが設定されていないパケットと、前記リスクが比較的高いことを示すように前記リスクフラグが設定されたパケットの一方又は両方を選択的に検査するパケット検査手段を備える。
また、本発明の一態様に係る通信装置は、受信したパケットのパケットヘッダに前記リスクが比較的高いことを示すように前記リスクフラグが設定されたパケットを廃棄するか、又は、特定のポートから出力するように制御する手段を備える。
また、本発明の一態様に係る通信装置において、前記リスクフラグは、前記パケットヘッダにおけるビット配列上の特定の位置に配置され、前記信頼度情報設定手段は、接続経路を隠ぺいするように前記パケットの送信元ＩＰアドレス又は宛先ＩＰアドレスが設定されたパケットである場合と、前記通信がメール又はメッセージを送るものであって、前記通信の送信元メールアドレス、宛先メールアドレス、又は、送信元アカウント名、宛先アカウント名、又は、電話番号、又は送信元ＵＲＬ（Uniform Resource Locator）、宛先ＵＲＬ、又は、送信元ＵＲＩ（Uniform Resource Identifier）、宛先ＵＲＩ、又は、宛先ＵＲＮ（Uniform Resource Name）、送信元ＵＲＮ、又は、送信元ドメイン名、宛先ドメイン名、又は、送信元ＦＱＤＮ（Fully Qualified Domain Name）、宛先ＦＱＤＮが隠ぺい化、匿名化、又は、詐称されたものである場合と、前記パケットの送信元ＩＰアドレスが詐称されたもの又は不正なものである場合と、のうちの何れかの場合に該当する場合にセットする。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段は、受信した第１パケットから、当該第１パケットの前記認証フラグと前記リスクフラグとを抽出し、当該受信した第１パケットをトンネリングさせる通信の第２パケットのパケットヘッダ、当該受信した第１パケットを分割して送信する第２パケットのパケットヘッダ、当該受信した第１パケットを暗号化して送信する第２パケットのパケットヘッダ、又は、当該受信した第１パケットの上位レイヤの情報を転送する際に生成されるパケットのパケットヘッダに設けられた認証フラグとリスクフラグにそれぞれ反映させる。
また、本発明の一態様に係る通信装置において、前記信頼度情報が、ＩＰｖ４（Internet Protocol version ４）パケットヘッダのサービス種別(Type of Service)フィールド内に割り当てられている。
また、本発明の一態様に係る通信装置において、前記信頼度情報が、ＩＰｖ６（Internet Protocol version ６）パケットヘッダのトラフィッククラスフィールド内に割り当てられている。
また、本発明の一態様に係る通信装置において、前記信頼度情報設定手段によって前記１又は複数を選択した結果に基づいて当該パケットの前記信頼度情報が設定されるまでの前記信頼度情報の値は、前記信頼度が不明であることを示す値に決定されている。
また、本発明の一態様に係る通信方法は、パケットにより、ネットワークを介して通信する通信方法であって、前記通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部が、前記パケットのパケットヘッダの所定位置に設けられており、前記ネットワークから受信したパケットに付与されているアドレス情報がブラックリストに非該当であり、かつ匿名ＩＰアドレスに該当している場合に、前記パケットの匿名性を示す所定値を前記信頼度情報の一部に設定し、前記信頼度情報に基づいて、当該パケットの信頼度が比較的高い又は当該パケットが匿名性を有することと、当該パケットのリスクが比較的高いことと、の内から１又は複数を選択し、前記１又は複数を選択した結果に基づいて当該パケットの前記信頼度情報を設定し、又は、前記１又は複数を選択した結果に基づいて前記信頼度が不明なパケットを選択して、前記選択されたパケットの前記信頼度情報を維持する、通信方法である。
また、本発明の一態様に係るプログラムは、パケットにより、ネットワークを介して通信する通信装置のコンピュータに、前記通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部が、前記パケットのパケットヘッダの所定位置に設けられており、前記ネットワークから受信したパケットに付与されているアドレス情報がブラックリストに非該当であり、かつ匿名ＩＰアドレスに該当している場合に、前記パケットの匿名性を示す所定値を前記信頼度情報の一部に設定するステップと、前記信頼度情報に基づいて、当該パケットの信頼度が比較的高い又は当該パケットが匿名性を有することと、当該パケットのリスクが比較的高いことと、の内から１又は複数を選択するステップと、前記１又は複数を選択した結果に基づいて当該パケットの前記信頼度情報を設定するステップ、又は、前記１又は複数を選択した結果に基づいて前記信頼度が不明なパケットを選択して、前記選択されたパケットの前記信頼度情報を維持するステップと、を実行させるためのプログラムである。
本発明の一態様によれば、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信者側へ通知する通信装置、通信方法、及びプログラムを提供することができる。
以下、図面を参照し、本発明の通信装置、通信方法、及びプログラムの実施形態について説明する。
図１は、本実施形態の通信システム１の構成を示す図である。通信システム１は、ネットワークＮＷ１を形成する。ネットワークＮＷ１は、互いに通信を可能とする１又は複数の他のネットワークに接続されている。ネットワークＮＷ２とネットワークＮＷ３とネットワークＮＷ４は、他のネットワークの一例である。以下の説明において、ネットワークＮＷ１、ネットワークＮＷ２、ネットワークＮＷ３、ネットワークＮＷ４等を総称してネットワークＮＷということがある。例えば、各ネットワークＮＷは、異なるＩＳＰ（Internet Service Provider）等によって独立して管理されており、管理者が定める通信規則（ポリシー等）はそれぞれ異なるものとする。例えば、各ネットワークＮＷは、互いに接続されており、例えば、それぞれがインターネットの一部を構成する。
本実施形態の各通信システムにおいて、それぞれの通信規則を次の６つの規則に分けて規定する。
第１規則は、自通信システムにおいて通信することを許可しないものを、制限対象の通信として定める。例えば、通信システム１は、制限対象として定められた通信のパケットを、廃棄対象のパケットとして選択するための条件（「廃棄対象条件」）を、「廃棄対象情報」として管理する。通信システム１は、廃棄対象情報をリスト化したブラックリスト（「廃棄対象ブラックリスト」）又はテーブル化した「廃棄テーブル」を利用することにより、制限対象とする通信を規制する。通信システム１は、廃棄対象ブラックリスト、又は、廃棄テーブルを各装置の廃棄対象記憶部等にそれぞれ格納してもよい。制限対象には、各装置に共通するもの、装置毎に固有のものが含まれていてもよい。なお、上記及び以下の説明における「廃棄」には、当該パケットに付与されている宛先情報又は送信元情報の少なくともいずれかに基づく通信を制限する、又は宛先情報又は送信元情報の少なくともいずれかに基づく通信を許可しない、又は宛先情報の少なくともいずれかに基づく通信を遮断する、又は宛先情報の少なくともいずれかに基づく通信を遮断し特定のポートに出力するなどのケースも含まれるものとし、これらを纏めて単に「廃棄」という。
第１規則は、自通信システムにおいて通信することを許可しないものを、制限対象の通信として定める。例えば、通信システム１は、制限対象として定められた通信のパケットを、廃棄対象のパケットとして選択するための条件（「廃棄対象条件」）を、「廃棄対象情報」として管理する。通信システム１は、廃棄対象情報をリスト化したブラックリスト（「廃棄対象ブラックリスト」）又はテーブル化した「廃棄テーブル」を利用することにより、制限対象とする通信を規制する。通信システム１は、廃棄対象ブラックリスト、又は、廃棄テーブルを各装置の廃棄対象記憶部等にそれぞれ格納してもよい。制限対象には、各装置に共通するもの、装置毎に固有のものが含まれていてもよい。なお、上記及び以下の説明における「廃棄」には、当該パケットに付与されている宛先情報又は送信元情報の少なくともいずれかに基づく通信を制限する、又は宛先情報又は送信元情報の少なくともいずれかに基づく通信を許可しない、又は宛先情報の少なくともいずれかに基づく通信を遮断する、又は宛先情報の少なくともいずれかに基づく通信を遮断し特定のポートに出力するなどのケースも含まれるものとし、これらを纏めて単に「廃棄」という。
第２規則は、自通信システムにおいて通信することを許可する条件を定めるものである。例えば、通信システム１は、許可する通信によるパケットを選択する条件（「通信許可条件」）を、「通信許可情報」に纏めて管理する。通信システム１は、通信許可情報をリスト化したホワイトリスト（「通信許可ホワイトリスト」）又はテーブル化した「ＭＬＢテーブル」を利用することにより、許可する通信を抽出する。ＭＬＢテーブルの詳細については後述する。なお、「通信許可ホワイトリスト」はホワイトリストの一例である。
第３規則は、自通信システムにおける通信のパケットの転送先を決定する「ルーティング条件」を定めるものである。例えば、通信システム１は、ルーティング条件を、「ルーティング情報」として管理する。通信システム１は、「ルーティング情報」をテーブル化した「ルーティングテーブル」を利用して、通信を制御する。
第４規則は、自通信システムにおいて、通信相手として許可するものを限定する条件を定めるものである。例えば、通信システム１は、限定した通信相手からのパケットを選択する条件（「通信相手許可条件」）を、「通信相手許可情報」に纏めて管理する。通信システム１は、通信相手許可情報をリスト化したホワイトリスト（「通信相手許可ホワイトリスト」）又はテーブル化した「ＱｏＳテーブル」を利用することにより、限定した通信相手を抽出する。ＱｏＳテーブルの詳細については後述する。なお、「通信相手許可ホワイトリスト」はホワイトリストの一例である。
第５規則は、通信によるネットワークセキュリティ上のリスクが比較的低いパケットであることを、当該パケットに明示して通信するための条件を定めるものである。
例えば、ネットワークセキュリティ上の信頼度に関する要求レベルが、通信システム１における所定の信頼度基準として規定される。通信システム１は、上記の所定の信頼度基準を満たす送信元を選択するための条件（「認証済送信元条件」）を、「認証済送信元情報」に纏めて管理することにより、通信によるネットワークセキュリティ上のリスクが比較的低いことを検出してもよい。パケットを送信した送信端末又は送信エンティティは、送信元の一例である。認証済送信元情報には、パケットを送信した送信端末又は送信エンティティを特定するための情報が含まれる。
上記の場合、通信システム１は、認証済送信元情報に基づいてパケットの送信元を判定することにより、上記の所定の信頼度基準を満たすと判定される送信元から送信されたパケットを特定し、当該パケットについては、ネットワークセキュリティ上のリスクが比較的低いと判定する。その判定の結果は、当該パケットの信頼度情報の一例である。通信システム１は、その判定の結果を、認証フラグＦ１又は特定のコードなどを用いて示すことにより、リスクが比較的低いパケットであることを管理可能にする。つまり、通信システム１は、その判定の結果に基づいて、認証フラグＦ１又は特定のコードなどを用いて、信頼度が比較的高いパケットであることを管理可能にする。本実施形態では、後述する認証フラグＦ１などのフラグを利用して、信頼度情報をそのフラグに対応付ける事例について説明する。通信システム１は、送信元が所定の信頼度基準を満たすものであるか否かの判定を、通信の接続要求時の認証処理、又は、検疫処理により実施してもよい。その場合、上記の処理の結果に基づいて、通信システム１は、例えば、認証フラグＦ１の状態を決定し、当該パケットの認証フラグＦ１を設定する。
なお、上記の判定が実施されて、その判定結果に対応するフラグがパケットにセットされることにより、当該パケットを中継する装置又は受信装置は、上記の場合に当たるか否かの判定を、上記の「認証フラグＦ１」の状態の判定に代えることができる。「認証フラグＦ１」を当該パケットに付与する具体的な方法については後述する。
第６規則は、通信によるネットワークセキュリティ上のリスクが比較的高いパケットであることを、当該パケットに明示して通信するための条件を定めるものである。
例えば、通信システム１は、送信元又は宛先を隠ぺい又は詐称したパケットを検出するためのアドレス情報又はメールアドレス情報又はアカウント情報又は電話番号又はＵＲＬ（Uniform Resource Locator）又はＵＲＩ（Uniform Resource Identifier）又はＵＲＮ（Uniform Resource Name）又はドメイン名又はＦＱＤＮ（Fully Qualified Domain Name）を纏めて管理することにより、通信によるネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを検出してもよい。通信システム１は、送信元又は宛先を隠ぺい又は詐称したパケットを検出するためのアドレス情報又はメールアドレス情報又はアカウント情報又は電話番号又はＵＲＬ又はＵＲＩ又はＵＲＮ又はドメイン名又はＦＱＤＮをリスト化したリストを以下、アドレスリスト（「匿名アドレスリスト」）と総称し、「匿名アドレスリスト」を利用して、条件に該当するパケットを抽出する。「匿名アドレスリスト」の詳細については後述する。
上記の場合、通信システム１は、送信元又は宛先を隠ぺい又は詐称したパケットについては、ネットワークセキュリティ上のリスクがある又はリスクが比較的高いと判定し、その判定の結果から当該パケットが所定の信頼度基準を必ずしも満たすものではないことを、リスクフラグＲＦを用いて管理する。通信システム１は、送信元又は宛先を隠ぺい又は詐称したパケットであるか否かの判定を、外部から提供される情報に基づいて実施してもよい。その判定の結果に基づいて、通信システム１は、リスクフラグＲＦの状態を決定し、当該パケットのリスクフラグＲＦを設定する。なお、上記の判定の詳細については後述する。
上記の場合、通信システム１は、送信元又は宛先を隠ぺい又は詐称したパケットについては、ネットワークセキュリティ上のリスクがある又はリスクが比較的高いと判定し、その判定の結果から当該パケットが所定の信頼度基準を必ずしも満たすものではないことを、リスクフラグＲＦを用いて管理する。通信システム１は、送信元又は宛先を隠ぺい又は詐称したパケットであるか否かの判定を、外部から提供される情報に基づいて実施してもよい。その判定の結果に基づいて、通信システム１は、リスクフラグＲＦの状態を決定し、当該パケットのリスクフラグＲＦを設定する。なお、上記の判定の詳細については後述する。
上記の判定が実施されて、その判定結果に対応するフラグがパケットにセットされることにより、当該パケットを中継する装置又は受信装置は、上記の場合に当たるか否かの判定を、上記の「リスクフラグＲＦ」の状態の判定に代えることができる。「リスクフラグＲＦ」を当該パケットに付与する具体的な方法については後述する。
なお、上記の第５規則は、上記のホワイトリストとは異なり当該パケットの通信を奨励することを示すものではない。また、上記の第６規則は、上記のブラックリストとは異なり当該パケットの通信を制限すべきものであることを示すものではない。第５規則と第６規則はともに、所定の判定基準に則って判定した結果を当該パケットに示すことを規定するものである。このように規定され、判定の結果を示すフラグがパケットに設けられていることにより、そのフラグを参照することで、当該パケットを受信すべきものか否かを、受信者側の端末装置で判断することが可能になる。通信システム１では、受信者側の端末装置に、上記の判断の結果に基づいたパケットの処理を、受信者の指定に基づいて実施させる。これにより、通信システム１は、自律分散や自己責任などの特徴を有しているインターネット文化を維持しつつ、安心・安全なインターネット環境が実現するように支援する。
通信システム１は、上記の規則の一部又は全部を利用して、その通信を制御する。
なお、本実施形態の以下の説明において、第２規則の通信許可ホワイトリストと第４規則の通信相手許可ホワイトリストの双方を区別することなく説明する場合に、単に「ホワイトリスト」という。また、第２規則の通信許可情報と第３規則のルーティング情報と第４規則の通信相手許可情報の全部または一部を纏めて経路情報という。また、通信システム１において通信相手を限定して通信する特定の装置を対象装置と呼び、対象装置又は対象装置による通信の何れかを特定する情報を特定情報と呼ぶ。例えば、特定情報には、通信許可情報又は通信相手許可情報を生成するための情報が含まれる。
なお、特定の装置又は通信を識別するための情報を識別情報と呼ぶことがある。例えば、受信したパケットに付与された識別情報を取得する場合には、通信の階層のレイヤ１の識別子、レイヤ２（Ｌ２）アドレス、レイヤ３（Ｌ３）アドレス（ＩＰアドレス）、及び、レイヤ４（Ｌ４）プロトコルのポート番号の一部又は全部を含む情報が識別情報に含まれる。また、特定の通信相手を特定する場合の識別情報には、各装置のＩＰアドレス又はＵＲＬ（Uniform Resource Locator）などが含まれる。第３規則のルーティング情報は、上記の識別情報としての宛先ＩＰアドレスによって規定される場合がある。
なお、本実施形態の以下の説明では、ＩＰｖ４（Internet Protocol version ４）の場合を例示して説明するが、ＩＰｖ６（Internet Protocol version ６）の場合も本実施形態に示す処理と同様の手法を適用することができる。
通信システム１は、ｅＭＬＢＲ（egress Multi Layer Binding Router）１１と、ｉＭＬＢＲ（ingress MLBR）１２と、ｂＭＬＢＲ（border MLBR）１３と、中継装置１４と、管理ホスト１５とを含む。以下の説明において、ｅＭＬＢＲ１１と、ｉＭＬＢＲ１２と、ｂＭＬＢＲ１３とを総称してＭＬＢＲ１０ということがある。各ＭＬＢＲ１０は、通信システム１の通信ノードとして機能する。通信システム１は、複数のＭＬＢＲ１０によってネットワークＮＷ１を構成する。ネットワークＮＷ１内の各ＭＬＢＲ１０間は、互いに直接的に接続されていてもよく、中継装置１４等を介して接続されていてもよい。
通信システム１には、ユーザが操作する端末装置１７、ＩｏＴ（Internet of Things）等と総称される各種データ端末１８などの端末が通信可能に接続される。例えば、端末装置１７とデータ端末１８は、ｅＭＬＢＲ１１等を介して、各端末からの要求等に起因する所望の通信を実施する。ＩｏＴ等と総称される各種データ端末１８は、対象装置の一例である。
管理ホスト１５は、通信システム１における基本設定を行うとともに、各ＭＬＢＲ１０の状態を監視させてもよい。さらに管理ホスト１５は、連携サーバとして機能し、端末装置１７などの認証と検疫を担うＨＲＳ（Home RADIUS Server）として機能させてもよい。また、管理ホスト１５は、ＩＤＳ（Intrusion Detection System）／ＩＰＳ（Intrusion Prevention System）等により検出した通信履歴を記憶するように構成してもよい。また、管理ホスト１５は、通信プロトコルを監視するプロトコルモニタとして機能してもよい。また、管理ホスト１５は、特定の装置に対してポートスキャンを実施するように構成してもよい。
通信システム１と同様に、通信システム２は、ネットワークＮＷ２を形成する。通信システム２は、ｅＭＬＢＲ２１と、ｉＭＬＢＲ２２と、ｂＭＬＢＲ２３と、管理装置２５とを含む。また、通信システム３は、ネットワークＮＷ３を形成する。通信システム３は、ｅＭＬＢＲ３１と、ｉＭＬＢＲ３２と、ｂＭＬＢＲ３３と、管理装置３５とを含む。通信システム２におけるｅＭＬＢＲ２１と、ｉＭＬＢＲ２２と、ｂＭＬＢＲ２３と、管理装置２５、及び、通信システム３におけるｅＭＬＢＲ３１と、ｉＭＬＢＲ３２と、ｂＭＬＢＲ３３と、管理装置３５は、通信システム１のｅＭＬＢＲ１１と、ｉＭＬＢＲ１２と、ｂＭＬＢＲ１３と、管理ホスト１５にそれぞれ対応する。通信システム２のｅＭＬＢＲ２１には、サーバ装置ＳＶが接続されている。各通信システムに接続される装置は、図に示されたものに制限されることなく、適宜設けることができる。
通信システム４は、ネットワークＮＷ４を形成する。通信システム４は、通信システム１とは異なり、ＭＬＢＲ１０を含まずに、ＭＬＢＲ１０とは異なるルータ等により構成される。以下の説明で、ネットワークＮＷ４またはネットワークＮＷ４のようにＭＬＢＲ１０とは異なるルータ等により構成されたネットワークのことを、比較例のネットワークと呼ぶことがある。
以下、通信システム１において、接続経路が隠ぺい化されたパケットを用いて実施される通信に対するネットワークセキュリティ対策の一例について説明する。以下に示す通信システム１は、送信端末が通信を許可すべき接続要求元として認証されている場合、又は上記の通信の接続要求元が検疫されている場合に適用されるものである。
（送信端末の認証）
通信を許可すべき接続要求元として送信端末を認証する認証方法として、端末装置の種別により異なる方法がとり得る。例えば、送信端末が汎用のパーソナルコンピュータなどであれば、その多くのものは、ＯＳ等の機能によりIEEE802.1X認証を利用できることが知られている。送信端末が汎用のものであれば、IEEE802.1X認証を利用することで、許容する通信の範囲を制限したり、送信元が認証済みであること示したりすることが可能になる。
これに対し、ＩｏＴ機器については、IEEE802.1X認証を利用できないものがある。IEEE802.1X認証を利用できるＩｏＴ機器については、汎用の端末装置と同様にIEEE802.1X認証を適用できるが、IEEE802.1X認証を利用できないＩｏＴ機器については、汎用の端末装置と同様の手法を利用することができない。以下の説明で例示するＩｏＴ機器は、例えば、IEEE802.1X認証を利用できない通信端末装置の一例である。
通信を許可すべき接続要求元として送信端末を認証する認証方法として、端末装置の種別により異なる方法がとり得る。例えば、送信端末が汎用のパーソナルコンピュータなどであれば、その多くのものは、ＯＳ等の機能によりIEEE802.1X認証を利用できることが知られている。送信端末が汎用のものであれば、IEEE802.1X認証を利用することで、許容する通信の範囲を制限したり、送信元が認証済みであること示したりすることが可能になる。
これに対し、ＩｏＴ機器については、IEEE802.1X認証を利用できないものがある。IEEE802.1X認証を利用できるＩｏＴ機器については、汎用の端末装置と同様にIEEE802.1X認証を適用できるが、IEEE802.1X認証を利用できないＩｏＴ機器については、汎用の端末装置と同様の手法を利用することができない。以下の説明で例示するＩｏＴ機器は、例えば、IEEE802.1X認証を利用できない通信端末装置の一例である。
そこで、通信システム１では、ＩｏＴ機器については、下記のいずれかの方法で当該端末装置の認証を実施する。
第１の方法として、ＩｏＴ機器の多くは特定の通信相手と通信することから、特定の通信相手に対して通信の接続を要求する端末装置を、正当なＩｏＴ機器として認証する。
第２の方法として、当該装置が送信する属性情報から、当該装置がＩｏＴ機器であることを判別する。例えば、当該装置のＭＡＣアドレスを上記の属性情報とし、その属性情報に基づいて、端末装置を、正当なＩｏＴ機器として認証してもよい。
第１の方法として、ＩｏＴ機器の多くは特定の通信相手と通信することから、特定の通信相手に対して通信の接続を要求する端末装置を、正当なＩｏＴ機器として認証する。
第２の方法として、当該装置が送信する属性情報から、当該装置がＩｏＴ機器であることを判別する。例えば、当該装置のＭＡＣアドレスを上記の属性情報とし、その属性情報に基づいて、端末装置を、正当なＩｏＴ機器として認証してもよい。
通信システム１は、ＭＬＢＲ１０が保持管理する物理ポート又は（セキュア）チャネルとＭＡＣアドレスとＩＰアドレスとの対応関係を管理する。例えば、通信システム１は、上記の対応関係を満足しないパケットについて、通信を許可しないものであると判定して廃棄する。なお、以下の説明における「パケット」には、当該パケットにレイヤ２でＭＡＣヘッダとトレーラを付加した所謂ＭＡＣフレームなどのフレームも含まれるものとし、これらを纏めて単に「パケット」という。
（ＭＬＢＲ１０）
通信システム１を構成するＭＬＢＲ１０には、複数のタイプがあり、互いに構成と用途が異なる。利用者ネットワーク側の出口（egress）に設置するｅＭＬＢＲ１１と、ネットワークＮＷ１の利用者側入口（ingress）端部（エッジ）に設置するｉＭＬＢＲ１２と、他のネットワークとの境界（border）に配置するｂＭＬＢＲ１３は、ＭＬＢＲ１０の一例である。ＭＬＢＲ１０の各タイプを上記のように配置することにより、例えば、外部のネットワークから大量の送信元ＩＰアドレスを詐称するパケットが送り付けられても、ｂＭＬＢＲ１３等が経路表の逆行経路から外れた当該攻撃パケットを遮断する。さらに、ｂＭＬＢＲ１３等は、その処理を実施するに当たり送信元ＩＰアドレス以外の情報を組み合わせて利用して、より正確に処理をする。例えば、送信元ＩＰアドレス以外の情報には、攻撃パケットの廃棄を要請した端末装置１７もしくは実際に攻撃された通信端末等のＩＰアドレス、ＴＣＰ等のレイヤ４（Ｌ４）のポート番号、制御フラグ等が含まれていてもよい。
通信システム１を構成するＭＬＢＲ１０には、複数のタイプがあり、互いに構成と用途が異なる。利用者ネットワーク側の出口（egress）に設置するｅＭＬＢＲ１１と、ネットワークＮＷ１の利用者側入口（ingress）端部（エッジ）に設置するｉＭＬＢＲ１２と、他のネットワークとの境界（border）に配置するｂＭＬＢＲ１３は、ＭＬＢＲ１０の一例である。ＭＬＢＲ１０の各タイプを上記のように配置することにより、例えば、外部のネットワークから大量の送信元ＩＰアドレスを詐称するパケットが送り付けられても、ｂＭＬＢＲ１３等が経路表の逆行経路から外れた当該攻撃パケットを遮断する。さらに、ｂＭＬＢＲ１３等は、その処理を実施するに当たり送信元ＩＰアドレス以外の情報を組み合わせて利用して、より正確に処理をする。例えば、送信元ＩＰアドレス以外の情報には、攻撃パケットの廃棄を要請した端末装置１７もしくは実際に攻撃された通信端末等のＩＰアドレス、ＴＣＰ等のレイヤ４（Ｌ４）のポート番号、制御フラグ等が含まれていてもよい。
図２を参照して、通信システム１における各ＭＬＢＲ１０について説明する。図２は、通信システム１の構成例を示す図である。通信システム１におけるＭＬＢＲ１０の詳細について順に説明する。
（ｅＭＬＢＲ１１）
ｅＭＬＢＲ１１（通信装置）は、コントローラ１１１（制御部）と、ＩＦ部１１３と、ＩＦ部１１４と、スイッチ部１１２（転送部）と、記憶部１１５とを含む。コントローラ１１１と記憶部１１５の組み合わせは通信装置の一例である。
ｅＭＬＢＲ１１（通信装置）は、コントローラ１１１（制御部）と、ＩＦ部１１３と、ＩＦ部１１４と、スイッチ部１１２（転送部）と、記憶部１１５とを含む。コントローラ１１１と記憶部１１５の組み合わせは通信装置の一例である。
ＩＦ部１１３は、端末装置１７又はデータ端末１８とのインタフェースである。例えば、端末装置１７又はデータ端末１８と有線で通信する場合、ＩＦ部１１３は、通信回線が接続される物理ポートに対応させて設けられ、物理ポートを介して通信回線から取得したパケットをスイッチ部１１２に出力し、スイッチ部１１２により転送されたパケットを、物理ポートに接続される通信回線に出力する。また、例えば、端末装置１７又はデータ端末１８と無線で通信する場合、ＩＦ部１１３は、無線通信の（セキュア）チャネルに対応させて設けられ、特定の（セキュア）チャネルから取得したパケットをスイッチ部１１２に出力し、スイッチ部１１２により転送されたパケットを、特定の（セキュア）チャネルまたは有線の物理ポートに出力する。以下、物理ポートと（セキュア）チャネルを接続ポートと総称する。
ＩＦ部１１４は、他のＭＬＢＲ１０等と通信する際のインタフェースである。例えば、ＩＦ部１１４は、通信回線が接続される物理ポートに対応させて設けられ、物理ポートを介して通信回線から取得したパケットをスイッチ部１１２に出力する。また、スイッチ部１１２から転送されたパケットを、物理ポートに接続される通信回線に出力する。
スイッチ部１１２は、コントローラ１１１により設定された条件に基づいて、ＩＦ部１１３とＩＦ部１１４とコントローラ１１１等の間でパケットを転送する。例えば、スイッチ部１１２は、プロトコルスタックのレイヤ２（Ｌ２）からレイヤ４（Ｌ４）までの各ヘッダ情報と物理ポートの識別情報などに基づいて、当該パケットの転送を制御する。パケットを転送する処理の詳細は後述する。
記憶部１１５は、ＲＯＭ（Read Only Memory）、ＥＥＰＲＯＭ（Electrically Erasable and Programmable Read Only Memory）、ＨＤＤ（Hard Disk Drive）等の不揮発性の記憶装置と、ＲＡＭ（Random Access Memory）レジスタ等の揮発性の記憶装置によって実現される。記憶部１１５は、ｅＭＬＢＲ１１を機能させるためのプログラム、スイッチ部１１２を制御するための複数のテーブル、通信履歴情報等を格納する。
例えば、第１記憶部１１５１と第２記憶部１１５２と第３記憶部１１５３と第４記憶部１１５４と第５記憶部１１５５と第６記憶部１１５６とは、上記の複数のテーブルを格納する記憶部の一例である。第１記憶部１１５１は、ｅＭＬＢＲ１１が受信した受信パケット（受信データ）の転送を制限する条件を定めた第１規則（廃棄対象ブラックリスト）を記憶する。受信パケットは、ヘッダ情報とデータ（受信データ）とを含んで構成される。第２記憶部１１５２は、受信パケットの転送を許可する条件を定めた第２規則（通信許可ホワイトリスト）を記憶する。第３記憶部１１５３は、パケットの転送先を決定するルーティング条件を定めた第３規則（ルーテイングテーブル、経路情報）を記憶する。第４記憶部１１５４は、限定した通信相手との通信のみを許可する条件を定めた第４規則（通信相手許可ホワイトリスト、経路情報）を記憶する。第５記憶部１１５５は、所定の信頼度基準を満たした送信元を選択する条件（認証済送信元情報）を定めた第５規則を記憶する。第６記憶部１１５６は、送信元又は宛先を隠ぺい又は詐称したパケットを検出するための条件（匿名アドレスリスト）を定めた第６規則を記憶する。
コントローラ１１１は、例えば、ＣＰＵ（Central Processing Unit）等のプロセッサを有する。コントローラ１１１は、記憶部１１５に記憶されているプログラムにより、複数の物理ポートを有するスイッチ部１１２から得た情報と、記憶部１１５に記憶されている複数のテーブルの情報の少なくとも何れかの情報に基づいて、スイッチ部１１２を制御する。例えば、コントローラ１１１は、管理ホスト１５から取得した各種情報、端末装置１７又はデータ端末１８からの要請などに基づいて、第１記憶部１１５１や第２記憶部１１５２、第３記憶部１１５３、第４記憶部１１５４、第５記憶部１１５５、第６記憶部１１５６を必要に応じて更新し、スイッチ部１１２の転送処理を変更する。より具体的には、後述するように、第１記憶部１１５１に格納された第１規則はスイッチ部１１２内の廃棄テーブル１１２１に、第２記憶部１１５２に格納された第２規則はスイッチ部１１２内のＭＬＢテーブル１１２４に、第３記憶部１１５３に格納された第３規則はスイッチ部１１２内のルーティングテーブル１１２５に、第４規則はスイッチ部１１２内のＱｏＳテーブル１１２６に、第５規則はスイッチ部１１２内のＭＬＢテーブル１１２４に、第６規則はスイッチ部１１２内の匿名フラグ設定テーブル１１２７（第２フラグ設定手段）に、登録され、それぞれがパケットの転送を制御する。その際に、パケットヘッダの情報が各テーブルの機能により適宜変更される。
通信システム１における通信メッセージは、フレーム又はパケットとして通信される。フレーム又はパケットのヘッダ情報には、通信メッセージを含むフレーム又はパケットを識別する識別情報が付与される。
特定情報取得部１１１１は、スイッチ部１１２を介する通信において、通信相手を限定して通信するデータ端末１８などの対象装置を特定する特定情報又はデータ端末１８などの対象装置による通信を特定する特定情報の少なくとも何れかを取得する。特定情報の詳細は後述する。
識別情報取得部１１１２は、特定情報に基づいて特定される通信を識別する識別情報を取得する。識別情報取得部１１１２は、データ端末１８からの通信要求に起因する認証処理、検疫処理、レイヤ３アドレスの割り当て処理の一部又は全部の処理の結果から、識別情報を取得してもよい。識別情報を取得する方法の詳細は後述する。
ＷＬ管理部１１１３は、通信を許可する条件を抽出し、ホワイトリストを生成して、その条件を管理する。このホワイトリストには、第２規則の通信許可ホワイトリストと第４規則の通信相手許可ホワイトリストの何れか一方又は両方が含まれる。
出力制御部１１１４は、複数の出力ポートを有するスイッチ部１１２の出力ポートを選択するためのルーティング情報を生成する。ＷＬ管理部１１１３と出力制御部１１１４についての詳細は後述する。
管理部１１１５は、識別情報取得部１１１２により取得された送信元の認証処理の結果、又は、検疫処理の結果を管理する。また、管理部１１１５は、それらの結果から、認証された送信元、又は、検疫処理の結果に異常が発見されなかったパケットの送信元に関する送信元認証情報を抽出して第５記憶部１１５５に書き込む。
また、管理部１１１５は、外部の装置から提供される「認証済送信元条件」などに関する情報を取得して、第５記憶部１１５５に書き込む。また、管理部１１１５は、外部の装置から提供される「匿名アドレスリスト」などに関する情報を取得して、第６記憶部１１５６に書き込む。
（ｉＭＬＢＲ１２）
ｉＭＬＢＲ１２は、コントローラ１２１と、ＩＦ部１２３と、ＩＦ部１２４と、スイッチ部１２２と、記憶部１２５とを含む。記憶部１２５が備える第１記憶部１２５１と第２記憶部１２５２と第３記憶部１２５３と第４記憶部１２５４と第５記憶部１２５５と第６記憶部１２５６とは、上記の複数のテーブルの一例である。第１記憶部１２５１は、ｉＭＬＢＲ１２が受信した受信パケット（受信データ）の転送を制限する条件を定めた第１規則（廃棄対象ブラックリスト）を記憶する。受信パケットは、ヘッダ情報とデータ（受信データ）とを含んで構成される。第２記憶部１２５２は、受信パケットの転送を許可する条件を定めた第２規則（通信許可ホワイトリスト）を記憶する。第３記憶部１２５３は、パケットの転送先を決定するルーティング条件を定めた第３規則（ルーテイングテーブル、経路情報）を記憶する。第４記憶部１２５４は、限定した通信相手との通信のみを許可する条件を定めた第４規則（通信相手許可ホワイトリスト、経路情報）を記憶する。第５記憶部１２５５は、「所定の信頼度基準を満たした送信元を選択する条件（認証済送信元情報）を定めた第５規則を記憶する。第６記憶部１２５６は、送信元又は宛先を隠ぺい又は詐称したパケットを検出するための条件（匿名アドレスリスト）を定めた第６規則を記憶する。
ｉＭＬＢＲ１２は、コントローラ１２１と、ＩＦ部１２３と、ＩＦ部１２４と、スイッチ部１２２と、記憶部１２５とを含む。記憶部１２５が備える第１記憶部１２５１と第２記憶部１２５２と第３記憶部１２５３と第４記憶部１２５４と第５記憶部１２５５と第６記憶部１２５６とは、上記の複数のテーブルの一例である。第１記憶部１２５１は、ｉＭＬＢＲ１２が受信した受信パケット（受信データ）の転送を制限する条件を定めた第１規則（廃棄対象ブラックリスト）を記憶する。受信パケットは、ヘッダ情報とデータ（受信データ）とを含んで構成される。第２記憶部１２５２は、受信パケットの転送を許可する条件を定めた第２規則（通信許可ホワイトリスト）を記憶する。第３記憶部１２５３は、パケットの転送先を決定するルーティング条件を定めた第３規則（ルーテイングテーブル、経路情報）を記憶する。第４記憶部１２５４は、限定した通信相手との通信のみを許可する条件を定めた第４規則（通信相手許可ホワイトリスト、経路情報）を記憶する。第５記憶部１２５５は、「所定の信頼度基準を満たした送信元を選択する条件（認証済送信元情報）を定めた第５規則を記憶する。第６記憶部１２５６は、送信元又は宛先を隠ぺい又は詐称したパケットを検出するための条件（匿名アドレスリスト）を定めた第６規則を記憶する。
第５規則に対応する認証済送信元情報は、ＭＬＢテーブル１２２４に登録された端末の中で、さらに所定の信頼度基準を満たしたもので、ホワイトリストに相当する。上記の所定の信頼度基準とは、例えば、IEEE802.1X認証や検疫に用いた所定の基準を示し、ＩｏＴ装置を対象としたＡＲＰリフレクションなどの簡易認証の基準は適用させないものとする。
例えば、上記の所定の信頼度基準を満たすパケットであれば、認証フラグＦ１がｅＭＬＢＲ１１によってセットされる。端末装置が勝手に認証フラグＦ１をセットしたパケットをｅＭＬＢＲ１１またはｉＭＬＢＲ１２に送信しても、これを受信したｅＭＬＢＲ１１またはｉＭＬＢＲ１２は、セットされていた認証フラグＦ１をリセットする。認証レベル又は検疫レベルをＭＬＢテーブル１１２４に付加するか、認証・検疫テーブルとして別に設けてもよい。管理ホスト１５は、各端末装置について定期的に再認証と再検疫を行い認証レベルと検疫レベル、並びに、認証・検疫テーブルを更新してもよい。
一方、匿名アドレスリストは、接続経路を隠ぺいしたＩＰアドレスや偽装したメールアドレス、偽装したアカウント又は偽装した電話番号又は偽装したＵＲＬ又は偽装したＵＲＩ又は偽装したＵＲＮ又は偽装したドメイン名又は偽装したＦＱＤＮなどを持つパケットの識別に当たるものである。これに該当するパケットは、ｅＭＬＢＲ１１又はｉＭＬＢＲ１２又はｂＭＬＢＲ１３によってリスクフラグＦＲがセットされる。
コントローラ１２１は、例えば、ＣＰＵ等のプロセッサ、揮発性又は不揮発性の記憶装置等を有する。コントローラ１２１は、記憶部１２５に記憶されているプログラムにより、複数の物理ポートを有するスイッチ部１２２から得た情報と、記憶部１２５に記憶されている複数のテーブルの情報の少なくとも何れかの情報に基づいて、スイッチ部１２２を制御する。例えば、コントローラ１２１は、管理ホスト１５から取得した各種情報、端末装置１７又はデータ端末１８からの要請などに基づいて、第１記憶部１２５１や第２記憶部１２５２、第３記憶部１２５３、第４記憶部１２５４、第５記憶部１２５５、第６記憶部１２５６を必要に応じて更新し、スイッチ部１２２の転送処理を変更する。スイッチ部１２２は、各段のフローテーブルとして、廃棄テーブル１２２１、パケットタイプテーブル１２２２、ＳＣＯＰＥテーブル１２２３、ＭＬＢテーブル１２２４、ルーティングテーブル１２２５、ＱｏＳテーブル１２２６、及び匿名フラグ設定テーブル１２２７を備える。例えば、第１記憶部１２５１に格納された第１規則はスイッチ部１２２内の廃棄テーブル１２２１に、第２記憶部１２５２に格納された第２規則はスイッチ部１２２内のＭＬＢテーブル１２２４に、第３記憶部１２５３に格納された第３規則はスイッチ部１２２内のルーティングテーブル１２２５に、第４規則はスイッチ部１２２内のＱｏＳテーブル１２２６に、第５規則はスイッチ部１２２内のＭＬＢテーブル１２２４に、第６規則はスイッチ部１２２内の匿名フラグ設定テーブル１２２７に、登録され、パケットの転送を制御する。
（ｂＭＬＢＲ１３）
ｂＭＬＢＲ１３は、コントローラ１３１と、ＩＦ部１３３と、ＩＦ部１３４と、スイッチ部１３２と、記憶部１３５とを含む。
記憶部１３５が備える第１記憶部１３５１と第２記憶部１３５２と第３記憶部１３５３と第４記憶部１３５４と第５記憶部１３５５と第６記憶部１３５６とは、上記の複数のテーブルの一例である。第１記憶部１３５１は、ｂＭＬＢＲ１３が受信した受信パケット（受信データ）の転送を制限する条件を定めた第１規則（廃棄対象ブラックリスト）を記憶する。受信パケットは、ヘッダ情報とデータ（受信データ）とを含んで構成される。第２記憶部１３５２は、受信パケットの転送を許可する条件を定めた第２規則（通信許可ホワイトリスト）を記憶する。第３記憶部１３５３は、パケットの転送先を決定するルーティング条件を定めた第３規則（ルーテイングテーブル、経路情報）を記憶する。第４記憶部１３５４は、限定した通信相手との通信のみを許可する条件を定めた第４規則（通信相手許可ホワイトリスト、経路情報）を記憶する。第５記憶部１３５５は、所定の信頼度基準を満たした送信元を選択する条件（認証済送信元情報）を定めた第５規則を記憶する。具体的には、相互認証したＭＬＢＲ１０が該当する。第６記憶部１３５６は、送信元又は宛先を隠ぺい又は詐称したパケットを検出するための条件（匿名アドレスリスト）を定めた第６規則を記憶する。
ｂＭＬＢＲ１３は、コントローラ１３１と、ＩＦ部１３３と、ＩＦ部１３４と、スイッチ部１３２と、記憶部１３５とを含む。
記憶部１３５が備える第１記憶部１３５１と第２記憶部１３５２と第３記憶部１３５３と第４記憶部１３５４と第５記憶部１３５５と第６記憶部１３５６とは、上記の複数のテーブルの一例である。第１記憶部１３５１は、ｂＭＬＢＲ１３が受信した受信パケット（受信データ）の転送を制限する条件を定めた第１規則（廃棄対象ブラックリスト）を記憶する。受信パケットは、ヘッダ情報とデータ（受信データ）とを含んで構成される。第２記憶部１３５２は、受信パケットの転送を許可する条件を定めた第２規則（通信許可ホワイトリスト）を記憶する。第３記憶部１３５３は、パケットの転送先を決定するルーティング条件を定めた第３規則（ルーテイングテーブル、経路情報）を記憶する。第４記憶部１３５４は、限定した通信相手との通信のみを許可する条件を定めた第４規則（通信相手許可ホワイトリスト、経路情報）を記憶する。第５記憶部１３５５は、所定の信頼度基準を満たした送信元を選択する条件（認証済送信元情報）を定めた第５規則を記憶する。具体的には、相互認証したＭＬＢＲ１０が該当する。第６記憶部１３５６は、送信元又は宛先を隠ぺい又は詐称したパケットを検出するための条件（匿名アドレスリスト）を定めた第６規則を記憶する。
コントローラ１３１は、例えば、ＣＰＵ等のプロセッサ、揮発性又は不揮発性の記憶装置等を有する。コントローラ１３１は、記憶部１３５に記憶されているプログラムにより、複数の物理ポートを有するスイッチ部１３２から得た情報と、記憶部１３５に記憶されている複数のテーブルの情報の少なくとも何れかの情報に基づいて、スイッチ部１３２を制御する。例えば、コントローラ１３１は、管理ホスト１５から取得した各種情報、端末装置１７又はデータ端末１８からの要請などに基づいて、第１記憶部１３５１や第２記憶部１３５２、第３記憶部１３５３、第４記憶部１３５４、第５記憶部１３５５、第６記憶部１３５６を必要に応じて更新し、スイッチ部１３２の転送処理を変更する。スイッチ部１３２は、各段のフローテーブルとして、廃棄テーブル１３２１、パケットタイプテーブル１３２２、ＳＣＯＰＥテーブル１３２３、ＭＬＢテーブル１３２４、ルーティングテーブル１３２５、ＱｏＳテーブル１３２６、及び匿名フラグ設定テーブル１３２７を備える。例えば、第１記憶部１３５１に格納された第１規則はスイッチ部１３２内の廃棄テーブル１３２１に、第２記憶部１３５２に格納された第２規則はスイッチ部１３２内のＭＬＢテーブル１３２４に、第３記憶部１３５３に格納された第３規則はスイッチ部１３２内のルーティングテーブル１３２５に、第４規則はスイッチ部１３２内のＱｏＳテーブル１３２６に、第５規則はスイッチ部１３２内のＭＬＢテーブル１３２４に、第６規則はスイッチ部１３２内の匿名フラグ設定テーブル１２２７に、登録され、パケットの転送を制御する。
上記のとおり、各ＭＬＢＲ１０は、それぞれコントローラとスイッチ部とを含む。ＭＬＢＲ１０のコントローラは、他のＭＬＢＲ１０のコントローラから取得した情報等に基づいて、自装置のコントローラ及びスイッチ部をそれぞれ制御する。
（端末装置１７）
図３７は、本実施形態の端末装置１７のハードウエア構成を示す図である。図３７に示すように端末装置１７は、ＣＰＵ１７Ａと、ＲＯＭ、ＥＥＰＲＯＭ、ＨＤＤなどの不揮発性記憶装置１７Ｂと、ＲＡＭ、レジスタ等の揮発性記憶装置１７Ｃと、キーボード、マウス、表示部などを含む入出力装置１７Ｄと、ｅＭＬＢＲ１１等に接続される通信インタフェース１７Ｅを備える。端末装置１７は、所謂コンピュータであり、ＣＰＵ１７Ａが実行するプログラムにより端末或いはサーバとして機能する。例えば、端末装置１７は、パーソナルコンピュータ、タブレット等の汎用端末である。端末装置１７のＣＰＵは、プログラムの実行により、端末装置１７を、ＩＤＳ／ＩＰＳとして機能させてもよい。この場合、端末装置１７は、端末装置１７に実装したもしくは端末装置１７が接続しているローカルエリアネットワークに接続されたＩＤＳ／ＩＰＳにより、所定の通信量又は頻度を超えて到来するパケットや、その振る舞いの異常さもしくは既知の攻撃パターン（シグネチャ）や既知の攻撃パターンから予測される未知の攻撃パターン、もしくは既知のマルウェアや既知のマルウェア等から予想されるマルウェア、既知のエクスプロイトコード（プログラムのセキュリティ上の脆弱性（セキュリティホール）を攻撃するために作成されたプログラムの総称）もしくは既知のエクスプロイトコードから予測される未知のエクスプロイトコードなどから攻撃パケットとして検出する。なお、上記の検出に当たり、ハニーポットを設置してもよい。ハニーポットとは、不正アクセスを行う攻撃パケットをおびき寄せ、攻撃をそらすためのおとりであり、ウイルスやワームの検体の入手、記録された操作ログ・通信ログなどから不正アクセスの手法や傾向の調査などに用いられるものである。例えば、端末装置１７は、攻撃パケットを検出した場合に、ネットワークＮＷ１への接続を遮断する。
ｅＭＬＢＲ１１は、ネットワークＮＷ１における攻撃パケットの転送を中断させることを要求するメッセージをｉＭＬＢＲ１２に対して送信してもよい。例えば、ｉＭＬＢＲ１２は、攻撃パケットの転送を中断させることを要求するメッセージを、攻撃パケットを廃棄することを要求する廃棄要請メッセージとして受け付けて、攻撃パケットを廃棄してもよい。以下の説明では、攻撃パケットの転送を中断させることを要求するメッセージをＤＲＭ（Dropping Request Message）と呼ぶ。例えば、端末装置１７は、自装置の正当性と完全性を示す検証用データもしくは認証コードをＤＲＭに付加してｅＭＬＢＲ１１へ送信する。さらに、ＤＲＭは、攻撃パケットの送信元アドレスに接近するようＭＬＢＲ１０間でバケツリレーされ、ＤＲＭを受信した各ＭＬＢＲ１０では、前述の第１規則として第１記憶部に登録する。
図３７は、本実施形態の端末装置１７のハードウエア構成を示す図である。図３７に示すように端末装置１７は、ＣＰＵ１７Ａと、ＲＯＭ、ＥＥＰＲＯＭ、ＨＤＤなどの不揮発性記憶装置１７Ｂと、ＲＡＭ、レジスタ等の揮発性記憶装置１７Ｃと、キーボード、マウス、表示部などを含む入出力装置１７Ｄと、ｅＭＬＢＲ１１等に接続される通信インタフェース１７Ｅを備える。端末装置１７は、所謂コンピュータであり、ＣＰＵ１７Ａが実行するプログラムにより端末或いはサーバとして機能する。例えば、端末装置１７は、パーソナルコンピュータ、タブレット等の汎用端末である。端末装置１７のＣＰＵは、プログラムの実行により、端末装置１７を、ＩＤＳ／ＩＰＳとして機能させてもよい。この場合、端末装置１７は、端末装置１７に実装したもしくは端末装置１７が接続しているローカルエリアネットワークに接続されたＩＤＳ／ＩＰＳにより、所定の通信量又は頻度を超えて到来するパケットや、その振る舞いの異常さもしくは既知の攻撃パターン（シグネチャ）や既知の攻撃パターンから予測される未知の攻撃パターン、もしくは既知のマルウェアや既知のマルウェア等から予想されるマルウェア、既知のエクスプロイトコード（プログラムのセキュリティ上の脆弱性（セキュリティホール）を攻撃するために作成されたプログラムの総称）もしくは既知のエクスプロイトコードから予測される未知のエクスプロイトコードなどから攻撃パケットとして検出する。なお、上記の検出に当たり、ハニーポットを設置してもよい。ハニーポットとは、不正アクセスを行う攻撃パケットをおびき寄せ、攻撃をそらすためのおとりであり、ウイルスやワームの検体の入手、記録された操作ログ・通信ログなどから不正アクセスの手法や傾向の調査などに用いられるものである。例えば、端末装置１７は、攻撃パケットを検出した場合に、ネットワークＮＷ１への接続を遮断する。
ｅＭＬＢＲ１１は、ネットワークＮＷ１における攻撃パケットの転送を中断させることを要求するメッセージをｉＭＬＢＲ１２に対して送信してもよい。例えば、ｉＭＬＢＲ１２は、攻撃パケットの転送を中断させることを要求するメッセージを、攻撃パケットを廃棄することを要求する廃棄要請メッセージとして受け付けて、攻撃パケットを廃棄してもよい。以下の説明では、攻撃パケットの転送を中断させることを要求するメッセージをＤＲＭ（Dropping Request Message）と呼ぶ。例えば、端末装置１７は、自装置の正当性と完全性を示す検証用データもしくは認証コードをＤＲＭに付加してｅＭＬＢＲ１１へ送信する。さらに、ＤＲＭは、攻撃パケットの送信元アドレスに接近するようＭＬＢＲ１０間でバケツリレーされ、ＤＲＭを受信した各ＭＬＢＲ１０では、前述の第１規則として第１記憶部に登録する。
（データ端末１８）
データ端末１８は、ＣＰＵと、ＲＯＭ、ＥＥＰＲＯＭ、ＨＤＤ、ＲＡＭ、レジスタ等の記憶装置と、を含むコンピュータであり、実行するプログラムにより端末或いはサーバとして機能するいわゆるＩｏＴ機器である。以下の説明に例示するデータ端末１８は、パケットのタイプとしてＩＰｖ４のパケットを利用して通信するものとし、IEEE802.1X認証を利用できないものとする。例えば、データ端末１８は、ネットワークに接続される各種センサ、スマートメータ、コネクテッドカー（自動車）、プリンター、テレビ、冷蔵庫、スマート家電、Ｍ２Ｍ（Machine to Machine）デバイス、ネットワークカメラ、自動販売機など多種多様な端末を総称する。これらの端末の通信相手は、特定のアドレス又はＵＲＬ又はＵＲＩ又はＵＲＮに限定される場合が多い。
データ端末１８は、ＣＰＵと、ＲＯＭ、ＥＥＰＲＯＭ、ＨＤＤ、ＲＡＭ、レジスタ等の記憶装置と、を含むコンピュータであり、実行するプログラムにより端末或いはサーバとして機能するいわゆるＩｏＴ機器である。以下の説明に例示するデータ端末１８は、パケットのタイプとしてＩＰｖ４のパケットを利用して通信するものとし、IEEE802.1X認証を利用できないものとする。例えば、データ端末１８は、ネットワークに接続される各種センサ、スマートメータ、コネクテッドカー（自動車）、プリンター、テレビ、冷蔵庫、スマート家電、Ｍ２Ｍ（Machine to Machine）デバイス、ネットワークカメラ、自動販売機など多種多様な端末を総称する。これらの端末の通信相手は、特定のアドレス又はＵＲＬ又はＵＲＩ又はＵＲＮに限定される場合が多い。
（スイッチ部を制御して端末装置のセキュリティ対策を実施するための処理）
図３を参照して、端末装置のセキュリティ対策を実施するための処理について説明する。図３は、端末装置のセキュリティ対策を実施するための処理の手順を示すフローチャートである。
図３を参照して、端末装置のセキュリティ対策を実施するための処理について説明する。図３は、端末装置のセキュリティ対策を実施するための処理の手順を示すフローチャートである。
通信システム１は、端末装置を、通信システム１において双方向通信を実施する端末として登録する（Ｓ１０）。
通信システム１において、例えば、上記の処理（Ｓ１０）は、下記する複数の処理の組み合わせとして実現される。
まず、通信システム１は、通信相手を限定する対象の端末装置を特定する（Ｓ１１）。
次に、通信システム１は、上記で特定された対象を識別可能な識別情報（第１識別情報）を取得する（Ｓ１２）。
次に、通信システム１は、上記で特定された対象の通信相手を識別可能な識別情報（第２識別情報）を取得する（Ｓ１３）。
次に、通信システム１は、限定する対象として特定された対象から送信されたパケットの通信相手を、上記で取得した識別情報（第１識別情報と第２識別情報）に基づいて限定するための通信相手許可ホワイトリストの要素（第１要素）を生成する（Ｓ１４）。
次に、通信システム１は、限定する対象として特定された対象宛に送信されたパケットの通信相手を、上記で取得した識別情報（第１識別情報と第２識別情報）に基づいて限定するための通信相手許可ホワイトリストの要素（第２要素）を生成する（Ｓ１５）。
次に、通信システム１は、通信相手許可ホワイトリストに上記の第１要素と第２要素とを追加する（Ｓ１６）。
次に、通信システム１は、Ｓ１１において特定した対象の端末装置のうち、所定の信頼度基準を満たした送信元（端末装置）を選択し、その識別情報を認証リストに追加する（Ｓ１８）。
次に、通信システム１は、信頼を置ける認定機関の監視装置から、匿名アドレスを利用して通信することを許容するノードのアドレスリストを取得する。例えば、管理ホスト１５は、配信されたノードのアドレスリストから匿名アドレスリストを生成して登録する（Ｓ１９）。
次に、通信システム１は、通信相手許可ホワイトリストに登録後に、第１要素と第２要素とに基づいて実際の通信を保護するための処理を実施して（Ｓ２０）、パケットの信頼度を示すフラグを、当該パケットに設定する（Ｓ２２）。
これにより、通信システム１は、端末装置のセキュリティ対策を実施する。
通信システム１において、例えば、上記の処理（Ｓ１０）は、下記する複数の処理の組み合わせとして実現される。
まず、通信システム１は、通信相手を限定する対象の端末装置を特定する（Ｓ１１）。
次に、通信システム１は、上記で特定された対象を識別可能な識別情報（第１識別情報）を取得する（Ｓ１２）。
次に、通信システム１は、上記で特定された対象の通信相手を識別可能な識別情報（第２識別情報）を取得する（Ｓ１３）。
次に、通信システム１は、限定する対象として特定された対象から送信されたパケットの通信相手を、上記で取得した識別情報（第１識別情報と第２識別情報）に基づいて限定するための通信相手許可ホワイトリストの要素（第１要素）を生成する（Ｓ１４）。
次に、通信システム１は、限定する対象として特定された対象宛に送信されたパケットの通信相手を、上記で取得した識別情報（第１識別情報と第２識別情報）に基づいて限定するための通信相手許可ホワイトリストの要素（第２要素）を生成する（Ｓ１５）。
次に、通信システム１は、通信相手許可ホワイトリストに上記の第１要素と第２要素とを追加する（Ｓ１６）。
次に、通信システム１は、Ｓ１１において特定した対象の端末装置のうち、所定の信頼度基準を満たした送信元（端末装置）を選択し、その識別情報を認証リストに追加する（Ｓ１８）。
次に、通信システム１は、信頼を置ける認定機関の監視装置から、匿名アドレスを利用して通信することを許容するノードのアドレスリストを取得する。例えば、管理ホスト１５は、配信されたノードのアドレスリストから匿名アドレスリストを生成して登録する（Ｓ１９）。
次に、通信システム１は、通信相手許可ホワイトリストに登録後に、第１要素と第２要素とに基づいて実際の通信を保護するための処理を実施して（Ｓ２０）、パケットの信頼度を示すフラグを、当該パケットに設定する（Ｓ２２）。
これにより、通信システム１は、端末装置のセキュリティ対策を実施する。
［より具体的な一実施例］
以下の説明では、ＯｐｅｎＦｌｏｗ（登録商標）の技術を適用してＭＬＢＲ１０を構成する場合を例示する。
以下の説明では、ＯｐｅｎＦｌｏｗ（登録商標）の技術を適用してＭＬＢＲ１０を構成する場合を例示する。
（分散型のコントローラ）
ＯｐｅｎＦｌｏｗの各ノードは、ＯｐｅｎＦｌｏｗコントローラにより制御されるＯｐｅｎＦｌｏｗスイッチ部を備える。一般的なＯｐｅｎＦｌｏｗの技術では、１つのＯｐｅｎＦｌｏｗコントローラが複数のＯｐｅｎＦｌｏｗスイッチを一元管理する。
これに代えて、本実施形態のＭＬＢＲ１０は、コントローラ１１１とスイッチ部１１２とを備えており、ＭＬＢＲ１０毎に設けられたコントローラ１１１がスイッチ部１１２を管理する。コントローラ１１１は、他のＭＬＢＲ１０のコントローラと独立に機能してもよく、連系して機能してもよい。この点が一般的なＯｐｅｎＦｌｏｗの構成と異なる。以下、上記の相違点を中心に説明する。
ＯｐｅｎＦｌｏｗの各ノードは、ＯｐｅｎＦｌｏｗコントローラにより制御されるＯｐｅｎＦｌｏｗスイッチ部を備える。一般的なＯｐｅｎＦｌｏｗの技術では、１つのＯｐｅｎＦｌｏｗコントローラが複数のＯｐｅｎＦｌｏｗスイッチを一元管理する。
これに代えて、本実施形態のＭＬＢＲ１０は、コントローラ１１１とスイッチ部１１２とを備えており、ＭＬＢＲ１０毎に設けられたコントローラ１１１がスイッチ部１１２を管理する。コントローラ１１１は、他のＭＬＢＲ１０のコントローラと独立に機能してもよく、連系して機能してもよい。この点が一般的なＯｐｅｎＦｌｏｗの構成と異なる。以下、上記の相違点を中心に説明する。
例えばコントローラ１１１は、特定情報取得部１１１１、識別情報取得部１１１２、ＷＬ管理部１１１３、出力制御部１１１４、管理部１１１５、パケットイン（Packet-In）１１１６、パケットアウト（Packet-Out）１１１７、及び、フロー変更出力部（Flow-Mod）１１１８を備える。
パケットイン１１１６は、スイッチ部１１２からの情報を受信する。パケットアウト１１７は、パケットとその宛先情報とを、スイッチ部１１２宛に出力する。フロー変更出力部（Flow-Mod）１１１８は、スイッチ部１１２の設定を変更するための情報をスイッチ部宛に出力する。スイッチ部１１２における他の構成の詳細については、後述する。
パケットイン１１１６は、スイッチ部１１２からの情報を受信する。パケットアウト１１７は、パケットとその宛先情報とを、スイッチ部１１２宛に出力する。フロー変更出力部（Flow-Mod）１１１８は、スイッチ部１１２の設定を変更するための情報をスイッチ部宛に出力する。スイッチ部１１２における他の構成の詳細については、後述する。
ＭＬＢＲ１０のコントローラは、少なくとも自装置のスイッチ部を制御して、その通信のセキュリティ性を確保する。なお、ＭＬＢＲ１０のコントローラは、互いに通信することにより、分散型のコントローラとして機能してもよく、その場合に、例えばＤＲＭを順に転送する。上記のとおり、ＤＲＭは、各ＭＬＢＲ１０における転送を制限するための情報である。ＭＬＢＲ１０は、ＤＲＭが通知されるまでに構成されていた転送情報を変更することなく、転送を制限する制限条件を追加し、また、制限条件を単位にして個々に削除する。これにより、通信システム１は、ネットワークＮＷ内の転送規則を維持したまま、転送を制限する制限条件のみを変更する。
(スイッチ部の一例)
図４から図１０を参照して、スイッチ部のより具体的な一例について説明する。図４は、ｅＭＬＢＲ１１を示す図である。スイッチ部１１２は、各段のフローテーブルとして、廃棄テーブル１１２１、パケットタイプテーブル１１２２、ＳＣＯＰＥテーブル１１２３、ＭＬＢテーブル１１２４、ルーティングテーブル１１２５、ＱｏＳテーブル１１２６及び、匿名フラグ設定テーブル１１２７を備える。図５Ａから図１０のそれぞれは、廃棄テーブル１１２１、匿名フラグ設定テーブル１１２７、パケットタイプテーブル１１２２、ＳＣＯＰＥテーブル１１２３、ＭＬＢテーブル１１２４、ルーティングテーブル１１２５、及びＱｏＳテーブル１１２６の一例を示す図である。
図４から図１０を参照して、スイッチ部のより具体的な一例について説明する。図４は、ｅＭＬＢＲ１１を示す図である。スイッチ部１１２は、各段のフローテーブルとして、廃棄テーブル１１２１、パケットタイプテーブル１１２２、ＳＣＯＰＥテーブル１１２３、ＭＬＢテーブル１１２４、ルーティングテーブル１１２５、ＱｏＳテーブル１１２６及び、匿名フラグ設定テーブル１１２７を備える。図５Ａから図１０のそれぞれは、廃棄テーブル１１２１、匿名フラグ設定テーブル１１２７、パケットタイプテーブル１１２２、ＳＣＯＰＥテーブル１１２３、ＭＬＢテーブル１１２４、ルーティングテーブル１１２５、及びＱｏＳテーブル１１２６の一例を示す図である。
（スイッチ部における各種テーブルの一例）
スイッチ部１１２において、廃棄テーブル１１２１には、廃棄するパケットのフローエントリが必要数格納される。廃棄するパケットのフローエントリは、前述のパケットの転送を制限する条件である第１規則（ブラックリスト）に対応する。例えば図５に示すように、廃棄テーブル１１２１は、格納されたフローエントリにマッチしたパケットを廃棄（ｄｒｏｐ）する。格納されたフローエントリにマッチしなかったパケットは、パケットタイプテーブル１１２２による選択処理の対象にする。フローエントリに規定する制限情報は、１つのＩＰアドレスであってもよく、或いは、複数のＩＰアドレスを含むネットワークアドレスであってもよい。さらに、宛先ＩＰアドレスや宛先ポート番号、送信元ポート番号、パケット長、パケットタイプ、ＴＣＰ制御フラグ等を適宜組み合わせて規定することによって、攻撃パケットと同じ宛先ＩＰアドレスに送信しようとしている他の一般ユーザの通信を妨げることを抑制することができる。例えば、廃棄テーブル１１２１のフローエントリとして、転送を制限する領域に対応するネットワークアドレスをマッチ条件として規定する。廃棄テーブル１１２１は、そのネットワークアドレスが示すアドレス空間に含まれた送信元ＩＰアドレスが付与されているパケットの転送を制限する。図５に示す「129.168.3.0/24」は、ＩＰｖ４で記述した場合のネットワークアドレスの一例である。
スイッチ部１１２において、廃棄テーブル１１２１には、廃棄するパケットのフローエントリが必要数格納される。廃棄するパケットのフローエントリは、前述のパケットの転送を制限する条件である第１規則（ブラックリスト）に対応する。例えば図５に示すように、廃棄テーブル１１２１は、格納されたフローエントリにマッチしたパケットを廃棄（ｄｒｏｐ）する。格納されたフローエントリにマッチしなかったパケットは、パケットタイプテーブル１１２２による選択処理の対象にする。フローエントリに規定する制限情報は、１つのＩＰアドレスであってもよく、或いは、複数のＩＰアドレスを含むネットワークアドレスであってもよい。さらに、宛先ＩＰアドレスや宛先ポート番号、送信元ポート番号、パケット長、パケットタイプ、ＴＣＰ制御フラグ等を適宜組み合わせて規定することによって、攻撃パケットと同じ宛先ＩＰアドレスに送信しようとしている他の一般ユーザの通信を妨げることを抑制することができる。例えば、廃棄テーブル１１２１のフローエントリとして、転送を制限する領域に対応するネットワークアドレスをマッチ条件として規定する。廃棄テーブル１１２１は、そのネットワークアドレスが示すアドレス空間に含まれた送信元ＩＰアドレスが付与されているパケットの転送を制限する。図５に示す「129.168.3.0/24」は、ＩＰｖ４で記述した場合のネットワークアドレスの一例である。
匿名フラグ設定テーブル１１２７は、匿名アドレスリストを保持しており、匿名アドレスリスト中のいずれかのアドレスに、送信元アドレス又は宛先アドレスが一致するパケットについて匿名フラグＦ２をセットする。匿名アドレスリストは、例えば特定の認定機関の監視装置から要請されたアドレス、使い捨て型で利用される電子メールアドレス、転送履歴情報として残された情報のうち、アドレス詐称（なりすまし）などの疑義が含まれた電子メールの送信元アドレスなどを含めて形成されるものであってもよい。転送履歴情報に疑義が含まれていることの検出の一例は、ＳＭＴＰ（Simple Mail Transfer Protocol）サーバ等の電子メールサーバと、電子メールサーバのＩＰアドレスとドメイン名の対応関係の不整合が挙げられる。なお、匿名アドレスリストには、パケットの送信元又は宛先を特定可能な、ＩＰアドレス、電子メールアドレス、電話番号、アカウント情報、ＵＲＬ、ＵＲＩ、ＵＲＮ、ドメイン名、ＦＱＤＮなどが含まれてもよい。匿名フラグ設定テーブル１１２７は、匿名アドレスリストに基づいた処理を実施しない場合には、廃棄テーブル１１２１による処理の結果を、次段のパケットタイプテーブル１１２２の処理対象にする。
パケットタイプテーブル１１２２は、廃棄テーブル１１２１により廃棄されずに残ったパケットであって、匿名フラグ設定テーブル１１２７により匿名フラグが必要に応じてセットされたパケットと、コントローラから取得したパケットを処理対象のパケットとして、パケットのタイプ毎のフローエントリを格納する。例えば図６に示すように、パケットタイプテーブル１１２２に格納するフローエントリには、ＩＰｖ４のパケットであることを特定するものと、ＩＰｖ６のパケットであることを特定するものと、コントローラ宛に送信するパケットであることを特定するものが含まれる。例えば、パケットタイプテーブル１１２２として、各パケットのタイプに対応するアクションを下記のように定義する。パケットタイプテーブル１１２２は、自ＭＬＢＲ１０宛のＩＣＭＰｖ６（Internet Control Message Protocol for IPv6）、又はＡＲＰ（Address Resolution Protocol）、ＩＣＭＰ（Internet Control Message Protocol）、ＤＨＣＰ（Dynamic Host Configuration Protocol）、ＤＲＰ（Dropping Request Message Protocol）、ＲＩＰ（Routing Information Protocol）、ＯＳＰＦ（Open Shortest Path First）、ＢＧＰ（Border Gateway Protocol）、ＵＰｎＰ（Universal Plug and Play）、ＤＮＳ（Domain Name System）、ＳＩＰ（Session Initiation Protocol）などの通信制御パケットをコントローラ１１１宛のパケット（Ｐａｃｋｅｔ−Ｉｎ）とし、上記を除くＩＰｖ４のパケットをＭＬＢテーブル１１２４による処理の対象にし、上記を除くＩＰｖ６のパケットをＳＣＯＰＥテーブル１１２３による処理の対象にする。上記のＤＲＰは、ＤＲＭに検証データもしくは認証コードを付加した規格である。ＤＲＰの詳細については後述する。パケットタイプテーブル１１２２は、コントローラ１１１宛のパケットのうち、コントローラ１１１による判定結果に基づいて、必要であればＦｌｏｗ−Ｍｏｄにて各テーブルを更新するとともに、他のＭＬＢＲに転送が必要なパケットは、スイッチ部１１２に戻す（Ｐａｃｋｅｔ−Ｏｕｔ）。
ＳＣＯＰＥテーブル１１２３は、パケットタイプテーブル１１２２によりＩＰｖ６のパケットであると特定されたパケットに対し、スコープ（SCOPE）の逸脱有無を判定して当該パケットのルーティングを許可するか否かを特定する。例えば図７に示すように、当該パケットの送信元IPアドレスと宛先IPアドレスが同じスコープ（グローバルアドレス、ユニークローカルアドレス、リンクローカルアドレスなど）に属し、ルーティングを許可すると判定した場合には、ＳＣＯＰＥテーブル１１２３は、当該パケットをＭＬＢテーブル１１２４による処理の対象にする。一方、当該パケットのスコープに逸脱がありルーティングを許可しないと判定した場合には、ＳＣＯＰＥテーブル１１２３は、対象のパケットを廃棄する。
ＭＬＢテーブル１１２４は、パケットタイプテーブル１１２２によりＩＰｖ４のパケットであると特定されたパケット、又は、ＳＣＯＰＥテーブル１１２３によりルーティングを許可するＩＰｖ６のパケットであると特定されたパケットに対し、当該パケットが転送を許可すべきパケットであるか否かを特定する。その特定の条件は第２規則（通信許可ホワイトリスト）に対応する。ＭＬＢテーブル１１２４は、ＩｏＴ装置やホスト等のＭＡＣアドレスとＩＰアドレス及びｅＭＬＢＲ１１の接続ポートの識別情報を組み合わせて、当該パケットが偽装パケットでないかをチェックする通信許可ホワイトリストとして機能するが、ＩｏＴ装置から送信されたパケットであるか否かを判別することもできる。例えば図８Ａ等に示すように、マッチ条件には、スイッチ部１１２の入力ポート番号（IN_Port）、ＩｏＴ装置に割り付けられているＭＡＣアドレスとＩＰアドレスなどが設定される。例えば、当該パケットが、ＩｏＴ装置から送信されたパケットであると判別すると（図８Ａ上段）、ＱｏＳテーブル１１２６（図１０）に遷移し、通信相手として許可された宛先アドレスであるかをＱｏＳテーブル１１２６によって判定し、該当する通信相手許可ホワイトリストがＱｏＳテーブル１１２６に存在した場合、ＱｏＳテーブル１１２６は、当該パケットをルーティングテーブル１１２５による転送処理の対象（図１０上段）にする。なお、図８Ａから図８Ｃは、ＭＬＢテーブル１１２４の一例を示す。図８Ｂと図８Ｃについての詳細は後述する。本実施形態の以下の説明では、図８Ａについて説明する。
さらに、ＭＬＢテーブル１１２４は、転送を許可すべきパケットであると判定されたパケットに対して、第５規則に従って認証フラグＦ１をセットするようにしてもよい（図８Ａ下段を除く各段）。なお、認証フラグＦ１として、認証レベル又は検疫レベルを示すようにしてもよい。本実施形態では、ＭＬＢテーブル１１２４が認証フラグＦ１をセットする場合を例示するが、これに代えて、ＭＬＢテーブル１１２４と別に設けた認証・検疫テーブルがホワイトリストに従って実施するようにしてもよい。認証・検疫テーブルについては後述する。
図９に示すように、ルーティングテーブル１１２５は、ＭＬＢテーブル１１２４（図８Ａ）により当該パケットが偽装されたパケットではないと判定された場合、当該パケットをルーティングテーブル１１２５により規定される物理ポートに出力するのが基本であるが、ルーティングテーブル１１２５によりＩｏＴ装置宛のパケットであることが判明した場合（図９上段）は、ＱｏＳテーブル１１２６（図１０）に遷移し、送信元が該ＩｏＴ装置の通信相手であるか否かを判定し、該当する通信相手許可ホワイトリストが存在した場合に、転送処理の対象にする（図１０中段）。ルーティングテーブル１１２５は、当該パケットが転送すべきパケットでないと特定された場合（図９下段）、当該パケットをルーティングテーブル１１２５の第３規則に従って、廃棄処理の対象にしてもよい。
ＱｏＳテーブル１１２６は、ＭＬＢテーブル１１２４により当該パケットが、ＩｏＴ装置から送信されたパケット、又は、ＩｏＴ装置宛に送信されたパケットであると判定されたパケットに対し、所望のＱｏＳを設定する。ＱｏＳとして設定する条件は、第４規則（通信相手許可ホワイトリスト）に対応する。例えば図１０に示すように、ＱｏＳテーブル１１２６における所望のＱｏＳには、送信元アドレスと宛先アドレスがマッチ条件に一致する場合に、パケットの転送を許可することで、許可される範囲を超えた宛先への転送を制限する（図１０下段）ことが含まれる。
（認証フラグＦ１を利用した認証処理）
通信システム１におけるＭＬＢＲ１０、端末装置１７、データ端末１８などの各装置は、前述の認証フラグＦ１（第１フラグ）を用いて通信することで、通信の接続要求元が認証されていること又は接続要求元から送信されたパケットが検疫されていることを、当該パケットを受信した装置が検出可能になる。認証フラグＦ１に、通信の接続要求に対する判定の結果を反映することにより、パケットを受信した受信端末又は受信エンティティは、認証フラグＦ１の状態に基づいて、パケットを送信した送信元の認証処理及び検疫処理を行うことを間接的に実施することができる。以下の説明において、パケットを受信した受信端末又は受信エンティティのことを、受信端末等ということがある。パケットを受信する側に設けられた端末装置１７、データ端末１８などは、受信端末等の一例である。このような認証フラグＦ１を用いることにより、受信端末におけるパケットの認証処理及び検疫処理による負荷を軽減することができる。以下、その一例について説明する。
通信システム１におけるＭＬＢＲ１０、端末装置１７、データ端末１８などの各装置は、前述の認証フラグＦ１（第１フラグ）を用いて通信することで、通信の接続要求元が認証されていること又は接続要求元から送信されたパケットが検疫されていることを、当該パケットを受信した装置が検出可能になる。認証フラグＦ１に、通信の接続要求に対する判定の結果を反映することにより、パケットを受信した受信端末又は受信エンティティは、認証フラグＦ１の状態に基づいて、パケットを送信した送信元の認証処理及び検疫処理を行うことを間接的に実施することができる。以下の説明において、パケットを受信した受信端末又は受信エンティティのことを、受信端末等ということがある。パケットを受信する側に設けられた端末装置１７、データ端末１８などは、受信端末等の一例である。このような認証フラグＦ１を用いることにより、受信端末におけるパケットの認証処理及び検疫処理による負荷を軽減することができる。以下、その一例について説明する。
ＭＬＢＲ１０により構成されるネットワークＮＷ１では、認証フラグＦ１が付与されたパケットを用いて通信する。例えば、ｅＭＬＢＲ１１は、受信したパケットの認証処理及び検疫処理を実施して、その認証処理及び検疫処理の結果を認証フラグＦ１に反映させる。以下の説明において、認証フラグＦ１がセットされた状態は、パケットを送信した送信元が所定の条件を満たすものである場合を示すものとする。
上述したとおり、ＭＬＢテーブル１１２４は、転送を許可するパケットに対して認証フラグＦ１をセット状態にし、転送を許可しないパケットを廃棄する。
なお、ＭＬＢＲ１０は、認証フラグＦ１が付与されていないパケットを、認証フラグＦ１が付与されたパケットと混在させて通信することができる。その場合、認証フラグＦ１が付与されていないパケットは、認証フラグＦ１がリセット状態と同様の信頼度と判断される。
なお、ＭＬＢＲ１０は、認証フラグＦ１が付与されていないパケットを、認証フラグＦ１が付与されたパケットと混在させて通信することができる。その場合、認証フラグＦ１が付与されていないパケットは、認証フラグＦ１がリセット状態と同様の信頼度と判断される。
図１１は、ＩＰｖ４のパケットヘッダを示す図である。図１１（ａ）に示すように、ＩＰｖ４のパケットヘッダは、バージョン、ヘッダ長、サービス種別（Type of Service（ＴＯＳ））フィールド、全長、識別子、フラグ、断片位置、生存時間、プロトコル、チェックサム、送信元アドレス、宛先アドレス、拡張情報の各フィールドにより構成されている。このパケットヘッダの後に、上位プロトコルにより指定されたデータを割り付けるペイロード部が続く。
図１１（ｂ）に、上記のうちサービス種別フィールドについて示す。サービス種別フィールドにおけるビット配列は、３ビット分の優先度、１ビットずつの遅延度、転送量、信頼性、２ビット分の予備ビット（未使用ビット）がそれぞれ割り付けられている。予備ビットを除く上位６ビットは、ＤＳＣＰ（Differentiated Services Code Point）と呼ばれている。例えば、ＤＳＣＰは、パケットにマーキングすることなどに利用されている。上記は、ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ（Request for Comments）３２６０、ＲＦＣ２４７４、ＲＦＣ２４７５、ＲＦＣ２５９７、ＲＦＣ３２４６等に規定されている。
ここで、本実施形態では、ＩＰｖ４パケットのＩＰパケットヘッダのサービス種別フィールドに、通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納するフラグ（格納部）をＩＥＴＦの規定に干渉しないように設ける。以下、上記の規定において予備ビット（未使用ビット）とされているリソースを、フラグとして利用する事例について説明する。例えば、上記の予備ビットの２ビットに、認証フラグＦ１と、リスクフラグＲＦとをそれぞれ割り付ける。例えば、リスクフラグＲＦは、前述した匿名フラグＦ２と、フラグＦ３と、フラグＦ４の論理和としてもよい。上記のように、本願出願時点の上記の規定において予備ビット（未使用ビット）とされているリソースを利用することで、上記の規定に準じた機能に、本実施形態に示す機能を付加することができる。このようにＩＥＴＦの規定に干渉しないように上記のフラグを割り付けたことにより、本実施形態の比較例のネットワークがＩＥＴＦの規定に準じていれば、比較例のネットワークは、本実施形態のフラグを割り付けたパケットを透過的に転送することができる。つまり、ＭＬＢＲ１０を構成に含むネットワークＮＷ１と、ＭＬＢＲ１０を構成に含まないネットワークＮＷ４とを接続して相互に通信することができる。
ここで、本実施形態では、ＩＰｖ４パケットのＩＰパケットヘッダのサービス種別フィールドに、通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納するフラグ（格納部）をＩＥＴＦの規定に干渉しないように設ける。以下、上記の規定において予備ビット（未使用ビット）とされているリソースを、フラグとして利用する事例について説明する。例えば、上記の予備ビットの２ビットに、認証フラグＦ１と、リスクフラグＲＦとをそれぞれ割り付ける。例えば、リスクフラグＲＦは、前述した匿名フラグＦ２と、フラグＦ３と、フラグＦ４の論理和としてもよい。上記のように、本願出願時点の上記の規定において予備ビット（未使用ビット）とされているリソースを利用することで、上記の規定に準じた機能に、本実施形態に示す機能を付加することができる。このようにＩＥＴＦの規定に干渉しないように上記のフラグを割り付けたことにより、本実施形態の比較例のネットワークがＩＥＴＦの規定に準じていれば、比較例のネットワークは、本実施形態のフラグを割り付けたパケットを透過的に転送することができる。つまり、ＭＬＢＲ１０を構成に含むネットワークＮＷ１と、ＭＬＢＲ１０を構成に含まないネットワークＮＷ４とを接続して相互に通信することができる。
受信端末等は、このように設定された認証フラグＦ１の状態を判定することにより、パケットの通信元である送信端末又は送信エンティティについて間接的に判定して、それを認証することができる。以下の説明において、パケットの通信元である送信端末又は送信エンティティのことを、単に、送信端末等ということがある。パケットを送信する側に設けられた端末装置１７、データ端末１８などは、送信端末等の一例である。
受信端末等は、受信したパケットのパケットヘッダに、ネットワークセキュリティ上のリスクが比較的低いことを示すように認証フラグＦ１が設定されたパケットを選択的に受信する受信手段を備えて構成してもよい。なお、上記のような受信端末等には、ｅＭＬＢＲ１１やファイアウォールなどが含まれる。
（認証フラグＦ１の設定方法）
図１２から図１３を参照して、認証フラグＦ１について説明する。図１２は、認証フラグＦ１の設定に関する条件を示す図である。図１３は、ｅＭＬＢＲ１１における認証フラグＦ１の設定に関する状態遷移図である。
図１２から図１３を参照して、認証フラグＦ１について説明する。図１２は、認証フラグＦ１の設定に関する条件を示す図である。図１３は、ｅＭＬＢＲ１１における認証フラグＦ１の設定に関する状態遷移図である。
ｅＭＬＢＲ１１は、受信したパケットの認証フラグＦ１の状態に依存することなく認証フラグＦ１を設定する。ｅＭＬＢＲ１１は、所定の認証レベル及び／又は検疫レベルを満たした送信端末からのパケットを検出することにより、認証フラグＦ１をセットする。一方、ｅＭＬＢＲ１１は、認証されていない送信端末からのパケットを検出することにより、認証フラグＦ１をリセットする。
（認証フラグＦ１を利用する装置）
認証フラグＦ１を利用する装置として、ｅＭＬＢＲ１１や、ＭＬＢＲ１０以外の装置が挙げられる。認証フラグＦ１のセット状態を検出する用途としては、ｅＭＬＢＲ１１、受信端末等、ファイアウォール等の装置が、パケットを選択して受信する判断基準として利用する用途が挙げられる。認証フラグＦ１のリセット状態を検出する用途としては、ＩＤＳ(Intrusion Detection System)、ＩＰＳ(Intrusion Prevention System)、ＤＰＩ(Deep Packet Inspection)等の装置がサイバー攻撃やサイバー犯罪などのマルウェアなどに汚染もしくは不正パケットかを検査する際に、優先的に検査する信頼度の低いパケットを抽出するための指標として利用する用途が挙げられる。ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置は、受信したパケットの履歴データに、認証フラグＦ１を含めて格納するとよい。ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置への適用例を後述する。
認証フラグＦ１を利用する装置として、ｅＭＬＢＲ１１や、ＭＬＢＲ１０以外の装置が挙げられる。認証フラグＦ１のセット状態を検出する用途としては、ｅＭＬＢＲ１１、受信端末等、ファイアウォール等の装置が、パケットを選択して受信する判断基準として利用する用途が挙げられる。認証フラグＦ１のリセット状態を検出する用途としては、ＩＤＳ(Intrusion Detection System)、ＩＰＳ(Intrusion Prevention System)、ＤＰＩ(Deep Packet Inspection)等の装置がサイバー攻撃やサイバー犯罪などのマルウェアなどに汚染もしくは不正パケットかを検査する際に、優先的に検査する信頼度の低いパケットを抽出するための指標として利用する用途が挙げられる。ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置は、受信したパケットの履歴データに、認証フラグＦ１を含めて格納するとよい。ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置への適用例を後述する。
上記の実施形態によれば、ＭＬＢＲ１０は、パケットにより、ネットワークを介して通信する。ＭＬＢＲ１０は、通信によるネットワークセキュリティ上の信頼度に関する信頼度情報（例えば、認証フラグＦ１とリスクフラグＲＦ）を格納する格納部が、そのパケットのパケットヘッダの所定位置に設けられている。ＭＬＢＲ１０のスイッチ部１１２（信頼度情報設定手段）は、信頼度が不明であることを示す所定値が格納部に格納されたパケットに対し、当該パケットに関する情報に基づいて、当該パケットの信頼度が比較的高いこと、当該パケットが匿名性を有すること、当該パケットのリスクが比較的高いこと、の内から１又は複数を選択して、その選択の結果に基づいて当該パケットの信頼度情報を設定し、又は、上記の信頼度が不明なパケットを選択して、その選択されたパケットの信頼度情報を維持することにより、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信側に通知することが可能になる。
また、ＭＬＢＲ１０は、当該パケットに関する情報に基づいて、ネットワークＮＷにおける所定の信頼度基準を満たす送信元から送信されたパケットの信頼度情報を、第５規則に従い当該パケットの信頼度が比較的高いことを示すように設定してもよい。
また、ＭＬＢＲ１０は、当該パケットに関する情報に基づいて、送信元又は宛先が隠ぺいされたパケットの信頼度情報を、第６規則に従い当該パケットが匿名性を有することを示すように設定してもよい。
また、ＭＬＢＲ１０は、当該パケットに関する情報に基づいて、ネットワークＮＷにおける所定の信頼度基準から外れた送信元から送信されたパケット又は上記の信頼度が不明な送信元から送信されたパケットの信頼度情報が所定値でないパケット又は信頼できないネットワークから転送されてきたパケットの信頼度情報が上記の所定値ではないパケットの信頼度情報を、第６規則に従い当該パケットのリスクが比較的高いことを示すように設定してもよい。
また、ＭＬＢＲ１０は、上記の信頼度が不明な送信元から送信されたパケットの信頼度情報が上記の所定値であるパケット又は信頼できないネットワークから到来したパケットの信頼度情報が上記の所定値であるパケットの信頼度情報を、第５規則と第６規則の何れの条件にも該当しないものとして維持してもよい。
換言すれば、上記の実施形態によれば、所定の信頼度基準を満たす送信元から送信されたパケットの信頼度情報を、前記ネットワークセキュリティ上のリスクが比較的低いことを示すように設定し、送信元又は宛先を隠ぺい又は詐称した、又は感染したマルウェアなどから送信された悪意あるパケットの前記信頼度情報を、前記リスクが比較的高いことを示すように設定することにより、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信側に通知することが可能になる。
例えば、ＭＬＢＲ１０は、通信によるネットワークセキュリティ上のリスクが比較的低いパケットであることを示す認証フラグＦ１が、パケットのパケットヘッダの所定位置に設けられており、認証フラグＦ１が設けられているパケットであって所定の信頼度基準を満たした送信元から送信されたパケットに対しては、上記のリスクが比較的低いことを示すように認証フラグＦ１をセットするスイッチ部１１２（信頼度情報設定手段）を備えるものである。
これにより、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信側に通知することが可能になる。
これにより、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信側に通知することが可能になる。
また、スイッチ部１１２は、認証フラグＦ１として、通信の接続要求元が認証されていること又は接続要求元から送信されたパケットが検疫されていることを示すフラグ（第１フラグ）が設けられ、通信の接続要求に対する判定の結果により、上記フラグの状態を設定するＭＬＢテーブル１１２４を含む。ＭＬＢテーブル１１２４は、第１フラグ設定手段の一例である。
以上に示した認証フラグＦ１を用いることにより、下記のことが実施可能になる。
［１］ＩＤＳやＩＰＳが、認証フラグＦ１が立っていないものから優先的にＤＰＩなどを行うことによって、ＩＤＳやＩＰＳの処理を軽減する。
［２］認証フラグＦ１が立っていないパケットを直ちに受信するのではなく、ＤＰＩを行って異常がないことが確認できた後に、そのパケットを、内部ネットワークないしはコンピュータに取り込む。
［３］要求されるセキュリティレベルが高い組織や、同組織で利用されるシステムでは、認証フラグＦ１が立っていないパケットの受信を拒否し廃棄する。
上記の例に示したように、認証フラグＦ１が立っているか否かによって、そのパケットをどのように処理するかは、受信者側の判断、つまり受信装置等の設定に委ねるものとなる。
［１］ＩＤＳやＩＰＳが、認証フラグＦ１が立っていないものから優先的にＤＰＩなどを行うことによって、ＩＤＳやＩＰＳの処理を軽減する。
［２］認証フラグＦ１が立っていないパケットを直ちに受信するのではなく、ＤＰＩを行って異常がないことが確認できた後に、そのパケットを、内部ネットワークないしはコンピュータに取り込む。
［３］要求されるセキュリティレベルが高い組織や、同組織で利用されるシステムでは、認証フラグＦ１が立っていないパケットの受信を拒否し廃棄する。
上記の例に示したように、認証フラグＦ１が立っているか否かによって、そのパケットをどのように処理するかは、受信者側の判断、つまり受信装置等の設定に委ねるものとなる。
（第１の実施形態の第１変形例）
第１の実施形態の第１変形例について説明する。第１の実施形態では、ＩＰｖ４のパケットによる通信に認証フラグＦ１を利用して、ＭＬＢＲ１０が送信端末等について認証する一例を示した。本変形例では、これに代えて、ＩＰｖ６のパケットによる通信に、認証フラグＦ１を利用して送信端末等について認証する場合の一例について説明する。
第１の実施形態の第１変形例について説明する。第１の実施形態では、ＩＰｖ４のパケットによる通信に認証フラグＦ１を利用して、ＭＬＢＲ１０が送信端末等について認証する一例を示した。本変形例では、これに代えて、ＩＰｖ６のパケットによる通信に、認証フラグＦ１を利用して送信端末等について認証する場合の一例について説明する。
図１４は、ＩＰｖ６のパケットヘッダを示す図である。例えば、図１４に示すように、認証フラグＦ１を、ＩＰｖ６のＩＰｖ６パケットヘッダのトラフィッククラスフィールドの予備ビットに割り当ててもよい。トラフィッククラスフィールドは、送信時のＱｏＳを指定する情報が格納されるが、ＭＬＢＲ１０及び受信端末等は、認証フラグＦ１についてもＱｏＳと同様に処理するとよい。
本変形例によれば、ＩＰｖ６の場合もＩＰｖ４の場合と同様の効果を奏するものになる。
（第１の実施形態の第２変形例）
第１の実施形態の第２変形例について説明する。上記の第１の実施形態では、認証フラグＦ１を利用する場合を例示したが、本変形例では、認証フラグＦ１に加えて、ネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを示すリスクフラグＲＦ(フラグＦ４（第４フラグ）)を利用する場合について例示する。第１の実施形態との相違点を中心に説明する。
第１の実施形態の第２変形例について説明する。上記の第１の実施形態では、認証フラグＦ１を利用する場合を例示したが、本変形例では、認証フラグＦ１に加えて、ネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを示すリスクフラグＲＦ(フラグＦ４（第４フラグ）)を利用する場合について例示する。第１の実施形態との相違点を中心に説明する。
リスクフラグＲＦは、例えば、前述の図１１（ｂ）に示すように、前述の認証フラグＦ１と同様に、ＩＰｖ４のパケットヘッダにおけるサービス種別フィールド内に割り当てられている。図８Ｂに示すように、本変形例のＭＬＢＲ１０では、ＭＬＢテーブル１１２４等によって、認証フラグＦ１とリスクフラグＲＦ(フラグＦ４)の状態を設定する。
上記の第１の実施形態では、ＭＬＢテーブル１１２４は、ＭＬＢテーブルに規定された第３規則から外れたパケットをＩＰアドレスが詐称されたパケットとして廃棄するものとして説明したが、本変形例では、これに代えて、上記のパケットを廃棄せずに、当該パケットのリスクフラグＲＦとしてフラグＦ４をセットしてルーティングテーブル１１２５に転送する（図８Ｂ下段）。
（リスクフラグの設定方法）
図１５から図１６を参照して、リスクフラグＲＦとしてのフラグＦ４について説明する。図１５は、フラグＦ４の設定に関する条件を示す図である。図１６は、ＭＬＢＲ１０におけるフラグＦ４の設定に関する状態遷移図である。
図１５から図１６を参照して、リスクフラグＲＦとしてのフラグＦ４について説明する。図１５は、フラグＦ４の設定に関する条件を示す図である。図１６は、ＭＬＢＲ１０におけるフラグＦ４の設定に関する状態遷移図である。
ＭＬＢＲ１０は、各ＭＬＢテーブルに設定された第３規則から外れたパケットを検出することによりフラグＦ４をセットする。一方、ＭＬＢＲ１０は、上記以外のパケットを検出しても、フラグＦ４をセットすることはなく、上記の条件に該当しなければフラグＦ４の状態を保持して、パケットを転送する。
このようにＭＬＢテーブル１１２４などを構成することにより、上記のようにＭＬＢテーブル１１２４の廃棄条件に該当するパケットはＭＬＢＲ１０によって廃棄されなくなり、当該パケットの処理を受信端末等の処理に委ねることが可能になる。
上記の場合、受信端末毎に異なる処理を実施させることが可能になり、一律に廃棄する場合と異なる運用を実現することが可能になる。
本変形例によれば、通信によるネットワークセキュリティ上のリスクが比較的低いパケットであることを示す認証フラグＦ１と、リスクがある又はリスクが比較的高いパケットであることを示すリスクフラグＲＦの少なくとも何れかが、当該パケットのパケットヘッダの所定位置に設けられている。例えば、スイッチ部１１２は、ＭＬＢテーブル１１２４により、認証フラグＦ１が設けられているパケットであって所定の信頼度基準を満たした送信元から送信されたパケットに対してはそのリスクが比較的低いことを示すように認証フラグＦ１を設定し、リスクフラグＲＦが設けられているパケットであって送信元又は宛先を隠ぺい又は詐称したパケットに対しては、そのリスクがある又はリスクが比較的高いことを示すようにリスクフラグＲＦ(フラグＦ４)を設定してもよい。なお、上記のＭＬＢテーブル１１２４による第３規則に基づいたパケットの判定を、例えば、ｕＲＰＦ（unicast Reverse Path Forwarding）の処理により実現してもよい。
（第２の実施形態）
第２の実施形態について説明する。第１の実施形態では、ｅＭＬＢＲ１１が、認証フラグＦ１の状態を設定する場合を例示したが、本実施形態では、これに加えて、ｉＭＬＢＲ１２及びｂＭＬＢＲ１３が、認証フラグＦ１の状態を設定、又は、変更する場合について例示する。
第２の実施形態について説明する。第１の実施形態では、ｅＭＬＢＲ１１が、認証フラグＦ１の状態を設定する場合を例示したが、本実施形態では、これに加えて、ｉＭＬＢＲ１２及びｂＭＬＢＲ１３が、認証フラグＦ１の状態を設定、又は、変更する場合について例示する。
第１の実施形態で示したようにｅＭＬＢＲ１１によって設定された認証フラグＦ１の状態が、受信端末等まで転送される間に書き換えられてしまうと、認証フラグＦ１が示す状態を信頼できなくなるリスクがある。このようなリスクを回避するために、例えば、そのパケットの中継経路で、不正な書き換えが行われ得る状態が検出された場合には、当該パケットに認証フラグＦ１がセットされていても、その状態をリセットするとよい。
図１７は、ｉＭＬＢＲ１２とｂＭＬＢＲ１３における認証フラグＦ１の設定に関する状態遷移図である。ＭＬＢＲ１０は、通信に先立ってＭＬＢＲ１０間の認証処理を実施する。
前述の図１２に示すように、ｉＭＬＢＲ１２は、ｅＭＬＢＲ１１−ｉＭＬＢＲ１２間のメッセージ認証に失敗した状態を、認証フラグＦ１の不正な書き換えが行われ得る状態と判定する。ｉＭＬＢＲ１２は、上記の状態を検出すると、そのパケットを、不正なパケットと見做して、そのパケットの認証フラグＦ１をリセットする。なお、ｉＭＬＢＲ１２は、認証フラグＦ１をセットすることはなく、上記の条件に該当しなければ、その認証フラグＦ１の状態を保持して、パケットを転送する。
また、ｂＭＬＢＲ１３は、ｉＭＬＢＲ１２−ｂＭＬＢＲ１３間、及び、ｂＭＬＢＲ１３−ｂＭＬＢＲ１３間のメッセージ認証に失敗した状態を、認証フラグＦ１の不正な書き換えが行われ得る状態と判定する。ｂＭＬＢＲ１３は、上記の状態を検出すると、そのパケットを、不正なパケットと見做して、そのパケットの認証フラグＦ１をリセットする。なお、ｂＭＬＢＲ１３は、認証フラグＦ１をセットすることはなく、上記の条件に該当しなければ、その認証フラグＦ１の状態を保持して、パケットを転送する。
このように、受信端末等は、認証フラグＦ１がリセットされたパケットを受信することにより、そのパケットの信頼度が、少なくとも認証フラグＦ１がセットされたパケットと同様の信頼度を有するものではなく、所望の信頼度を満たすものではないということを検出できる。
（第３の実施形態）
第３の実施形態について説明する。上記の各実施形態では、認証フラグＦ１を利用する場合を例示したが、本実施形態では、これに代えて、認証フラグＦ１（第１フラグ）と匿名フラグＦ２（第２フラグ）とを利用する場合について例示する。第１の実施形態との相違点を中心に説明する。
第３の実施形態について説明する。上記の各実施形態では、認証フラグＦ１を利用する場合を例示したが、本実施形態では、これに代えて、認証フラグＦ１（第１フラグ）と匿名フラグＦ２（第２フラグ）とを利用する場合について例示する。第１の実施形態との相違点を中心に説明する。
本実施形態のＭＬＢＲ１０は、認証フラグＦ１と匿名フラグＦ２とを利用する。例えば、ｅＭＬＢＲ１１のスイッチ部１１２は、ＭＬＢテーブル１１２４が認証フラグＦ１を設定し、匿名フラグ設定テーブル１１２７が匿名フラグＦ２を設定する。認証フラグＦ１と匿名フラグＦ２は、前述の図４における認証フラグＦ１とリスクフラグＲＦと同様に割り付けてもよい。
図１８は、匿名フラグＦ２の設定に関する条件を示す図である。図１９は、匿名フラグＦ２の設定に関する状態遷移図である。
匿名フラグ設定テーブル１１２７には、少なくとも自身が管理するアドレス空間内の匿名アドレスリスト等が設定されている。匿名フラグ設定テーブル１１２７は、受信した処理対象のパケットに、接続経路を隠ぺいするようにパケットの送信元ＩＰアドレス又は宛先ＩＰアドレスが設定されていることを検出し、その検出の結果により、上記に該当するパケットである場合（＜Ｆ２ＳＥＴ＞）に、匿名フラグＦ２をセットする。一方、匿名フラグ設定テーブル１１２７は、上記以外のパケットを検出しても、匿名フラグＦ２をセットすることはなく、上記の条件に該当しなければ匿名フラグＦ２の状態を保持して、パケットを転送する。
通信システム１の受信端末等は、上記の匿名フラグＦ２を参照して、匿名フラグＦ２がセットされたパケットを、送信元又は宛先を隠ぺい又は詐称したパケットであると判定し、ネットワークセキュリティ上のリスクがある又はリスクが比較的高いものとして扱ってもよい。
上記の実施形態の受信装置等は、受信したパケットのパケットヘッダに、認証フラグＦ１がリセットされてネットワークセキュリティ上のリスクが比較的低いと判定できないパケットと、匿名フラグがセットされて上記のリスクがある又はリスクが比較的高いと判定されるパケットの一方又は両方を選択的に検査するパケット検査手段を備えて構成してもよい。受信装置等は、受信したパケットのパケットヘッダに、認証フラグＦ１がセットされ、ネットワークセキュリティ上のリスクが比較的低いと判定されるパケットと、匿名フラグがセットされ、上記のリスクがある又はリスクが比較的高いと判定されるパケットの一方又は両方を選択的に検査するパケット検査手段を備えて構成してもよい。
上記の実施形態によれば、スイッチ部１１２は、リスクフラグＲＦとして、接続経路を隠ぺいするようにパケットの送信元ＩＰアドレス又は宛先ＩＰアドレスが設定されたパケットであることを示す匿名フラグＦ２を当該パケットに設定する匿名フラグ設定テーブル１１２７を含む。これにより、通信システム１は、認証フラグＦ１と匿名フラグＦ２とを利用する場合においても、パケットの検査を容易に実施することができる。
この匿名フラグＦ２を利用することにより、下記の特徴を有する通信であることを、受信端末等が容易に検出することが可能になる。例えば、受信端末等は、通信の接続経路を匿名化する技術（プログラム）を利用する通信であることを検出する。通信の接続経路を匿名化する技術の一例として、Ｔｏｒ（The Onion Router,トーア）規格が知られている。Ｔｏｒ規格のクライアントとして機能する端末装置は、Ｔｏｒ規格の通信サービスを提供するＴｏｒサーバに対して通信の接続開始を要求し、Ｔｏｒサーバにより許可されると、そのＴｏｒサーバを介して目的の通信相手宛にパケットを送信する。上記の端末装置は、このような手順を踏み通信することで接続経路を隠ぺい化することができる。
図３１は、Ｔｏｒネットワークを構成するノードのアドレスリストの一例を示す図である。２０１６年の時点で、すでに７０００個を超えるノードが登録されており、図示する範囲は、その一部である。同図に示すように、各ノードのＩＰアドレス（ip）、ノードの名称（name）、ルータのポート（router-port）、ディレクトリポート（directory-port）、フラグ（flags）、稼働時間（uptime）、バージョン（version）、連絡先（contactinfo）等の情報が掲載されている。
例えば、信頼を置ける認定機関の監視装置から定期的又は更新が為された時点で、上記の図に示すアドレスリストの全部又は変更部分の情報が、特定の認証機関から管理ホスト１５等に配信される。管理ホスト１５は、配信されたノードのアドレスリストから匿名アドレスリストを生成して、当該匿名アドレスリストを収容するＭＬＢＲ１０に通知する。ＭＬＢＲ１０のコントローラは、通知を受けた匿名アドレスリストを、第６記憶部１１５６等に書き込むとともに、スイッチ部１１２の匿名フラグ設定テーブル１１２７に登録する。これによって、匿名フラグ設定テーブル１１２７は、匿名アドレスリストに該当するアドレスを持つパケットについて、その匿名フラグＦ２またはリスクフラグＲＦをセットする。
上記の手順で送信され、目的の通信相手に届いたパケットを解析しても、接続経路が匿名化されており、その解析結果から、パケットの送信元や接続経路などを得ることができない。通信相手に届いたパケットに限らず、中継区間で傍受されたとしても、そのパケットの送信元や接続経路などを容易に得ることはできない。
上記のとおり匿名フラグＦ３を用いることにより、接続経路を隠ぺい化した匿名アドレスを送信元ＩＰアドレスあるいは宛先ＩＰアドレスに用いているかを示すことを可能とする。
比較例として、他のアドレス偽装パケットなどと同様に扱って遮断又は廃棄する場合がある。この場合、上記の匿名アドレスを用いたパケットまでも、遮断又は廃棄することになりうる。
これに対し、本実施形態によれば、匿名アドレスを用いたパケットを遮断又は廃棄することなく通信させることができる。また、リスクフラグＲＦを匿名フラグＦ３として利用したことで下記のことが可能になる。
［１］リスクフラグＲＦが立っているパケットは、リスクが比較的高いことを明示的に示すものである。このことから、善良なユーザの多くは、ファイアウォールのフィルタレベルの設定によって、そのパケットの受信を拒否して直ちに廃棄することができる。
［２］人権擁護団体サイトなどでは、人権擁護に係る情報提供を匿名で実施する可能性がある。このような通信に用いられるアドレスには、匿名アドレスが用いられていることがある。上記の通信を受信する場合には、パケットの受信を直ちに拒否するのではなく、ｅＭＬＢＲ１１などを用いて判定するとよい。例えば、ｅＭＬＢＲ１１は、当該パケットを、まずスイッチ部１１２等により特定のポートに出力してＤＰＩにかける。ＤＰＩにより、「マルウェアに感染していないこと」、「サイバー攻撃やサイバー犯罪に係るパケットでないこと」などを確認した後に、内部ネットワーク或いは端末装置１７などのコンピュータに取り込むとよい。上記の「サイバー攻撃やサイバー犯罪に係るパケット」の特定は、例えば、過去にサイバー攻撃やサイバー犯罪に悪用されたことがある又は偽装されたアカウント情報やＵＲＬ、ＵＲＩ、ＵＲＮ、ドメイン名、ＦＱＤＮなどによって行ってもよい。
［３］特異な例であるが、サイバー攻撃や犯罪に加担するサイトであれば、リスクフラグが立っているパケットを積極的に受信して、ボットネットやマルウェアに感染したＩｏＴ機器、あるいは遠隔操作しているＰＣ宛の指令メッセージをＣ＆Ｃサーバにアップするなどの動作を行うことがあり得る。このような場合も、上記のパケットを受信するか否かは受信者側の判断に委ねることになる。ただし、仮に、上記のようなサイバー攻撃や犯罪に加担するサイトが存在していたとしても、本実施形態であれば、同サイトの認証又は検疫の結果から、同サイトから送信されたパケットは、認証フラグＦ１も匿名フラグＦ２もセットされないパケットになる。その結果、当該パケットを受信した受信端末等はそのパケットの信頼度レベルを容易に検知できる。
上記のとおり、認証フラグＦ１と匿名フラグＦ２とでは、それぞれのフラグが示す性質や、受信端末等における扱いが異なるものとなる。認証フラグＦ１や、リスクフラグＲＦとしての匿名フラグＦ２の状態をいかに用いるかが受信者側の判断に委ねられることになっても、上記のとおり、本実施形態であれば、通信システム１により機能するネットワークＮＷの秩序を高めることに貢献することが可能になる。
なお、通信システム１は、リスクフラグＲＦとして、匿名アドレスＦ２のほかに、アドレス偽装パケットを示す場合にセットするフラグを論理和として加えて、リスクフラグＲＦがアドレス偽装パケットの全てを示すようにしてもよい。
接続経路を隠ぺい化する技術には、Ｔｏｒ規格の他に、Ｉ２Ｐ（The Invisible Internet Project）などのネットワークがある。これらについても認定機関の監視装置が隠ぺい化するネットワークであることを検知し次第、同様の方法で管理ホスト１５などに通知する。管理ホスト１５は、検出されたＩ２Ｐなどの情報を匿名アドレスリストに追加し、当該匿名アドレスを収容するＭＬＢＲ１０又は各ＭＬＢＲ１０に通知して、少なくとも当該匿名アドレスを収容するＭＬＢＲ１０の匿名フラグ設定テーブルに登録させる。ＭＬＢＲ１０は、上記の通知に応じて匿名フラグ設定テーブルを更新して、上記の該当するアドレスを持つパケットの匿名フラグＦ２またはリスクフラグＲＦをセットすればよい。
（第３の実施形態の第１変形例）
第３の実施形態の第１変形例について説明する。上記の第３の実施形態では、接続経路を隠ぺいするようにパケットの送信元ＩＰアドレス又は宛先ＩＰアドレスが設定されていることをパケットレベルで検出する場合を例示したが、本変形例では、これに代えて、或いは、これに加えて、送信元又は宛先を隠ぺいするようにメール又はメッセージを送る場合について例示する。第３の実施形態との相違点を中心に説明する。なお、本変形例は、ネットワークＮＷ２に接続されたサーバ装置ＳＶ（図１）が上位プロトコルレベルでメール又はメッセージを転送する場合に対応する。
第３の実施形態の第１変形例について説明する。上記の第３の実施形態では、接続経路を隠ぺいするようにパケットの送信元ＩＰアドレス又は宛先ＩＰアドレスが設定されていることをパケットレベルで検出する場合を例示したが、本変形例では、これに代えて、或いは、これに加えて、送信元又は宛先を隠ぺいするようにメール又はメッセージを送る場合について例示する。第３の実施形態との相違点を中心に説明する。なお、本変形例は、ネットワークＮＷ２に接続されたサーバ装置ＳＶ（図１）が上位プロトコルレベルでメール又はメッセージを転送する場合に対応する。
例えば、その通信の送信元メールアドレスと、宛先メールアドレスと、電話番号又はアカウント情報又はＵＲＬ又はＵＲＩ又はＵＲＮ又はドメイン名又はＦＱＤＮとの何れかが隠ぺい化、匿名化、又は詐称されたメール又はメッセージであることが判明したものについては、それを送る各パケットのパケットヘッダに、上記の判明結果を示すフラグＦ３を設定する。例えば、サーバ装置ＳＶは、上記のフラグＦ３を、匿名フラグに代えて構成してもよい。つまり、サーバ装置ＳＶは、通信がメール又はメッセージを送るものである場合に、リスクフラグＲＦとしてフラグＦ３（第３フラグ）を設定する設定手段（第３フラグ設定手段）を含むものである。第３フラグ設定手段は、通信の送信元メールアドレスと、宛先メールアドレスと、電話番号又はアカウント情報又はＵＲＬ又はＵＲＩ又はＵＲＮ又はドメイン名又はＦＱＤＮとの何れかが隠ぺい化、匿名化、又は詐称されたものである場合に、当該パケットにフラグＦ３をセットする。
上記のように、変形例のサーバ装置ＳＶ（通信装置）であれば、受信装置等に、フラグＦ３がセットされているメッセージを受信させることにより、そのメッセージにネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを、受信装置等におけるパケットレベルの処理で検出させることができる。なお、本変形例のサーバ装置ＳＶは、端末装置１７などの形態として構成されていてもよい。
（第３の実施形態の第２変形例）
第３の実施形態の第２変形例について説明する。上記の第３の実施形態では、匿名フラグ設定テーブル１１２７により匿名フラグＦ２を設定する場合を例示したが、本変形例では、これに代えて、或いは、これに加えて、ＭＬＢテーブル１１２４（第４フラグ設定手段）によりフラグＦ４（第４フラグ）を設定する場合について例示する。第３の実施形態との相違点を中心に説明する。
第３の実施形態の第２変形例について説明する。上記の第３の実施形態では、匿名フラグ設定テーブル１１２７により匿名フラグＦ２を設定する場合を例示したが、本変形例では、これに代えて、或いは、これに加えて、ＭＬＢテーブル１１２４（第４フラグ設定手段）によりフラグＦ４（第４フラグ）を設定する場合について例示する。第３の実施形態との相違点を中心に説明する。
本変形例のＭＬＢＲ１０は、匿名フラグＦ２とフラグＦ４のいずれかを利用することで、受信端末等がパケットを受信した際に、そのパケットにネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを提示する。例えば、ＭＬＢＲ１０は、匿名フラグＦ２とフラグＦ４とをパケットヘッダ内の共通のビット（リスクフラグＲＦ）に割り付ける。この場合、ＭＬＢＲ１０は、判定対象のパケットに、匿名フラグＦ２とフラグＦ４の少なくとも何れかがセットされる条件を満たしていれば、スイッチ部１１２がリスクフラグＲＦをセットして、そのパケットにネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを示す。
上記のように、変形例のＭＬＢＲ１０（通信装置）であれば、受信装置等に、匿名フラグＦ２とフラグＦ４の少なくとも何れかがセットされているパケットを受信させることにより、そのパケットにネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを、受信装置等におけるパケットレベルの処理で検出させることができる。
（第３の実施形態の第３変形例）
第３の実施形態の第３変形例について説明する。上記の第３の実施形態と上記の各変形例では、匿名フラグ設定テーブル１１２７により匿名フラグＦ２を設定する場合、サーバ装置ＳＶ（図１）がフラグＦ２を設定する場合、ＭＬＢテーブル１１２４によりフラグＦ４を設定する場合などの場合について例示したが、本変形例では、上記の匿名フラグＦ２、フラグＦ３、フラグＦ４の何れも共通のビットに割り付ける場合について例示する。第３の実施形態との相違点を中心に説明する。
第３の実施形態の第３変形例について説明する。上記の第３の実施形態と上記の各変形例では、匿名フラグ設定テーブル１１２７により匿名フラグＦ２を設定する場合、サーバ装置ＳＶ（図１）がフラグＦ２を設定する場合、ＭＬＢテーブル１１２４によりフラグＦ４を設定する場合などの場合について例示したが、本変形例では、上記の匿名フラグＦ２、フラグＦ３、フラグＦ４の何れも共通のビットに割り付ける場合について例示する。第３の実施形態との相違点を中心に説明する。
本変形例の通信システム１では、匿名フラグＦ２とフラグＦ３とフラグＦ４のいずれかをセットすることにより、受信端末等がパケットを受信した際に、そのパケットにネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを提示可能にする。例えば、ＭＬＢＲ１０は、匿名フラグＦ２とフラグＦ４とをパケットヘッダ内の共通のビット（リスクフラグＲＦ）に割り付ける。この場合、ＭＬＢＲ１０は、判定対象のパケットに、匿名フラグＦ２とフラグＦ４の少なくとも何れかがセットされる条件を満たしていれば、スイッチ部１１２がリスクフラグＲＦをセットして、そのパケットにネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを示すことができる。
さらには、前述の第３の実施形態の第１変形例に示したように、フラグＦ３をセットする条件を満たしていれば、サーバ装置ＳＶが、リスクフラグＲＦをセットして、そのパケットにネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを示すことができる。
上記のようにリスクフラグＲＦがセットされているパケットを、受信装置等に検出させることにより、受信装置等は、リスクフラグＲＦの状態から、そのパケットにネットワークセキュリティ上のリスクがある又はリスクが比較的高いことを検出することができる。例えば、ＭＬＢＲ１０は、受信したパケットのパケットヘッダにリスクがある又はリスクが比較的高いことを示すようにリスクフラグＲＦが設定されたパケットを廃棄するか、又は、特定のポートから出力するようにスイッチ部１１２等が制御してもよい。
（第４の実施形態）
第４の実施形態について説明する。上記の各実施形態では、送信端末等が送信したパケットが、受信端末等宛にそのまま中継される場合を例示したが、本実施形態では、これに代えて、転送経路の一部に、送信端末等が送信したパケットと異なるパケットで、先のパケットで送信された情報が転送される場合について例示する。
第４の実施形態について説明する。上記の各実施形態では、送信端末等が送信したパケットが、受信端末等宛にそのまま中継される場合を例示したが、本実施形態では、これに代えて、転送経路の一部に、送信端末等が送信したパケットと異なるパケットで、先のパケットで送信された情報が転送される場合について例示する。
図２０は、本実施形態の通信システム１の概略構成図である。図２０には、通信システム１に含まれる２つのｅＭＬＢＲ１１がネットワークを介して対称になるように設けられている。
ｅＭＬＢＲ１１は、コントローラ１１１Ａと、スイッチ部１１２Ａと、スイッチ部１１２Ｂと、ＩＦ部１１３と、ＩＦ部１１４と、記憶部１１５を備える。前述のｅＭＬＢＲ１１との相違点を中心に説明する。
スイッチ部１１２Ａは、端末装置のプロトコルスタックに対応するプロトコルスタックを含み、レイヤ２からレイヤ４までのプロトコルを処理する。スイッチ部１１２Ｂは、ネットワーク側のプロトコルスタックに対応するプロトコルスタックを含み、レイヤ２からレイヤ３までのプロトコルを処理する。例えば、スイッチ部１１２Ｂは、スイッチ部１１２Ａから出力される第１パケットに基づいて、新たに第２パケットを生成して、ネットワーク側に出力させる。コントローラ１１１Ａは、前述のコントローラ１１１の機能に加え、スイッチ部１１２Ａとスイッチ部１１２Ｂの双方を制御する。
本実施形態の通信システム１では、図２０の左側の端末装置１７（送信端末）から、同図右側の端末装置１７（受信端末）宛にパケットを送付する場合を例示して、その時の各部の処理について説明するが、双方向の通信を可能とする。
このように構成されるＭＬＢＲ１０を利用して、「トンネリング」、「フラグメント」、「暗号化」などの機能を実現してもよい。以下、トンネリングについて説明する。
「トンネリング」は、送信側中継ノードが受信した第１パケットを、送信側中継ノードから受信側中継ノード宛に送信する第２パケットに代えて送信する一手段である。
図２１は、「トンネリング」の概要を示すための図である。例えば、図２１（ａ）はＭＡＣヘッダ（ＭＡＣＡ）を含むＭＡＣフレームを示す。第１パケットは、ＭＡＣフレームに割り当てられ、ＩＰパケットヘッダ（パケットヘッダＰＨＡ）とペイロード（ＰＬＤＡ）により構成される。図２１（ｂ）はＭＡＣヘッダ（ＭＡＣＢ）を含むＭＡＣフレームを示す。ＭＡＣフレームには、第２パケットが割り当てられ、第２パケットは、ＩＰパケットヘッダ（パケットヘッダＰＨＢ）とペイロードにより構成される。
「トンネリング」処理は、上記の第１パケットを第２パケットのペイロード内に割り付けて転送するという標準的な手順に従い実施可能である。本実施形態のｅＭＬＢＲ１１は、それに加えて、認証フラグＦ１とリスクフラグＲＦの処理が附加される。以下、その相違点を中心に説明する。
図２２は、「トンネリング」処理における認証フラグＦ１とリスクフラグＲＦの処理を説明するための図である。
送信側のｅＭＬＢＲ１１は、送信端末からパケットＰＡを受信する。ｅＭＬＢＲ１１は、受信したパケットＰＡを、パケットＰＢのペイロードに割り付けてカプセル化する。その際、ｅＭＬＢＲ１１は、パケットＰＡのパケットヘッダＰＨＡから各フラグの状態を抽出し、パケットＰＢのパケットヘッダＰＨＢに引き継ぐ。上記のより具体的な処理の一例を示す。スイッチ部１１２Ａは、第１パケットのパケットヘッダＰＨＡから認証フラグＦ１とリスクフラグＲＦを抽出し、抽出された認証フラグＦ１とリスクフラグＲＦの状態を、スイッチ部１１２Ｂに引き継ぐ。スイッチ部１１２Ｂは、スイッチ部１１２Ａから引き継がれた認証フラグＦ１とリスクフラグＲＦの状態に基づいて第２パケットを生成して、出力する。
一方、受信側のｅＭＬＢＲ１１は、ネットワーク側からパケットＰＢを受信して、受信したパケットＰＢを、デカプセル化してパケットＰＡを再生する。その際、ｅＭＬＢＲ１１は、パケットＰＢのパケットヘッダＰＨＢから各フラグの状態を抽出し、パケットＰＡのパケットヘッダＰＨＡに引き継ぐ。上記のより具体的な処理の一例を示す。スイッチ部１１２Ｂは、第２パケットのパケットヘッダＰＨＢから認証フラグＦ１とリスクフラグＲＦを抽出し、抽出された認証フラグＦ１とリスクフラグＲＦの状態を、スイッチ部１１２Ａに引き継ぐ。スイッチ部１１２Ａは、スイッチ部１１２Ｂから引き継がれた認証フラグＦ１とリスクフラグＲＦの状態に基づいて第１パケットを生成して、出力する。
上記の実施形態によれば、通信システム１は、スイッチ部１１２Ａとスイッチ部１１２Ｂは、受信した第１パケットから、当該第１パケットの認証フラグＦ１とリスクフラグＲＦとを抽出し、当該受信した第１パケットをトンネリングさせる通信の第２パケットのパケットヘッダに反映させることができる。
（第４の実施形態の第１変形例）
第４の実施形態の第１変形例について説明する。上記の第４の実施形態では、トンネリングを利用する場合について例示したが、本変形例では、フラグメントを利用する場合について例示する。第４の実施形態との相違点を中心に説明する。
第４の実施形態の第１変形例について説明する。上記の第４の実施形態では、トンネリングを利用する場合について例示したが、本変形例では、フラグメントを利用する場合について例示する。第４の実施形態との相違点を中心に説明する。
「フラグメント」は、送信側中継ノードが受信した第１パケットのデータ長さが、送信側中継ノードから受信側中継ノード宛に送信する第２パケットで許容されるデータ長さより長い場合に利用される一手段である。
図２３は、「フラグメント」の概要を示すための図である。例えば、図２３（ａ）はＭＡＣヘッダ（ＭＡＣＡ）を含むＭＡＣフレームを示す。第１パケットは、ＭＡＣフレームに割り当てられ、ＩＰパケットヘッダ（パケットヘッダＰＨＡ）とペイロード（ＰＬＤＡ）により構成される。図２３（ｂ）はＭＡＣヘッダ（ＭＡＣＢ）を含む複数のＭＡＣフレームを示す。１つ目のＭＡＣフレームには、１つ目の第２パケットが割り当てられ、１つ目の第２パケットは、ＩＰパケットヘッダ（パケットヘッダＰＨＢ）とペイロードＰＬＤＡ１により構成される。同様に２つ目のＭＡＣフレームには、２つ目の第２パケットが割り当てられ、２つ目の第２パケットは、ＩＰパケットヘッダ（パケットヘッダＰＨＢ）とペイロードＰＬＤＡ２により構成される。
「フラグメント」処理は、例えば、上記の第１パケットのデータが所定の長さに分割され、各第２パケットのペイロード内にそれぞれ割り付けられて転送されるという標準的な処理で実施される。本実施形態のｅＭＬＢＲ１１は、それに加えて、認証フラグＦ１とリスクフラグＲＦの処理が附加される。以下、その相違点を中心に説明する。
図２４は、「フラグメント」処理における認証フラグＦ１とリスクフラグＲＦの処理を説明するための図である。
送信側のｅＭＬＢＲ１１は、送信端末からパケットＰＡを受信する。ｅＭＬＢＲ１１は、受信したパケットＰＡのペイロード部のデータを複数に分割し、複数のパケットＰＢのペイロードに、分割したデータを順に割り付ける。その際、ｅＭＬＢＲ１１は、パケットＰＡのパケットヘッダＰＨＡから、認証フラグＦ１とリスクフラグＲＦの各フラグの状態を抽出し、各パケットＰＢのパケットヘッダＰＨＢに引き継ぐ。
一方、受信側のｅＭＬＢＲ１１は、受信した複数のパケットＰＢのペイロードからデータを抽出し、抽出したデータを結合してパケットＰＡを再生する。その際、ｅＭＬＢＲ１１は、代表するパケットＰＢのパケットヘッダＰＨＢから各フラグの状態を抽出し、パケットＰＡのパケットヘッダＰＨＡに引き継ぐ。
上記の変形例によれば、通信システム１は、スイッチ部１１２Ａとスイッチ部１１２Ｂは、受信した第１パケットから、当該第１パケットの認証フラグＦ１とリスクフラグＲＦとを抽出し、当該受信した第１パケットを分割して送信する第２パケットのパケットヘッダに反映させることができる。
（第４の実施形態の第２変形例）
第４の実施形態の第２変形例について説明する。上記の第４の実施形態では、トンネリングを利用する場合について例示したが、本変形例では、トンネリングモードの暗号化通信を利用する場合について例示する。第４の実施形態との相違点を中心に説明する。
第４の実施形態の第２変形例について説明する。上記の第４の実施形態では、トンネリングを利用する場合について例示したが、本変形例では、トンネリングモードの暗号化通信を利用する場合について例示する。第４の実施形態との相違点を中心に説明する。
トンネリングモードの「暗号化通信」は、中継区間の一部又は全部で、第１パケットのデータ、或いは、第１パケットそのものを秘匿して第２パケットを生成し、第２パケットとして転送する場合に利用される一手段である。
図２５は、「暗号化通信」の概要を示すための図である。例えば、図２５（ａ）はＭＡＣヘッダ（ＭＡＣＡ）を含むＭＡＣフレームを示す。第１パケットは、ＭＡＣフレームに割り当てられ、ＩＰパケットヘッダ（パケットヘッダＰＨＡ）とペイロード（ＰＬＤＡ）により構成される。図２５（ｂ）はＭＡＣヘッダ（ＭＡＣＢ）を含むＭＡＣフレームを示す。ＭＡＣフレームには、第２パケットが割り当てられ、第２パケットは、ＩＰパケットヘッダ（パケットヘッダＰＨＢ）と、ＡＨ（Authentication Header）と、ペイロードとにより構成される。
「暗号化通信」処理は、例えば、上記の第１パケットは、第２パケットのペイロード内に暗号化されて割り付けられて転送されるという標準的な処理で実施される。本実施形態のｅＭＬＢＲ１１は、それに加えて、認証フラグＦ１とリスクフラグＲＦの処理が附加される。以下、その相違点を中心に説明する。
図２６は、トンネリングモードの「暗号化通信」処理における認証フラグＦ１とリスクフラグＲＦの処理を説明するための図である。
送信側のｅＭＬＢＲ１１は、送信端末からパケットＰＡを受信する。ｅＭＬＢＲ１１は、受信したパケットＰＡを暗号化して、パケットＰＢのペイロードに割り付けてカプセル化する。その際、ｅＭＬＢＲ１１は、パケットＰＡのパケットヘッダＰＨＡから、認証フラグＦ１とリスクフラグＲＦの各フラグの状態を抽出し、パケットＰＢのパケットヘッダＰＨＢに引き継ぐ。
一方、受信側のｅＭＬＢＲ１１は、受信したパケットＰＢにカプセル化されたデータを復号化して、パケットＰＡを再生する。その際、ｅＭＬＢＲ１１は、パケットＰＢのパケットヘッダＰＨＢから各フラグの状態を抽出し、パケットＰＡのパケットヘッダＰＨＡに引き継ぐ。
上記の変形例によれば、通信システム１は、スイッチ部１１２Ａとスイッチ部１１２Ｂは、受信した第１パケットから、当該第１パケットの認証フラグＦ１とリスクフラグＲＦとを抽出し、当該受信した第１パケットを暗号化して送信する第２パケットのパケットヘッダに反映させることができる。
なお、上記に示した以外にも、暗号化の方式には幾つかの方式がある。それらのうちから他の方式を適宜選択できる。
（第４の実施形態の第３変形例）
第４の実施形態の第３変形例について説明する。上記の第４の実施形態では、トンネリングを利用する場合について例示したが、本変形例では、トランスポートモードの暗号化通信を利用する場合について例示する。第４の実施形態との相違点を中心に説明する。
第４の実施形態の第３変形例について説明する。上記の第４の実施形態では、トンネリングを利用する場合について例示したが、本変形例では、トランスポートモードの暗号化通信を利用する場合について例示する。第４の実施形態との相違点を中心に説明する。
トランスポートモードの「暗号化通信」は、中継区間の一部又は全部で、第１パケットのデータ、或いは、第１パケットそのものを秘匿して第２パケットを生成し、第２パケットとして転送する場合に利用される一手段である。
図２７は、トランスポートモードの「暗号化通信」処理における認証フラグＦ１とリスクフラグＲＦの処理を説明するための図である。
送信側のｅＭＬＢＲ１１は、送信端末からパケットＰＡを受信する。ｅＭＬＢＲ１１は、受信したパケットＰＡのペイロード部を暗号化して、パケットＰＢのペイロードに割り付けてカプセル化する。その際に、ｅＭＬＢＲ１１は、パケットＰＡのパケットヘッダＰＨＡを抽出し、パケットＰＢのパケットヘッダＰＨＢに引き継ぐ。上記により、間接的に、パケットＰＡのパケットヘッダＰＨＡの各フラグの状態が、パケットＰＢのパケットヘッダＰＨＢに引き継がれる。
一方、受信側のｅＭＬＢＲ１１は、受信したパケットＰＢにカプセル化されたデータを復号化して、パケットＰＡを再生する。その際、ｅＭＬＢＲ１１は、パケットＰＢのパケットヘッダＰＨＢを抽出し、パケットＰＡのパケットヘッダＰＨＡに引き継ぐ。上記により、間接的に、パケットＰＢのパケットヘッダＰＨＢの各フラグの状態が、パケットＰＡのパケットヘッダＰＨＡに引き継がれる。
上記の変形例によれば、通信システム１は、スイッチ部１１２Ａとスイッチ部１１２Ｂは、受信した第１パケットから、当該第１パケットの認証フラグＦ１とリスクフラグＲＦとを抽出し、当該受信した第１パケットを暗号化して送信する第２パケットのパケットヘッダに反映させることができる。
（第４の実施形態の第４変形例）
第４の実施形態の第４変形例について説明する。上記の第４の実施形態では、ＭＬＢＲ１０による転送処理について例示したが、本変形例では、サーバ装置ＳＶによる転送処理について例示する。第４の実施形態との相違点を中心に説明する。
第４の実施形態の第４変形例について説明する。上記の第４の実施形態では、ＭＬＢＲ１０による転送処理について例示したが、本変形例では、サーバ装置ＳＶによる転送処理について例示する。第４の実施形態との相違点を中心に説明する。
サーバ装置ＳＶによる「上位プロトコルによる転送」は、受信した第１パケットから抽出された上位プロトコルのデータを、第２パケットを利用して転送する場合に利用される一手法である。
図２８は、「上位プロトコルによる転送」の概要を示すための図である。例えば、図２８（ａ）はＭＡＣヘッダ（ＭＡＣＡ）を含むＭＡＣフレームを示す。第１パケットは、ＭＡＣフレームに割り当てられ、ＩＰパケットヘッダ（パケットヘッダＰＨＡ）とペイロード（ＰＬＤＡ）により構成される。図２８（ｂ）はＭＡＣヘッダ（ＭＡＣＢ）を含むＭＡＣフレームを示す。ＭＡＣフレームには、第２パケットが割り当てられ、第２パケットは、ＩＰパケットヘッダ（パケットヘッダＰＨＢ）と、ペイロード（ＰＬＤＡ）とにより構成される。サーバ装置ＳＶは、第１パケットのデータを、第１のパケットと異なる第２パケットに含めて転送する。
「上位プロトコルによる転送」は、ＭＬＢＲ１０に代えて、例えば、上位プロトコルの処理を実施するサーバ装置ＳＶ等により実施される。より具体的な形態を例示すれば、プロキシサーバ、電子メールを中継するメールサーバ、チャットサービス、ショートメッセージサービス、音声通話サービスを提供するＳＮＳサーバなどが挙げられる。
上記の各サーバ装置は、受信した第１パケットの認証フラグＦ１とリスクフラグＲＦの状態を第２パケットに引き継ぎつつ、第１パケットのデータを含む第２パケットを生成する。
（第５の実施形態）
第５の実施形態について説明する。第１の実施形態では、ＭＬＢテーブル１１２４等が認証フラグＦ１を設定する場合を例示したが、本実施形態では、これに代えて、認証・検疫テーブルが認証フラグＦ１を設定する場合について例示する。以下、相違点を中心に説明する。
第５の実施形態について説明する。第１の実施形態では、ＭＬＢテーブル１１２４等が認証フラグＦ１を設定する場合を例示したが、本実施形態では、これに代えて、認証・検疫テーブルが認証フラグＦ１を設定する場合について例示する。以下、相違点を中心に説明する。
図２９は、本実施形態のｅＭＬＢＲ１１を示す図である。スイッチ部１１２は、各段のフローテーブルとして、廃棄テーブル１１２１、パケットタイプテーブル１１２２、ＳＣＯＰＥテーブル１１２３、ＭＬＢテーブル１１２４、ルーティングテーブル１１２５、ＱｏＳテーブル１１２６、匿名フラグ設定テーブル１１２７、及び認証・検疫テーブル１１２８を備える。
本実施形態の場合、第５規則はスイッチ部１１２内の認証・検疫テーブル１１２８に、第６規則はスイッチ部１３２内の匿名フラグ設定テーブル１１２７に、登録され、パケットの転送を制御する。
本実施形態のＭＬＢテーブル１１２４を図８Ｃに示す。上述のとおり、ＭＬＢテーブル１１２４は、認証フラグＦ１の設定を実施せずに、ルーティングテーブル１１２５への転送等を実施する。本実施形態における認証フラグＦ１は下記する通りである。
本実施形態の場合、第５規則はスイッチ部１１２内の認証・検疫テーブル１１２８に、第６規則はスイッチ部１３２内の匿名フラグ設定テーブル１１２７に、登録され、パケットの転送を制御する。
本実施形態のＭＬＢテーブル１１２４を図８Ｃに示す。上述のとおり、ＭＬＢテーブル１１２４は、認証フラグＦ１の設定を実施せずに、ルーティングテーブル１１２５への転送等を実施する。本実施形態における認証フラグＦ１は下記する通りである。
認証・検疫テーブル１１２８は、匿名フラグ設定テーブル１１２７により匿名フラグＦ２が設定されたパケットに対し、第５規則に従う所定の条件を満たす場合に認証フラグＦ１をセットする。所定の条件とは、所定の信頼度基準を満たした送信元を選択するための認証済送信元情報（認証リスト）として生成される。認証・検疫テーブル１１２８の一例を図３０に示す。
例えば、認証・検疫テーブル１１２８は、認証リストに一致する送信元ＩＰアドレスのパケットに対し、認証フラグＦ１をセットして、パケットタイプテーブルに送る（図３０上段）。認証・検疫テーブル１１２８は、認証リストに一致しない送信元ＩＰアドレスのパケットに対し、認証フラグＦ１をリセットして、パケットタイプテーブルに送る（図３０下段）。
例えば、認証・検疫テーブル１１２８は、認証リストに一致する送信元ＩＰアドレスのパケットに対し、認証フラグＦ１をセットして、パケットタイプテーブルに送る（図３０上段）。認証・検疫テーブル１１２８は、認証リストに一致しない送信元ＩＰアドレスのパケットに対し、認証フラグＦ１をリセットして、パケットタイプテーブルに送る（図３０下段）。
通信システム１では、上記の所定の信頼度基準を、必要とされる認証レベルに設定してもよい。例えば、認証レベルの高い例としては、IEEE802.1X認証において、サプリカント（非認証ノード）と認証サーバとが相互にデジタル証明書を交換するＥＡＰ−ＴＬＳ（Extensible Authentication Protocol−Transport Layer Security）がある。次いで、サプリカント側がユーザ名とパスワードを使用し、認証サーバ側がデジタル証明書を使用する、ＥＡＰ−ＴＴＬＳ（Tunneled Transport Layer Security）やＥＡＰ−ＰＥＡＰ（Protected Extensible Authentication Protocol）がある。上記の他に、認証サーバ側にデジタル証明書を必要とせず、サプリカントはユーザ名とパスワードで認証を行うＥＡＰ−ＭＤ５（Message digest algorithm 5）やＥＡＰ−ＬＥＡＰ（Lightweight Extensible Authentication Protocol）、ＥＡＰ−ＦＡＳＴなどがある。
また、今後の認証技術の進歩とともに指紋認証や声紋認証、顔認証、手書き認証などの、いわゆるバイオ認証（生体認証）技術を用いた、より高度でかつ不正し難い認証方法が一般に利用されるようになる。通信システム１では、これらのより高度でかつ不正し難い認証方法を、より高い認証レベルの判定に適用してもよい。
また、通信システム１は、検疫レベルとして、例えばMicrosoft社（登録商標）のＮＡＰ(Network Access Protection)（登録商標）やCisco Systems社（登録商標）のＮＡＣ（network admission control）（登録商標）などの検疫ソフトウェアに見られるような手法を利用してもよい。検疫ソフトウェアでは、当該コンピュータのＯＳやウイルス検知ソフト、ファイアウォール、Adobe社（登録商標）のAcrobat Reader（登録商標）のように広く利用されているパッケージソフトウェアなどの更新履歴情報や設定状態（設定情報）を利用している。上記と同様にそれら情報を利用して、検疫レベルとして、ＯＳやパッケージソフトウェアなどの更新履歴情報や設定状態（設定情報）をもとにしたレベル分けを適用してもよい。
その一方で、ＩｏＴ機器などのデータ端末１８などのIEEE802.1X認証機能を持たない機器については、その機器に異常が認められず、かつ、当該機器が、ＭＬＢテーブル１１２４と通信相手許可（ＱｏＳ）テーブル１１２６の少なくとも何れかに該当するパケットを送信している場合に、認証フラグＦ１をセットするようにしてもよい。上記のＩｏＴ機器などのデータ端末１８に異常が認められない状態とは、例えば、ＡＲＰリフレクションなどの簡易認証やＮｍａｐなどのポートスキャナ、ウイルス検知ソフトなどを用いた簡易認証・検疫の結果が良好な場合とする。
本実施形態の場合、コントローラ１１１が、スイッチ部１１２によって受信されたパケットに対する処理を実施するのに先立って、匿名フラグ設定テーブル１１２７により匿名フラグＦ２が設定され、さらに、認証・検疫テーブル１１２８により認証フラグＦ１が設定される。つまし、コントローラ１１１自身が、スイッチ部１１２によって設定された認証フラグＦ１と匿名フラグＦ２を利用して処理することができる。
例えば、コントローラ１１１がＤＲＭの処理をする場合に、そのＤＲＭを送信した端末装置などの認証処理を、認証フラグＦ１を利用して実施することができる。アドレス詐称（なりすまし）された端末装置から送られたＤＲＭを廃棄することが容易になる。
例えば、コントローラ１１１がＤＲＭの処理をする場合に、そのＤＲＭを送信した端末装置などの認証処理を、認証フラグＦ１を利用して実施することができる。アドレス詐称（なりすまし）された端末装置から送られたＤＲＭを廃棄することが容易になる。
（リスクフラグＲＦを利用する装置）
リスクフラグＲＦを利用する装置として、ＭＬＢＲ１０や、ＭＬＢＲ１０以外の装置が挙げられる。リスクフラグＲＦのセット状態を検出する用途としては、ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置が信頼度の低いパケットを抽出するための指標として利用する用途が挙げられる。ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置は、受信したパケットの履歴データに、リスクフラグＲＦを含めて格納するとよい。ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置への適用例を後述する。
リスクフラグＲＦを利用する装置として、ＭＬＢＲ１０や、ＭＬＢＲ１０以外の装置が挙げられる。リスクフラグＲＦのセット状態を検出する用途としては、ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置が信頼度の低いパケットを抽出するための指標として利用する用途が挙げられる。ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置は、受信したパケットの履歴データに、リスクフラグＲＦを含めて格納するとよい。ＩＤＳ、ＩＰＳ、ＤＰＩ等の装置への適用例を後述する。
（第６の実施形態）
第６の実施形態について説明する。第１から第５の実施形態では、ＩＰｖ４のパケットヘッダのサービス種別フィールドにおける予備ビット（未使用ビット）を、信頼度情報を示すフラグとして利用する事例について説明した。本実施形態では、これに代えて、同サービス種別フィールドにおける未定義コード（未使用コード）を信頼度情報として利用する事例について説明する。以下、第１から第５の実施形態、及び、それらの変形例等との相違点を中心に説明する。
第６の実施形態について説明する。第１から第５の実施形態では、ＩＰｖ４のパケットヘッダのサービス種別フィールドにおける予備ビット（未使用ビット）を、信頼度情報を示すフラグとして利用する事例について説明した。本実施形態では、これに代えて、同サービス種別フィールドにおける未定義コード（未使用コード）を信頼度情報として利用する事例について説明する。以下、第１から第５の実施形態、及び、それらの変形例等との相違点を中心に説明する。
本実施形態においても、ＩＰｖ４のパケットへの適用を例示して説明する。ＩＰｖ４のパケットヘッダのサービス種別フィールドに、通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部を設ける。前述の図１１（ｂ）に示すように、サービス種別フィールドの上位６ビットは、ＤＳＣＰとして利用されている。
図３２は、サービス種別フィールドに割り当てられたＤＳＣＰにについて説明するための図である。この図３２に示すＤＳＣＰの各コードは、前述のＲＦＣ３２６０、ＲＦＣ２４７４、ＲＦＣ２５９７、ＲＦＣ３２４６等において規定されているものである。このように、ＤＳＣＰに割り付けられたコードは、６ビットで表すことができるコードの全てではなく、その一部に限られる。
ここで、本実施形態では、上記の規定においてＤＳＣＰとして割り当てられていない未定義コードを利用する事例について説明する。本実施形態では、ＩＥＴＦの規定に干渉しないように未定義コードを利用することにより、比較例のネットワークがＩＥＴＦの規定に準じていれば、比較例のネットワークであっても、本実施形態のコードを割り付けたパケットを透過的に転送することが可能になる。つまり、ネットワークＮＷ１とネットワークＮＷ４とを接続して相互に通信することができる。
例えば、ＭＬＢＲ１０のスイッチ（信頼度情報設定手段）、例えば、ｅＭＬＢＲ１１のスイッチ部１１２は、所定の信頼度基準を満たす送信元から送信されたパケットの信頼度情報を、ネットワークセキュリティ上の信頼度が比較的高いこと（リスクが比較的低いこと）を示すように設定し、送信元又は宛先を隠ぺい又は詐称したパケットの前記信頼度情報を、そのリスクが比較的高いことを示すように設定する。
本実施形態における信頼度情報には、信頼度が不明なパケット、信頼度が高いパケット、送信元又は宛先を隠ぺい又は詐称したパケット（例えば、匿名アドレスを利用するパケット）、及び明白な不正なパケットのうちの少なくとも何れかに対応付けられた情報が含まれる。
例えば、ＭＬＢＲ１０のスイッチ部１１２は、受信したパケットの信頼度情報を参照して、そのパケットの信頼度情報を識別する。スイッチ部１１２は、その識別の結果に基づいて、当該パケットの転送、転送の制限、検疫、ＱＯＳ制御など通信処理と、通信処理のための管理に関する各種処理を実施する。スイッチ部１１２は、その処理の結果に基づいて、当該パケットを所望の経路に出力する。
例えば、スイッチ部１１２は、受信したパケットの信頼度情報を参照して、そのパケットの信頼度が不明なパケットであると判定した場合には、そのパケットの信頼度情報を維持してもよい。例えば、ＤＳＣＰに割り付けるコードの値を「＊＊＊＊＊０」に定める。「＊」は、「０」または「１」の何れかである。５個の「＊」で示す上位の５ビットについて、スイッチ部１１２は、パケットに設定されているコードの上位５ビットと同じ値にして、下位１ビットを「０」にする。このコードの値は、ＤＳＣＰとして既定されているコードの値と同じものになる。スイッチ部１１２は、この値が設定されているパケットを、所定の信頼度レベルを満たさないものと判定する。上記のコードは、第１の実施形態に示した「認証フラグＦ１」と「匿名フラグＦ２」とをリセットした状態（０）に対応する。例えば、上記のコード「＊＊＊＊＊０」が選択される場合は、第１の実施形態等に示した「認証フラグＦ１」をリセットして、「リスクフラグＦＲ」をセットした状態に対応させてもよい。
なお、信頼度の検証がなされていないネットワークＮＷ４等の比較例のネットワーク上であれば、この値に設定されたパケットは、これまでとパケットと同様に扱うことができる。つまり、このコードに設定されたパケットが、パケットの信頼度を管理しないネットワークから到来した場合、又は、信頼度が不明な端末装置から到来した場合には、ＭＬＢＲ１０のスイッチは、そのパケットの信頼度情報を変更することにより、信頼度の検証がなされていない信頼度が不明なパケットとして扱うことができる。例えば、上記と異なるコードが設定されたパケットであっても、当該パケットの信頼度が不明であると判定した場合には、スイッチ部１１２は、ＤＳＣＰ（コードの値「＊＊＊＊＊１」）の下位１ビットを反転して、コードの値を「＊＊＊＊＊０」に変更する。スイッチ部１１２は、そのコードを当該パケットの信頼度情報として設定する。
また、スイッチ部１１２は、信頼度が高いパケットの信頼度情報を、当該パケットの信頼度が高いことを示す第１のコード（第１の所定の情報）の情報に変更してもよい。例えば、ＤＳＣＰに割り付けるコードの値を「＊＊＊＊＊１」と定める。ＤＳＣＰにおける上位の５ビットは、既に定められているコードの上位５ビットと同じ値にする。この値は、上記のコード「＊＊＊＊＊０」とは異なり、既に定められているコードの何れにも当てはまらない。なお、上記のコード「＊＊＊＊＊１」が選択される場合は、例えば、第１の実施形態等に示した「認証フラグＦ１」をセットして、「リスクフラグＦＲ」又は「匿名フラグＦ２」をリセットした状態に対応する。
スイッチ部１１２は、上記のコード「＊＊＊＊＊１」に設定されているパケットを、所定の信頼度レベルを満たすものと判定する。なお、この値に設定されたパケットは、ネットワークＮＷ４のように一般的な通信プロトコルが適用された比較例のネットワークでは、ＤＳＣＰの上位５ビットを参照することで、これまでと同様のパケットとして扱うことができる。また、ＤＳＣＰの下位１ビットを参照することで、その値が「１」であることから、所定の信頼度レベルを満たすパケットであることを識別できる。
また、スイッチ部１１２は、当該パケットのパケットヘッダに含まれている送信元又は宛先アドレスが、隠ぺい又は詐称したアドレス（例えば、匿名アドレス等）を利用するパケットの信頼度情報を、送信元又は宛先の匿名性を示す第２のコード（第２の所定の情報）に変更してもよい。例えば、ＤＳＣＰに割り付けるコードの値を「＊＊＊１１１」と定める。ＤＳＣＰの上位の３ビットは、既に定められているコードの上位３ビットと同じ値にする。なお、下位３ビットに規定されているコードには、「１１１」が含まれていない。つまり、コード「＊＊＊１１１」は、既知のＤＳＣＰの各コードとは異なり、それらのコードの何れにも当てはまらない。なお、上記のコード「＊＊＊１１１」が選択される場合は、例えば、第１の実施形態等に示した「認証フラグＦ１」をリセットして、「リスクフラグＦＲ」をセットした状態に対応する。上記の「リスクフラグＦＲ」をセットした状態は、例えば、第３の実施形態に示した「匿名フラグＦ２」をセットした状態、または、第３の実施形態の第２変形例に示した「フラグＦ４」をセットした状態を含む。
スイッチ部１１２は、ＤＳＣＰが上記のコード「＊＊＊１１１」に設定されているパケットを、隠ぺい又は詐称したアドレス（匿名アドレス等）を利用するパケットであると判定する。
なお、ＤＳＣＰが上記のコード「＊＊＊１１１」に設定されたパケットは、比較例のネットワークでは、ＤＳＣＰとして規定されているコードを利用して、当該パケットを転送することができる。つまり、ＤＳＣＰに「１１１」が設定されていること以外は、これまでと同様のパケットとして扱うことができる。
なお、当該パケットを受信した端末装置は、受信したパケットにおいて、ＤＳＣＰの下位３ビットを参照してもよい。例えば、端末装置は、受信したパケットのＤＳＣＰの下位３ビットがコード「１１１」であれば、「そのパケットが、隠ぺい又は詐称したアドレス（匿名アドレス等）を利用したパケットである。」と既に判定されていることを識別できる。
また、下記のようなパケットは、明らかな不正なパケットとして扱うようにしてもよい。例えば、明らかな不正なパケットには、その信頼度情報が規定外の情報に設定されているパケット、所定の認証条件を満たしていないパケット、及び、前記パケットの信頼度が補償されない通信経路を経て到来したものであると判定されたパケットなどが含まれる。明白な不正なパケットは、上記のうちの何れかであってよい。この場合、スイッチ部１１２は、明白な不正なパケットの信頼度情報を、当該パケットが明白な不正なパケットであると判定し、これを示す第３のコード（第３の所定の情報）に変更してもよい。
以下、より具体的な適用例について説明する。ＭＬＢＲ１０は、上記の通り、ｅＭＬＢＲ１１と、ｉＭＬＢＲ１２と、ｂＭＬＢＲ１３に大別される。ｅＭＬＢＲ１１と、ｉＭＬＢＲ１２と、ｂＭＬＢＲ１３は、受信したパケットに対する処理などが互いに異なる。
例えば、ネットワークＮＷ１内のｅＭＬＢＲ１１と、ｉＭＬＢＲ１２と、ｂＭＬＢＲ１３は、前述の図１に示すように接続されている。ｅＭＬＢＲ１１は、ユーザが利用する端末装置を収容し、ｉＭＬＢＲ１２に接続されている。さらに、ｅＭＬＢＲ１１は、比較例のネットワーク（不図示）としてのノード（不図示）に接続されていてもよい。ｉＭＬＢＲ１２は、ｅＭＬＢＲ１１、他のｉＭＬＢＲ１２、ｂＭＬＢＲ１３等に接続されている。ｂＭＬＢＲ１３は、当該ネットワーク（ネットワークＮＷ１）内でｉＭＬＢＲ１２、他のｂＭＬＢＲ１３等に接続されており、他のネットワークと接続されている。
以下、ｅＭＬＢＲ１１と、ｉＭＬＢＲ１２と、ｂＭＬＢＲ１３とに分けて、パケットに対する信頼度情報の設定処理について説明する。なお、以下の説明における「認証・検疫レベル」を５段階とし、その値が「１」である場合に、最も信頼度が低い状態にあり、その値が「５」である場合に、最も信頼度が高い状態にあるとする。
（ｅＭＬＢＲ１１）
図３３は、ｅＭＬＢＲ１１が信頼度情報に基づいて通信制御を実施する処理を示すための図である。
ｅＭＬＢＲ１１は、端末装置等から受信したパケットの信頼度が不明な場合には、そのパケットのＤＳＣＰのＬＳＢ（下位ビット）を「０」にする。ただし、パケットをｅＭＬＢＲ１１に送信した直前の通信ノードからのパケット、または、ユーザが利用する端末装置の認証・検疫レベルが「２〜４」の端末装置からのパケットのＤＳＣＰのＬＳＢが０であれば、ｅＭＬＢＲは、そのパケットのＤＳＣＰのＬＳＢ（ＤＳＣＰのコード）を変更しない。
図３３は、ｅＭＬＢＲ１１が信頼度情報に基づいて通信制御を実施する処理を示すための図である。
ｅＭＬＢＲ１１は、端末装置等から受信したパケットの信頼度が不明な場合には、そのパケットのＤＳＣＰのＬＳＢ（下位ビット）を「０」にする。ただし、パケットをｅＭＬＢＲ１１に送信した直前の通信ノードからのパケット、または、ユーザが利用する端末装置の認証・検疫レベルが「２〜４」の端末装置からのパケットのＤＳＣＰのＬＳＢが０であれば、ｅＭＬＢＲは、そのパケットのＤＳＣＰのＬＳＢ（ＤＳＣＰのコード）を変更しない。
ｅＭＬＢＲ１１は、端末装置等から受信した信頼できるパケットについては、そのパケットのＤＳＣＰのＬＳＢを「１」に設定する。例えば、パケットをｅＭＬＢＲ１１に送信した直前のノード、または、ユーザが利用する端末装置の認証・検疫レベルが「５」である場合、ｅＭＬＢＲ１１は、そのパケットのＤＳＣＰのＬＳＢを「１」にする。
ｅＭＬＢＲ１１は、パケットの送信元ＩＰアドレスが匿名フラグ設定テーブル１１２７に存在する場合、パケットのＤＳＣＰを「７」に設定する。
ｅＭＬＢＲ１１は、端末装置等から受信した明白な不正パケットについては、ＤＳＣＰに「６３」を設定する。
例えば、ｅＭＬＢＲ１１は、下記の処理を実施する。
（１）ｅＭＬＢＲ１１に収容しているノード（但し、ｉＭＬＢＲ１２を除く）から送信されたパケットのＤＳＣＰのＬＳＢが「１」である場合、ｅＭＬＢＲ１１は、そのパケットを不正パケットとして扱うように、そのパケットにおけるＤＳＣＰを「６３」に設定する。
（１）ｅＭＬＢＲ１１に収容しているノード（但し、ｉＭＬＢＲ１２を除く）から送信されたパケットのＤＳＣＰのＬＳＢが「１」である場合、ｅＭＬＢＲ１１は、そのパケットを不正パケットとして扱うように、そのパケットにおけるＤＳＣＰを「６３」に設定する。
つまり、ＭＬＢＲ１０がＤＳＣＰに信頼度情報として設定するコードを、各パケットのＤＳＣＰに設定する権限は、原則としてｅＭＬＢＲ１１のみに制限する。このように制限することにより、ｅＭＬＢＲ１１に収容しているノードなどは、その設定に関する権限がなく、当該ノードから送信するパケットに、そのＤＳＣＰのＬＳＢに「１」を設定することはできない。ｅＭＬＢＲ１１は、このようなパケットを、明白な不正パケットであると識別する。
（２）パケットをｅＭＬＢＲ１１に送信した直前のノード（但し、ｉＭＬＢＲ１２を除く）、及び、ユーザが利用する端末装置の認証・検疫レベルが「１」である場合、又は感染したマルウェアなどから送信された悪意あるパケットである場合、ｅＭＬＢＲは、そのパケットを不正パケットとして扱うように、そのパケットにおけるＤＳＣＰを「６３」に設定する。
（３）ｅＭＬＢＲ１１が収容している端末装置（ノード）から送信されたパケットの認証処理（以下、ＡＨ検証という。）に失敗した場合、ｅＭＬＢＲ１１は、そのパケットを不正パケットとして扱うように、そのパケットにおけるＤＳＣＰを「６３」に設定する。
なお、ｅＭＬＢＲの処理ではないが、実施形態の各端末装置（ノード）は、下記の機能を有することを推奨する。端末装置１７とデータ端末１８は、端末装置（ノード）の一例である。端末装置（ノード）がパケットの送信にマルウェアが関与していることを検知した場合、当該端末装置（ノード）は、ＡＨをパケットに付加せずに、または、認証に失敗したことを示すためＡＨをパケットに付加せずに送信するようにしてもよい。端末装置（ノード）がＡＨを利用して通信することにより、後述するように端末装置（ノード）とｅＭＬＢＲ１１との間の通信の信頼度を高めることができる。
（ｉＭＬＢＲ１２）
図３４は、ｉＭＬＢＲ１２が信頼度情報に基づいて通信制御を実施する処理を示すための図である。
ｉＭＬＢＲ１２は、ｅＭＬＢＲ１１または端末装置等から受信したパケットの信頼度が不明な場合には、そのパケットのＤＳＣＰのＬＳＢ（下位ビット）を「０」にする。ただし、ｉＭＬＢＲ１２は、ｅＭＬＢＲ１１から送られてきたパケットのＡＨ検証に成功した場合、そのパケットのＤＳＣＰのＬＳＢを変更しない。
図３４は、ｉＭＬＢＲ１２が信頼度情報に基づいて通信制御を実施する処理を示すための図である。
ｉＭＬＢＲ１２は、ｅＭＬＢＲ１１または端末装置等から受信したパケットの信頼度が不明な場合には、そのパケットのＤＳＣＰのＬＳＢ（下位ビット）を「０」にする。ただし、ｉＭＬＢＲ１２は、ｅＭＬＢＲ１１から送られてきたパケットのＡＨ検証に成功した場合、そのパケットのＤＳＣＰのＬＳＢを変更しない。
ｅＭＬＢＲ１１から送られてきたパケットのＡＨ検証に成功した場合、ｉＭＬＢＲ１２は、そのパケットのＤＳＣＰを変更しない。
ｉＭＬＢＲ１２は、匿名アドレスを利用するパケットについては、そのパケットのＤＳＣＰを「７」に設定する。例えば、匿名アドレスを利用するノードを収容している場合、ｉＭＬＢＲ１２は、その匿名アドレスパケットのＤＳＣＰを「７」に設定する。
ｉＭＬＢＲ１２は、明白な不正パケットについては、そのパケットのＤＳＣＰを「６３」に設定する。例えば、収容しているノードから送信されたパケットのＡＨ検証に失敗した場合、ｉＭＬＢＲ１２は、そのパケットを不正パケットとして扱うように、そのパケットにおけるＤＳＣＰを「６３」にする。
（ｂＭＬＢＲ１３）
図３５は、ｂＭＬＢＲ１３が信頼度情報に基づいて通信制御を実施する処理を示すための図である。
ｂＭＬＢＲ１３は、受信したパケットの信頼度が不明な場合には、そのパケットのＤＳＣＰのＬＳＢ（下位ビット）を「０」にする。ｂＭＬＢＲ１３は、ＭＬＢＲ１０の未導入ネットワークから送られてきたパケットのＤＳＣＰのＬＳＢが０であれば、そのＬＳＢを変更しない。
図３５は、ｂＭＬＢＲ１３が信頼度情報に基づいて通信制御を実施する処理を示すための図である。
ｂＭＬＢＲ１３は、受信したパケットの信頼度が不明な場合には、そのパケットのＤＳＣＰのＬＳＢ（下位ビット）を「０」にする。ｂＭＬＢＲ１３は、ＭＬＢＲ１０の未導入ネットワークから送られてきたパケットのＤＳＣＰのＬＳＢが０であれば、そのＬＳＢを変更しない。
ｂＭＬＢＲ１３は、ＭＬＢＲ１０の既導入ネットワークから送られてきたパケットについては、そのパケットにおけるＤＳＣＰを変更しない。
ｂＭＬＢＲ１３は、未導入ネットワークから送られてきた匿名アドレスを利用するパケットについては、そのパケットのＤＳＣＰを「７」に設定する。例えば、逆行経路内に一又は複数の匿名化ノードが存在する場合、ｂＭＬＢＲ１３は、当該ノードのアドレスを予め匿名フラグ設定テーブルに保持し、受信したパケットの送信元アドレスが匿名フラグ設定テーブルに存在した場合、パケットのＤＳＣＰを「７」に設定する。
ｂＭＬＢＲ１３は、ＭＬＢＲ１０の未導入ネットワーク等から受信した明白な不正パケットについては、そのパケットのＤＳＣＰを「６３」に設定する。例えば、ＭＬＢＲ１０の未導入ネットワークから送られてきたパケットのＬＳＢが「１」である場合、ｂＭＬＢＲ１３は、そのパケットを不正パケットとして扱うように、そのパケットにおけるＤＳＣＰを「６３」にする。
上記の実施形態によれば、第１の実施形態と同様の効果を奏することの他、ＩＰｖ４のサービス種別フィールドを利用して、同サービス種別フィールドにおける未定義コード（未使用コード）を信頼度情報として利用することにより、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信側に通知することが可能になる。
また、信頼度情報には、信頼度が不明なパケット、信頼度が高いパケット、送信元又は宛先を隠ぺい又は詐称したパケット、及び明白な不正なパケットのうちの少なくとも何れかに対応付けられた情報が含まれていてもよい。これにより、パケットの信頼度に基づいて、当該パケットを識別することができる。
また、ＭＬＢＲ１０のスイッチ（信頼度情報設定手段）は、信頼度が不明なパケットの信頼度情報を維持して、当該パケットを転送してもよい。これにより、信頼度の判定が困難なパケットを、信頼度が高いパケットと異なる分類で転送することができる。
また、ＭＬＢＲ１０のスイッチは、信頼度が高いパケットの信頼度情報を、当該パケットの信頼度が高いことを示す第１の所定の情報に変更してもよい。これにより、信頼度が高いパケットに、それを識別するための情報を付加することができる。
また、ＭＬＢＲ１０のスイッチは、送信元又は宛先を隠ぺい又は詐称したパケットの前記信頼度情報を、送信元又は宛先の匿名性を示す第２の所定の情報に変更してもよい。これにより、送信元又は宛先を隠ぺい又は詐称したパケットに、それを識別するための情報を付加することができる。
また、明白な不正なパケットは、信頼度情報が規定外の情報に設定されているパケット、所定の認証条件を満たしていないパケット、及び、パケットの信頼度が補償されない通信経路を経て到来したものであると判定されたパケットのうちの何れかであってもよい。その場合、ＭＬＢＲ１０のスイッチは、明白な不正なパケットの前記信頼度情報を、当該パケットが明白な不正なパケットであることを示す第３の所定の情報に変更してもよい。これにより、明白な不正なパケットに、それを識別するための情報を付加することができる。
なお、上記の信頼度情報のＤＳＣＰの設定を、ＭＬＢＲ１０のスイッチ部が実施するものとして説明したが、これに制限されず、ＭＬＢＲ１０内に設けられた機能部であって、スイッチ部と連携する機能部（不図示）、又はＭＬＢＲ１０に連携して機能する装置（不図示）が実施してもよい。例えば、ＤＳＣＰの設定において、ＤＳＣＰの値をＭＬＢＲ１０が変更する場合、ＩＰパケットヘッダのチェックサムも計算し直すことになる。とりわけ１００Ｇｂｐｓや４００Ｇｂｐｓなどの高速のインタフェースを持つｂＭＬＢＲ１３では、流入するすべてのパケットについて、ＤＳＣＰが適正か否か、すなわちＬＳＢが「１」になっていないかをチェックし、不適切であればＤＳＣＰを「６３」に書き換えるとともに、チェックサムを再計算する。これは、悪意ある複数のノードからＬＳＢを「１」にセットした不正パケットを大量に送り付けられれば、ｂＭＬＢＲ１３には過大な処理負荷がかかることを意味する。これについては、例えば、ｂＭＬＢＲ１３が、スイッチ部１３２内、又はスイッチ部１３２の外部に、ハードウエアによるチェックサム計算処理モジュールを内蔵している所謂ＮｅｔＦＰＧＡや専用のチェックサム計算処理チップを備えていれば、それらを利用してもよい。あるいは、ｂＭＬＢＲ１３は、ＬＳＢが１のパケットを検出したら、所定のポートからｂＭＬＢＲ１３に付帯して設けられたパケット処理装置（不図示）に転送し、そのパケット処理装置によりＤＳＣＰの書き換えとチェックサムを再計算してからｂＭＬＢＲ１３に戻す。上記のパケット処理装置は、通信装置の一例である。
なお、このパケット処理装置を、ＩＰパケットヘッダの内容を書き換えるゲートウエイとして構成することもできる。また、このパケット処理装置を、負荷分散のために、１台のｂＭＬＢＲ１３に対して複数台を備えてもよい。また、ｂＭＬＢＲ１３に隣接する中継装置１４（図１）に、このパケット処理装置の機能を含めてもよい。その機能を、ｂＭＬＢＲ１３からの要請によって活性化してもよい。
あるいは、ｂＭＬＢＲ１３は、ＬＳＢが１のパケットを次ホップノードに転送せずに、当該ｂＭＬＢＲ１３で廃棄する。このような構成にすれば、ｂＭＬＢＲ１３に過大な処理負荷がかかることはない。上記の処理は、ｅＭＬＢＲ１１やｉＭＬＢＲ１２においても同様である。
また、悪意あるノードから意図的にＡＨ認証失敗となるパケットが大量にｅＭＬＢＲ１１やｉＭＬＢＲ１２に送り付けられると、各ノード等に過大な処理負荷がかかるが、これについても上記と同様の対策を施せばよい。
また、悪意あるノードから意図的にＡＨ認証失敗となるパケットが大量にｅＭＬＢＲ１１やｉＭＬＢＲ１２に送り付けられると、各ノード等に過大な処理負荷がかかるが、これについても上記と同様の対策を施せばよい。
（第６の実施形態の変形例）
第６の実施形態の変形例について説明する。上記の第６の実施形態では、ユーザが利用する端末装置の認証の結果を、ＭＬＢＲ１０が利用する事例について例示したが、本変形例では、これに代えて、端末装置がユーザ又はエンティティを認証して、その認証の結果を、ＭＬＢＲ１０が利用する事例について説明する。第６の実施形態との相違点を中心に説明する。
第６の実施形態の変形例について説明する。上記の第６の実施形態では、ユーザが利用する端末装置の認証の結果を、ＭＬＢＲ１０が利用する事例について例示したが、本変形例では、これに代えて、端末装置がユーザ又はエンティティを認証して、その認証の結果を、ＭＬＢＲ１０が利用する事例について説明する。第６の実施形態との相違点を中心に説明する。
図３６は、本実施形態の変形例における端末装置１７の構成図である。図３７は、本実施形態の変形例における端末装置１７の機能構成を示す図である。
端末装置１７は、制御部１７１と、記憶部１７２と、通信制御部１７３、と認証処理部１７４、とを含む。例えば、制御部１７１と通信制御部１７３と認証処理部１７４は、ＣＰＵ１７Ａ等のプロセッサがプログラムを実行することにより実現される。
端末装置１７は、制御部１７１と、記憶部１７２と、通信制御部１７３、と認証処理部１７４、とを含む。例えば、制御部１７１と通信制御部１７３と認証処理部１７４は、ＣＰＵ１７Ａ等のプロセッサがプログラムを実行することにより実現される。
制御部１７１は、ＯＳ及びアプリケーションプログラムの実行により、入出力装置１７Ｄを介した情報の入出力を制御して、通信インタフェース１７Ｅを介して通信するように、端末装置１７内の各部を制御する。
記憶部１７２は、プロファイルＤＢとストローク情報ＤＢを格納する。プロファイルＤＢには、ユーザの識別情報と、認証処理により参照されるパスワードと、ユーザのキー操作の特徴を示す基準ストローク情報とが含まれる。ストローク情報ＤＢには、端末装置１７の使用者の識別情報と、端末装置１７の使用者のキー操作の特徴を記録したストローク履歴情報が含まれる。
通信制御部１７３は、通信インタフェース１７Ｅを介して、外部機器であるｅＭＬＢＲ１１と通信する。
認証処理部１７４は、ユーザを特定するための認証処理を、端末装置１７の起動時、またはユーザの要求時に実施して、その認証結果を制御部１７１に通知する。認証処理の詳細については後述する。
図３８と図３９は、端末装置の認証処理を示すための図である。
端末装置１７は、入出力装置１７Ｄとして設けられたキーボードに対するユーザのキー操作を検出して、各キーのストロークに関する情報を収集する。
制御部１７１は、図３８に示すように、各キーが打鍵される度に、そのキーに対する打鍵開始時刻と打鍵終了時刻とを検出し、記憶部１７２のストローク情報ＤＢに格納する。
例えば、時刻ｔＡ１において「Ａ」キーが打鍵（［Ａ］press）され、「Ａ」キーが押された状態で保持された後、時刻ｔＡ２において「Ａ」キーが離された（［Ａ］release）とする。この場合、「Ａ」キーに対する打鍵開始時刻が時刻ｔＡ１であり、打鍵終了時刻が時刻ｔＡ２である。認証処理部１７４は、上記の時刻に基づいて、「Ａ」キーが押されていた期間（Ｔ［Ａ］pr）を次式（１）により算出する。
端末装置１７は、入出力装置１７Ｄとして設けられたキーボードに対するユーザのキー操作を検出して、各キーのストロークに関する情報を収集する。
制御部１７１は、図３８に示すように、各キーが打鍵される度に、そのキーに対する打鍵開始時刻と打鍵終了時刻とを検出し、記憶部１７２のストローク情報ＤＢに格納する。
例えば、時刻ｔＡ１において「Ａ」キーが打鍵（［Ａ］press）され、「Ａ」キーが押された状態で保持された後、時刻ｔＡ２において「Ａ」キーが離された（［Ａ］release）とする。この場合、「Ａ」キーに対する打鍵開始時刻が時刻ｔＡ１であり、打鍵終了時刻が時刻ｔＡ２である。認証処理部１７４は、上記の時刻に基づいて、「Ａ」キーが押されていた期間（Ｔ［Ａ］pr）を次式（１）により算出する。
Ｔ［Ａ］pr＝（ｔＡ２−ｔＡ１） ・・・（１）
制御部１７１は、上記のように、各キーの操作を検出する。制御部１７１は、例えば、予め定められた順で特定又は非定型文字列の複数のキーが操作された場合には、そのキーと時刻情報とを関連付けてストローク情報ＤＢを格納する。なお、上記の予め定められた順で操作される特定の複数のキーは、プロファイルＤＢに格納されている識別情報やパスワードなどであってもよい。また非定型文字列は、任意の文字列から構成される文章であってもよい。これにより、端末装置１７は、ユーザが特定又は非定型文字列の複数のキーを操作する際の癖を収集し、それをユーザの認証情報に利用する。
図３９に示すように２つのキーを順に操作する場合には、制御部１７１は、上記にならって下記の処理を実施する。下記の処理では、「Ｂ」キーに続いて「Ｃ」キーが操作された場合を一例として示すものであり、キーの種類はこれに制限されるものではなく、他のキーの組み合わせを選択できる。なお、説明を簡素化するために２つのキーを操作する場合を例示するが、キーの個数はこれに制限されるものではなく、適宜選択できる。
例えば、制御部１７１は、図３９に示すように、時刻ｔＢ１において「Ｂ」キーが打鍵（［Ｂ］press）され、「Ｂ」キーが押された状態で保持された後、時刻ｔＢ２において「Ｂ」キーが離された（［Ｂ］release）とする。更に、続けて、時刻ｔＣ１において「Ｃ」キーが打鍵（［Ｃ］press）され、「Ｃ」キーが押された状態で保持された後、時刻ｔＣ２において「Ｃ」キーが離された（［Ｃ］release）とする。
この場合、「Ｂ」キーに対する打鍵開始時刻が時刻ｔＢ１であり、打鍵終了時刻が時刻ｔＢ２である。「Ｃ」キーに対する打鍵開始時刻が時刻ｔＣ１であり、打鍵終了時刻が時刻ｔＣ２である。
制御部１７１は、上記の時刻に基づいて、「Ｂ」キーが押されていた期間（Ｔ［Ｂ］pr）を次式（２）により算出し、「Ｃ」キーが押されていた期間（Ｔ［Ｃ］pr）を次式（３）により算出する。
Ｔ［Ｂ］ｐｒ＝（ｔＢ２−ｔＢ１） ・・・（２）
Ｔ［Ｃ］ｐｒ＝（ｔＣ２−ｔＣ１） ・・・（３）
Ｔ［Ｃ］ｐｒ＝（ｔＣ２−ｔＣ１） ・・・（３）
更に、制御部１７１は、上記の時刻に基づいて、「Ｂ」キーが打鍵されてから「Ｃ」キーが打鍵されるまでの期間（Ｔ［Ｂ、Ｃ］pｐ）を次式（４）により算出し、「Ｂ」キーが離されてから「Ｃ」キーが離されるまでの期間（Ｔ［Ｂ、Ｃ］ｒｒ）を次式（５）により算出する。
Ｔ［Ｂ，Ｃ］ｐｐ＝（ｔＣ１−ｔＢ１） ・・・（４）
Ｔ［Ｂ，Ｃ］ｒｒ＝（ｔＣ２−ｔＢ２） ・・・（５）
Ｔ［Ｂ，Ｃ］ｒｒ＝（ｔＣ２−ｔＢ２） ・・・（５）
更に、制御部１７１は、上記の時刻に基づいて、「Ｂ」キーが打鍵されてから「Ｃ」キーが離されるまでの期間（Ｔ［Ｂ、Ｃ］pｒ）を次式（６）により算出し、「Ｂ」キーが離されてから「Ｃ」キーが打鍵されるまでの期間（Ｔ［Ｂ、Ｃ］ｒｐ）を次式（７）により算出する。
Ｔ［Ｂ，Ｃ］ｐｒ＝（ｔＣ２−ｔＢ１） ・・・（６）
Ｔ［Ｂ，Ｃ］ｒｐ＝（ｔＣ１−ｔＢ２） ・・・（７）
Ｔ［Ｂ，Ｃ］ｒｐ＝（ｔＣ１−ｔＢ２） ・・・（７）
制御部１７１は、上記の式（２）から式（７）を用いて算出した結果を、そのキーと時刻情報とに関連付けてストローク情報ＤＢに追加する。
制御部１７１は、ストローク情報ＤＢに格納された、各期間に関する算出結果を複数組抽出して集計する。これにより、制御部１７１は、特定又は非定型文字列のキーボードから入力された文字列に関する操作の特徴を統計的な処理により抽出する。例えば、制御部１７１は、上記の統計的な処理により、平均値、中心値、分散を考慮して決定された上限値と下限値、最短値と最長値に基づいて決定される下限値と上限値などのうちの一部、または全部をその代表値としてもよい。
制御部１７１は、ストローク情報ＤＢに格納された、各期間に関する算出結果を複数組抽出して集計する。これにより、制御部１７１は、特定又は非定型文字列のキーボードから入力された文字列に関する操作の特徴を統計的な処理により抽出する。例えば、制御部１７１は、上記の統計的な処理により、平均値、中心値、分散を考慮して決定された上限値と下限値、最短値と最長値に基づいて決定される下限値と上限値などのうちの一部、または全部をその代表値としてもよい。
以上の処理により、特定又は非定型文字列の複数のキーが操作される場合に、ユーザのキー操作の特徴を示す代表値を抽出できる。制御部１７１は、抽出した代表値に基づいてプロファイルＤＢのデータを更新してもよい。
認証処理部１７４は、実際に端末装置を利用するためにログインする際などの認証処理でパスワードなどが入力された際の、各期間の値と、事前に算出していた上記の代表値とを比較して、操作者が正当なユーザであるか否かを判定する。
端末装置１７は、上記の認証処理におけるユーザの認証結果に基づいて、正当なユーザであると認証された場合に、当該ユーザによるログインを許可して、自装置の所定のリソースを利用可能にする。
端末装置１７は、ログイン後もユーザのキー操作を測定しプロファイルＤＢから外れていないか、すなわち認証した本人が操作しているか監視し、認証した本人の操作により、パケットを送信する際には、認証済みを示すＡＨをパケットに付加して送信する。キー操作がプロファイルＤＢから外れている場合には、端末装置１７は、認証した本人でない人物が操作していると見なし、パケットにＡＨを付加せずに送信する。これら一連の認証をソフトステート型認証と呼ぶ。
（ユーザの認証）
各ＭＬＢＲ１０は、ＡＨが付加されたパケットを受信した際には、そのＡＨの妥当性を検証して、信頼できるユーザからのパケットを受信したものと判定するとよい。
各ＭＬＢＲ１０は、ＡＨが付加されたパケットを受信した際には、そのＡＨの妥当性を検証して、信頼できるユーザからのパケットを受信したものと判定するとよい。
例えば、ＭＬＢＲ１０は、信頼できるユーザからのパケットを、前述の信頼できる端末装置１７からのパケットと同様に扱うことにより、上記の実施形態の処理を適用することができる。
上記の変形例によれば、第６の実施形態と同様の効果を奏することの他、端末装置１７のログイン時だけの認証に代えて、端末装置１７のユーザのソフトステート型認証を実施することができる。この場合、１つの端末装置１７を複数のユーザが共用する場合であっても、ユーザ毎に異なる判定基準で認証処理を実施することができ、ユーザ毎に異なる通信サービスを提供できる。
（実施形態に共通する第１変形例）
ＩＤＳ／ＩＰＳ／ＤＰＩに搭載される攻撃検出エンジンの一例について説明する。
ＩＤＳ／ＩＰＳ／ＤＰＩに搭載される攻撃検出エンジンの一例について説明する。
［ＩＤＳ／ＩＰＳ／ＤＰＩの攻撃検出エンジンの一例について］
ＩＤＳ／ＩＰＳ／ＤＰＩ等には、その攻撃検出エンジンとして所謂人工知能を適用してもよい。上記の人工知能とは過去の経験に基づいて、未知の事象を判断するものである。人工知能が適用された攻撃検出エンジンは、パケットやファイル（暗号化されていれば、復号したもの）、時系列の挙動やログなどに基づいて、それに含まれるデータを学習して、機械学習済みデータ（例えば、ニューラルネットワークの結合重み係数等）を生成する。また、機械学習済みデータが実装された人工知能搭載攻撃検出エンジンは、未知の事象におけるこれらのデータが入力されると直ちに判定結果を出力する。
ＩＤＳ／ＩＰＳ／ＤＰＩ等には、その攻撃検出エンジンとして所謂人工知能を適用してもよい。上記の人工知能とは過去の経験に基づいて、未知の事象を判断するものである。人工知能が適用された攻撃検出エンジンは、パケットやファイル（暗号化されていれば、復号したもの）、時系列の挙動やログなどに基づいて、それに含まれるデータを学習して、機械学習済みデータ（例えば、ニューラルネットワークの結合重み係数等）を生成する。また、機械学習済みデータが実装された人工知能搭載攻撃検出エンジンは、未知の事象におけるこれらのデータが入力されると直ちに判定結果を出力する。
機械学習あるいは深層学習には膨大な量の学習用データや教師データと、それらを処理するためのＨＰＣ(High-Performance Computing)環境が必要である。このようなＨＰＣ環境は、大量の浮動小数点演算を高速に処理することができる。一方、機械学習済みデータは、高速並列浮動小数点演算専用のＧＰＵ（Graphics Processing Unit）などによる比較的軽装備なＨＰＣ環境を実装した攻撃検出エンジン上で実行できる。このように構成された攻撃検出エンジンは、これまでの既知のパターンファイルを用いたウイルス検知ソフトウェアや、ログ分析を人手が介在して判断していた方法に比べ、既知・未知を問わず格段に高速かつ高精度に攻撃を検出することが可能になる。
そして、各ＭＬＢＲ１０は、ＩＤＳ／ＩＰＳ／ＤＰＩ等による検出結果に基づいて必要な処理を実施することにより、自システム（通信システム１）を守ることができる。さらに、自システムを守ることの他に、各ＭＬＢＲ１０は、攻撃などに関与したパケットの送信元アドレスとそのパケットの属性情報を特定して廃棄要請メッセージ（ＤＲＭ）を生成し、攻撃パケットの送信元アドレスに向けて送信すれば、その送信元アドレスに最も接近したＭＬＢＲ１０がその攻撃を遮断できる。さらに、ＭＬＢＲ１０又は別に設けたＤＲＭ分析装置（不図示）に、多数のノードから送信された複数のＤＲＭを集め分析することによって、攻撃が１対多あるいは多対多で行われていることを判定し、その結果に基づいてＤＲＭを集約してもよい。これによって、例え、効果的な対策が未確定な状態にある所謂ゼロデイ攻撃であっても、被害の拡大を自動的に短時間で抑制することが可能になるとともに、ＭＬＢＲ１０内の廃棄テーブルの廃棄エントリーも削減できることになる。
（実施形態に共通する第２変形例）
端末装置等における認証処理と検疫処理の一例について説明する。
端末装置等における認証処理と検疫処理の一例について説明する。
［ソフトステート型本人認証について］
端末装置等におけるソフトステート型本人認証に機械学習を適用してもよい。例えば、ユーザのキーストロークの特徴（ローマ字表記や、２連字のキーストローク時間間隔などの特徴）を機械学習させて、その結果を認証エンジンに登録する。ユーザがログインした後、文字を入力するごとにキーストロークの特徴を計測し、これを認証エンジンが判定することによって、ログインした時のユーザ本人がその後も操作し続けているか、あるいは別の人物が操作していないかを継続的に判定するようにしてもよい。
端末装置等におけるソフトステート型本人認証に機械学習を適用してもよい。例えば、ユーザのキーストロークの特徴（ローマ字表記や、２連字のキーストローク時間間隔などの特徴）を機械学習させて、その結果を認証エンジンに登録する。ユーザがログインした後、文字を入力するごとにキーストロークの特徴を計測し、これを認証エンジンが判定することによって、ログインした時のユーザ本人がその後も操作し続けているか、あるいは別の人物が操作していないかを継続的に判定するようにしてもよい。
［ソフトステート型検疫について］
端末装置等におけるソフトステート型検疫に機械学習を適用してもよい。例えば、大量の既知のマルウェアを使って、暗号化ＡＰＩを呼び出したり、システムの安定稼働に影響を及ぼすような危険なメモリアクセスを行ったりするマルウェアの大量の特徴を機械学習させて、学習済みデータを検疫エンジンに登録する。例えば、新しいファイルをダウンロードした時やファイルの実行直前に検疫エンジンにかけることによって、既知、亜種、未知を問わずマルウェアの存在の有無を検出するようにしてもよい。
端末装置等におけるソフトステート型検疫に機械学習を適用してもよい。例えば、大量の既知のマルウェアを使って、暗号化ＡＰＩを呼び出したり、システムの安定稼働に影響を及ぼすような危険なメモリアクセスを行ったりするマルウェアの大量の特徴を機械学習させて、学習済みデータを検疫エンジンに登録する。例えば、新しいファイルをダウンロードした時やファイルの実行直前に検疫エンジンにかけることによって、既知、亜種、未知を問わずマルウェアの存在の有無を検出するようにしてもよい。
［ソフトステート型認証・検疫と信頼度情報］
上述の人工知能技術を用いた認証エンジンや検疫エンジンの処理負荷が処理装置の能力に対して比較的軽い場合には、ＧＰＵなどを用いずにＰＣなどのＣＰＵがその処理を実行してもよい。
上述の人工知能技術を用いた認証エンジンや検疫エンジンの処理負荷が処理装置の能力に対して比較的軽い場合には、ＧＰＵなどを用いずにＰＣなどのＣＰＵがその処理を実行してもよい。
例えば、認証エンジンによって、ログイン若しくはIEEE802.1X認証に成功した時のユーザ本人が、その後もキー操作を行っていることが継続的に検出され、さらに、検疫エンジンによって端末装置１７がマルウェアに感染していない、若しくはマルウェアがパケットの送信に関与してないことが確認できたと仮定する。
この場合には、端末装置１７は、端末装置１７とｅＭＬＢＲ１１との間で予め交わした共有鍵を用いて認証ヘッダ（ＡＨ）をパケットに付加して、それをｅＭＬＢＲ１１へ送信する。ｅＭＬＢＲ１１は、ＡＨの検証に成功したことによって、所定の信頼度基準を満たしている送信元から送信されたパケットと判定し、前記信頼度情報を信頼度が比較的高いことを示すように設定するようにしてもよい。そして、ｅＭＬＢＲ１１は同パケットにｅＭＬＢＲ１１とｉＭＬＢＲ１２との間で予め交わしておいた共有鍵を使って生成したＡＨを付加してｉＭＬＢＲ１２に転送するようにしてもよい。
この場合には、端末装置１７は、端末装置１７とｅＭＬＢＲ１１との間で予め交わした共有鍵を用いて認証ヘッダ（ＡＨ）をパケットに付加して、それをｅＭＬＢＲ１１へ送信する。ｅＭＬＢＲ１１は、ＡＨの検証に成功したことによって、所定の信頼度基準を満たしている送信元から送信されたパケットと判定し、前記信頼度情報を信頼度が比較的高いことを示すように設定するようにしてもよい。そして、ｅＭＬＢＲ１１は同パケットにｅＭＬＢＲ１１とｉＭＬＢＲ１２との間で予め交わしておいた共有鍵を使って生成したＡＨを付加してｉＭＬＢＲ１２に転送するようにしてもよい。
一方、認証エンジンによってログイン若しくはIEEE802.1X認証に成功した時のユーザ本人がキー操作を行っていることが確認できない場合、若しくは確認できなくなった場合には、検疫エンジンによって端末装置１７がマルウェアに感染していないことが確認できていても、端末装置１７は、パケットにＡＨを付加せずに、そのパケットを送信する。ｅＭＬＢＲ１１は、受信したパケットにＡＨが付加されていないことから、そのパケットを信頼度が不明なパケットと判定し、そのパケットの信頼度情報を信頼度が不明なパケットであることを示すように、その信頼度情報の値を維持するようにしてもよい。そして、ｅＭＬＢＲ１１は、同パケットにｅＭＬＢＲ１１とｉＭＬＢＲ１２との間で予め交わしておいた共有鍵を使って生成したＡＨを付加してｉＭＬＢＲ１２に転送するようにしてもよい。
さらに、認証エンジンによってユーザ本人によるキー操作が確認できているか否かに拘らず、検疫エンジンによって端末装置１７がマルウェアに感染していることが判明した場合には、端末装置１７は、マルウェアが関与して送信しようとしているパケットを、偽ＡＨを付加してｅＭＬＢＲ１１へ送信するとよい。ｅＭＬＢＲ１１は、偽ＡＨが付加されたパケットのＡＨの検証に失敗する。これにより、ｅＭＬＢＲ１１は、信頼度情報をリスクが比較的高いことを示すように設定してもよい。そして、ｅＭＬＢＲ１１は、ｅＭＬＢＲ１１とｉＭＬＢＲ１２との間で予め交わしておいた共有鍵を使って生成したＡＨを、同パケットに付加してｉＭＬＢＲ１２に転送するようにしてもよい。
［ソフトステート型認証・検疫の真正性・完全性検証］
本実施形態の端末装置１７は、ソフトステート型認証・検疫エンジンを備えることにより、その結果をパケットに付加するＡＨに反映させる。端末装置１７は、認証エンジンや検疫エンジン及びそれらに実装されている機械学習済みデータが改ざんやマルウェアに感染したものでないことを検証してもよい。
本実施形態の端末装置１７は、ソフトステート型認証・検疫エンジンを備えることにより、その結果をパケットに付加するＡＨに反映させる。端末装置１７は、認証エンジンや検疫エンジン及びそれらに実装されている機械学習済みデータが改ざんやマルウェアに感染したものでないことを検証してもよい。
例えば、耐タンパー性を有するセキュリティモジュールとしてＴＰＭ（Trusted Platform Module）が知られている。ＴＰＭは、ＴＰＭの識別用のＥＫ（Endorsement Key）鍵や署名用のＡＩＫ（Attestation Identity Key）鍵、暗号用のＳＴＫ（Storage Key）鍵と、これらの秘密鍵やプログラムやファイルのハッシュ値を格納するためのＰＣＲ（Platform Configuration Register）などを備えている。端末装置１７は、ＴＰＭを利用して、認証エンジンや検疫エンジンのメインメモリに展開されているプログラムファイルのハッシュ値や、機械学習済みデータのハッシュ値を定期的にｅＭＬＢＲ１１との間で交換しておく。端末装置１７は、送信すべきパケットが発生したら、パケットのペイロードとこれらのハッシュ値及び共有鍵とを組み合わせてＡＨを生成し、それをパケットに付加して、ｅＭＬＢＲ１１に送信する。
ｅＭＬＢＲ１１は、受信したパケットのペイロードとｅＭＬＢＲ１１が保持していた当該端末装置１７の認証エンジンや検疫エンジン、機械学習済みデータのハッシュ値と共有鍵を組み合わせて、端末装置１７における生成方法と同じ方法でＡＨを生成する。ｅＭＬＢＲ１１は、生成したＡＨと、パケットに付加されていたＡＨとを照合することによって、その真正性（正しい送信元であること）及び完全性（プログラムやデータが改ざんさせていないこと）を検証するようにしてもよい。なお、前述の人工知能を搭載した攻撃検出エンジンや、ｅＭＬＢＲ１１、ｉＭＬＢＲ１1、ｂＭＬＢＲ１３などの真正性と完全性についても同様の方法で検証するようにしてもよい。
また、これらの真正性と完全性検証により信頼性を持たせるために、各装置のＴＰＭのＥＫ鍵（公開鍵）やベンダーが提供するプログラムファイルのハッシュ値や、機械学習済みデータのハッシュ値などを認定機関などで一括管理し、各装置が前記認定機関に照会するようにしてもよい。なお、この場合には、前記認定機関への各装置からの照会が集中し負荷が過大になる恐れがあるが、ルートＤＮＳサーバなどに見られるように、前記認定機関のＩＰアドレスをａｎｙｃａｓｔとし、複数の前記認定機関を配備することによって、照会があった装置に最も近い前記認定機関が応答を返すようにしてもよい。
上記の変形例によれば、端末装置においてソフトステート型の認証処理と検疫処理を実施することにより、端末装置を操作するユーザ、端末装置の状態等に基づいて、端末装置の信頼度について判定することができる。
なお、本実施形態のパケットは、フラグ又はコードで示される信頼度情報を格納する格納部が設けられている。例えば、この格納部は、本願出願時点のＩＥＴＦの規定に干渉しないようにパケットヘッダの所定の位置に設けることができる。これにより、未導入ネットワークから送信されてきたパケットなどを含むすべてのパケットに、上記の格納部を設けることができる。
なお、パケットの信頼度が判断されるまでに、当該パケットの信頼度情報として付与される値（デフォルト値）は、予め定められた所定値であってよい。例えば、スイッチ部によって決定された結果（パケットの信頼度の選択の結果）に基づいて当該パケットの信頼度情報が設定されるまでの信頼度情報の値は、その信頼度が不明であることを示す値に決定されていてもよい。上記の定義によれば、信頼度情報の設定が必須ではないネットワークから到来するパケットの信頼度情報は、上記の値（デフォルト値）になる。その結果、ＭＬＢＲ１０等の各装置は、それぞれのパケットの信頼度を不明と判定することができる。
以上説明した少なくともひとつの実施形態によれば、通信装置は、パケットにより、ネットワークを介して通信する。通信装置は、通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部が、前記パケットのパケットヘッダの所定位置に設けられており、信頼度が不明であることを示す所定値が格納部に格納されたパケットに対し、当該パケットに関する情報に基づいて、当該パケットの信頼度が比較的高いこと、当該パケットが匿名性を有すること、当該パケットのリスクが比較的高いこと、の内から１又は複数を選択して、選択の結果に基づいて当該パケットの信頼度情報を設定し、又は、信頼度が不明なパケットを選択して、選択されたパケットの信頼度情報を維持することにより、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信者側に通知することができる。
また、通信装置は、所定の信頼度基準を満たす送信元から送信されたパケットの前記信頼度情報を、前記ネットワークセキュリティ上のリスクが比較的低いことを示すように設定し、送信元又は宛先を隠ぺいしたパケットの前記信頼度情報を、前記リスクが比較的高いことを示すように設定することにより、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信者側に通知することができる。
また、通信装置は、所定の信頼度基準を満たす送信元から送信されたパケットの前記信頼度情報を、前記ネットワークセキュリティ上のリスクが比較的低いことを示すように設定し、送信元又は宛先を隠ぺい又は詐称したパケットの前記信頼度情報を、前記リスクが比較的高いことを示すように設定し、信頼度が不明なバケットについては信頼度が不明であることを示すように設定することにより、パケット通信におけるネットワークセキュリティ上のリスク度をより簡易な方法で受信者側に通知することができる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、適宜組み合わせを変更してもよく、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
例えば、上記の実施形態の説明では、ＭＬＢＲ１０等のスイッチ部が攻撃パケットを“廃棄する”こととして説明したが、ＭＬＢＲ１０等は、当該パケットを、各スイッチ部内で廃棄せずに、特定のポートから外部記憶装置に出力して格納させてもよい。
また、上記の実施形態の説明では、ＩＰｖ４のプライベートＩＰアドレスを用いたが、本発明は、これに限定するものではなく、ＩＰｖ４のプライベートＩＰアドレスとグローバルＩＰアドレスとで通信許可情報を構成してもよく、あるいはＩＰｖ４のグローバルＩＰアドレスで通信許可情報を構成してもよく、あるいはＩＰｖ６アドレスで通信許可情報を構成してもよく、さらにレイヤ２アドレス（ＭＡＣアドレス）で通信許可情報を構成してもよい。
なお、上記の実施形態の説明では、端末装置１７がＩＤＳ／ＩＰＳを備えるものとして説明したが、ｅＭＬＢＲ１１又はｉＭＬＢＲ１２がＩＤＳ／ＩＰＳを備えるように構成してもよい。この場合、ｅＭＬＢＲ１１又はｉＭＬＢＲ１２は、端末装置１７のＩＤＳ／ＩＰＳに代えて、ｅＭＬＢＲ１１又はｉＭＬＢＲ１２が備えるＩＤＳ／ＩＰＳの検出結果を取得するように構成する。
１、２、３、４…通信システム、１０…ＭＬＢＲ、１１…ｅＭＬＢＲ、１２…ｉＭＬＢＲ、１３…ｂＭＬＢＲ、１４…中継装置、１５…管理ホスト、１７…端末装置、１８…データ端末、１１１…コントローラ（制御部）、１１２…スイッチ部、１１３、１１４…ＩＦ部、１１５…記憶部、ＮＷ、ＮＷ１、ＮＷ３、ＮＷ４…ネットワーク
Claims (21)
- パケットにより、ネットワークを介して通信する通信装置であって、
前記通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部が、前記パケットのパケットヘッダの所定位置に設けられており、
前記ネットワークから受信したパケットに付与されているアドレス情報がブラックリストに非該当であり、かつ匿名ＩＰアドレスに該当している場合に、前記パケットの匿名性を示す所定値を前記信頼度情報の一部に設定し、
前記信頼度情報に基づいて、当該パケットの信頼度が比較的高い又は当該パケットが匿名性を有することと、当該パケットのリスクが比較的高いことと、の内から１又は複数を選択し、
前記１又は複数を選択した結果に基づいて当該パケットの前記信頼度情報を設定し、又は、
前記１又は複数を選択した結果に基づいて前記信頼度が不明なパケットを選択して、前記選択されたパケットの前記信頼度情報を維持する信頼度情報設定手段を備える、
通信装置。 - 前記信頼度情報設定手段は、
当該パケットに関する情報に基づいて、前記ネットワークにおける所定の信頼度基準を満たす送信元から送信されたパケットの前記信頼度情報を、当該パケットの信頼度が比較的高いことを示すように設定する、
請求項１に記載の通信装置。 - 前記信頼度情報設定手段は、
当該パケットに関する情報に基づいて、送信元又は宛先が隠ぺいされたパケットの前記信頼度情報の一部に、前記所定値を設定する、
請求項１又は請求項２に記載の通信装置。 - 前記信頼度情報設定手段は、
当該パケットに関する情報に基づいて、前記ネットワークにおける所定の信頼度基準から外れた送信元から送信されたパケット又は前記信頼度が不明な送信元から送信されたパケットの信頼度情報の一部が前記所定値でないパケット又は信頼できないネットワークから転送されてきたパケットの信頼度情報の一部が前記所定値ではないパケットの前記信頼度情報を、当該パケットのリスクが比較的高いことを示すように設定する、
請求項１から請求項３の何れか１項に記載の通信装置。 - 前記信頼度情報設定手段は、
前記信頼度が不明な送信元から送信されたパケットの信頼度情報の一部が前記所定値であるパケット又は信頼できないネットワークから到来したパケットの信頼度情報の一部が前記所定値であるパケットの前記信頼度情報を維持する、
請求項１から請求項４の何れか１項に記載の通信装置。 - パケットにより、ネットワークを介して通信する通信装置であって、
前記通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部が、前記パケットのパケットヘッダの所定位置に設けられており、
信頼度が不明であることを示す所定値が格納部に格納されたパケットに対し、当該パケットの信頼度が比較的高いこと、当該パケットが匿名性を有すること、当該パケットのリスクが比較的高いこと、の内から１又は複数を選択して、前記選択の結果に基づいて当該パケットの前記信頼度情報を設定し、又は、前記選択の結果に基づいて前記信頼度が不明なパケットを選択して、前記選択されたパケットの前記信頼度情報を維持する信頼度情報設定手段を備え、
前記パケットのパケットヘッダの所定位置は、ＩＰｖ４パケットヘッダのサービス種別(Type of Service)フィールド内の予備ビットまたはＩＰｖ６パケットヘッダのトラフィッククラスフィールド内の予備ビットであり、
前記信頼度情報設定手段は、前記パケットのパケットヘッダの所定位置に、パケットの信頼度情報とリスク情報の双方を含む属性を識別するためのフラグを前記信頼度情報として設定し、
前記フラグが設定されてから前記パケットを前記ネットワークに送信する、
通信装置。 - 前記格納部には、前記通信によるネットワークセキュリティ上のリスクが比較的低いパケットであることを示す認証フラグと、前記リスクが比較的高いパケットであることを示すリスクフラグの少なくとも何れかのフラグが前記信頼度情報を示すものとして設けられ、
前記信頼度情報設定手段は、
前記認証フラグが設けられているパケットであって所定の信頼度基準を満たした送信元から送信されたパケットに対しては前記リスクが比較的低いことを示すように前記認証フラグを設定し、前記リスクフラグが設けられているパケットであって送信元又は宛先を隠ぺいしたパケットに対しては前記リスクが比較的高いことを示すように前記リスクフラグを設定する、
請求項６記載の通信装置。 - 前記信頼度情報設定手段は、
前記認証フラグとして、通信の接続要求元が認証されていること又は接続要求元が検疫されていることを示す第１フラグが設けられ、通信の接続要求に対する判定の結果により前記第１フラグの状態を設定する第１フラグ設定手段を含む、
請求項７記載の通信装置。 - 前記信頼度情報設定手段は、
前記リスクフラグとして、接続経路を隠ぺいするように前記パケットの送信元ＩＰアドレス又は宛先ＩＰアドレスが設定されたパケットであることを示す第２フラグを当該パケットに設定する第２フラグ設定手段を含む、
請求項７又は請求項８記載の通信装置。 - 前記信頼度情報設定手段は、
前記通信がメール又はメッセージを送るものである場合には、前記リスクフラグとして、前記通信の送信元メールアドレスと、宛先メールアドレスと、電話番号との何れかが隠ぺい化、匿名化、又は詐称されたものであることを示す第３フラグを当該パケットに設定する第３フラグ設定手段を含む、
請求項７から請求項９の何れか１項に記載の通信装置。 - 前記信頼度情報設定手段は、
所定の判定基準に基づいた前記リスクの有無についての判定を含む所定の手続きにより、前記パケットの送信元ＩＰアドレスの詐称の有無を検査し、前記判定の結果により、前記リスクフラグとして、前記送信元ＩＰアドレスが詐称されたもの又は不正なものであることを示す第４フラグを当該パケットに設定する第４フラグ設定手段を含む、
請求項７から請求項１０の何れか１項に記載の通信装置。 - 受信したパケットのパケットヘッダに前記リスクが比較的低いことを示すように前記認証フラグが設定されたパケットを選択的に受信するパケット受信手段
を備える請求項８記載の通信装置。 - 受信したパケットのパケットヘッダに前記リスクが比較的低いことを示すように前記認証フラグが設定されていないパケットと、前記リスクが比較的高いことを示すように前記リスクフラグが設定されたパケットの一方又は両方を選択的に検査するパケット検査手段 を備える請求項８記載の通信装置。
- 受信したパケットのパケットヘッダに前記リスクが比較的高いことを示すように前記リスクフラグが設定されたパケットを廃棄するか、又は、特定のポートから出力するように制御する手段
を備える請求項７から請求項１３の何れか１項に記載の通信装置。 - 前記リスクフラグは、前記パケットヘッダにおけるビット配列上の特定の位置に配置され、
前記信頼度情報設定手段は、
接続経路を隠ぺいするように前記パケットの送信元ＩＰアドレス又は宛先ＩＰアドレスが設定されたパケットである場合と、
前記通信がメール又はメッセージを送るものであって、前記通信の送信元メールアドレス、宛先メールアドレス、又は、送信元アカウント名、宛先アカウント名、又は、電話番号、又は送信元ＵＲＬ（Uniform Resource Locator）、宛先ＵＲＬ、又は、送信元ＵＲＩ（Uniform Resource Identifier）、宛先ＵＲＩ、又は、宛先ＵＲＮ（Uniform Resource Name）、送信元ＵＲＮ、又は、送信元ドメイン名、宛先ドメイン名、又は、送信元ＦＱＤＮ（Fully Qualified Domain Name）、宛先ＦＱＤＮが隠ぺい化、匿名化、又は、詐称されたものである場合と、
前記パケットの送信元ＩＰアドレスが詐称されたもの又は不正なものである場合と、のうちの何れかの場合に該当する場合にセットする、
請求項７から請求項１４の何れか１項に記載の通信装置。 - 前記信頼度情報設定手段は、
受信した第１パケットから、当該第１パケットの前記認証フラグと前記リスクフラグとを抽出し、当該受信した第１パケットをトンネリングさせる通信の第２パケットのパケットヘッダ、当該受信した第１パケットを分割して送信する第２パケットのパケットヘッダ、当該受信した第１パケットを暗号化して送信する第２パケットのパケットヘッダ、又は、当該受信した第１パケットの上位レイヤの情報を転送する際に生成されるパケットのパケットヘッダに設けられた認証フラグとリスクフラグにそれぞれ反映させる、
請求項７から請求項１５の何れか１項に記載の通信装置。 - 前記信頼度情報が、ＩＰｖ４（Internet Protocol version ４）パケットヘッダのサービス種別(Type of Service)フィールド内に割り当てられている、
を備える請求項１から請求項１５の何れか１項に記載の通信装置。 - 前記信頼度情報が、ＩＰｖ６（Internet Protocol version ６）パケットヘッダのトラフィッククラスフィールド内に割り当てられている、
を備える請求項１から請求項１６の何れか１項に記載の通信装置。 - 前記信頼度情報設定手段によって前記１又は複数を選択した結果に基づいて当該パケットの前記信頼度情報が設定されるまでの前記信頼度情報の値は、前記信頼度が不明であることを示す値に決定されている、
請求項１から請求項５の何れか１項に記載の通信装置。 - パケットにより、ネットワークを介して通信する通信方法であって、
前記通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部が、前記パケットのパケットヘッダの所定位置に設けられており、
前記ネットワークから受信したパケットに付与されているアドレス情報がブラックリストに非該当であり、かつ匿名ＩＰアドレスに該当している場合に、前記パケットの匿名性を示す所定値を前記信頼度情報の一部に設定し、
前記信頼度情報に基づいて、当該パケットの信頼度が比較的高い又は当該パケットが匿名性を有することと、当該パケットのリスクが比較的高いことと、の内から１又は複数を選択し、
前記１又は複数を選択した結果に基づいて当該パケットの前記信頼度情報を設定し、又は、
前記１又は複数を選択した結果に基づいて前記信頼度が不明なパケットを選択して、前記選択されたパケットの前記信頼度情報を維持する、
通信方法。 - パケットにより、ネットワークを介して通信する通信装置のコンピュータに、
前記通信によるネットワークセキュリティ上の信頼度に関する信頼度情報を格納する格納部が、前記パケットのパケットヘッダの所定位置に設けられており、
前記ネットワークから受信したパケットに付与されているアドレス情報がブラックリストに非該当であり、かつ匿名ＩＰアドレスに該当している場合に、前記パケットの匿名性を示す所定値を前記信頼度情報の一部に設定するステップと、
前記信頼度情報に基づいて、当該パケットの信頼度が比較的高い又は当該パケットが匿名性を有することと、当該パケットのリスクが比較的高いことと、の内から１又は複数を選択するステップと、
前記１又は複数を選択した結果に基づいて当該パケットの前記信頼度情報を設定するステップ、又は、前記１又は複数を選択した結果に基づいて前記信頼度が不明なパケットを選択して、前記選択されたパケットの前記信頼度情報を維持するステップと、
を実行させるためのプログラム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016092113 | 2016-04-28 | ||
| JP2016092113 | 2016-04-28 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2017201774A JP2017201774A (ja) | 2017-11-09 |
| JP6896264B2 true JP6896264B2 (ja) | 2021-06-30 |
Family
ID=60264859
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2017002110A Active JP6896264B2 (ja) | 2016-04-28 | 2017-01-10 | 通信装置、通信方法、及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6896264B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023281748A1 (ja) | 2021-07-09 | 2023-01-12 | 浩 小林 | 再生可能エネルギ供給システム、浮体式洋上太陽光発電プラント、及び再生可能エネルギ供給方法 |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2019058684A1 (ja) * | 2017-09-25 | 2019-03-28 | ソニー株式会社 | 検証装置、情報処理方法、およびプログラム |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002158699A (ja) * | 2000-11-20 | 2002-05-31 | Nippon Telegr & Teleph Corp <Ntt> | ＤｏＳ攻撃防止方法および装置およびシステムおよび記録媒体 |
| JP2003143189A (ja) * | 2001-10-31 | 2003-05-16 | Fujitsu Ltd | 通信システム |
| US8578441B2 (en) * | 2004-07-22 | 2013-11-05 | Hewlett-Packard Development Company, L.P. | Enforcing network security policies with packet labels |
| JPWO2015174100A1 (ja) * | 2014-05-14 | 2017-04-20 | 学校法人東京電機大学 | パケット転送装置、パケット転送システム及びパケット転送方法 |
| JP5902264B2 (ja) * | 2014-08-28 | 2016-04-13 | ソフトバンク株式会社 | 通信制御装置、通信制御システム、通信制御方法、および通信制御プログラム |
-
2017
- 2017-01-10 JP JP2017002110A patent/JP6896264B2/ja active Active
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023281748A1 (ja) | 2021-07-09 | 2023-01-12 | 浩 小林 | 再生可能エネルギ供給システム、浮体式洋上太陽光発電プラント、及び再生可能エネルギ供給方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2017201774A (ja) | 2017-11-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20240121211A1 (en) | Systems and methods for continuous fingerprinting to detect session hijacking inside zero trust private networks | |
| US9762596B2 (en) | Heuristic botnet detection | |
| US9723019B1 (en) | Infected endpoint containment using aggregated security status information | |
| US20180198828A1 (en) | Identity-Based Internet Protocol Networking | |
| US8806572B2 (en) | Authentication via monitoring | |
| US20160248754A1 (en) | Password constraint enforcement used in external site authentication | |
| Shi et al. | Dynamic distributed honeypot based on blockchain | |
| JP6737610B2 (ja) | 通信装置 | |
| US20170310579A1 (en) | Method for using authenticated requests to select network routes | |
| Hussein et al. | Software-Defined Networking (SDN): the security review | |
| Roselin et al. | Exploiting the remote server access support of CoAP protocol | |
| Dua et al. | Iisr: A secure router for iot networks | |
| Nasser et al. | Provably curb man-in-the-middle attack-based ARP spoofing in a local network | |
| JP6896264B2 (ja) | 通信装置、通信方法、及びプログラム | |
| JP6780838B2 (ja) | 通信制御装置及び課金方法 | |
| US20230412626A1 (en) | Systems and methods for cyber security and quantum encapsulation for smart cities and the internet of things | |
| US11265249B2 (en) | Method for using authenticated requests to select network routes | |
| Pareek et al. | Different type network security threats and solutions, a review | |
| EP1836559B1 (en) | Apparatus and method for traversing gateway device using a plurality of batons | |
| JP2017200152A (ja) | 通信制限範囲特定装置、通信制御装置、通信装置、通信システム、通信制限範囲特定方法、及びプログラム | |
| Temdee et al. | Security for context-aware applications | |
| Sørensen et al. | Automatic profile-based firewall for iot devices | |
| Hyppönen | Securing a Linux Server Against Cyber Attacks | |
| Railkar et al. | 3 Threat analysis and attack modeling for machine-to-machine communication toward Internet of things | |
| Bharti et al. | Prevention of Session Hijacking and IP Spoofing With Sensor Nodes and Cryptographic Approach |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20191126 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20200928 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20201013 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20201211 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20210427 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20210513 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20210525 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20210602 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6896264 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |