セキュリティ機能を有するＩＰネットワーク通信方法及び通信システム
【課題】ＩＰsec等の適用により増加するCPU負荷による処理遅延を軽減し、ネットワークのデータ伝送効率低下を軽減する。
【解決手段】セキュリティ機能を有するＩＰネットワーク通信システムであって、送信データを複数のパケットに分割する手段と、前記分割された複数のパケットの一部のパケットのみに暗号化を行い、残りのパケットは非暗号化とする手段と、前記暗号化されたパケットと非暗号化のパケットを送信する送信手段を、有する。
【解決手段】セキュリティ機能を有するＩＰネットワーク通信システムであって、送信データを複数のパケットに分割する手段と、前記分割された複数のパケットの一部のパケットのみに暗号化を行い、残りのパケットは非暗号化とする手段と、前記暗号化されたパケットと非暗号化のパケットを送信する送信手段を、有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セキュリティ機能を有するＩＰネットワーク通信方法及び通信システムに関する。
【背景技術】
【０００２】
移動通信システムにおいて、システムを構成する各ネットワーク機器（無線基地局装置、無線基地局制御装置、交換装置等）を接続する回線には、一般的にＡＴＭ(Asynchronous Transfer Mode：非同期転送モード)回線及びＩＰ（Internet Protocol：インターネット・プロトコル）回線が多く用いられている。
【０００３】
現在検討が盛んに行なわれている、次世代移動通信システム（LTE：Long Tern Evolution, SAE：System Architecture Evolution, ECN：Evolved Core Network, WiMAX, 4G等）においては、そのネットワーク機器接続回線にＩＰ網を定義することを検討されている通信システムが多くある。
【０００４】
このため、移動通信システムにおいても、全ＩＰ（Internet Protocol Network）網に接続される、一サービスとして実現されようとしている。
【０００５】
このように、現在のインターネット等のＩＰ通信等も含めて、あらゆる通信がＩＰという共通の基盤を利用したサービスへと移行してきている。
【０００６】
これらのＩＰ上で通信するサービスには、さまざまなタイプがあり、たとえば、音声や動画のように遅延の少ない通信が要求されるものや、大量のデータを高速に伝送することが要求されるもの等がある。
【０００７】
大量にデータを通信する場合は、ＩＰ回線にはパケット長が大きな（パケット長が長い）パケットを使用する方が伝送効率はよくなる。しかし、大きなパケットを伝送するには、長い時間ＩＰ回線を占有することになり、この占有時間のために遅延の少ない通信を要求するサービスの妨げとなる可能性がある。
【０００８】
このために、遅延の少ない通信の品質を確保するためには、大きなパケットは分割(fragment)して送信することが一般的である。
【０００９】
一方、通信の安全性についても関心が高まってきている。サービス提供者においては、自サービスの通信安全性などを考慮し、暗号化通信によるセキュリティ対策に関する課題対策を行うことが望ましい。
【００１０】
なお、ネットワーク回線においては、その回線上のアプリケーションに関係なく、すべての通信を自動的に暗号化可能とする技術として、ＩＰsec（ＩＰ security Protocol）を採用する方向で各種検討がされている。
【００１１】
以下、図１にLTEシステムを例として、ＩＰsec対象区間となりうる回線例を示す。図１において、無線基地局（ｅＮＢ）１，２間、及び無線基地局１，２とゲートウエイ３との間が、ＩＰsecトンネル４，５，６によりＩＰsec対象区間となり得る。
【００１２】
さらに、図２にＩＰsec適用可能なレイヤ構造を示す。図２において、移動局装置MS、無線基地局ｅＮＢ、ネットワーク制御装置ＮＣＵ間のユーザプレーンデータプロトコルスタックが示される。かかるスタックレイヤにおいて、無線基地局ｅＮＢとネットワーク制御装置ＮＣＵ間において、ＩＰsecの適用(図２、A)が可能である。
【００１３】
図３にＩＰsecのプロトコルを示す。図３において、通常パケットAを暗号化する際は、暗号化されていることを示す暗号化ヘッダBとトレーラーCが付加される。そして、通常パケットAとトレーラーCを含む範囲が暗号化され（図３、D）、暗号化ヘッダBを含む範囲が送信側と受信側との間で認証される。
【００１４】
さらに、暗号化されたパケットを、暗号通信用トンネルを通して送信するために、新ヘッダEとトレーラーFが付加される。
【００１５】
ここで、ＩＰsec技術を適用するには、各種キー(key)交換をネットワーク装置間で定期的に実施することが望ましく、ＩＰsec専用プロトコル終端部を整備するのが好ましい。
【００１６】
かかる場合、ＩＰsec専用プロトコル終端に関わる技術を適用するデータレイヤや対象データ伝送量などにも起因するが、伝送装置自体の処理能力を大きく損なうことが懸念される。
【００１７】
一般的にはＩＰsecを適用するか否か（ＩＰsec on/off）でプロトコル終端部の性能は３〜４割程度異なるといわれている。
【００１８】
また、ＩＰsec適用時には図３で説明したように、暗号通信用のヘッダ、トレーラー(図３:Ｄ、Ｂ)等を追加すると、データ容量が増加する。このためにデータ伝送効率を下げる要因になる。
【００１９】
図４に、ＩＰsec適用時のデータ伝送効率を示す。横軸にフレームサイズ、縦軸にスループットを示す。図４において、ＩはＩＰsec offの時、ＩＩは、ＩＰsec onの時の伝送効率を示している。
【００２０】
図４に示すように、ＩＰsec on/offによるデータ伝送効率の理論値変化は、何れの場合もパケット長が短い（フレーム長が短い）程下がり、最短パケット(64byte/packet) 時には、ＩＰsec非適用の場合（Ｉ）に比べ４割程度下がる。
【００２１】
一方、ネットワーク上に音声データ等、データ遅延を一定時間以下に抑えることが望ましいサービスが存在する場合、パケット長をある程度短く抑えることが望ましい。長いパケットは、伝送するために長い時間ネットワークを占有し (遅延制限のある)音声データ等を待たせてしまうため、予め短いパケットに分割（フラグメント：fragment）する。
【００２２】
従来技術として、暗号処理を行うベきパケットに、パケットヘッダの特定のフィールドをハッシュキーとして得たハッシュ値毎に異なる識別子を付与して、順序保証、並列処理を行う技術がある（特許文献１）。
【特許文献１】特開２０００−３１５９９７号公報
【発明の開示】
【発明が解決しようとする課題】
【００２３】
しかし、フラグメントするということはパケット長を短くすることであり、図４について述べたように伝送効率を下げる要因となる。
【００２４】
一方、高速なイーサネット（Ethernet）（登録商標）の普及とともに、大容量のデータやプライベートなデータをEthernet（登録商標）で伝送する機会が多くなり、データセキュリティ対策の効率化が求められる。
【００２５】
したがって、一目的は、ＩＰsec等の適用により増加するCPU負荷による処理遅延を軽減し、ネットワークのデータ伝送効率低下を軽減する暗号化を適用するＩＰネットワーク通信システムを提供することにある。
【課題を解決するための手段】
【００２６】
昨今の大容量の通信データ は、ZIP等のバイナリの圧縮データやmpeg等の映像や音声の圧縮データが多い。これらの圧縮データは、その先頭部分にデータを復元するための情報を含んでいることがほとんどである。そして、かかる部分を暗号化し、復号できない状態では、これらの圧縮データを正確に復元できなくなる場合が多い。
【００２７】
したがって、ネットワークに要求のある、ＩＰsec等のセキュリティ技術を、パケット全体に適用するのではなく、その一部であって、セキュリティが必要な部分にのみ適用する。
【００２８】
一構成例として、セキュリティ機能を有するＩＰネットワーク通信システムであって、送信データを複数のパケットに分割する手段と、前記分割された複数のパケットの一部のパケットのみに暗号化を行い、残りのパケットは非暗号化とする手段と、前記暗号化されたパケットと非暗号化のパケットを送信する送信手段を有する。
【００２９】
これにより、ＩＰsec等の適用により増加するCPU負荷による処理遅延を軽減し、ネットワークのデータ伝送効率低下を軽減する。
【発明を実施するための最良の形態】
【００３０】
以下に図面に従い、実施例を説明する。
【００３１】
図５は、ＩＰsecが適用可能なＩＰネットワーク通信システムの実施例構成を示すブロック図である。同様構成であるので、双方向通信における片方向通信側分の構成のみを示している。
【００３２】
ＩＰネットワーク通信システムにおいて、送信側データ送信装置２０と受信側データ受信装置４０が、ネットワーク３０を通して接続される。送信側データ送信装置２０の入力側には入力インタフェース１０が備えられる。
【００３３】
ネットワーク３０は、暗号化しないセッション用パケット(通常パケット)用の経路３１を有し、後で説明するように、暗号化したデータの通信セッションの際に暗号通信用トンネル３２と、暗号制御用トンネル３３が形成される。
【００３４】
図５において、送信側データ送信装置２０の入力インタフェース１０のバッファ１１に、他伝送装置または、自伝送装置におけるデータ源からのパケットデータが入力される。
【００３５】
送信パケット生成部１２は、バッファ１１から読み出されるパケットデータを所定のデータ長にフラグメント化する。
【００３６】
セッション制御部１３は、バッファ１１に入力するパケットデータについて、送信パケット生成部１２でフラグメント化されたフラグメント情報に基き、フラグメントパケット毎にセッション、QoS（Quality of Service）を判定して、セッション単位に暗号化通信でなければ、送信パケット生成部１２及び第１のＩＰsec on/off部２４に非暗号化通信を指示する。
【００３７】
これにより、送信パケット生成部１２は、バッファ１１からのパケットデータをフラグメント化したまま出力してデータ送信装置２０のセレクタ２５に入力する。
【００３８】
第１のＩＰsec on/off部２４は、セッション制御部１３からの非暗号化の指示を受けているので、セレクタ２５をネットワーク３０の通常パケット経路３１を通るように設定する。
【００３９】
図６は、図５のデータ伝送装置２０から送信されるパケットデータを示す図である。図６において、図６Ａは、送信パケット生成部１２によりバッファ１１からのパケットデータ（A）を複数のパケット（B）にフラグメント化した状態を示している。
【００４０】
図６Ｂは、これまでのパケットデータの暗号化の方法に対応するパケットデータの例である。セッション制御部１３による判定処理に基づき、送信パケット生成部１２から出力される複数のフラグメント化された全てのパケットに暗号化処理のためのヘッダ（IA）とトレーラ（IB）が付加され、暗号通信用トンネル３２を通すためのヘッダ（IIA）とトレーラ（IIB）が付加されている。
【００４１】
ここで、暗号化処理のための、ネットワーク３０における暗号通信用トンネル３２及び暗号制御用トンネル３３を生成するシーケンスについて図７を説明する。
【００４２】
すなわち、図７において、ＩＰsec通信に先立つフェーズ１及びフェーズ２の処理を有する。
【００４３】
フェーズ１において、送信側伝送装置Aと受信側伝送装置Bとの間で暗号制御用トンネル３３を形成するために、暗号制御用トンネル３３で使用するアルゴリズム（暗号algorithm、認証algorithm等）を通常パケット用の経路３１を通して決定する（処理工程Ｐ１１）。
【００４４】
ついで、同様に通常パケット用の経路３１を通して、処理工程Ｐ１１で決定されたアルゴリズムを使って暗号制御用トンネル３３の暗証鍵を決定する（処理工程Ｐ１２）。これにより、暗号制御用トンネル３３が形成される。
【００４５】
さらに、フェーズ１において、処理工程Ｐ１１，１２により決定された暗号制御用トンネル３３を使用して、伝送装置Ａ，Ｂ間で相互に通信相手の認証を行う（処理工程Ｐ１３）。
【００４６】
フェーズ２において、フェーズ１で生成された暗号制御用トンネル３３を使って、伝送装置Ａ，Ｂ間で、暗号通信用トンネル３２で使用する暗号鍵とアルゴリズムを決定する（処理工程Ｐ２１）。さらに、伝送装置Ａは、伝送装置Ｂに対して決定された暗号通信用トンネル３２で使用する暗号鍵とアルゴリズムを確認する（処理工程Ｐ２２）。
【００４７】
以降、生成された暗号通信用トンネル３２を使用して暗号化通信（ＩＰsec）を行う（処理工程Ｐ３）。
【００４８】
図８Ａ，図８Ｂは、第1の実施例における送信側装置Ａ(図８A)と、受信側装置Ｂ（図８B）の処理フローを示す。
【００４９】
先ず、セッション制御部１３は、バッファ１１のパケットデータに基づき、セッション単位に暗号化送信か否かを判定する（ステップＳ１）。暗号化送信でなければ（ステップＳ１、Ｎ）、バッファ１１から出力され、フラグメント化されたパケットは、通常パケット送信経路３１を通してデータ受信装置４０に送られ、バッファ１１のパケットデータが途切れるまで送信が継続する（図８Ａ，ステップＳ８、Ｓ９）。このとき送信されるパケットは、図６Ａの（B）に示したと同様である。
【００５０】
ステップＳ１でセッション制御部１３がパケットデータに基づき、セッション単位に暗号化通信か否かを判定して、暗号化通信であれば（ステップＳ１、Ｙ）、図７により説明したように暗号化準備としてフェーズ１，２により暗号通信用トンネル３２及び暗号制御用トンネル３３を形成する（ステップＳ２）。受信側装置４０においては、送信側装置とで確認した暗号鍵を保存する。
【００５１】
図８Aにおいて、第１の実施例としてフラグメント化された複数のパケットについて、パケット単位に暗号化送信する対象か否かを判定する（ステップＳ３）。すなわち、複数のパケット内の一部のパケットのみ、例えば、先頭パケットのみをIPsec通信を適用し、一セッションにおける残りの分割パケットは、暗号化せずに送信する。
【００５２】
例えば、先頭パケットのみを暗号化するようにすると、送信処理対象が先頭パケットのときに（ステップＳ３、Ｙ）、ＩＰsec コントローラ２１内の第１のＩＰsec on/off部２４に対し、セレクタ２５で先頭パケットのみをＩＰ暗号化部２６に出力するように切替え制御させる。
【００５３】
同時に、第２のＩＰsec on/off部２３に指示を行い、暗号鍵生成部２２により生成される暗号鍵を用いて、ＩＰsec暗号化部２６により先頭パケットのみを暗号化させる。このようにフラグメント化されたパケットの一部のみに対して暗号化する（ステップＳ５）。
【００５４】
図６Cに示すように、第１の実施例においては、暗号化される先頭パケットには、暗号化ヘッダ（IA）とトレーラー（IB）が付加され、更にその外側に、暗号通信用トンネル３２を通過させるためのヘッダIIAとトレーラー（IIB）が付加される。
【００５５】
一方、第１の実施例において、先頭パケットに続くパケットには、暗号化しなくてもよいので、暗号化用ヘッダIAのみ付され、受信側装置との間で認証しなくてもよいので暗号通信用トンネル３２を通過させるためのヘッダIIAのみが付加されている（ステップＳ４）。暗号化用トレーラー（IB）及び認証用トレーラー（IIB）は、付加されていない。
【００５６】
そして、暗号化された一部のパケット（例えば、先頭パケット）と、他のフラグメント化されたパケットは、バッファ１１にデータがなくなるまで暗号化通信用トンネルに送出される。（ステップＳ６、Ｓ７）。
【００５７】
ここで、暗号化精度を高めるために、暗号鍵に有効時間が設定されている。暗号鍵の有効時間がタイムアウトする場合（ステップＳ５、Ｙ）は、ステップＳ２に戻り再度暗号化準備処理を行って、以降の処理を継続する。
【００５８】
図８Ｂは、図８Ａの送信側装置の処理フローに対応する、受信側装置の処理フローである。図５を参照して説明する。
【００５９】
データ受信装置４０は、通常パケットの経路３１、暗号通信用トンネル３２及び暗号制御用トンネル３３のそれぞれについて、パケットを受信する。
【００６０】
ＩＰsec復号化部４２において、暗号通信用トンネル３２から受信されるパケットについて、暗号化ヘッダの有無によって、暗号化パケットか否かを判定する（ステップＳ１０）。
【００６１】
さらに、データ受信装置４０は、暗号化通信に先立って送信側装置とで決定した暗号鍵を、復号用暗号鍵生成部４１に保持している。
【００６２】
図５において、暗号通信用トンネル３２から受信されるパケットのヘッダ情報と復号用暗号鍵生成部４１に保持している暗号鍵に基づき、復号用暗号鍵生成部４１は、復号用暗号鍵を生成する。そして、生成された復号用暗号鍵を用いて、ＩＰsec復号化部４２において、暗号化パケットを復号する（ステップＳ１１）。
【００６３】
このように、ＩＰsec復号化部４２において、暗号化されているパケットは復号化され、非暗号化のパケットはそのままで、図５において図示されないアセンブル回路に入力される。そして、受信、復号されたパケットはフラグメント化されているのでアセンブル回路で、再組み立てされて、元のパケットデータを受信装置側で得ることができる。
【００６４】
かかる第１の実施例において、フラグメントされたデータの複数のパケットのうち先頭のパケットのみにＩＰsecを適用し、残りのパケットは、ＩＰsec非適用で暗号通信用トンネルに送信する等、暗号化適用データ範囲を減らすことができる。
【００６５】
このため、データ全体を通信網にさらさないのでセキュリティは確保しつつ、且つ暗号化off時にESP header（IA）等を省略できるのでネットワーク負荷と 暗号化に必要な処理を省略できる。
【００６６】
したがって、 CPUの負荷を軽減し、遅延の少ない通信が可能となる。なお、この実施例では、データ受信装置側は、ＩＰsecのESP header（IA）により暗号化の適用・非適用がパケット単位で判断可能なため特別な機能追加を行わなくてもよい。
【００６７】
図９は、第２の実施例に対応する送信側伝送装置の処理フローである。
【００６８】
この実施例では、先の第１の実施例におけると同様に、フラグメントされたパケットの一部、例えば、先頭パケットのみを暗号化を行う。そして、それ以降のフラグメントされたパケットは暗号化せずに通常パケットの経路３１を通過するように、セッション制御部１３により第１のＩＰsec on/off回路２４に指示してセレクタ２５を切換制御する。
【００６９】
したがって、第２の実施例のパケットデータを示す図６Dにおいて、先頭パケットに対し、暗号化ヘッダ（IA）及びトレーラー（IB）が付加され、暗号通信用トンネル３２を通過させるためのヘッダ（IIA）とトレイラー（IIB）が付加されている。
【００７０】
それ以降のパケットは、フラグメント化された状態のままであり、通常パケット経路３１により送信される。
【００７１】
したがって、図９において、第１の実施例に対応する図８の処理フローと比較すると、ステップＳ４の処理が、ステップＳ４Aに置き換えられている点のみが異なる。
【００７２】
すなわち、先頭パケットを除き、暗号化送信パケットでないと判定される（ステップＳ３、N）と、フラグメントされたパケットの状態のままで（図６D, III）、通常パケットの経路３１により送信される。その他の処理は、第１の実施例と同様である。
【００７３】
かかる第２の実施例では、上記のように、同じセッション内でＩＰsecがonのパケットは、暗号通信トンネル３２を使って送信され、ＩＰsecがoffのパケットは、トンネルを使わず通常パケットとして通常パケット経路３１で送信する。このため、本実施例において、ＩＰsec offの場合のパケットは、第１の暗号化offの場合のパケットから暗号通信用トンネル３２に送信するためのheader等を省略でき、第１の実施例に比べ、更にネットワーク負荷とCPUの負荷を軽減することが可能である。
【００７４】
なお、第１の実施例と同様に、本実施例のデータ受信装置側には、本実施例の実行のために特別な機能を追加しなくてもよい。
【００７５】
図１０は、更に第３の実施例に対応する送信側伝送装置の構成例ブロック図である。
【００７６】
この実施例では、送信装置２０の入力インタフェース部１０にパケットをフラグメント化する送信パケット生成部１２を有していない。
【００７７】
セッション制御部１３は、バッファから読みだされる送信パケットに対し、送信パケットの一部をＩＰsecの適用範囲に指定する。このＩＰsecの適用範囲は、セッション情報、QoS等の情報に基き、予め設定した条件に対応するように決められる。
【００７８】
すなわち、セッション制御部１３は、バッファ１１からデータ送信装置２０に入力されるパケットに同期して、ＩＰsecコントローラ２１の暗号鍵生成部２２Aに暗号化適用範囲を通知する。
【００７９】
ＩＰsec暗号化部２６は、暗号鍵生成部２２A からの暗号化適用範囲に対応するタイミングでの暗号化指示に従い、暗号化を行って、一パケット中の暗号化された部分及び、該当のパケットの残りの部分と共に、ネットワーク３０の暗号通信用トンネル３２を通して、受信側伝送装置４０に送信する。
【００８０】
図１１A−図１１Cは、かかる第３の実施例に対応する暗号化パケットの例を示す図である。
【００８１】
図１１Aは、通常のＩＰsecを示す図であり、送信すべきパケットと、パケットに付加された暗号化用トレーラーIBの範囲をＩＰsecの適用範囲としている。これに対し、図１１B, 図１１C に示すように、第３の実施例では、送信対象である一つのパケット中の任意の範囲を暗号化対象としている。
【００８２】
具体的には、図１１Bの例では、パケットのヘッダ部の途中を暗号化開始位置とし、その後の所定のＩＰsec長の範囲を暗号化領域としている。さらに、図１１Cの例では、所定の部分領域を暗号化される領域とし、それに続く非暗号化の部分を含めた長さ領域をＩＰsecの適用パターン長として、かかるパターンを繰り返すように設定する（図１１C, III1, III2, III3）。なお、最後のパターン領域はパターン長が、途中までとなる場合があり、図１１Cは、かかる場合を示している。
【００８３】
図１２A, 図１２Bは、第３の実施例に対応する送信側伝送装置（図１２A）と受信側伝送装置（図１２B）の処理フローである。
【００８４】
図８A, 図８Bに示した第1の実施例の処理フローとの比較において、パケット単位での暗号化送信の適用判断（図８A、ステップＳ３）を行わずに、セッション制御部１３により、送信処理対象のパケットに対して予め設定したＩＰsec適用範囲について、暗号化処理を実行する（ステップＳ５Ａ）。他の処理は、先の実施例の処理フローと同様である。
【００８５】
図１２Bにおける受信側伝送装置の処理フローにおいては、暗号化パケットと判断されるとき（ステップＳ１０、Ｙ）、ＩＰsec復号化部４２は、ヘッダ部の情報に基き、暗号化パケットにおける暗号化されている領域について、復号化を行う（ステップＳ１１A）。他の処理は、先の実施例と同様である。
【００８６】
この第３の実施例では、上記に図１０、図１１A−図１１Cで説明した通り、ＩＰsecで通信を行うデータ送信側伝送装置・データ受信側伝送装置において、a) 暗号鍵の交換時等に、ＩＰsecの適用範囲、例えば、先頭何byte目から何byte間のデータにＩＰsecを掛けたり、暗号化パターン(パターンにより斑に暗号化する) 等の情報をデータ送受信双方で共有し、b) この情報に従ってデータの限定した領域のみＩＰsecを施し、c) この情報に従って限定した領域にＩＰsecがかけられたデータを復元することで実現される。
【００８７】
さらに、図７で説明した暗号か準備のための処理フェーズ１，２の基本は変わらないが、ＩＰsecのフェーズ２で扱うデータに暗号化パターンが追加される。
【００８８】
また、本実施例として、図１０の送信側伝送装置のインタフェース部１０において、送信パケット生成部１２を設けないで、フラグメントされていないパケットにおいてＩＰsec適用範囲を設定するように説明したが、当然にフラグメントされたそれぞれのパケット中に部分的にＩＰsec適用範囲を適用することも同様に可能である。本実施例によりCPUの負荷を従来方式に比べ軽減したＩＰsec通信が可能となる。
【００８９】
ここで、上記に説明したように第１、第２の実施例においては、パケット単位での制御のため、セッションの途中で実施例方式を切り換えることが可能である。このため、更なる実施例として、上記各実施例のそれぞれの特性を考慮し、ネットワークの輻輳状況、CPUの使用率、セッションのQoS等によって、各実施例方式を切り換えて、ネットワークの状態を最適化することが可能である。
【００９０】
図１３は、第４の実施例としてかかる別の実施例に従う送信側伝送装置の処理フローである。図１４は、上記の各実施例の特徴を比較するテーブルである。
【００９１】
図１４において、例えば、セキュリティの強度に関しては、これまでの通状のＩＰsecの方式が最もセキュリティは強く、次いで、第１の実施例、第２の実施例の順となる。また、ネット枠負荷及びＣＰＵ負荷に関しては、第２の実施例、第１の実施例、通常のＩＰsecの順位負荷が重くなる。なお、セキュリティ強度が低い場合は、暗号鍵の更新頻度を短くすることで改善できる。しかしこれは、ネットワーク負荷・CPU負荷とのトレードオフになる。
【００９２】
図１３の処理フローにおいて、パケット単位で暗号化送信か否か、即ちフラグメントパケットに対する暗号化か否かを判断する（ステップＳ３）。パケット単位での暗号化でないとき（ステップＳ３、N）は、かかる図１４のテーブルに示した特徴に鑑みて、先頭パケット以降のフラグメントパケットに対して、ネットワークの適用条件等に適合する第１の実施例あるいは第２の実施例の何れを適用するかを判定し（ステップＳ３A）、判定に対応する処理を行う（ステップＳ４A,またはＳ４Ｂ）。
図１３において、他のステップにおける処理は、先に説明した実施例におけると同様である。
【図面の簡単な説明】
【００９３】
【図１】LTEシステムを例として、ＩＰsec対象区間となりうる回線例を示す図である。
【図２】ＩＰsec適用可能なレイヤ構造を示す図である。
【図３】ＩＰsecのプロトコルを示す図である。
【図４】ＩＰsec適用時のデータ伝送効率を示す図である。
【図５】ＩＰsecが適用可能なＩＰネットワーク通信システムの実施例構成を示すブロック図である。
【図６】図５のデータ伝送装置２０から送信されるパケットデータを示す図である。
【図７】暗号化処理のための、ネットワークにおける暗号通信用トンネル及び暗号制御用トンネルを生成するシーケンスについて説明する図である。
【図８Ａ】第1の実施例における送信側装置Ａの処理フローを示す図である。
【図８Ｂ】第1の実施例における受信側装置Ｂの処理フローを示す図である。
【図９】第２の実施例に対応する送信側伝送装置の処理フローを示す図である。
【図１０】第３の実施例に対応する送信側伝送装置の構成例ブロック図である。
【図１１Ａ】これまでのパケットデータのＩＰsecを示す図である。
【図１１Ｂ】第３の実施例におけるパケットのヘッダ部の途中を暗号化開始位置とし、その後の所定のＩＰsec長の範囲を暗号化領域とする例を示す図である。
【図１１Ｃ】第３の実施例における所定の部分領域を暗号化される領域とし、それに続く非暗号化の部分を含めた長さ領域をＩＰsecの適用パターン長する例を示す図である。
【図１２Ａ】第３の実施例に対応する送信側伝送装置の処理フローである。
【図１２Ｂ】第３の実施例に対応する受信側伝送装置の処理フローである。
【図１３】第４の実施例に従う送信側伝送装置の処理フローである。
【図１４】上記の第１、第２の実施例の特徴を比較するテーブルである。
【符号の説明】
【００９４】
１０ 入力インタフェース部
１１ バッファ
１２ 送信パケット生成部
１３ セッション制御部
２０ データ伝送装置
２１ ＩＰsecコントローラ
２２ 暗号鍵生成部
２３ 第２のＩＰsec on/off回路
２４ 第１のＩＰsec on/off回路
２５ セレクタ
２６ ＩＰsec暗号化部
３０ ネットワーク
３１ 通状パケット経路
３２ 暗号通信用トンネル
３３ 暗号制御用トンネル
４０ データ受信装置
４１ 暗号鍵生成部
４２ ＩＰsec復号化部
【技術分野】
【０００１】
本発明は、セキュリティ機能を有するＩＰネットワーク通信方法及び通信システムに関する。
【背景技術】
【０００２】
移動通信システムにおいて、システムを構成する各ネットワーク機器（無線基地局装置、無線基地局制御装置、交換装置等）を接続する回線には、一般的にＡＴＭ(Asynchronous Transfer Mode：非同期転送モード)回線及びＩＰ（Internet Protocol：インターネット・プロトコル）回線が多く用いられている。
【０００３】
現在検討が盛んに行なわれている、次世代移動通信システム（LTE：Long Tern Evolution, SAE：System Architecture Evolution, ECN：Evolved Core Network, WiMAX, 4G等）においては、そのネットワーク機器接続回線にＩＰ網を定義することを検討されている通信システムが多くある。
【０００４】
このため、移動通信システムにおいても、全ＩＰ（Internet Protocol Network）網に接続される、一サービスとして実現されようとしている。
【０００５】
このように、現在のインターネット等のＩＰ通信等も含めて、あらゆる通信がＩＰという共通の基盤を利用したサービスへと移行してきている。
【０００６】
これらのＩＰ上で通信するサービスには、さまざまなタイプがあり、たとえば、音声や動画のように遅延の少ない通信が要求されるものや、大量のデータを高速に伝送することが要求されるもの等がある。
【０００７】
大量にデータを通信する場合は、ＩＰ回線にはパケット長が大きな（パケット長が長い）パケットを使用する方が伝送効率はよくなる。しかし、大きなパケットを伝送するには、長い時間ＩＰ回線を占有することになり、この占有時間のために遅延の少ない通信を要求するサービスの妨げとなる可能性がある。
【０００８】
このために、遅延の少ない通信の品質を確保するためには、大きなパケットは分割(fragment)して送信することが一般的である。
【０００９】
一方、通信の安全性についても関心が高まってきている。サービス提供者においては、自サービスの通信安全性などを考慮し、暗号化通信によるセキュリティ対策に関する課題対策を行うことが望ましい。
【００１０】
なお、ネットワーク回線においては、その回線上のアプリケーションに関係なく、すべての通信を自動的に暗号化可能とする技術として、ＩＰsec（ＩＰ security Protocol）を採用する方向で各種検討がされている。
【００１１】
以下、図１にLTEシステムを例として、ＩＰsec対象区間となりうる回線例を示す。図１において、無線基地局（ｅＮＢ）１，２間、及び無線基地局１，２とゲートウエイ３との間が、ＩＰsecトンネル４，５，６によりＩＰsec対象区間となり得る。
【００１２】
さらに、図２にＩＰsec適用可能なレイヤ構造を示す。図２において、移動局装置MS、無線基地局ｅＮＢ、ネットワーク制御装置ＮＣＵ間のユーザプレーンデータプロトコルスタックが示される。かかるスタックレイヤにおいて、無線基地局ｅＮＢとネットワーク制御装置ＮＣＵ間において、ＩＰsecの適用(図２、A)が可能である。
【００１３】
図３にＩＰsecのプロトコルを示す。図３において、通常パケットAを暗号化する際は、暗号化されていることを示す暗号化ヘッダBとトレーラーCが付加される。そして、通常パケットAとトレーラーCを含む範囲が暗号化され（図３、D）、暗号化ヘッダBを含む範囲が送信側と受信側との間で認証される。
【００１４】
さらに、暗号化されたパケットを、暗号通信用トンネルを通して送信するために、新ヘッダEとトレーラーFが付加される。
【００１５】
ここで、ＩＰsec技術を適用するには、各種キー(key)交換をネットワーク装置間で定期的に実施することが望ましく、ＩＰsec専用プロトコル終端部を整備するのが好ましい。
【００１６】
かかる場合、ＩＰsec専用プロトコル終端に関わる技術を適用するデータレイヤや対象データ伝送量などにも起因するが、伝送装置自体の処理能力を大きく損なうことが懸念される。
【００１７】
一般的にはＩＰsecを適用するか否か（ＩＰsec on/off）でプロトコル終端部の性能は３〜４割程度異なるといわれている。
【００１８】
また、ＩＰsec適用時には図３で説明したように、暗号通信用のヘッダ、トレーラー(図３:Ｄ、Ｂ)等を追加すると、データ容量が増加する。このためにデータ伝送効率を下げる要因になる。
【００１９】
図４に、ＩＰsec適用時のデータ伝送効率を示す。横軸にフレームサイズ、縦軸にスループットを示す。図４において、ＩはＩＰsec offの時、ＩＩは、ＩＰsec onの時の伝送効率を示している。
【００２０】
図４に示すように、ＩＰsec on/offによるデータ伝送効率の理論値変化は、何れの場合もパケット長が短い（フレーム長が短い）程下がり、最短パケット(64byte/packet) 時には、ＩＰsec非適用の場合（Ｉ）に比べ４割程度下がる。
【００２１】
一方、ネットワーク上に音声データ等、データ遅延を一定時間以下に抑えることが望ましいサービスが存在する場合、パケット長をある程度短く抑えることが望ましい。長いパケットは、伝送するために長い時間ネットワークを占有し (遅延制限のある)音声データ等を待たせてしまうため、予め短いパケットに分割（フラグメント：fragment）する。
【００２２】
従来技術として、暗号処理を行うベきパケットに、パケットヘッダの特定のフィールドをハッシュキーとして得たハッシュ値毎に異なる識別子を付与して、順序保証、並列処理を行う技術がある（特許文献１）。
【特許文献１】特開２０００−３１５９９７号公報
【発明の開示】
【発明が解決しようとする課題】
【００２３】
しかし、フラグメントするということはパケット長を短くすることであり、図４について述べたように伝送効率を下げる要因となる。
【００２４】
一方、高速なイーサネット（Ethernet）（登録商標）の普及とともに、大容量のデータやプライベートなデータをEthernet（登録商標）で伝送する機会が多くなり、データセキュリティ対策の効率化が求められる。
【００２５】
したがって、一目的は、ＩＰsec等の適用により増加するCPU負荷による処理遅延を軽減し、ネットワークのデータ伝送効率低下を軽減する暗号化を適用するＩＰネットワーク通信システムを提供することにある。
【課題を解決するための手段】
【００２６】
昨今の大容量の通信データ は、ZIP等のバイナリの圧縮データやmpeg等の映像や音声の圧縮データが多い。これらの圧縮データは、その先頭部分にデータを復元するための情報を含んでいることがほとんどである。そして、かかる部分を暗号化し、復号できない状態では、これらの圧縮データを正確に復元できなくなる場合が多い。
【００２７】
したがって、ネットワークに要求のある、ＩＰsec等のセキュリティ技術を、パケット全体に適用するのではなく、その一部であって、セキュリティが必要な部分にのみ適用する。
【００２８】
一構成例として、セキュリティ機能を有するＩＰネットワーク通信システムであって、送信データを複数のパケットに分割する手段と、前記分割された複数のパケットの一部のパケットのみに暗号化を行い、残りのパケットは非暗号化とする手段と、前記暗号化されたパケットと非暗号化のパケットを送信する送信手段を有する。
【００２９】
これにより、ＩＰsec等の適用により増加するCPU負荷による処理遅延を軽減し、ネットワークのデータ伝送効率低下を軽減する。
【発明を実施するための最良の形態】
【００３０】
以下に図面に従い、実施例を説明する。
【００３１】
図５は、ＩＰsecが適用可能なＩＰネットワーク通信システムの実施例構成を示すブロック図である。同様構成であるので、双方向通信における片方向通信側分の構成のみを示している。
【００３２】
ＩＰネットワーク通信システムにおいて、送信側データ送信装置２０と受信側データ受信装置４０が、ネットワーク３０を通して接続される。送信側データ送信装置２０の入力側には入力インタフェース１０が備えられる。
【００３３】
ネットワーク３０は、暗号化しないセッション用パケット(通常パケット)用の経路３１を有し、後で説明するように、暗号化したデータの通信セッションの際に暗号通信用トンネル３２と、暗号制御用トンネル３３が形成される。
【００３４】
図５において、送信側データ送信装置２０の入力インタフェース１０のバッファ１１に、他伝送装置または、自伝送装置におけるデータ源からのパケットデータが入力される。
【００３５】
送信パケット生成部１２は、バッファ１１から読み出されるパケットデータを所定のデータ長にフラグメント化する。
【００３６】
セッション制御部１３は、バッファ１１に入力するパケットデータについて、送信パケット生成部１２でフラグメント化されたフラグメント情報に基き、フラグメントパケット毎にセッション、QoS（Quality of Service）を判定して、セッション単位に暗号化通信でなければ、送信パケット生成部１２及び第１のＩＰsec on/off部２４に非暗号化通信を指示する。
【００３７】
これにより、送信パケット生成部１２は、バッファ１１からのパケットデータをフラグメント化したまま出力してデータ送信装置２０のセレクタ２５に入力する。
【００３８】
第１のＩＰsec on/off部２４は、セッション制御部１３からの非暗号化の指示を受けているので、セレクタ２５をネットワーク３０の通常パケット経路３１を通るように設定する。
【００３９】
図６は、図５のデータ伝送装置２０から送信されるパケットデータを示す図である。図６において、図６Ａは、送信パケット生成部１２によりバッファ１１からのパケットデータ（A）を複数のパケット（B）にフラグメント化した状態を示している。
【００４０】
図６Ｂは、これまでのパケットデータの暗号化の方法に対応するパケットデータの例である。セッション制御部１３による判定処理に基づき、送信パケット生成部１２から出力される複数のフラグメント化された全てのパケットに暗号化処理のためのヘッダ（IA）とトレーラ（IB）が付加され、暗号通信用トンネル３２を通すためのヘッダ（IIA）とトレーラ（IIB）が付加されている。
【００４１】
ここで、暗号化処理のための、ネットワーク３０における暗号通信用トンネル３２及び暗号制御用トンネル３３を生成するシーケンスについて図７を説明する。
【００４２】
すなわち、図７において、ＩＰsec通信に先立つフェーズ１及びフェーズ２の処理を有する。
【００４３】
フェーズ１において、送信側伝送装置Aと受信側伝送装置Bとの間で暗号制御用トンネル３３を形成するために、暗号制御用トンネル３３で使用するアルゴリズム（暗号algorithm、認証algorithm等）を通常パケット用の経路３１を通して決定する（処理工程Ｐ１１）。
【００４４】
ついで、同様に通常パケット用の経路３１を通して、処理工程Ｐ１１で決定されたアルゴリズムを使って暗号制御用トンネル３３の暗証鍵を決定する（処理工程Ｐ１２）。これにより、暗号制御用トンネル３３が形成される。
【００４５】
さらに、フェーズ１において、処理工程Ｐ１１，１２により決定された暗号制御用トンネル３３を使用して、伝送装置Ａ，Ｂ間で相互に通信相手の認証を行う（処理工程Ｐ１３）。
【００４６】
フェーズ２において、フェーズ１で生成された暗号制御用トンネル３３を使って、伝送装置Ａ，Ｂ間で、暗号通信用トンネル３２で使用する暗号鍵とアルゴリズムを決定する（処理工程Ｐ２１）。さらに、伝送装置Ａは、伝送装置Ｂに対して決定された暗号通信用トンネル３２で使用する暗号鍵とアルゴリズムを確認する（処理工程Ｐ２２）。
【００４７】
以降、生成された暗号通信用トンネル３２を使用して暗号化通信（ＩＰsec）を行う（処理工程Ｐ３）。
【００４８】
図８Ａ，図８Ｂは、第1の実施例における送信側装置Ａ(図８A)と、受信側装置Ｂ（図８B）の処理フローを示す。
【００４９】
先ず、セッション制御部１３は、バッファ１１のパケットデータに基づき、セッション単位に暗号化送信か否かを判定する（ステップＳ１）。暗号化送信でなければ（ステップＳ１、Ｎ）、バッファ１１から出力され、フラグメント化されたパケットは、通常パケット送信経路３１を通してデータ受信装置４０に送られ、バッファ１１のパケットデータが途切れるまで送信が継続する（図８Ａ，ステップＳ８、Ｓ９）。このとき送信されるパケットは、図６Ａの（B）に示したと同様である。
【００５０】
ステップＳ１でセッション制御部１３がパケットデータに基づき、セッション単位に暗号化通信か否かを判定して、暗号化通信であれば（ステップＳ１、Ｙ）、図７により説明したように暗号化準備としてフェーズ１，２により暗号通信用トンネル３２及び暗号制御用トンネル３３を形成する（ステップＳ２）。受信側装置４０においては、送信側装置とで確認した暗号鍵を保存する。
【００５１】
図８Aにおいて、第１の実施例としてフラグメント化された複数のパケットについて、パケット単位に暗号化送信する対象か否かを判定する（ステップＳ３）。すなわち、複数のパケット内の一部のパケットのみ、例えば、先頭パケットのみをIPsec通信を適用し、一セッションにおける残りの分割パケットは、暗号化せずに送信する。
【００５２】
例えば、先頭パケットのみを暗号化するようにすると、送信処理対象が先頭パケットのときに（ステップＳ３、Ｙ）、ＩＰsec コントローラ２１内の第１のＩＰsec on/off部２４に対し、セレクタ２５で先頭パケットのみをＩＰ暗号化部２６に出力するように切替え制御させる。
【００５３】
同時に、第２のＩＰsec on/off部２３に指示を行い、暗号鍵生成部２２により生成される暗号鍵を用いて、ＩＰsec暗号化部２６により先頭パケットのみを暗号化させる。このようにフラグメント化されたパケットの一部のみに対して暗号化する（ステップＳ５）。
【００５４】
図６Cに示すように、第１の実施例においては、暗号化される先頭パケットには、暗号化ヘッダ（IA）とトレーラー（IB）が付加され、更にその外側に、暗号通信用トンネル３２を通過させるためのヘッダIIAとトレーラー（IIB）が付加される。
【００５５】
一方、第１の実施例において、先頭パケットに続くパケットには、暗号化しなくてもよいので、暗号化用ヘッダIAのみ付され、受信側装置との間で認証しなくてもよいので暗号通信用トンネル３２を通過させるためのヘッダIIAのみが付加されている（ステップＳ４）。暗号化用トレーラー（IB）及び認証用トレーラー（IIB）は、付加されていない。
【００５６】
そして、暗号化された一部のパケット（例えば、先頭パケット）と、他のフラグメント化されたパケットは、バッファ１１にデータがなくなるまで暗号化通信用トンネルに送出される。（ステップＳ６、Ｓ７）。
【００５７】
ここで、暗号化精度を高めるために、暗号鍵に有効時間が設定されている。暗号鍵の有効時間がタイムアウトする場合（ステップＳ５、Ｙ）は、ステップＳ２に戻り再度暗号化準備処理を行って、以降の処理を継続する。
【００５８】
図８Ｂは、図８Ａの送信側装置の処理フローに対応する、受信側装置の処理フローである。図５を参照して説明する。
【００５９】
データ受信装置４０は、通常パケットの経路３１、暗号通信用トンネル３２及び暗号制御用トンネル３３のそれぞれについて、パケットを受信する。
【００６０】
ＩＰsec復号化部４２において、暗号通信用トンネル３２から受信されるパケットについて、暗号化ヘッダの有無によって、暗号化パケットか否かを判定する（ステップＳ１０）。
【００６１】
さらに、データ受信装置４０は、暗号化通信に先立って送信側装置とで決定した暗号鍵を、復号用暗号鍵生成部４１に保持している。
【００６２】
図５において、暗号通信用トンネル３２から受信されるパケットのヘッダ情報と復号用暗号鍵生成部４１に保持している暗号鍵に基づき、復号用暗号鍵生成部４１は、復号用暗号鍵を生成する。そして、生成された復号用暗号鍵を用いて、ＩＰsec復号化部４２において、暗号化パケットを復号する（ステップＳ１１）。
【００６３】
このように、ＩＰsec復号化部４２において、暗号化されているパケットは復号化され、非暗号化のパケットはそのままで、図５において図示されないアセンブル回路に入力される。そして、受信、復号されたパケットはフラグメント化されているのでアセンブル回路で、再組み立てされて、元のパケットデータを受信装置側で得ることができる。
【００６４】
かかる第１の実施例において、フラグメントされたデータの複数のパケットのうち先頭のパケットのみにＩＰsecを適用し、残りのパケットは、ＩＰsec非適用で暗号通信用トンネルに送信する等、暗号化適用データ範囲を減らすことができる。
【００６５】
このため、データ全体を通信網にさらさないのでセキュリティは確保しつつ、且つ暗号化off時にESP header（IA）等を省略できるのでネットワーク負荷と 暗号化に必要な処理を省略できる。
【００６６】
したがって、 CPUの負荷を軽減し、遅延の少ない通信が可能となる。なお、この実施例では、データ受信装置側は、ＩＰsecのESP header（IA）により暗号化の適用・非適用がパケット単位で判断可能なため特別な機能追加を行わなくてもよい。
【００６７】
図９は、第２の実施例に対応する送信側伝送装置の処理フローである。
【００６８】
この実施例では、先の第１の実施例におけると同様に、フラグメントされたパケットの一部、例えば、先頭パケットのみを暗号化を行う。そして、それ以降のフラグメントされたパケットは暗号化せずに通常パケットの経路３１を通過するように、セッション制御部１３により第１のＩＰsec on/off回路２４に指示してセレクタ２５を切換制御する。
【００６９】
したがって、第２の実施例のパケットデータを示す図６Dにおいて、先頭パケットに対し、暗号化ヘッダ（IA）及びトレーラー（IB）が付加され、暗号通信用トンネル３２を通過させるためのヘッダ（IIA）とトレイラー（IIB）が付加されている。
【００７０】
それ以降のパケットは、フラグメント化された状態のままであり、通常パケット経路３１により送信される。
【００７１】
したがって、図９において、第１の実施例に対応する図８の処理フローと比較すると、ステップＳ４の処理が、ステップＳ４Aに置き換えられている点のみが異なる。
【００７２】
すなわち、先頭パケットを除き、暗号化送信パケットでないと判定される（ステップＳ３、N）と、フラグメントされたパケットの状態のままで（図６D, III）、通常パケットの経路３１により送信される。その他の処理は、第１の実施例と同様である。
【００７３】
かかる第２の実施例では、上記のように、同じセッション内でＩＰsecがonのパケットは、暗号通信トンネル３２を使って送信され、ＩＰsecがoffのパケットは、トンネルを使わず通常パケットとして通常パケット経路３１で送信する。このため、本実施例において、ＩＰsec offの場合のパケットは、第１の暗号化offの場合のパケットから暗号通信用トンネル３２に送信するためのheader等を省略でき、第１の実施例に比べ、更にネットワーク負荷とCPUの負荷を軽減することが可能である。
【００７４】
なお、第１の実施例と同様に、本実施例のデータ受信装置側には、本実施例の実行のために特別な機能を追加しなくてもよい。
【００７５】
図１０は、更に第３の実施例に対応する送信側伝送装置の構成例ブロック図である。
【００７６】
この実施例では、送信装置２０の入力インタフェース部１０にパケットをフラグメント化する送信パケット生成部１２を有していない。
【００７７】
セッション制御部１３は、バッファから読みだされる送信パケットに対し、送信パケットの一部をＩＰsecの適用範囲に指定する。このＩＰsecの適用範囲は、セッション情報、QoS等の情報に基き、予め設定した条件に対応するように決められる。
【００７８】
すなわち、セッション制御部１３は、バッファ１１からデータ送信装置２０に入力されるパケットに同期して、ＩＰsecコントローラ２１の暗号鍵生成部２２Aに暗号化適用範囲を通知する。
【００７９】
ＩＰsec暗号化部２６は、暗号鍵生成部２２A からの暗号化適用範囲に対応するタイミングでの暗号化指示に従い、暗号化を行って、一パケット中の暗号化された部分及び、該当のパケットの残りの部分と共に、ネットワーク３０の暗号通信用トンネル３２を通して、受信側伝送装置４０に送信する。
【００８０】
図１１A−図１１Cは、かかる第３の実施例に対応する暗号化パケットの例を示す図である。
【００８１】
図１１Aは、通常のＩＰsecを示す図であり、送信すべきパケットと、パケットに付加された暗号化用トレーラーIBの範囲をＩＰsecの適用範囲としている。これに対し、図１１B, 図１１C に示すように、第３の実施例では、送信対象である一つのパケット中の任意の範囲を暗号化対象としている。
【００８２】
具体的には、図１１Bの例では、パケットのヘッダ部の途中を暗号化開始位置とし、その後の所定のＩＰsec長の範囲を暗号化領域としている。さらに、図１１Cの例では、所定の部分領域を暗号化される領域とし、それに続く非暗号化の部分を含めた長さ領域をＩＰsecの適用パターン長として、かかるパターンを繰り返すように設定する（図１１C, III1, III2, III3）。なお、最後のパターン領域はパターン長が、途中までとなる場合があり、図１１Cは、かかる場合を示している。
【００８３】
図１２A, 図１２Bは、第３の実施例に対応する送信側伝送装置（図１２A）と受信側伝送装置（図１２B）の処理フローである。
【００８４】
図８A, 図８Bに示した第1の実施例の処理フローとの比較において、パケット単位での暗号化送信の適用判断（図８A、ステップＳ３）を行わずに、セッション制御部１３により、送信処理対象のパケットに対して予め設定したＩＰsec適用範囲について、暗号化処理を実行する（ステップＳ５Ａ）。他の処理は、先の実施例の処理フローと同様である。
【００８５】
図１２Bにおける受信側伝送装置の処理フローにおいては、暗号化パケットと判断されるとき（ステップＳ１０、Ｙ）、ＩＰsec復号化部４２は、ヘッダ部の情報に基き、暗号化パケットにおける暗号化されている領域について、復号化を行う（ステップＳ１１A）。他の処理は、先の実施例と同様である。
【００８６】
この第３の実施例では、上記に図１０、図１１A−図１１Cで説明した通り、ＩＰsecで通信を行うデータ送信側伝送装置・データ受信側伝送装置において、a) 暗号鍵の交換時等に、ＩＰsecの適用範囲、例えば、先頭何byte目から何byte間のデータにＩＰsecを掛けたり、暗号化パターン(パターンにより斑に暗号化する) 等の情報をデータ送受信双方で共有し、b) この情報に従ってデータの限定した領域のみＩＰsecを施し、c) この情報に従って限定した領域にＩＰsecがかけられたデータを復元することで実現される。
【００８７】
さらに、図７で説明した暗号か準備のための処理フェーズ１，２の基本は変わらないが、ＩＰsecのフェーズ２で扱うデータに暗号化パターンが追加される。
【００８８】
また、本実施例として、図１０の送信側伝送装置のインタフェース部１０において、送信パケット生成部１２を設けないで、フラグメントされていないパケットにおいてＩＰsec適用範囲を設定するように説明したが、当然にフラグメントされたそれぞれのパケット中に部分的にＩＰsec適用範囲を適用することも同様に可能である。本実施例によりCPUの負荷を従来方式に比べ軽減したＩＰsec通信が可能となる。
【００８９】
ここで、上記に説明したように第１、第２の実施例においては、パケット単位での制御のため、セッションの途中で実施例方式を切り換えることが可能である。このため、更なる実施例として、上記各実施例のそれぞれの特性を考慮し、ネットワークの輻輳状況、CPUの使用率、セッションのQoS等によって、各実施例方式を切り換えて、ネットワークの状態を最適化することが可能である。
【００９０】
図１３は、第４の実施例としてかかる別の実施例に従う送信側伝送装置の処理フローである。図１４は、上記の各実施例の特徴を比較するテーブルである。
【００９１】
図１４において、例えば、セキュリティの強度に関しては、これまでの通状のＩＰsecの方式が最もセキュリティは強く、次いで、第１の実施例、第２の実施例の順となる。また、ネット枠負荷及びＣＰＵ負荷に関しては、第２の実施例、第１の実施例、通常のＩＰsecの順位負荷が重くなる。なお、セキュリティ強度が低い場合は、暗号鍵の更新頻度を短くすることで改善できる。しかしこれは、ネットワーク負荷・CPU負荷とのトレードオフになる。
【００９２】
図１３の処理フローにおいて、パケット単位で暗号化送信か否か、即ちフラグメントパケットに対する暗号化か否かを判断する（ステップＳ３）。パケット単位での暗号化でないとき（ステップＳ３、N）は、かかる図１４のテーブルに示した特徴に鑑みて、先頭パケット以降のフラグメントパケットに対して、ネットワークの適用条件等に適合する第１の実施例あるいは第２の実施例の何れを適用するかを判定し（ステップＳ３A）、判定に対応する処理を行う（ステップＳ４A,またはＳ４Ｂ）。
図１３において、他のステップにおける処理は、先に説明した実施例におけると同様である。
【図面の簡単な説明】
【００９３】
【図１】LTEシステムを例として、ＩＰsec対象区間となりうる回線例を示す図である。
【図２】ＩＰsec適用可能なレイヤ構造を示す図である。
【図３】ＩＰsecのプロトコルを示す図である。
【図４】ＩＰsec適用時のデータ伝送効率を示す図である。
【図５】ＩＰsecが適用可能なＩＰネットワーク通信システムの実施例構成を示すブロック図である。
【図６】図５のデータ伝送装置２０から送信されるパケットデータを示す図である。
【図７】暗号化処理のための、ネットワークにおける暗号通信用トンネル及び暗号制御用トンネルを生成するシーケンスについて説明する図である。
【図８Ａ】第1の実施例における送信側装置Ａの処理フローを示す図である。
【図８Ｂ】第1の実施例における受信側装置Ｂの処理フローを示す図である。
【図９】第２の実施例に対応する送信側伝送装置の処理フローを示す図である。
【図１０】第３の実施例に対応する送信側伝送装置の構成例ブロック図である。
【図１１Ａ】これまでのパケットデータのＩＰsecを示す図である。
【図１１Ｂ】第３の実施例におけるパケットのヘッダ部の途中を暗号化開始位置とし、その後の所定のＩＰsec長の範囲を暗号化領域とする例を示す図である。
【図１１Ｃ】第３の実施例における所定の部分領域を暗号化される領域とし、それに続く非暗号化の部分を含めた長さ領域をＩＰsecの適用パターン長する例を示す図である。
【図１２Ａ】第３の実施例に対応する送信側伝送装置の処理フローである。
【図１２Ｂ】第３の実施例に対応する受信側伝送装置の処理フローである。
【図１３】第４の実施例に従う送信側伝送装置の処理フローである。
【図１４】上記の第１、第２の実施例の特徴を比較するテーブルである。
【符号の説明】
【００９４】
１０ 入力インタフェース部
１１ バッファ
１２ 送信パケット生成部
１３ セッション制御部
２０ データ伝送装置
２１ ＩＰsecコントローラ
２２ 暗号鍵生成部
２３ 第２のＩＰsec on/off回路
２４ 第１のＩＰsec on/off回路
２５ セレクタ
２６ ＩＰsec暗号化部
３０ ネットワーク
３１ 通状パケット経路
３２ 暗号通信用トンネル
３３ 暗号制御用トンネル
４０ データ受信装置
４１ 暗号鍵生成部
４２ ＩＰsec復号化部
【特許請求の範囲】
【請求項１】
セキュリティ機能を有するＩＰネットワーク通信方法であって、
暗号化処理部で、一の送信パケットの所定の領域範囲に対して暗号化を行い、前記パケットの残りの領域を非暗号化とする工程と、
前記暗号化処理部により暗号化されたパケットを暗号用トンネルで送信する工程を、
有することを特徴とするＩＰネットワーク通信方法。
【請求項２】
請求項１において、
更に分割部により、送信データを複数のパケットに分割する工程を有し、
前記一の送信パケットは、前記分割部により分割された複数のパケットの一つであることを特徴とするＩＰネットワーク通信方法。
【請求項３】
請求項１において、
前記暗号化される一部のパケットの所定の領域範囲は、前記分割された複数のパケットの先頭パケットであることを特徴とするＩＰネットワーク通信方法。
【請求項４】
請求項１において、
前記分割された複数のパケットの前記非暗号化のパケットは、前記暗号化されたパケットと同じ暗号用トンネルで送信されることを特徴とするＩＰネットワーク通信方法。
【請求項５】
請求項１において、
前記暗号された一部のパケットは、暗号用トンネルで送信され、前記非暗号化のパケットは、通常のパケット用経路で送信されることを特徴とするＩＰネットワーク通信方法。
【請求項６】
セキュリティ機能を有するＩＰネットワーク通信システムであって、
一の送信パケットの所定の領域範囲に対して暗号化を行い、前記パケットの残りの領域を非暗号化とする暗号化処理部と、
前記暗号化処理部により暗号化されたパケットを暗号用トンネルで送信する送信部を、
有することを特徴とするＩＰネットワーク通信システム。
【請求項７】
請求項６において、
更に送信データを複数のパケットに分割する分割部を有し、
前記一の送信パケットは、前記分割部により分割された複数のパケットの一つであることを特徴とするＩＰネットワーク通信システム。
【請求項１】
セキュリティ機能を有するＩＰネットワーク通信方法であって、
暗号化処理部で、一の送信パケットの所定の領域範囲に対して暗号化を行い、前記パケットの残りの領域を非暗号化とする工程と、
前記暗号化処理部により暗号化されたパケットを暗号用トンネルで送信する工程を、
有することを特徴とするＩＰネットワーク通信方法。
【請求項２】
請求項１において、
更に分割部により、送信データを複数のパケットに分割する工程を有し、
前記一の送信パケットは、前記分割部により分割された複数のパケットの一つであることを特徴とするＩＰネットワーク通信方法。
【請求項３】
請求項１において、
前記暗号化される一部のパケットの所定の領域範囲は、前記分割された複数のパケットの先頭パケットであることを特徴とするＩＰネットワーク通信方法。
【請求項４】
請求項１において、
前記分割された複数のパケットの前記非暗号化のパケットは、前記暗号化されたパケットと同じ暗号用トンネルで送信されることを特徴とするＩＰネットワーク通信方法。
【請求項５】
請求項１において、
前記暗号された一部のパケットは、暗号用トンネルで送信され、前記非暗号化のパケットは、通常のパケット用経路で送信されることを特徴とするＩＰネットワーク通信方法。
【請求項６】
セキュリティ機能を有するＩＰネットワーク通信システムであって、
一の送信パケットの所定の領域範囲に対して暗号化を行い、前記パケットの残りの領域を非暗号化とする暗号化処理部と、
前記暗号化処理部により暗号化されたパケットを暗号用トンネルで送信する送信部を、
有することを特徴とするＩＰネットワーク通信システム。
【請求項７】
請求項６において、
更に送信データを複数のパケットに分割する分割部を有し、
前記一の送信パケットは、前記分割部により分割された複数のパケットの一つであることを特徴とするＩＰネットワーク通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１Ａ】
【図１１Ｂ】
【図１１Ｃ】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図９】
【図１０】
【図１１Ａ】
【図１１Ｂ】
【図１１Ｃ】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【図１４】
【公開番号】特開２０１０−３４８６０（Ｐ２０１０−３４８６０Ａ）
【公開日】平成２２年２月１２日（２０１０．２．１２）
【国際特許分類】
【出願番号】特願２００８−１９４９８６（Ｐ２００８−１９４９８６）
【出願日】平成２０年７月２９日（２００８．７．２９）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２２年２月１２日（２０１０．２．１２）
【国際特許分類】
【出願日】平成２０年７月２９日（２００８．７．２９）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]