要約

  • RFC 9686は、端末がSLAACまたは静的設定で選んだIPv6アドレスをDHCPv6サーバーへ登録する経路を標準化する。RFC 9915の6.6節は、この自己生成アドレスについてサーバー側にleaseが作られることを記述するが、RFC 2119のMUSTを付してはいない。leaseはDHCPv6によるアドレス割り当ての証明でもない。
  • 登録は可観測性を高めると同時に、Client Identifier、IPv6アドレス、relayやリンク、認証情報などを結ぶ相関能力を生む。そのため、収集範囲、相関権限、対応権限を分離し、取得可能であることを結合や制裁の許可へ読み替えない統制が必要になる。
  • 有効なADDR-REG-REPLYを受けたクライアントは再送を停止しなければならない。しかしreplyが直接示すのは登録メッセージの受領であり、永続的保存、任意のリンク／プレフィックス検証の実施、アドレスの真正性、本人性、実際の通信利用、隔離や制裁の権限までは証明しない。
  • 相関結果を行動へ移すには、登録と独立したパケットまたはフローの利用証拠、独立した端末・加入者情報、適用方針、承認権限が必要である。Neighbor Cacheやアクセスポイントの文脈は接続関係を補強できるが、それ自体を実際のパケット／フロー利用証拠として扱うことはできない。

可観測性が増えると、結合可能性も増える

DHCPv6サーバーが割り当てたアドレスなら、サーバーは割り当て処理の中でクライアントとの関係を記録できる。これに対し、SLAACや静的設定で端末が選んだアドレスは、従来の割り当て記録には現れないことがある。RFC 9686はAddress Registration Optionを用い、この空白を埋める。

クライアントは機能の利用を要求し、インフラストラクチャ側がAdvertiseまたはReplyのOPTION_ADDR_REG_ENABLEで対応を示した後、所定の規則に従ってADDR-REG-INFORMを送る。能力信号がなければ登録してはならない。登録対象は有効な自己生成または静的IPv6アドレスであり、link-localアドレスは除外される。メッセージにはClient IdentifierとIA Addressが含まれる。

運用者にとって、これは障害解析やセキュリティ調査の死角を減らす。しかしプライバシー審査では、同じ機能を別の方向から見る必要がある。Client Identifierとアドレスの関係に、relay階層、受信リンク、スイッチポート、認証、RADIUS、資産台帳などを加えれば、接続行動を高い粒度で相関できる。その能力は正当な運用目的に役立つ一方、目的外監視、過剰保持、誤帰属の拡散にも利用できる。

したがって設計上の問いは「登録を有効にするか」だけではない。「何を収集するか」「誰が何と相関できるか」「その結果を使って何を実行できるか」を分けて決める必要がある。

三つの権限を分離する

第一は収集範囲である。これは、RFC 9686の処理に必要なClient Identifier、IA Address、valid lifetime、送信元またはrelay文脈、処理結果など、どの情報を取得・保存するかを定める。収集できる項目を無条件に最大化するのではなく、明示された運用目的ごとに必要性を示すべきである。

第二は相関権限である。登録データを、ファイアウォール、フロー、認証、RADIUS、ポート、資産管理、加入者情報と結合する権限を指す。各システムへ個別にアクセスできることは、それらを一つの人物像へ統合してよいことを意味しない。相関の目的、検索条件、実行者、結果の利用先を監査可能にする必要がある。

第三は対応権限である。調査開始、利用者への照会、端末隔離、通信遮断、資格情報の停止、懲戒手続きなどを実施する権限である。これは収集機能や相関機能から自動的には生じない。技術担当者がログを閲覧できても、利用停止を決定できるとは限らない。

権限層 中心となる問い 越えてはならない推論
収集範囲 どのプロトコル事実を何の目的で記録するか 収集可能だから恒久保存してよい
相関権限 どの情報源を誰がどの条件で結合できるか 技術識別子が一致したから人間が確定した
対応権限 誰がどの根拠で措置を承認できるか 相関結果があるから自動的に処分できる

この分離は処理速度を落とすためではない。誤った結合が複数システムへ伝播し、訂正困難な措置へ変わるのを防ぐためである。

規格が要求すること、勧告すること

ADDR-REG-INFORM内のIA Addressは、直接受信の場合には元メッセージのIPv6送信元と、relay経由の場合には最も内側のRelay-forwardにあるpeer-addressと一致しなければならない。矛盾するメッセージは破棄される。

サーバーは、登録アドレスが受信リンクに適切であるか、またはクライアントへ委任されたプレフィックス内にあるかを検証すべきである。この検証はSHOULDであり、標準があらゆる適合実装に例外なく実施を義務付けている、と表現するのは正しくない。一方、製品や運用方針がこの検証を常に実施することは可能であり、それによってRFC 9686のSHOULDがMUSTへ変わるわけでもない。

サーバーがこの検証を実際に行い、失敗した場合に限り、メッセージを破棄しなければならず、失敗を記録すべきである。監査画面で「検証せず」「検証して成功」「検証して失敗」を同じ空欄や真偽値へ潰すと、SHOULDの実装差を証拠の確度へ反映できない。

受理された登録は、記録を無効にする設定がない限り、ログに記録しなければならない。サーバーはClient-Identifier-to-address bindingを作成すべきであり、登録アドレスを他のクライアントへの割り当て対象外として印すべきである。また、ADDR-REG-REPLYを返さなければならない。

