JP6330814B2 - 通信システム、制御指示装置、通信制御方法及びプログラム - Google Patents

Description

［関連出願についての記載］
本発明は、日本国特許出願：特願２０１３−１７１２６６号（２０１３年８月２１日出願）に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信システム、制御指示装置、通信制御方法及びプログラムに関し、特に、ノード間の通信を制御する通信システム、制御指示装置、通信制御方法及びプログラムに関する。

近年、オープンフロー（ＯｐｅｎＦｌｏｗ）という技術が提案されている（非特許文献１、２参照）。オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。非特許文献２に仕様化されているオープンフロースイッチは、オープンフローコントローラとの通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。フローテーブルには、フロー毎に、パケットヘッダと照合するマッチ条件（Ｍａｔｃｈ Ｆｉｅｌｄｓ）と、フロー統計情報（Ｃｏｕｎｔｅｒｓ）と、処理内容を定義したインストラクション（Ｉｎｓｔｒｕｃｔｉｏｎｓ）と、の組が定義される（非特許文献２の「４．１ Ｆｌｏｗ Ｔａｂｌｅ」の項参照）。

例えば、オープンフロースイッチは、パケットを受信すると、フローテーブルから、受信パケットのヘッダ情報に適合するマッチ条件（非特許文献２の「４．３ Ｍａｔｃｈ Ｆｉｅｌｄｓ」参照）を持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、フロー統計情報（カウンタ）を更新するとともに、受信パケットに対して、当該エントリのインストラクションフィールドに記述された処理内容（指定ポートからのパケット送信、フラッディング、廃棄等）を実施する。一方、検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対してエントリ設定の要求、即ち、受信パケットを処理するための制御情報の送信要求（Ｐａｃｋｅｔ−Ｉｎメッセージ）を送信する。オープンフロースイッチは、処理内容が定められたフローエントリを受け取ってフローテーブルを更新する。このように、オープンフロースイッチは、フローテーブルに格納されたエントリを制御情報として用いてパケット転送を行う。

特許文献１には、ロールベースアクセス制御（Ｒｏｌｅ−Ｂａｓｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ、以下、「ＲＢＡＣ」）を行うアクセス制御装置の一例が開示されている。同文献のアクセス制御装置は、ユーザ毎に属性値が設定されるユーザ情報テーブルと、属性値の組み合わせを示すロールが設定されるロール情報テーブルと、コンテンツ毎にアクセス条件としてロールＩＤが設定されるアクセス制御テーブルとを記憶する。そして、同文献のアクセス制御装置は、ユーザ情報テーブルとロール情報テーブルとに基づいて、属性値がロールに対応するユーザのリストをロール毎にユーザリスト情報テーブルに設定する。コンテンツへのアクセス要求が発生した場合、アクセス制御部は、アクセス制御テーブルに基づいてアクセス条件のロールを特定し、特定したロールのユーザリストにアクセスユーザが含まれるかによりアクセス権限を判定する、と記載されている。

特開２０１０−１１７８８５号公報

Ｎｉｃｋ ＭｃＫｅｏｗｎほか７名、"ＯｐｅｎＦｌｏｗ： Ｅｎａｂｌｉｎｇ Ｉｎｎｏｖａｔｉｏｎ ｉｎ Ｃａｍｐｕｓ Ｎｅｔｗｏｒｋｓ"、［ｏｎｌｉｎｅ］、［平成２５（２０１３）年８月７日検索］、インターネット〈URL: http://www.openflow.org/documents/openflow-wp-latest.pdf〉 "ＯｐｅｎＦｌｏｗ Ｓｗｉｔｃｈ Ｓｐｅｃｉｆｉｃａｔｉｏｎ" Ｖｅｒｓｉｏｎ １．１．０ Ｉｍｐｌｅｍｅｎｔｅｄ （Ｗｉｒｅ Ｐｒｏｔｏｃｏｌ ０ｘ０２）、［ｏｎｌｉｎｅ］、［平成２５（２０１３）年８月７日検索］、インターネット〈URL:http://www.openflow.org/documents/openflow-spec-v1.1.0.pdf〉

以下の分析は、本発明によって与えられたものである。非特許文献１、２の技術を用いれば、経路上のオープンフロースイッチにロールを考慮したフローエントリを設定することで、特許文献１のようなロールベースのアクセス制御はもちろんのこと、経路制御まで実現可能となる。

ところで、近年のサイバーアタックは、社外から社内のノードにアクセスし、その社内のノードを踏み台にして社内の他のノードに更にアクセスして情報を収集することが行われる。よって、このような攻撃を防ぐためには、あるノードが、いつの間にか踏み台（英語圏では、「Ｚｏｍｂｉｅ」と呼ばれる）として動作していることを検出し、かかる踏み台の挙動を制御する技術が望まれている。

しかしながら、上記の特許文献及び非特許文献記載の技術では、上記踏み台や「Ｚｏｍｂｉｅ」として動作するノードの挙動を制御することが出来ないという問題点がある。その理由は、あるノードの接続時に相応のアクセス制御を行うものの、その後に、踏み台や「Ｚｏｍｂｉｅ」として動作を開始したことを検出する仕組みが存在しないからである。

本発明は、通信を許可したノードが、上述した踏み台や「Ｚｏｍｂｉｅ」として動作することを抑止することのできる通信システム、制御指示装置、通信制御方法及びプログラムを提供することを目的とする。

第１の視点によれば、所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置と、前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部と、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部と、を備える制御指示装置と、を含む通信システムが提供される。

第２の視点によれば、制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部と、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部と、を備える制御指示装置が提供される。

第３の視点によれば、所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータが、前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するステップと、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止するステップと、を含む通信制御方法が提供される。本方法は、制御実施装置を制御する制御指示装置として機能するコンピュータという、特定の機械に結びつけられている。

第４の視点によれば、所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータに、前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断する処理と、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する処理と、を実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な（非トランジエントな）記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、通信を許可したノードが、上述した踏み台や「Ｚｏｍｂｉｅ」として動作することを抑止することが可能となる。

本発明の第１の実施形態の通信システムの構成を示す図である。 本発明の第１の実施形態の制御指示装置が保持する通信履歴情報の一例を示す図である。 本発明の第１の実施形態の制御指示装置が通信を許可するか否かを判断するため使用するポリシーの一例を示す図である。 本発明の第１の実施形態の制御指示装置による通信制御パターンを示す図である。 本発明の第１の実施形態の制御指示装置による通信制御の具体例を説明するための図である。 本発明の第１の実施形態の制御指示装置による通信制御の具体例を説明するための図である。 本発明の第１の実施形態の通信システムの全体の動作を表したシーケンス図である。 図７の続図である。 本発明の第１の実施形態の制御実施装置のパケット受信時の詳細な動作を表したシーケンス図である。 本発明の第１の実施形態の制御指示装置のメッセージ受信時の詳細な動作を表したシーケンス図である。 本発明の第１の実施形態の通信システムの全体の動作を表した別のシーケンス図である。 図１１の続図である。 本発明の第２の実施形態の通信システムの構成を示す図である。 本発明の第２の実施形態の制御指示装置が保持する第２のテーブル（ノード状態判断用テーブル）の一例を示す図である。 本発明の第２の実施形態の制御指示装置が保持する第３のテーブル（アクセス可否判断用テーブル）の一例を示す図である。 本発明の第２の実施形態の制御指示装置が保持する第３のテーブル（アクセス可否判断用テーブル）の別の一例を示す図である。 本発明の第２の実施形態の制御指示装置のメッセージ受信時の詳細な動作を表したシーケンス図である。 本発明の第３の実施形態の通信システムの構成を示す図である。 本発明の第３の実施形態におけるノード１〜３の関係を説明するための図である。 本発明の第３の実施形態の通信システムの全体の動作を表したシーケンス図である。 図２０の続図である。 図２１の続図である。 本発明の第４の実施形態の通信システムの構成を示す図である。 本発明の第４の実施形態の制御指示装置のポリシーデータベース（ポリシーＤＢ）に保持されるノード状態判断用テーブルの一例を示す図である。 本発明の第４の実施形態の制御指示装置のアクセス制御ルールデータベース（アクセス制御ルールＤＢ）に保持されるアクセス可否判断用テーブルの一例を示す図である。 本発明の第４の実施形態の通信システムの全体の動作を表したシーケンス図である。 図２６の続図である。 本発明の第１の実施形態のオープンフローコントローラのメッセージ受信時の詳細な動作を表したシーケンス図である。 図２７の続図である。 本発明の第１の実施形態のオープンフローコントローラのメッセージ受信時の詳細な動作を表したシーケンス図である。 図２７の続図である。 本発明の第４の実施形態の制御指示装置のアクセス制御ルールデータベース（アクセス制御ルールＤＢ）に保持されるアクセス可否判断用テーブルの別の一例を示す図である。 本発明の第５の実施形態の通信システムの構成を示す図である。 本発明の第５の実施形態の制御指示装置によるノード状態の判定処理を説明するための図である。

はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。

本発明は、その一実施形態において、図１に示すように、所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置（図１の２０）と、この制御実施装置に対して指示を与える制御指示装置（図１の１０）とを接続した構成にて実現できる。

