要約

  • RFC 3948 は IKE と UDP カプセル化 ESP に同じ NAT マッピングを使わせ、正規の ESP SPI がゼロになれないことを利用して、4つのゼロオクテットを IKE の印にした。
  • その印が決めるのは次に試す処理系だけである。SA の検索、リプレイ防止、暗号検証、内側アドレスの方針、アプリケーション結果は別々に確かめる必要があり、0xFF の受信はピアの生存証明にもならない。

一つの穴を三つの目的が通った

NAT を越えるため ESP を UDP で包むと、変換装置には扱いやすい外側のポートができる。ただし、IPsec の制御を担う IKE と保護データを運ぶ ESP が別々のマッピングを必要とすれば、タイマーもファイアウォール規則も増える。RFC 3948 は同じポートを共有する道を選んだ。マッピングを一つにすれば規模を広げやすく、通常の通信が IKE 用の余分な維持信号を減らし、設定と実装も単純になる。RFC 3947 は NAT 越えの交渉と UDP 4500 への移行を規定した。

外側が単純になった分、受信側には内側の振り分けが必要になった。ポート番号だけでは IKE と ESP を区別できない。RFC 3948 は新しい大きなヘッダーを足すのではなく、ESP が正規には使えない値を境界にした。

使えないゼロに役割を与える

ESP ヘッダーの先頭32ビットは Security Parameters Index、SPI である。受信側はこの値を手掛かりに、パケットを処理する Security Association を探す。RFC 2406 ではゼロがローカル用途のために予約され、通常の ESP SPI として回線上に現れない。RFC 3948 も UDP カプセル化 ESP の SPI をゼロにしてはならないと明記した。

一方、UDP 4500 上の IKE メッセージは、UDP ヘッダーと IKE ヘッダーの間に4つのゼロオクテットを置く。これが Non-ESP Marker であり、ESP なら SPI が置かれる位置と重なる。先頭32ビットがゼロなら IKE へ、非ゼロなら ESP へ、という最初の分岐が成立する。

この仕組みは、排除済みの値を再利用した点で小さく美しい。しかし4つのゼロは秘密でも署名でも MAC でもない。送信者を特定せず、IKE SA を指さず、その後ろのメッセージが正しい形式かどうかも保証しない。IKE の認証や状態検査は、振り分け後に IKE 自身が行う。

非ゼロ側も同様である。先頭語を SPI 候補として読めても、該当する SA が存在するとは限らない。シーケンス番号、リプレイ窓、暗号保護、トラフィックセレクターを調べ、内側の通信を許可して初めて先へ進む。未知の SPI や検証失敗は、正しい振り分けの後でもパケットを終わらせる。

1オクテットが守ったのは NAT の状態

同じ経路には、0xFF だけを積んだ1オクテットの NAT キープアライブも流れる。RFC 3948 は受信側にこれを無視するよう勧め、その目的を NAT マッピングの維持だけに限定した。

さらに、受信したキープアライブを接続の生存判定に使ってはならないと明記した。変換装置がタイマーを更新したとしても、IKE の状態が健全とは限らず、ESP SA が残っているとも、暗号処理が成功するとも、アプリケーションが応答するとも限らない。中間装置の記憶とエンドツーエンドの結果は別物である。

当時の既定値である「必要な場合に20秒ほかの送信がなければ送る」「SA が存在していた後も設定可能な5分間は送り得る」は、機器共通の現在値ではない。ここで重要なのは所有者の違いだ。NAT はマッピング期限を持ち、端点は送信タイマーを持ち、IKE と ESP は SA の寿命を持ち、アプリケーションは別の可用性基準を持つ。

パーサーを選んでも内側の権限は決まらない

UDP カプセル化は ESP を置き換えない。送信側は通常の ESP 処理の外に UDP を加え、受信側は UDP を外して通常の ESP 処理を続ける。その後も NAT が変えたアドレスをどう扱うかという問題が残る。

トンネルモードでは、内側送信元が許可範囲か、ピアに割り当てたアドレスかを検査し、必要ならローカル網向けに変換する。トランスポートモードでは、アドレス変更で TCP または UDP のチェックサムが合わなくなるため、IKE で得た元アドレスを使う差分修正や再計算など、限定された方法が必要になる。先頭4オクテットはこの方針を選ばない。

セキュリティ節の重複例はさらに明快だ。別々の NAT の後ろにいる二台が同じプライベートアドレスを持てば、ゲートウェイには同じ内側宛先へ向かう複数の SA が見える。同じ公開アドレスの後ろに複数クライアントがいて、トラフィック記述が重なれば、単純な検索では送信に使う SA を選べない。実装は一意なローカルアドレスの割当、再変換、競合拒否などで曖昧さを処理しなければならない。

この課題は RFC 3715 が整理した IPsec と NAT の互換性要件につながる。RFC 3948 は実用的な回線形式を与えたが、外側アドレスを NAT 内部の万能な主体名にしたわけではない。

IKEv2 に残った狭い約束

RFC 3948 の公式記録 は、2005年1月公開の Standards Track 文書であることを示す。確認済み errata は序文の参照先を一か所直すだけで、4ゼロの形式を変えない。

RFC 7296 の IKEv2 も、4500 上の IKE に4つのゼロを付け、ESP をゼロになれない SPI から直接始める。しかも、NAT を検出していなくても開始時から 4500 を使う選択を認める。したがって、4500 の観測を NAT 存在の証明に読み替えることもできない。

RFC 3948 が残したのは「4バイトが IPsec を安全にした」という物語ではない。ポートは共通入口、先頭語は処理候補、IKE と ESP はそれぞれの判定、ローカル方針は内側通信の許可、アプリケーションは最終結果を担当する。小さな規則が長く使えるのは、一つの仕事だけを正確に引き受け、ほかの権限を奪わなかったからである。

参照資料