6. Miscellaneous Considerations (その他の考慮)
6.1. Anonymous Calls
DTLS-SRTP は匿名呼を提供しないが禁止もしない. [RFC3325] や [RFC5767] の匿名機能を不注意に使うと匿名呼を逆特定し得る. 匿名呼では次を SHOULD とする.
各呼に新しい自己署名証明書を SHOULD (同一発信者の相関を避ける). ある程度の相関が許容なら認証連続性のため同一証明書を複数呼で SHOULD (第 8.4 節).
[RFC3325] 展開網では Privacy ヘッダを [RFC3323] に従い id にする必要がある. 証明書の subjectAltName に匿名希望ユーザを特定・相関させる情報を MUST NOT で含めない. 本推奨だけでは匿名化は十分でない.
6.2. Early Media
早期メディアを提供する端点が offer を受け取ったら setup:active を MUST とし, 直ちに DTLS を張ってメディアを送れる. passive 側は active の fingerprint を未検証かもしれない (第 8 節).
6.3. Forking
SIP ではリクエストが複数端点にフォークされ得る. 各フォークが異なる answer を生む. offer を出した側は, 各 answerer がユニークな answer と DTLS association を持つ. offerer は SIP の fingerprint と各 association の証明書ハッシュを照合して answer を対応付ける.
6.4. Delayed Offer Calls
offer のない INVITE を送れる. 受信側が offer を応答で返し, 発信側が ACK または PRACK [RFC3262] で answer を返す. active 側が passive と association を張る点は同じ.
6.5. Multiple Associations
複数フローでは active 側は任意順でハンドシェイクしてよい (MAY). 並行に関しては [RFC5764] 付録 B. answerer が active なら一部ストリームにだけ開始し得る. offerer が active なら完全な answer 後に開始する.
6.6. Session Modification
answer 後はどちらもセッション変更 (更新 offer を含む) を MAY で要求できる. INVITE または UPDATE で運べる. 互換なら association を再利用し, そうでなければ初回と同じ規則で新規に張り替え offer/answer 完了後に旧を閉じる. active/passive が変われば新接続を MUST.
6.7. Middlebox Interaction
DTLS-SRTP と中間装置の悪相互作用は [MMUSIC-MEDIA] に記載がある.
6.7.1. ICE Interaction
ICE [RFC5245] は相互到達性を検証する. DTLS 前に ICE チェックを行う. 攻撃的指名では複数ペアが有効になり得るが, 単一コンポーネントの ICE ペアは同一 DTLS association と MUST 扱い. 有効ペアが複数でもハンドシェイクは一回. 選択ペア変更時はアドレス調整が要る場合がある.
STUN は UDP 直送で DTLS 上ではない. 非多重化は [RFC5764].
6.7.2. Latching Control without ICE
ICE 非使用時は SBC のラッチングと干渉し得る [MMUSIC-MEDIA]. 相手 SDP 受信時に DTLS が未完了なら passive 側は STUN [RFC5389] チェックを一回 MUST (ピンホール). 実装はハンドシェイク期間中この要求に答える MUST. active は STUN が来なくても DTLS を進める MUST. passive は STUN 応答を待って ServerHello を遅らせてはならない MUST NOT.
6.8. Rekeying
TLS と同様 DTLS は再ハンドシェイクで再鍵化できる. 再鍵中も旧材料で継続し, 新鍵確立後に切替えて遅延を避ける. 詳細は [RFC5764] 3.7 節.
6.9. Conference Servers and Shared Encryptions Contexts
会議サーバが全参加者で同一暗号コンテキストを共有する案があるが, 本仕様では各 DTLS で新鍵が生じ双方完全制御できないため不可. RTP 暗号化負荷はコーデック等に比べ小さいとされる. [SRTP-EKT] や [KEY-TRANSPORT] 等の将来拡張で補える.
6.10. Media over SRTP
DTLS のデータプロトコルは汎用であり RTP 最適化は SRTP [RFC3711] に及ばない. DTLS-SRTP [RFC5764] で SRTP を DTLS 上に交渉し, 性能と鍵管理の両立を図る. 本仕様の実装は DTLS-SRTP を MUST サポート.
6.11. Best Effort Encryption
[RFC5479] の要件に従い, 両者が SRTP を支持し交渉成功時は SRTP, それ以外は RTP. [MMUSIC-SDP] で RTP/SRTP を代替として通知でき, offerer は SRTP を好みつつデフォルトは RTP. 本書の実装は [MMUSIC-SDP] を MUST サポート.