より具体的には、制御指示装置（図１の１０）は、前記制御実施装置（図１の２０）を介したノード間の通信履歴を管理する通信履歴管理部（図１の１３）と、前記通信履歴管理部（図１の１３）の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部（図１の１２）と、少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部（図１の１１）と、を備える。

以上のように、制御指示装置（図１の１０）を動作させることで、サービスを提供する側にあるノード、即ち、サーバ等として動作しているコンピュータが、踏み台にされ、通信を開始しようとしていることを検出し、その通信を禁止することが可能となる。

［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図１は、本発明の第１の実施形態の通信システムの構成を示す図である。図１を参照すると、制御実施装置２０と、制御実施装置２０に指示を与えることでノード間の通信を実現する制御指示装置１０と、を接続した構成が示されている。

制御指示装置１０は、受信パケットのヘッダ等に格納された情報を記録することで、ノード間の通信履歴を管理する通信履歴管理部１３と、通信履歴管理部１３に記録された通信履歴を参照して、制御実施装置２０から処理方法の問い合せを受けたパケットの送信元又は送信先のノードの状態を判断するノード状態判断部１２と、制御実施装置２０に対し、前記ノード状態に基づいて決定した受信パケットの処理に関する指示メッセージ等を送信する制御指示部１１とを備える。

制御実施装置２０は、制御指示装置１０と制御情報を含んだ制御メッセージを送受信する通信部２１と、通信部２１から受信した制御情報を用いて受信パケットを処理するパケット処理部２２とを備えている。

制御指示装置１０の通信履歴管理部１３は、受信パケットのヘッダ等に格納された情報を記録するためのエントリを保持している。

図２は、通信履歴管理部１３に保持されるエントリの一例を示す図である。図２の例では、パケットの発信元や送信先の識別子や、サービスやプロトコルの識別子が記録される。なお、図２の例では、送信元の識別子を１つ記録する例を示したが、ネットワークの各レイヤの識別子など、複数の識別子を記録してもよい。例えば、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルのレイヤ２（Ｌ２）の識別子であるＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスやレイヤ３（Ｌ３）の識別子であるＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを記録してもよい。同様に、送信先の識別子も複数記録してもよい。また、送信元および送信先のサービスやプロトコルの識別子についても、１つだけではなく、複数記録してもよい。

制御指示装置１０のノード状態判断部１２は、通信履歴管理部１３に記録されている情報を参照して、これから通信を行おうとしているノードの状態の判定を行う。ノードの状態の判定方法については、後に具体例を示して詳細に説明する。

制御指示装置１０の制御指示部１１は、ノード状態判断部１２の判定結果に基づいたアクセス制御（制御実施装置への指示）を行う。また、制御指示部１１は、通信履歴管理部１３に、処理対象のパケットから抽出した上記識別子等を記録する。

ここで、ノード状態判断部１２におけるノードの状態の判定の動作について説明する。ノード状態判断部１２は、制御実施装置２０から処理方法の問い合わせを受けたパケットの送信元又は送信先のノードの識別子等が通信履歴管理部１３に記録されている場合、その情報に基づいて、前記ノードが「クライアント状態」又は「サーバ状態」となっていないかを確認する。ここで、「サーバ状態」とは、そのノードが通信のコネクションを受け付けている状態、つまり、クライアント等からの要求に応じてサービスを提供している状態である。一方、クライアント状態とは、そのノードから他のノードへコネクションを張っている状態、つまり、サーバ等に対してサービスの提供を受けているである。

具体的には、ノード状態判断部１２は、通信履歴管理部１３に記録されている情報を参照して、当該ノードをパケット送信先として通信が開始された通信履歴があった場合、前記ノードが他のノードからコネクションを受け付けているとみなし、当該ノードを「サーバ状態」であると判定する。また、当該ノードがパケットの送信元として通信が開始された通信履歴があった場合、当該ノードから他のノードへコネクションを張っているとみなし、「クライアント状態」であると判定する。なお、通信履歴に当該ノードに関する情報が無い場合、ノード状態判断部１２は、サーバ状態とクライアント状態のどちらでもないと判定する。

ノード状態判断部１２は、制御実施装置２０から処理方法の問い合わせを受けたパケットの送信元のノードについても同様の判定を行う。

制御指示部１１は、前記ノード状態判断部１２による判定結果に基づいたアクセス制御を行う。

図３は、制御指示部１１が通信を許可するか否かを判断するため使用するポリシーの一例を示す図である。図３の１番目のエントリは、パケットの送信先ノードが、クライアント状態ではないとき、すなわちサーバ状態もしくはどちらの状態でもないとき、通信を許可することを定めている。

逆に、制御実施装置２０から処理方法の問い合わせを受けたパケットの送信先のノードが、クライアント状態である場合、制御指示部１１は、当該ノードがサーバ状態になることを禁止する。具体的には、制御指示部１１は、制御実施装置２０に対し、当該ノードが他のノードからコネクションを受け付けないように、パケットを破棄するように指示を行う。

図３の２番目のエントリは、パケットの送信元ノードが、サーバ状態ではないとき、すなわちクライアント状態もしくはどちらの状態でもないとき、通信を許可することを定めている。具体的には、制御実施装置２０から処理方法の問い合わせを受けたパケットの送信元ノードがサーバ状態ではないとき、制御指示部１１は、前記パケットを転送するように、制御実施装置２０に指示する。

逆に、制御実施装置２０から処理方法の問い合わせを受けたパケットの送信元のノードが、サーバ状態である場合、制御指示部１１は、当該ノードがクライアント状態になることを禁止する。具体的には、制御指示部１１は、制御実施装置２０に対し、当該ノードが他のノードにコネクションを張らないように、パケットを破棄するように指示を行う。

以上を総合し、パケット送信元と送信先の両方のノードについて、判定が「許可」であるとき、制御指示部１１は、制御実施装置２０から処理方法の問い合わせを受けたパケットを転送する（アクセスを許可）ように、制御実施装置２０に指示する。一方、どちらかでも「禁止」の判定であった場合は、制御指示部１１は、パケットの破棄を指示（アクセスを禁止）する。

また、制御指示部１１は、以上の判定の結果を用いて、通信履歴管理部１３への記録を行う。即ち、前記アクセス可否の判定が「許可」であり、かつ、送信元と送信先が同じであるエントリがテーブルに存在しないとき、制御指示部１１は、通信履歴管理部１３に、送信元と送信先の識別子等を対応付けたエントリとして追加する。このとき、サービスやプロトコルの識別子も、エントリの中に含めてもよい（図２参照）。

図４は、ノード間の通信履歴による制御指示装置の動作をまとめたものである。大きく分けて６つのパターンに類別されるので、以下、これらについて説明する。

（１）通信履歴に、制御実施装置からの問い合わせの通信の送信先と送信元のどちらも出現しないとき
まず、ノードの状態の判断について説明する。この場合、通信履歴に送信元であるノード１の記録が無いので、「サーバでもクライアント状態でもない」、また、通信履歴に送信先であるノード２の記録も無いので、「サーバでもクライアント状態でもない」と判断される。
この結果、図３のテーブルを用いたアクセス可否の判定は、送信元は「サーバでもクライアント状態でもない」ので「許可」である。また、送信先も「サーバでもクライアント状態でもない」ので「許可」である。送信元と送信先が許可であるので、このアクセスは許可される。
また、通信記憶にはこの通信の記録が存在しないので、制御指示部１１は、新たなエントリを追加する。

（２）通信履歴に、制御実施装置からの問い合わせの通信の送信元（ノード１）と送信先（ノード２）と同一の組み合わせの通信があるとき
この場合、通信履歴に、制御実施装置からの問い合わせの通信の送信元（ノード１）は、送信元と記録されており、「クライアント状態」であると判定される。制御実施装置２０からの問い合わせの通信の送信先（ノード２）も、通信履歴に送信先と記録されており、「サーバ状態」であると判定される。
この結果、図３のテーブルを用いたアクセス可否の判定は、パケット送信元（ノード１）は「クライアント状態」なので「許可」である。同様に、パケット送信先（ノード２）は「サーバ状態」であるので「許可」である。送信元（ノード１）と送信先（ノード２）のいずれもが許可であるので、当該アクセスは許可される。
また、通信記憶には同一の通信記録がすでに存在するので、制御指示部１１は、通信記憶管理部１３への新たなエントリの追加を行わない。

（３）通信履歴に、制御実施装置からの問い合わせの通信の送信元（ノード２）が通信の送信先として記録されているとき
この場合、通信履歴に、制御実施装置からの問い合わせの通信の送信元（ノード２）は、送信先と記録されているので、「サーバ状態」と判定される。
この結果、図３のテーブルを用いたアクセス可否の判定は、通信の送信元（ノード２）は「サーバ状態」なので「禁止」である。よって、送信先（ノード３）の状態に拘らず、当該通信は禁止される。
また、この場合も通信記憶管理部１３への新たなエントリの追加を行わない。なぜなら、通信は禁止され、パケットが破棄されるため、実際の通信は発生しないためである。

