要約

  • RFC 5202 は、SPI を利用する中間システムが rekey 情報を読むため、ESP_INFO を暗号化できないと明記した。後継の RFC 7402 も同じ境界を維持している。
  • 署名済み、暗号化済み、観測可能、保持終了、新 SA 稼働中という状態は同義ではない。運用記録と表示を分ける必要がある。

まず ESP ヘッダーを見る

プライバシー評価をアプリケーション本文から始めると、HIP の重要な設計判断を見落とす。RFC 4303 の ESP ヘッダーでは、32 ビットの SPI と Sequence Number が暗号化領域より前に置かれる。両者は integrity の対象だが、送信時には暗号化されない。

SPI は受信側が受信 SA を検索するために選ぶ値である。HIP ではさらに HIT ペアの圧縮表現として扱われ、アドレス対応を行う中間システムが利用できる。ただし意味は局所的だ。ある時点の宛先アドレスと SPI の組で受信側 HIT が定まり、別のホストや別の時点では同じ数値が別の意味を持ち得る。

この限定が大切である。SPI は永久 ID でも鍵でもない。一方で、動作中の装置にとっては無意味な乱数でもない。

読ませるための署名

HIP が ESP SA を rekey するとき、ESP_INFO は旧 SPI、新 SPI、KEYMAT index を運ぶ。開始側の UPDATE には SEQ、任意の Diffie–Hellman、HMAC、HIP signature が入り、応答側は ACK と自分の対応情報を返す。

RFC 5202 は中間システムの立場から理由を書く。SPI を使う装置は rekey 情報を含む HIP packet を inspect しなければならない。packet はその装置の利益のために署名される。新 SPI が必要なので内容は暗号化できない。RFC 7402 は Experimental 文書を置き換えた後も、この説明を残した。

ここで signature と encryption は逆向きの機能を持つ。署名は見えている遷移を検証可能にする。暗号化は遷移を読めなくする。従って「署名があるから秘密」という表示は、暗号技術の役割を取り違えている。

何が関連付けられるか

HIP header には送受信 HIT があり、ESP_INFO には旧値から新値への移行があり、IP header と観測装置には locator と時刻がある。association context を保持する HIP-aware firewall や NAT は、これらを用いて意図どおり state を更新できる。

RFC 9063 は、その種の中間装置が on-path traffic を受動的に観測し、control plane と data plane の soft state を維持し得ると説明する。RFC 6973 の定義では、暗号化済み flow でも、存在、方向、時刻、量、構成、頻度から推論することは traffic analysis である。

ただし、人の名前まで飛躍してはならない。単一の SPI は自然人や企業を表さず、payload も明らかにしない。実際の linkability は、観測者が持つ HIT 履歴、locator、他センサー、保存期間に依存する。記事が立証するのは、時間付きの対応関係が露出する境界である。

乱数化の射程

仕様は SPI の random 選択を勧め、同じ peer との別 exchange には異なる値を用い、rekey では変更を必須とする。これは再利用や replay への対策として重要である。

しかし、保存済みの 旧 → 新 関係は次の乱数化では消えない。装置内部の soft state が timeout しても、pcap、flow export、incident ticket、backup に複製された記録は別の寿命を持つ。

RFC 9063 が匿名用 HI の頻繁な rotation を勧めるのも、linkability と trackability を崩すためである。HI rotation は endpoint policy であり、過去ログの deletion policy ではない。SPI、HI、ログの三つの lifecycle を一つにしてはいけない。

中間装置のための証拠設計

各 consumer について、読んだ field、必要とする機能、install rule、operator role、export 先、expiry、deletion evidence を登録する。共通 protocol が要求するのは一時的な mapping であり、無期限の分析利用ではない。

一つの rekey receipt には、sensor、方向、locator、必要なら保護された HIT reference、旧新 SPI、SEQ/ACK、HMAC と signature の結果、algorithm、policy version、soft-state timeout を含める。そこから先は別の receipt である。endpoint SAD に新 SA ができたか、新 SPI の packet が最初に authentication を通ったか、旧状態が消えたかを独立に記録する。

削除にも観測点が要る。firewall table の消滅だけで、外部 collector の複製まで消えたとは言えない。原本、派生 record、support 添付、processor copy の範囲を列挙し、それぞれの終了を確認する。

2008 年の実験を現在形で扱わない

RFC 5202 は 2008 年の Experimental 文書で、現在は obsolete である。held erratum は transform parameter に関する語句修正で、本論点を変えない。2015 年の RFC 7402 が HIPv2 向け Standards Track として置換した。

だからこそ、両方に同じ可視性条項があることが重要になる。古い algorithm set を現在の標準だと主張する必要はない。現行文書が、middlebox participation のために signed control metadata を読める状態にする設計を維持している。

経営判断

契約、architecture review、dashboard で四つの主張を分離する。payload confidentiality、control authenticity、metadata visibility、retention termination である。新 SA の実効性は五つ目の独立項目にする。

実装が露出する事実を先に置き、製品名の「secure」や「encrypted」を後に置く。最低限の相互運用に必要な可視性を認めつつ、目的外利用と保存を局所的に制限する。それが running code を象徴より優先する監査である。

情報源

  1. RFC 5202 HTML
  2. RFC 5202 text
  3. RFC 5202 information
  4. IETF Datatracker RFC 5202
  5. RFC 5202 history
  6. RFC 5202 references
  7. RFC 5202 errata
  8. RFC 7402 HTML
  9. RFC 7402 text
  10. RFC 7402 information
  11. IETF Datatracker RFC 7402
  12. RFC 7402 history
  13. RFC 7402 references
  14. RFC 7402 errata
  15. RFC 4303 — ESP
  16. RFC 4301 — IPsec architecture
  17. RFC 9063 — HIP architecture
  18. RFC 6538 — HIP experiment report
  19. RFC 6973 — privacy considerations
  20. Heng Lu — reality layers
  21. Heng Lu — minimum initial specification
  22. Heng Lu — running-code primacy