要約

  • 10月1日付の作業部会Internet-Draft第08版は、送信元IPアドレスやポートが異なる新しいTCP接続で保護されたIKEメッセージを受けた場合を明記した。その接続はIKE SAにだけ使い、配下のESP SAの送信元IPアドレスやポートを変えてはならない。
  • 双方向の通信が想定されるのに受信ESPパケットがない場合、ESPの接続性に問題がある可能性がある、とも書き加えた。暗号化ESP pingも代替の確認手段として残る。無通信だけで障害を断定する文言ではない。

管理画面ではVPNの鍵交換が成功したように見え、肝心の通信が通らない。その差を生むのは、IKEv2がセキュリティアソシエーションを交渉する制御の仕組みであり、ESPが保護されたデータを運ぶ仕組みだからだ。今回の草案は、鍵交換が大きくなる場面でIKEをTCPに乗せつつ、可能ならESPをIPまたはUDPで運ぶ構成を扱う。TCPが通るという観測から、別の経路を使うESPまで通ると推定してはいけない。

第07版との比較で重要なのはNATに関する一文の限定だ。以前は異なる送信元IPアドレスやポートから届いた保護済みIKEメッセージと書かれていた。第08版はそれを、異なる送信元を持つ新しいTCP接続上のメッセージと明示する。NATの外側にいるホストはその接続をIKE SAにだけ使い、そのIKE SAが作ったESP SAの送信元情報を変更してはならない。一方、完全性検証を通過したESPパケットが新しい送信元から届いた場合には、ESP側の別個の更新規則がある。制御路の再接続とデータ路の移動は、証拠も影響する状態も異なる。

別々のトランスポートを使う仕組み自体は第08版の発明ではない。提案には以前からSEPARATE_TRANSPORTS通知があり、開始時にUDP 4500でIKE_SA_INITを行って応答側の対応を確認してから後続のIKE交換をTCPへ切り替える方法がある。初回の鍵交換が大きければTCPから始める方法もある。ESPは到達可能ならIP直送またはUDPカプセル化を使う。TCPから始めた際に応答側が通知を返さなければ、既存のRFC 9329に従いIKEもESPもTCPで送る。今回変わったのは、この設計の輪郭ではなく、接続が変わったときに更新してよい状態の書き方だ。

もう一つの改訂は監視の読み方に関わる。双方向のパケットを期待しているのにESPの受信が途絶えたら、経路に問題がある可能性を調べる理由になる。前版が挙げていた暗号化ESP pingは、新版でも使える。とはいえ、アプリケーションが休止している場合、応答しない通信形態の場合、監視点が適切でない場合にも受信はゼロになりうる。この文言だけでファイアウォールやNATの障害、まして攻撃を特定できない。

以前からある本文の規則も、この境界を補う。IKEのTCP接続はESP用UDPのNATマッピングを維持しないため、ESPの経路には独自のキープアライブが必要だ。IKEをTCPで開始した場合、その交換成功はESPの到達性の証拠にならない。Child SAを設けた後、他の証拠がなければESPを確かめ、確認できなければIKE SAを削除して、ESPの別経路を提案せずTCP上で作り直すよう定める。これはデータ経路の確認結果に基づく切り替えであり、鍵交換の成功だけに反応する自動処理ではない。

Datatrackerでの位置づけは、公開を要請された有効な作業部会Internet-Draftである。RFCとして確定したものではなく、草案の通知番号も未割り当てだ。特定製品の実装や実際の通信障害を裏づける資料もない。今回の報道対象は、IKEとESPの境界をより検証しやすくした文言の変更に限られる。

出典