同じ話題を扱った、Slashdot 本家と Slashdot Japan の二つのストーリーをまず見比べていただきたい。
新山祐介さんが時折 /.J のダメさ加減について書くが、こういうのを指すのだろうなと思った。両者を見比べると一目瞭然である。片やプロジェクトが終了しても開発継続可能なオープンソースの利点とその実態についての議論はあるは、継ぐのは俺だと後継プロジェクトについて宣伝しまくる人はいるは、実際の利用者による IPsec スタックとしての FreeS/WAN の問題点、そしてカーネル 2.6 に取り込まれた IPsec スタックとの比較論もある200以上のコメントに対し、日本版のストーリーは、本家のそれに比べれば情報量は限りなくゼロに近い。もっとも、内容のある書き込みを行うインセンティブが /.J にはあまりないのだから仕方ないのかもしれないが。
……と、人の尻馬に乗ってあげつらうだけというのも生産的でない。そもそも、この世の椅子をスケベ椅子とそれ以外の椅子に分類するようにふるい分ければ、ワタシだってダメな方に入るだろう。その一人として、調査がてらに FreeS/WAN プロジェクトの終焉を契機として、IPsec の現状について考えてみる。多分事実認識の誤りなどツッコミどころの多いだろうから、ご指摘を歓迎します。
以前ワタシは、「Linux で IPsec が使われない理由」という文章を書いたことがあるが、前述の /.J のストーリーを読んでも、「利用者の声」が皆無なのをみると、当時から FreeS/WAN 利用者はあまり増えていないのだろうか。
かの John Gilmore が、盗聴に対抗してインターネット上のトラフィックの多くを暗号化するという目標を掲げて始まったプロジェクトは、残念ながら最後までその目標を達成することができなかった。これには、Clay Shirky の The RIAA Succeeds Where the Cypherpunks Failed を読んだときに感じたのと同じ苦さを感じてしまうのだが、FreeS/WAN プロジェクト終了に関して言えば、（以前書いた文章と同じ流れになってしまうが）その FreeS/WAN 自体の問題と、IPsec というセキュリティプロトコルの問題の両方があるだろう。
それではまず FreeS/WAN の問題は何かということになると、やはりそれがカーネルに取り込まれなかったという一点につきる、とインストールに苦労したことのある人間としてはどうしても思う。これがカーネル設定一つですぐに IPsec が利用できるようになる FreeBSD の KAME IPsec スタックなどとの違いである。
それではどうして FreeS/WAN は Linux カーネル本体に取り込まれなかったのか。Linux Advanced Routing & Traffic Control HOWTO によると、
とのことだが、前者は FreeS/WAN と Linux カーネルに限った話ではないのだから、後者が主なのだろう。FreeS/WAN は、単体のフリーソフトウェアプロジェクトとしてはドキュメンテーションが非常に充実していたことを考えると余計残念である。
あとワタシ自身が思うところを付け加えておくと、FreeS/WAN の IPsec サポート範囲が狭いのも問題だったように思う。RFC において実装 MUST である DES の非サポートというのはポリシーとして許容できるとしても、それ以外で正式にサポートしていた暗号アルゴリズムが長らく 3DES だけだったというのは寂しいものがあるし、ワタシもインターネットドラフトを訳したりしている NAT Traversal 関係を含め、「製品」レベルに必要な仕様をサポートしようと思えば、Super FreeS/WAN を持ってくるしかない現実が以前からあった。
FreeS/WAN プロジェクトは、一方で Opportunistic Encryption の普及を目標としたのだが、結局のところこうしたものは他の実装との相互接続性がないと意味がない。それよりも先に本体に取り込むべきもの、改善すべきものがあったろうにと思ってしまうのだ。
岡目八目的な苦言が続いたが、/. 本家のストーリーでは、Openswan の人が勢い良く名乗りをあげており、フリーソフトウェアの利点の一つである、その作者やプロジェクトが見放したとしてもソースコードが自由にアクセスでき、後を引き継げるというお題目を再確認できた。Super FreeS/WAN と併せ、その遺産がそのまま無駄になることはないはずである。
しかし、不思議なのは、FreeS/WAN のコード品質があったとはいえ、いきなり Linux カーネル2.6に新しい IPsec コードベースが採用されたことである。LARTC HOWTO や The official IPsec Howto for Linux（日本語訳）を見ても、確かに設定インタフェースは KAME 風であり、IKE（自動鍵交換）プロセスは、KAME の racoon が標準になりそうである。
思えば2000年の Internet Week における 6bone-JP BOF で、当時立ち上げ間もなかった USAGI Project について、山本和彦さんらがしきりに「あの謎のロシア人」、「屑ネット」を何とかしないとと語っており、当時のワタシにはそれが誰を指すのかまったく分からなかったわけだが、LATRC によると「USAGI IPv6 グループの成果から刺激を受け」カーネルネイティブな IPsec を実装した Alexey Kuznetsov のことだったりする。
ただ、BOF で話題になっていたのは飽くまで IPv6 実装の話であり、それにしてもこれは道は遠いなと思わせたものだが、USAGI プロジェクトの IPsec 実装については、とにかく仕様を実装するという "rough consensus and running code" だけでは駄目だという批判もあった。これが Linux カーネルに取り入れられた経緯はどんなものだったのだろう。
試しに Linux カーネル2.6.3のソースコードをダウンロードしてざっと見てみたが、IPv6 の IPsec にあたる net/ipv6/esp6.c, ah6.c には、USAGI Project のメンバー二人と Kunihiro Ishiguro さん（GNU Zebra の作者として著名）の名前がクレジットされている。Kernel Traffic #206 によると、David S. Miller のとりなしで両者の作業がマージされたようだが、WIDE 系人脈に近い印象がある石黒さんが USAGI と別々に作業していたということの方が、個人的には逆に不思議な感じもする。
しかし、IPv4 の IPsec ということで net/ipv6/esp4.c, ah4.c のコードを見たのだが、こちらには作者のクレジットがないのでよく分からない……と言うか、それええんか？ まあ、USAGI STABLE 5 リリース時のアナウンスを読む限り、こちらも USAGI Project の実装がベースになっていると考えてよいとは思うが。
さて、IPsec スタックがカーネル安定版に正式に取り込まれたとなれば、当方がかつて味わった苦労もなくなるし、また例えば Mandrake の IPsec のような問題もなくなるだろう。遂に Linux においても IPsec 利用が本格化するに違いない……とは言えないように当方には思えるのである。残念ながら。
ここで浮かびあがるのが、IPsec（とその実装）が抱えてきた問題である。
暗号研究における第一人者である Bruce Schneier らは、1998年末の IPsec バージョン2と IKE の仕様 RFC 化を受けて行った調査結果をまとめた A Cryptographic Evaluation of IPsec において、冒頭 "IPsec was a great disappointment to us." と断じているが、槍玉にあげているのはその「複雑さ」である。そして実際、その複雑さと仕様に残る曖昧さが原因で、その後長らく各社の製品間の相互接続性が、IPsec 利用の最大のネックであり続けた。
「IPsec の相互接続性の問題」という場合、それはほぼ IKE のそれだと思ってよい。FreeS/WAN Project による Opportunistic Encryption は、そのあたりを簡単に済ませることを目指したものであり、その方向性自体は間違っていなかったと思うのだが、それはさておき、当方が現在懸念するのは、現在策定が進められている IPsec、IKE の次バージョンが、そのあたりを解決してくれるのかということである。
IPsec の次バージョンについての情報は、坂根昌一さんによる第58回IETF報告会における発表資料、並びにそれについてのレポートに詳しいが、当方は前者を読み、正直これはダメじゃないかと思った。
今から一年以上前になるが、Port139ケーキOFFの際に講師の wakatono さんに、「IKEv2 が作られるのはいいが、v1 と v2 の実装が混在することで、相互接続性の問題が今より悪化する可能性は？」と質問したところ、「ポート番号が変わるだろうから大丈夫では」というお答えをいただいたのだが……ポート番号一緒らしいですぜ、旦那（IKE ヘッダにはバージョン番号を格納するフィールドがあるから大丈夫なのか？）。
それに、である。wakatono さんも懸念していた ESP と AH のプロトコル番号だが、IETF の IPsec WG のページから LAST CALL がかかっている ESPv3 と AHv3 のドラフトを見ても、シーケンス番号フィールドに変更が出るにも関わらず、それぞれプロトコル番号50と51で、v2 のときと変わっていない。
つまり、IPsec 本体にしろ IKE にしろ新版になり、特に後者は前版と互換性がなくなる。しかし、利用するポート番号、プロトコル番号は基本的に変わらない。もちろんまるっきり別モノというわけもないのだから、仕様が固まればすぐに実装は出てくるのだろう。しかし、この混在具合を考えると、またぞろ相互接続性の罠にはまるように思えてならない。
IETF には、ワタシなんかより遥かに優れた人たちが集まって議論しているのだから、こんな初歩的な疑問に対する答えは用意されているに違いない。ご存知の方は是非教えていただきたい。だが、ワタシのようなボンクラには、非常にヤバく思えてならないのだ。IPsecv1→v2時の移行のときとは、現バージョンの普及範囲は全然違うというのに。
ワタシが IPsec の将来について悲観的なのに、リモートアクセス系において、IPsec より、俗に言う SSL-VPN が普及しそうな気配があるのもある。「俗に言う」と書いたのは、この SSL-VPN と呼ばれるソリューションが、VPN と名乗るに値しないと思うからである。案の定「「SSL-VPNには危険が潜んでいる」とノキア幹部が警鐘」なんて記事が出たりしているが、企業のセキュリティポリシー（とその遵守）一つでかなり危険ではないかと予防線を張っておきたい。
しかし、利用者は「正しい」方より、「使いやすい」方を歓迎する。やはりどの PC にも入っている、またほとんどの人が日常的に利用するブラウザベースでアクセスできる方が便利に決まっている（かくして不完全なセキュリティ製品がはびこるのである）。
もちろん SSL をベースとしてちゃんとした VPN を提供するソフトウェアもあるのでそこらへん誤解なきよう。/. の Evaluating SSL-Based VPNs? というストーリーあたりが参考になるだろうか（今気付いたのだが、このストーリーを垂れ込んだのは、当方が訳している Apache based WebDAV Server with LDAP and SSL HOWTO の著者ですな）。
リモートアクセス系は企業ソリューションにしても、また個人のトンネル掘削的（笑）需要にしてもどうも IPsec は部が悪いようである。
それでも、IPsec の本領と言える LAN 間接続、それも企業の拠点間などのスタティックなネットワーク環境においては現在も広範に利用されているし、それはこれからも変わらないだろう。上記のバージョン混在問題も、こうした環境では両方の終端に同じメーカの製品を揃えているケースが多いだろうから混乱は小さいはずだ。
しかし、前述の通り個人寄りの需要に応えられないのは大きな問題だと思う。IPv6 の旗を振る人たち（と書くと揶揄しているようだが、そんなつもりはない）は、IPv6 におけるセキュリティの懸念について IPsec を引き合いに出すのだが、その答え自体弱いのを差し引いても、現在我々が利用しているトンネル掘削＋暗号化に慣れてしまい、IPv6 ネットワークにおいてもその延長線上のソリューションを求めてしまうということはないのだろうか。IPsec 自体がユーザに取り残されてしまうような……
SSL（HTTPS）のような分かりやすいアプリケーション（ブラウザ）との密着がなく、また PPTP のようにかつて馴染んだ（そうでない世代も多いのかもしれないが…）ダイヤルアップの接続イメージもない IPsec の今後は厳しいというのが当方の正直な見方である。本来筋の良いはずのプロトコルが、NAT との噛みの悪さ、仕様の改版などに足を絡められている間に、SoftEther という極めて破壊的な（もちろん良い意味で）ソリューションが登場した今となってはそう思ってしまうのだ。
[後記]：
wakatonoの戯れメモ、そして無印吉澤＠はてなダイアリーの文章が、本文に足らないものを数多く指摘していますので、是非こちらもご一読ください。なお、Openswan が正式に FreeS/WAN の後を継ぐ模様です。