Comments
Description
Transcript
データ駆動型ファイアウォールにおける TCP パケット処理
平成 16 年度 学士学位論文 データ駆動型ファイアウォールにおける TCP パケット処理の並列実現法 Parallel Implementation of TCP Processing on Data-Driven Firewall Processor 1050326 嶋田 栄悟 指導教員 岩田 誠 教授 2005 年 3 月 11 日 高知工科大学 情報システム工学科 要 旨 データ駆動型ファイアウォールにおける TCP パケット処理の 並列実現法 嶋田 栄悟 インターネットが普及したことにより、不正アクセスや悪意のある侵入、ネットワーク ウィルスなどの検出方法として、ネットワークセキュリティが非常に重要視されている。様々 なネットワークセキュリティの中で、ファイアウォールが一般的に利用されている。 誰にでも知られているように、ネットワークでは最大転送単位（MTU）が設定されてお り、そのサイズを超えるパケットは複数パケットに分割されてネットワーク上に送信される。 そのためファイアウォールなどのネットワークセキュリティでは、分割されたことによっ て、シグナチャマッチングなどの機能で、不正パケットが検出できないというミスをなくす ために、分割されたパケットを再構築する必要がある。 本稿では，TCP リアセンブル処理への応用実装を視野に入れて、データ駆動処理方式を 用いて IP パケットの再構成処理である IP デフラグメント処理の並列実現法の検討と実装 ならびに性能評価を行った。 性能評価の結果、259 IPPacket/sec の性能が確認できた。また再構築時のデータ格納処 理の処理速度のボトルネックが課題であるということを確認した。 キーワード データ駆動型プロセッサ、データ駆動型ファイアウォール、パターンマッチン グ、IP デフラグメント、TCP リアセンブル、MTU –i– Abstract Parallel Implementation of TCP Processing on Data-Driven Firewall Processor Eigo Shimada With the prevalence of Internet, the network security is becoming an important aspect which should be considered in order to keep the network off numerous unauthorized access, malicious intrusion, network virus and so on. Among the exiting security products, firewall system is popular. My work is based on the TCP processing module of an embedded data-driven firewall processor. As we all know, because of the length limitation of IP packet and the maximum transition unit (MTU) of link layer, longer TCP/IP packets will be fragmented when they pass through the network. As far as the TCP processing module of a firewall system is concerned, a IP defragment and TCP reassemble processing of the fragmented packets is required before they pass through other packet content analysis modules such as signature matching so that no malicious signature which spans two fragments would be ignored. As for the increasing bandwidth of network, a high processing speed is also important. In my previous work, a parallel implementation of IP defragment module and its evaluation on the data-driven network processor (DDNP) board are accomplished. The evaluation result shows that the performance gets to 259 IPPacket/sec. key words Date Driven Processor, Date Driven Firewall Processor, Pattern Match- ing、IPdefragment, TCPreassemble, MTU – ii – 目次 第1章 序論 1 第2章 ファイアウォール 4 2.1 緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 ファイアウォールの基本機能 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 ファイアウォールの実装形態 . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 データ駆動型ファイアウォール . . . . . . . . . . . . . . . . . . . . . . . 6 2.5 結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 TCP/IP 7 3.1 緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 第3章 3.3 3.4 第4章 3.2.1 IP 基本機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2 IP パケットの再構築処理 . . . . . . . . . . . . . . . . . . . . . . . 9 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1 TCP の基本機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.2 TCP ストリーム分割 . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.3 TCP の詳細機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 データ駆動による TCP パケット処理の実現 16 4.1 緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 IP デフラグメントプログラム . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3 データ駆動による利点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 – iii – 目次 4.4 問題点と解決法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5 結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 性能評価 26 5.1 緒言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.2 評価結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3 結言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 結論 28 第5章 第6章 謝辞 29 参考文献 30 – iv – 図目次 1.1 データ・フローグラフ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.1 IP ヘッダ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 スリーウェイハンドシェイク (コネクションの確立) . . . . . . . . . . . . . 11 3.3 コネクションの切断 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4 TCP ヘッダ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1 IP デフラグメントのモジュール構成 . . . . . . . . . . . . . . . . . . . . . 17 4.2 再構築判定モジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3 バッファ割当モジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4 データ格納モジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5 バッファ更新チェックモジュール . . . . . . . . . . . . . . . . . . . . . . . 21 4.6 パケット出力モジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 –v– 表目次 3.1 MTU 比較表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 IP パケット再構築処理性能 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 – vi – 第1章 序論 近年、無線機器の発達やポータブル端末等のモバイルメディアの発達を筆頭に、ネット ワーク環境がより身近な存在になってきた。その中で、ネットワーク上に存在する脅威や ネットワークを利用しての脅威の存在が増大してきた。不正アクセスやウイルス、不正ア タック等がそれに該当する。これらを防ぐための一つの手段として、ファイアウォールが非 常に注目されている。このファイアウォールを利用して、内部ネットワークや外部ネット ワークから端末を保護することが可能である。 一般にネットワーク通信路では、MTU という一度に送信できる最大データ転送サイズを 定めて、データ転送を行っている。そこで、ネットワーク通信路が定める MTU 以上のデー タを送信したい場合は、パケットを分割して送信する必要がある。そして、受信側では分割 されたパケットを、送信される前のパケットに再構築する処理を行う必要がある。分割され たパケットが送信されてきた場合に、ファイアウォール機能の一部である、パターンマッチ ングによるフィルタリング処理が適切に行われない可能性がある。これは、あらかじめデー タ・ベース化しておいたウイルス等の不正コードとのパターンと、受信したパケットのマッ チング処理を行う際に、分割されているデータに対してのマッチング処理しか行えない事が 原因である。そこで、分割されたデータの再構築処理を行い、送信される前のデータ全てに 対してマッチング処理を行い適切にフィルタリング処理を行う必要がある。パケットの再構 築処理には、IP パケットの再構築を行う処理と TCP パケットの再構築を行う処理がある。 受信側では、送信されてきた IP パケットの再構築処理を始めに行い、次に TCP による通 信の場合は TCP の再構築処理を行う。 そこで、本研究ではデータ駆動型マルチプロセッサ（DDMP）を用いて実現される、デー –1– タ駆動型ファイアウォールの研究の一環として、IP パケットの再構築処理に着目して IP デ フラグメントプログラムの作成と評価を行う。IP デフラグメント処理は、データ駆動処理 方式の特徴を活かすように並列化して実現する。 次に、データ駆動型プロセッサについての説明を行う。データ駆動型の特徴としては、低 消費電力で並列的に処理を行なうことができることである。従来のノイマン型プロセッサの ように、クロック信号を用いるのではなく、処理するべきデータがそろったときにのみ命令 が実行され、そのときのみに電力が発生する仕組みを持つ。よって、低消費電力が実現され る。また、従来のノイマン型プロセッサと違い、命令を並列に実行することが可能である。 そのために、高速な処理が実現でき処理時間が非常に早い特徴を持つ。具体的には、パケッ トに世代といわれるカラー情報を持たせることによって実現される. 同じ世代情報を持つパ ケットが揃ったときのみに、そのデータ同士で命令が実行される。その時、命令は非同期に 実行される。 また、データ・フローグラフによりプログラムを記述することが可能なので、非常にフレ キシブルにプログラムを作成することが可能である。図 1.1 にデータ・フローグラフを示す。 図 1.1 データ・フローグラフ –2– 第二章では、 現在のファイアウォールが搭載している基本機能について簡単に説明する。 そして、ファイアウォールの実装形態を述べた後、データ駆動型ファイアウォールの特徴と 必要性を示す。 第三章では、本研究を行なうにあたって TCP と IP のプロトコルについての、基本的な 機能と役割についての説明を行う。 第四章では、データ駆動処理方式を用いた IP デフラグメントプログラムのモジュール構 成と、その役割について説明する。その後、問題点と解決法を示す。 第五章では、性能評価として IP デフラグメントプログラムが正常に動作することを示し、 性能指標としてスループットと応答時間を算出する。また、プログラム規模を示す。 第六章では、結論として IP デフラグメント処理がデータ駆動処理方式を利用して実現で きたことを示す。また、データ格納時のさらなる並列化が必要であることを示す。 –3– 第2章 ファイアウォール 2.1 緒言 本章では、基本的なファイアウォールの機能や構築形態について説明する。そして、デー タ駆動型ファイアウォールがどのような位置付けにあるかを説明する。 2.2 ファイアウォールの基本機能 ファイアウォールは、内部ネットワークと外部ネットワークの通過点に設置され、不正な パケットのアクセスを制限するためのものであり、送受信されるパケット全てに対して通 過・破棄のアクセス制限を決定する役割を行なう。セキュリティに関しては、利便性と安全 性を考慮してセキュリティポリシーを定める必要がある。一般的にセキュリティを強化させ ると使用できるサービスが制限されるので、利便性が悪くなる。そのため、構築するネット ワーク環境に応じたセキュリティポリシーを設定する必要がある。 ファイアウォールは、ネットワーク上のセキュリティに関して非常に重要な役割を行なう 一つであるが、設定をしっかりと行わないと逆にセキュリティを危険に及ぼす可能性もあ る。基本的なファイアウォールの機能を以下に示す。 • パケットフィルタリング • アプリケーションレベルゲートウェイ • サーキットレベルゲートウェイ パケットフィルタリングは、送信されたパケットのヘッダ部分のパラメータを参照しアク –4– 2.3 ファイアウォールの実装形態 セス制限を決定する方法のことである。パケットに含まれるデータ部分に関しては一切の確 認を行わないので、非常に高速に処理することが可能である。 アプリケーションゲートウェイは、アプリケーション層でデータを中継させることによっ てセキュリティを確保する方法である。内部ネットワークと外部ネットワークとの中継点で ネットワークとの接続を代理に行なう、プロキシプログラムを使用する。各プロトコルごと にプログラムを用意する必要があるが、アプリケーションごとにフィルタリングが可能であ る。デメリットとして、プログラムが複雑になり処理速度が遅くなる。 サーキットレベルゲートウェイは、トランスポート層のレベルでデータを中継させアクセ ス制御を行なう方法のことである。通常のトランスポート層のコネクション要求を、ゲート ウェイサービスが改めて行なう事によって、ゲートウェイサービスがコネクション要求を行 なったように見える。セッション情報を見て、どの TCP と通信しているかを把握してアク セス制御を行なう。 2.3 ファイアウォールの実装形態 ファイアウォールは、ネットワーク規模や運用形態によって、主に以下に示すような実装 形態が存在する。 • ネットワーク型 • ホスト型 • Embedded 型 特徴としてネットワーク型は、独立した端末上で動作し内部ネットワークと外部ネット ワークのゲートウェイとして実装される。内部と外部ネットワークを通過する全パケットに 対しての攻撃を防ぐことが可能である。しかし、内部ネットワーク同士で通信されるパケッ トを見ることはないので、内部ネットワークで起こる攻撃は防ぐことができない。 ホスト型は、各端末の OS 上で動作し各端末を保護することが可能である。外部ネット ワークからの攻撃はもちろん防ぐことが可能であり、内部ネットワークからの攻撃も防ぐこ –5– 2.4 データ駆動型ファイアウォール とが可能である。 Embedded 型は、各端末の NIC 上に実装されホスト型と同様各端末ごとのセキュリティ を確保することが可能なので、外部・内部ネットワークからの攻撃を防ぐことが可能である。 2.4 データ駆動型ファイアウォール 将来的に、あらゆるモバイル端末がネットワークを形成するようになると、問題となって くるのは、消費電力の増大と処理速度の問題である。モバイル端末では、処理速度に伴なう 消費電力の増大に耐えられず、今まで以上の処理速度の向上に期待できない。そこで、低消 費電力かつ並列性に優れた処理方式であるデータ駆動処理方式を用いた、データ駆動型ファ イアウォールの実現を目指したい。データ駆動型ファイアウォールでは、低消費電力かつ並 列性に優れ、高速な処理速度を実現することができる。そのため、将来的にはモバイル端末 への搭載が可能である。 2.5 結言 本章では、現状の基本的なファイアウォールの基本機能とファイアウォールの構築形態に ついて述べた後、データ駆動型ファイアウォールの特徴を述べた。 –6– 第3章 TCP/IP 3.1 緒言 本章では、ネットワークの標準プロトコルとなっている IP プロトコルと TCP プロトコ ルの役割、および基本機能について述べる。TCP については詳細な機能についても簡単に 述べる。 3.2 3.2.1 IP IP 基本機能 IP（Internet Protocol）はネットワーク上のパケットを目的の場所まで運ぶ重要なプロト コルである。IP の特徴を以下に示す。 • IP アドレス IP アドレスは (IPv4)、32 ビットの整数値で表される。アドレスは、ネットワーク部と ホスト部に分けられ、TCP/IP ネットワーク上に接続されているコンピュータを識別す るために使用される。 • 経路制御（ルーティング） 経路制御 (ルーティング) は、IP の中で最も重要な役割を果たす。宛先の IP アドレス までパケットを届けるための制御を行なう機能である。ルーティングテーブルに指定さ れているネットワーク・アドレスとネットワーク・インターフェースが存在すれば送信 する。存在しない場合は、指定されているデフォルト・ゲートウェイへ送信される。 –7– 3.2 IP • IP パケットの分割処理と再構築処理 IP では、MTU(Maximum Transmission Unit) という最大データ転送サイズを基準に データ転送を行なっている。もし、送信先のホストや中継するルーターの MTU の値 を超える IP パケットを送信したい場合は、IP パケットを分割して送信する必要があ る。分割された IP パケットの再構築処理は、データの受信先で行なわれる。分割され た IP パケットは送信の途中で到着順序が入れ替わったり、途中で消失する可能性があ るので、それを考慮した再構築を行なう必要がある。表 3.1 に各データリンクにおける MTU を参考として示す。 表 3.1 MTU 比較表 データリンク MTU（オクテット） Hyperchannel 65535 IP over HIPPI 65280 IP over ATM 9180 IEEE 802.4 Token Bus 8166 IEEE 802.5 Token Ring 4464 FDDI 4352 Ethernet 1500 PPP 1500 IEEE 802.3 Ethernet 1492 IP の最小 MTU 68 –8– 3.2 IP • コネクションレス型 コネクションレス型とは、通信先との接続の確認をせずに一方的にパケットを送信する 方法である。通信先にデータが問題なく送信されたかどうかの確認を行なわないので、 正確さに欠けるが高速な通信を実現することが可能である。 3.2.2 IP パケットの再構築処理 分割された IP パケットが送信されてきた場合は、受信する際に分割された IP パケット を再構築する必要がある。分割されたパケットであるかを知るためには、図 3.1 に示す IP ヘッダに含まれる以下のパラメータを使って判断する。 • 識別子 • フラグ • フラグメントオフセット 識別子は、送信元で分割される前にランダムに決定される値である。この値が同一の分割 された IP パケットは、送信される前は同一の IP パケットであったと判断することが可能で ある。 フラグは 3 ビットで表され、１ビット目は未使用。２ビット目は、分割を許可する場合は ０で、分割を許可しない場合に１がセットされる。３ビット目には、この IP パケットが分 割されたパケットの最後であるかそうでないかを示す。最後のパケットである場合は０を、 そうでない場合は１をセットする。 フラグメントオフセットは、送信元で IP パケットを分割した際に割り当てられる値であ る。この値は、分割されたパケットを再構築する際に、送信前のデータのどの部分であるか を示している。 –9– 3.3 TCP バージョン (4bit) データ長 (4bit) サービスタイプ 識別子 (16bit) フラグ (16bit) 生存時間 (TTL) 全データ長 (8bit) (3bit) プロトコル (8bit) (8bit) フラグメントオフセット (13bit) ヘッダチェックサム (16bit) 送信元 IP アドレス (32bit) 宛先 IP アドレス (32bit) オプション パディング 図 3.1 IP ヘッダ 3.3 TCP TCP はトランスポート層のプロトコルであり、コネクション型で全二重によるデータ通 信を行い、信頼性を保障するプロトコルである。 3.3.1 TCP の基本機能 TCP には、様々な信頼性を保障するための機能や、ネットワークの利用効率を向上させ るための機能を備えている。以下に TCP の信頼性を保障するための基本的な機能を示す。 • コネクション管理 • ストリーム型の通信 TCP では、コネクションの確立を行い送信側と受信側の論理的な通信路の確保を行なう。 コネクションの確立を開始する際の手順を、スリーウェイハンドシェイクという。また、通 – 10 – 3.3 TCP 信が終了すると、コネクションの切断を行なう。以下にコネクションの確立の処理手順を示 す。また、図 3.2 にコネクションを確立している様子を示す。 図 3.2 スリーウェイハンドシェイク (コネクションの確立) 1. 送信元ホストから接続先のホストに対して、コネクションの接続を行なうための SYN セグメントを送信する。 2. 接続先のホストが SYN セグメントを受信すると、確認応答としての ACK セグメント と、コネクションの接続要求を示す SYN セグメントを、同時に送信元ホストへ送信 する。 3. 送信元ホストでは、確認応答として ACK セグメントを接続先のホストに送信する。 – 11 – 3.3 TCP 次に、図 3.3 にコネクションの切断の様子を示す。また、図 3.3 にコネクションを確立し ている様子を示す。 図 3.3 コネクションの切断 1. 送信元ホストから接続先ホストに対して、コネクションの切断を行なうための FIN セ グメントを送信する。 2. 接続先のホストが送信元ホストから FIN セグメントを受信すると、確認応答として ACK セグメントを送信元ホストへ送信する。 3. 接続先のホストは、送信元ホストに対して、コネクションの切断を行なうための FIN セグメントを送信する。 4. 送信元ホストが FIN セグメントを受信すると、確認応答として ACK セグメントを接 – 12 – 3.3 TCP 続先のホストに送信する。 ストリーム型の通信では、送信元でランダムに決定した図 3.4 に示す TCP ヘッダの シーケンス番号を元に、データの送信を行なう。そして、受信先は TCP ヘッダの確認応答 （ACK）を送信元へ返すと共に、次の送信データを指定する値を確認応答番号として返すこ とによって信頼性のある通信を実現する。 送信元ポート番号 宛先ポート番号 (16bit) (16bit) シーケンス番号 (32bit) 確認応答番号 (32bit) データオフセット (4bit) 予約 (6bit) コードビット (6bit) ウィンドウサイズ (16bit) チェックサム 緊急ポインタ オプション パディング (16bit) (16bit) 図 3.4 TCP ヘッダ 3.3.2 TCP ストリーム分割 ネットワーク通信路であるデータリンク層の違いによって、伝送速度は違ってくる。そ のために一度に送信するデータの大きさを小さくしなければ、通信効率が悪くなってしま う。TCP では、MSS(Maximum Segment Size) の値を基準に TCP パケットを送受信して いる。MSS は、その通信路の最大セグメント長を表しており、MSS の値を超過している TCP パケットは、パケットの分割を行い送信する。また、受信時には分割されたパケット – 13 – 3.3 TCP の再構築を行う必要がある。 3.3.3 TCP の詳細機能 前節で述べた TCP の基本機能に加えて、TCP の信頼性のある通信を行なうために必要 な機能について示す。以下に示すような機能を実現して、信頼性のある通信制御を行なって いる。 • ウィンドウ制御 TCP ヘッダに示されるウィンドウサイズを用いて、受信側が受信可能なデータサイズ を通知する制御のことである。通常は、データを送信する度に受信の確認を示す ACK セグメントを送信する必要がある。しかし、それでは非常に効率が悪いのでウィンド ウズサイズでデータサイズを示すことによって、それがバッファの役割を示し、バッ ファが満たされるまでは ACK セグメントを返さないことにより、効率よい通信を実現 する。 • フロー制御 ウィンドウサイズを越える通信の場合に、受信側ではデータを受信できなくなってしま う。そういった状態を防ぐために、ウィンドウズサイズによるバッファ容量を超過しそ うになった時に、ウィンドウズサイズを小さくして送信するデータ量を少なくして制御 を行う方式である。 • 輻輳制御 ネットワーク上に大量のパケットを送信したり、他のユーザーがネットワークに負荷 をかけていたりすると、トラフィックが増大してしまう。そこで、ネットワークのトラ フィックの増大を考慮しながら、送信するデータサイズや送信頻度を変更する制御のこ とを輻輳制御という。特徴としてコネクション開始時は、スロースタートと呼ばれるア ルゴリズムを使用して、一度に転送できるデータ転送量を、少しずつ増やしていくこと により制御する。 – 14 – 3.4 結言 • 遅延確認応答 データを受信した際に、すぐに ACK セグメントを返さずに受信側でデータを多数受け 取ってから ACK セグメントを返す方式である。特徴として、ACK セグメントの数を 減らすことができるので、ネットワークトラフィックの増大を防ぎ、ネットワーク効率 を良くする。 3.4 結言 本章では、IP プロトコルの基本機能と IP パケットの再構築処理に必要な IP ヘッダのパ ラメータと処理手順を簡単に示した。また、TCP プロトコルの基本機能であるコネクショ ン管理やストリーム型通信を示し、詳細な機能についても簡単に示した。 – 15 – 第4章 データ駆動による TCP パケット処理の実現 4.1 緒言 本章では、作成した IP デフラグメントを行うプログラムの構成や使用したモジュールに ついて示す 。そして、データ駆動を用いていることの利点や処理の並列化部分についてを 示し、現状の問題点と解決案を示す。 4.2 IP デフラグメントプログラム IP デフラグメントプログラムの処理の流れを大まかに説明した後に、各モジュールの処 理内容について詳しく述べる。IP デフラグメントを行なうにあたっての前提条件を示す。 • IP ヘッダは内部メモリに格納済み • IP パケットのペイロードは外部メモリに格納済み 内部メモリには、これから再構築される IP パケットの IP ヘッダ部分が格納されている ものとする。 外部メモリには、これから再構築される IP パケットのペイロードが格納されているもの とする。 IP デフラグメント処理モジュールの構成を図 4.1 に示す。 – 16 – 4.2 IP デフラグメントプログラム 図 4.1 IP デフラグメントのモジュール構成 各モジュールの処理内容について説明する。 1. 再構築判定モジュール 投入された IP パケットが、分割されたパケットであるかのチェックを行なう。 2. バッファ割当モジュール 分割されたパケットの再構成を行なうためのバッファ領域を割り当てる。 3. データ格納モジュール – 17 – 4.2 IP デフラグメントプログラム 分割されたデータを割り当てられたバッファへ格納する。 4. バッファ更新チェックモジュール 分割された最初のパケットと最後のパケットであるかのチェックを行なう。 5. 終了判定モジュール 全てのフラグメントパケットが再構築されたら処理を終了する。 6. パケット出力モジュール 再構築終了後のパケットに IP ヘッダを付加して出力する。 以下に、各モジュールの構成と処理内容について示す。 再構築判定モジュールには、図 4.2 に示すモジュールが含まれている。 図 4.2 再構築判定モジュール • BufferID 作成モジュール IP ヘッダの識別子、送信元アドレス、宛先アドレス、プロトコルを基に BufferID を作 成する。今後、この BufferID が内部メモリ上に存在している間、この BufferID を持つ – 18 – 4.2 IP デフラグメントプログラム 分割されたパケットの再構築処理が行なわれていることを示している。 • ヘッダ flags チェックモジュール IP ヘッダの FragmentOffset の値と Flags の下位１ビットの値をチェックする。両方の 値が共に 0 であれば、このパケットは再構築の必要はないと判断し、0 の値をトリガー として出力する。それ以外であれば、再構築の必要があると判断し、1 の値をトリガー として出力する。 バッファ割当モジュールには、図 4.3 に示すモジュールが含まれている。 図 4.3 バッファ割当モジュール • BufferID チェックモジュール BufferID 作成のモジュールで作成した BufferID が、内部メモリ空間内に存在してい るかチェックを行う。存在しなければ、今まで再構築されていない新しい分割されたパ ケットが来たと判断し、BufferID をバッファ割当モジュールへ渡す。既に同じ BufferID – 19 – 4.2 IP デフラグメントプログラム が内部メモリ上に存在するならば、再構築中の分割されたパケットが来たと判断し、再 構成を行っているバッファへの参照アドレスを出力する。 • バッファ割当モジュール BufferID チェックモジュールで、BufferID が存在しないと判断された場合は、このモ ジュールが実行される。新たにフラグメントの再構成を行うために、使用されてない バッファへの参照アドレスを出力する。 データ格納モジュールには、図 4.4 に示すモジュールが含まれている。 図 4.4 データ格納モジュール • データ格納モジュール バッファへの参照アドレスから示されるバッファへ、外部メモリからペイロードを読み 込み格納する。 • ビットテーブル更新モジュール データが確実にバッファへ格納されたことを示すためにビットテーブルバッファを更新 – 20 – 4.2 IP デフラグメントプログラム する。 バッファ更新チェックモジュールには、図 4.5 に示すモジュールが含まれている。 図 4.5 バッファ更新チェックモジュール • ヘッダ格納モジュール 入力された分割されたパケットの IP ヘッダを参照し、FragmentOffset の値が 0 の場 合はヘッダバッファに IP ヘッダを格納する。格納されたヘッダは、再構築終了後にパ ケットに付加するためである。また、分割されたパケットの FragmentOffset が 0 の場 合は、IP ヘッダをヘッダバッファに格納する。 • 全データ長更新モジュール 分割されたパケットの IP ヘッダを参照し、Flags パラメータの下位 1bit が 0 であるか を判定する。0 であった場合は、送信される前のパケットの最後に分割したパケットだ と判断し、IP ヘッダの FragmentOffset を基に、全データ長バッファを更新する。更新 – 21 – 4.2 IP デフラグメントプログラム する値は、IP ヘッダのパケット長から IP ヘッダの長さを引いた値に FragmentOffset の値を 8 倍した値を格納する。 終了判定モジュールについての説明を以下に示す。 • 終了判定モジュール 全データ長が初期値の 0 でなく、かつビットテーブルが完全であるかのチェックを行う。 これらの条件を満たしている場合は、パケットの再構成が終了したと判断する。条件を 満たしていない場合は、まだ再構成途中であり分割されたパケットが到着してないと判 断して処理を終了し、分割されたパケットが到着するのを待つ。 パケット出力モジュールには、図 4.6 に示すモジュールが含まれている。 図 4.6 パケット出力モジュール – 22 – 4.3 データ駆動による利点 • パケット長更新モジュール デフラグメントが終了した場合は、ヘッダバッファのパケット長を更新する。更新する 値は、全データ長バッファの値と IP ヘッダのデータ長を４倍した値を加えた値である。 • データ出力モジュール 再構築されたデータを順に出力する。 • ヘッダ出力モジュール ヘッダバッファから IP ヘッダを出力する。 4.3 データ駆動による利点 IP デフラグメントの処理では、分割された IP パケットの再構築を終えるまでの処理時間 が非常に長い。また、分割された IP パケットのデータサイズの大きさに比例して、処理時 間が長くなってしまう。しかし、IP デフラグメント処理はパケットの受信元で行なう最初の 処理になるので、この処理部分でボトルネックが発生してしまうと、他の処理に影響を与え てしまう。 そこで、再構築を行なう際の処理を高速に行なう必要がある。また、分割された IP パ ケットのサイズがある程度大きくても高速に処理する必要がある。そこで、従来のノイマン 型プロセッサを用いてのアーキテクチャでは、プロセッサとメモリとの転送速度に限界があ り、ノイマンボトルネックが発生してしまう。今後、ノイマン型アーキテクチャでは、処理 速度の限界を迎えてしまうと考え、処理時間の短縮を見込める可能性はないと考える。 しかし、データ駆動型を用いることによって、並列性の高い処理を実現し、処理時間の 短縮を図ることが可能であると考えられる。IP デフラグメントプログラムでは、図 4.2 の BufferID 作成モジュールとヘッダ flags チェックモジュールを並列に動作させることが可能 である。ヘッダ flags チェックモジュールで再構築が必要であると判断された場合のみ、次 の処理からデフラグメントの必要があると判断して、BufferID を出力してデフラグメント を開始する。 – 23 – 4.4 問題点と解決法 また、図 4.4 では、データを格納すると同時にビットテーブルを更新することによって、 処理の短縮を図っている。 図 4.5 では、最初のフラグメントパケットか最後のフラグメントパケットかを、ヘッダ情 報から判定する処理を並列に行い、判定処理により次に処理するモジュールを選んでいる。 さらに、図 4.6 に含まれるデータ出力モジュールとヘッダ出力モジュールを並列に動作させ、 再構築済みのパケットを出力させることができる。 4.4 問題点と解決法 IP デフラグメントプログラムの作成にあたって、今後改良しなくてはならない問題点を 以下に示す。 • バッファ容量 • データ格納処理に要する時間 これらの問題点の解決法を考察した結果を以下に示す。 1. 環境に対応させたメモリ空間の有効利用 より複数のフラグメントパケットを再構築するためには、その数だけバッファを容易し なくてはならない。しかし、再構築を行なうために必要なバッファ容量は 65535 オク テット以上必要なので、バッファ容量があまり確保できない環境では同時に複数の再構 成を行なえない可能性がある。この問題に関しては、バッファ容量を削減するために、 他の再構築アルゴリズムを考える必用がある。例えば、リスト構造を用いた再構築手法 を用いるとデータを再構築するためのバッファは必用ではなくなると考える。 また、前提条件としての分割された IP パケットのデータ部分を格納しておくバッファ 容量に関しては、一般家庭で用いられている Ethernet に限定して考えると、分割され たパケットのサイズは Ethernet の MTU である 1500 以下となる。なので、それを考 慮して分割されたパケットを一時保存しておくためのバッファサイズの確保を行なえ – 24 – 4.5 結言 ば、メモリの有効利用が可能である。 2. データ格納の並列化 分割されたパケットを指定されたバッファへ格納する処理は、パケットを再構築する際 の一番のボトルネックになっている。この処理部分は、逐次的に外部メモリからのペイ ロードの読み込みを行なった上で、再構築するためのバッファへの書き込みを行なって いる。なので、ペイロード部分をより高速に外部メモリから読み出しバッファに格納す るために、ペイロードの読み出しと書き込みの処理をそれぞれ並列に行なう機構を 実 装する必要がある。 4.5 結言 本章では、プログラム構成を示し、各モジュールの処理内容を明確に示した。そして、問 題点を上げて、データ駆動による利点とプログラムの問題点と解決案を示した。 – 25 – 第5章 性能評価 5.1 緒言 本章では、第三章で説明した IP デフラグメントプログラムを DDMP シミュレータを用 いて性能を評価する。性能指標としてスループットと応答時間の算出を行なう。また、プロ グラム規模として総ノード数を示す。 5.2 評価結果 DDMP シミュレーションを用いて、IP デフラグメントプログラムの性能を評価した。性 能指標として、スループットと応答時間を用いた。また、IP デフラグメントプログラムの 総ノード数は 1091 ノードである。 表 5.1 に、84 オクテットの IP パケット２つを 148 オクテットの IP パケット長に再構築 した場合と、156 オクテットの IP パケット２つを 292 オクテットの IP パケット長に再構築 した場合についての評価結果を示す。 また、実際に Ethernet で再構築を行なうことを想定して、1500 オクテットと 24 オク テットの２つの IP パケットを 1504 オクテットの IP パケット長に再構築した場合について も示す。 表 5.1 に示しているスループットでは一秒あたりの IP パケット量を示している。 – 26 – 5.3 結言 表 5.1 IP パケット再構築処理性能 IP パケット長 [octet] スループット [pps] 応答時間 [ms] 148 3128 0.63 292 689 2.9 1504 259 7.7 プログラムの性能を評価して、実際に再構築を行なえることは確認できた。しかし、実際 に IP デフラグメントプログラムを実装するにあたっては、さらなる処理時間の短縮を図る 必要がある。 5.3 結言 本章では IP デフラグメントプログラムのが正常に動作していることを示し、プログラ ム規模として総ノード数を示した。また、性能評価としてスループットと応答時間を算出 した。 – 27 – 第6章 結論 近年のネットワークの普及によって、誰もが簡単にインターネットを使用して情報を容易 に得ることが出きるようになった。しかし、その背景ではネットワークを利用しての不正ア クセスやウイルス、不正アタック等による情報の漏洩やネットワークへの侵入、情報の改ざ んやデータの破壊、サービス停止などの被害が社会問題になっている。それは、全ての情報 がコンピュータを用いてデータとして管理されているからこそ起こる問題である。そこで、 セキュリティ対策について強く考える必要がある。 本研究では、セキュリティ対策の一つとしてデータ駆動型プロセッサを用いて、データ駆 動型ファイアウォールを実現することを想定し、パターンマッチングを用いてウイルス等の 不正コードを抽出するために必要な、TCP リアセンブル処理への応用を視野に入れ、IP デ フラグメント処理をデータ駆動処理方式を用いて並列化して実装を行ない、シミュレーショ ンを用いて評価を行なった。また評価結果より、データ格納処理部分にオーバーヘッドが発 生していることが分かった。今後は、データ格納処理部分で並列にペイロードを読み出し、 並列にバッファに書き込む必要がある。以下に今後の課題を示す。 • TCP リアセンブル処理への応用 今後は、IP デフラグメント処理を TCP リアセンブル処理に応用することを考える。IP デフラグメント処理と TCP リアセンブル処理は、ほぼ同一の処理手順で実現すること が可能である。今後は、TCP リアセンブル処理を行うために必用な TCP ヘッダのパ ラメータを正確に把握する必要がある。また、TCP ヘッダのパラメータを操作するた めのモジュールを作成する必要がある。 – 28 – 謝辞 本研究に当たって、多大なる御指導を賜った岩田 誠教授に心より感謝の意を表します。 本研究の基礎としているデータ駆動型アーキテクチャを提唱され、様々な御示唆を賜っ た、寺田浩詔 教授に心より感謝の意を表します。 本研究論文の副査をお引き受けいただきました、島村 和典教授、福本 昌弘助教授に心よ り感謝します。 ご多忙の中、本研究の指導、並びにご助言を頂きました、森川 大智 氏、志摩 浩 氏、 三宮 秀次 氏に、心より感謝の意を表します。 日頃から、暖かいご支援、並びにご助言を頂いた大石 裕子 氏、西山 直人 氏、 小笠原 新二 氏に、感謝の意を表します。 日頃から、多くのご意見、ご支援を頂いた、朝日山 輝久 氏、白根 裕太 氏に感謝の意を 表します。 日頃から、多くのご意見、ご支援を頂いた岩田研究室の方々、河野 恵美 氏、 高橋 恵理子 氏、常石 将司 氏、藤本 健太郎 氏、松本 拓也 氏に、感謝の意を表します。 – 29 – 参考文献 [1] H. Terada, et al, ”DDMP’s: self-timed super- pipelined data-driven multimedia processors, ”Proc. of the IEEE, 87(2), 282-296, 1999. [2] RFC 791 ”INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION”, September 1981 [3] RFC815 ”IP DATAGRAM REASSEMBLY ALGORITHMS”, July 1982 [4] TCP/IP illustrated, Volume 1:The Protocols, by W. Richard Stevens, December 2000 – 30 –