（４）通信履歴に、制御実施装置からの問い合わせの通信の送信先（ノード２）が通信の送信元として記録されているとき
この場合、通信履歴に、制御実施装置からの問い合わせの通信の送信先（ノード２）は、送信元と記録されているので、「クライアント状態」であると判定される。
この結果、図３のテーブルを用いたアクセス可否の判定は、送信先が「クライアント状態」であるので、「禁止」と判断される。よって、送信元（ノード１）の状態に拘らず、当該通信は禁止される。
また、この場合も通信記憶管理部１３への新たなエントリの追加を行わない。なぜなら、通信は禁止され、パケットが破棄されるため、実際の通信は発生しないためである。
（５）通信履歴に、制御実施装置からの問い合わせの通信の送信元（ノード１）が別の通信の送信元として記録されているとき
この場合、（２）の場合と同様に、制御実施装置からの問い合わせの通信の送信元（ノード１）は、テーブルにも送信元と記載されているので、「クライアント状態」であると判定される。また、図３のテーブルを用いたアクセス可否の判定は、「許可」となる。
制御実施装置からの問い合わせの通信の送信先（ノード３）が、（４）で示した例のようにクライアント状態で無い場合、すわなち（１）の場合のようにサーバとクライアントのどちらでもない状態の場合か、（１）の例のように、送信先（ノード３）がサーバ状態の場合、送信先（ノード３）についても「許可」の判定となる。この結果、送信元と送信先の両方が「許可」であるため、当該通信は許可される。
また、通信記憶にはこの通信の記録が存在しないので、制御指示部１１は、新たなエントリを追加する。
なお、送信先（ノード３）が、（４）の場合のように、クライアント状態である場合は、通信は禁止され、テーブルにもエントリは追加されない。
（６）通信履歴に、制御実施装置からの問い合わせの通信の送信先が別の通信の送信先として記録されているとき
この場合、（２）の場合と同様に、制御実施装置からの問い合わせの通信の送信先(ノード２)は、テーブルにも送信先と記録されているので「サーバ状態」であると判定される。また、図３のテーブルを用いたアクセス可否の判定も、「許可」となる。
一方で、送信元（ノード３）が（１）の場合のように「サーバ状態でもクライアント状態でもない」場合や、（２）のようにクライアント状態であるときは、送信元（ノード３）についても許可であり、送信元と送信先の両方が「許可」の判定であるので、通信は許可される。
なお、通信記憶にはこの通信の記録が存在しないので、制御指示部１１は、新たなエントリを追加する。
なお、送信先（ノード２）が、（４）の場合のように、クライアント状態である場合は、通信は禁止され、通信履歴へのエントリの追加も行われない。

続いて、本実施形態の制御実施装置２０について、再度図１を参照して詳細に説明する。制御実施装置２０は、通信部２１と、パケット処理部２２とを備えている。

通信部２１は、パケット処理部２２から、受信パケットに対する処理内容の問い合わせを要求するメッセージの送信指示を受けると、制御指示装置１０に対して該メッセージを送信する。また、制御指示装置１０から該メッセージに対する応答メッセージを受け取ると、通信部２１は、パケット処理部２２に対し制御指示装置１０から受け取った指示を送信する。

制御実施装置２０のパケット処理部２２は、新規パケットを受信した際、パケット処理部２２に備えられた指示キャッシュ２３の中から、受信パケットに適合するエントリを検索する。前記検索の結果、前記受信パケットに適合するエントリが見つかった場合、パケット処理部２２は、該エントリに従いパケットを処理する。一方、前記受信パケットに適合するエントリが見つからなかった場合、パケット処理部２２は、通信部２１に対して、制御指示装置１０へ前記受信パケットに対する処理内容を問い合わせるメッセージの送信を要求する。前記メッセージに対する応答として、指示キャッシュ２３に格納するエントリを受信した場合、パケット処理部２２は、指示キャッシュ２３は、当該エントリを指示キャッシュ２３に格納する。これにより、同一の特徴を持つパケットは、前記指示キャッシュ２３に格納されたエントリを用いて処理される。また、前記メッセージに対する応答として、制御指示装置１０からパケットの出力指示の処理命令等を受けた場合、パケット処理部２２は、制御指示装置１０から受信したパケットに対し、指示された処理内容を適用する。

なお、図１に示した制御指示装置１０及び制御実施装置２０の各部（処理手段）は、これらの装置を構成するコンピュータに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することもできる。

続いて、本実施形態の動作について図面を参照して詳細に説明する。図５、図６は、本発明の第１の実施形態の制御指示装置による通信制御の具体例を説明するための図である。図５は、ノードＢ、ノードＣ間の通信が確立された後（パケットＢを送信）、ノードＡからノードＢへアクセスを試みる場合（パケットＡを送信）を示している。この図では、ノードＢは、ノードＣと通信をしている際はクライアント状態である。この状態で、ノードＡからアクセスを受け付けるとサーバ状態となり、所謂踏み台として動作している状態となってしまう。本実施形態の制御指示装置１０により、クライアント状態で動作中のノードのサーバ状態での通信が禁止されるまでの流れを図７〜図１０を参照して説明する。

図７、図８は、本発明の第１の実施形態の通信システムの全体の動作を表したシーケンス図である。図７を参照すると、まず、通信を開始するノードＢが、ノードＣ宛てのパケットを制御実施装置２０へ送る（ステップＸ１）。または、ノードＢがノードＣへ送信したパケットを、制御実施装置２０がフックしてもよい。

制御実施装置２０は、ノードＢからのパケットを受信すると、ノードＢからノードＣへコネクションを張って良いかどうか確認するために、制御実施装置２０の指示キャッシュ２３から、当該パケットに適合するエントリを検索する（ステップＸ２）。

ここで、図９を参照してステップＸ２の動作の詳細を説明する。制御実施装置２０のパケット処理部２２は、ノードＢからノードＣへのパケットを受信すると（ステップＳ１）、受信パケットのヘッダ情報を基に指示キャッシュ２３内に該当エントリがあるか検索を行う（ステップＳ２）。既にノードＢ、ノードＣ間のコネクションが張られている場合は、指示キャッシュ２３に該当するエントリが存在するため、そのエントリの処理内容をパケットに適用することになる。ここでは、新規通信であるため、指示キャッシュ２３に、当該パケットに適合するエントリがないので、パケット処理部２２は、通信部２１に対し、制御指示装置１０へ当該パケットの処理内容を問い合わせるメッセージの送信を依頼する（ステップＳ３）。

再度、図７に戻ると、制御実施装置２０の通信部２１からの問い合わせメッセージを受信した、制御指示装置１０は、受信したメッセージに含まれるパケットの情報を元に、送受信ノードの状態を確認する（ステップＸ３）。

ここで、図１０を参照してステップＸ３の動作の詳細を説明する。制御指示装置１０内のノード状態判断部１２は、制御実施装置２０からの問い合わせメッセージを受信すると（ステップＴ１）、受信したメッセージ内にパケットヘッダの情報から、送信元と送信先として指定されたノードＢとノードＣの識別子をキーに通信履歴管理部１３内の通信履歴を検索する（ステップＴ２）。この例の場合、ノードＢ、ノードＣ間の通信履歴は記録されていないので、ノード状態判断部１２は「履歴なし」と回答する。この回答を受けた制御指示部１１は、パケットＢが初めてのパケットであり、ノードＢとノードＣの双方がサーバ状態とクライアント状態のいずれでもないと判定し、通信を許可する（ステップＴ３）。

再度、図７に戻ると、制御指示装置１０の制御指示部１１は、通信履歴管理部１３に、前記通信を許可すると判定したノードＢ、ノードＣ間の通信履歴を登録する（ステップＸ４）。次に、制御指示装置１０の制御指示部１１は、制御実施装置２０に対し、ノードＢからノードＣ宛てのパケットを送受信するよう指示する。具体的には、制御指示装置１０は、制御実施装置２０に対し、ステップＸ１にて受信したパケットをノードＣへ転送するよう指示するメッセージと、以降のノードＢからのパケットをノードＣへ転送することを指示する処理内容を含むエントリを指示キャッシュ２３に格納させるメッセージとを送信する（ステップＸ５）。

前記メッセージを受け取った制御実施装置２０は、受信したパケットをノードＣに送信するとともに、制御指示装置１０からの指示内容を、指示キャッシュ２３に格納する（ステップＸ６）。

ノードＣは、制御実施装置２０から送信されたパケットを受信する（ステップＸ７）。以上により、ノードＢからノードＣへのパケット送信が可能化される。

次に、図８を参照して、その後、ノードＡがノードＢへパケットを送信する場合の動作を説明する。ノードＡがノードＢへパケットを送信すると（ステップＸ８）、制御実施装置２０は、制御実施装置２０内の指示キャッシュ２３を検索する。これまでのステップＸ１〜ステップＸ７の処理では、ノードＡからノードＢ宛てのパケットに関する指示は、指示キャッシュ２３へ格納されていないため、制御実施装置２０は、制御指示装置１０に対し、受信したパケットの処理内容を問い合わせるメッセージを送信する（ステップＸ９）。

