JP2018125647A

JP2018125647A - 仮想閉域網の形成システム及び方法並びにプログラム

Info

Publication number: JP2018125647A
Application number: JP2017015223A
Authority: JP
Inventors: 健太川上; Kenta Kawakami; 章弘森田; Akihiro Morita; 則武　克誌; Katsushi Noritake; 克誌則武
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2017-01-31
Filing date: 2017-01-31
Publication date: 2018-08-09
Anticipated expiration: 2037-01-31
Also published as: JP6666863B2

Abstract

【課題】ＩｏＴに適した仮想閉域網の形成システム及び方法並びに提供する。【解決手段】端末１０に名前解決サービスを提供するグループ毎のＤＮＳプロセス１２０と、端末１０に払い出すＬ３アドレスとＤＮＳプロセス１２０のＬ３アドレスとを含む構成情報を端末１０毎に保持し端末１０に配布するＤＨＣＰプロセス１１０と、ゲートウェイ１３０とを備えた仮想ＣＰＥ１００を、ネットワーク２００側に配置する。ゲートウェイ１３０は、ＤＨＣＰプロセス１１０が配布した端末アドレスと該端末の属するグループ用のＤＮＳプロセス１２０応答したＬ３アドレスとの間のトラフィックのみを通過させるよう動的にフィルタリング設定を行う。【選択図】図２

Description

本発明は、端末を収容するネットワーク上に前記端末が所属するグループ毎の仮想閉域網を形成するシステムに関する。

現在、多様な端末がネットワークに接続するＩｏＴ（Internet of Thing）に関する検討が様々な標準化団体等で議論されている。ＩｏＴネットワークでは、多様な端末が接続する事から、端末種別毎の通信の頻度や帯域の振れ幅が大きく、個々の端末の挙動（バースト的なトラヒックの送出、監視カメラによる広帯域の占有等）によって、他の正常なサービス利用が阻害される懸念がある。また、同一仕様の端末が数多く分散して配置されるため、それらの端末のセキュリティの脆弱性を付いた攻撃が行われた場合にネットワーク全体への影響が非常に大きい。

これらの課題を解決するためには、個々のＩｏＴサービス毎にＶＰＮ（Virtual Private Network）等の閉域網を構築し、サービス間での相互干渉を防止する手法が一般的である。

吉田誠、他、「ＩｏＴを支える無線ネットワークの運用管理技術」、２０１６年電子情報通信学会総合大会、ＢＰ−５−４ Jungo Tsubakihara、「ＩｏＴソリューション導入の技術課題」、２０１６年電子情報通信学会総合大会、ＢＰ−５−６

しかし、ＶＰＮ技術による閉域網には以下に述べるような問題点がある（非特許文献１、２参照）。

１．端末に機能追加が必要である。

多様な端末が簡易にネットワークに接続できるようにするためには，端末にはネットワークに接続するための必要最低限の機能を具備するだけでＩｏＴネットワークに接続できる事が望ましい。しかし、ＶＰＮの場合は、トンネル制御のための機能を具備する必要があり、任意の端末が自由にネットワークに接続できる、というＩｏＴの理念から乖離している。

また、ＩｏＴ端末はネットワークに定常的に接続するため、サービス提供のコスト削減の観点から、必要となるマシンリソースは小さく、消費電力が少ない事が望ましい。しかし、ＩＰＳｅｃ等のＶＰＮ技術の実装は高コストであり、かつ消費電力やマシンリソースも大きい。

２．ネットワーク側でもトンネル制御のための機能追加が必要である。

また、ＩｏＴ固有の課題として、以下に述べるような問題点がある。

定期的なバーストトラヒックへの対処：ＩｏＴの様な機械端末では、ネットワークの接続が特定のタイミング（例：毎時０分，毎分０秒）に集中する事が多い。その様な定期的なバーストトラヒックに対して、サーバや通信路の輻輳が発生しやすい。

ＩｏＴネットワークでは、端末数が膨大で広範囲に散らばっているため、全ての端末を保守者が現地で維持メンテする事が困難である。

