要約

  • RFC 3408は、RモードのR-0だけを無ヘッダーパケットへ置き換え、失われる種類識別と順序情報を補助層が別経路で供給できる場合に限った。
  • 順序の復元を保証できなくなれば、補助層はSN_breakを記録して無ヘッダー送信を止め、その境界を越える更新が確認されるまで再開できなかった。

出発点は圧縮率の競争ではない。RFC 3243が扱った古い無線インターフェースには、利用できるパケット長が段階的に決まるものがあった。音声ペイロードに1オクテットのROHCヘッダーを加えただけで、より大きな物理パケットが必要になる。そのためゼロバイト圧縮は、一般的な最適化ではなく、特定のアプリケーションとリンク特性が一致するときの対策だった。

RFC 3242はまずUモードとOモードでヘッダーを省く仕組みを定義した。ただし、ヘッダーが担っていた意味まで削除したわけではない。受信側はNHPと通常のROHCパケットを区別し、順序を維持し、リンク上で失われた各パケットを知る必要がある。これらを補助層が提供しなければ、短くなったペイロードは解釈できない。

RFC 3408はその条件を信頼型のRモードへ移した。対象はR-0だけである。受信側は最後に安全と確認されたRTPシーケンス番号を基準にし、そこへオフセットを加えてNHPの番号を再構成する。重要なのは、標準がオフセットの作り方を普遍化しなかった点だ。リンク技術ごとの文書が、観測可能な導出方法を定めなければならない。

ある実装は、最後のコンテキスト更新以降に届いた非更新パケットと損失通知を数えられる。別の実装は、リンクの時刻とRTPシーケンスの線形対応を維持できる。どちらも、存在しないヘッダーの値を推測する話ではない。別の証拠源から同じ位置情報を再構成する話である。

この依存関係は補助層に停止権限を与えた。コンプレッサーがNHPを許していても、補助層が正しい復元を保証できなければ「unsafe」である。補助層はその時点の番号をSN_breakとして保存し、NHPを止める。通常の安全条件が戻るだけでは足りない。最後に確認されたSN_ACKedが境界より先へ進んで初めて再開できる。

次の自然なコンテキスト更新を待つと、最悪の場合は長時間ゼロバイト経路を使えない。そこでRFC 3408は、補助層からコンプレッサーへ更新を求める任意インターフェースを推奨した。要求が不可靠な内部経路で失われても、起きるのは効率回復の遅延である。失われた要求を、安全条件の免除に読み替えることはできない。

Rモードでは、NHPも損失通知もコンテキストを更新しない。R-0にはもともとCRCがないため、U/Oモードで必要になったCRC機能の代替も不要だった。6ビットの番号が周回するときのR-0-CRCが周期的な確認を提供する。省略は、安全な基準点を壊さない範囲に閉じ込められていた。

ACKの運び方にも副作用があった。インタースパースされたフィードバックはRTPの連続性を割り込み、一時的にNHPを使えなくするため推奨されない。さらに、攻撃者がランダムなCRCを持つ偽CCPを注入できれば、誤った検査失敗、コンテキスト無効化、フィードバック、更新を増やせる。内容を偽造せずに最適化だけを失わせる可用性攻撃である。

後のROHCフレームワークやROHCv2、並べ替えを扱う文書は周辺設計を発展させた。IANA登録も識別子を残す。しかし、それらはRFC 3408の利用実績を証明しない。このRFCが残したのは、ワイヤーから消した情報の責任を、別の層で名前付きの信号と再開条件に変換する設計原則である。

Sources