制御実施装置２０の通信部２１からの問い合わせメッセージを受信した制御指示装置１０のノード状態判断部１２は、受信したメッセージに含まれるパケットの情報を元に、送受信ノードの状態を確認する（ステップＸ１０）。通信履歴管理部１３にはノードＢ−ノードＣ間の通信履歴が登録されているため、ノード状態判断部１２は、通信履歴管理部１３からノードＢに関する情報を取得することになる。この結果、制御指示部１１は、ノードＢがパケットを送信していることを確認し、ノードＢは「クライアント状態」であると判断する。一方、ノードＡに関する通信履歴は、通信履歴管理部１３に登録されていないので、制御指示部１１は、ノードＡがサーバとクライアントのどちらの状態でもないと判断する（ステップＸ１０）。

その後、制御指示部１１は、ノードＢが既にクライアント状態として動作しているため、ノードＡからノードＢへのアクセスを禁止する（ステップＸ１１）。具体的には、制御指示部１１は、ノードＡからノードＢ宛てのパケットを破棄することを指示するエントリを指示キャッシュ２３に追加するよう、制御実施装置２０へ指示する。また、この際、ノードＡ、ノードＢ間の通信履歴は、通信履歴管理部１３にも登録されない。

制御実施装置２０は、制御指示装置１０の制御指示部１１からの指示に基づいて、以降ノードＡからノードＢ宛てのパケットを破棄する（ステップＸ１２）。

以上の動作によって、ノードＡからノードＢへの通信、すなわち、クライアント状態であったノードＢがサーバとなるような通信を禁止することができる。

次にサーバ状態で動作するノードがさらにクライアント状態として動作することを禁止する例について説明する。図６は、ノードＡ、ノードＢ間の通信が確立された後（パケットＡを送信）、ノードＢがノードＣへのアクセスを試みる場合（パケットＢを送信）を示している。この図では、ノードＢは、ノードＡと通信をしている際はサーバ状態である。この状態で、ノードＣへのアクセスを開始するとクライアント状態となり、所謂踏み台として動作している状態となってしまう。本実施形態の制御指示装置１０により、サーバ状態で動作中のノードによる新たな通信が禁止されるまでの流れを図１１〜図１２を参照して説明する。

図１１、図１２は、本発明の第１の実施形態の通信システムの全体の動作を表した別のシーケンス図である。図１１を参照すると、まず、通信を開始するノードＡが、ノードＢ宛てのパケットを制御実施装置２０へ送る（ステップＹ１）。

制御実施装置２０は、ノードＡからのパケットを受信すると、ノードＡからノードＢへコネクションを張って良いかどうか確認するために、制御実施装置２０の指示キャッシュ２３から、当該パケットに適合するエントリを検索する（ステップＹ２）。ステップＹ２の動作は、図９に示したものと同様であり、制御実施装置２０から制御指示装置１０に対し、受信パケットに適用する処理内容を問い合わせるメッセージが送信される。その他の詳細は、図９と同様であるため説明を省略する。

制御実施装置２０の通信部２１からの問い合わせメッセージを受信した、制御指示装置１０は、受信したメッセージに含まれるパケットの情報を元に、送受信ノードの状態を確認する（ステップＹ３）。ここでは、通信履歴管理部１３にノードＡ、ノードＢ間の通信履歴は記録されていないので、制御指示装置１０は、ノードＡとノードＢの双方がサーバ状態とクライアント状態のいずれでもないと判定し、通信を許可することになる。その他の詳細は、図１０と同様であるため説明を省略する。

その後、制御指示装置１０の制御指示部１１は、通信履歴管理部１３に、前記通信を許可すると判定したノードＡ、ノードＢ間の通信履歴を登録する（ステップＹ４）。次に、制御指示装置１０の制御指示部１１は、制御実施装置２０に対し、ノードＡからノードＢ宛てのパケットを送受信するよう指示する。具体的には、制御指示装置１０は、制御実施装置２０に対し、ステップＹ１にて受信したパケットをノードＢへ転送するよう指示するメッセージと、以降のノードＡからの受信パケットをノードＢへ転送することを指示する処理内容を含むエントリを指示キャッシュ２３に格納させるメッセージとを送信する（ステップＹ５）。

前記メッセージを受け取った制御実施装置２０は、受信したパケットをノードＢに送信するとともに、制御指示装置１０からの指示内容を、指示キャッシュ２３に格納する（ステップＹ６）。

ノードＢは、制御実施装置２０から送信されたパケットを受信する（ステップＹ７）。以上により、ノードＡからノードＢへのパケット送信が可能化される。

次に、図１２を参照して、その後、ノードＢがノードＣへパケットの送信を試みた場合の動作を説明する。ノードＢがノードＣへパケットを送信すると（ステップＹ８）、制御実施装置２０は、制御実施装置２０内の指示キャッシュ２３を検索する。これまでのステップＹ１〜ステップＹ７の処理では、ノードＢからノードＣ宛てのパケットに関する指示は、指示キャッシュ２３へ格納されていないため、制御実施装置２０は、制御指示装置１０に対し、受信したパケットの処理内容を問い合わせるメッセージを送信する（ステップＹ９）。

制御実施装置２０の通信部２１からの問い合わせメッセージを受信した制御指示装置１０のノード状態判断部１２は、受信したメッセージに含まれるパケットの情報を元に、送受信ノードの状態を確認する（ステップＹ１０）。通信履歴管理部１３にはノードＡ−ノードＢ間の通信履歴が登録されているため、ノード状態判断部１２は、通信履歴管理部１３からノードＢに関する情報を取得することになる。この結果、制御指示部１１は、ノードＢがパケットを受信していることを確認し、ノードＢは「サーバ状態」であると判断する。一方、ノードＣに関する通信履歴は、通信履歴管理部１３に登録されていないので、制御指示部１１は、ノードＡがサーバとクライアントのどちらの状態でもないと判断する（ステップＹ１０）。

その後、制御指示部１１は、ノードＢが既にサーバ状態として動作しているため、ノードＢからノードＣへのアクセスを禁止する（ステップＹ１１）。具体的には、制御指示部１１は、ノードＢからノードＣ宛てのパケットを破棄することを指示するエントリを指示キャッシュ２３に追加するよう、制御実施装置２０へ指示する。また、この際、ノードＢ、ノードＣ間の通信履歴は、通信履歴管理部１３にも登録されない。

制御実施装置２０は、制御指示装置１０の制御指示部１１からの指示に基づいて、以降ノードＢからノードＣ宛てのパケットを破棄する（ステップＹ１２）。

以上の動作によって、ノードＢからノードＣへの通信、すなわち、サーバ状態であったノードＢがクライアントとなるような通信を禁止することができる。

なお、上記した実施形態では、通信履歴管理部１３に、送信元と送信先の識別子等を対応付けたエントリを登録するものとして説明したが、これらの識別子に代えて、受信パケットの送信先ＩＰアドレスおよびポート番号を用いることができる。

また、上記した実施形態では、制御指示装置１０の通信履歴や、制御実施装置２０の指示キャッシュ２３のエントリを掃き出すタイミングについて触れなかったが、例えば、一定時間使用されないエントリをタイムアウトとして削除する制御を行うことが望ましい（エージング処理）。なお、制御実施装置２０において、このタイムアウトが起こった場合、制御実施装置２０は、制御指示装置１０に対し、タイムアウトによりエントリを削除したことを示すメッセージを送信することが望ましい。制御指示装置１０は、前記通知に基づいて、制御指示装置１０側の通信履歴管理部１３の対応するエントリを削除することができる。

あるいは、制御実施装置２０側に、ノード間の通信終了を検出する機構を追加し、より的確に指示キャッシュ２３のエントリの要否を判断させるようにしてもよい。前記ノード間の通信終了を検出する機構としては、コネクション型通信プロトコルの終了メッセージをチェックする方法が挙げられる。例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）では、ＦＩＮフラグやその逆方向からのＡＣＫフラグのチェックにより、通信の終了を検知することができる。この場合も、制御実施装置２０が、制御指示装置１０に対し、フロー終了検出により指示キャッシュ２３のエントリを削除したことを示すメッセージを送信することが望ましい。制御指示装置１０は、前記通知に基づいて、制御指示装置１０側の通信履歴管理部１３の対応するエントリを削除することができる。

また、上述した制御実施装置２０は、ファイアーウォールやネットワークスイッチとして実装されてもよい。また、上記した説明では、制御実施装置２０は、物理的な装置であるものとして説明したが、例えば、ノードＡ、ノードＢ、ノードＣ上、即ち、通信端末上で動作するソフトウェアで実装されたパーソナルファイアウォールや仮想スイッチであってもよい。

［第２の実施形態］
続いて、より細かく通信許可／禁止判定を判断できるようにした本発明の第２の実施形態について、図面を参照して詳細に説明する。図１３は、本発明の第２の実施形態の通信システムの構成を示す図である。図１３を参照すると、第１の実施形態と比較して、制御指示装置１０ａ側の構成に変更が加えられており、通信履歴管理部１３に代えて、通信履歴のほか、ノード状態判定情報やアクセス制御ポリシーを格納するテーブル群１３ａが備えられている。また、第１の実施形態では、ノード状態判断部１２は、ノードがコネクションを受け付けていればサーバ状態、当該ノードから他ノードへコネクションを張っていればクライアント状態であると判定したが、第２の実施形態では、これらのテーブル群１３ａを参照してノード状態やアクセス可否の判定を行う点が異なっている。以下、第１の実施形態との相違点を中心に説明する。

