要約

  • RFC 5124は、AVPFのフィードバック機能とSAVPの安全処理をSAVPFとして組み合わせた。
  • SAVPとSAVPFのエンティティは、同じ安全なRTPセッションに参加できる。
  • AVPとAVPFも非安全なセッション内で共存できるが、安全系と非安全系を同じRTPセッションに混在させてはならない。
  • 共存できることは、全参加者が早期フィードバックを生成できることを意味しない。
  • AVPFが送信時刻を決め、SAVP層がSRTCPのフィールドと暗号処理を追加する。
  • RFC 5124が説明する追加分はおおむね10～20バイトで、既定例は14バイトである。
  • 実装は保護後の寸法をavg_rtcp_sizeへ反映しなければならない。
  • N <= B*T/Rでは、平均寸法Rが増えるほど同じ期限内に報告できる事象数が減る。
  • SAVPFの選択は、鍵確立、SRTCP受理、期限内到着、送信側の動作、映像回復を証明しない。
  • 安全・非安全候補を同時に提示する場合、選択信号自体を降格攻撃から守る必要がある。
  • 交渉はメディア記述ごとであり、一つの成功を通話全体へ拡張してはならない。
  • 運用はセッション、メディア、プロファイル時代、鍵時代を明示し、結果を段階別に保存すべきである。

「同じセッション」の内側にある差

ある参加者はSAVPFを使い、損失を検出すると早期RTCPフィードバックを送る。別の参加者はSAVPで安全なメディアと通常のRTCPを扱えるが、AVPFの早期機能を持たない。RFC 5124は、この二者が安全側の同じRTPセッションに混在し得るとしている。

ここで「安全なセッション」という表示は正しい。しかし「全員が同じ修復能力を持つ」という表示は誤りになる。相互運用境界はワイヤ形式の家族をそろえるためのもので、機能均質性の証明ではない。運用台帳には、各SSRCや参加者がどのプロファイル機能を使うか、どの種類のフィードバックを生成・理解できるかを残す必要がある。

非安全側でもAVPとAVPFは共存できる。一方、AVP/AVPFとSAVP/SAVPFという二つの家族を同一RTPセッションに混ぜてはならない。RTPとSRTPは、そのように互換な代用品ではないからだ。異なるRTPセッションで異なるプロファイルを使うことはできる。この粒度を製品単位の「対応済み」に縮約すると、故障説明が消える。

上層の時間、下層の保護

RFC 5124の構造では、AVPFがRTCPフィードバックの形式と送信タイミングを扱う。SAVP層は、そのパケットが予定された後にSRTCP処理を施す。AVPFの機能は暗号化や完全性保護の有無によって書き換えられない。SAVPF下のRTCPはすべてRFC 3711のSRTCPとしてカプセル化される。

層が分かれていても資源は共有する。SRTCPはインデックス、認証タグ、場合によってはMKIなどを加える。RFC 5124の想定では追加分は少なくともおおむね10～20バイト、既定例は14バイトである。将来の変換や設定された長さによって増減し得る。

そこで規範はavg_rtcp_sizeの更新を要求する。AVPFのスケジューラが保護前の小さいパケットを仮定すれば、実際には使えない送信機会を計上してしまう。暗号保護は帳簿の外にある無料の装飾ではない。

RFC 4585の概算N <= B*T/Rは、平均パケットサイズRと期限Tの関係を示す。RTCP帯域Bが同じなら、Rが大きくなるほど期間内に報告できる事象数Nは少なくなる。保護が正しくても、Immediate Feedbackの余裕は減る。

三つのモードを一つのフラグにしない

Immediate Feedbackでは、各受信者が価値ある事象をほぼ直ちに報告できる余裕がある。Early RTCPでは全件は無理だが、選ばれた報告が送信側の適応に間に合う。Regular RTCPでは、集団規模や時間尺度のため個別事象のフィードバックが有効でなくなる。

