1996年,商用ファイアウォールにおけるIPsecの実装状況を調査するために,アトランタで開催されたNETWORLD+INTEROPを訪れた。IPsecの仕様はその1年前に発行されていたが,改定される予定になっていたのでほとんどのベンダーは実装を見合わせていた。そんな中,IPsecとパケット・フィルタを併せ持つWindows用アプリケーションを出品し,「これからはファイアウォールじゃなくて,ファイアクロース(防火服)だぜ!」と宣伝している小さなブースがあった。

 ちょうどその頃,多種多様なファイアウォールが世の中に出ていた。悪者から自分達を守ってくれるのはファイアウォールしかないと信じていた私は,ファイアクロース(防火服)という言葉に衝撃を受けた。のちに悪者は,むしろ組織の内部に多く潜んでいることに気づく。結局,自分のことは自分で守らなければいけないのだ。時期が早すぎたのか,その商品はあまり売れなかったようだ。しかし,IPv6が広まりつつある今ならば,この考え方が受け入られるかもしれない

 IPv6が本当に世の中に広まった時,現在では想像もできないデバイスがインターネットにつながっているはずだ。ファイアウォールやNATの内側で生活していると,何ができるのか気づくことすらできない。夢に溢れたインターネット本来の姿を望むならば,個々のデバイスに防火服を着せ,荒野に住まわすのがいいだろう。そのための1つの技術としてIPsecがあると信じている。

 かつてIPsecは万能で完全なセキュリティ・プロトコルだと信じられていた。プロトコル設計者は,セキュリティについて述べる時にはIPsecの仕様を参照するだけで安心していた。IPv6の設計者達も同様に参照するだけだった。

 しかし,実際に運用してみると,解決しなければならないさまざまな問題があることがわかってきた。それらの問題は,つい最近になってようやくIETFの場で議論されるようになった。抜本的な問題解決に向け,基本仕様の改定もほのめかされている。

 例えば,IKEの問題がある。IPsecを使うためには,通信するデバイス同士がいくつかのパラメータを共有する必要がある。このパラメータを共有するためのプロトコルがIKEだ。実は,このIKEの仕様は不完全である。設定の複雑さからパラメータの共有に失敗したり,また,エラーからの回復処理が定義されていないという問題がある。こうしたことからIETFではIKEの改定版を検討している。

 設定の複雑さは,IPsecの自由度の高さに関係している。セキュリティ対策を考えるとき,「何を何からどうやって守るのか」,つまりセキュリティ・ポリシーを定めるところから始まる。そしてポリシーは管理者の数だけ存在するので,IPsecはそのすべてに対応するべく設計されている。だが,結果的にそれが仇となった。IPsecを設定するパラメータが多くなり,組み合わせも増えて複雑になってしまった。微妙なポリシーの違いや,実装の違いををうまく吸収したガイドラインがあれば,状況はもう少し改善されるかもしれない。

 また,モバイル環境でうまく動作しないという問題もある。移動するたびにIPアドレスが変わるデバイスの場合,移動するごとにパラメータを共有しなおす必要があるからだ。IETFでは,新しい概念をIPsecの仕様に導入し,IKEに変わるプロトコルを設計する動きがある。

 NATの内側のホストから外側のサーバーにIPsecを使って通信するための仕様も検討されている。これは,IPv6のホストからIPv4のサーバーへ通信する時のことも考慮に入れているらしい。NATやトランスレータが介在すると,どんどん複雑になってしまうが,現状を考えるとそうも言ってられない。

 ともかく,まだまだやらなければならないことは多そうである。



ファイアウォール
 組織の外部のネットワークから,組織の内部のネットワークへの不正なアクセスを防ぐ装置のこと。内部から外部へのアクセスを制限することもできる。
IPsec
 IP通信にセキュリティを付加するインターネット標準の一つ。要素技術としては,IPパケットの暗号化,送信側と受信側とでの相互認証がある。
パケット・フィルタ
 パケットの内部情報を基に,そのパケットを通過させるか破棄させるかを決める制御機能。
ファイアウォールやNATの内側
 >ファイアウォールは通過できるサービスを制限している場合がある。また,NATを通過できるサービスは限られている。どちらの場合も,その内側にいるホストは,外側のサービスの利用を制限される。
IKE
 Internet Key Exchange。IPsecのためのパラメータ共有を自動実行するためのプロトコル。
セキュリティ・ポリシー
 セキュリティに関する基本的な方針のこと。ネットワーク管理者が自らのネットワークのあるべき姿に照らしながら作成するルール。例えばパケット・フィルタリングのルールは,このセキュリティ・ポリシーに基づいて決めていく。

坂根 昌一
IPsecの調査実装をしていたことが縁でKAMEプロジェクトに参加。結成時以来,先生方の背中を見て精進する毎日。鍵交換デーモン racoon の開発者でもある。ネットワークのセキュリティ全般に興味があり,面白いと思えば何にでも手を出す。趣味は広くそこそこ深くだが,最近はまとまった時間が取れず散歩くらいしかしていない。いつかフロリダバスを釣ってやると誓っている。