要約

  • RFC 2406はESPの保護範囲をフィールド単位で定めた。トランスポートモードでは元のIPヘッダーが外に残り、トンネルモードでは内側データグラムを保護する一方、新しい外側IPヘッダーが見えた。SPIとSequence Numberも平文で送られた。
  • 機密性、認証、リプレイ防止は別々の選択だった。認証は任意で、暗号化にはNULLを選べた。必須のシーケンス番号も、受信側が窓を有効にして認証後に判定しなければ、リプレイ防止の証拠にはならなかった。

トンネルを観察すると、見えなくなる住所と新しく見える住所がある。内側の送信元と宛先は暗号化領域に入る。代わりに、トンネル終端へ届ける外側アドレスが現れる。通信の関係は消えたのではなく、別の関係に置き換わった。

1998年11月のRFC 2406は、この境界をESPの共通仕様として整理した。1995年のRFC 1827では、SPIだけが変換方式に依存しない必須フィールドだった。暗号方式ごとの文書が追加フィールドと処理を定めた。RFC 2406は、変換の組合せが増えすぎたため、Sequence Number、Padding、Next Header、任意のAuthentication Dataと処理順序を基本形式へ移したと説明する。

共通形式になっても、サービスは一つにならなかった。機密性だけを選ぶことができ、ESP認証を付けない構成もあった。NULL暗号を使い、認証だけを選ぶこともできた。両方とも省くことはできない。リプレイ防止は認証がある場合にだけ選べ、その採用は受信側の判断だった。

ワイヤ形式は外側IPヘッダーから始まり、プロトコル番号50を示す。その後に32ビットのSPIと32ビットのSequence Numberが続く。次にPayload Data、Padding、Pad Length、Next Headerが並び、選択された場合だけAuthentication Dataが末尾に付く。

暗号と認証が別アルゴリズムなら、暗号化範囲はPayload DataからNext Headerまでだった。外側IPヘッダー、SPI、Sequence Number、末尾の認証値は暗号化されない。明示IVがPayload Dataの先頭に置かれる場合も、文書は「ciphertextの一部」と呼ばれがちだが、IV自体は通常暗号化されないと注意した。

完全性の範囲は異なる。認証を選ぶと、ICVはSPI、Sequence Number、Payload Data、Padding、Pad Length、Next Headerを対象にする。ICVを格納するAuthentication Data自身は除く。暗号化が先なので、ペイロード部分は暗号文の形でICVに入る。外側IPヘッダーはそれでも対象外だった。

トランスポートモードでは、ESPは元のIPヘッダーと上位プロトコルの間に置かれる。元のアドレスは経路から見える。IPv6ではESPより前の拡張ヘッダーも保護外で、後ろに置くDestination Optionsは保護領域へ入れられる。ヘッダー順序は単なる構文ではなく、保証の境界だった。

トンネルモードでは、元のIPヘッダーを含むデータグラム全体が内側へ入る。ただし配送のため新しい外側ヘッダーが必要になる。観測者は最終端点を失っても、ゲートウェイ、時刻、パケット長、量を見られる。十分な数の通信が同じゲートウェイ間に集約されなければ、個別フローの特徴は残りやすい。

RFC 2406がトラフィックフロー機密性を「限定的」とした理由である。効果にはトンネルモードとセキュリティゲートウェイでの集約が必要だった。余分なPaddingは実ペイロード長の推定を難しくできるが、帯域を消費する。時間、総量、外側端点まで単独で隠すものではない。

Sequence Numberも、存在と実行を分けていた。送信側は受信側の設定にかかわらず番号を増やして送る。受信側はSAごとにリプレイ検査を無効にできた。キャプチャに連番があるだけでは、スライディングウィンドウが動いたとはいえない。

リプレイ防止を有効にするなら認証も必要だった。完全性のない番号は改変できるからである。受信側は古すぎる候補を先に落とせても、ICVが成功するまで窓を進めてはならない。必要な証拠は、正しいSA、認証された番号、受信側の窓判定を結ぶ。ワイヤ上の番号はその一要素にすぎない。

処理順序はポリシーとの距離も示す。送信前に、RFC 2401の仕組みがESPを要求するSAを選ぶ。その後にカプセル化、Padding、暗号化、任意の認証が行われ、IP断片化はESP処理の後で起きる。受信時は再構成が先であり、断片のままESPへ渡されたパケットは破棄対象だった。

受信側は宛先、ESP、SPIから一方向SAを探す。SAが、番号を調べるか、認証データがあるか、どの鍵とアルゴリズムを使うかを決める。有効なSAがなければ破棄する。ICV一致はESP段階の妥当性を示すが、受信ポリシーやアプリケーションの受理までは決めない。

認証がない場合、誤ったSAや破損した暗号文から生じた異常をIPsecが必ず検出するとは限らず、後続プロトコルに任されることもあった。認証と復号を並列実行しても、検証が終わる前に平文を後段へ渡してはならない。暗号処理の成功は、内容の意味や利用許可ではない。

監査も同じである。監査機能を持つシステムはESPを組み込み、管理者が有効・無効を選べなければならない。しかし全実装に監査機能が必須だったわけではなく、粒度は主にローカルだった。SA不在、断片、番号枯渇、ICV失敗が「監査可能」と書かれていても、ログが保存された証明にはならない。

RFC 4303は2005年にRFC 2406を置き換えた。平文のSPIと番号、トランスポート／トンネル、機密性／完全性、受信側リプレイ判断という骨格を保ちながら、拡張シーケンス番号、複合モード、TFC Paddingなどを加えた。1998年文書は現在の暗号選択表ではなく、設計史として読むべきである。

Lu Hengが述べるrunning codeの視点を適用すると、問いは「ESPという名称が付いたか」では終わらない。どのモード、どのサービス、どのSA、どの受信検査が実際に動き、外側から何が見え、後段が何を受理したかを確かめる必要がある。仕様の図は、その分離を一枚で示していた。

出典