要約

  • RFC 7844は匿名アドレスではなく、DHCPクライアントの匿名性プロファイルを定めた。DUID、IAID、過去のアドレス、Server Identifier、FQDN、class optionを同じリンク境界で扱う。
  • 名前がなくても、要求するオプションの組合せと順序が実装のfingerprintになる。要求を最小化して順序を変えるのは、privacy mode自体を珍しい印にしないためである。
  • 協調した忘却は継続性を失わせる。古いleaseが残り、poolやbinding tableの負荷が増え、登録済み端末だけを許すネットワークでは接続を断られることもある。DHCPの相関を減らすことと不可視になることは別である。

新しいアドレスに古い記憶が付いてきた

アドレスはpacket captureで見つけやすい。そのため、値が変わると観測者との関係まで切れたように感じる。RFC 7824は、DHCPのどの情報がその境界を越えて残るかを洗い出した分析文書である。

DHCPv6のDUIDはserverに対してclientを表し、IAIDはclient内部のidentity associationを区別する。Client FQDNはhost名を伝え得る。User Class、Vendor Class、vendor固有情報は用途や実装を示す。Option Request Optionには必要な設定の集合が並ぶ。以前のアドレスをhintとして提示すれば、前の接続との関係も明示される。

一つ一つが世界で唯一である必要はない。長く変わらないDUIDと珍しいoption setが重なれば、二回の接続を結ぶ材料になる。link-layer addressを含むDUIDなら、無線アドレスのrandomizationを直接打ち消す場合さえある。実名を知らなくても、「同じ端末らしい」という相関は成立する。

Huitema、Tomek Mrugalski、Suresh Krishnanは2016年のRFC 7844で共通profileを提示した。目的は、利用者が匿名性を選んだときにDHCPが追加する手掛かりを減らすことだった。共通であることにも意味がある。各OSが独特のprivacy動作をすれば、その差異が新しいfingerprintになるからだ。

DUIDの安定性にも終点がある

通常の運用では、安定したDUIDは便利である。serverは戻ってきたclientを認識し、leaseやpolicyの連続性を保てる。しかしlink-layer identityを変えた後も古いDUIDを送れば、匿名性profileでは同じ安定性が相関の橋になる。

RFC 7844はDHCP identifierの寿命をlink changeに合わせる。randomなlink-layer addressを採用したなら、関連するDHCP identityだけが以前のまま生き残ってはならない。link-layer randomizationを使わない関連ケースについても、randomized DUID-LLTの扱いを定める。

2026年に現在のDHCPv6基本仕様となったRFC 9915は、DUIDを通常は安定させる一方、RFC 7844に基づく変更を明示的に認めている。これは矛盾ではない。service continuityを求める契約と、相関を切るための契約で境界が異なる。

IAIDも永久のmachine signatureにしてはならない。必要な安定性は現在のlink-layer associationの中に限られる。「安定しているか」だけでは監査にならない。どの変更をまたぎ、誰のために安定するのかを問う必要がある。

過去のアドレスhintはtrade-offをよく示す。以前のアドレスを再取得できれば便利だが、その要求は以前の接続を告白する。profileはlink-layer addressの変更時に保存アドレスを捨てる。切断と再会を同時に最大化する方法はない。

順番だけでも実装は見える

RFC 7824は明示的なidentifierとfingerprintingを分けて考える。DHCP clientは同じoptionを同じ順序で要求するわけではない。集合と順序がOSや実装系統の特徴になり、名前のないmessageから継続性が推測される。

RFC 7844の対策は控えめである。必要な最小集合だけを求め、順序を変え、cacheに残る古い値を惰性で再送しない。User Class、Vendor Class、vendor固有情報、Client FQDNも原則として避ける。localだけで必要なFQDNはあり得るが、linkを越えて持ち歩く名前にしてはならない。

さらに「匿名性を希望する」という専用flagを作らない。privacyを望むclientだけを小さな群として宣言すれば、blockingや監視はむしろ容易になる。普及の少ないtemporary-address optionも同じ問題を持つ。機能名がprivacyらしいことと、wire上で目立たないことは一致しない。

最小の共通仕様は、clientに多くを語らせない。漏れる量と実装差を減らし、profileを使う将来の判断は利用者に残す。

DHCPの外側は残る

RFC 7844はradio fingerprintingをscope外と明記する。hardware特性、traffic timing、application account、他protocolは別の観測面である。この限定があるから、profileが何を減らしたかを実測できる。

server側の費用も消えない。戻ってきたclientを認識できなければ、以前の割当てを期限まで残し、新しいidentityに別の状態を作ることがある。変更頻度が高ければaddress poolやbinding tableを消費する。事前登録したlink-layer addressだけを認めるnetworkは接続を拒否できる。stateful serviceの継続性も失われ得る。

これらは直ちにprofileの失敗を意味しない。serverはstateの節約を望み、admission systemは安定したhandleを望み、利用者は二回の訪問を結ばれたくない。仕様は選択を利用者に残し、相反する目的を隠さない。

Huitemaが示したのは約束の範囲だった

IETF profileは、Christian Huitemaの長い標準化活動と、Microsoft退職後のprivacy、QUICの仕事を記録する。本人の経歴ページにはtransport、naming、securityと情報流通への関心が並ぶ。ただしRFC 7844は共同成果である。MrugalskiとKrishnanが共著者であり、RFC 7824の分析にもDHCP communityの蓄積がある。

歴史的に残るのは、複数の小さな値を一つのidentity surfaceとして点検する方法である。全項目を列挙し、同じ境界で変更し、running implementationが本当に採用したかをcaptureとlogで確かめる。RFCの存在だけでは実行を証明しない。

identifierは人ではなく、所有権でもない。あるpolicyの下で発行されたreceiptである。Huitemaらのprofileは、そのreceiptを適切なscopeで読み、利用者の目的から外れた境界へ持ち越さないことを求めた。

出典