要約

  • RFC 5207 は HIP 制御交換と ESP データ面を分ける。I1/R1/I2/R2 の完了だけでは、保護されたデータの往復を証明できない。
  • SPI は片方向の文脈を持つため、出方向を観測した NAT が逆方向の値を自動的に知るわけではない。経路変更は学習済み状態を無関係にもする。
  • 健全性は、交換パケット、各 middlebox の規則、双方向 ESP、端点での検証・復号、アプリケーション結果を時系列で結んで初めて成立する。

認証の記録は揃い、注文だけが届かなかった

ある拠点の装置が内側から HIP を開始した。UDP で運ばれた制御交換を境界ファイアウォールが許可し、両端はベース交換を完了した。認証ログも四つのメッセージも揃う。監視はセッションを緑にした。

しかし業務データの戻りは、マルチホーム構成の別回線を選んだ。そちらの境界は交換を見ておらず、SPI の状態も受け取っていない。ESP は既定拒否で落ち、注文処理はタイムアウトした。

これは仕組みを明らかにするための仮想例であり、実在の障害ではない。RFC 5207 も現在の製品や導入率を測定していない。重要なのは、認証が真であることと、アプリ結果が真であることの間に、別の支配面が存在する点だ。

RFC 5207 は 2008 年の Informational RFC で、IRTF の HIP Research Group による問題記述である。Internet Standard ではない。文書は middlebox が HIP の制御トラフィックと ESP のデータトラフィックに別々の障害を生むと整理した。この二分は運用記録でも維持すべきである。

元の IPv4 交換には NAPT が探すポートがない

初期の IPv4 HIP は、よく知られたトランスポートではなく固有の IP payload type を使った。アドレスだけを書き換える単純な NAT なら、内部を理解せず通過させられる場合がある。

NAPT は複数の内部ホストを区別するため、通常はポート番号を必要とする。ところが HIP の制御パケットには、その装置が期待するポートがない。外から開始された場合には、内側からの先行パケットが作る translation state もない。

ここで欠けているのは端点の暗号能力ではない。middlebox が配送判断に使う座標である。失敗を HIP unsupported by peer と保存すれば、経路の制約を相手の能力として記録してしまう。

IPv6 では拡張ヘッダーが問題になり得る。未知の拡張を拒否するフィルターは、有効な交換を遮断する。UDP encapsulation はポートと内向き応答用の状態を与え、第一段階を助けるが、それだけで ESP の状態は作られない。

ESP は判断材料を暗号化の内側へ移す

ベース交換後、HIP は ESP でデータを保護する。NAT やファイアウォールが通常参照する上位ポートは見えなくなる。HIT を checksum 計算に使う設計はアドレス変換に伴う一問題を避けるが、復路の demultiplexing を完成させるわけではない。

ESP ヘッダーの SPI は見える。そこで装置は SPI を flow identifier として使いたくなる。しかし RFC 5207 が強調する通り、SPI の意味は片方向だけである。A から B の値を見ても、B から A の値は導けない。

同じ NAT の背後にいる複数ホストが同じ SPI を選ぶ可能性もある。装置が SPI を書き換えるなら、元の値、外側の値、方向、Security Association、規則、期限を残す必要がある。数字だけを保存すると、どの変換がどの主体に属したかを後から説明できない。

SPI は精密なフィールドだが、世界共通のセッション ID ではない。ユーザーもアプリケーションも表さず、受信、integrity、anti-replay、復号の成功も保証しない。

交換から学ぶ装置は、その装置の状態しか作れない

RFC 5207 は、HIP ベース交換を観測して双方の SPI を学ぶ architectured NAT、SPINAT を検討する。後続 ESP だけから推測するより、制御交換の意味を使える点で強い。

それでも learned は広域の事実ではない。parser は正しい版と拡張を理解し、policy は pinhole を許可し、規則は実際の forwarding table に入り、期限内にデータが到着し、そのデータが同じ装置を通らなければならない。

したがって証跡は装置単位になる。どのパケットを見たか、どの状態を提案したか、誰の方針で承認したか、match と lifetime は何か、後で何パケットが hit したか。controller の成功応答は意図の処理を示す。dataplane の前後観測が効果を示す。

