要約

  • RFC 5372では、現在の主ヘッダーが失われ、非ゼロのmh_idが保存値と一致すると、受信機は以前の完全な主ヘッダーで復号を試みられる。一致は試行条件であり、ヘッダーの新鮮性証明ではない。
  • 三ビットの識別子は一から七までを再利用する。六回連続の更新を見失うと、古いキャッシュと新しい状態が同じ値を持ち得る。デコーダーの不整合検出は、その組み合わせが実行面へ入った後に起こる。
  • mhc交渉、完全なヘッダー受領、保存状態の来歴、補償判断、復号受理、出力生成、表示結果は別の証跡である。priorityは重要度を示しても配送を保証しない。

検出は選択の後に来た

RFC 5372の安全性に関する説明は、主ヘッダー補償の限界を具体的に示している。識別子は最大七種類の主ヘッダーしか区別できない。ランダムな損失でも意図的な損失でも、六回続く更新が見えなくなれば、受信機は誤った主ヘッダーで解凍を試みる可能性がある。

標準的なJPEG 2000デコーダーは、ヘッダーとpayloadの不整合を検出できる場合がある。そのときは保存したmh_idと主ヘッダーを消去することが推奨される。

この順序が重要である。検出器は、ネットワーク上の三ビット値を見ただけで古さを判定したのではない。受信機がキャッシュを選び、欠けたヘッダーの代わりに差し込み、デコーダーへ渡した結果として不整合が露出する。

したがって「不整合を検出できる」は「古い状態を使用前に拒否できる」と同義ではない。メモリーはすでに確保されたかもしれない。遅延予算は消費されたかもしれない。フレームは破棄され、一般的な復号エラーとして記録されたかもしれない。実装によっては、どの段階で異常を表面化させるかも異なる。

キャッシュ消去は将来の再利用を止める。失われた正しいヘッダーを生成するわけではない。回復の完了には、その後に完全な主ヘッダーを新たに受け取った証拠が必要になる。

同じ番号は同じ内容ではなかった

mh_idという名前は、値が主ヘッダーの永続的な身元を表すように見える。RFC 5372は、その解釈を明確に否定している。識別子と符号化パラメーターは一対一に対応しない。

フィールドは三ビットで、セッション開始時は一である。規定されたパラメーターがフレーム間で変わらない限り、送信者は同じ値を使う。パラメーターが変わり、新しい主ヘッダーを送るたびに値を進める。七を超えれば一へ戻る。

比較対象にはSIZと、COD、COC、RGN、QCD、QCC、POCの機能マーカーが含まれる。三ビット値の中にそれらの内容が入っているわけではない。値は送信者が観測した変化を短く伝えるだけで、バイト列のハッシュでも、無限に増える版番号でも、認証されたepochでもない。

受信側がmh_id=1だけを保存すると、座標は残るが対象物の来歴は失われる。必要なのはRTPセッションと同期送信源、完全なヘッダーを受け取ったsequence位置、値、実際のヘッダーまたはローカルな安定ハッシュ、保存時刻、以後に観測した遷移、消去理由である。

値の一致は、この来歴が連続している間だけ有用な推定になる。来歴に一周分の盲点があれば、同じ座標は別の状態を指し得る。

六つの欠落が古い状態を現在へ戻した

受信機が完全な主ヘッダーを値一として保存したとする。送信者の符号化パラメーターが変わり、新しいヘッダーと値二を送る。受信機はそれを失う。同じことが三、四、五、六、七まで続く。次の変更で値は一へ戻る。

現在値と保存値の比較そのものは正しい。だが、その間にあった六つの失われた更新が、古いキャッシュの権威をすでに消している。

一般的なpacket loss率では、この危険を説明できない。六つの通常データを失うことと、六回連続のパラメーター変更を失うことは違う。後者では、欠けたbytesだけでなく、キャッシュを無効化するはずだった出来事が消える。

攻撃者も最終値を偽造する必要がない。変更を知らせるヘッダーを選択的に落とせるなら、正しく巡回した一が古い一と衝突する。完全性保護は到着したpacketを守るが、到着しなかった遷移の存在を証明しない。

監視は損失量ではなく、損失の位置と役割を残す必要がある。完全な主ヘッダーの近傍で失ったか、七から一への巡回を連続して観測したか、保存ヘッダー以後に説明できないsequence gapがあるかを別々に記録しなければならない。

キャッシュは完全な受領から始まる

RFC 5372は、主ヘッダーを完全に受け取ったとき、RTP sequence number、mh_id、主ヘッダーを保存するよう受信機へ求める。保存するのは最後に完全受領した一つだけである。

フィールドを見たことと、再利用できるobjectを持つことは同じではない。最後のヘッダー断片が届いても、それ以前の断片が揃った証明にはならない。packet認証が成功しても、欠けたbytesは戻らない。SDPでmhc=1を受け入れても、キャッシュが自動的に満たされるわけではない。

実装は少なくとも次の状態を区別すべきである。

  • 完全な主ヘッダーをまだ一度も受け取っていない。
  • 完全な主ヘッダーを来歴付きで保存した。
  • 値の変更を見たが、新しい主ヘッダーは不完全だった。
  • 完全な新ヘッダーで以前のキャッシュを置き換えた。
  • 不整合によりキャッシュを疑わしい状態として消去した。
  • 新しい完全なヘッダーを再取得した。