以上の議論より、以下の要件を設定した。

要件１：サービス毎のトラヒックの相互干渉の防止。通信の頻度や帯域の振れ幅が異なる多様な端末を同一ネットワークに収容し、かつ、サービス間での相互干渉を防止できる事。

要件２：端末への追加実装が不要。端末には要件１を実現するための固有の追加機能の実装が不要である事（ネットワークに接続するための必要最低限の機能のみを具備するだけでよい事）。

要件３：ネットワークへの追加実装が不要。ネットワーク側においても、要件１を実現するための固有の追加機能の実装が不要である事。

要件４：バーストトラヒックの抑止。定期的なバーストトラヒックによるトラヒックの輻輳を抑止する事ができる事。

要件５：端末の保守運用の簡素化。端末が正常な動作を行わなくなった場合の保守運用稼働が低減化されている事。

本発明は上記事情に鑑みてなされたものであり、その目的とするところは、上記要件を満たしＩｏＴに適した仮想閉域網の形成システム及び方法並びに提供することにある。

上記目的を達成するために、本願発明は、１以上の端末を収容するネットワーク上に前記端末が所属するグループ毎の仮想閉域網を形成する仮想閉域網の形成システムであって端末に名前解決サービスを提供するグループ毎の名前解決サーバと、端末に払い出すＬ３（Layer 3）アドレスと当該端末が属するグループ用の名前解決サーバのＬ３アドレスとを含む構成情報を端末毎に保持するとともにネットワークに接続しようとする端末に当該端末の構成情報を配布する構成情報配布サーバと、端末・ネットワーク間のトラヒックの中継及びパケットフィルタリングを行う中継装置と、を前記ネットワーク側に配置し、前記中継装置は、構成情報配布サーバが配布した端末のＬ３アドレスと該端末の属するグループ用の名前解決サーバが名前解決して該端末に応答したＬ３アドレスとの間のトラフィックのみを通過させるよう動的にフィルタリング設定を行うことを特徴とする。

本発明によれば、ネットワークに流入する端末のトラヒックは、当該端末の属するグループ毎に管理される名前解決サービスが応答したＬ３アドレス宛てのもののみとなるので、グループ間でのトラヒックの相互干渉を防止できる。また、端末として、構成情報配布サービスを利用した端末構成を行う一般的なものをそのまま用いることができる。また、名前解決サーバ及び構成情報配布サーバにおける各種データの管理によりトラヒック等をネットワーク側で一括して制御できるので、端末の保守運用を簡素化することができる。

本発明の世界観を説明するネットワーク図本実施の形態に係る仮想閉域網の形成システムを説明する図ＤＮＳプロセスの構成図ゲートウェイの構成図応答ドメインの限定によるトラヒックグループの区別について説明する図ＤＮＳクエリの集中とＴＴＬの関係を説明する図ＴＴＬの調整方法について説明する図

まず、本発明の目指す世界観について図１のネットワーク図を参照して説明する。本発明は、多様なＩｏＴ端末が、個々のサービス毎に相互干渉せずに共存できるネットワークの実現を目指すものである。

本発明では、まずＩｏＴ端末１０をトラヒックグループに分類する。ネットワーク２００には、ＣＰＥ（宅内通信設備：Customer Premises Equipment）の一部機能を仮想化した仮想ＣＰＥ１００を配置する。仮想ＣＰＥ１００は、グループ毎に仮想閉域網３００を形成する。仮想ＣＰＥ１００は、複数の仮想閉域網３００を形成することができる。なお図１では、各仮想ＣＰＥ１００はそれぞれ１つの仮想閉域網３００を形成している。仮想閉域網３００は、個々のトラヒックがグループ毎に独立しており、混ざり合う事が無い。仮想ＣＰＥ１００は、自身が対応する１つ以上のグループに属するＩｏＴ端末１０に、ＣＰＥの一部機能を提供する。ネットワーク２００側は、通常のパケット転送のみでよい。ＩｏＴ端末１０自身は、自分がどのトラヒックグループに属しているのかは意識しない、すなわちネットワーク２００側でトラヒック制御を行う。

