(57)【要約】      （修正有）【課題】ネットワーク上でIPパケットを暗号化して送信する場合においてフラグメントを処理する技術に関し、トランスポートモードでのIPsec処理において、事前にフラグメント処理されたパケットを暗号化可能とする。【解決手段】フラグメントパケットにおいて、２００１として示されるIPヘッダ１９０１のフラグメント情報が、３０４として示されるように暗号化の結果挿入されるべきESPヘッダ３０１内のSPIフィールド上位16ビットに退避させられ、元のIPヘッダ１９０１のフラグメント情報は、３０３として示されるようにクリアされる。この結果、フラグメントパケットに対してトランスポートモードでIPsec処理されたパケットは、見かけ上フラグメントされていないIPsecパケットとして転送される。この結果、復号側では、上記パケットを、IPsec処理後にフラグメントされたパケットと区別することができる。【選択図】図３
2009246801.tif 000002
【特許請求の範囲】
【請求項１】
インターネットプロトコルに基づいて通信されるIPパケットを、そのIPヘッダを含まない形態で暗号化する暗号化処理方法であって、
前記IPヘッダに含まれる分割情報を該IPヘッダ以外の領域に退避させる第１のステップと、
前記IPヘッダに含まれる分割情報をクリアする第２のステップと、
前記第１及び第２のステップの結果得られるIPパケットに対して暗号化処理を実行し、その結果得られる暗号化パケットを出力する第３のステップと、
を含むことを特徴とする分割されたパケットの暗号化方法。
【請求項２】
前記第１のステップは、前記IPヘッダに含まれる分割情報を前記暗号化処理において付加されるべき暗号化ヘッダの一部に退避させる、
ことを特徴とする請求項１に記載の分割されたパケットの暗号化方法。
【請求項３】
前記第１のステップは、前記IPヘッダに含まれる分割情報を前記暗号化処理において付加されるべきパディング領域の一部に退避させる、
ことを特徴とする請求項１に記載の分割されたパケットの暗号化方法。
【請求項４】
前記分割情報は、分割されたデータの元データの先頭からの位置を示すオフセット情報と、分割されたデータの後続データが存在するか否かを示す識別情報である、
ことを特徴とする請求項１乃至３の何れか１項に記載の分割されたパケットの暗号化方法。
【請求項５】
前記第１のステップは、前記IPヘッダにおいて前記分割情報が格納される領域の情報を、前記IPパケットが分割されたパケットであるか否かにかかわらず、前記IPヘッダ以外の領域に退避させる、
ことを特徴とする請求項１乃至４の何れか１項に記載の分割されたパケットの暗号化方法。
【請求項６】
インターネットプロトコルに基づいて通信されるIPパケットについて、該IPパケットのIPヘッダに含まれる分割情報が該IPヘッダ以外の領域に退避させられ該IPヘッダに含まれる分割情報がクリアされた上で暗号化された暗号化パケットを復号する復号方法であって、
前記暗号化パケットを復号する第４のステップと、
該復号の結果得られるIPパケットにおいて、前記退避させられている分割情報を、該IPパケットのIPヘッダに戻して出力する第５のステップと
を含むことを特徴とする分割暗号化パケットの復号方法。
【請求項７】
前記第５のステップは、暗号化処理において付加されている暗号化ヘッダの一部に退避させられている分割情報を、前記復号されたIPパケットのIPヘッダに戻して出力する、
ことを特徴とする請求項６に記載の分割暗号化パケットの復号方法。
【請求項８】
前記第５のステップは、暗号化処理において付加されているパディング領域一部に退避させられている分割情報を、前記復号されたIPパケットのIPヘッダに戻して出力する、
ことを特徴とする請求項６に記載の分割暗号化パケットの復号方法。
【請求項９】
前記分割情報は、分割されたデータの元データの先頭からの位置を示すオフセット情報と、分割されたデータの後続データが存在するか否かを示す識別情報である、
ことを特徴とする請求項６乃至８の何れか１項に記載の分割されたパケットの暗号化方
法。
【請求項１０】
インターネットプロトコルに基づいて通信されるIPパケットを、そのIPヘッダを含まない形態で暗号化する暗号化装置であって、
前記IPヘッダに含まれる分割情報を該IPヘッダ以外の領域に退避させる退避手段と、
前記IPヘッダに含まれる分割情報をクリアするクリア手段と、
前記退避手段と、前記クリア手段の結果得られるIPパケットに対して暗号化処理を実行し、その結果得られる暗号化パケットを出力する出力手段と、
を有することを特徴とする暗号化装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上でIPパケットを暗号化して送信する場合においてフラグメントを処理する技術に関する。
【背景技術】
【０００２】
個人情報保護法案や情報漏洩事件などによる社会的なセキュリティ意識の高まりや、IPsecを標準的に使用できるIPv6の普及開始を背景として、インターネット上で通信する際にデータを暗号化する方式としてIPsec（Security Architecture for the Internet Protocol）が注目されている。
【０００３】
IPsecの運用方法としては、VPNルータと呼ばれるIPsec機能を実装したルータ間で暗号化する方式と、エンド端末（PC）間で暗号化する方式があり、現在の主流はVPNルータを使用した方式である。
【０００４】
なお、今後エンド端末間で直接暗号化を行う方式が増えていくことも予想されるが、その際には、エンド端末が直接暗号化を行う以外に、Bump In The Wire(BITW)と呼ばれるネットワークケーブル上で暗号化を行う装置を外付けする方式も有望である。特にBITW装置は、PCのように高性能でない組み込み機器において高速な暗号化を実現する方法として注目されている。
【０００５】
また、IPsecの暗号化方法は、主にVPNルータにおいて使用されるトンネルモードと、主にエンド端末において使用されるトランスポートモードに分けられるが、トランスポートモードがVPNルータにおいて使用されることもある。
【０００６】
トランスポートモードでは、IPパケットのうちのデータ部分のみの認証／暗号化が行われ、元のIPヘッダは暗号化対象とされない。トランスポートモードでは、カプセル化（元のIPヘッダをデータの一部とみなして新規にIPヘッダをつけること）が行われないため、パケット長のオーバーヘッドが少ないという特徴を有する。
【０００７】
一方、トンネルモードでは、IPヘッダも含めて暗号化・カプセル化され、暗号化されたパケットには新たなIPヘッダが付加される。
図１３は、ルータ１３０２間でIPsec処理が行われる場合とエンド端末１３０１間でIPsec処理が行われる場合のそれぞれにおいて、パケットが保護（暗号化）される区間を示す。ルータ１３０２間でIPsec処理が行われる場合には、ルータがパケットの暗号化／復号処理を行い、エンド端末１３０１間でIPsecが行われる場合には、エンド端末がパケットの暗号化／復号処理を行う。
【０００８】
一般的にネットワーク上のパケットサイズの上限は1500バイト程度、下限は64バイトであり、ネットワーク上には様々なサイズのパケットが流れる。上限を超える大きさのデータを送る場合にはそのデータは分割される必要があり、特にUDP（User Data Protocol）と呼ばれるプロトコルで巨大なデータを送る場合には、一度巨大なデータを一つのIPパケットの形にしてからIPパケットを分割して送信する形となる。IPパケットを分割する処理のことをフラグメントと呼び、分割されたパケットをフラグメントパケットと呼ぶ。
【０００９】
例として図１４に、端末から送信される前の4088バイトのデータを持つUDPパケットの構成を示す。説明を簡単にするためにイーサパケットの最後に付加されるFCS（Frame Che
ck Sequence）は省略している。IPヘッダ１４０１とイーサネットヘッダ（Etherヘッダ）１４０２が付加されたIPパケット（イーサネットパケット）のデータ部に、UDPヘッダ１４０３と4088バイトのデータ１４０４とが格納されている。
【００１０】
次に、図１５は、上記UDPパケットが分割されて送信される場合の分割例を示した図である。ここでは、話を分かりやすくするために、全てのパケットにおいてIPパケット長が1044バイトになるように、分割が行われている。
【００１１】
ここでIPヘッダ(1)〜(4)は、どのように分割されたかを示す分割情報を除いては同一である。分割情報は、先頭データからのオフセットを8バイト単位で示すfragment offsetと、後続のフラグメントパケットの有無を示すMF(More Flag)で表され、図１５の例の場合では、図１６に示される表のようになる。
【００１２】
フラグメントパケットに対しては、トンネルモードにおいては、IPヘッダも含むIPパケットごとIPsecカプセル化処理（暗号化処理）が行われて送信され、受信側では、IPsecデカプセル化処理（復号処理）によってフラグメントパケットが取り出された後に、受信側端末等に転送され、そこで、元のIPパケットの組立処理（これを「リアセンブル処理」という）が行われて復元される。
【００１３】
また、トンネルモード、トランスポートモード共に、IPsec処理の後にIPsecパケットの長さがネットワーク上のパケットサイズの上限を超えるような場合にフラグメント処理が行われる場合もあり、その場合には、受信側では、まずルータ装置等においてリアセンブル処理が行われた後にIPsec処理（復号）が実行される。
【００１４】
フラグメント処理とIPsec処理とに関する従来技術として、例えば下記特許文献１又は下記特許文献２に記載の技術が公知である。
【特許文献１】特開２００７−１３５０３５号公報
【特許文献２】特開２００２−４４１３５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１５】
しかし、特許文献１や特許文献２に記載の従来技術は、トンネルモードでのIPsec処理を前提とした技術であり、トランスポートモードを使用したIPsec処理には適用できなかった。
【００１６】
そして従来は、トランスポートモードでのIPsec処理においては、事前にフラグメントされたパケットをIPsec処理することは禁止されていた。
具体的には、図１７の動作フローチャートとして示されるように、送信側の端末装置又はＢＩＴＷ装置又はルータ装置に実装されているトランスポートモードで動作するIPsec処理装置は、フラグメントパケットが到来したか否かを監視し（ステップＳ１７０１）、フラグメントパケットが到来していない場合にはIPsec処理（暗号化）を行い（ステップＳ１７０２）、フラグメントパケットが到来した場合にはそのパケットを廃棄していた（ステップＳ１７０３）。
【００１７】
一方、図１８の動作フローチャートとして示されるように、受信側の端末装置又はＢＩＴＷ装置又はルータ装置に実装されているトランスポートモードで動作するIPsec処理装置は、IPsec処理後にフラグメント処理がされている場合（これは許される）を考慮して、フラグメントパケットが到来したか否かを監視し（ステップＳ１８０１）、フラグメントパケットが到来していない場合にはそのままIPsec処理（復号）を行い（ステップＳ１８０２）、フラグメントパケットが到来した場合にはリアセンブル処理を行って元のIPsecパケットを組み立てた後に（ステップＳ１８０３）、IPsec処理（復号）（ステップＳ１８０２）を行っていた。
【００１８】
このように、送信側にてトランスポートモードでIPsec処理（暗号化）を行う場合に、フラグメントパケットを廃棄しなければならない理由は、以下に説明するように、IPヘッダにフラグメント情報を含むIPsec処理後のパケットが、IPsec処理前にフラグメント処理されたものなのか、IPsec処理後にフラグメント処理されたものなのか区別がつかないためである。
【００１９】
具体的には、図１９に示されるように、例えばUDPヘッダ１９０２と2040バイトのデータ１９０３とからなる上位レイヤパケットが格納され、IPヘッダ１９０１とイーサネットヘッダ（Etherヘッダ）１９０４が付加されたパケットがオリジナルパケットとしてあった場合、そのIPヘッダ１９０１内のフラグメント情報{flags, Fragment Offset}は、１９０５として示されるように、クリアされた状態になっている。
【００２０】
なお、説明を簡単にするために、IPsec処理はトランスポートモードに限定し、認証処理は行わず暗号処理のみを行うこととし、暗号化の際のパディング処理についても必要な時以外は説明を省略し、パディングによるパケット長の増加も考慮しない。また、フラグメント情報として、{flags, fragment offset}というIPヘッダ中の形式のまま表示する。Flagsは{未使用ビット、DF(Don’t fragment)ビット、MF(More fragment)ビット}の3bitで構成され、Flags = 0x1がMF=1（後続あり）という意味になる。Fragment offsetは先頭位置からのデータオフセットを8バイト単位で表したものである。
【００２１】
図１９に示されるオリジナルパケットに対して、まず、フラグメント処理が行われた後にIPsec処理が行われる第１のケースを考える。なお、この第１のケースは本来禁止されているケースであるため、以下の説明はルールを無視して処理を進めた場合の説明である。
【００２２】
始めにオリジナルパケットに対して、例えば図２０に示されるようなフラグメント処理が実行されたとする。
この場合、図２０（ａ）に示される１番目のフラグメントパケットにおいては、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}は、図中２００１として示されるように、flags（MF）=1（後続あり）、Fragment Offset=0x0（先頭のフラグメントを表す）となる。また、データ部には、オリジナルパケットのUDPヘッダ１９０２とデータ１９０３のうち先頭の1〜1016バイトまでのデータ１９０３−１が格納される。
【００２３】
次に、図２０（ｂ）に示される２番目のフラグメントパケットにおいては、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}は、図中２００２として示されるように、flags（MF）=0（後続なし）、Fragment Offset=0x100となる。データ部には、オリジナルパケットのデータ１９０３のうちの後半部の1017〜2040バイトまでのデータ１９０３−２が格納される。
【００２４】
続いて、上記フラグメントパケットに対して、例えば図２１に示されるようなIPsec処理（暗号化）が実行されたとする。
この場合、図２１（ａ）に示される１番目のフラグメントパケットをIPsec処理したパケットにおいては、まず、図２０（ａ）のUDPヘッダ１９０２と分割データ１９０３−１とからなるデータ部が暗号化されて２１０２になり、データ部の先頭にESPヘッダ２１０１が追加される。このヘッダは、RFC（Request for Comments）2406やRFC4303で規定されている、IPsec処理における暗号ペイロードヘッダである。また、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}は、図中２１０３として示されるように、図２０（ａ）の場合と同じく、flags（MF）=1（後続あり）、Fragment Offset=0x0となる。なお、IPヘッダ１９０１内のNext Protocolフィールドの値は、ESP暗号化を表す値 0x32となる。
【００２５】
次に、図２１（ｂ）に示される２番目のフラグメントパケットをIPsec処理したパケットにおいては、まず、図２０（ｂ）のデータ部の分割データ１９０３−２が暗号化されて２１０５になり、データ部の先頭にESPヘッダ２１０４が追加される。また、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}は、図中２１０６として示されるように、図２０（ｂ）の場合と同じく、flags（MF）=0（後続無し）、Fragment Offset=0x100となる。なお、図２１（ａ）と同様に、IPヘッダ１９０１内のNext Protocolフィールドの値は、ESP暗号化を表す値 0x32となる。
【００２６】
上記図２１（ａ）及び（ｂ）に例示される、フラグメントパケットをIPsec処理したパケットが、受信側に向けて送信される。
次に、上記第１のケースとは逆に、図１９に示されるオリジナルパケットに対して、まず、IPsec処理が行われた後に、フラグメント処理が行われる第２のケースを考える。この第２のケースは、従来許可されているケースである。
【００２７】
まず、図１９に示されるオリジナルパケットに対して、例えば図２２に示されるようなIPsec処理（暗号化）が実行されたとする。
この場合、まず、図１９のUDPヘッダ１９０２とデータ１９０３とからなるデータ部が暗号化されて２２０２になり、データ部の先頭にESPヘッダ２２０１が追加される。また、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}は、図中２２０３として示されるように、図１９の場合と同じくクリアされたままである。なお、IPヘッダ１９０１内のNext Protocolフィールドの値は、ESP暗号化を表す値 0x32となる。
【００２８】
続いて、上記IPsecパケットに対して、例えば図２３に示されるようなフラグメント処理が実行されたとする。
この場合、図２３（ａ）に示される１番目のフラグメントパケットにおいては、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}は、図中２３０１として示されるように、flags（MF）=1（後続あり）、Fragment Offset=0x0（先頭のフラグメントを表す）となる。また、データ部には、図２２に示されるIPsecパケットのESPヘッダ２２０１と暗号化データ２２０２のうち先頭の例えば1〜1000バイトまでのデータ２２０２−１が格納される。
【００２９】
次に、図２３（ｂ）に示される２番目のフラグメントパケットにおいては、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}は、図中２３０２として示されるように、flags（MF）=0（後続無し）、Fragment Offset=0x100となる。また、データ部には、図２２に示されるIPsecパケットの暗号化データ２２０２のうち後半の例えば1001〜2040バイトまでのデータ２２０２−２が格納される。
【００３０】
上記図２３（ａ）及び（ｂ）に例示される、IPsecパケットをフラグメント処理したパケットが、受信側に向けて送信される。
ここで、前述した、フラグメント処理が行われた後にIPsec処理が行われる第１のケースである図２１の場合と、上記IPsec処理が行われた後にフラグメント処理が行われる第２のケースである図２３の場合とを比較してみる。
【００３１】
受信側では、パケットのヘッダを判断して処理を決定するが、例えば図２１（ａ）のパケットと図２３（ａ）のパケットを比較すると、IPヘッダ１９０１に設定されているフラグメント情報{flags, Fragment Offset}は、２１０３及び２３０１として示されるように
全く同一であり、ESPヘッダ２１０１と２２０１も同一である。従って、このままでは、受信側は、IPsec処理（復号）とリアセンブル処理のどちらを先に行うべきか判断がつかない。
【００３２】
図２１（ｂ）のパケットと図２３（ｂ）のパケットでも、まず、図２１（ｂ）のパケットについては、上述のように、受信側は、IPsec処理（復号）とリアセンブル処理のどちらを先に行うべきか判断がつかない。また、図２３（ｂ）のパケットについては、ESPヘッダが付いていないため、受信側は、リアセンブル処理を行おうとするが、上述の理由で先頭のフラグメントパケットを見つけることができないため、リアセンブル処理を行うことができない。
【００３３】
本来であれば、図２１に示される第１のケースのパケットに対しては、IPsec処理（復号）を先に行って暗号化されていないフラグメントパケット（図２０）を得てから、一連の得られたフラグメントパケットに対してリアセンブル処理を行うべきである。一方、図２３に示される第２のケースのパケットに対しては、リアセンブル処理を先に行って元のIPsecパケット（図２２）を組み立ててから、その組み立てたIPsecパケットに対してIPsec処理（復号）を行うべきである。
【００３４】
以上のように、IPsec処理された後にフラグメントされた第２のケースのパケットと区別がつかなくなるという理由で、トランスポートモードでのIPsec処理においては、事前にフラグメントされたパケットをIPsec処理する第１のケースは、RFC2406（3.3.5項）及びRFC4303（3.3.4項）にて禁止されていた。
【００３５】
近年、インターネットやローカルエリアネットワークを含むグローバルネットワークの構成はますます複雑化しており、パケット長のオーバーヘッドが少ないトランスポートモードによるIPsec処理がルータ装置等に実装されるケースも増えており、事前にフラグメントされたパケットがトランスポートモードでIPsec処理を行うルータ装置やその他の中継端末等に流入するケースも増加している。
【００３６】
しかしこのような場合には、従来は、上述の理由で、図１７に示したように、流入したフラグメントパケットは廃棄されてしまう。この結果、上位レイヤの判定によりパケットとの再送が頻発したり、場合によっては通信不能という状況が発生してしまい、パケット長のオーバーヘッドが少ないというトランスポートモードの特性が生かされず、ネットワークの通信品質が低下してしまうという問題点を有していた。
【課題を解決するための手段】
【００３７】
本発明の課題は、トランスポートモードでのIPsec処理において、事前にフラグメント処理されたパケットを暗号化可能とすることにある。
本発明の第１の態様は、インターネットプロトコルに基づいて通信されるIPパケットを、そのIPヘッダを含まない形態で暗号化する暗号化処理方法又はそのプログラムを前提とする。
【００３８】
まず、IPヘッダに含まれる分割情報をそのIPヘッダ以外の領域に退避させる第１のステップが実行される。この第１のステップでは例えば、IPヘッダに含まれる分割情報が暗号化処理において付加されるべき暗号化ヘッダの一部に退避させられる。或いは、この第１のステップでは例えば、IPヘッダに含まれる分割情報が暗号化処理において付加されるべきパディング領域の一部に退避させられる。また、分割情報は例えば、分割されたデータの元データの先頭からの位置を示すオフセット情報と、分割されたデータの後続データが存在するか否かを示す識別情報である。更に、第１のステップは、IPヘッダにおいて分割情報が格納される領域の情報を、IPパケットが分割されたパケットであるか否かにかかわらず、IPヘッダ以外の領域に退避させるように構成することも可能である。
【００３９】
次に、IPヘッダに含まれる分割情報をクリアする第２のステップが実行される。
そして、第１及び第２のステップの結果得られるIPパケットに対して暗号化処理を実行し、その結果得られる暗号化パケットを出力する第３のステップが実行される。
【００４０】
本発明の第２の態様は、インターネットプロトコルに基づいて通信されるIPパケットについて、そのIPパケットのIPヘッダに含まれる分割情報がそのIPヘッダ以外の領域に退避させられそのIPヘッダに含まれる分割情報がクリアされた上で暗号化された暗号化パケットを復号する復号方法又はそのプログラムを前提とする。
【００４１】
まず、暗号化パケットを復号する第４のステップが実行される。
次に、その復号の結果得られるIPパケットにおいて、退避させられている分割情報を、そのIPパケットのIPヘッダに戻して出力する第５のステップが実行される。この第５のステップでは例えば、暗号化処理において付加されている暗号化ヘッダの一部に退避させられている分割情報が、復号されたIPパケットのIPヘッダに戻して出力される。或いは、この第５のステップでは例えば、暗号化処理において付加されているパディング領域一部に退避させられている分割情報が、復号されたIPパケットのIPヘッダに戻して出力される。また、分割情報は例えば、分割されたデータの元データの先頭からの位置を示すオフセット情報と、分割されたデータの後続データが存在するか否かを示す識別情報である。更に、第５のステップは、復号の結果得られるIPパケットが分割されたパケットであるか否かにかかわらず、そのIPパケットにおいて退避させられている分割情報を、そのIPパケットのIPヘッダに戻して出力するように構成することができる。
【発明の効果】
【００４２】
本発明によれば、フラグメントパケット中のフラグメント情報を暗号化ヘッダ内に退避させることにより、新しいフィールドやプロトコルを追加することなく、分割されたパケットを暗号化及び復号することが可能となる。この場合に、暗号化後に分割されたパケットと暗号化前に分割されたパケットの処理を区別することが可能となる。
【００４３】
また本発明によれば、フラグメントパケット中のフラグメント情報を暗号化処理において追加されるパディング内に退避させることにより、新しいフィールドやプロトコルを追加することなくかつヘッダフォーマットも変更することなく、分割されたパケットを暗号化及び復号することが可能となる。この場合も、暗号化後に分割されたパケットと暗号化前に分割されたパケットの処理を区別することが可能となり、また、オリジナルパケットの分割情報も暗号化により保護されるというメリットも生まれる。
【００４４】
更に本発明によれば、分割されたパケットであるか否かにかかわらず上記退避処理を行うことにより、パケット処理のスループットを向上させることが可能となる。
【発明を実施するための最良の形態】
【００４５】
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
本発明の実施形態が適用されるハードウェア構成
図１は、後述する本発明の各実施形態を実現できるコンピュータのハードウェア構成の基本構成例を示す図である。
【００４６】
本発明の実施形態におけるIPsec処理が、ルータ装置において実現される場合には、図１のハードウェア構成はルータ装置のハードウェアとなり、ＢＩＴＷ装置において実現される場合には、図１のハードウェア構成はＢＩＴＷ装置のハードウェアとなり、端末装置において実現される場合には、図１のハードウェア構成はワークステーションコンピュー
タ又はパーソナルコンピュータのハードウェアとなる。
【００４７】
図１に示されるコンピュータは、少なくともＣＰＵ１０１、メモリ１０２、外部記憶装置１０３、及びネットワーク接続装置１０４を有し、これらがバス１０５によって相互に接続された構成を有する。外部記憶装置１０３は、端末装置の場合には例えばハードディスク記憶装置やＣＤ−ＲＯＭ記憶装置、ルータ装置の場合には例えばフラッシュＲＯＭメモリ等である。端末装置の場合には、図１の構成に加えて、キーボード・マウス等の入力装置、ディスプレイ・プリンタ等の出力装置等も接続される。同図に示される構成は、本発明の実施形態として実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。また、本発明の実施形態はコンピュータに限定されるものでもなく、例えばメモリや外部記憶装置を持たないハードワイヤードロジックで構成される回路も含む。
【００４８】
ＣＰＵ１０１は、当該コンピュータ全体の制御を行う。メモリ１０２は、プログラムの実行、データ更新等の際に、外部記憶装置１０３に記憶されているプログラム又はデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ１０１は、プログラムをメモリ１０２に読み出して実行することにより、全体の制御を行う。
【００４９】
外部記憶装置１０３は、主に各種データやプログラムの保存に用いられる。
ネットワーク接続装置１０４は、例えばLAN（ローカルエリアネットワーク）又はWAN（ワイドエリアネットワーク）の通信回線を接続するための装置である。端末装置においてはLAN,WANの2ポートではなく、1ポートのみを持つ場合が多い。
【００５０】
本実施形態によるシステムは、後述する動作フローチャート群の各機能を実現するプログラムをＣＰＵ１０１が実行することで実現される。そのプログラムは、例えば外部記憶装置１０３等に記録して配布してもよく、或いはネットワーク接続装置１０４によりネットワークから取得できるようにしてもよい。
【００５１】
上述の構成を有する本発明の実施形態の動作について以下に説明する。
以下に説明する各実施形態では、事前にフラグメントされたパケットのフラグメント情報をIPsec用ヘッダ内又はパディング内に退避させることにより、該当パケットのIPsec処理を可能にするものである。
【００５２】
第１の実施形態
まず、本発明の第１の実施形態について説明する。
第１の実施形態では、事前にフラグメントされたパケットのフラグメント情報は、IPsec処理におけるESPヘッダ内に退避されることが特徴である。
【００５３】
図２は、第１の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec暗号化処理の動作フローチャートである。
まず、例えば図１のLANからネットワーク接続装置１０４を介して到来したパケットが、フラグメントパケットであるか否かが判定される（ステップＳ２０１）。フラグメントパケットであるか否かは、到来したパケットのIPヘッダ内のフラグメント情報から判定することができる。
【００５４】
到来したパケットがフラグメントパケットではないと判定された場合には、通常のIPsec処理が実行され（ステップＳ２０１−＞Ｓ２０２）、その結果生成されたIPsecパケットが、ネットワーク接続装置１０４からWANに出力される。
【００５５】
到来したパケットがフラグメントパケットであると判定された場合には、フラグメント
情報退避処理が実行され（ステップＳ２０１−＞Ｓ２０３）、その後に通常のIPsec処理が実行される（ステップＳ２０３−＞Ｓ２０２）。これらの処理の詳細について、以下に説明する。
【００５６】
今例えば、従来技術の説明において前述した図１９に示されるUDPパケットに対して、外部の端末装置においてフラグメント処理が実行され、更に、図１のコンピュータにおいてルータ装置またはBITW装置としてIPsec処理が実行される場合を考える。
【００５７】
まず、図３（ａ）に示されるIPsec処理前の１番目のフラグメントパケット（図２０（ａ）と同じもの）においては、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}は、図中２００１として示されるように、flags（MF）=1（後続あり）、Fragment Offset=0x0（先頭のフラグメントを表す）となる。また、データ部には、オリジナルパケットのUDPヘッダ１９０２とデータ１９０３のうち先頭の1〜1016バイトまでのデータ１９０３−１が格納される。
【００５８】
図３（ｂ）は、図３（ａ）に示される１番目のフラグメントパケットをIPsec処理して得られるパケットを表した図である。
このとき、第１の実施形態の特徴として、図３（ａ）のIPヘッダ１９０１に設定されていたフラグメント情報{flags, Fragment Offset}、flags（MF）=1、Fragment Offset=0x0が、図中３０４として示されるように、IPsecパケットに付加されるべきESPヘッダ３０１内のSPIフィールドの上位16ビット（下位16ビットでもよい）内に退避される。また、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}が、図中３０３として示されるように、flags（MF）=0、Fragment Offset=0x0にクリアされる。なお、IPヘッダ１９０１内のNext Protocolフィールドの値は、ESP暗号化を表す値 0x32となる。（以上、図２のステップＳ２０３。）
そして、図３（ａ）のUDPヘッダ１９０２と分割データ１９０３−１とからなるデータ部が暗号化されて３０２になり、データ部の先頭に上記ESPヘッダ３０１が追加される。（図２のステップＳ２０２。）
図４（ａ）に示されるIPsec処理前の２番目のフラグメントパケット（図２０（ｂ）と同じもの）においては、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}は、図中２００２として示されるように、flags（MF）=0（後続無し）、Fragment Offset=0x100となる。また、データ部には、オリジナルパケットのデータ１９０３のうち後半の1017〜2040バイトまでのデータ１９０３−２が格納される。
【００５９】
図４（ｂ）は、図４（ａ）に示される２番目のフラグメントパケットをIPsec処理して得られるパケットを表した図である。
このときも、図３（ｂ）の場合と同様に、図４（ａ）のIPヘッダ１９０１に設定されていたフラグメント情報{flags, Fragment Offset}、flags（MF）=0、Fragment Offset=0x100が、図中４０４として示されるように、IPsecパケットに付加されるべきESPヘッダ４０１内のSPIフィールドの上位16ビット（下位16ビットでもよい）内に退避される。また、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}が、図中４０３として示されるように、flags（MF）=0、Fragment Offset=0x0にクリアされる。なお、IPヘッダ１９０１内のNext Protocolフィールドの値は、ESP暗号化を表す値 0x32となる。（以上、図２のステップＳ２０３。）
そして、図４（ａ）の分割データ１９０３−２からなるデータ部が暗号化されて４０２になり、データ部の先頭に上記ESPヘッダ４０１が追加される。（図２のステップＳ２０２。）
図４の３０１及び３０２の部分又は図４の４０１及び４０２の部分を含むESP（IP Encapsulating Security Payload）フォーマットの詳細を、図５(a)に示す。図５(a)において、「SPI（Security Pointer Index）」は、パケット内の通信内容がどのような暗号化アルゴリズムで暗号化されたのか及びどの暗号鍵を使うのかといった暗号化アルゴリズム及び暗号鍵に関する合意（「SA（Security Association）」と呼ばれる）と関連付けて割り当てられる32ビットの整数値である。受信側の復号装置は、通信開始時のネゴシエーションにおいてこのSPIをどのように設定するかを決定し、通信開始後はこの値を見て、復号化のための暗号化アルゴリズムと暗号鍵を選び出す。本実施形態では、このSPIの例えば上位16ビット（下位16ビットでもよい）に、フラグメント情報を退避する。なお、図５(a)のESPフォーマットは、RFC4303（IPsecバージョン3）において規定されているが、RFC2406（IPsecバージョン2）でも同様にSPIが利用可能である。
【００６０】
以上のようにして、第１の実施形態において、事前にフラグメント処理されたパケットがIPsec処理（暗号化）されて生成されたIPsecパケットにおいては、IPヘッダ部のフラグメント情報はクリアされているため、見かけ上フラグメントされていないIPsecパケットとして図１の装置からWAN等に送出される。
【００６１】
その後、途中経路上で、IPsecパケットがフラグメントされる場合はあり得る。その場合には、IPsecパケットのIPヘッダに新たにフラグメント情報が設定される。
このようにして処理されたIPsecパケットが受信側の装置で受信された場合の動作について、以下に説明する。
【００６２】
図６は、第１の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec復号処理の動作フローチャートである。
まず、例えば図１のWANからネットワーク接続装置１０４を介して到来したパケットが、フラグメントパケットであるか否かが判定される（ステップＳ６０１）。
【００６３】
到来したパケットがフラグメントパケットであると判定された場合には、これは送信側にてIPsec処理された後にフラグメント処理されたパケットであるため、リアセンブル処理が実行される（ステップＳ６０２）。
【００６４】
到来したパケットがフラグメントパケットではないと判定された場合、又は上記リアセンブル処理の後に、IPsecヘッダであるESPヘッダのSPIフィールド上位１６ビット（下位１６ビットでもよい）にフラグメント情報が格納されているか否か（図３（ｂ）の３０４又は図４（ｂ）の４０４参照）が判定される（ステップＳ６０３）。
【００６５】
もし、フラグメント情報が格納されていると判定された場合には、そのフラグメント情報がメモリ１０２（図１）上のフラグメント情報変数に格納される（ステップＳ６０４）。
【００６６】
フラグメント情報が格納されていない場合、又は格納されていて上記フラグメント情報変数への取出しが行われた後、IPsec処理（復号）が実行されて、暗号化前の元のパケットが取り出される（ステップＳ６０５）。
【００６７】
続いて、前述のフラグメント情報変数に値があるか否かが判定される（ステップＳ６０６）。
フラグメント情報変数に値がある場合には、復号されたパケットはフラグメントパケットであるため、そのフラグメント情報変数の値が、復号されたパケットのIPヘッダのフラグメント情報フィールド（図３（ａ）の２００１又は図４（ａ）の２００２参照）に戻される。
【００６８】
以上のようにして得られた暗号化前のパケットが、ネットワーク接続装置１０４からLANに出力される。このパケットがフラグメントパケットである場合には、後段の端末装置においてリアセンブル処理される。
【００６９】
第２の実施形態
次に、本発明の第２の実施形態について説明する。
第２の実施形態では、事前にフラグメントされたパケットのフラグメント情報は、IPsec処理におけるパディング内に退避されることが特徴である。
【００７０】
第２の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec暗号化処理の動作フローチャートは、第１の実施形態における図２の動作フローチャートと同じである。
【００７１】
第２の実施形態が第１の実施形態と異なる部分は、到来したパケットがフラグメントパケットであると判定された場合における、フラグメント情報退避処理（ステップＳ２０３）の部分の処理である。第１の実施形態ではフラグメント情報はESPヘッダのSPI上位16ビットに退避させられたが、第２の実施形態では、フラグメント情報はパディング内に退避させられる。
【００７２】
この処理とそれに続くIPsec処理の詳細について、以下に説明する。
まず、図７（ａ）に示されるIPsec処理前の１番目のフラグメントパケットは、第１の実施形態における図３（ａ）と同じである。
【００７３】
図７（ｂ）は、図７（ａ）に示される１番目のフラグメントパケットに対して、IPsec処理の前処理としてフラグメント情報を退避して得られるパケットを表した図である。
このとき、第２の実施形態の特徴として、図７（ａ）のIPヘッダ１９０１に設定されていたフラグメント情報{flags, Fragment Offset}、flags（MF）=1、Fragment Offset=0x0が、図中７０１として示されるように、IPsec処理においてペイロードデータに続けて挿入されるパディング部に退避される。また、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}が、図中７０２として示されるように、flags（MF）=0、Fragment Offset=0x0にクリアされる。なお、IPヘッダ１９０１内のNext Protocolフィールドの値は、ESP暗号化を表す値 0x32となる。（以上、図２のステップＳ２０３。）
図７（ｃ）は、図７（ｂ）に示されるフラグメント情報が退避させられた１番目のフラグメントパケットに対して、IPsec処理を実行して得られるパケットを表した図である。
【００７４】
即ち、図７（ｂ）のUDPヘッダ１９０２と分割データ１９０３−１とパディング７０１からなるデータ部が暗号化されて７０４になり、データ部の先頭にESPヘッダ７０３が追加される。（図２のステップＳ２０２。）
次に、図８（ａ）に示されるIPsec処理前の２番目のフラグメントパケットは、第１の実施形態における図４（ａ）と同じである。
【００７５】
図８（ｂ）は、図８（ａ）に示される２番目のフラグメントパケットに対して、IPsec処理の前処理としてフラグメント情報を退避して得られるパケットを表した図である。
このときも、図７（ｂ）の場合と同様に、図８（ａ）のIPヘッダ１９０１に設定されていたフラグメント情報{flags, Fragment Offset}、flags（MF）=0、Fragment Offset=0x100が、図中８０１として示されるように、IPsec処理においてペイロードデータに続けて挿入されるパディング部に退避される。また、IPヘッダ１９０１に設定されるフラグメント情報{flags, Fragment Offset}が、図中８０２として示されるように、flags（MF）=0、Fragment Offset=0x0にクリアされる。なお、IPヘッダ１９０１内のNext Protocolフィールドの値は、ESP暗号化を表す値 0x32となる。（以上、図２のステップＳ２０３。）
図８（ｃ）は、図８（ｂ）に示されるフラグメント情報が退避させられた２番目のフラグメントパケットに対して、IPsec処理を実行して得られるパケットを表した図である。
【００７６】
即ち、図８（ｂ）の分割データ１９０３−２とパディング８０１とからなるデータ部が暗号化されて８０４になり、データ部の先頭にESPヘッダ８０３が追加される。（図２のステップＳ２０２。）
パディング部は、第１の実施形態の説明において前述した図５(a)のESPフォーマットにおいて、ペイロードデータに続いて挿入される部分である。暗号化アルゴリズムによって処理する単位が決まっているので、ペイロードデータをその単位にそろえる必要がある。そのためにペイロードデータに埋め合わせのデータを付加する。これがパディングである。そして付加したバイト数が図５(a)のパディング長に設定される。
【００７７】
以上のようにして処理されたIPsecパケットが受信側の装置で受信された場合の動作について、以下に説明する。
図９は、第２の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec復号処理の動作フローチャートである。
【００７８】
まず、例えば図１のWANからネットワーク接続装置１０４を介して到来したパケットが、フラグメントパケットであるか否かが判定される（ステップＳ９０１）。
到来したパケットがフラグメントパケットであると判定された場合には、これは送信側にてIPsec処理された後にフラグメント処理されたパケットであるため、リアセンブル処理が実行される（ステップＳ９０２）。
【００７９】
到来したパケットがフラグメントパケットではないと判定された場合、又は上記リアセンブル処理の後に、IPsec処理（復号）が実行されて、暗号化前の元のパケットが取り出される（ステップＳ９０３）。
【００８０】
続いて、復号されたパケットのペイロードデータに続くパディング部（図７（ｂ）の７０１又は図８（ｂ）の８０１参照）に、フラグメント情報が格納されているか否かが判定される（ステップＳ９０４）。
【００８１】
フラグメント情報が格納されていると判定された場合には、復号されたパケットはフラグメントパケットであるため、そのフラグメント情報が、復号されたパケットのIPヘッダのフラグメント情報フィールド（図７（ａ）の２００１又は図８（ａ）の２００２参照）に戻される（ステップＳ９０５）。
【００８２】
以上のようにして得られた暗号化前のパケットが、ネットワーク接続装置１０４からLANに出力される。このパケットがフラグメントパケットである場合には、後段の端末装置においてリアセンブル処理される。
【００８３】
第３の実施形態
次に、本発明の第３の実施形態について説明する。
第３の実施形態では、IPsecの暗号処理において、到来したパケットがフラグメントパケットであるか否かの判定をすることなく無条件に、IPヘッダ内のフラグメント情報が、IPsec処理におけるESPヘッダ内に退避されることが特徴である。
【００８４】
このようにすることにより、到来したパケットがフラグメントパケットであるか否かの判定を行う処理が不要となり、パケット処理のスループットが向上する。
図１０は、第３の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec暗号化処理の動作フローチャートである。
【００８５】
まず、図１のLANからネットワーク接続装置１０４を介して到来したパケットのIPヘッ
ダ内のフラグメント情報（図３（ａ）の２００１又は図４（ａ）の２００２参照）が、ESPヘッダ内のSPIフィールド上位16ビット（図３（ｂ）の３０４又は図４（ｂ）の４０４参照）に退避させられる（ステップＳ１００１）。
【００８６】
そして、通常のIPsec処理が実行され（ステップＳ１００２）、その結果生成されたIPsecパケットが、図１のネットワーク接続装置１０４からWANに出力される。
図１１は、第３の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec復号処理の動作フローチャートである。
【００８７】
まず、例えば図１のWANからネットワーク接続装置１０４を介して到来したパケットが、フラグメントパケットであるか否かが判定される（ステップＳ１１０１）。
到来したパケットがフラグメントパケットであると判定された場合には、これは送信側にてIPsec処理された後にフラグメント処理されたパケットであるため、リアセンブル処理が実行される（ステップＳ１１０２）。
【００８８】
到来したパケットがフラグメントパケットではないと判定された場合、又は上記リアセンブル処理の後に、IPsecヘッダであるESPヘッダのSPIフィールド上位16ビットに格納されているフラグメント情報がメモリ１０２（図１）上のフラグメント情報変数に格納される（ステップＳ１１０３）。
【００８９】
その後、IPsec処理（復号）が実行されて、暗号化前の元のパケットが取り出される（ステップＳ１１０４）。
最後に、前述のフラグメント情報変数に格納されているフラグメント情報変数の値が、復号されたパケットのIPヘッダのフラグメント情報フィールド（図３（ａ）の２００１又は図４（ａ）の２００２参照）に戻される。
【００９０】
以上のようにして得られた暗号化前のパケットが、ネットワーク接続装置１０４からLANに出力される。このパケットがフラグメントパケットである場合には、後段の端末装置においてリアセンブル処理される。
【００９１】
第４の実施形態
次に、本発明の第４の実施形態について説明する。
第４の実施形態は、上記第３の実施形態で、退避先を、第２の実施形態の場合と同様に、IPsec処理におけるパディング内とした実施形態である。
【００９２】
第４の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec暗号化処理の動作フローチャートは、第３の実施形態における図１０の動作フローチャートと同じである。
【００９３】
第４の実施形態が第３の実施形態と異なる部分は、フラグメント情報退避処理（ステップＳ１００１）の部分の処理である。第３の実施形態ではフラグメント情報はESPヘッダのSPI上位16ビットに退避させられたが、第４の実施形態では、フラグメント情報はパディング内（図７（ｂ）の７０１又は図８（ｂ）の８０１参照）に退避させられる。
【００９４】
図１２は、第４の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec復号処理の動作フローチャートである。
まず、例えば図１のWANからネットワーク接続装置１０４を介して到来したパケットが、フラグメントパケットであるか否かが判定される（ステップＳ１２０１）。
【００９５】
到来したパケットがフラグメントパケットであると判定された場合には、これは送信側
にてIPsec処理された後にフラグメント処理されたパケットであるため、リアセンブル処理が実行される（ステップＳ１２０２）。
【００９６】
到来したパケットがフラグメントパケットではないと判定された場合、又は上記リアセンブル処理の後に、IPsec処理（復号）が実行されて、暗号化前の元のパケットが取り出される（ステップＳ１２０３）。
【００９７】
続いて、復号されたパケットのペイロードデータに続くパディング部（図７（ｂ）の７０１又は図８（ｂ）の８０１参照）からフラグメント情報が取り出され、復号されたパケットのIPヘッダのフラグメント情報フィールド（図７（ａ）の２００１又は図８（ａ）の２００２参照）に戻される（ステップＳ１２０４）。
【００９８】
以上のようにして得られた暗号化前のパケットが、ネットワーク接続装置１０４からLANに出力される。このパケットがフラグメントパケットである場合には、後段の端末装置においてリアセンブル処理される。
【００９９】
本発明の第１〜第４の実施形態に対する補足
以上説明した第１及び第３の実施形態では、フラグメント情報の退避先としてESPヘッダ内のSPIフィールドが用いられたが、IPsec処理の他の実現形態であるAHヘッダ（IP Authentication Header）のデータフォーマットでも、図５（ｂ）に示されるように、SPIフィールドを有するため、同様の実現が可能である。
【０１００】
また、上記第１〜第４の実施形態の説明においては、暗号化処理方法としてIPsecを用いた例について説明したが、本発明はIPsecに限定されるものではなく、IPパケットに対してIPヘッダのフラグメント情報を書き換えないで暗号化するような方法であれば、どのような暗号化処理方法であってもよい。
【０１０１】
以上の第１〜第４の実施形態に関して、更に以下の付記を開示する。
（付記１）
インターネットプロトコルに基づいて通信されるIPパケットを、そのIPヘッダを含まない形態で暗号化する暗号化処理方法であって、
前記IPヘッダに含まれる分割情報を該IPヘッダ以外の領域に退避させる第１のステップと、
前記IPヘッダに含まれる分割情報をクリアする第２のステップと、
前記第１及び第２のステップの結果得られるIPパケットに対して暗号化処理を実行し、その結果得られる暗号化パケットを出力する第３のステップと、
を含むことを特徴とする分割されたパケットの暗号化方法。
（付記２）
前記第１のステップは、前記IPヘッダに含まれる分割情報を前記暗号化処理において付加されるべき暗号化ヘッダの一部に退避させる、
ことを特徴とする付記１に記載の分割されたパケットの暗号化方法。
（付記３）
前記第１のステップは、前記IPヘッダに含まれる分割情報を前記暗号化処理において付加されるべきパディング領域の一部に退避させる、
ことを特徴とする付記１に記載の分割されたパケットの暗号化方法。
（付記４）
前記分割情報は、分割されたデータの元データの先頭からの位置を示すオフセット情報と、分割されたデータの後続データが存在するか否かを示す識別情報である、
ことを特徴とする付記１乃至３の何れか１項に記載の分割されたパケットの暗号化方法。
（付記５）
前記第１のステップは、前記IPヘッダにおいて前記分割情報が格納される領域の情報を、前記IPパケットが分割されたパケットであるか否かにかかわらず、前記IPヘッダ以外の領域に退避させる、
ことを特徴とする付記１乃至４の何れか１項に記載の分割されたパケットの暗号化方法。
（付記６）
インターネットプロトコルに基づいて通信されるIPパケットについて、該IPパケットのIPヘッダに含まれる分割情報が該IPヘッダ以外の領域に退避させられ該IPヘッダに含まれる分割情報がクリアされた上で暗号化された暗号化パケットを復号する復号方法であって、
前記暗号化パケットを復号する第４のステップと、
該復号の結果得られるIPパケットにおいて、前記退避させられている分割情報を、該IPパケットのIPヘッダに戻して出力する第５のステップと
を含むことを特徴とする分割暗号化パケットの復号方法。
（付記７）
前記第５のステップは、暗号化処理において付加されている暗号化ヘッダの一部に退避させられている分割情報を、前記復号されたIPパケットのIPヘッダに戻して出力する、
ことを特徴とする付記６に記載の分割暗号化パケットの復号方法。
（付記８）
前記第５のステップは、暗号化処理において付加されているパディング領域一部に退避させられている分割情報を、前記復号されたIPパケットのIPヘッダに戻して出力する、
ことを特徴とする付記６に記載の分割暗号化パケットの復号方法。
（付記９）
前記分割情報は、分割されたデータの元データの先頭からの位置を示すオフセット情報と、分割されたデータの後続データが存在するか否かを示す識別情報である、
ことを特徴とする付記６乃至８の何れか１項に記載の分割されたパケットの暗号化方法。
（付記１０）
前記第５のステップは、復号の結果得られるIPパケットが分割されたパケットであるか否かにかかわらず、該IPパケットにおいて退避させられている分割情報を、該IPパケットのIPヘッダに戻して出力する、
ことを特徴とする付記６乃至９の何れか１項に記載の分割されたパケットの暗号化方法。
（付記１１）
インターネットプロトコルに基づいて通信されるIPパケットを、そのIPヘッダを含まない形態で暗号化するコンピュータに、
前記IPヘッダに含まれる分割情報を該IPヘッダ以外の領域に退避させる第１の機能と、
前記IPヘッダに含まれる分割情報をクリアする第２の機能と、
前記第１及び第２の機能の結果得られるIPパケットに対して暗号化処理を実行し、その結果得られる暗号化パケットを出力する第３の機能と、
を実行させるためのプログラム。
（付記１２）
インターネットプロトコルに基づいて通信されるIPパケットについて、該IPパケットのIPヘッダに含まれる分割情報が該IPヘッダ以外の領域に退避させられ該IPヘッダに含まれる分割情報がクリアされた上で暗号化された暗号化パケットを復号するコンピュータに、
前記暗号化パケットを復号する第４の機能と、
該復号の結果得られるIPパケットにおいて、前記退避させられている分割情報を、該IPパケットのIPヘッダに戻して出力する第５の機能と
を実行させるためのプログラム。
（付記１３）
インターネットプロトコルに基づいて通信されるIPパケットを、そのIPヘッダを含まない形態で暗号化する暗号化装置であって、
前記IPヘッダに含まれる分割情報を該IPヘッダ以外の領域に退避させる退避手段と、
前記IPヘッダに含まれる分割情報をクリアするクリア手段と、
前記退避手段と、前記クリア手段の結果得られるIPパケットに対して暗号化処理を実行し、その結果得られる暗号化パケットを出力する出力手段と、
を有することを特徴とする暗号化装置。
【図面の簡単な説明】
【０１０２】
【図１】本発明の各実施形態を実現できるコンピュータのハードウェア構成の基本構成例を示す図である。
【図２】第１、第２の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec暗号化処理の動作フローチャートである。
【図３】トランスポートモードにてフラグメントパケットをIPsec処理する場合のパケットフォーマット（ESPヘッダの一部を利用する例）（1番目のフラグメントパケット）である。
【図４】トランスポートモードにてフラグメントパケットをIPsec処理する場合のパケットフォーマット（ESPヘッダの一部を利用する例）（2番目のフラグメントパケット）である。
【図５】ESPフォーマットとAHヘッダフォーマットを示す図である。
【図６】第１の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec復号処理の動作フローチャートである。
【図７】トランスポートモードにてフラグメントパケットをIPsec処理する場合のパケットフォーマット（パディング部分を利用する例）（1番目のフラグメントパケット）である。
【図８】トランスポートモードにてフラグメントパケットをIPsec処理する場合のパケットフォーマット（パディング部分を利用する例）（2番目のフラグメントパケット）である。
【図９】第２の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec復号処理の動作フローチャートである。
【図１０】第３、第４の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec暗号化処理の動作フローチャートである。
【図１１】第３の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec復号処理の動作フローチャートである。
【図１２】第４の実施形態において、図１のコンピュータ（ルータ装置又はＢＩＴＷ装置又は端末装置）によって実行されるIPsec復号処理の動作フローチャートである。
【図１３】パケットが保護される区間の説明図である。
【図１４】分割前のIPパケットの例を示す図である。
【図１５】IPパケットの分割例を示す図である。
【図１６】分割されたパケットに含まれる分割情報を示す図である。
【図１７】従来のIPsec暗号化処理の動作フローチャートである。
【図１８】従来のIPsec復号処理の動作フローチャートである。
【図１９】従来のフラグメント方法（暗号化前のオリジナルパケットのフォーマット）の説明図である。
【図２０】従来のフラグメント方法（オリジナルパケットのフラグメント処理）の説明図である。
【図２１】従来のフラグメント方法（フラグメントパケットのIPsec処理（本来は禁止））の説明図である。
【図２２】従来のフラグメント方法（オリジナルパケットのIPsec処理）の説明図である。
【図２３】従来のフラグメント方法（IPsecパケットのフラグメント処理）の説明図である。
【符号の説明】
【０１０３】
１０１  ＣＰＵ（中央演算処理装置）
１０２  メモリ
１０３  外部記憶装置
１０４  ネットワーク接続装置
１０５  バス
【図１】
2009246801.tif 000003
【図２】
2009246801.tif 000004
【図３】
2009246801.tif 000005
【図４】
2009246801.tif 000006
【図５】
2009246801.tif 000007
【図６】
2009246801.tif 000008
【図７】
2009246801.tif 000009
【図８】
2009246801.tif 000010
【図９】
2009246801.tif 000011
【図１０】
2009246801.tif 000012
【図１１】
2009246801.tif 000013
【図１２】
2009246801.tif 000014
【図１３】
2009246801.tif 000015
【図１４】
2009246801.tif 000016
【図１５】
2009246801.tif 000017
【図１６】
2009246801.tif 000018
【図１７】
2009246801.tif 000019
【図１８】
2009246801.tif 000020
【図１９】
2009246801.tif 000021
【図２０】
2009246801.tif 000022
【図２１】
2009246801.tif 000023
【図２２】
2009246801.tif 000024
【図２３】
2009246801.tif 000025