3.3.2. Replay Protection (リプレイ保護)

3.3.2. Replay Protection (リプレイ保護)

安全なリプレイ保護 (replay protection) は, 完全性保護 (integrity protection) が存在する場合にのみ可能です。完全性保護だけではリプレイ攻撃に対するセキュリティを保証できないため, RTP と RTCP の両方でリプレイ保護を使用することが推奨されます (RECOMMENDED)。

パケットは, 敵対者によって保存され, その後ネットワークに再注入されると「リプレイされた」(replayed) ことになります。メッセージ認証が提供される場合, SRTP はリプレイリスト (Replay List) を通じてこのような攻撃から保護します。各 SRTP 受信者はリプレイリストを維持します。これは概念的には, 受信され認証されたすべてのパケットのインデックスを含みます。実際には, リストは「スライディングウィンドウ」(sliding window) アプローチを使用できるため, 固定量のストレージでリプレイ保護に十分です。コンテキスト内のパケットインデックスより SRTP-WINDOW-SIZE 以上遅れているパケットインデックスは, 受信されたと見なすことができます。ここで, SRTP-WINDOW-SIZE は受信側の実装依存パラメータであり, 少なくとも 64 でなければなりませんが (MUST), より高い値に設定してもかまいません (MAY)。

受信者は, 受信パケットのインデックスをリプレイリストとウィンドウに対してチェックします。ウィンドウの前方にあるインデックスを持つパケット, またはウィンドウ内にあるがまだ受信されていないパケットのみが受け入れられなければなりません (SHALL)。

パケットが認証された後 (必要に応じて最初にウィンドウを前方に移動), リプレイリストは新しいインデックスで更新されなければなりません (SHALL)。

リプレイリストは, IP のセキュリティアーキテクチャ (Security Architecture for IP) [RFC2401] で説明されているように, どのパケットが受信されたかを表すビットマップ (bitmap) を使用して効率的に実装できます。