以下の説明では、テーブル群１３ａとして、３つのテーブルを備えている例を挙げて説明する。なお、テーブルの数は、３つに限られるものではなく、必要とされる判断の内容や各テーブルの管理の容易性等を考慮して変更することができる。

第１のテーブルは、第１の実施形態の通信履歴管理部１３に相当する通信履歴を保持するテーブルである（図２参照）。

第２のテーブルは、第１のテーブルによるノード状態の判断に加えて、受信したパケットのヘッダ等の情報からノードの状態を判定するための、予め生成されたポリシーを格納したテーブルである。図１４は、第２のテーブルの一例である。図１４の例では、ノードが送信したパケットのヘッダに含まれるサービスやプロトコルの識別子を元に、ノードの状態を判定するエントリが格納されている。例えば、図１４の１番目のエントリは、あるサービス（Ｓｅｒｖｉｃｅ ａ）に関する通信が発生し、制御実施装置２０から、その最初のパケットの処理内容について問い合わせがあった場合、制御指示装置１０ａは、その送信先に指定されているノードを「サーバ状態」と判断することを示している。同様に、図１４の２番目のエントリは、あるサービス（Ｓｅｒｖｉｃｅ ａ）のパケットの処理内容について問い合わせがあった場合、制御指示装置１０ａは、その送信元に指定されているノードを「クライアント状態」と判断することを示している。なお、図１４の例は、あくまで一例であり、適宜フィールドを加えてより細かい判断を行うようにしても良い。このようなテーブルを用いることで、どのようなサービスやプロトコルの通信を開始しようとしているか、もしくは、受けようとしているかによってノードの状態を判断することができる。また図１４の例では、サーバ状態もしくはクライアント状態のいずれかに決定するエントリが格納されているが、「サーバ状態とクライアント状態のどちらでも無い」という状態と判断する条件を設定したエントリを追加してもよい。

また、第１のテーブルのエントリに第２のテーブルを検索する際のキーとして用いることのできるメタ情報を設定しておき、第１のテーブルの検索結果を用いて第２のテーブルを検索できるようにすることもできる。このようにすることで、特定のノードの組み合わせならば、キー「Ｐｒｉｏｒｉｔｙ＝１」が得られ、第２のテーブルの検索時に「Ｐｒｉｏｒｉｔｙ＝１」であるエントリを検索するといったきめ細かい判断を行わせることができる。

第３のテーブルは、送信元と送信先に設定されたノード間の通信の可否を判定するための、予め生成されたアクセス制御ルールを格納するテーブルである。図１５は、第３のテーブルの一例である。図１５の例では、送信元と送信先に設定されたノードの組み合わせを元に、アクセス可否を定めたエントリが格納されている。例えば、図１５の１番目のエントリは、識別子がＨｏｓｔ ａであるノードから、識別子がＨｏｓｔ ｂであるノードへのアクセスを禁止することを示している。同様に、図１５の２番目のエントリは、任意のノード（「＊」はワイルドカードを表す。）から、識別子がＨｏｓｔ ｃであるノードへのアクセスを許可することを示している。同様に、図１５の３番目のエントリは、識別子がＨｏｓｔ ｄであるノードから任意のノード（「＊」はワイルドカードを表す。）へのアクセスを許可することを示している。

なお、図１５の例では、ノードの識別子を用いてアクセス可否を判定する例を挙げたが、例えば、図１６に示すように、ノードのアドレス（図１５の例ではＩＰアドレス）の組を用いて、ノード間のアクセス可否を判断するテーブルを用いることもできる。なお、図１５、図１６に、例えば、サービスやプロトコルの識別子を条件とするフィールドを加えてより細かい判断を行うようにすることもできる。

本実施形態の制御指示装置１０ａのノード状態判断部１２ａは、上記のようなテーブルを参照して、ノードの状態の判定と、アクセス可否の判断を行う。具体的には、第１の実施形態では、サーバ状態であるときはコネクションを張ることを一律に禁止し、クライアント状態であるときはコネクションを受け付けることを一律に禁止していたが、第２の実施形態では、ノード状態判断部１２ａは、第１、第２のテーブルによるノードの状態の判定と第３のテーブルを用いたアクセス可否の判定を行うことになる。

ノード状態判断部１２ａは、第１のテーブルの通信記録に基づくノード状態の判断の後、第２のテーブルによるノード状態の判断を行う。ノード状態判断部１２ａは、これら３つのテーブルに該当するエントリに従い、対象のノードをサーバ状態とするのか、クライアント状態とするのか、を判断する。なお、第１のテーブルと、第２のテーブルによるノード状態の判断結果が異なる場合も起こりうるが（例えば、新規通信のため、第１のテーブルで「ノードでもサーバでもない状態」と判断、第２のテーブルでは「サーバ状態」とされる等）、その場合には、どちらかを優先するかを予め決めておけばよい。

さらに、本実施形態のノード状態判断部１２ａは、第３のテーブルに、制御実施装置２０から処理内容の問い合わせを受けたパケットの送信元と送信先間の通信が認められているか否かを確認する。

さらに、本実施形態の制御指示部１１は、上記ノード状態判断部１２ａによる判断結果に基づいて、制御実施装置２０への応答を実施する。これにより、第１の実施形態ではノードの状態のみでしかアクセス制御を行えなかったが、第２の実施形態では、例えば、ノード状態による判断では通信が許可される組み合わせであっても、通信を禁止したり、逆に、ノード状態による判断では通信が禁止される組み合わせであっても、通信を許可するといった運用を行うことが可能となる。

続いて、本実施形態の動作について図面を参照して詳細に説明する。図１７は、本発明の第２の実施形態の制御指示装置が制御実施装置からパケットの処理内容を問い合わせるメッセージを受信した際の処理の流れを表したシーケンス図である。なお、以下の説明で用いるノードの構成およびパケット名は図５と同様であり、制御指示装置以外の動作は第１の実施形態と同様である。

図５、図１７を参照すると、まず、制御装置１０ａのノード状態判断部１２ａは制御実施装置２０から処理内容を問い合わせるメッセージを受信すると（ステップＵ１）、受信パケットのヘッダ情報を基に、第１のテーブルに既に該当するエントリがあるか確認する（ステップＵ２）。次に、ノード状態判断部１２ａは、必要に応じ第１のテーブルから得られた情報も用いて、第２のテーブルから、受信パケットに適合するエントリを検索し、パケットＢの送信ノード、受信ノードの状態を確認する（ステップＵ３）。さらに、ノード状態判断部１２ａは、第３のテーブルを参照して、各ノードの例外処理も含めて送信元、送信先ノード間の通信可否を確認する（ステップＵ４）。ノード状態判断部１２ａは、上記した判断の結果を制御指示部１１へ送信し、その内容を受信した制御指示部１１は、制御実施装置へ処理を要求する（ステップＵ５）。

以上説明した本発明の第２の実施形態によれば、第１の実施形態のようなノード状態だけでなく、あるノードが受け付けたコネクション情報をもとに、ユーザごとのアクセス制御や、例外処理を行うことができる。

なお、上記した例では、第１のテーブルから得られた情報も用いて、第２のテーブルの検索を行うことがあるため、テーブルの参照順序を決めているが、受信パケットの情報のみを用いて、それぞれのテーブルから該当エントリを検索可能な場合、上記したテーブルの参照順序に制約はなく、適宜変更することができる。

［第３の実施形態］
続いて、より具体的な構成で第１の実施形態相当の機能を実現する本発明の第３の実施形態について説明する。以下の説明では、制御指示装置１１として、オープンフローコントローラ（以下、「制御装置」）、制御実施装置としてオープンフロースイッチ（以下、「スイッチ」）を用いる。また、制御実施装置２０の指示キャッシュ２３は、ＯＦＳのフローテーブルにて実現できる（非特許文献２参照）。

図１８は、本発明の第３の実施形態の通信システムの構成を示す図である。図１８を参照すると、制御装置１０ｂと、スイッチ２０ｂと、ノード群が示されている。制御装置１０ｂは、スイッチにつながる各ノードの位置情報を蓄積するＦｏｒｗａｒｄｉｎｇ ＤＢ（以下、「ＦＤＢ」）１２ｂと、受信パケットの送信先ＩＰアドレスとポート番号を記録することで通信履歴を蓄積するＲｏｕｔｅ ＤＢ（以下、「ＲＤＢ」）１３ｂと、これらの情報を基にノード状態に基づく通信可否を判定し、スイッチ２０ｂに対し指示を行うスイッチ制御部１１ｂとを備えている。

スイッチ２０ｂは、通信部２１ｂ、パケット処理部２２ｂに加えて、上記した指示キャッシュ２３に相当し、フローエントリを保持するためのフローテーブル２３ｂを備えている。フローテーブル２３ｂには、受信パケットと照合するマッチ条件と、このマッチ条件に適合するパケットに適用する処理内容を定めたエントリが格納される。パケット処理部２２ｂは、パケットを受信すると、フローテーブル２３ｂから受信パケットに適合するマッチ条件を持つエントリを検索し、検索されたエントリに定められた処理内容（パケット転送、ヘッダ書換え、パケット破棄等）を実行する。

