JP2006311164A - パケット転送装置 - Google Patents

Abstract

【課題】すべて、もしくは暗号化以外の処理をソフトウェアで行うIPsec処理装置において、IPsecトンネルモード時のカプセル化IPヘッダのルーティングテーブル検索およびSPD検索が性能面でボトルネックとなる。
【解決手段】IPsecトンネルデバイスドライバ内のIPsecトンネル情報内にルーティングテーブル検索結果およびSPD検索結果をキャッシュし、2回目以降そのキャッシュを元にIPsec処理を行うことで、データベース検索をスキップする。
【選択図】図３

Description

本発明は、IPsecトンネル処理を行う装置に関する。

IPsecはIPパケットを暗号化して安全に転送するための仕組みであり、IETFによって規定されている。IPsecには、IPパケットのペイロード部分のみを直接暗号化してIPヘッダを付与して転送するトランスポートモードと、IPパケット全体を暗号化し、カプセル化ヘッダを付与して転送するトンネルモードがある。一般にはトンネルモードが広く使われている。IPsecを使用するに際しては、まず、送信元と受信先との間で暗号の種類と暗号鍵を取り決める。これをSA(Security Association)といい、手動で行うことも可能であるが、IKE(Internet Key Exchange)というプロトコルを用いて自動化することも可能である。次いで、送信元および受信先で、IPパケットのプロトコルや、宛先および/または送信元のアドレスおよび/またはポートに応じてIPsec処理を行うか行わないかのポリシを決定する。これをSP(Security Policy)といい、これらを集めたデータベースをSPD(SP Database)と呼ぶ。

ところで、IPsecトンネルやその他のトンネルを扱うために、多くのOSではトンネルデバイスという仕組みを提供している。これは、イーサネット（登録商標）やATMといった物理デバイスと同様にトンネルを扱うための仕組みであり、送信元や受信先の物理IPアドレスなどがトンネル内に隠蔽されている。TCP/IPスタックやOS上のアプリケーションからは物理デバイスと同様に見えるが、一点違うのは物理IPアドレスではなく、トンネルとしてのIPアドレスが別個に付与されているということである。トンネルデバイスは通常Point-to-Pointデバイスとして上位プログラムには認識され、トンネルが複数必要なときはデバイスが複数生成される。

IPsec処理において、もっとも高負荷の処理は暗号化処理であり、ほとんどのIPsec装置でハードウェアアシストされている。次いで高負荷の処理は、ルーティング処理およびSP検索処理である。IPsec一般では、パケットごとに毎回これらの処理を行う必要があるが、データベース検索処理であるので他の処理に比べて負荷が大きく、性能上のボトルネックとなる。これも高価なIPsec装置ではハードウェアアシストされているので問題とはならないが、安価な機器ではここまでハードウェアアシストすることができず、高速化の妨げとなる。

IPsecをトンネルモードでトンネルデバイスを用いて運用している場合、カプセル化IPヘッダの内容とSPは常に一定であるので、毎回ルーティング処理およびSP検索をする必要はない。そこで、トンネルデバイス内のトンネル情報にルーティング情報およびセキュリティポリシ情報のキャッシュ領域を設定する。初回にパケットがトンネルデバイスを通過する際に該情報をキャッシングする。二回目以降にパケットがトンネルデバイスを通過する際にはキャッシングされた情報を読み出すことによってテーブル検索処理を省略し、処理を高速化する。

本発明によれば、IPsec装置のソフトウェアの改良だけで、高価なIPsecアクセラレータハードウェア無しにIPsec処理を高速化することが可能となる。

図2は、本発明が適用されるネットワークの模式図である。1は本発明が適用される安価なIPsec装置であり、一方では端末6と接続しており、もう一方ではIP網2と接続している。3はSAによって確立されたIPsecトンネル5を介して1と接続しているIPsec装置であり、一方では端末7と接続しており、一方ではIP網2と接続している。4はIP網2内のルータであり、レイヤ3レベルでIPsec装置1と直接接続しているNextHopルータである。

図3はIPsec装置1の内部構造例である。101はメモリであり、転送処理を行うためのプログラムやデータが格納されている。102はCPUであり、転送処理の大部分を実行する。103はIPsecアクセラレータであり、高価なものでは暗号化以外にSPD検索、ルーティング処理、IKE処理なども行うことが可能であるが、安価なものでは暗号化のみを行う。本実施例では暗号化のみを行う安価なものを例として用いる。NIF104a,104bは実際にネットワークと物理的に接続する箇所である。ここまで述べた各ハードウェアはバス105によって接続されている。105はバスでなくスイッチでもよい。