ここで、図１は概念図である点に留意されたい。したがって、ネットワーク２００の形態は不問である。すなわち、ネットワーク２００は、１つ以上物理網により形成されていてもよいし、１つ以上の仮想網により形成されていてもよいし、１つ以上の物理網と仮想網の組み合わせであってもよい。また、物理網は、固定網であっても移動網であってもよいし、これらの組み合わせであってもよい。また、ＩｏＴ端末１０を収容するためのアクセス回線の形態も不問である。

次に、本実施の形態に係る仮想閉域網の形成システムについて図２を参照して説明する。仮想ＣＰＥ１００は、図２に示すように、構成情報配布サービスを提供するＤＨＣＰ（Dynamic Host Configuration Protocol）プロセス１１０と、グループ毎に形成され当該グループに属するＩｏＴ端末１０に名前解決サービスを提供する１つ以上のＤＮＳ（Domain Name System）プロセス１２０と、ＩｏＴ端末１０とネットワーク２００間のトラヒックを中継するゲートウェイ１３０とを備えている。

ＤＨＣＰプロセス１１０は、図２に示すように、ＩｏＴ端末１０に払い出すＬ３アドレスと当該ＩｏＴ端末が属するグループ用のＤＮＳサーバのＬ３アドレスとを含む構成情報１１１をＩｏＴ端末１０毎に保持する。なお、本実施形態では、Ｌ３アドレスの一例としてＩＰｖ６アドレスを用いる。また、ＩｏＴ端末１０を識別する情報としては、ＩｏＴ端末１０のＬ２アドレスであるＭＡＣ（Media Access Control）アドレスを用いる。

ＤＨＣＰプロセス１１０は、ＩｏＴ端末１０がネットワーク２００に接続しようとする際に、当該ＩｏＴ端末１０からの要求に応じて、当該ＩｏＴ端末１０を識別し、当該ＩｏＴ端末１０用に保持している構成情報１１１を応答する。ＩｏＴ端末１０は、受信した構成情報１１１に基づき、自身のＬ３アドレス及び名前解決の際に用いるＤＮＳサーバを設定する。

図３にＤＮＳプロセス１２０の構成図を示す。ＤＮＳプロセス１２０は、図３に示すように、名前解決処理部１２１と、ゾーンファイル１２２と、ＴＴＬ（Time To Live）調整部１２３とを備えている。

名前解決処理部１２１は、ＩｏＴ端末１０からの名前解決要求（ＤＮＳクエリ）に対してゾーンファイル１２２を参照して名前解決処理を行い、要求元にＩｏＴ端末１０に応答する。ゾーンファイル１２２は、仮想ＣＰＥ１００が対応する１つ以上のグループについてのゾーン情報を有している。このゾーン情報にはＴＴＬが含まれる。また、ＩｏＴ端末１０への応答にはＴＴＬが含まれる。ＴＴＬ調整部１２３については後述する。

図４にゲートウェイ１３０の構成図を示す。ゲートウェイ１３０は、図４に示すように、ＩｏＴ端末１０側とネットワーク２００側との間でパケットを中継するパケット中継部１３１を備えている。パケット中継部１３１は、フィルタリング処理部１３２と、フィルタ設定部１３４とを備えている。フィルタリング処理部１３２は、フィルタリング処理部１３２により動的に設定された通過トラヒック情報１３３を保持しており、この通過トラヒック情報１３３に合致するトラヒックのみを通過させ、他のトラヒックは廃棄する。フィルタ設定部１３４は、ＤＨＣＰプロセス１１０が配布した構成情報１１１及びＤＮＳプロセス１２０がＩｏＴ端末１０に応答した応答情報に基づき、前記通過トラヒック情報１３３を動的に設定する。通過トラヒック情報１３３は、図４に示すように、宛先のＬ３アドレスと送信元のＬ３アドレスの組を含む。

また、ゲートウェイ１３０は、図４に示すように、廃棄トラヒック集約部１３５を備えている。廃棄トラヒック集約部１３５は、フィルタリング処理部１３２で廃棄したトラヒックについての各種情報を集約し、所定の端末管理サイトに通知する。

