DTLS-SRTP Handling in SIP Back-to-Back User Agents
Extracted elements (19)
A B2BUA cannot modify RTP headers or RTCP packets without first acting as a DTLS endpoint, terminating the DTLS-SRTP session, and decrypting/re-encrypting the RTP payload. Any modification to the authenticated portions will fail the HMAC integrity check (negotiated during the DTLS handshake per RFC 5764 Section 4.1.2) and cause the endpoint to drop the packet.
B2BUAs deployed for address hiding or media latching can perform those functions while only terminating at the IP and UDP/TCP layers, without acting as a DTLS proxy. TURN and ICE are expected to be used more often than B2BUAs for NAT traversal because they provide better security properties.
B2BUAs that provide identity assurance and terminate DTLS-SRTP sessions are explicitly out of scope. Because such a B2BUA generates the identity signature itself, it is not possible to detect whether it has terminated the DTLS-SRTP session.
DTLS-SRTP is defined only for point-to-point media sessions, so B2BUAs sitting between endpoints commonly break end-to-end DTLS-SRTP by terminating the DTLS session and decrypting the RTP payload. This document targets the subset of B2BUAs that can relay media at the transport layer without needing to terminate DTLS.
If endpoints use RFC 4474 for identity assurance, a B2BUA cannot function as a media relay without violating the identity signature. If SIP-ID is used instead, the B2BUA may modify the c= line IP address and m= line port in the SDP without breaking the identity guarantee.
Proxy-B2BUAs (RFC 7092 Section 3.1.1) modify only Via and Record-Route headers and do not touch any field covered by the RFC 4474 or SIP-ID identity signature, so they are fully compatible with end-to-end DTLS-SRTP without any additional constraints.
Signaling-only and SDP-modifying signaling-only B2BUAs (RFC 7092 Sections 3.1.2 and 3.1.3) commonly alter fields such as the Contact URI that are covered by the identity signature, and are likely to violate the rules for end-to-end DTLS-SRTP unless they carefully constrain their modifications to fields permitted by RFC 4474 or SIP-ID.
The DTLS handshake and the INVITE response may proceed in parallel; a B2BUA must therefore be prepared to receive DTLS, STUN, and media packets on the ports it advertised in the SDP offer before it has received the SDP answer.
B2BUAs MUST forward the certificate fingerprint and SDP setup attribute received from one endpoint unmodified towards the other endpoint and vice versa. This is the foundational rule for preserving end-to-end DTLS-SRTP across a B2BUA.
Both media relays and media-aware relays MUST NOT modify the authenticated portion of RTP and RTCP packets, and MUST NOT modify the authentication tag in those packets.
During forking, B2BUAs MUST forward certificate fingerprints and SDP setup attributes from each answerer unmodified toward the offerer. The B2BUA replaces each answerer's transport address with its own unique transport address, enabling the offerer to establish a separate DTLS connection per answerer.
When RFC 4474 identity assurance is in use (SIP request contains both Identity and Identity-Info headers), B2BUAs MUST NOT modify any information used to construct the identity signature, including the entire SDP body and protected SIP headers. In this case a B2BUA cannot act as a media-relay B2BUA.
When SIP-ID (draft-ietf-stir-rfc4474bis) is in use — identified by an Identity header without an Identity-Info header — B2BUAs MUST NOT modify any headers used to construct the identity signature, but the B2BUA may still act as a media-relay B2BUA.
A DTLS-SRTP session contains either one DTLS connection (when RTP and RTCP are multiplexed per RFC 5761) or two DTLS connections (when RTP and RTCP are not multiplexed), and either one or two SRTP contexts depending on whether media flows in one or both directions on the same 5-tuple.
A media-relay B2BUA (RFC 7092 Section 3.2.1) forwards all packets on a negotiated connection without inspecting or modifying packet contents; it modifies only the UDP/TCP and IP headers, leaving the DTLS payload and SRTP authentication tag intact.
In a forked call, each DTLS connection is set up on a unique 5-tuple. The B2BUA advertises a distinct transport address (IP:port) for each forked answer and maintains a mapping between remote sources (e.g., Bob, Charlie) and local sources used to relay media toward the offerer.
There are two subtypes of media-aware relay (RFC 7092 Section 3.2.2): inspection-only (reads RTP headers and unencrypted RTCP) and modifying (alters them). Only inspection-only relays are compatible with end-to-end DTLS-SRTP; modifying relays require DTLS termination.
A malicious B2BUA may attempt to terminate the DTLS connection to decrypt RTP payloads. This attack can be detected and prevented by using the identity validation mechanisms in RFC 4474 or SIP-ID, either by the endpoints themselves or by authentication service proxies in the call path.
B2BUAs that modify RTP/RTCP packets, or that alter SIP headers or SDP fields protected by the identity signature, are incompatible with end-to-end DTLS-SRTP and fall outside the scope of this document. The B2BUA behaviors described here do not affect the security or integrity of a DTLS-SRTP session or the data exchanged over it.