すべてを「cache hit」「cache miss」の二値へ落とすと、権威が生まれた時点も失われた時点も見えなくなる。

ゼロは補償をしないという状態だった

mh_id=0には特別な意味がある。受信機は、その値の主ヘッダーを保存してはならず、失われたヘッダーを補償してもならない。

ゼロは先頭の通常IDではない。欠損値でもwildcardでもない。キャッシュ機構から明示的に降りる状態である。

収集基盤がゼロをnullへ変換し、後段が直前値で補完すると、protocolの判断が逆転する。観測では、拡張が非対応、mhc=0で拒否、拡張中にmh_id=0を受信、非ゼロだが完全キャッシュなし、非ゼロ一致後に失敗、という状態を分けなければならない。

どれも補償をしない結果になり得る。しかし理由と責任は異なる。

mhcは能力を合わせ、キャッシュ内容までは合わせなかった

RFC 5372はvideo/jpeg2000へmhcparameterを追加する。offerで一を提示し、受け入れるanswerはその機能を示す。例には、色空間やpriority方式を受け入れながら主ヘッダー補償をゼロで拒否する応答もある。

交渉が証明するのは共通methodである。完全なヘッダーが後に到着したか、どのbytesを保存したか、巡回をまたいで新鮮だったかは証明しない。

同じofferを受け入れた二台の受信機でも、一台は最新の完全ヘッダーを持ち、もう一台は初期ヘッダーを失い、三台目は不整合後に消去済みかもしれない。SDPの一行から三台のruntime stateを推定できない。

交渉記録は正確なRTP文脈へ結び付け、キャッシュeventも同じsession coordinateを持たせる必要がある。再交渉、source変更、payload type変更、再起動を越えて古いcacheが権威を継承してはならない。

復号受理と画面出力は別だった

補償された入力をデコーダーが受け入れても、期待された画像が生成された証明にはならない。画像が生成されても、下流へ届いた証明ではない。表示surfaceが必要なら、その観測はさらに後ろにある。

運用記録は次を分けるべきだ。

  1. 識別子が一致した。
  2. 受信機が補償を選んだ。
  3. デコーダーが入力を受理した。
  4. 不整合を報告せず処理を終えた。
  5. output frameを生成した。
  6. applicationまたは表示系がそれを受け取った。

前段の成功は後段のreceiptではない。特に「errorなし」は、正しい見え方を直接観測したことと同じではない。

失敗の帰属もこの順序に従うべきである。古いcache選択が原因なのに、エラーを最後に検出したdecoderだけへ責任を置くと、補償側の指標は改善し続け、実際のリスクが別部署へ移る。

priority zeroは配送済みという意味ではない

もう一つの拡張は八ビットのpriorityである。主ヘッダーまたはtile-part headerを含むpayloadはゼロを使う。数値が小さいほど重要で、一から255まで重要度が下がる。

packet-number方式は必須のdefaultで、progression、layer、resolution、component方式はoptionである。ptparameterが対応表を提示し、answerで一つを選ぶ。

この値はcodestream内の重要度を表す。帯域予約、queue admission、配送保証、decode admission、表示品質を表さない。priority zeroの主ヘッダーも失われ得る。分類が正しいことと、ネットワークがその分類を実行したことは別である。

一つのRTP payloadに複数のJPEG 2000 packetを詰める場合、最小の数値、つまり最も高い重要度を使う。この集約値も、含まれる全要素が利用されたことを証明しない。

mh_idのゼロとpriorityのゼロも混同できない。前者は保存・補償を禁止し、後者はheader-bearing payloadの重要度を示す。同じ表記でもauthority surfaceが違う。

multicastでは同じbitsが同じ意味を持たない

RFC 5372はRFC 5371に対する任意拡張である。基礎仕様だけを実装するreceiverはmh_idとpriorityを安全に無視する。multicastでは一部のmemberが未対応でもsenderは拡張を使える。

同一packet captureを見ても、受信機ごとに実行が違う。一台はheaderを保存して一致を判断し、もう一台はfieldへ意味を与えない。一台は選択されたpriority tableで取捨選択し、別の一台はそうしない。

senderがfieldを設定したという事実から、group全体の補償成功を宣言してはならない。受信機のcapability、交渉、cache event、decoder resultを個別に持つ必要がある。

互換性は共通transportを可能にする。共通の観測や共通の画面結果までは保証しない。

事前に拒めないなら、判断の来歴を残す

三ビットfieldだけで巡回aliasを完全に防ぐことはできない。そこで必要になるのが、判断を後から説明できる証拠である。

補償前に、active session、source、mhc交渉、非ゼロ値、完全cacheの存在、保存sequence、header hash、過去の不整合、説明不能なgapを確認する。補償時には選択したobjectと現在packetを結び付ける。補償後にはdecoder result、cache clear、再取得、outputを同じeventへ関連付ける。

local policyはより厳しくできる。古いcacheをtime outする、長いgap後は完全なheaderを要求する、説明できない巡回後は補償を止める、連続不整合後に機能を一時停止する、といった選択である。これらは組織のrisk controlであって、RFCが直接命じたと装ってはならない。

不整合検出は価値がある。その価値を誇張しないことも同じくらい重要である。それは誤った状態が試されたことを知らせるreceiptであり、最初から正しい状態だったというcertificateではない。