本実施の形態に係る仮想閉域網の形成システムは、図２に示すように、以下のポイントを有している。

ポイント１：ゲートウェイにおける動的なトラヒックフィルタ設定
ポイント２：ゲートウェイにおける廃棄トラック関連情報の収集
ポイント３：応答ドメインの限定によるトラヒックグループの区別
ポイント４：名前解決応答におけるＴＴＬの変更によるクエリ集中の回避
ポイント５：ＣＰＥを仮想化する事による保守運用性向上
以下に上記各ポイントについて詳述する。

［ポイント１：ゲートウェイにおける動的なトラヒックフィルタ設定］
まず、図２に示すように、ＤＨＣＰプロセス１１０に予めＩｏＴ端末１０のＬ２アドレスと、当該ＩｏＴ端末１０が接続するトラヒックグループのテーブルを保持しておき、ＩｏＴ端末１０からのＤＨＣＰ要求に対して、ＩｏＴ端末のＬ３アドレスとＤＮＳプロセス１２０のＬ３アドレスを回答する（ステップ（１））。ＩｏＴ端末１０がＤＨＣＰによる回答に係るＤＮＳプロセス１２０に対してＤＮＳクエリを送信すると（ステップ（２））、当該ＤＮＳプロセス１２０が応答する（ステップＳ（３））。ＩｏＴ端末１０は、ＤＮＳ応答に係るＬ３アドレスを宛先アドレスとし、且つ、ＤＨＣＰ応答に係るＬ３アドレスを送信元アドレスとしたユーザ通信を行う。

そして、上記ポイント１は、ゲートウェイ１３０において、前記ステップ（１）とステップ（３）の情報からパケットフィルタを設定し、該当する通信のみを許容することである。

このようにポイント１では、仮想ＣＰＥ１００のゲートウェイ１３０にて動的なトラヒックフィルタを設定し、個々のトラヒックグループへの振り分けを実施する事で、サービス毎（グループ毎）のトラヒックの相互干渉を防止できる。また、上記のトラヒックグループへの接続の可否は上記ゲートウェイ１３０にて一元的に管理するため、個々のＩｏＴ端末１０やネットワーク２００では固有機能の具備が不要である。以上より、上記要件１、２、３が解決される。

[ポイント２：ゲートウェイにおける廃棄トラック関連情報の収集]
次に、上記ポイント２について説明する。上記ポイント２は、ゲートウェイ１３０において、廃棄トラヒックのデータを集約して仮想ＣＰＥ１００から所定の端末管理サイトに報告し、ＩｏＴ端末１０の保守運用に活用するものである。データ集約は、例えば通信データ（端末Ｌ３アドレス、通信内容）など端末保守での活用に有用なものを対象とすればよい。これらのデータは所謂ビッグデータとして、ビッグデータ解析に利用できる。また、保守管理の内容としては、例えば、遠隔での復旧操作、（必要に応じて）現地交換を実施、統計的な分析（セキュリティ攻撃の分析等）などが挙げられる。また、不正な動作を行っているＩｏＴ端末１０の検知を行う事で、不正端末の傾向分析を行うこともできる。このようにポイント２により、上記要件５が解決される。

［ポイント３：応答ドメインの限定による、トラヒックグループの区別］
次に、上記ポイント３について図５を参照して説明する。ＩｏＴ端末１０は、人間の機械端末の操作とは異なり、名前解決の問い合わせドメインのバリエーションは限定的であると想定される。このため、本システムでは、下位プロキシでは、それぞれ特定のドメインのみの応答を行うＤＮＳプロセスが複数設定される事を許容する（図５ではＤＮＳプロセス１，ＤＮＳプロセス２）。各々のＤＮＳプロセス１２０には、Ｌ３アドレスである所定のＩＰｖ６アドレスを付与する事とする。個々のＩｏＴ端末１０は、ＤＨＣＰ応答にてそれぞれのＩｏＴ端末１０の用途に適したＤＮＳプロセス１２０のＬ３アドレスが通知され、そのＬ３アドレスに対して名前解決要求を送出する事とする。