有効なADDR-REG-REPLYを受けたクライアントは、ADDR-REG-INFORMの再送を停止しなければならない。ただしreplyから、ログ記録が有効だったこと、バインディングが作成されたこと、リンク／プレフィックス検証が実施されたことは導けない。返信は保存完了証明や本人証明ではなく、通信利用や対応権限の証明でもない。

leaseとbindingを混同しない

RFC 9915の6.6節は、端末が選んだ自己生成アドレスの登録について、サーバー側にleaseが作られることを記述する。ただし、この記述にはRFC 2119のMUSTが付されていない。アドレス選択は端末側にあり、DHCPv6がそのアドレスを割り当てたわけではない。ここでのleaseは登録のライフサイクルを扱うサーバー側状態である。

これに対し、RFC 9686におけるClient-Identifier-to-address bindingの作成はSHOULDである。leaseが記録されていることと、期待する形式のbindingが存在することを同一視してはならない。さらに、bindingがあっても、それだけで対象アドレスが実際にパケットを送信したとは言えない。

データモデルでは、少なくとも次の状態を別項目として扱う必要がある。

  • アドレスの選択方法
  • サーバー側leaseの識別子と状態
  • Client-Identifier-to-address bindingの有無
  • リンク／委任プレフィックス検証の実施有無と結果
  • 受理、拒否、replyの各イベント
  • 独立した通信利用の観測
  • 端末、アカウント、加入者、人間への相関根拠

一つの「登録済み」フラグへ統合すれば、プロトコル処理と本人帰属の境界が消える。

更新情報を追跡信号へ変えない

SLAACアドレスでは、クライアントはvalid lifetimeの80％を基礎に0.9から1.1の分散を加え、NextAddrRegRefreshTimeを計算する。しかし初回登録時には、その計算だけでrefresh送信を予定しない。

その後、ネットワークから得るValid Lifetimeが1％を超えて変化した場合にrefreshを予定する。時間の経過に伴ってValid Lifetimeが通常どおり減少し、予想失効時刻が実質的に変わらないなら、refreshが送られないことがある。したがってnominalな80％時点を過ぎたのに新しい登録がない、というだけで障害、切断、端末消失を推論してはならない。

この性質はプライバシー設計にも重要である。登録更新を端末の周期的な在席信号として利用しようとすると、規格上予定されていない送信の欠如へ意味を付与することになる。SLAAC登録から導けるのは登録イベントとその条件であり、連続的な存在や利用ではない。

静的アドレスの4時間は、設定可能な登録更新間隔の既定値である。アドレスの寿命でも、leaseの寿命でもない。SLAACと静的アドレスでは更新規則が異なるため、同じ分析規則で「沈黙」を評価してはならない。

zero lifetimeは登録の失効を伝えるが、失効前の通信や失効後の不正利用を単独で証明しない。登録のライフサイクルと、ネットワーク上で実際に観測された利用は分離して扱う必要がある。

接続文脈と利用証拠の境界

RFC 6620のFCFS SAVIでは、binding anchorとして許されるのはスイッチポートだけである。SAVI bindingは、保護境界内で送信元アドレスとスイッチポートの関係を扱うが、その強さはアンカーを越えない。ポート配下に複数端末や中継機器が存在する場合、それだけで一人の利用者を識別することはできない。

Neighbor Cacheは、近隣解決に関する状態を提供する。アクセスポイント、SSID、無線コントローラーなどの情報は、接続文脈を補足し得る。しかし、これらは対象アドレスが問題の通信を実際に行ったことを示すパケットまたはフローの証拠とは異なる。

RFC 9099が挙げるアプリケーションログ、IPFIX、Neighbor Cache履歴、DHCPv6、SAVI、ポート、ファイアウォール、認証、RADIUSは、役割の異なる情報源である。それらを結合する際は、次の区別を保つ必要がある。

情報源 主に示すもの 単独では示さないもの
RFC 9686登録 Client Identifierと自己生成アドレスに関するクライアントの登録主張とサーバー受領 パケット利用、人間の本人性、許可、対応権限
SAVI アドレスとスイッチポートのbinding ポート配下の個人、通信内容、政策違反
Neighbor Cache 近隣解決の状態 問題となったパケットまたはフローの実利用
アクセスポイント文脈 無線接続環境や接続点 対象通信の生成
ファイアウォール・IPFIX 観測点を通過した通信またはフロー 登録者と操作者が同一であること
認証・RADIUS アカウントやセッションとの関係 端末を実際に操作した人間、通信の正当性

この表の列を越える推論には、別の証拠と明示的な判断が必要である。

最小収集と監査可能な相関

最小収集は、単に項目数を減らすことではない。目的に対して不要な精度、期間、識別子の安定性を持たせないことである。障害対応に短期のリンク情報が必要でも、同じ情報を人事上の分析へ恒常的に転用する必要はないかもしれない。

登録基盤には、少なくとも次の統制が求められる。

  • 収集目的ごとに必須項目と任意項目を定義する
  • ログ記録を無効化できる主体と変更履歴を監査する
  • リンク／プレフィックス検証の実施有無を結果と分けて保存する
  • Client Identifier、アドレス、ポート、認証情報の横断検索を役割で制限する
  • 相関検索の目的、照会条件、実行者、出力先を記録する
  • 自動処理へ渡す前に、登録情報と通信利用証拠を区別する
  • 目的を終えた識別子や相関表を削除または非識別化する
  • 誤帰属の申告、再調査、訂正、措置解除を追跡できるようにする

相関ログそのものも保護対象である。誰が何を検索したかという記録には、調査対象や組織の関心が表れる。閲覧権限、完全性保護、保存期間を、元の登録ログとは別に定める必要がある。

情報源