境界は固定の人数ではない。帯域、パケット率、損失分布、コーデック、報告頻度、平均寸法が影響する。同じ参加者数でも、認証タグやMKIの変更によって余裕が変化する。セッションが切断されないため、単純な稼働監視はこの移行を見逃す。

RFC 4585のT_max_fb_delayは、フィードバックが役に立つ最大遅延をアプリケーションごとに表す。RFC 5124は一律値を保証しない。認証済みNACKが期限後に到着すれば、暗号学的には成功し、修復制御としては失敗し得る。

さらに到着だけでは回復を証明しない。送信側が再送できない、適応を選ばない、再送が失われる、デコーダの参照状態が戻らない、といった段階が残る。イベント、予定、送信、受理、動作、媒体到着、復号、表示を別々に記録しなければならない。

プロファイル名より細かい安全性

RFC 3711のSRTP/SRTCPは機密性、完全性またはメッセージ認証、リプレイ保護を提供できる。SRTCPの完全性は必須だが、暗号化は独立した設定でありNULL暗号も存在する。従って、SAVPFの成立だけで制御内容の機密性まで断言できない。

グループ鍵を共有する構成では、有効なタグが「鍵を持つ集合の誰か」を示しても、単一の送信元を識別しない場合がある。RFC 3711も、この状況で認証という語が実質的に完全性を指すことを注意している。運用表示は実際の鍵モデルに合わせるべきである。

受信側の判定には、アルゴリズム、セッション鍵、マスター鍵、SRTCPインデックス、リプレイ窓、鍵の有効期間とMKIが関係する。SDPのRTP/SAVPF文字列は、その実行結果ではない。設定が合っていても、古い鍵時代のパケットは拒否され得る。

選択を守らなければ後段の保護は届かない

安全プロファイルと非安全プロファイルを同じ提示に置くと、bidding downなどの攻撃面が生まれる。RFC 5124は、その場合に交渉信号を適切に保護するよう求める。安全な候補を先頭に置くことは方針であって、改ざんされなかった証拠ではない。

SRTCPが働くのは選択と鍵確立の後である。攻撃者がその前のSDPから安全候補を除けば、後段の認証タグは元の提示を復元できない。提示、順序、属性、応答を覆う完全性の証跡が必要になる。

一つのメディア記述ではAVP、AVPF、SAVP、SAVPFは排他的である。SAVPFを理解できない応答側はそのメディアを拒否する。提示がSAVPFでないのに応答側がSAVPFを望む場合も、いったん拒否し、後の提示で提案できる。黙って変更して合意と呼ぶことはできない。

メディアごとの交渉と再構築

音声が成功し、映像が失敗することは規格上あり得る。一つの通話状態に丸めると、部分成功も部分失敗も説明できない。各m=行、RTPセッション、輸送先、選択プロファイル、鍵管理方式を結び付ける必要がある。

RFC 5124が説明するRTSP手順では、クライアントがSETUPで受信したい各ストリームについて一つのプロファイルを選び、サーバーが確認または拒否する。当時の手順でプロファイルを変更するには、TEARDOWNして再びSETUPする。これはライブ設定の上書きではなく、旧状態を終え、新しい輸送と鍵を立ち上げる継続性イベントである。

SAP、電子メール、ウェブページのような非対話配布には応答がない。開始者が適切な代替と安全なアクセスを用意する責任を負う。RFC 4568のinline鍵を機密性のない経路で送れば、媒体開始前に鍵が見える。SRTCPは漏れた配布経路を後から直せない。

RFC 8866は後に旧SDP仕様を、RFC 7826は旧RTSP仕様を置き換えた。RFC 5763/5764はDTLS-SRTPを後に標準化した。これらは文書史であり、RFC 5124の更新や現在の導入率を示すものではない。

RFC Editorの記録はRFC 5124を2008年2月のProposed Standardとし、更新・廃止関係を列挙していない。凍結資料には現在の製品名、導入数、障害、相互接続試験や品質測定がない。本稿はその空白を推測で埋めない。

情報源