経路が変われば、完全に正しい規則が、完全に無関係な装置に残る。集約された緑表示はこの状態を表現しにくい。

明示的な signal も宛先を誤れば効かない

端点が汎用 NAT/firewall signaling を使い、必要な SPI を通知する方式もある。RFC 5207 は MIDCOM と NATFW NSLP を挙げる。middlebox に HIP 全体を理解させなくてもよい反面、端点か代理は関係する境界を特定しなければならない。

マルチホームでは、複数の NAT やファイアウォールのどれを signal するかが問題になる。境界 A が署名済み要求を正しく認可しても、ESP が境界 B を通れば、その成功はデータに影響しない。

path-coupled signaling は実際の経路上の装置へ届くよう設計できる。しかし、その後に route が変わり得る。proxy mode は導入範囲を広げるが、新たな権限主体を追加する。要求、認証、認可、install、expiry、経路の継続、packet hit を別々に記録する必要がある。

pinhole や NAT binding はセキュリティ上敏感である。peer の認証は、ネットワーク境界を変更する権利と同じではない。match の範囲、所有者、承認、期限、撤去までが統治対象となる。

UDP が救うのは、まず制御面である

旧来の NAT は UDP を扱えることが多い。内側から送れば mapping ができ、応答も戻る。これによって HIP ベース交換が成功する場合がある。

RFC 5207 はそこで結論を止める。UDP がベース交換を通しても、ESP にはなお問題がある。VPN pass-through が SPI を対応付けようとしても、多数のホストや collision、片方向の値によって限界が出る。

ESP 自体を UDP で包めばポートが得られる。後の RFC 5770 は ICE と UDP を用いる実験的仕組みを、RFC 9028 は native NAT traversal mode を示し、RFC 9063 は新しい HIP architecture を記述した。

だが文書の系譜は deployment record ではない。実装されているか、設定で有効か、policy が許可するか、この path が使うかは別である。資産台帳には、版、mode、encapsulation、port、locator、keepalive、双方向の観測を明記すべきだ。

一つの緑表示は修復範囲を無駄に広げる

認証、middlebox state、ESP、application を一つの session established にまとめると、各チームは自分の局所的成功を提示できる。security は規則を、network は出方向 SPI を、protocol は peer authentication を示す。application だけが timeout を示す。

不足箇所が特定できない組織は、ESP を広く許可し、期限を延長し、経路を固定し、inspection を無効化しがちだ。通信が戻っても、例外は本来の主体より広く長く残り、原因は不明のままである。

安全な timeline は最初に欠けた receipt で止まる。交換 packet fingerprint、両方向 SPI、各装置の installed state、境界前後の ESP、端点の integrity・anti-replay・decrypt、application transaction。ここまで分ければ修復も局所化できる。

unknown は観測の欠陥を隠さないための正当な値である。沈黙から成功を推定するより、次の観測点を指定できる。

古い RFC も新しい RFC も running state ではない

RFC 5207 は当時の問題空間を記録した。後続仕様は解決策を発展させた。古い分析を現在の全装置へ一般化してはいけないし、新仕様が公開されたから全装置が移行したと考えてもいけない。

specification は意味を定める。implementation は機能を持つ。configuration は機能を選ぶ。policy は許可する。capture は特定地点の packet を示す。endpoint log は cryptographic outcome を示す。application receipt は有用な結果を示す。

Running Code Primary は仕様を捨てる原則ではない。仕様を観測項目へ変換し、現実の代用にしない原則である。

最小 receipt は二段階を往復する

HIP version と traversal mode、HIT と locator、I1/R1/I2/R2 の fingerprint と timestamp、NAT mapping、firewall identity と policy revision、outbound/inbound SPI、signal principal と応答、rule match・owner・expiry、各段階の path identity、境界前後の ESP counter、integrity・anti-replay・decrypt、application transaction と結果を結ぶ。

一つの装置に全知を求める必要はない。NAT は mapping を、firewall は rule を、host は association を、application は outcome を語ればよい。問題は局所的な報告ではなく、それを end-to-end verdict として代用することにある。

出典