skip to content

In SRTP, how does SRTCP protect RTCP control packets differently from SRTP data packets, and why is its authentication mandatory?

level: middleimportance: must knowfreq 24%

answer

  1. control traffic steers the session
  2. no sequence number to borrow
  3. three fields appended at the tail
  4. a flag, a counter, a tag
  5. a forged BYE ends a stream

basics

~20 s

SRTCP appends an encrypt flag, an explicit 31-bit SRTCP index and a mandatory authentication tag to each RTCP compound packet, because RTCP has no sequence number to derive an index from and forged reports or BYEs could disrupt the session.

solid answer

~50 s

SRTP derives its 48-bit packet index implicitly from the RTP sequence number and a rollover counter, but RTCP has no sequence number, so RFC 3711 makes SRTCP carry its index explicitly. It appends a 1-bit `E` flag, a 31-bit SRTCP index and an authentication tag (plus an optional MKI) to the compound packet. Encryption covers everything after the first eight octets and is optional per packet, since `E` says whether it was applied, but authentication is REQUIRED: RTCP is the control protocol, so a forged `BYE` could end a participant's stream and forged reports could corrupt the feedback senders rely on. SRTCP gets its own session keys (KDF labels `0x03` to `0x05`), its own replay list, and an index that is never reset after a re-key. In typical sessions the 2^31 SRTCP limit, not the 2^48 SRTP one, forces a new master key first.

go deeper

for a junior

Recall that RTCP carries reports and BYE messages about the media, and that SRTCP is the protected form of RTCP, which is always authenticated even when it is not encrypted.

for a middle

Explain the three mandatory fields SRTCP appends, why the index has to be explicit, and why the E flag makes encryption optional per packet while the authentication tag never is.

for a senior

Show you can read a control-path symptom: vanishing call statistics or ignored BYEs on a working call often mean SRTCP packets failing authentication or landing in the wrong context.

for a principal

Weigh SRTCP's key lifetime and per-packet overhead against RTCP's bandwidth share, and decide where control traffic is terminated when an intermediary regenerates RTCP on each leg.

## Why RTCP needs its own protection **RTP** carries the media; **RTCP**, its companion control protocol (RFC 3550), carries sender reports, receiver reports with loss and jitter figures, source descriptions and the `BYE` packet that says a participant has left. A sender adapts to the receiver reports, and a receiver drops a source when it sees that source's `BYE`. If an attacker on the path could forge or alter RTCP, they could make a sender believe the network is collapsing, or end a participant's stream, without touching a single media packet. **SRTP** (RFC 3711) protects RTP, and **SRTCP** is its counterpart for RTCP. RFC 3711 makes the security services of SRTP optional and independent, with one exception: **SRTCP message authentication is mandatory**, because, as the RFC puts it, RTCP is the control protocol and has a `BYE` packet. WebRTC goes further: RFC 8827 requires every media channel to be secured with both SRTP and SRTCP and forbids NULL encryption. ## What SRTCP appends to the packet An SRTP packet needs no new fields to find its index: the receiver combines the 16-bit RTP sequence number with a 32-bit **rollover counter (ROC)** it keeps locally, giving the 48-bit index `i = 2^16 * ROC + SEQ`. RTCP packets have no sequence number, so SRTCP cannot estimate anything. Instead it appends fields to the RTCP compound packet: | Field | Size | Required? | What it does | |---|---|---|---| | `E` flag | 1 bit | yes | 1 if this packet's payload was encrypted, 0 if not | | SRTCP index | 31 bits | yes | explicit packet counter, starts at 0, +1 per packet, modulo 2^31 | | MKI | configurable | optional | Master Key Indicator, selects among master keys | | Authentication tag | configurable | yes | integrity check over the packet, the `E` flag and the index | The **Encrypted Portion** starts at the ninth octet, so the first RTCP header and the sender's SSRC stay readable; the receiver needs that SSRC to find the right cryptographic context. The **Authenticated Portion** is the whole RTCP compound packet plus the `E` flag and the index, so those eight clear octets are still integrity-protected. ## How a receiver processes SRTCP RFC 3711 reuses the SRTP processing steps with SRTCP-specific changes: 1. Read the SRTCP index straight from the packet; no estimation is needed. 2. Check it against a **separate replay list** kept for SRTCP only. 3. Verify the authentication tag over the Authenticated Portion; on failure the packet MUST be discarded, and logging is only a SHOULD. 4. If `E` is 1, decrypt the Encrypted Portion using the index; if `E` is 0, leave the payload as it is. The `E` flag exists because RFC 3550 lets an application split a compound RTCP packet so that one part travels encrypted and another in clear. That is why encryption is optional per packet while the tag never is. ## Keys, limits and re-keying - **Separate session keys.** The SRTP key derivation function produces SRTP keys with labels `0x00` to `0x02` and SRTCP encryption, authentication and salting keys with labels `0x03`, `0x04` and `0x05`, all from the same master key by default. - **Never reset.** After a re-key the SRTCP index MUST NOT go back to zero. - **Key lifetime.** One master key may protect at most 2^48 SRTP packets or 2^31 SRTCP packets, whichever comes first. RFC 3711 notes that with at least one RTCP packet per 128,000 RTP packets, the SRTCP index usually reaches its limit first. - **Arithmetic.** 2^31 = 2,147,483,648 packets. At 200 SRTCP packets per second that is about 10,737,418 seconds, roughly 124 days, which RFC 3711 rounds to "approximately 4 months". - **Bandwidth.** The appended fields enlarge every control packet, so RFC 3711 requires the RTCP average-packet-size estimate to include them, keeping RTCP within its bandwidth share. ## What this means on a real call In DTLS-SRTP the protection profile `SRTP_AES128_CM_HMAC_SHA1_32` shortens the SRTP tag to 32 bits but keeps an **80-bit tag for SRTCP** (RFC 5764 section 4.1.2): media packets are small and frequent, control packets rarer and more consequential. When RTP and RTCP share one port (RFC 5761), SRTP and SRTCP are still produced from separate contexts and multiplexed just before sending. Operationally, an SRTCP failure rarely produces an error. Packets whose tag fails are dropped, so the visible symptoms are missing call statistics, a sender that never adapts, or a `BYE` that is ignored, while the audio itself keeps flowing. When call-quality figures vanish on one leg of an otherwise working call, a key or context mismatch on SRTCP is worth checking before blaming the network.

  • Why does an SRTCP packet leave its first eight octets unencrypted?
    Those octets hold the first RTCP header and the sender's SSRC. The receiver needs the SSRC in clear to select the cryptographic context before it can verify or decrypt anything, and when RTP and RTCP share a port the packet-type byte is what tells RTCP apart from RTP. The eight octets are still covered by the authentication tag, so they cannot be altered undetected.
  • On a DTLS-SRTP session using the SRTP_AES128_CM_HMAC_SHA1_32 profile, how long is the SRTCP authentication tag?
    80 bits. RFC 5764 lists that profile with a 32-bit tag for SRTP but an RTCP tag length of 80 bits. The short tag saves bandwidth on many small media packets, while the less frequent control packets, which can end a stream or steer a sender, keep the full-length tag.

saying these in an interview costs you the question

  • SRTCP is optional; protecting the media packets is enough.
  • SRTCP estimates its index from a rollover counter, just like SRTP.
  • An SRTCP packet with the E flag set to 0 carries no authentication.
  • The SRTCP index restarts at zero after every re-key.
  • SRTCP encrypts the whole RTCP packet, including the sender's SSRC.