要約

  • 改訂07はIKEv2をTCP、ESPをIP直送またはUDPカプセル化で運べるようにするが、Child SAの成立はESP経路の到達性を示さない。
  • ネゴシエーション、トランスポート別NAT状態、暗号化ESP応答、実アプリ通信、フォールバック判断を別々に記録しなければ、真正性と可用性を取り違える。

障害対応の現場では、最初に成功したものが全体を代表してしまう。TCP接続が張れた。IKEv2の相互認証が終わった。鍵が導出され、Child SAも作成された。ここまで見れば「トンネルは上がった」と言いたくなる。

しかし、利用者の通信は一件も届かない。

TCPを許したファイアウォールがネイティブESPを拒否しているかもしれない。IKE用TCP状態を持つNATが、ESP用UDP 4500のマッピングを持っていないかもしれない。制御のための道と、保護データのための道は同じ証拠を共有しない。

IPsecME作業部会の Separate Transports for IKE and ESP は、この不一致を仕様上の問題として扱う。改訂07はIETF streamのStandards Track向けInternet-Draftで、凍結したDatatracker状態は「WG Consensus: Waiting for Write-Up」である。RFCでも実装実績でもない。その段階を越えて語ってはならない。

出発点には二つの事情がある。IKEv2はもともとUDPを使う。RFC 9329はUDPが通らない環境のため、IKEとESPをTCPに包む方法を定めた。一方、ポスト量子鍵交換では公開鍵や制御メッセージが大きくなり、信頼できるバイトストリームが有利になる。ただし、大量のESP通信までTCPに載せると、性能や輻輳の性質まで変わる。

改訂07はSEPARATE_TRANSPORTS通知で両者を切り離す。応答側も能力を返せば、以後のIKE交換はTCPを継続し、ESPは可能ならIP直送、NATがあればUDPカプセル化を使う。応答側が通知を返さなければ、RFC 9329どおりIKEとESPの双方をTCPに残す。

ここで合意されたのは方式であって、開通ではない。

IKE_SA_INITをUDPで始めた場合、その要求と応答自体がUDP到達性の手掛かりになる。最初からTCPで始めた場合、ESPについて同じ暗黙の証拠は存在しない。そこで改訂07は、受信ESPなど別の証拠がない限り、Child SA作成後にESP到達性を確認するよう求める。

この順序は重要だ。Child SAは暗号学的に正しくても、運用上は使えないことがある。ドラフトのSecurity Considerationsも、ESP到達性が確認できない事実だけではIKEv2認証やChild SAの暗号保護は弱くならない、と明記する。真正性が保たれたまま、可用性だけが失われ得る。

NAT環境では差がさらに明確になる。中間装置はトランスポートごとに状態を持つ。IKEのTCP接続を維持しても、ESPのUDPマッピングは維持されない。ESP側は独自にNAT keepaliveを送る必要がある。新しい送信元から正当なESPを受けたときはESP SA群の端点を更新できるが、IKE SAの端点を勝手に変えてはならない。保護されたIKEメッセージで制御端点が変わっても、ESP端点の証明にはならない。

同じ相手でも、経路の記憶は二つある。

TCP開始時の確認手順も分離されている。NATを検出したならUDP 4500でESPを試す。NATがなければまずネイティブESPを試し、短い待ち時間で応答がなければUDPカプセル化も試す。UDPまたはTCPヘッダーのないIP通信を拒む中間装置があるためだ。先に応答した経路を採用する考え方はHappy Eyeballsに似ている。

Encrypted ESP Echoは、その確認に使える候補である。ただし証明範囲は限定される。特定のSAと経路で、保護された要求に保護された応答が返ったことは示せる。すべてのパケット長、すべてのTraffic Selector、トンネル先サービスの健全性、利用者の処理完了までは示さない。Echoの後にも、代表的なアプリ通信の受領証が要る。

ESP到達性を確認できなければ、現在のIKE SAをDELETE payloadで削除し、ESPの分離を提案せずTCP上で再確立する。つまりRFC 9329の一体型へ戻る。そこで運用ポリシーが問われる。ESP-over-TCPの性能上の代償を受け入れるのか、要件を満たさない接続として中止するのか。

答えはサービスごとに異なる。緊急管理経路は継続性を優先できる。低遅延・高スループット用途はTCPフォールバックを拒否するかもしれない。監査対象システムなら、暗号化プローブと実トラフィックの両方が揃うまで健康状態にしない設計が妥当だ。

MOBIKEでアドレスが変われば、過去の判定は期限切れになる。新しいネットワークには新しいフィルタとNATがある。IKEがTCPで連続している事実は、ESP経路の証拠を新しい場所へ運ばない。セッション再開も同様で、ネットワーク条件が変わり得るため、分離トランスポートの選択をチケットに保存してはならず、再交渉する。

これはHeng Luの最小初期仕様と現実レイヤーの考え方に沿う。仕様は相互運用に必要な能力だけを共有し、将来の経路判断は現場の事実を持つ端点に残す。「SA established」という記号は、実際の保護パケットより上位の現実ではない。Running-Code Primacyが重視するのは、設定項目ではなく動いた経路である。

運用記録は、IKE各段階のトランスポート、通知の合意、NAT判定、ESP候補、独立マッピングとkeepalive、最初の保護応答、実アプリ結果、フォールバック承認、移動・再開後の再検証を別項目で持つべきだ。「VPN up」という一語では、責任の境界が消える。

出典