メモリ101内には、TCP/IPの転送処理を行うTCP/IPスタック1011、NIF104a、104bを1011他のソフトから利用できるようにするためのNIFデバイスドライバ1012、そして、IPsecトンネルをNIFと同様に利用できるようにするためのIPsecトンネルデバイスドライバ1013が最低存在する。TCP/IPスタック1011は、ルーティング情報を格納したデータベースであるルーティングテーブル10111、SP情報を格納したデータベースであるSPD10112、IPsecヘッダを生成するIPsec生成部10113が少なくとも存在する。IPsecトンネルデバイスドライバ1013の内部には、トンネル情報10131が存在する。

図1は、本発明のトンネル情報である。上部t1が従来よりトンネル情報に格納されていた情報であり、インターフェイスID、自物理ＩＰアドレスおよび対向物理IPアドレス、自トンネルＩＰアドレスおよび対向トンネルIPアドレスなどが存在する。下部t2は、本発明で付加されたキャッシュ情報領域であり、ネクストホップIPアドレス、物理インターフェイス、上り、下りのセキュリティポリシなどを格納する領域が存在する。

図8は、ルーティングテーブル10111の例である。1行目のエントリはIP網2向けのパケットのルーティングエントリであり、物理インターフェイスデバイスwan1からネクストホップとしてルータ4に向けてIPパケットを送信することを意味している。2行目のエントリもIP網2向けのパケットのルーティングエントリであるが、物理的に直接接続しているサブネットなのでネクストホップは存在せず、ARPを用いて送信先を決定する。3行目はIPsec装置1向けのルーティングエントリであり、出力先は無く、IPパケットは1内部で処理される。4行目は端末6の属するLAN向けルーティングエントリであり、出力先物理インターフェイスデバイスはlan0である。物理的に直接接続しているサブネットなのでネクストホップは存在せず、ARPを用いて送信先を決定する。最終行はデフォルトルートであり、どれにも属さない宛先を持つパケットはすべてIPsecトンネルデバイスdti1に向けて送信することを意味する。dti1はPoint-to-Pointデバイスであるのでネクストホップは無い。

図9はSPD 10112の例である。ポリシ番号#1は、上り、すなわちlan0で受信するパケットの扱いを決めたSPの例であり、端末6から送信されたパケットはapply(IPsecカプセル化する)として扱うというポリシの例である。ポリシ番号#2は下り、すなわちlan0から送信するパケットの扱いを決めたSPの例であり、端末6を宛先とするパケットはapply(IPsecデカプセル化する)として扱うというポリシの例である。最終行のポリシ番号#nは、上位のどのポリシにも当てはまらなかったパケットはdiscard(廃棄する)として扱うというポリシの例である。

図10〜図12は本発明で扱うパケットの模式図である。TTLなど本発明の説明に直接関係しない箇所は省略している。
図10は端末6から端末7へと送信されるパケットの模式図である。UDPパケットであり、IPヘッダp1、UDPヘッダp2、ペイロードp3からなっている。

図11はIPsec装置1において図10のパケットが変換されたものであり、カプセル化ヘッダp4を付与されている。

図12はIPsec装置1において図11のパケットが暗号化されたものであり、p1〜p3がESPヘッダp5とESPペイロードp6に変換されている。
図4および図5は本発明を適用していないIPsec処理のフローチャート例である。これに対し、図6および図7は本発明を適用したIPsec処理のフローチャート例である。いずれにおいても、SA処理など本発明の説明に直接関係しない処理に関しては省略している。

