要約

  • History-Info は、対応する中継ノードが公開した Request-URI の変化を保存する。点区切りの hi-index は分岐木を表し、rc、mp、np はそれぞれ同一対象ユーザー内の変更、別の対象ユーザーへの写像、Request-URI を変えない次ホップ変更を示す。
  • 拡張は任意であり、旧形式、推定された欠落、未完了の分岐、プライバシーによる匿名化があり得る。TLS/SIPS は経路外の攻撃者を抑えるが、信頼された中継者が履歴を書き換えないことまでは保証しない。
  • 説明責任を果たすには、履歴に加えて、実行した規則、その所有者、参照データ、分岐状態、プライバシー処理、下流トランザクション、実際のサービス結果を結び付ける必要がある。

「転送済み」という一語が消したもの

ある企業の代表番号には、営業時間外だけ社内当番へ転送する規則があるとする。月曜の昼、顧客が未知の外部事業者へつながった。監査画面には、代表番号から部門アドレス、外部アプリケーションまで、整然とした History-Info の木が表示されている。索引の構文は正しく、最後の宛先は成功応答を返した。画面は「転送済み」と結論する。

しかし、知りたいのは転送が起きたかだけではない。誰が時間条件を変更したのか。どのディレクトリ値を使ったのか。外部事業者は承認済みだったのか。並行して呼び出された社内分岐はあったのか。プライバシー境界で何が隠されたのか。相手は音声を受け、契約どおりの業務を行ったのか。

経路の木は、観測地点に届いたメッセージが語る宛先の変化を示す。それ以上の問いには、別の証拠が必要である。

RFC 7044 は、初期要求またはダイアログ外要求について、通常なら Request-URI の更新で失われる履歴を保持する任意拡張を定義する。この限定された役割を守ることが、履歴を信頼できる証人にする。

ルーティングが成功すると、以前の宛先は消える

RFC 3261 のプロキシは、ロケーションサービス、リダイレクト、Route 情報、ローカル方針などから次の宛先を決める。Request-URI を更新して送れば、次のノードは現在の目標を知る。一方、更新前の目標は通常の要求だけでは失われ得る。

RFC 7044 は、対象決定規則に従って Request-URI を変え、要求を転送する行為をリターゲティングとして扱う。History-Info は、その結果を後続ノードに残す。

ここで主体を取り違えてはいけない。実際に次の URI を選んだのは、稼働中のプロキシ、PBX、B2BUA、またはアプリケーションである。RFC は記録形式を定めた。IANA の SIP パラメータ登録簿 は History-Info、histinfo、history、rc、mp、np を登録した。登録簿は、ローカル規則を承認した機関ではない。

対象は初期要求とダイアログ外要求である。確立後のダイアログ内信号、メディア、録音、課金、担当者画面までを History-Info が追跡するわけではない。SIP の招待経路と、利用者が受けたサービスの全履歴は別物だ。

索引は樹形を示し、時刻を示さない

各エントリーには、対象 URI と hi-index が必要である。索引は非負整数を点で連結する。子は親の索引を延長し、フォークは同じ親を持つ兄弟になる。送信順は先行順走査であり、受信側はそこから木を再構成できる。

この構造は平坦な一覧より優れている。二つの並行呼び出しを、連続する二回の転送と誤認しにくい。しかし、索引は時計ではない。数字から遅延は分からず、別々のノードがいつ判断したかも証明できない。後ろの兄弟が後から完了したとも限らない。

エッジの意味を補うのが三つのパラメータである。

  • rc は Request-URI が変わっても対象ユーザーは同じだと挿入ノードが判断した場合を示す。AoR から登録 Contact への解決などが該当する。
  • mp は別の対象ユーザーまたは別の AoR へ写像したことを示す。
  • np は Request-URI を維持したまま次ホップだけを変えたことを示す。

これらは動作分類であり、権限判定ではない。同じ利用者と分類された二つの URI が、契約上も同じ責任主体だとは限らない。別利用者への写像が正しく記録されても、その写像を行う権限は別途必要である。次ホップが記録されても、その運用者の信頼性までは証明されない。

欠落を不正と決め付けてはいけない

History-Info の対応は任意である。histinfo は Supported で通知され、全ホップに参加を強制するための Require や Proxy-Require には使われない。非対応装置を一つ通るだけで、可視の履歴には空白が生じる。

旧仕様の RFC 4244 に基づくエントリーも残り得る。RFC 7044 は旧エントリーを転送するよう求める一方、観測していない過去の判断に rc、mp、np を後付けすることを認めない。パラメータがないことは、リターゲティングがなかった証拠ではない。

受信した Request-URI が最後の履歴エントリーと一致しない場合、受信者は直前のノードに代わってギャップ用エントリーを加える。確実に言えるのは「どこかで対象が変わった」という点だけだ。どの規則だったかは見ていないため、機構パラメータを付けない。この不確実性を残すことが正しい実装である。

フォークも完全性を難しくする。RFC 7044 の例では、一方の分岐が 200 を返した時点で、もう一方はまだ応答していない。成功応答に、未到来の分岐結果を入れることはできない。勝者側だけを収集したシステムは、妥当だが網羅的ではない木を持つ。