ここで、制御装置１０ｂは、スイッチ２０ｂからＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）パケットを受信した場合、スイッチ２０ｂにつながる各ノードの位置情報を記録するＦＤＢ１２ｂのみ更新することとし、ＲＤＢ１３ｂの更新は行わないこととする。これにより、スイッチ２０ｂも、ＡＲＰパケット受信時に、フローテーブル２３ｂの更新は行わないことになる。

続いて、本実施形態の動作について図面を参照して詳細に説明する。以下の説明では、図１９のノード１からノード２へリモートログインし、その後、ノード３へアクセスする状況を例に説明する。この際流れるパケットを図１９に示すようにパケットＡ〜Ｄと名付ける。なお、リモートログイン用のプロトコルとしては、ＲＤＰ（Ｒｅｍｏｔｅ Ｄｅｓｋｔｏｐ Ｐｒｏｔｏｃｏｌ）を用いるものとする。

図２０は、本発明の第３の実施形態の通信システムの全体の動作を表したシーケンス図である。まず、ノード１がノード２に対し最初にＳＹＮパケット（ここではパケットＡ）を送信すると（ステップＺ１）、スイッチ２０ｂは、フローテーブル２３ｂに該当するフローエントリがあるか否かを確認する（ステップＺ２）。

ここで、パケットＡに適合するフローエントリが見つかった場合、スイッチ２０ｂは、ノード２が接続するスイッチ２０ｂのポートにパケットを送る。一方、フローテーブル２３ｂに、パケットＡに適合するフローエントリがなかった場合、スイッチ２０ｂは、制御装置２０ｂに対して、Ｐａｃｋｅｔ−ｉｎメッセージを用いてパケットＡを送信する（ステップＺ３）。

このＰａｃｋｅｔ−ｉｎメッセージを受け取った制御装置１０ｂのスイッチ制御部１１ｂは、ＲＤＢ１３ｂにパケットＡの送信元ＩＰアドレス（今回の例ではノード１のＩＰアドレス）が登録されているか否かを確認する（ステップＺ４）。ここで、該当するエントリがあった場合、スイッチ制御部１１ｂは、当該エントリに記載されているＴＣＰポート番号を取得し、ノード状態の判断を行う（これについては図２２で説明する）。

一方、前記ＲＤＢ１３ｂに該当するエントリがない場合、スイッチ制御部１１ｂは、ＲＤＢ１３ｂ内に該当するＩＰアドレスのエントリ（通信履歴）が存在しないため、ノード１、２がサーバ状態でもクライアント状態でもないと判断し、アクセス許可と判断する。スイッチ制御部１１ｂは、ＲＤＢ１３ｂに、パケットＡの送信元であるノード１のＩＰアドレス及びポート番号と、パケットＡの送信先であるノード２のＩＰアドレス及びポート番号を登録する（ステップＺ６、Ｚ７）。

ＲＤＢ１３ｂへの登録後、スイッチ制御部１１ｂは、ＦＤＢ１２ｂへ、パケットＡの送信先スイッチが接続されたスイッチ２０ｂのポート番号を問い合わせる（ステップＺ８）。ＦＤＢ１２ｂは、パケットＡの送信先ＭＡＣアドレス（ノード２のＭＡＣアドレス）に対するスイッチ２０ｂのポート番号を探す。なお、ＦＤＢ１２ｂに該当するポート番号がない場合、スイッチ制御部１１ｂは、スイッチ２０ｂのすべてのポート番号からパケットを送信することでフラッディングを行い、ノード２へパケットを届ける。

一方、ＦＤＢ１２ｂに、パケットＡの送信先ＭＡＣアドレスに対応するポート番号があった場合（ステップＺ９）、スイッチ制御部１１ｂは、Ｐａｃｋｅｔ−ｏｕｔメッセージにより、スイッチ２０ｂに、ノード２が接続されているポートからパケットを送信するよう指示する。さらに、スイッチ制御部１１ｂは、Ｆｌｏｗ−ｍｏｄメッセージにより、スイッチ２０ｂに、フローテーブル２３ｂにパケットＡの送信先を定めたエントリを追加するよう指示する（ステップＺ１０）。フローテーブル２３ｂにエントリを追加する際、現在許可したフローエントリ（ノード２からノード１はポート番号Ａ番に送信）と一緒に、逆向きのフローエントリ（ノード１からノード２はポート番号Ｂ番に送信）と登録してしまうこともできる。これは、ノード１からノード２へＲＤＰパケットを送信した後、ノード２からノード１への応答パケットが、ＲＤＢ１３ｂを参照するアクセス制御により届かなくなってしまうことを防ぐためである。

Ｐａｃｋｅｔ−ｏｕｔメッセージを受信したスイッチ２０ｂは、ＦＤＢ１２ｂに記載されている該当ポート番号からノード２に宛ててパケットＡを送信する（ステップＺ１１）。

パケットＡを受信したノード２は、パケットＡに対するＳＹＮ／ＡＣＫパケット（パケットＢ）を返す（ステップＺ１２）。パケットＡの時と同様に、スイッチ２０ｂは、自身のフローテーブル２３ｂを確認する（ステップＺ１３）。今回はパケットＡのやりとり時に生成されたフローエントリが登録されているので、スイッチ２０ｂは、制御装置１０ｂに対しＰａｃｋｅｔ−ｉｎを送信せず、フローエントリにて指定されたポートからパケットＢを送信する（ステップＺ１４）。

以上の動作で、ノード１からノード２へリモートログインできたことになる。

この状態で、図５に示すように、ノード２からノード３へアクセスを試みる。図２２に示すように、ノード２からノード３へパケットＣが送信されると（ステップＺ１５）、スイッチ２０ｂのスイッチ制御部１１ｂは、フローテーブル２３ｂに、パケットＣを処理するためのフローエントリが存在するか否かを確認する。この時点では、フローテーブル２３ｂにはパケットＡを処理するフローエントリは登録されていないため、スイッチ２０ｂは、制御装置１０ｂに対し、Ｐａｃｋｅｔ−ｉｎメッセージを送信する（ステップＺ１６）。Ｐａｃｋｅｔ−ｉｎメッセージによりパケットＣを受け取った制御装置１０ｂのスイッチ制御部１１ｂは、パケットＣの送信元ＩＰアドレスを基に、ＲＤＢ１３ｂ内に該当情報があるか検索する（ステップＺ１７）。パケットＡがノード２に届いた時点でＲＤＢ１３ｂに、「ノード２のＩＰアドレス、３３８９（ＲＤＰを表すポート番号）」が記載されているため、ＲＤＢ１３ｂからスイッチ制御部１１ｂに、３３８９という値が返される（ステップＺ１８）。スイッチ制御部１１ｂは、３３８９を受信すると、ノードＢがサーバ状態であると判定する。そして、パケット送信元がサーバ状態であるので、パケットを破棄するようスイッチ２０ｂに指示する（ステップＺ１９）。この時、ＲＤＰのポート番号３３８９以外のポート番号でアクセス制御をすることも可能である。

上記の動作によって、ノード２が踏み台となることを、防止することができる。

なお、非特許文献２のオープンフロースイッチは、Ｆｌｏｗ−ｒｅｍｏｖｅｄメッセージを用いて、オープンフローコントローラ（制御装置１０ｂ）に対し、フローエントリがタイムアウトしたことを通知できる。より具体的には、オープンフロースイッチのフローテーブル２３ｂのフローエントリにタイムアウトを設定し、一定期間該当パケットを受信しないなどしてタイムアウトが成立した時、スイッチ２０ｂは制御装置１０ｂに対して、Ｆｌｏｗ−ｒｅｍｏｖｅｄメッセージによってタイムアウトの通知を行う。Ｆｌｏｗ−ｒｅｍｏｖｅｄメッセージを受け取った制御装置１０ｂは、タイムアウトの通知に含まれている、パケットの送信先ＩＰアドレス、ポート番号を基に、ＲＤＢ１３ｂのエントリを検索し、削除を実行する。

［第４の実施形態］
続いて、より具体的な構成で第２の実施形態相当の機能を実現する本発明の第４の実施形態について説明する。図２３は、本発明の第４の実施形態の通信システムの構成を示す図である。図２３を参照すると、第１の実施形態の構成に加えて、制御装置１０ｂに、第２のテーブルに相当するアクセス制御ルールデータベース（アクセス制御ルールＤＢ）１３ｃと、第２のテーブルに相当するポリシーデータベース（ポリシーＤＢ）１３ｄを追加した構成となっている。

図２４は、ポリシーＤＢ１３ｄに保持されるノード状態判断用テーブルの一例を示す図である。図２４の例では、ポート番号３３８９（ＲＤＰ）を用いて、コネクションを受け付けたならサーバ状態とし、ポート番号３３８９を用いてコネクションを張ったならクライアント状態とする、という判定ポリシーが登録されている。コネクションを受け付けた側か、コネクションを張った側かの判断は、該当するＩＰアドレスが送信元に設定されているか、送信先に設定されているかによって判断できる（図２４の「ｓｒｃ／ｄｓｔ」参照。）。