図4は本発明を適用していない上りIPsec処理、すなわち端末6が属するネットワークから発されたIPパケットをIPsecカプセル化する処理である。端末6からのパケットを受け取ったIPsec装置1は、ルーティングテーブル10111を検索し、出力先のインターフェイスと、もしあればネクストホップIPアドレスを得る(S1)。ついで、得た出力インターフェイスがIPsecトンネルデバイスであるかを判定し(S2)、IPsecトンネルデバイスでなければ通常のパケット出力処理に分岐し(S3)、IPsecトンネルデバイスであれば、トンネル情報10131からカプセル化IPヘッダを生成し付与する(S4)。ついで、SPD 10112を検索し、生成パケットのSPを得る(S5)。得たSPからパケットがapplyであるかを判定し(S6)、applyでなければ廃棄・出力などの適切な処理へ移行し(S7)、applyであれば暗号化処理を行い、元パケット部分を暗号化ヘッダと暗号化ペイロードに変換する(S8)。そして暗号化されたカプセル化パケットに対して再びルーティングテーブル10111を検索して出力先のインターフェイスと、あればネクストホップIPアドレスを得(S9)、その結果を元にパケット出力処理を行う(S10)。

以上の一連の処理を具体的なパケットとデータベースを以って説明すると、以下のようになる。図10で示される端末6から発されたIPパケットを図8で示したルーティングテーブル10111で検索すると、最終行にマッチし、出力インターフェイスとしてdti1を得る(S1)。これはIPsecトンネルデバイスであるので、判定の結果S4の処理に移行する。S4の処理においてパケットは図11に示した形に変換される。変換されたパケットを図9で示したSPD 10112で検索すると1行目にマッチし、applyの結果を得る(S5)。applyであるので、S8の処理に移行する。S8の処理において、パケットは図12で示した形に変換される。そして再び図8で示したルーティングテーブル10111を検索すると、こんどは1行目にマッチするので、出力インターフェイスwan1とネクストホップIPアドレス1.0.0.1を得る。その結果を持ってS10の出力処理に移行し、ここにおいてパケットはIP網2に向けて発信される。

これに対して、本発明を適用した上りIPsec処理を示したのが図6である。S1〜S4までの処理は図4の場合と同様であるが、その直後にトンネル情報をチェックし、キャッシュが存在するかどうかを判定する処理が入る(S11)。もしキャッシュが存在しなければ、S5〜S9は図4と同様に処理を行い、その後にSPDおよびS9のルーティングテーブル検索結果をトンネル情報にキャッシュする処理を行う(S16)。しかる後に、S10の処理を行う。キャッシュが存在した場合は、キャッシュを用いてSPをチェックし(S12)、もしチェックに失敗したらパケットを廃棄する(S13)。チェックに成功したならば暗号化処理を行い元パケットを暗号化ヘッダと暗号化ペイロードに変換する(S14)。その後、キャッシュから出力インターフェイスとネクストホップIPアドレスを得(S15)、その結果を持ってパケット出力処理を行う(S10)。

本発明を適用した場合、最初のパケットは図4とほぼ同等の処理で転送されるが、2個目以降のパケットは、S5のSPD検索とS9のルーティングテーブル検索をスキップできる。比較的負荷の高い処理であるデータベース検索を2回スキップすることにより、高速化が期待できる。

図5は本発明を適用していない下りIPsec処理、すなわちIPsecパケットを受信し、端末6が属するネットワークにパケットを転送する処理のフローチャート例である。パケットを受け取ったIPsec装置1はルーティングテーブル10111を検索する(S50)。IPsecトンネルの端点はIPsec装置1自身であるので、1宛てのIPsecパケットであるかどうかを判定し（S51）、1宛てのIPsecパケットでなければ通常のパケット転送処理に移行し(S52)、1宛てのIPsecパケットであれば復号化処理を行い、暗号化ヘッダと暗号化ペイロードから元パケット部分を復元する(S53)。ついで、復元されたパケットでSPD 10112を検索し、パケットのSPを得る(S54)。得たSPからパケットがapplyであるかを判定し(S55)、applyでなければ廃棄などの適切な処理へ移行し(S56)、applyであればカプセル化IPヘッダを除去する(S57)。カプセル化IPヘッダを除去して完全に復元されたIPパケットに対して、ルーティングテーブル10111を再び検索し、lan0へのルーティング処理を行う(S58)。

