Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)
Extracted elements (20)
SAVP and AVPF are largely orthogonal profiles, making their combination in SAVPF mostly straightforward without requiring new sophisticated algorithms. SAVPF simply layers AVPF timing and feedback packet formats on top of SAVP's SRTP encryption and integrity protection.
SRTCP adds at least 10–20 bytes (14 bytes by default) of overhead per RTCP packet, increasing average RTCP packet size and thereby reducing the frequency at which timely feedback can be provided under AVPF timing rules. Application designers must account for this by adjusting 'avg_rtcp_size' to maintain RTCP bandwidth shares.
RTP entities using SAVP and SAVPF MAY be mixed in a single RTP session. The interworking considerations defined in Section 5 of RFC 4585 apply. However, mixing secure (SAVP/SAVPF) and insecure (AVP/AVPF) profiles in the same RTP session is prohibited.
An offer SHOULD NOT include both a secure alternative (SAVP or SAVPF) and an insecure alternative (AVP or AVPF) in the same offer, as this may enable bidding-down attacks. If both are offered (e.g., for best-effort SRTP), the negotiation signaling MUST be protected appropriately.
AVP/AVPF (plain RTP) and SAVP/SAVPF (SRTP-based) MUST NOT be mixed in the same RTP session, since SRTP and plain RTP are not meant to interoperate.
For announced sessions (SAP, web, email) with no interactive negotiation, incompatible profiles (secure and insecure) MUST NOT be specified as alternatives. For negotiated sessions, one profile MUST be chosen from among offered alternatives.
For SAVPF, all RTCP packets MUST be encapsulated as defined in Section 3.4 of RFC 3711 (SRTP).
If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected. Conversely, if the answerer wants SAVPF but the offer does not use it, the answerer MUST also reject the session and MAY provide a counter-offer.
In RTSP-based negotiation, the RTSP client MUST select exactly one profile per media stream in the SETUP request, indicating the chosen RTP profile and the full server transport address in the Transport header. The server's response MUST confirm this profile selection or refuse the SETUP.
In SDP offer/answer negotiation, the four profiles AVP, AVPF, SAVP, and SAVPF are mutually exclusive for a given media description. An offerer capable of supporting more than one profile SHOULD offer all acceptable alternatives, listed in order of preference, preferring secure profiles over non-secure ones.
The average RTCP packet size calculation done by the AVPF layer for timing purposes MUST take into account the fields added by the SAVP layer (i.e., the SRTCP overhead). This is done by adjusting the RTCP variable 'avg_rtcp_size' to reflect the size of SRTCP packets.
The encryption prefix MUST NOT be used within the SAVPF profile. It is not used in SAVP, as it is only applicable to the encryption method specified in RFC 3550.
When using SDP key management (RFC 4567) with a secure profile in RTSP, the KeyMgmt header MUST be included in the appropriate RTSP messages. After choosing one secure profile in SETUP, only the KeyMgmt header for the chosen profile MUST be provided.
SAVPF is a new RTP profile that combines SAVP (Secure RTP, RFC 3711) and AVPF (Extended RTP Profile for RTCP-Based Feedback, RFC 4585), enabling secure RTP communications with timely RTCP feedback. SAVP forms an intermediate layer between AVPF and the transport layer, with AVPF replacing the upper AVP layer.
The SDP profile identifier for the combined secure feedback profile is 'RTP/SAVPF'. All SDP attributes defined for RTP/SAVP and RTP/AVPF are valid for RTP/SAVPF.
RFC 5124 registers the SDP protocol ('proto') value 'RTP/SAVPF' (Long form: 'Secure RTP Profile with RTCP-based Feedback') as a media-level-only SDP attribute with the Session Description Protocol registries.
A master key MUST NOT be shared among different RTP sessions unless the SSRCs used are unique across all RTP streams sharing the same master key, to avoid two-time pad (keystream reuse). When 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key, key management MUST be called to provide new master keys or the session MUST be terminated.
Applying the SAVPF profile implies mandatory integrity protection on RTCP. While this prevents false packets from non-members, it does not prevent a malicious legitimate member from acting improperly within the session.
Mixing secure and insecure media sessions across different RTP sessions may reveal information to third parties. The decision to mix them MUST be in line with a local security policy that specifies acceptable combinations (e.g., whether an unprotected audio stream alongside a protected video stream is acceptable).
SAVPF inherits all security properties from SAVP (RFC 3711) and does not add or remove any security services. Offering secure and insecure profiles simultaneously may enable bidding-down attacks and SHOULD NOT be done. If confidentiality or integrity is required, only SAVP/SAVPF alternatives should be offered unless other security mechanisms are in place.