skip to content

On an SRTP-protected call, what can an on-path observer still read from each packet, and why does SRTP leave the RTP header unencrypted?

level: seniorimportance: should knowfreq 18%

answer

  1. authenticated is not encrypted
  2. header compression on slow links
  3. SSRC and sequence feed the keys
  4. length and timing leak too
  5. RFC 6904, then RFC 9335

basics

~20 s

Under SRTP the observer still reads the whole RTP header — payload type, sequence number, timestamp, SSRC, CSRCs, extensions — plus packet sizes and timing. RFC 3711 leaves headers in clear for header compression; they are authenticated, not encrypted.

solid answer

~40 s

SRTP (RFC 3711) encrypts only the payload; the RTP header is inside the authenticated portion but stays readable. An on-path observer therefore sees the payload type (the codec), the sequence number and timestamp (packet rate and timing), the SSRC and any CSRCs (which streams and which mixed talkers), header extensions, the marker bit at talkspurt starts, and every packet's length — RFC 3711 notes the payload length leaks. RFC 3711 §9.4 gives the reason: headers stay clear to allow header compression, and SSRC and sequence number also drive SRTP's per-packet keying. The observer can read but not change: a rewritten header fails the tag. RFC 6904 added selective encryption of header extensions, and RFC 9335 (Cryptex) encrypts CSRCs and extensions, still leaving the fixed header, including SSRC and sequence number, clear.

go deeper

for a junior

Recall that SRTP encrypts the payload and leaves the RTP header readable, though authenticated.

for a middle

List the readable fields and what each reveals, and give RFC 3711's reason: header compression, with SSRC and sequence number needed for keying.

for a senior

Explain to a privacy-conscious team what metadata still leaks, why rewriting the header fails authentication, and where RFC 6904 and Cryptex help.

for a principal

Weigh metadata exposure against header compression and middlebox compatibility, and decide when lower-layer protection of a path justifies its cost.

## Authenticated, not encrypted An SRTP packet (RFC 3711 §3.1) has two overlapping regions: - the **Encrypted Portion** — the RTP payload, plus RTP padding if present; - the **Authenticated Portion** — the RTP header followed by the Encrypted Portion, covered by the authentication tag. So the header is **integrity-protected but readable**. The AES-GCM profiles of RFC 7714 keep the same split, feeding the header in as associated data that is authenticated but not encrypted. ## What an observer still reads | Visible item | What it reveals | |---|---| | Payload type | The codec, so the call's quality tier and bitrate class | | Sequence number | Packet rate, loss on the path, call duration | | Timestamp | Media-clock timing; together with sequence numbers, silent stretches | | Marker bit | RFC 3551 says it SHOULD be set on the first packet of a talkspurt when silence suppression is on | | SSRC | Which streams belong together, stable across the call | | CSRC list | Which participants a mixer combined into this packet | | Header extensions | Whatever they carry; RFC 9335 cites per-packet audio levels as sensitive | | Packet length and timing | Payload size and pacing; RFC 3711 says "the payload length (and information deducible from this) will leak" | Add the IP and UDP headers, which SRTP never touches, and an observer learns who talks to whom, when, for how long, with which codec, and — with silence suppression — when each side is speaking. The words remain protected. For SRTCP the picture is similar: the first eight octets, the RTCP header and sender SSRC, stay in clear, along with the E flag and SRTCP index; the rest of the compound packet is encrypted when the E flag is set. ## The office call, as seen from the path Take a 20 ms PCMU call under SRTP's default AES counter-mode profile with an 80-bit tag: 1. 50 packets per second in each direction, each with a 12-byte clear RTP header. 2. A 160-byte encrypted payload (no padding with the pre-defined transforms) and a 10-byte tag, so 182 bytes above UDP. 3. Steady sequence numbers and timestamp steps of 160, with pauses and a set marker bit where silence suppression cuts in. With a constant-rate codec, payload length says little; with a variable-rate codec, sizes can follow the speech itself. ## Why RFC 3711 left the header in clear 1. **Header compression.** RFC 3711 §9.4: "RTP headers are sent in the clear to allow for header compression." On low-bandwidth links the 40 bytes of IPv4, UDP and RTP headers can rival or exceed a small voice payload, and compressing them needs readable, predictable fields. 2. **Keying.** SRTP's per-packet processing uses the SSRC (with destination address and port) to find the cryptographic context and the sequence number to form the packet index; RFC 9335 says these "need to remain as cleartext because they are used for key scheduling". 3. **Compatibility.** Monitors, translators and demultiplexers that read the first bytes of an RTP packet keep working; RFC 3550 already expected profile-independent monitors to interpret the first twelve octets. RFC 3711 accepts the trade-off openly and says that anyone who really needs to protect headers should look at alternatives such as IPsec (RFC 3711 cites RFC 2401, since obsoleted by RFC 4301). ## Reading is not tampering Because the header is inside the authenticated portion, an on-path attacker who rewrites the SSRC, sequence number, timestamp or payload type produces a packet whose tag no longer verifies, and the receiver discards it. That holds only when authentication is on; RFC 3711 says SRTP SHOULD NOT be used without it. ## Narrowing the metadata - **RFC 6904** (Standards Track, updates RFC 3711) added selective encryption of RTP header extensions within SRTP. - **RFC 9335** (Standards Track, updates RFC 3711), called **Cryptex**, encrypts the CSRC list and header extensions entirely, apart from the 4-byte extension block header. It deliberately leaves the 12-byte fixed header in clear — the first two bytes for compatibility, the SSRC and sequence number for key scheduling. Neither hides the fixed header's SSRC, sequence number or timestamp, nor packet sizes and timing. ## For the operator - Treat call metadata as visible even on SRTP: who, when, how long, which codec. - If header extensions carry sensitive data such as audio levels, negotiate Cryptex where both ends support it. - If even the fixed header must be hidden on a path, protect that path at a lower layer and accept losing header compression. - Do not drop SRTP authentication to save bytes: the clear header is safe to expose only because it is authenticated.

  • Do SRTP's AES-GCM profiles encrypt the RTP header?
    No. RFC 7714 uses AEAD with the RTP header as associated data: authenticated, not encrypted. The header stays readable exactly as with the AES counter-mode profile; only the payload is encrypted.
  • Can an observer tell when a participant on an SRTP call is talking?
    Often, yes, without decrypting anything. With silence suppression the packet stream pauses or switches to comfort noise during silence, and RFC 3551 says the first packet of each talkspurt SHOULD carry the marker bit, both visible in clear. Packet lengths can leak more, since RFC 3711 notes payload length leaks. The words stay protected; the rhythm of the conversation does not.

saying these in an interview costs you the question

  • SRTP hides the codec because the payload type is encrypted.
  • Since the RTP header is in clear, an attacker can rewrite the SSRC undetected.
  • SRTP's AES-GCM profiles encrypt the RTP header as well.
  • RFC 9335 Cryptex encrypts the whole RTP header, SSRC included.
  • On an SRTP call nobody on the path can tell when someone is speaking.