これに対して、図7は本発明を適用した下りIPsec処理を示したものである。はじめに、自宛パケットかどうかルーティングテーブルを用いずにディスティネーションアドレスと次ヘッダからはじめに確認する(S59)。その結果から、自宛のIPsecパケットであるかどうかを判定し(S51)、自宛のIPsecパケットでなければ改めてルーティングテーブル検索も含めた通常のパケット転送処理へ移行し(S60)、自宛のIPsecパケットであれば復号化処理を行い、暗号化ヘッダと暗号化ペイロードから元パケット部分を復元する（S53）。その後にトンネル情報にキャッシュが存在するかの判定を行い(S61)、キャッシュが存在しなければS54からS56を図5と同様に行い、SPD検索結果をトンネル情報にキャッシュし(S64)、S57、S58の処理を図5と同様に行う。キャッシュが存在すれば、キャッシュを用いてSPチェックを行い(S62)、失敗すればパケットを廃棄し(S63)、成功すればS57、S58の処理を図5と同様に行う。

本発明を適用した場合、最初のパケットは図5でのS50のルーティングテーブル検索をスキップでき、2個目以降のパケットは、S50のルーティングテーブル検索とS54のSPD検索をスキップできる。比較的負荷の高い処理であるデータベース検索を1回ないし2回スキップすることにより、高速化が期待できる。

本発明を適用したトンネル情報の例。 本発明を適用するネットワークの例。 本発明を適用するIPsec装置の模式図。 本発明を適用していない上りIPsec処理のフローチャート例。 本発明を適用していない下りIPsec処理のフローチャート例。 本発明を適用した上りIPsec処理のフローチャート例。 本発明を適用した下りIPsec処理のフローチャート例。 ルーティングテーブルの例。 SPDの例。 元パケットの例。 カプセル化IPヘッダを付与したパケットの例。 暗号化済みパケットの例。

符号の説明

1…本発明を適用するIPsec装置、2…IP網、3…1の対向IPsec装置、4…1のネクストホップルータ、5…IPsecトンネル、6,7…端末、101…メモリ、102…CPU、103…IPsecアクセラレータ(暗号化エンジン)、104a,b…NIF、105…バスもしくはスイッチ、1011…TCP/IPスタック、1012…NIFデバイスドライバ、1013…IPsecトンネルデバイスドライバ、10111…ルーティングテーブル、10112…SPD、10113…IPsecヘッダ生成部、10131…トンネル情報、t1…トンネル情報の一般的な項目、t2…本発明によるキャッシュ情報、p1…元パケットIPヘッダ、p2…元パケットUDPヘッダ、p3…元パケットUDPペイロード、p4…カプセル化IPヘッダ、p5…暗号化ヘッダ、p6…暗号化ペイロード。

Claims (5)

1. パケットを送受信するインターフェースと、メモリと、ＣＰＵを有するパケット転送装置であって、
   上記メモリには、パケット転送先を決定するルーティングテーブルと、セキュリティポリシ情報が格納されており、
   上記ＣＰＵは、
   上記インターフェースから入力されたパケットの転送先を上記ルーティングテーブルを用いて検索し、該パケットのセキュリティポリシを上記セキュリティポリシ情報を用いて検索し、
   上記パケットに対して上記セキュリティポリシ情報の検索結果に従ったセキュリティ処理を施して、該セキュリティ処理を施されたパケットを上記ルーティングテーブルの検索結果として得られた送信先に送信し、
   さらに上記ルーティングテーブルの検索結果および上記セキュリティポリシ情報の検索結果を上記メモリ内にトンネル情報として記憶することを特徴とするパケット転送装置。
2. 請求項１記載のパケット転送装置であって、
   上記ＣＰＵは、
   上記インターフェースから受信した他のパケットの送信先ＩＰアドレス、送信元ＩＰアドレス、送信先トンネルＩＰアドレス、送信元トンネルＩＰアドレス、および上記インターフェースのＩＤのうちすくなくともいずれか一つを含む所定の情報が先に受信した上記パケットの情報と一致するか否かを判定し、
   上記判定の結果、一致する場合には、先に受信した上記パケットの上記トンネル情報を用いて、上記他のパケットの送信先と該他のパケットに適用すべきセキュリティポリシを決定することを特徴とするパケット転送装置。
3. 請求項１記載のパケット転送装置であって、
   上記セキュリティポリシは、ＩＰｓｅｃに関するセキュリティポリシであることを特徴とするパケット転送装置。
4. 請求項１記載のパケット転送装置であって、
   上記セキュリティポリシは、パケットの暗号化が必要か否かの情報を含むことを特徴とするパケット転送装置。
5. 請求項１記載のパケット転送装置であって、
   上記セキュリティポリシは、パケットのカプセル化に用いるプロトコルの情報を含むことを特徴とするパケット転送装置。

Images