JP6151906B2 - 通信装置及びその制御方法 - Google Patents

通信装置及びその制御方法 Download PDF

Info

Publication number
JP6151906B2
JP6151906B2 JP2012225368A JP2012225368A JP6151906B2 JP 6151906 B2 JP6151906 B2 JP 6151906B2 JP 2012225368 A JP2012225368 A JP 2012225368A JP 2012225368 A JP2012225368 A JP 2012225368A JP 6151906 B2 JP6151906 B2 JP 6151906B2
Authority
JP
Japan
Prior art keywords
size
algorithm
packet
ipsec
packet processing
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
Application number
JP2012225368A
Other languages
English (en)
Other versions
JP2014078852A (ja
Inventor
暁央 木下
暁央 木下
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2012225368A priority Critical patent/JP6151906B2/ja
Priority to US14/043,069 priority patent/US9467471B2/en
Publication of JP2014078852A publication Critical patent/JP2014078852A/ja
Application granted granted Critical
Publication of JP6151906B2 publication Critical patent/JP6151906B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/164Implementing security features at a particular protocol layer at the network layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、ネットワークを介したデータ送受信のセキュリティに関する。本発明は、特に、IPsecを適用した通信においてIPフラグメンテーションを抑制するためにIPパケットサイズを制御する技術に関する。
近年、ネットワーク上におけるセキュリティについて必要性が高まってきており、特に、暗号化通信によるセキュリティの必要性が高まってきている。現在、セキュリティプロトコルとして幾つかのプロトコルが存在している。その中でIPsec(IP Security Protocol)は、AH(Authentication Header)プロトコルによる送信元の認証とデータの完全性保証の仕組みを備える。加えて、IPsecは、ESP(Encapsulating Security Payload)プロトコルによるIPパケットの機密性の確保と安全性保証と送信元の認証の仕組みを備えている。IPsecはIPレベル(OSI参照モデルではネットワーク層)で実現されているセキュリティプロトコルのため、IPパケット単位でAH処理及びESP処理が行われる。IPsecの技術は、RFC2401及びRFC2402及びRFC2406等で規定されている。
IPを利用した通信では、1回の転送で送信できるデータの最大値としてMTU(Maximum Transmission Unit)が規定されている。MTUを超えたIPパケットを送信する場合、IPパケットにIPフラグメンテーションが実行されて送信される。IPフラグメンテーションを発生させない技術として、RFC1191及びRFC1981でPMTU(Path MTU Discovery)が規定されている。
また、IPsecを利用した通信パケットのパケット長がPMTUの範囲で最大になるように最適化する技術が、特許文献1に開示されている。
特開2006−165847号公報
IPsecを適用したIPパケットは、IPsec適用前のIPパケットに比べ、ESP処理又はAH処理によりIPパケットサイズが増加する。そのため、IPsec適用前のIPパケットサイズがMTUに近い場合、IPパケットにフラグメンテーションが実行される。IPパケットのフラグメンテーションは、送信側においてはIPパケットの分割処理を伴い、受信側においてはIPパケットの再構成処理を伴うため、通信速度低下を引き起こすという問題がある。
IPsecを適用したIPパケットにフラグメンテーションを発生させないために、PMTUを実施することでMTUの値を小さくすることは可能であるが、PMTUはICMPパケットを利用するためにファイアウォールで破棄されてしまうこともある。しかも、IPsec適用で増加するIPパケットサイズが厳密に考慮されていないため、必ずしもIPsecを適用したIPパケットにフラグメンテーションが発生しないとも限らない。また、IPパケットにフラグメンテーションが発生しないMTU値に変更されたとしても、IPパケットにフラグメンテーションが発生しない範囲で最大サイズになる保証はない。そのため、フラグメンテーションは発生しないがMTU値が小さいためにIPパケットが小さくなることで通信速度低下を引き起こすこともある。
本発明は、上述の問題を鑑み、IPパケットにIPsecを適用した際に、IPパケットを、フラグメンテーションが発生しない範囲で最大のサイズにする暗号化通信を実現することを目的とする。本発明は更に、IPパケットにIPsec適用した際にフラグメンテーションが発生しないIPパケットの最大サイズの計算にかかる演算量を最小限にすることを目的とする。
本発明の一側面によれば、通信装置であって、第1のアルゴリズムを利用してIPSec(IP Security Protocol)に基づくパケット処理を実行する第1の実行手段と、第2のアルゴリズムを利用してIPSecに基づくパケット処理を実行する第2の実行手段と、前記第1のアルゴリズムを利用してパケット処理を実行した場合に増加するIPヘッダの第1サイズと、前記第2のアルゴリズムを利用してパケット処理を実行した場合に増加するIPヘッダの第2サイズとのうち、サイズが大きい方を記憶し、サイズが小さい方を記憶しないメモリと、前記第1のアルゴリズムを利用してパケット処理を実行する場合であっても、前記第2のアルゴリズムを利用してパケット処理を実行する場合であっても、前記メモリに記憶されたサイズに基づいて、フラグメンテーションが発生しないように、IPSecに基づくパケット処理が適用されるパケットに含まれる送信データサイズを決定する決定手段とを有することを特徴とする通信装置が提供される。
本発明によれば、IPパケットにIPsecを適用した際に、IPパケットを、MTUを超えずにフラグメンテーションが発生しない最大サイズにすることができる。また、本発明によれば、IPパケットにIPsec適用した際にフラグメンテーションが発生しないIPパケットの最大サイズの計算にかかる演算量を最小限にすることができる。
実施形態における暗号化通信装置の構成を示すブロック図。 IPパケットにIPsec適用をすることで増加するデータサイズを計算する処理を示すフローチャート。 IPパケットにフラグメンテーションが発生しないデータサイズを設定する処理を示すフローチャート。 IPパケットにIPsec適用することで増加するデータサイズを設定する処理を示すフローチャート。 AH(認証ヘッダ)のフォーマットの一例を示す図。 ESP(暗号ペイロード)のパケットフォーマットの一例を示す図。 IPsec適用することで増加するデータサイズの計算後に生成されるテーブルの一例を示す図。
以下、図面を参照して本発明の好適な実施形態について詳細に説明する。なお、本発明は以下の実施形態に限定されるものではなく、本発明の実施に有利な具体例を示すにすぎない。また、以下の実施形態の中で説明されている特徴の組み合わせの全てが本発明の課題解決のために必須のものであるとは限らない。
<実施形態1>
実施形態1では、IPsec適用によるデータサイズ増加に起因するIPパケットのフラグメンテーションの抑制処理を用いた暗号化通信を説明する。図1は、本実施形態の係る暗号化通信装置の構成を示すブロック図である。
本実施形態における暗号化通信装置は、IPパケットに対しIPsecを適用することでネットワーク上を流れるデータのセキュリティを確保するための構成を有する。具体的には、図1に示されるように、このIPsecを実装した暗号化通信装置は、ネットワークプロトコル処理部101、IPsec処理部102、最大送信データサイズ記憶部103を有する。暗号化通信装置は、更に、最大送信データサイズ更新部104、ネットワークインタフェース部105、IPsecパケット増加サイズ設定部106も有している。IPsec処理部102は、IPsecに係る制御を行う構成を備えている。具体的には、IPsec処理部102は、SP管理部201、SA管理部202、IPsec適用部203、IPsecパケット増加サイズ記憶部204、IPsecパケット増加サイズ計算部205を有している。
ネットワークプロトコル処理部101は、OSI参照モデルでいうところのネットワーク層以上の上位レイヤを指し、ネットワークを介して通信をするためのプロトコル機能を処理する。具体的には、ネットワークプロトコル処理部101は、最大送信データサイズ記憶部103に記憶されている最大送信データサイズを基にIPパケットを分割してネットワークインタフェース部105にIPパケットを渡す。IPsec処理部102は、ネットワークプロトコル処理部101から受け取ったIPパケットに対してIPsecを適用する処理を実行する。最大送信データサイズ記憶部103は、IPパケットにフラグメンテーションが発生しない最大送信データサイズを記憶する。最大送信データサイズ更新部104は、ネットワークプロトコル処理部101を介して、IPsecパケット増加サイズ計算部205で計算されたIPパケットに対してIPsec適用により増加したパケットサイズを取得する。最大送信データサイズ更新部104はその後、最大送信データサイズ記憶部103に記憶されている最大送信データサイズを変更する。ネットワークインタフェース部105は、OSI参照モデルでいうところのデータリンク層と物理層を指し、IPパケットをネットワーク上に送信を行う。
暗号化通信装置は、複数の暗号アルゴリズム及び複数の認証アルゴリズムを利用可能である。IPsecパケット増加サイズ記憶部204は、IPsec適用によるパケットサイズの増加分が最大となる暗号アルゴリズム及び認証アルゴリズムの当該最大となるパケットサイズの増加分の情報を予め記憶している。IPsecパケット増加サイズ設定部106は、IPパケットに対するIPsec適用によるパケットサイズの増加分の情報をIPsecパケット増加サイズ記憶部204に設定することができる。
本実施形態において、暗号化通信装置で用いられるIPパケットデータは、インターネット上で送受信されるデータの単位である。IPパケットデータの組み立て方法については、発明の本質に関わらないので、説明を省略する。また、SP管理部201とSA管理部202は、通常のIPsecを利用した暗号化通信において公知のものであって発明の本質に関わらないので、それらの詳細な説明も省略する。また、暗号化通信を始める前に必要となる鍵交換は、IKEまたはSSLといった公知の方法を利用して行うことを前提としている。これらの鍵交換の詳細も、発明の本質に関係がないので、説明を省略する。
次に、IPsec処理部102の構成について、図1に基づき説明する。SP管理部201は、セキュリティポリシー(SP)が登録されているSPD(セキュリティポリシーデータベース)を管理する。SPは、IPパケットに対して実行する処理(破棄(discard)、IPsecを適用しない(bypass IPsec)、IPsecを適用する(apply IPsec))を記述する。SPは、「IPsecを適用する」を指定する場合は、適用するセキュリティプロトコル(AH/ESP)やカプセル化モード(トンネルモード/トランスポートモード)等も指定する。SA管理部202は、セキュリティアソシエーション(SA)が格納されているSAD(セキュリティアソシエーションデータベース)を管理する。SAは、送信時及び受信時のIPパケットに対して行う認証及び暗号アルゴリズムのパラメータを定義する。
IPsec適用部203は、ネットワークプロトコル処理部101から受け取ったIPパケットに対してIPsecを適用する。IPsec適用部203での送信時の処理は次のとおりである。IPパケットに対してIPsecを適用するかどうかを判定するため、まず、IPパケットの始点IPアドレス、終点IPアドレス、プロトコル、ポート番号の情報からSP管理部201に管理されているSPDよりSP(セキュリティポリシー)を検索する。SPが「破棄」を示す場合には、IPパケットを破棄する。また、SPが「IPsecを適用しない」を示す場合は、IPsecを適用せずにIPパケットをネットワークプロトコル処理部101に受け渡す。SPが「IPsecを適用する」を示す場合は、SA管理部202に管理されているSADよりSA(セキュリティアソシエーション)を検索する。そしてSAに記載されているアルゴリズムや鍵を利用し、暗号化処理を実行後、ネットワークプロトコル処理部101にIPsecを適用したIPパケットを受け渡す。
IPsec適用部203での受信時の処理は次のとおりである。まず、IPパケットに対してIPsecが適用されているかどうかを判定する。IPsecが適用されていない場合は、SP管理部201に管理されているSPDからSPを検索する。検索されたSPが「破棄」を示す場合は、IPパケットを破棄する。SPが「IPsecを適用」を示す場合は、このIPパケットにはIPsecが適用されていないため、このIPパケットを破棄する。また、SPが「IPsecを適用しない」を示す場合は、受信したIPパケットと条件が一致するので、ネットワークプロトコル処理部101にIPパケットを受け渡す。IPsecが適用されている場合は、まず、SA管理部202に管理されているSADからSAを検索し、SAに記載されているアルゴリズムや鍵を利用して復号化処理を行う。次に、復号化処理が行われた後にSPDからSPを検索し、SPの内容と受信したIPパケットに適用されている内容と一致しているかどうかを判定する。一致していない場合は、IPパケットを破棄し、一致している場合は、ネットワークプロトコル処理部101にIPパケットを受け渡す。
次に、IPsec適用により増加するデータサイズの計算の流れを、図2及び図3のフローチャートに基づき説明する。このフローチャートに対応する処理は、IPsecパケット増加サイズ計算部205によって実行される。
まずS301において、ネットワークプロトコル処理部101より送信元及び宛先のIPアドレス、プロトコル番号、送信元及び宛先のポート番号の情報を受け取る。SP管理部201に管理されているSPDから、これらの情報に対応するSPを検索する。S302では、SPの検索結果を判断する。ここで、該当するSPが存在しない場合は、処理はS305に進み、IPsec適用で増加するパケットサイズは0となり処理を終了する。SPが存在する場合は、処理はS303に進み、送信元及び宛先のIPアドレス、プロトコル番号、送信元及び宛先のポート番号の情報に対応するSAを、SA管理部202に管理されているSADから検索する。S304では、SAの検索結果を判断する。ここで、該当するSAが存在しない場合は、処理はS305に進み、IPsec適用で増加するパケットサイズは0となり処理を終了する。該当するSAが存在する場合は、処理はS401に進む。
S401では、IPパケットに対して適用する、IPsecにおけるセキュリティプロトコルを決定する。具体的には、まず、検索されたSAに記述されるSAパラメータを受け取るとともに、IPsec適用前の最大送信データサイズの情報を受け取る。その後、受け取ったSAパラメータにおけるセキュリティプロトコルの種別が、AH(認証ヘッダ)のみ、ESP(暗号ペイロード)のみ、ESP及びESP認証、AH及びESP及びESP認証、のいずれであるかをチェックする。以下、決定されたセキュリティプロトコルに従う処理が実行される。
SAパラメータにおけるセキュリティプロトコルの種別がAHのみの場合、処理はS402に進み、AH処理によって増加するパケットサイズをIPsecパケット増加サイズ記憶部204より取得し、その後、処理はS411に進む。SAパラメータにおけるセキュリティプロトコルの種別がESPのみの場合、処理はS403に進み、ESP処理によって増加するパケットサイズをIPsecパケット増加サイズ記憶部204より取得し、その後、処理はS410に進む。SAパラメータにおけるセキュリティプロトコルの種別がESPとESP認証機能の場合、処理はS404に進み、ESP処理によって増加するパケットサイズをIPsecパケット増加サイズ記憶部204より取得する。次にS406で、ESP認証機能処理によって増加するパケットサイズをIPsecパケット増加サイズ記憶部204より取得する。その後、処理はS409に進む。SAパラメータにおけるセキュリティプロトコルの種別がAHとESPとESP認証機能の場合、処理はS405に進み、AH処理によって増加するパケットサイズをIPsecパケット増加サイズ記憶部204より取得する。次にS407で、ESP処理によって増加するパケットサイズをIPsecパケット増加サイズ記憶部204より取得する。さらにS408で、ESP認証機能処理によって増加するパケットサイズをIPsecパケット増加サイズ記憶部204より取得する。その後、処理はS409に進む。
S409では、取得した各IPsec適用で増加するパケットサイズ全てを積算する。その後、処理はS410に進む。S410では、ESP処理の際、暗号化適用により必要なパディング、パディング長、次ヘッダ番号による増加分とS409で計算した値とを積算する。その後、処理はS411に進む。S411では、SAパラメータのカプセル化モードがトンネルモードである場合にのみ、増加するIPヘッダサイズとステップ410で計算した値とを積算し、処理を終了する。
次に、IPsecパケット増加サイズ設定部106において、IPsec適用によって増加するデータサイズをIPsecパケット増加サイズ記憶部204に設定する処理の流れを、図4のフローチャートに基づき説明する。
まずS501において、AH処理実行によって増加するデータサイズの設定か、ESP処理実行によって増加するデータサイズの設定か、ESP認証機能処理実行によって増加するデータサイズの設定かをチェックする。
AH処理実行によって増加するデータサイズの設定の場合、処理はS502に進む。S502では、IPsecパケット増加サイズ記憶部204に対してAHと対応付けして増加データサイズを設定する。
ESP処理実行によって増加するデータサイズの設定の場合、処理はS503に進む。S503では、IPsecパケット増加サイズ記憶部204に対してESPと対応付けして増加データサイズを設定する。
ESP認証機能処理実行によって増加するデータサイズの設定の場合、処理はS504に進む。S504では、IPsecパケット増加サイズ記憶部204に対してESP認証機能と対応付けして増加データサイズを設定する。
次に、最大送信データサイズ更新部104において、IPパケットにフラグメンテーションが発生しない範囲内で最大の送信パケットサイズを最大送信データサイズ記憶部103に設定する処理の流れを、図5のフローチャートに基づき説明する。
まずS601において、ネットワークプロトコル処理部101からセッション情報とIPパケットにフラグメンテーションが発生しない範囲内で最大の送信パケットサイズを取得する。次にS602で、最大送信データサイズ記憶部103の記憶領域に、セッション情報とIPパケットにフラグメンテーションが発生しない範囲内で最大の送信パケットサイズとを対応付けて設定する。こうして、セッション毎に、IPパケットにフラグメンテーションが発生しない範囲内で最大の送信パケットサイズが更新される。
前述のとおり、IPsecパケット増加サイズ記憶部204は、IPsec適用によるパケットサイズの増加分が最大となる暗号アルゴリズム及び認証アルゴリズムの当該最大となるパケットサイズの増加分の情報を予め記憶している。そして、暗号化通信装置で利用可能な複数の暗号アルゴリズム及び複数の認証アルゴリズムのうちパケットサイズの増加分が最大となるものを使用すると仮定して、最大送信パケットサイズが計算される。すなわち、この計算は、決定されたセキュリティプロトコルにより実際に指定される暗号アルゴリズム及び認証アルゴリズムに関わらない。
<実施形態2>
実施形態2では、以下のような通信装置を考える。
・認証アルゴリズムにHMAC-MD5とHMAC-SHA1が利用可能。
・暗号アルゴリズムにDES-CBCと3DES-CBCとAES-CBCが利用可能。
・IPsecモードはトランスポートモード。
・MTUは1500byte。
以下、この通信装置における、IPsec適用によるデータサイズ増加に起因するTCP通信のIPv4パケットのフラグメンテーションを抑制する処理を、図1のブロック図を基に説明する。
まず、IPsecパケット増加サイズ設定部106は、以下の情報を、IPsecパケット増加サイズ記憶部204に設定する。
・利用可能な暗号アルゴリズムを用いたESP処理実行によって増加する最大サイズ。
・利用可能な認証アルゴリズムを用いたESP認証機能処理又はAH処理実行によって増加する最大サイズ。
IPsecパケット増加サイズ記憶部204に設定されるデータサイズについて、以下に説明する。
(1)AH処理によって増加するデータサイズ
AH処理によって、IPパケットに対して、図6に示されるような認証ヘッダのフォーマットが追加される。次ヘッダ番号、ペイロード長、予約、SPI(セキュリティパラメータインデックス)、シーケンス番号はそれぞれ、認証アルゴリズムに依存しない固定長である。一方、認証データは、認証アルゴリズムとIPプロトコルバージョンに依存する。本実施形態のHMAC-MD5とHMAC-SHA1とIPv4プロトコルでは、RFC2403とRFC2404に規定されている12byteとなる。
AH処理による増加データサイズは次式により、24byteとなる。
1byte(次ヘッダ番号サイズ)+1byte(ペイロード長サイズ)+2byte(予約サイズ)
+4byte(SPIサイズ)+4byte(シーケンス番号サイズ)
+12byte(認証データサイズ)
= 24byte
(2)ESP処理によって増加するデータサイズ
ESP処理によって、IPヘッダに対して、図7に示されるような暗号ペイロードのフォーマットが追加される。SPI、シーケンス番号、パディング長、次ヘッダ番号はそれぞれ、暗号アルゴリズムに依存しない固定長である。一方、初期ベクトル、ペイロードデータ、パディングはそれぞれ、暗号アルゴリズムとIPプロトコルバージョンとMTUとに依存する。本実施形態のDES-CBCと3DES-CBCとAES-CBCの中では、AES-CBCが初期ベクトルとブロックサイズより増加データサイズが大きくなる。初期ベクトル及びブロックサイズはRFC2405とRFC2451とRFC3602にて規定されている。
IPv4パケットでMTUが1500byteの場合、ESP処理においてAES-CBCは初期ベクトルが16byte、ブロックサイズが16byteであり、増加するデータサイズは次式により、26byteとなる。
MTU=1500byte
IPv4ヘッダサイズ=20byte
SPIサイズ=4byte
シーケンス番号サイズ=4byte
初期ベクトルサイズ=16byte
ブロックサイズ=16byte
パディング長サイズ=1byte
次ヘッダサイズ=1byte
ペイロードデータサイズ=MTU−IPv4ヘッダサイズ
=1500−20
=1480byte
暗号化対象のペイロードデータサイズ=ペイロードデータサイズ
−SPIサイズ−シーケンス番号サイズ
−初期ベクトルサイズ
=1480−4−4−16
=1456byte
パディング=暗号化対象のペイロードデータサイズ mod ブロックサイズ
=1456 mod 16 = 0byte
増加するデータサイズ= ペイロードデータサイズ−(暗号化対象のペイロードデータサイズ−パディング−パディング長サイズ−次ヘッダサイズ)
=1480−(1456−0−1−1)
=26byte
(3)ESP処理とESP認証処理によって増加するデータサイズ
ESP処理とESP認証処理によって、IPヘッダに対して、図7に示されるような暗号ペイロードのフォーマットが追加される。SPI、シーケンス番号、パディング長、次ヘッダ番号はそれぞれ、暗号アルゴリズムに依存しない固定長である。一方、初期ベクトル、ペイロードデータ、パディングはそれぞれ、暗号アルゴリズムとIPプロトコルバージョンとMTUとに依存する。本実施形態のDES-CBCと3DES-CBCとAES-CBCの中では、AES-CBCが初期ベクトルとブロックサイズより増加データサイズが大きくなる。初期ベクトル及びブロックサイズはRFC2405とRFC2451とRFC3602にて規定されている。ESP認証処理の認証データは認証アルゴリズム種別に依存し、本実施形態のHMAC-MD5とHMAC-SHA1とIPv4プロトコルでは、RFC2403とRFC2404に規定されている12byteとなる。
IPv4パケットでMTUが1500byteの場合、ESP処理においてAES-CBCは初期ベクトルが16byte、ブロックサイズが16byte、ESP認証処理の認証データが12byteである。増加するデータサイズは次式により、42byteとなる。
MTU=1500byte
IPv4ヘッダサイズ=20byte
SPIサイズ=4byte
シーケンス番号サイズ=4byte
初期ベクトルサイズ=16byte
ブロックサイズ=16byte
パディング長サイズ=1byte
次ヘッダサイズ=1byte
ESP認証データ=12byte
ペイロードデータサイズ=MTU−IPv4ヘッダサイズ
=1500−20
=1480byte
暗号化対象のペイロードデータサイズ=ペイロードデータサイズ
−SPIサイズ−シーケンス番号サイズ
−初期ベクトルサイズ
−ESP認証データ
=1480−4−4−16−12
=1444byte
パディング=暗号化対象のペイロードデータサイズ mod ブロックサイズ
=1444 mod 16 = 4byte
増加するデータサイズ= ペイロードデータサイズ−(暗号化対象のペイロードデータサイズ−パディング−パディング長サイズ−次ヘッダサイズ)
=1480−(1444−4−1−1)
=42byte
(4)AH処理とESP処理によって増加するデータサイズ
AH処理とESP処理を実施する場合は、AH処理によって増加するデータサイズ24byte(上記(1)参照。)を、ESP処理によって増加するデータサイズを計算(上記(2)参照。)する際、暗号化対象のペイロードデータサイズを求めるにときに利用する。AH処理とESP処理によって増加するデータサイズは次式により、58byteとなる。
MTU=1500byte
IPv4ヘッダサイズ=20byte
AH処理増加サイズ=24byte
SPIサイズ=4byte
シーケンス番号サイズ=4byte
初期ベクトルサイズ=16byte
ブロックサイズ=16byte
パディング長サイズ=1byte
次ヘッダサイズ=1byte
ペイロードデータサイズ=MTU−IPv4ヘッダサイズ
=1500−20
=1480byte
暗号化対象のペイロードデータサイズ=ペイロードデータサイズ
−AH処理増加データサイズ
−SPIサイズ−シーケンス番号サイズ
−初期ベクトルサイズ
=1480−24−4−4−16
=1432byte
パディング=暗号化対象のペイロードデータサイズ mod ブロックサイズ
=1432 mod 16 = 8byte
増加するデータサイズ= ペイロードデータサイズ−(暗号化対象のペイロードデータサイズ−パディング−パディング長サイズ−次ヘッダサイズ)
=1480−(1432−8−1−1)
=58byte
(5)AH処理とESP処理とESP認証処理によって増加するデータサイズ
AH処理とESP処理とESP認証処理を実施する場合は、AH処理によって増加するデータサイズ24byte(上記(1)参照。)を、ESP処理とESP認証処理によって増加するデータサイズを計算(上記(3)参照。)する際、暗号化対象のペイロードデータサイズを求めるときに利用する。AH処理とESP処理とESP認証処理によって増加するデータサイズは次式より、74byteとなる。
MTU=1500byte
IPv4ヘッダサイズ=20byte
AH処理増加サイズ=24byte
SPIサイズ=4byte
シーケンス番号サイズ=4byte
初期ベクトルサイズ=16byte
ブロックサイズ=16byte
パディング長サイズ=1byte
次ヘッダサイズ=1byte
ESP認証データ=12byte
ペイロードデータサイズ=MTU−IPv4ヘッダサイズ
=1500−20
=1480byte
暗号化対象のペイロードデータサイズ=ペイロードデータサイズ
−AH処理増加データサイズ
−SPIサイズ−シーケンス番号サイズ
−初期ベクトルサイズ
−ESP認証データ
=1480−24−4−4−16−12
=1420byte
パディング=暗号化対象のペイロードデータサイズ mod ブロックサイズ
=1420 mod 16 = 12byte
増加するデータサイズ= ペイロードデータサイズ−(暗号化対象のペイロードデータサイズ−パディング−パディング長サイズ−次ヘッダサイズ)
=1480−(1420−12−1−1)
=74byte
ネットワークプロトコル処理部101では、TCPを利用した通信においてデータ転送を行う間にコネクションの確立を行う。コネクションを確立するには3ウェイハンドシェイク(three-way handshaking)と呼ばれる処理を行う。3ウェイハンドシェイクにて送信するSYNは、IPsecを適用したとしてもMTUを超える程のIPパケットサイズではないため、フラグメンテーションが発生することにはならない。この3ウェイハンドシェイクのSYNの送信後、もしくはSYNの受信後の際、IPsecパケット増加サイズ計算部205は、IPパケットにIPsecを適用してもフラグメンテーションが発生しない範囲内で最大の送信サイズを計算する。ネットワークプロトコル処理部101は、送信元と宛先のIPアドレス、TCPプロトコル番号、送信元と宛先のポート番号、IPsec適用前のフラグメンテーションが発生しない最大送信サイズ(MTU)をIPsecパケット増加サイズ計算部205に渡す。IPsecパケット増加サイズ計算部205は、送信元及び宛先のIPアドレス、TCPプロトコル番号、送信元及び宛先のポート番号の情報を基に、SP管理部201からSPを検索し、その後、SA管理部202からSAを検索する。検索で見つかったSAが、AH、ESP、ESP認証機能の3つの処理の実行が必要であることを示す場合、IPsecパケット増加サイズ計算部205は、図3、図4に示したフローに従い増加サイズを計算する。計算した増加サイズは、ネットワークプロトコル処理部101に通知される。ネットワークプロトコル処理部101内のTCPは、最大送信データサイズ更新部104を用いて、最大送信データサイズ記憶部103に、通知された増加サイズを設定する。TCPでは、例えばコネクションを管理するTCB(Transmission Control Block)に最大送信データサイズを設定する。これにより、3ウェイハンドシェイク終了後に行うデータ転送は、IPsecの適用が考慮されている最大送信データサイズによって実施される。このため、IPsec適用部203によってIPパケットにIPsecが適用された後においても、IPパケットのフラグメンテーションが発生せずにネットワークインタフェース部105によりネットワーク上へIPパケットが送信される。
<実施形態3>
実施形態3では、IPsec適用によるデータサイズ増加に起因するIPパケットフラグメンテーションを抑制する処理において、IPsecパケット増加サイズ計算部205は次の処理を行う。すなわち、実施形態1又は2に記載の計算方法により計算した最大送信パケットサイズを、通信相手ごとのデータベースに記憶する。データベースの例を図8に示す。
図8のデータベースにおいて、通信相手ごとに以下の情報が記述される。
・AH処理により増加する最大サイズ、
・ESP処理により増加する最大サイズ、
・SP処理及びESP認証処理により増加する最大サイズ、
・AH処理及びESP処理により増加する最大サイズ、
・AH処理及びESP処理及びESP認証処理により増加する最大サイズ。
ネットワークプロトコル処理部101からは、IPsecパケット増加サイズ計算部205に、以下の情報が渡される。
・送信元と宛先のIPアドレス、
・TCPプロトコル番号、
・送信元と宛先のポート番号、
・IPsec適用前のフラグメンテーションが発生しない最大送信サイズ(MTU)。
IPsecパケット増加サイズ計算部205は、送信元と宛先のIPアドレス、プロトコル番号、送信元と宛先のポート番号の情報を基に、図8のデータベースから増加パケットサイズを検索する。ネットワークプロトコル処理部101は、検索で見つかった増加パケットサイズをIPsecパケット増加サイズ計算部205から取得する。
このデータベースは、SA管理部202に管理されているSAが存在する間は維持されるが、通信相手に該当するSAが全て削除されるとときに、データベースの該当のエントリも削除される。
以上説明した本発明の実施形態によれば、IPsec適用時、IPパケットが、MTUを超えない最大サイズでネットワーク上に送信される。このため、IPパケットのフラグメンテーションによる通信速度低下が発生しない。また、IPsec適用によるパケット増加サイズの計算は、暗号アルゴリズム又は認証アルゴリズムに依存しないので、その計算にかかる演算量を最小限にすることができる。また、IPsec適用によるパケット増加サイズの計算を実施するのがコネクション開始時の特定の場合のみのため、通信速度への影響度も少ない。
(他の実施形態)
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

Claims (12)

  1. 通信装置であって、
    第1のアルゴリズムを利用してIPSec(IP Security Protocol)に基づくパケット処理を実行する第1の実行手段と、
    第2のアルゴリズムを利用してIPSecに基づくパケット処理を実行する第2の実行手段と、
    前記第1のアルゴリズムを利用してパケット処理を実行した場合に増加するIPヘッダの第1サイズと、前記第2のアルゴリズムを利用してパケット処理を実行した場合に増加するIPヘッダの第2サイズとのうち、サイズが大きい方を記憶し、サイズが小さい方を記憶しないメモリと、
    前記第1のアルゴリズムを利用してパケット処理を実行する場合であっても、前記第2のアルゴリズムを利用してパケット処理を実行する場合であっても、前記メモリに記憶されたサイズに基づいて、フラグメンテーションが発生しないように、IPSecに基づくパケット処理が適用されるパケットに含まれる送信データサイズを決定する決定手段と、
    を有することを特徴とする通信装置。
  2. 前記決定手段は、フラグメンテーションが発生しない送信データサイズのうち最大のサイズを、送信データサイズとして決定することを特徴とする請求項1に記載の通信装置。
  3. 前記第1のアルゴリズムおよび前記第2のアルゴリズムは、前記通信装置が送信するパケットに含まれるデータを暗号化するための暗号化アルゴリズムであることを特徴とする請求項1または2に記載の通信装置。
  4. 前記第1のアルゴリズムは、DES-CBC、3DES-CBC、および、AES-CBCのうちの1つであり、前記第2のアルゴリズムは、DES-CBC、3DES-CBC、および、AES-CBCのうち、前記第1のアルゴリズムとは異なるアルゴリズムであることを特徴とする請求項3に記載の通信装置。
  5. 前記第1の実行手段および前記第2の実行手段は、IPSecに規定されたESP(Encapsulating Security Payload)モードのパケット処理を実行することを特徴とする請求項3または4に記載の通信装置。
  6. 前記第1のアルゴリズムおよび前記第2のアルゴリズムは、前記通信装置が送信するパケットに含まれるデータの認証処理を行うための認証アルゴリズムであることを特徴とする請求項1または2に記載の通信装置。
  7. 前記第1のアルゴリズムは、HMAC-MD5またはHMAC-SHA1であり、前記第2のアルゴリズムは、HMAC-MD5およびHMAC-SHA1のうち前記第1のアルゴリズムとは異なるアルゴリズムであることを特徴とする請求項6に記載の通信装置。
  8. 前記第1の実行手段および前記第2の実行手段は、IPSecに規定されたAH(Authentication Header)モードのパケット処理を実行することを特徴とする請求項6または7に記載の通信装置。
  9. 前記決定手段により決定された送信データサイズに応じたサイズに、送信データを分割する分割手段と、
    前記分割手段により分割された送信データの各々を、異なるIPパケットとして送信する送信手段と、
    を更に有することを特徴とする請求項1乃至8のいずれか1項に記載の通信装置。
  10. 前記決定手段は、前記送信手段によりIPパケットを送信する送信先ごとに前記送信データサイズを決定することを特徴とする請求項9に記載の通信装置。
  11. 第1のアルゴリズムを利用してIPSec(IP Security Protocol)に基づくパケット処理を実行する第1の実行手段と、第2のアルゴリズムを利用してIPSecに基づくパケット処理を実行する第2の実行手段とを有する通信装置の制御方法であって、
    前記第1の実行手段により前記第1のアルゴリズムを利用してパケット処理を実行した場合に増加するIPヘッダの第1サイズと、前記第2の実行手段により前記第2のアルゴリズムを利用してパケット処理を実行した場合に増加するIPヘッダの第2サイズとのうち、サイズが大きい方をメモリに格納し、サイズが小さい方をメモリには格納せず、
    前記第1の実行手段により前記第1のアルゴリズムを利用してパケット処理を実行する場合であっても、前記第2の実行手段により前記第2のアルゴリズムを利用してパケット処理を実行する場合であっても、前記メモリに格納されたサイズに基づいて、フラグメンテーションが発生しないように、IPSecに基づくパケット処理が適用されるパケットに含まれる送信データサイズを決定する
    ことを特徴とする制御方法。
  12. コンピュータを、請求項1乃至10のいずれか1項に記載の通信装置の各手段として機能させるためのプログラム。
JP2012225368A 2012-10-10 2012-10-10 通信装置及びその制御方法 Active JP6151906B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012225368A JP6151906B2 (ja) 2012-10-10 2012-10-10 通信装置及びその制御方法
US14/043,069 US9467471B2 (en) 2012-10-10 2013-10-01 Encrypted communication apparatus and control method therefor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012225368A JP6151906B2 (ja) 2012-10-10 2012-10-10 通信装置及びその制御方法

Publications (2)

Publication Number Publication Date
JP2014078852A JP2014078852A (ja) 2014-05-01
JP6151906B2 true JP6151906B2 (ja) 2017-06-21

Family

ID=50433714

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012225368A Active JP6151906B2 (ja) 2012-10-10 2012-10-10 通信装置及びその制御方法

Country Status (2)

Country Link
US (1) US9467471B2 (ja)
JP (1) JP6151906B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10051000B2 (en) * 2015-07-28 2018-08-14 Citrix Systems, Inc. Efficient use of IPsec tunnels in multi-path environment
US10419356B1 (en) * 2017-07-22 2019-09-17 Juniper Networks, Inc Apparatus, system, and method for discovering network path maximum transmission units
CN108848071A (zh) * 2018-05-30 2018-11-20 深圳市元征科技股份有限公司 一种数据传输方法、系统及设备和存储介质
US11310161B2 (en) * 2019-08-12 2022-04-19 Verizon Patent And Licensing Inc. Method and system for packet size management
US20210136036A1 (en) * 2019-11-01 2021-05-06 Parallel Wireless, Inc. Multi UE and Multi Message Support in Tunnel Management Messages
CN114301592B (zh) * 2021-12-30 2023-06-23 李秦豫 一种网络加密算法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020188871A1 (en) * 2001-06-12 2002-12-12 Corrent Corporation System and method for managing security packet processing
US20030196081A1 (en) * 2002-04-11 2003-10-16 Raymond Savarda Methods, systems, and computer program products for processing a packet-object using multiple pipelined processing modules
JP4367106B2 (ja) * 2003-11-26 2009-11-18 日本電気株式会社 ネットワーク、通信ノード及びそれらに用いるセキュリティ方法並びにそのプログラム
JP4672350B2 (ja) * 2004-12-06 2011-04-20 パナソニック電工株式会社 パケット長制御装置及び該方法並びにルータ装置
JP2008035272A (ja) * 2006-07-28 2008-02-14 Canon Inc 情報処理システム及び当該システムにおけるデータ通信方法
US8488628B2 (en) * 2007-06-14 2013-07-16 Research In Motion Limited Apparatus, and associated method, for selecting and negotiating frame size of communication data communicated in a radio communication system

Also Published As

Publication number Publication date
US20140101435A1 (en) 2014-04-10
JP2014078852A (ja) 2014-05-01
US9467471B2 (en) 2016-10-11

Similar Documents

Publication Publication Date Title
US11729155B2 (en) Segmentation of encrypted segments in networks
US20220174050A1 (en) Cloud storage using encryption gateway with certificate authority identification
JP6151906B2 (ja) 通信装置及びその制御方法
US10419406B2 (en) Efficient forwarding of encrypted TCP retransmissions
CN109150688B (zh) IPSec VPN数据传输方法及装置
TWI499342B (zh) 網路卸載方法與系統
US7774593B2 (en) Encrypted packet, processing device, method, program, and program recording medium
US7162630B2 (en) Systems and methods for implementing host-based security in a computer network
EP2742665B1 (en) Method and apparatus for coordinating compression information through key establishment protocols
TW201944754A (zh) 合作式傳輸層安全性協定(tls)加速
US10044841B2 (en) Methods and systems for creating protocol header for embedded layer two packets
US20110271096A1 (en) Loosely-Coupled Encryption Functionality for Operating Systems
WO2010124014A2 (en) Methods, systems, and computer readable media for maintaining flow affinity to internet protocol security (ipsec) sessions in a load-sharing security gateway
US20180091483A1 (en) Method for in-line tls/ssl cleartext encryption and authentication
KR101386809B1 (ko) 다중 mtu를 설정하는 모바일 디바이스 및 이를 이용한 데이터 전송 방법
EP3613195A1 (en) Cloud storage using encryption gateway with certificate authority identification
US11924248B2 (en) Secure communications using secure sessions
US7802090B2 (en) Determining composition of an initialization vector for encapsulating security payload processing
US20110271097A1 (en) Loosely-Coupled Encryption Functionality for Operating Systems
JP2009060245A (ja) 通信制御方法、プログラム及び通信装置
JP2012160941A (ja) 情報処理装置、情報処理方法及びプログラム
JP2011015042A (ja) 暗号化通信装置、暗号化通信方法及びプログラム
US20240106647A1 (en) Methods and systems of a packet orchestration to provide data encryption at the ip layer, utilizing a data link layer encryption scheme
US20220038443A1 (en) Methods and systems of a packet orchestration to provide data encryption at the ip layer, utilizing a data link layer encryption scheme
JP6228370B2 (ja) 通信装置、通信方法、及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150917

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160829

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160916

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161114

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: 20170428

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170526

R151 Written notification of patent or utility model registration

Ref document number: 6151906

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151