（Linuxの）IPsecの困難(YAMDAS Project)
http://www1.neweb.ne.jp/wa/yamdas/column/technique/ipsec2.html
id:yomoyomoさんによる、主にLinux上のIPsecに関する記事です。FreeS/WANプロジェクトの終焉と、その利用者が増えなかった理由についての考察、その一方でUSAGIが最新のLinux 2.6系にマージされている現状、そしてIPsecが抱える現在と将来の問題について、と、かなり盛りだくさんな内容で参考になります。
僕はFreeS/WANについてほとんど何も知らなかったので、前半の内容を消化するのにだいぶ時間がかかりました。とはいえ、FreeS/WANとUSAGIの違いは未だによく分かってないので、BSD系とLinuxでIPsec実装に差が無くなるという意味ではUSAGIが選ばれてよかったんじゃないかなぁ……という程度の認識しかなかったりするんですが。
-
-
- -
-
そういうわけで、個人的には後半の内容の方がいろいろ気になりました。
今から一年以上前になるが、Port139ケーキOFFの際に講師の wakatono さんに、「IKEv2 が作られるのはいいが、v1 と v2 の実装が混在することで、相互接続性の問題が今より悪化する可能性は？」と質問したところ、「ポート番号が変わるだろうから大丈夫では」というお答えをいただいたのだが……ポート番号一緒らしいですぜ、旦那（IKE ヘッダにはバージョン番号を格納するフィールドがあるから大丈夫なのか？）。
それに、である。wakatono さんも懸念していた ESP と AH のプロトコル番号だが、IETF の IPsec WG のページから LAST CALL がかかっている ESPv3 と AHv3 のドラフトを見ても、シーケンス番号フィールドに変更が出るにも関わらず、それぞれプロトコル番号50と51で、v2 のときと変わっていない。
こりゃまずいんじゃ……と思いつつ『マスタリングIPsec』サポートページ経由でドラフトをちらっと確認したところ、確かにIKE*1の方はヘッダが同じなので上位互換の実装は可能そうです。
ESPv3*2とAHv3*3では通常32ビットのシーケンス番号を64ビットで管理するExtended Sequence Number(ESN)がサポートされるようですが、これは単に「シーケンス番号を内部的に64ビットで管理しなさい」と指示するSAパラメータの一種であって、実際にヘッダ中のシーケンス番号フィールドを64ビットにするわけではないとのこと（ただし、ICVの計算には反映）。ESPv3とAHv3、それぞれのドラフトの付録部分にESNの扱い方が書かれています。
と、まぁ、確かにパケットの見た目的には旧バージョンと衝突しなそうなのですが、どちらの場合も新旧のバージョンを共存させようと思うと内部設計上大変そうですね……。同じポート500番で待ち受けるということはIKEv1とIKEv2のサーバ（デーモン）は一体化する必要があるでしょうし、ESPとAHは別バージョンを付けて現在のものとは分離した方が実装しやすかったんじゃないでしょうか。
-
-
- -
-
あとは最後の段落でちらっと触れられているIPsecとIPv6の組み合わせについて、最近考えていたこととちょっと近かったので、少し考えをまとめてコメントしてみます。
それでも、IPsec の本領と言える LAN 間接続、それも企業の拠点間などのスタティックなネットワーク環境においては現在も広範に利用されているし、それはこれからも変わらないだろう。上記のバージョン混在問題も、こうした環境では両方の終端に同じメーカの製品を揃えているケースが多いだろうから混乱は小さいはずだ。
しかし、前述の通り個人寄りの需要に応えられないのは大きな問題だと思う。IPv6 の旗を振る人たち（と書くと揶揄しているようだが、そんなつもりはない）は、IPv6 におけるセキュリティの懸念について IPsec を引き合いに出すのだが、その答え自体弱いのを差し引いても、現在我々が利用しているトンネル掘削＋暗号化に慣れてしまい、IPv6 ネットワークにおいてもその延長線上のソリューションを求めてしまうということはないのだろうか。IPsec 自体がユーザに取り残されてしまうような……
この文章はIPv6の持つ2つのメリット、つまり
- アドレスを自由に使えるのでend-to-end通信が可能
- 標準でIPsecをサポートしている
ということを前提にしてると思うのですが、最近仕事でUSAGIを少しいじってみて感じたんですけど……この2つのメリットって実際のところ全然共存できてないですよね？
つまり、IPsecはend-to-end通信（peer-to-peerに置き換えても可）に向かないようになっている、またはend-to-end通信で利用するための考慮が足りてないのではないか、と最近考えています。今のところ思いつく理由を以下に並べてみます。
1. 一時的な用途に向かない
まず、IPsecを必要なときだけ使うのって難しい気がします。どんな方法でセキュリティアソシエーションを確立するにしても、作ったセキュリティポリシー(SP)とセキュリティアソシエーション(SA)は使用後に明示的に削除する必要があるし、特にSPはライフタイムの概念が無いので、消し忘れるといつまでも残ってしまいますし。
ソケットを閉じれば使われなくなるTLS/SSLと比較すると、end-to-endで不特定多数の相手と通信する場合にはかなり面倒に見えます。
2. 管理者権限がないとセキュリティポリシーを作成できない
rootやAdministratorの権限を持っていない一般ユーザがセキュリティ機能を利用できないというのは、ちょっと違うのではないかと。まぁ、Windowsの場合はAdministratorになって使っている人も多そうですけど……。
例えば、個々のIPsec SP、SAの利用を特定のユーザやアプリケーションに制限・権限管理する機能があれば、「管理者権限がないと使えない」なんていう制限は要らなくなると思うのですがどうでしょう。ちなみにTLS/SSLの場合はソケットを開いたアプリケーションでしか使えないので、この手の心配はありません。
3. アプリケーション側から分かりづらい
これは2と似た話なのですが、IPsec通信をするアプリケーションは基本的に元々用意されているSP、SAを利用する形になるので、アプリ側では通信が暗号化されているかどうか等の情報を持つことはほとんどありません。
IKEを使って自動的にSAを確立する場合に限らず、SAが存在することはわかっても、そのアプリが送受信するパケットが暗号化されているかどうかはわからないですよね？ それはTLS/SSLの場合も同じじゃないかと言われそうですが、こちらは「ソケットが使える＝暗号化が行われている」と直結しやすいので、データが暗号化されずに送られる心配はあまり起こらないような気がします。
・
・
・
と、まぁ、さんざん書いてしまったような気がしますが、もちろんIPsecにはIPsecのメリットがまだちゃんとあります。特に3番目の項目については、逆に言えばアプリ自体に手を入れなくても通信も暗号化できるということなわけですし……。
そういうことで、今のところの結論としては「アプリに意識させずにIPsecを利用する方法」と「アプリから意識的にIPsecを利用する方法」の両方があれば、end-to-end通信とIPsecが共存しやすくなるのではないかなぁ、といったところでしょうか。アプリから意識的にIPsecを利用する場合は、TLS/SSLを使ってSAパラメータを交換するような方法が最適解になるような可能性もあると思うのですが……いかがでしょう。
まだ自分の頭の中でもよくまとまってないせいで、読みにくい文章になってしまって申し訳ありませんでした。_|￣|○
何かお気づきの点などありましたらコメントお願いしますー。
><
-
-
- -
-
（2004/03/23修正）
終盤があまりにもぐだぐだだったので修正しました。
