要約

  • RFC 3323 の匿名性は観察者ごとの性質であり、受信者から住所を隠しても、経路を代行するサービスや認証先は本人を知り得た。
  • critical は保護成功の印ではなく、実行不能なら要求を拒否するという失敗時の規則だった。

直接経路の限界

From に Anonymous と予約済みの匿名 SIP ドメインを使えば、再利用可能なアドレスを受信者へ見せずに済む。しかし Contact と Via は現在のダイアログを継続するための経路であり、SDP はメディアの送信先を示し得る。適当な偽値に置換すれば匿名になる前に通信が壊れる。

二つの端末が直接通信すれば、ネットワークアドレスは互いに見える。隠すには中継点が必要になる。プライバシーサービスは元の値を知り、外向きの値を書き換え、後のメッセージや媒体を戻す責任を引き受けた。受信者に対する匿名性は、サービスに対する匿名性ではない。

RFC 3323 は、宛先だけから隠す場合、中間者だけから隠す場合、両方から隠す場合を分けた。認証は少なくとも一者へ本人情報を示すことが多い。同じ通話が、ある観察者には認証済み、別の観察者には匿名でも矛盾しない。

ヘッダーは依頼書だった

Privacy の header は Contact や Via などの処理、session はセッション経路の匿名化、user は端末ができない利用者レベルの処理を要求した。トークンが存在しても、サービスの実装、設定、法的条件が処理を許した証拠にはならない。

文書は、要求が満たされない可能性を明記した。critical が付けば、満たせない要求は拒否すべきである。保護なしで転送することは、失敗ではなく意図の反転になる。none は反対に、既定値が匿名化を行う環境でも本メッセージへ適用しないよう命じ、仲介者による変更を禁じた。

サービスまでの経路

RFC は TLS などでサービスまで直接保護することを強く推奨した。手前で読まれれば、後でヘッダーを消しても漏えいは取り消せない。途中のプロキシが Privacy 要求を削除する可能性もある。証明書を確認できる短い経路は、その危険を減らした。

ただし TLS はサービス自身から情報を隠さない。メディア中継が相手から IP を隠しても、暗号化されていない媒体を中継者が観察し得る。宛先に対する位置プライバシーと、サービスに対する内容機密性は別々に検証しなければならない。

受信者とプロキシには、特定できない発信者を拒否する自由も残った。匿名を求める自由は受理を強制する権限ではない。RFC 3325 の信頼網内アイデンティティや後年の SIP Identity／History 文書は、観察者と信頼領域をさらに区別した。

RFC 3323 が残した設計規律は、匿名というラベルの背後に経路を保存することである。誰から隠したか、誰が元を知ったか、何を変えたか、実行不能時に閉じたか。それがなければ Anonymous は表示名にすぎない。

応答経路は後から差し込めない

SIP の応答は要求が通った経路を戻る。要求を受け取った側が、その時点から応答経路へ新しいプライバシーサービスを挿入することはできない。応答側の Contact や登録位置も隠したいなら、匿名コールバック URI、サービス経由の REGISTER、保護された持続接続などを前もって用意する必要があった。

これはプライバシーが表示上の後処理ではなく、経路設計であることを示す。最終メッセージだけが匿名化されていても、どのノードが要求を受け、どのノードが応答を返したかを保存しなければ、双方向の保護は証明できない。

ヘッダーとセッションは別の表面

From や Via を隠しても、SDP や媒体パケットの送信元は残り得る。反対に媒体リレーで IP を隠しても、Organization、User-Agent、Call-ID が発信者を示す場合がある。RFC 3323 が header と session を分けたのは、一方の成功を全体の成功に拡張しないためだった。

運用試験も同じ粒度を保つべきである。ヘッダー、シグナリング経路、媒体経路、認証ログを別々に観測し、それぞれについて隠す相手を記録する。「宛先からはネットワーク位置を隠したが、契約ドメインは利用者を認証した」という記述は矛盾ではない。むしろ、RFC が意図した証拠の形に近い。

Sources