このようにポイント３では、個々のサービスに適したＤＮＳプロセス１２０を提供する事で、個別端末が接続できる通信相手を限定する事ができる。以上より、上記要件１，２，３が解決できる。

［ポイント４：名前解決応答におけるＴＴＬの変更によるクエリ集中の回避］
次に、上記ポイント４について図６及び図７を参照して説明する。図６はＩｏＴ端末のＤＮＳクエリとＴＴＬの関係を説明する図、図７はＴＴＬ調整方法について説明する図である。図６において、横軸は時間、縦軸はクエリ量を示す。図６に示すように、ＩｏＴ端末１０は、一定の間隔で繰り返しＤＮＳクエリを送出するケースが多い。

このようなケースにおいて、一定間隔でのＤＮＳクエリの集中を回避するために、ＤＮＳプロセス１２０のＴＴＬ調整部１２３は、ドメイン単位でクエリ推移を記録し、ドメインのキャッシュ保持時間（ＴＴＬ）と定期クエリ間隔の大小関係を判別する。そして、この大小関係に応じて、図７に示すようなＴＴＬの変更を行う事で、クエリ集中の回避と、クエリ総数の削減を実現する。

図７において、横軸は時間であり、横軸から上方に延びる矢印はＩｏＴ端末１０において名前解決を行うタイミングを示す。また、横軸上の長方形はＩｏＴ端末１０においてＴＴＬにより設定されたキャッシュ保持期間を示す。また、横軸下方の三角形は名前解決についてＤＮＳプロセス１２０にＤＮＳクエリを送信するタイミングを示す。

図７（ａ）はＴＴＬ＞定期クエリ間隔の場合を示す。この場合「通常時」は、各ＩｏＴ端末１０のＤＮＳクエリは定期的に送出され、これによりトラヒックが集中することになる。そこで、ＴＴＬ調整部１２３はＴＴＬを意図的に減算又は加算する。ＴＴＬ調整部１２３は、加減算とクエリ分散の変化を繰り返し学習する事で、加減算幅を最適に変更する。この減算処理によれば、図７（ａ）に示すように、通常時では各ＩｏＴ端末１０が同じタイミングでＤＮＳクエリを送出するところ、このタイミングがずれるのでトラヒック集中を回避できる。一方、加算処理によれば、図７（ａ）に示すように、ＤＮＳクエリの総数を削減することができる。

図７（ｂ）はＴＴＬ＜定期クエリ間隔の場合を示す。この場合「通常時」は、ＤＮＳクエリは各ＩｏＴ端末１０において名前解決を行うタイミングで毎回送出され、クエリ総数が大きくなる。そこで、ＴＴＬ調整部１２３はＴＴＬを意図的に加算（延長）する。ＴＴＬ調整部１２３は、延長とクエリ減少の変化を繰り返し学習する事で、延長幅を最適に変更する。この加算処理によれば、図７（ｂ）に示すように、ＤＮＳクエリの総数を削減することができる。

このようにポイント４では、ＴＴＬを変更させる事で、定期的なクエリ要求に対するバーストトラヒックを低減させ、耐性を向上させることができる。以上より上記要件４を解決する。

［ポイント５：ＣＰＥを仮想化する事による保守運用性向上］
次に、上記ポイント５について図２を参照して説明する。本システムにおけるＣＰＥは、図２に示すような構成情報１１１が必要であり、これらの維持管理が必要となる。本システムでは、ネットワーク２００側において、すなわち仮想ＣＰＥ１００において一括で管理するので、保守運用性の向上と、管理権限の厳格化（悪意のあるユーザが任意の操作をできないようにする）を実現する。このようにポイント５により、上記要件５を解決する。

