skip to content

In what order does an SRTP receiver run the replay check, tag verification, decryption and state update, and why are failures discarded silently?

level: seniorimportance: should knowfreq 18%

answer

  1. nothing decrypted before the tag passes
  2. state written last
  3. a cheap lookup can come first
  4. MUST discard, SHOULD log
  5. no error on the wire

basics

~20 s

RFC 3711 has the SRTP receiver check the replay list, verify the tag, decrypt, then update ROC, s_l and the replay list. A failure is discarded and logged locally; nothing goes back to an unverified sender.

solid answer

~50 s

RFC 3711's receiver steps are: find the crypto context, estimate the 48-bit index, pick the keys, then **check the replay list**, then **verify the authentication tag**, then **decrypt**, and only then **update** ROC, `s_l` and the replay list. The two invariants that matter: nothing is decrypted or released before the tag passes, and no state is written for a packet that has not authenticated, so a forged packet cannot slide the window or bump ROC. The replay lookup comes first because it is cheap; for the AES-GCM profiles RFC 7714 says a packet must pass AEAD authentication before any other action, so implementations may verify first — both are safe if state is written last. On failure the packet MUST be discarded and the event SHOULD be logged. SRTP sends no error: the failed packet's source is unproven, so a reply could be aimed at a spoofed address.

go deeper

for a junior

Recall that an SRTP receiver throws away a packet that fails its replay or tag check, and does not send any error back.

for a middle

List RFC 3711's receive steps in order and state the two invariants: no decryption before the tag passes, no state update for an unauthenticated packet.

for a senior

Explain why both 'replay lookup first' and 'authenticate first' are safe, what a forged far-ahead index would do if state were written early, and how to read discard counters with no feedback from the far end.

for a principal

Set the observability policy for silent discard across a media fleet: which counters per stream, how logging is rate-limited under a flood, and which patterns page someone.

## The receiver's steps, as RFC 3711 writes them RFC 3711 section 3.3 lists what an SRTP receiver SHALL do with each packet: 1. **Find the cryptographic context** from the SSRC, destination address and destination port. No context: discard. 2. **Estimate the packet index** — ROC and the 16-bit sequence number — from the stored ROC and `s_l`. 3. **Choose the master key and salt**, from the MKI if one is present, otherwise from the index. 4. **Determine the session keys** for that index. 5. **Replay check, then tag check.** First check the replay list; a replayed packet MUST be discarded and the event SHOULD be logged. Next verify the authentication tag; on `AUTHENTICATION FAILURE` the packet MUST be discarded and the event SHOULD be logged. 6. **Decrypt** the encrypted portion. 7. **Update** ROC and `s_l` from the estimate in step 2, and, if replay protection is on, the replay list. 8. **Strip** the MKI and tag. The sender does the mirror image: encrypt first, then compute the tag over the result. RFC 3711 states the rule as encryption before authentication on the sending side, and the converse on the receiving side. ## Why this order: two invariants | Invariant | What breaks without it | |---|---| | **No decryption or release before the tag verifies** | Edited ciphertext reaches the decoder; with a counter-mode cipher a flipped bit becomes a flipped media bit | | **No state written for an unauthenticated packet** | One forged packet with a far-ahead index slides the replay window, so genuine packets land behind it and are thrown away; or it bumps ROC and every later tag fails | Everything else is efficiency. The replay check is a bitmap lookup, cheaper than an HMAC, so RFC 3711 puts it first: a re-sent burst is rejected without computing a tag for each packet. ## A common summary, and what the RFCs actually say Many write-ups summarise SRTP reception as "authenticate, replay-check, decrypt". RFC 3711's text puts the replay *lookup* before tag verification and the replay *update* after it. For the AES-GCM profiles, RFC 7714 says all incoming packets MUST pass AEAD authentication before any other action takes place, and the ciphertext MUST NOT be decrypted until the tag is validated — there the tag check and decryption are one AEAD operation. Both orders satisfy both invariants. What is wrong is any order that: - **decrypts and hands media to the decoder** before the tag is checked, or - **marks the replay window or advances ROC** before the tag is checked. ## Silent discard On failure, RFC 3711 requires one thing on the wire: nothing. The packet MUST be discarded and the event SHOULD be logged. `AUTHENTICATION FAILURE` is an audit result the verification step returns inside the receiver, not a message to anyone. For the AEAD profiles RFC 7714 says the packet is discarded and a **Validation Error flag** raised, with its handling left to local policy. RFC 5764 adds, for DTLS-SRTP, that DTLS alerts SHOULD NOT be generated as a response to data packets. The reasons follow from what a failed packet is (this is the reasoning, not RFC text): - **Its origin is unproven.** The tag is the only proof of who sent it. A reply would go to a source address an attacker may have forged, turning the receiver into a reflector. - **A reply is an oracle.** Telling a prober which packets failed and why helps them, and helps no honest sender. - **Nothing would be retransmitted.** RTP media is real-time; a late copy of a voice frame is useless. - **The real fixes live elsewhere.** A key or ROC mismatch is repaired by key management and signalling, not by per-packet complaints. ## Running it What an operator should make visible, per SSRC (counters are an operator's choice, not an RFC requirement): - **Replay discards** — a low rate from network duplicates and reordering beyond the window is normal; a block of earlier indices re-appearing is the replay pattern. - **Authentication failures** — scattered failures suggest corruption or forgery attempts; **every packet failing** suggests mismatched keys or a desynchronised ROC. - **Log volume** — logging every failed packet of a flood can itself be the outage, so rate-limit the log, not the discard. Because nothing is sent back, the far end sees only silence. The receiver's counters are where the diagnosis has to start.

  • In SRTP, what goes wrong if an implementation decrypts a packet and passes it to the media decoder, then checks the tag?
    Edited packets reach the decoder before anyone notices. With a counter-mode cipher an attacker's bit flips become flipped media bits, and RFC 3711 warns that some decoders crash on such input. RFC 7714 forbids it outright for the AEAD profiles: the ciphertext MUST NOT be decrypted until the tag has been validated.
  • Why does SRTP check the replay list before the tag, if the replay list is only updated after the tag?
    The lookup is cheap and the HMAC is not. Rejecting a known index first means a re-sent burst costs a bitmap read per packet, not a tag computation. The update has to wait for the tag, because writing state for an unverified packet would let a forger move the window or the rollover counter.

saying these in an interview costs you the question

  • The receiver decrypts first and checks the tag on the plaintext afterwards.
  • The replay window is updated as soon as the packet passes the replay lookup.
  • AUTHENTICATION FAILURE is an error message sent back to the SRTP sender.
  • The receiver should send a DTLS alert for each packet that fails its tag.
  • Checking the replay list before the tag lets replayed packets through.