3.3.1. Packet Index Determination, and ROC, s_l Update (パケットインデックス決定と ROC, s_l 更新)
3.3.1. Packet Index Determination, and ROC, s_l Update (パケットインデックス決定と ROC, s_l 更新)
SRTP 実装は, シーケンシングに「暗黙的な」パケットインデックス (implicit packet index) を使用します。つまり, インデックスのすべてが SRTP パケットで明示的に運ばれるわけではありません。事前定義された変換の場合, インデックス i はリプレイ保護 (Section 3.3.2), 暗号化 (Section 4.1), メッセージ認証 (Section 4.2), および鍵導出 (Section 4.3) で使用されます。
セッションが開始されると, 送信側はロールオーバーカウンタ ROC (rollover counter) をゼロに設定しなければなりません (MUST)。RTP シーケンス番号 SEQ が 2^16 を法として回り込むたびに, 送信側は ROC を 2^32 を法として 1 増やさなければなりません (MUST) (下記のセキュリティ面を参照)。送信者のパケットインデックスは次のように定義されます:
i = 2^16 * ROC + SEQ.
受信側の実装は, RTP シーケンス番号を使用してパケットの正しいインデックスを決定します。これは, すべての SRTP パケットのシーケンス内のパケットの位置です。ロールオーバーカウンタの適切な使用のための堅牢なアプローチには, その処理と使用が明確に定義されている必要があります。特に, シーケンス番号が 2^16 またはゼロに近い順序外の RTP パケットは適切に処理されなければなりません。
インデックス推定は, 受信者がローカルに維持する ROC と s_l 値に基づいています。セッションのセットアップ時に, ROC はゼロに設定されなければなりません (MUST)。進行中のセッションに参加する受信者には, 鍵管理シグナリングなどの帯域外シグナリング (out-of-band signaling) を使用して現在の ROC 値を与えなければなりません (MUST)。さらに, 受信者は, 最初に観測された SRTP パケットの RTP シーケンス番号 (SEQ) に s_l を初期化しなければなりません (SHALL) (初期値が鍵管理などの帯域外シグナリングによって提供されない限り)。
連続する SRTP パケットについて, 受信者はインデックスを次のように推定すべきです (SHOULD):
i = 2^16 * v + SEQ,
ここで, v は集合 { ROC-1, ROC, ROC+1 } (2^32 を法とする) から選択され, i が値 2^16 * ROC + s_l に (2^48 を法とする意味で) 最も近くなるようにします (疑似コードについては Appendix A を参照)。
パケットが処理され認証された後 (セッションの SRTP パケットに対して有効になっている場合), 受信者は v を使用して次のように s_l と ROC 変数を条件付きで更新しなければなりません (MUST)。v=(ROC-1) mod 2^32 の場合, s_l または ROC への更新はありません。v=ROC の場合, SEQ が現在の s_l より大きい場合に限り s_l が SEQ に設定され, ROC への変更はありません。v=(ROC+1) mod 2^32 の場合, s_l は SEQ に設定され, ROC は v に設定されます。
再鍵化 (re-keying) が発生した後 (新しいマスター鍵への変更), ロールオーバーカウンタは常にその値のシーケンスを維持します。つまり, ゼロにリセットしてはなりません (MUST NOT)。
ロールオーバーカウンタが 32 ビット長で, シーケンス番号が 16 ビット長であるため, 事前定義された変換を使用して同じ鍵で保護できる特定の SRTP ストリームに属するパケットの最大数は 2^48 です。特定の (マスターまたはセッション) 鍵でその数の SRTP パケットが送信された後, 送信者はその鍵でこれ以上パケットを送信してはなりません (MUST NOT)。(SRTCP にも同様の制限があり, 実際にはより制限的である可能性があります。Section 9.2 を参照。) この制限は, 暗号鍵が変更される前に通過できるトラフィック量に上限を設けることで, セキュリティ上の利点を強制します。この量のトラフィックの前に再鍵化 (Section 8.1 を参照) をトリガーしなければならず (MUST), セキュリティの強化やメディアへのアクセス制御のためなど, より早くトリガーしてもかまいません (MAY)。非ゼロの key_derivation_rate による繰り返し鍵導出 (Section 4.3 を参照) もより強力なセキュリティを提供しますが, 上記の絶対最大値は変更されません。
受信側では, s_l と ROC の更新に関して注意点があります: メッセージ認証が存在しない場合, s_l の初期化も ROC 更新も完全に堅牢にすることはできません。受信者の「暗黙的インデックス」アプローチは, パケットの再順序付けと損失があまり大きくなく, ビットエラーが不幸な方法で発生しない限り, 事前定義された変換に対して機能します。特に, 同期が失われる前に 2^15 個のパケットが失われる必要があるか, パケットがシーケンスから 2^15 個離れている必要があります。このような劇的な損失または再順序付けは, RTP アプリケーション自体を混乱させる可能性があります。
インデックス推定と ROC 更新のアルゴリズムは実装の問題であり, 環境 (パケット損失率など) と同期が失われる可能性がある場合 (初期シーケンス番号 (RTP によってランダムに選択される) が事前にわかっておらず (鍵管理プロトコルで送信されない), 2^16 を法として回り込む可能性がある場合など) を考慮する必要があります。
上記のものよりも精巧で堅牢なスキームは, RTP 自身の「ロールオーバーカウンタ」の処理です。[RFC3550] の Appendix A.1 を参照してください。