以上本発明の一実施の形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施の形態では構成情報配布サービスとしてＤＨＣＰを例示し、名前解決サービスとしてＤＮＳを例示したが、それぞれ他のプロトコルであっても本発明を実施できる。また、上記実施の形態ではＬ３アドレスとしてＩＰｖ６、Ｌ２アドレスとしてＭＡＣアドレスを例示したが、それぞれ他のプロトコルに係るアドレスであっても本発明を実施できる。また、本実施の形態ではＩｏＴ端末について説明したが、その他の端末であっても本発明を実施できる。

１０…ＩｏＴ端末
１００…仮想ＣＰＥ
１１０…ＤＨＣＰプロセス
１１１…構成情報
１２０…ＤＮＳプロセス
１２１…名前解決処理部
１２２…ゾーンファイル
１２３…ＴＴＬ調整部１２３
１３０…ゲートウェイ
１３１…パケット中継部
１３２…フィルタリング処理部
１３３…通過トラヒック情報
１３４…フィルタ設定部
１３５…廃棄トラヒック集約部
２００…ネットワーク

Claims

１以上の端末を収容するネットワーク上に前記端末が所属するグループ毎の仮想閉域網を形成する仮想閉域網の形成システムであって、
端末に名前解決サービスを提供するグループ毎の名前解決サーバと、端末に払い出すＬ３アドレスと当該端末が属するグループ用の名前解決サーバのＬ３アドレスとを含む構成情報を端末毎に保持するとともにネットワークに接続しようとする端末に当該端末の構成情報を配布する構成情報配布サーバと、端末・ネットワーク間のトラヒックの中継及びパケットフィルタリングを行う中継装置と、を前記ネットワーク側に配置し、
前記中継装置は、構成情報配布サーバが配布した端末のＬ３アドレスと該端末の属するグループ用の名前解決サーバが名前解決して該端末に応答したＬ３アドレスとの間のトラフィックのみを通過させるよう動的にフィルタリング設定を行う
ことを特徴とする仮想閉域網の形成システム。
前記中継装置は、廃棄したトラヒックの情報を集約する廃棄トラヒック収集部を備えた
ことを特徴とする請求項１記載の仮想閉域網の形成システム。
前記名前解決サーバは、自身のグループに対応する所定のドメイン名のみを名前解決する
ことを特徴とする請求項１又は２記載の仮想閉域網の形成システム。
前記名前解決サーバは、端末からの名前解決要求の間隔に基づき当該名前解決に係るドメインのＴＴＬを調整するＴＴＬ調整部を備えた
ことを特徴とする請求項１乃至３何れか１項記載の仮想閉域網の形成システム。
前記名前解決サーバと、前記構成情報配布サーバと、前記中継装置とを、ネットワーク側の装置上のプロセスとして仮想化した仮想ＣＰＥとして配置した
ことを特徴とする請求項１乃至４何れか１項記載の仮想閉域網の形成システム。
１以上の端末を収容するネットワーク上に前記端末が所属するグループ毎の仮想閉域網を形成する仮想閉域網の形成方法であって
端末に名前解決サービスを提供するグループ毎の名前解決サーバと、端末に払い出すＬ３アドレスと当該端末が属するグループ用の名前解決サーバのＬ３アドレスとを含む構成情報を端末毎に保持するとともにネットワークに接続しようとする端末に当該端末の構成情報を配布する構成情報配布サーバと、端末・ネットワーク間のトラヒックの中継及びパケットフィルタリングを行う中継装置と、を前記ネットワーク側に配置し、
前記端末が、前記ネットワークへの接続の際に前記構成情報配布サーバから受信した構成情報に基づき自身のＬ３アドレス及び自身が利用する名前解決サーバのＬ３アドレスを設定するステップと、
前記端末が、設定した名前解決サーバに名前解決要求を行うステップと、
名前解決サーバが、要求元の端末に名前解決応答を送信するステップと、
前記中継装置が、前記端末に設定されたＬ３アドレスと前記名前解決サーバが名前解決して該端末に応答したＬ３アドレスとの間のトラフィックのみを通過させるよう動的にフィルタリング設定を行うステップとを備えた
ことを特徴とする仮想閉域網の形成方法。
コンピュータを請求項１乃至５に記載の各部として機能させることを特徴とするプログラム。