八巻研の研究内容


<バックグラウンド:レイヤ7解析ルータ>

八巻研において研究のコアとなる部分は,ルータによる通信データの内容解析です. まず,従来のルータは当然ながら,通信データの中身まで見ることはしません. 通信パケットの宛先IPアドレスを見て,適切なポートから送り出す,という役割のみを担います. これに対し,レイヤ7と呼ばれる通信パケットのより深い部分(webページやユーザID,パスワードといった通信内容本体が入っている)にまで踏み込んで処理を行うレイヤ7解析ルータが近年注目されています. このようなルータを使うことで,例えば怪しいwebサイトへのアクセスやウィルスデータを含んだメールの転送といった, 危険なネット行為に対し,ユーザが意識することなく対処可能となります.
図.レイヤ7解析ルータを用いたインターネットアプリケーションの例

<レイヤ7解析ルータにおける文字列探索処理の高速化>

レイヤ7解析ルータの処理は重く,近年の高速なネットワークで実用するには10倍~100倍程度も処理速度が足りていないのが現状です. 処理性能向上のボトルネックとなっている処理に,パケットに対する文字列探索処理があります. 従来のパケット処理では,データの先頭から何Byte目に宛先IPアドレスが入っている,というように必要な情報がどこに含まれているかがわかっていたため,高速な処理が実現できました. しかし,例えばウィルスが何Byte目に入っているか,メールの何文字目に有害なURL情報が含まれているか,決まっているでしょうか? この問題を解決するためには,ウィルスだと判断できるデータ列や有害なURLを,パケットの先頭から一文字ずつマッチングさせていくしかありません. すなわち,”virus”という文字列を検出するには,データの先頭から”v”を探し,”v”が見つかったら次の文字が”i”かどうか判定し…,という動作を繰り返します. そして,この処理こそがレイヤ7ルータにおいて最も時間のかかる処理となります.
図.パケットに対する文字列探索処理の例

これに対し,八巻研ではなるべく上記のような文字列探索をさせないことで文字列探索を高速化する様々なアプローチを提案しています.
一つのアプローチとして,文字列ではなくハッシュ値と呼ばれる数値によりマッチングを行う手法があります. ”virus”という文字列に対しハッシュ値計算を行うと,例えば12という数値が結果として得られます. 同様に,パケットデータから5文字を取りハッシュ値計算を行います. ここで計算結果が12となった場合には,その5文字が”virus”である可能性があるということです. 逆に言えば,計算結果が12とならない場合は,確実に”virus”ではないと言えます. この手法は,検出すべき文字列パターン数が多くなるほど効果的です.
図.ハッシュ値を用いた文字列探索処理

また,別のアプローチとして,そもそも文字列探索をする必要のないデータ部分に対し探索処理をしないという手法があります. インターネット上を流れるデータは様々ですが,例えば動画データ本体やIP電話の音声データにまで文字列探索を行う必要はありません. また,メールや画像等のデータにまで,webサーバの脆弱性を突いたアタックパターンを検出する必要もありません. このように,通信データの内容を知ることができれば,それに応じた検出パターンを適切に選んで適用することが可能となります.


<通信経路上におけるHTTP圧縮通信データの高速展開機構>

近年,インターネット通信において通信データの圧縮技術が注目されています. というのも,ネットワークトラフィック量はここ3年で2倍に増大と,急速な速度で成長しています. そこで,通信の始点において通信データ圧縮し,終点において圧縮データを展開することで,ネットワーク上を流れるトラフィック量の削減が期待できます. 現在では,我々がwebページを見る際に用いるHTTPプロトコルにおいても,GZIP圧縮されたwebコンテンツをやりとりする機能がデフォルトとなりつつあります.
しかしながら,レイヤ7解析ルータにおいては,データが圧縮されているとその内容解析ができなくなるため厄介です. そこで,八巻研ではレイヤ7解析ルータ上においてパケット内の圧縮されたデータを高速に展開し,解析可能とする機構を提案しています. また,従来の圧縮展開機構は,展開処理の高速さやリアルタイム性に関して意識することはありませんでした. そのため,圧縮されたデータを溜めこみ,先頭から末尾まで圧縮データが揃った段階でようやく展開処理を開始します.
図.従来のGZIP展開機構による圧縮パケットの展開

一方で,ネットワーク経路上では,圧縮データが複数のパケットに分割された状態で流れます. 従って,従来手法を用いて圧縮展開する場合には,圧縮データの末尾部分のパケットが到着するまで, 圧縮データを含んでいる全てのパケットを保持して待たなければなりません. これでは,通信データをオンザフライに解析できるレイヤ7解析ルータのメリットを活かせず,また膨大なメモリ容量が必要となります. そこで八巻研では,少ないメモリ容量で,なおかつ圧縮データが揃うのを待つことなく,到着パケットを逐次に圧縮展開できるアーキテクチャを提案しています.
図.八巻研提案のGZIP展開機構による圧縮パケットの展開

<フロー処理キャッシュを用いたパケット処理の高速化および省電力化>

近年,全てのモノがインターネットに繋がるというInternet of Things(IoT)や,膨大なサイズのデータを扱うビッグデータ解析という言葉が科学技術研究者や企業の界隈においてキーワードとなっています. これらの実現に伴い,通信データ量が今後爆発的に増加する情報爆発が起こると予測されています. 私たちがインターネットを利用するとき,必ず通信データはルータを通過し,正しい宛先へ転送されていきますが,ルータはこの情報爆発に耐えられるのでしょうか? 答えは,処理速度的に見ても,消費電力的に見ても,”危うい”です.

インターネットにおいてデータはパケットという小さいデータ単位で送られてくるため,ルータはパケット毎に処理を行いますが, この時,各パケットの処理に必要な情報はメモリから読み出します. 例えば,パケットの宛先IPアドレスを基に送り出すポートを決定するルーティングテーブルや,パケットに対してファイアウォールを行うフィルタリングテーブル,パケットの転送優先度を決定するQoS(Quality of Service)テーブル等, 複数のテーブルを1パケット毎に読み出すことで,ルータは処理に要する情報を得てパケットを処理します. ここで,現在のハイエンドなルータはTernary Content Addressable Memory(TCAM)と呼ばれる,データエントリ検索の非常に速い特殊なメモリにテーブルを格納することで,高速なパケット処理を実現しています. しかしながら,TCAMは一般的なSRAMメモリ等に対して16倍程高消費電力と言われ,また,その速度も現在のインターネットの最大帯域である100Gbpsで限界が見えてきたと言われています.

従来ルータのパケット処理
図.従来ルータのパケット処理

これに対し本研究室では,小規模な分,高速かつ低消費電力なキャッシュメモリにパケット処理結果を保存し,その処理結果を他のパケットでも使い回そうというアプローチを試みています. パケットを一つの通信(例えばブラウザであるwebページを見た際の片方向の通信)や一つの送信元IPアドレスといった,何かしらでまとめた単位をフローと定義します. この時,同じフローに属するパケットの多くのテーブル検索結果は等しくなります. そこで,フローの初回パケットのみ,TCAMで処理し,後続パケットはキャッシュにより処理することで,パケット処理の大幅な高速化と省電力化が可能となります. 特に,フローとして送信元IP・宛先IP・送信元ポート番号・宛先ポート番号・プロトコル番号の5タプルによりフローを定義することで,ほとんどのテーブル検索結果はフローで単一に決定できます.

フロー処理キャッシュの概要
図.フロー処理キャッシュの概要