図２５は、アクセス制御ルールＤＢ１３ｃに保持されるアクセス可否判断用テーブルの一例を示す図である。図２５の上から１番目のエントリは、ＩＰアドレス１９２．１６８．０．２のノードから、ＩＰアドレス１９２．１６８．０．３のノードへアクセスがあった場合、アクセスを許可するというルールとなっている。なお、本実施形態では、アクセス制御ルールＤＢ１３ｃによる判定がポリシーＤＢ１３ｄによる判定よりも優先されるものとする。このような優先度を持たせることにより、ＩＰアドレス１９２．１６８．０．２のノードが既にサーバ状態で動作している、もしくは、ＩＰアドレス１９２．１６８．０．３のノードが既にクライアント状態で動作していても、アクセスを許可する、という制御が可能となる。また、図２５の＊はすべてのＩＰアドレスを意味しており、既にクライアントとして動作していても、ＩＰアドレス１９２．１６８．０．１のノードへのアクセスは常に許可する、というルール（図２５の上から２つ目のエントリ）や、既にサーバとして動作していても、ＩＰアドレス１９２．１６８．０．３のノードからのアクセスは常に許可する、というルール（図１８の上から３つ目のエントリ）を設けることも可能となっている。

続いて、本実施形態の動作について図面を参照して詳細に説明する。以下、スイッチ２０ｂからのＰａｃｋｅｔ−ｉｎメッセージが制御装置１０ｂにパケットが届いた後から、受信パケットの処理が決定し、制御装置１０ｂからスイッチ２０ｂへＰａｃｋｅｔ−ｏｕｔメッセージ及びＦｌｏｗ−ｍｏｄメッセージを送信するところまでを詳細に説明する。なお、スイッチ２０ｂ内でのパケットの処理の仕方は、第３の実施形態と同様であるため、説明を省略する。

また、以下の説明では、第３の実施形態と同様に、図１９のノード１からノード２へリモートログインし、その後、ノード３へアクセスする状況を例に説明する。この際流れるパケットを図１９に示すようにパケットＡ〜Ｄと名付ける。なお、リモートログイン用のプロトコルとしては、ＲＤＰ（Ｒｅｍｏｔｅ Ｄｅｓｋｔｏｐ Ｐｒｏｔｏｃｏｌ）を用いるものとする。

次に、ノード１からノード２へリモートログインし、その後、ノード２がノード３へアクセスする状況を例に説明する。

図２６、図２７は本発明の第４の実施形態の通信システムの全体の動作を表したシーケンス図である。図２６のステップＶ１〜ステップＶ３までは、第３の実施形態の図２０のステップＺ１〜Ｚ３と同様である。

次にステップＶ４、ステップＶ５について、図２８、図２９を参照して詳細に説明する。Ｐａｃｋｅｔ−ｉｎメッセージによってＳＹＮパケット（パケットＡ）を受信すると（ステップＷ１）、スイッチ制御部１１ｂは、ＲＤＢ１３ｂから、当該パケットＡのヘッダ中のポート番号と、送信元ＩＰアドレス又は送信先ＩＰアドレスのいずれか適合するエントリを検索する（ステップＷ２）。この時点では、ＲＤＢ１３ｂに上記ＳＹＮパケットに対応するエントリは存在しないため、スイッチ制御部１１ｂは、ＲＤＢ１３ｂから、該当するＩＰアドレスが記載されたエントリが存在しないとの応答を受ける（ステップＷ３）。スイッチ制御部１１ｂは、ポリシーＤＢ１３ｄを参照することなく、ノード１、ノード２はいずれもクライアント状態及びサーバ状態のいずれでもないと判断する（ステップＷ４）。

次に、スイッチ制御部１１ｂは、アクセス制御ルールＤＢ１３ｃから、ＳＹＮパケット（パケットＡ）の送信元ＩＰアドレス、送信先ＩＰアドレスに示されるノードに適用すべきルールを検索する（ステップＷ５）。アクセス制御ルールＤＢ１３ｃが図２５のようなルールが格納されているとすると、上記ＳＹＮパケットに適合するするルールが存在しない。このため、スイッチ制御部１１ｂは、アクセス制御ルールＤＢ１３ｃから、該当するルールが存在しないとの応答を受ける（ステップＷ６）。

以上の結果、スイッチ制御部１１ｂは、図２９に示すように、パケットＡの送受信が可能であると判断し、ＲＤＢ１３ｂに対し、上記ＳＹＮパケットに対応するエントリを登録するようメッセージを送信し（ステップＷ８）、上記ＳＹＮパケットの送信元ＩＰアドレス又は送信先ＩＰアドレスのいずれかとポート番号とを対応付けたエントリを登録する（ステップＷ９、ステップＶ５）。

以降、図２９におけるステップＷ１０〜ステップＷ１２及び図２６〜図２７におけるステップＶ６〜ステップＶ１２は、それぞれ第３実施形態の図２１、２２のステップＺ８〜ステップＺ１０、ステップＺ１１〜ステップＺ１６と同様であるため説明を省略する。

その後、ノード２がパケットＣを送信した場合の動作のうち、図２７のステップＶ１３〜ステップＶ１５について、図３０を参照して詳細に説明する。まず、図２７のステップＶ１３について説明する。Ｐａｃｋｅｔ−ｉｎメッセージによりスイッチ２０ｂからパケットＣを受信すると（ステップＲ１）、スイッチ制御部１１ｂは、ＲＤＢ１３ｂから、ＰパケットＣの送信元、送信先ＩＰアドレス情報に対応するエントリを検索する（ステップＲ２）。この時点では、先のステップ図２９のＷ９にてＳＹＮパケットに対応するエントリを登録済みであるため、ＲＤＢ１３ｂには、ノード２の情報が登録されているため、ＲＤＢ１３ｂから、ノード２のＩＰアドレスが送信先であったという情報と、ポート番号を得る。一方、ノード３については、ＲＤＢ１３ｂの該当エントリが存在しないことが分かる。さらに、スイッチ制御部１１ｂは、ポリシーＤＢ１３ｄから、ノード２のＩＰアドレスが送信先であったという情報と、ポート番号に対応するエントリを検索する。以上の結果、スイッチ制御部１１ｂは、ノード２はサーバ状態で動作しており、ノード３はクライアント状態及びサーバ状態のいずれでもないことを判断する（ステップＲ４；図２４のポリシーＤＢ１３ｄの１番目のエントリ参照）。

次に、スイッチ制御部１１ｂは、アクセス制御ルールＤＢ１３ｃから、パケットＣの送信元ＩＰアドレス、送信先ＩＰアドレスに示されるノードに適用すべきルールを検索し、該当するルールがあるか確認する（ステップＲ５）。この結果、図２５に示す１９２．１６８．０．２（ノード２のＩＰアドレス）から１９２．１６８．０．３（ノード３のＩＰアドレス）へのアクセスを許可するとのルールが応答される。

以上の結果、スイッチ制御部１１ｂは、ノード２がサーバ状態であるものの、ノード２−ノード３間の通信を許可するアクセス制御ルールを優先し、アクセスは許可という判断をする。さらに、ステップＲ４によってノード３がＲＤＢ１３ｂに登録されていないことが判明しているので、スイッチ制御部１３ｂは、図３１に示すように、ＲＤＢ１３ｂに、ノード３の情報を登録するようメッセージを送信し（ステップＲ７）、送信先ＩＰアドレスとしてノード３のＩＰアドレスとポート番号とを対応付けたエントリを登録する（ステップＲ８、ステップＶ１４）。

その後の図３１のステップＲ９〜ステップＲ１１は、図２９のステップＷ１０〜Ｗ１２と同様であるため説明を省略する。再度、図２７を参照して説明を継続すると、スイッチ制御部１１ｂは、スイッチ２０ｂに対し、ノード３が接続されているポートよりパケットＣを送信することを指示するＰａｃｋｅｔ−ｏｕｔメッセージと、フローテーブル２３ｂにフローエントリを登録することを指示するＦｌｏｗ−ｍｏｄメッセージとを送信する（ステップＶ１５）。

前記各メッセージを受信したスイッチ２０ｂは、パケットＣをノード３へ送信する（ステップＶ１６）。このように、第１の実施形態ではノード２から送信することができなかったパケットＣが、第２の実施形態ではノード３へ到着することになる（ステップＶ１７）。

以上のように、本実施形態では、ＲＤＢ１３ｂ及びポリシーＤＢ１３ｄによるノード状態の判断よりもアクセス制御ルールを優先適用するため、例えば、アクセス制御ルールＤＢ１３ｃが図３２に示すようなルールであった場合、ステップＶ５の時点でノード１からノード２へのアクセスは拒否される。このため、ノード１、ノード２共に既にクライアント・サーバ状態となっていない場合でも、コネクションを確立させないことも可能である（ＳＹＮパケットを破棄する）。

もちろん、アクセス制御ルールよりも、ＲＤＢ１３ｂ及びポリシーＤＢ１３ｄによるノード状態による判断を優先させることも可能である。

［第５の実施形態］
続いて、位置情報も併用してノードの状態の判断を行うようにした本発明の第５の実施形態について説明する。図３３は、本発明の第５の実施形態の通信システムの構成を示す図である。図３３を参照すると、第１の実施形態の構成に加えて、制御指示装置１０ｅに、位置ベースポリシーテーブル１３ｅを追加した構成となっている。その他の構成は第1の実施形態と同様であるため、以下、その相違点を中心に説明する。

