要約

  • RFC 3323 のプライバシーは、特定の相手に情報を見せないという選択であり、SIP 要求から識別情報を一切なくす保証ではない。
  • ヘッダーを隠すサービスは、対話の経路状態を保存して後で復元する場合がある。信頼の境界は消えるのではなく、そのサービスへ移る。

匿名とは、誰から見て匿名なのか

2002 年の SIP において、プライバシーは「実名」か「匿名」かという単純な二択ではなかった。RFC 3323 は、対話に参加する一人または複数の相手から情報を隠すこととして説明する。発信者は相手に本名を見せず、信頼するサービスには識別情報を明かすことができる。別の構成では、利用者からネットワーク情報を隠す。まず問うべきなのは「誰に対して匿名なのか」だ。

匿名の From 値は、要求に有効なアドレスを含めてはいけないという意味ではない。仕様は匿名 SIP URI に anonymous.invalid を推奨する一方、同じ対話内の後続要求が相手の端末へ届くことも必要とする。個人の識別情報を隠しながら、Contact、Via、Record-Route やセッション情報を残す場合がある。ここでのプライバシーは、プロトコル状態の見せ方を制御することであり、状態そのものの消去ではない。

隠すサービスは、内容を記憶しなければならない

RFC 3323 は利用者側のプライバシーとネットワーク側のプライバシーを分ける。Privacy ヘッダーには user、header、session などがあり、none はサービスにプライバシー処理をさせず、critical は要求された保護が提供できない場合に要求を失敗させる。これは方針の指定であり、認証、認可、メディア暗号化、または全中継点の遵守を証明するものではない。

ヘッダーのプライバシーには運用上の代償がある。サービスは B2BUA として識別情報を含むヘッダーを削除・書き換え、Contact を自分のアドレスに置き換え、元の経路情報をローカルに保管できる。後続メッセージが戻ると、対話を続けるのに必要な値を復元しなければならない。相手に見える情報は減る一方、サービスはより多くの特権的状態を持つ。発信者はそのサービスから匿名ではない。

セッションのプライバシーにはさらに、B2BUA とメディア中継またはトラフィック匿名化が必要となる。サービスが通信経路の一部になるため、RFC 3323 は SRTP などのエンドツーエンド保護なしでこの方式を使うことに慎重だった。これは設計上の注意であり、導入状況の統計ではない。

識別情報を隠すと新しい制御点ができる

この RFC の歴史的な論点は、相手が知る情報を減らすほど、隠蔽を実行するコンポーネントへの依存が高まるという緊張関係だ。サービスは削除、保持、書換え、復元を判断し、対話の継続に必要な状態を預かるため、信頼されなければならない。

RFC 3261 は SIP の対話とルートセットの前提を定める。RFC 3325 は信頼されたネットワーク内の Asserted Identity を扱うが、信頼ドメイン間の一般的なモデルは定義しない。両者は隣接する境界を扱うのであり、万能なプライバシー解ではない。RFC 3323 も普及や相互運用を証明しない。記録されたのは、相手に見せる情報を減らしながら通話に必要な状態を保ち、その交換条件を担う中継サービスを明示する設計判断である。

出典