要約

  • RFC 5204 の RVS は宛先 HIT の登録を検索して I1 を中継する初期接点であり、R1、I2、R2 の通常経路には残らない。
  • FROM と RVS_HMAC は登録関係における書き換えの完全性を示すが、格納 locator の現時点での有効性や端点認証を示さない。
  • DNS 解決、登録エポック、中継送信、応答側受信、直接 R1、I2/R2、保護データ、アプリ結果を一つずつ結ぶ必要がある。

登録が正しくても現実は先に動く

架空の運用例を考える。移動端末はアドレス A を RVS に登録した後、アドレス B へ移った。更新はまだ届かず、A の登録 lifetime は残っている。I1 が来ると、RVS は正しい表を読み、A を選び、FROM と RVS_HMAC を付けて送信する。RVS の全検査は成功するが、応答側は受信しない。

ここで壊れたのは必ずしもプロトコル処理ではない。「登録済み」を「現在そこにいる」へ読み替えた運用上の判断である。

RFC 5204 は 2008 年の Experimental RFC で、後に RFC 8004 が置き換えた。目的は mobile／multihomed HIP ノードへの初回接触を助けることだ。クライアントは HIT と現在の IP アドレスを RVS に登録する。開始側は DNS などから RVS を知り、I1 を送る。RVS は適切な登録があれば locator へ転送し、なければ破棄する。

登録表の「current」は RVS が現在採用している状態を指す。問い合せ時に端末を再測定したという意味ではない。

復路は RVS を通らない

設計の重要点は経路の切替にある。I1 だけが RVS を介する。応答側は R1 を開始側へ直接返し、I2 と R2 も直接交換する。したがって RVS は association 全体の観測者ではない。

開始側が RVS に届いたこと、RVS が I1 を送ったこと、応答側が受け取ったこと、R1 が戻ったこと、base exchange が完了したこと、アプリが成功したことは別々の状態である。最初の二つだけを数える監視は、後半について「不明」と答えなければならない。

また RFC 5204 は、開始側が自分の RVS を利用して NAT や firewall を越える一般形を扱わない。拡張機能があるなら、その機能固有の契約と証拠が要る。

FROM が保存するのは書き換えの文脈

egress filtering のため、RVS は I1 の source IP を自分のアドレスに置き換えることがある。その場合、元の開始側アドレスを FROM に入れ、登録時に確立した鍵による RVS_HMAC で保護する。既存の FROM は消さず、後続 RVS が末尾に追加する。

これにより登録クライアントは、登録鍵を持つ RVS がその変換を保護したと確認できる。だが元アドレスが Host Identity そのものになったわけではない。全 IP hop を列挙したわけでも、宛先受領を証明したわけでもない。

HMAC の価値を守るには、主語を明示する必要がある。「provenance valid」ではなく「RVS-client 登録スコープの変換完全性が valid」と記録する。

端点認証は次の段階にある

I1 にはまだ HIP base exchange の end-to-end HMAC や signature がない。そのため RVS は header を変更し、parameter と checksum を追加できる。端点同士の認証は後続 exchange が担う。

登録関係の完全性と端点認証は競合する仕組みではなく、異なる層の仕組みである。前者の成功を後者の成功として表示すると、まさに保護境界が消える。

RFC 5204 は redirection、amplification、reflection、HIP 層への攻撃を検討している。RVS が強い control point であるほど、その event を過大な security verdict にしないことが重要になる。

VIA_RVS は診断用の手掛かり

中継 I1 を受けた応答側は、R1 に VIA_RVS を追加する。主目的は association 確立時の障害診断である。

この値は traceroute でも成功証明でもない。応答側が R1 を構成したことと、開始側がそれを受信・検証したことは別だ。その後の I2、R2、保護状態も別である。監視系は breadcrumb を completion へ昇格させてはならない。

DNS と登録は別の時計で動く

DNS には公開時刻、TTL、resolver cache、署名条件がある。RVS 登録には登録 ID、lifetime、renewal、最終更新がある。新しい DNS RR が古い登録を指すことも、有効な登録が使えない locator を持つこともある。

必要な receipt は、利用した DNS 証拠、要求 HIT、登録エポック、I1 fingerprint、lookup、書換前後の header、FROM 順序、HMAC context、送信時刻を保存する。さらに応答側受信、R1 の直接返送、I2/R2、association、保護データ、アプリ結果を別ソースから追加する。

obsolete は実装観測ではない

RFC 8004 は RFC 5204 を置き換え、周辺の base protocol、registration、DNS、mobility にも RFC 7401、8003、8005、8046 がある。資産台帳はどの世代を実装しているかを明記すべきだ。

しかし旧 RFC の引用だけで、ある製品が古い、脆弱、または移行済みとは断定できない。仕様は期待される振る舞いを示し、running code と packet evidence が実際の振る舞いを示す。

Sources