wakatonoの戯れメモ

はてなダイアリーから引っ越してきました。

「(Linuxの)IPsecの困難」を何度か読み返して…

セキュリティ

オレも前に書いたが、IPsecを取り巻く環境がナニである、というのはyomoyomoさんも自身のコラムで書かれている。
この状態を承知の上で、IPsecがv2からv3へ、IKEがv1からv2へと移行するにあたって、スムーズに移行（もしくは共存）できるための方法を妄想してみよう。

自分で書いておいてなんだが、IKE v2になり、IPsec v3になったとして、もしかしたらそんなに大変なことにはならないかもしれない。

IKE v2 & IPsec v3 になったとして、おそらく一番大変なのはやっぱりIKEの実装だろう。もちろん、これらのバージョン（IKE v2 & IPsec v3 の組み合わせ）だけしかサポートしなければ、多分まだラクだ。ただ、IKEでやりとりされるメッセージのフォーマットを見ると、なるほどIKEのバージョンを扱うフィールドがある。

まず1つ、これでIKEについては解決された（いいのか？）。ではIPsec v3の方はどうだろう…

ここではESPについてのみ扱ってみる。

通常このテのプロトコルを扱う場合には、後方互換性を考慮する必要があるか、全く考慮する必要がない（別モノ）として扱う必要がある。どっちのアプローチが正しく、どっちのアプローチが間違ってるということはない。決めの問題である…と個人的には思う。そう思ってみてみたところ、IPsec v3については後前者のアプローチを取っているようだ。ヘッダについてはフォーマットを変えず、他の部分でなんかやっている。具体的には

  • シーケンス番号のサイズは32bitから64bitに増えている
  • シーケンス番号の下位32bitは、IPsec v2のシーケンス番号と同じところに位置する
  • シーケンス番号の上位32botは、パケットの後ろに位置する

なるほど、こうすれば暗号化されたペイロードの位置は変わらない。
ついでにいうならば、シーケンス番号はあくまでリプレイアタックを防ぐためのものであり、パケットを送るごとに増分されるもんであるから、通常の処理をする上で普段見なければならないカウンタは下位32bitのみでOK。上位のカウンタを参照したり更新したりする時は

  • リプレイアタックよろしく同じシーケンス番号のものが出てくるような時
  • 下位32bitがオーバフローした時

というようにすればいいだけか。

これは「カウンタは必ず連続したビットで保持されなければならない」というオレの思い込みを見事に打ち砕いた結果になる（いや、たいしたことはないのだけど）。

なんのことはない、ちゃんと考えてはあるのだ。
このあたり、要らぬ憶測により混乱をさせてしまったことについて、深くお詫び申し上げたい。

で、ここからが本題なのだが…（前振りが長い）。

IPsec v3が実装され、IKE v2が実装された際に、その中に互換性に関する規定はあるのか？といわれると、多分ないだろう。しかし、ESP v3のパケット構成中の「Integrity Check Value(ICV)」と呼ばれるフィールドの構成によっては互換性を保つことも可能に見える。

ESP v2 についてはこのフィールドは「Authentication Data (variable)」と呼ばれる。どっちにしても可変である。

ただ、ヘタにスタックに互換性を持たせようとすると、おそらくESP v2の認証とICVの構成をまたなんかしないといけないとかいう話になるが、この部分の処理は間違いなくバージョンに依存するだろう（多分いっしょには出来ない）。

すると、IPsec通信を行うにあたって必要となるSA(Security Association)の情報に埋めておいた方が、実装する側もラクになる。こんなのは、IKEでやりとりする情報を1つ増やしてやればいいだけの話だ。

ただしこれは、ある一対の通信相手の間で複数のバージョンのESPパケットが流れないという前提のもとに成立するものである。ここまで縛ってたかどうかはちょっとドラフトを読みきってないのでなんともいえない…。もしかしたら重大な勘違いしてるかもしれないし＞オレ

そうなると、パケットそのものにバージョン情報を持たせる、というのが最も有力な解になるのだが、ざっと調べた限りはICVがその鍵を握るような気がしてきた。

このあたりは、IETFの報告会の資料だけを斜め読みしていたバチがあたったともいえるが、実はESPとIKEの新しいバージョンに関するドラフトは、意外に練ってあるように見えてきたというのが正直なオレの感想である。

しかしこれはあくまで現状の話であり、今後どのように変わるかは全くわからない。
オレは「ICVが鍵を握る気がする」といってるが、もしかしたらICVそのものを使わないという解もありうるのだ。

さて、実装に目を落とすと、おそらくIKEv3の実装は必然的にIKEv2についても解釈できるようにしておくのではないか。これについては、CISCOやNOKIAをはじめとするVPNソリューションを売っている会社に対するカスタマの要望として出ることが予想される。

そうなると、IPsecスタックについても同様のことが出てくるだろう。

今後、ドラフトを実装したものが出てくるだろうが、それらが出てきてから改めて考察してみることとしたい。

＃もちろん、今後またドラフトを読むチャンスがあったらそうしてみるが…。