図３４は、本発明の第５の実施形態の制御指示装置によるノード状態の判定処理を説明するための図である。図３４の上段は、位置ベースポリシーテーブル１３ｅの例である。図３４の上段の上から１〜２番目のエントリは、同図下段に示すように、スイッチ＃１のノード＃１に接続されているノードについては、通信履歴に拘らず、サーバ状態と判定するとのポリシーを表している。上段の下から１〜３番目のエントリは、無線ＡＰを介してスイッチ＃３に接続されているノードについては、通信履歴に拘らず、クライアント状態と判定するとのポリシーを表している。また、図３４の例では、スイッチによってノードの属性が一意に決定できないスイッチ＃２については、ノード状態「Ａｎｙ」となっている。

以上のような本実施形態の制御指示装置１０ｅによれば、ノードの位置を併用したノードの判断を行うことができる。位置ベースポリシーテーブル１３ｅと、通信履歴による判断に優劣を付けることで、例えば、位置ベースポリシーテーブル１３ｅによればサーバ状態と判断すべき位置にあるノードであっても、特定の通信履歴を持つ場合には、クライアント状態と判断することができる。また逆に、例えば、通信履歴によればサーバ状態と判断すべき位置にあるノードであっても、特定の位置にある場合には、クライアント状態と判断することができる。また、位置ベースポリシーテーブル１３ｅにより、ノード状態が不定「Ａｎｙ」である場合にのみ、通信履歴による判断を行うようにすることもできる。

またあるいは、位置ベースポリシーテーブル１３ｅによる判断と、通信履歴による判断が一致した場合にのみ、ノードをサーバ状態、あるいは、クライアント状態と判断し、その他はサーバ状態及びクライアント状態のいずれでもないと判断するようにしてもよい。

また、上記第５の実施形態においても、第２、第４実施形態にて説明したアクセス制御ルールによる判断を行ってもよいことはもちろんである。

以上、本発明の好適な実施形態を説明したが、本発明の技術的範囲は、上記した各実施形態の記載に限定されるものではない。例えば、上記した第３、第４の実施形態では、非特許文献１、２のオープンフローの制御装置（コントローラ）とスイッチを用いるものとして説明したが、同等の機能を持つ制御装置と制御実施装置であればかまわない。

最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点による通信システム参照）
［第２の形態］
第１の形態の通信システムにおいて、
前記ノード状態判断部は、さらに、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断し、
前記制御指示部は、前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する通信システム。
［第３の形態］
所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置と、
前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断するノード状態判断部と、
少なくとも前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する制御指示部と、
を備える制御指示装置と、を含む通信システム。
［第４の形態］
第１から第３いずれか一の形態の通信システムにおいて、
さらに、ノード間の通信に適用するアクセス制御ルールを格納するアクセス制御ルール記憶部を備え、
前記ノードの状態と、前記アクセス制御ルールによる通信可否を用いて、前記新規通信を禁止するか否かを決定する通信システム。
［第５の形態］
第１から第４いずれか一の形態の通信システムにおいて、
さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記ノード状態判断部は、前記通信履歴管理部の通信履歴に加え、前記ノードの位置情報を参照して、ノードの状態を判断する通信システム。
［第６の形態］
第１から第４いずれか一の形態の通信システムにおいて、
さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、当該ノードから他のノードへの新規通信を禁止する通信システム。
［第７の形態］
第１から第４いずれか一の形態の通信システムにおいて、
さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、他のノードから当該ノードに対する新規通信を禁止する通信システム。
［第８の形態］
第１から第７いずれか一の形態の通信システムにおいて、
前記ノード状態判断部は、前記処理方法の問い合わせを受けたパケットを分析し、送信元のノードが、コネクション接続要求を発信したか、コネクションを受け付けたかに基づいて、前記ノードの状態を判断する通信システム。
［第９の形態］
第１から第８いずれか一の形態の通信システムにおいて、
前記制御実施装置は、前記制御指示装置から設定された制御指示を記憶するテーブルを備え、
前記パケット処理部は、前記テーブルから受信パケットに適合するマッチ条件を持つエントリを検索することで、前記制御指示装置からの指示に基づいたパケット処理を実行する通信システム。
［第１０の形態］
（上記第２の視点による制御指示装置参照）
［第１１の形態］
第３の形態対応の制御指示装置。
［第１２の形態］
（上記第３の視点による通信制御方法参照）
［第１３の形態］
第３の形態対応の通信制御方法。
［第１４の形態］
（上記第４の視点によるプログラム参照）
［第１５の形態］
第３の形態対応のプログラム。
なお、上記第１０〜第１５の形態は、第１の形態と同様に、第２、第４〜第９の形態に展開することが可能である。

なお、上記の特許文献および非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１０、１０ａ、１０ｅ 制御指示装置
１０ｂ、１０ｃ 制御装置
１１ 制御指示部
１１ｂ スイッチ制御部
１２、１２ａ ノード状態判断部
１２ｂ Ｆｏｒｗａｒｄｉｎｇ ＤＢ（ＦＤＢ）
１３ 通信履歴管理部
１３ａ テーブル群
１３ｂ Ｒｏｕｔｅ ＤＢ（ＲＤＢ）
１３ｃ アクセス制御ルールＤＢ
１３ｄ ポリシーＤＢ
１３ｅ 位置ベースポリシーテーブル
２０ 制御実施装置
２０ｂ スイッチ
２１、２１ｂ 通信部
２２、２２ｂ パケット処理部
２３ 指示キャッシュ
２３ｂ フローテーブル

Claims (15)

1. 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置と、
   前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
   前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部と、
   少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部と、
   を備える制御指示装置と、を含む通信システム。
2. 前記ノード状態判断部は、さらに、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断し、
   前記制御指示部は、前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する請求項１の通信システム。
3. 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置と、
   前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
   前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断するノード状態判断部と、
   少なくとも前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する制御指示部と、
   を備える制御指示装置と、を含む通信システム。
4. さらに、ノード間の通信に適用するアクセス制御ルールを格納するアクセス制御ルール記憶部を備え、
   前記ノードの状態と、前記アクセス制御ルールによる通信可否を用いて、前記新規通信を禁止するか否かを決定する請求項１から３いずれか一の通信システム。
5. さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
   前記ノード状態判断部は、前記通信履歴管理部の通信履歴に加え、前記ノードの位置情報を参照して、ノードの状態を判断する請求項１から４いずれか一の通信システム。
6. さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
   前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、当該ノードから他のノードへの新規通信を禁止する請求項１から４いずれか一の通信システム。
7. さらに、前記ノードの位置から、前記他のノードにサービスを提供する側にあるか否かを判断するためのノード状態判定テーブルを備え、
   前記制御指示部は、前記ノードの位置が所定の位置にある場合、前記ノード状態判断部の判断結果に拘らず、他のノードから当該ノードに対する新規通信を禁止する請求項１から４いずれか一の通信システム。
8. 前記ノード状態判断部は、前記処理方法の問い合わせを受けたパケットを分析し、送信元のノードが、コネクション接続要求を発信したか、コネクションを受け付けたかに基づいて、前記ノードの状態を判断する請求項１から７いずれか一の通信システム。
9. 前記制御実施装置は、前記制御指示装置から設定された制御指示を記憶するテーブルを備え、
   前記パケット処理部は、前記テーブルから受信パケットに適合するマッチ条件を持つエントリを検索することで、前記制御指示装置からの指示に基づいたパケット処理を実行する請求項１から８いずれか一の通信システム。
10. 制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
    前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するノード状態判断部と、
    少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する制御指示部と、
    を備える制御指示装置。
11. 制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部と、
    前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断するノード状態判断部と、
    前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する制御指示部と、
    を備える制御指示装置。
12. 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、
    前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータが、
    前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断するステップと、
    少なくとも前記ノードが他のノードにサービスを提供する側にある場合、他のノードから当該ノードへの新規通信を禁止するステップと、
    を含む通信制御方法。
13. 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、
    前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータが、
    前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断するステップと、
    少なくとも前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止するステップと、
    を含む通信制御方法。
14. 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、
    前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータに、
    前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードにサービスを提供する側にあるか否かを判断する処理と、
    少なくとも前記ノードが他のノードにサービスを提供する側にある場合、当該ノードから他のノードへの新規通信を禁止する処理と、
    を実行させるプログラム。
15. 所定の制御指示装置に対し、パケットの処理方法を問い合せる通信部と、前記制御指示装置からの指示に基づいて、パケットを処理するパケット処理部とを備える制御実施装置に接続され、
    前記制御実施装置を介したノード間の通信履歴を管理する通信履歴管理部を備えたコンピュータに、
    前記通信履歴管理部の通信履歴を参照して、処理方法の問い合せを受けたパケットの送信元又は送信先のノードが他のノードに対しサービスの提供を要求した側にあるか否かを判断する処理と、
    少なくとも前記ノードが他のノードに対しサービスの提供を要求した側にある場合、他のノードから当該ノードへの新規通信を禁止する処理と、
    を実行させるプログラム。

Images