要約

  • RFC 5206 と後継 RFC 8046 では、locator 通知の真正性と新アドレスの到達性を分ける。新規アドレスは原則 UNVERIFIED となり、nonce の往復か新 SA 上の受信で次の事実を得る。
  • Credit-Based Authorization は未検証経路へ送れる量を最近の受信量で制限する。増幅を抑える仕組みであって、検証やアプリ継続の証明ではない。

移動通知を受け取った瞬間

HIP の利点は、IP アドレスが変わっても Host Identity に結び付いた関係を維持できることにある。ところが運用画面がその利点を一つの「移動成功」にまとめると、RFC が残した重要な途中状態が消える。

UPDATE の HMAC や署名が通れば、既存 association の相手が locator を通知したと判断できる。攻撃者による書換えを検出し、sequence と lifetime を関連付けられる。しかし無線断、経路未収束、NAT state 消失、ESP policy 不一致は署名の外側にある。

そこで locator table は UNVERIFIED、ACTIVE、DEPRECATED を持つ。最初の状態は失敗ではない。証拠の範囲を正確に表した正常な状態である。

新経路へ質問を送る

典型的な検証は、ランダムな nonce を ECHO_REQUEST に入れ、新 locator 宛ての UPDATE として送る。対応する応答が戻れば、peer がそのアドレスで受信し、返答したことを確認できる。

新しく通知された SA 上で保護データを実際に受信した場合、それを暗黙の reachability evidence としてよい場合もある。ここでも根拠は通知そのものではなく、新しい経路で観測した packet である。

SA を作る、nonce が戻る、最初の ESP payload を受ける、アプリが復旧する、という四つは別の時刻を持つ。障害解析では一致しないことを許さなければならない。

preferred は希望値

P bit は peer の希望する宛先を示す。未検証の preferred locator が届いても、既存の ACTIVE locator があれば検証中はそちらを使う。検証後に初めて新 locator を ACTIVE にする。

Locator Lifetime も可用性保証ではない。レコードが有効である期間と、interface や route が使える期間は一致しない。通信が途絶えれば ACTIVE を再び UNVERIFIED に戻して確かめる必要もある。

R1 に関する例外は base exchange の限定された条件である。一般的な「署名済みアドレスは検証不要」という製品ルールにしてはならない。

先に少し送るための会計

移動のたびに検証 RTT を待つとアプリが止まる。CBA は最近 peer から受けた byte を credit とし、その範囲だけ未検証 locator へ送信する。送信で残高が減り、時間でも減衰する。

これは不確実性を隠さず扱う方法である。RFC は、redirection による増幅を防ぐと説明する。洪水そのものを消すとも、住所の所有を証明するとも述べない。

ログには CBA 開始残高、獲得 byte、ageing、消費、拒否、verification 結果を残すべきだ。packet sent を path verified に変換すると、制限付き送信を用意した理由が失われる。

嘘をつかない移動台帳

association、UPDATE fingerprint、locator set、lifetime、P bit、address check、初期状態、fallback、nonce、再送、response、新 SA の packet、状態遷移、preferred decision、SA、application result、expiry と deletion を順に結ぶ。

この台帳なら、署名成功・challenge 失敗、challenge 成功・ESP 失敗、ESP 成功・application 失敗を区別できる。各 owner は自分が観測した層だけを保証する。

世代を混ぜない

RFC 5206 は 2008 年の Experimental RFC で、現在は obsolete。2017 年の Standards Track RFC 8046 が置き換え、LOCATOR を LOCATOR_SET に変更し、multihoming を RFC 8047 に分離した。到達性を別途確認する境界は残る。

新 RFC を inventory に書くだけでは migration evidence にならない。実装 version、parser、state transition、timer、CBA 値と packet behavior を確認する。

経営判断は、通知認証、locator 検証、保護経路、application continuity を別の SLA とすることだ。署名は発言者に責任を持つ。経路について語れるのは、そこから返ってきた running code の証拠だけである。

出典

  1. RFC 5206 情報
  2. RFC 5206 HTML
  3. RFC 5206 テキスト
  4. Datatracker RFC 5206
  5. RFC 5206 履歴
  6. RFC 5206 参照
  7. RFC 5206 Errata
  8. RFC 8046 情報
  9. RFC 8046 HTML
  10. RFC 8046 テキスト
  11. Datatracker RFC 8046
  12. RFC 8046 履歴
  13. RFC 8046 参照
  14. RFC 8046 Errata
  15. RFC 7401 — HIP v2
  16. RFC 7402 — HIP ESP
  17. RFC 8047 — HIP multihoming
  18. RFC 6973 — privacy considerations
  19. RFC 4423 — HIP architecture
  20. Heng Lu — reality layers
  21. Heng Lu — minimum initial specification
  22. Heng Lu — running-code primacy