RFC 4244 のプライバシー例では、上流から隠された分岐が既に試されたことを上流が知らず、同じ宛先を再試行する可能性が示される。これはプライバシーを否定する理由ではない。部分情報を前提にした安全な既定動作が必要だという理由である。

Reason は応答理由であって、組織の動機ではない

History-Info の URI headers 部には Reason 情報を含められる。RFC 3326 は SIP や Q.850 の原因値を定義し、複数の名前空間を許す。RFC 7044 は、失敗応答やタイムアウトの文脈を履歴へ加える。

忙しかったため次へ進んだ、応答がなく 408 相当になった、という枝の説明には有用である。ただし、Reason は人間の意図、転送規則の正当性、契約上の理由、障害の根本原因を証明しない。完全性保護がなければ改変や削除も可能なので、値だけでなく、どのメッセージをどこで観測したかを残す必要がある。

RFC 7044 の errata には、Reason を付与する応答クラスに関する技術的指摘、ギャップ索引に関する指摘、節番号に関する指摘が Reported として登録され、ほかに Rejected が二件ある。Reported は Verified ではない。相互接続試験の論点にはなるが、規範本文を置き換えるものではない。

プライバシーは意図的に履歴を縮める

Request-URI の履歴は、個人端末、別名、社内部署、ボイスメール、ネットワーク構成を明らかにし得る。RFC 3323 が中継型プライバシーを必要とするのは、プロキシ自身が経路情報を追加するからである。

RFC 7044 の Privacy: history は、履歴全体または特定エントリーの保護を可能にする。受信要求が privacy none でも、ドメインは内部経路を隠せる。UAS は発信者に最終到達先を見せないこともできる。境界のプライバシーサービスは URI を anonymous.invalid 配下の匿名値へ変換できる。

これは正当な処理であり得る。匿名化されたからといって、直ちに悪意ある削除とは言えない。ただし、下流が立証できる範囲は小さくなる。誰が、どの方針で、どの項目を変換したか、権限を持つ監査者向けの保護された対応表があるかを別に記録すべきである。

対象を選ぶ権限と、対象を隠す権限も分離しなければならない。「経路を正規化した」という一イベントにまとめると、どちらの決定も追跡できなくなる。

TLS は信頼された編集者の列を守る

RFC 7044 は TLS を強く推奨し、それ以外では安全な環境を前提とする。SIPS は、信頼モデルの範囲で経路外の第三者による改変を防ぐ。しかし、経路内の中継者は履歴を読み、追加し、場合によってはプライバシー変換を行う。

悪意ある、または侵害された中継者はエントリーを削除、並べ替え、書き換えられる。RFC 7044 は、そのような中継者による改変をこの仕組みが防止・検出しないと明記する。

従って「SIPS を使った」は「エンドツーエンドで履歴が証明された」と同義ではない。各観測点で TLS ピア、証明書結果、信頼ドメイン、メッセージ指紋を保存し、重要な境界の両側で照合する必要がある。

アプリケーションが必要な部分を選ぶ

RFC 7044 は、履歴が欠ける場合の既定動作を各アプリケーションに定義させる。すべての用途に共通する「正しい一行」はない。

企業 PBX と一般利用者向けボイスメールは、着信者を推定するために別の rc 位置を使い得る。企業へ入る前に転送されていれば、単純に最初の rc を選ぶ規則は社外の利用者を社内対象と誤認する。RFC 4458 でも、ボイスメール向け target や cause の情報が、対応状況と経路により現在の Request-URI または History-Info に現れることが示される。

アプリケーションは目的、信頼するドメイン、欠落時の扱い、プライバシー、競合するエントリーの選択規則を公開すべきである。共通仕様を薄く保ち、将来の通常判断を当事者へ残すという Heng Lu の原則に沿う。ただし、ローカル規則を隠して「プロトコルがそう判断した」と説明してはならない。

争いに耐える決定記録

まず、受信・送信 Request-URI、メソッド、Call-ID、CSeq、Via branch、時刻、観測地点、ヘッダー指紋を保存する。

次に、受信した木と送信した木を別々に保存する。順序、hi-index、URI、rc/mp/np の参照、Reason、プライバシー、旧形式、解析結果、代理挿入したギャップを含める。欠けた機構を推測で埋めない。

第三に、実際の対象決定を記録する。規則 ID と版、ロケーション照会やリダイレクトの入力、候補、選択先、フォールバック順、分岐生成、サービス ID、テナント、管理者、承認、適用期間である。

第四に、信頼とプライバシーを記録する。入出力ドメイン、TLS ピア、変換者、適用方針、保護された対応表、閲覧権限、保持期間を分ける。

最後に、各分岐の応答、タイムアウト、CANCEL、勝者、B2BUA の上流・下流レッグ対応、ダイアログ、メディア、アプリケーション、録音、課金、苦情結果を結ぶ。

矛盾を消してはいけない。勝者の木に既知の兄弟がない、rc の同一利用者判定がテナント境界と食い違う、Reason とアプリログが一致しない、B2BUA の木は正しいがレッグ表がない、200 なのに音声がない。これらは、どこで説明責任が途切れたかを示す。

情報源