An SRTP media leg kept open for months nears its master-key packet limit; how is it re-keyed, and why can a non-zero key derivation rate not postpone the limit?
answer
- the sender counts packets per key
- 2^48 SRTP, 2^31 SRTCP
- new handshake or new a=crypto
- the index bounds the master key
basics
~20 sRFC 3711 caps a master key at 2^48 SRTP or 2^31 SRTCP packets; before either, key management must install a new master key, through a fresh DTLS handshake or SDES offer, or end the session. Session-key re-derivation cannot stretch that cap.
solid answer
~40 sThe sender must count packets per master key. RFC 3711 allows 2^48 SRTP or 2^31 SRTCP packets, whichever comes first when they share a key, and each DTLS-SRTP profile sets a `maximum_lifetime` of 2^31 packets per key set, counting RTP and RTCP separately. Before the limit, DTLS-SRTP re-keys with a fresh handshake: RFC 5764 runs it over the existing association, but WebRTC forbids renegotiation, so there it means a new association agreed in signalling. SDES re-keys with a new offer/answer carrying new `a=crypto` keys, where an MKI tells receivers which key a packet uses. The rollover counter is never reset, and receivers keep the old keys briefly for late packets. A key derivation rate refreshes session keys but cannot help, because keystream uniqueness depends on distinct packet indices under one master key.
go deeper
Remember that an SRTP master key has a packet limit and must be replaced before it is reached, by new key management rather than by SRTP itself.
Explain the limits, 2^48 SRTP and 2^31 SRTCP per master key, and that the sender counts packets and triggers re-keying through DTLS-SRTP or SDES.
Show operating judgement: compute time to the 2^31 limit for long or high-rate legs, keep old keys for late packets, never reset the rollover counter, and know WebRTC needs a new association.
Decide a re-keying policy for long-lived media legs: when to force a new association, how MKI versus trial decryption trades overhead against tag strength, and how to monitor packet counts.
## Why a master key has a packet budget SRTP's default cipher is AES in counter mode. Its keystream for a packet depends on the session salting key, the SSRC and the **packet index**, so two packets protected under the same key must never share an index, or the keystream repeats: the *two-time pad*. The index for SRTP is 48 bits (a 32-bit rollover counter and the 16-bit sequence number); SRTCP carries an explicit 31-bit index. Hence RFC 3711's limits per master key: - **2^48 SRTP packets** per stream; - **2^31 SRTCP packets**; - when SRTP and SRTCP derive their keys from the same master key, the default, **whichever is reached first**. The sender **must keep packet counts**, because re-keying means the limit need not coincide with an index wrap. When the limit is reached, key management must supply a new master key, and previously used keys must never be reused, or the session must be terminated. Where several streams share a master key, the stream that exhausts its index space first decides when all of them re-key. DTLS-SRTP adds its own ceiling. Every profile in RFC 5764 sets a `maximum_lifetime` of 2^31 packets per set of keys, counting RTP and RTCP separately, and once it is reached the existing keys must not be used for either direction. ## How long that takes | Stream | Packets per second | Limit | Time to limit | |---|---|---|---| | RTCP, the case in RFC 3711's note | 200 | 2^31 | about 124 days | | Voice, 20 ms packets | 50 | 2^31 (DTLS-SRTP profile) | about 497 days | | Video | 1,000 | 2^31 (DTLS-SRTP profile) | about 25 days | | Voice | 50 | 2^48 (RFC 3711 SRTP) | about 178,000 years | A short call never comes close. A leg kept up for weeks, such as a permanent feed, a nailed-up bridge between two media servers or a high-rate video stream, can, and that is where re-keying stops being theoretical. ## Re-keying with DTLS-SRTP 1. **Run a new handshake.** RFC 5764 re-keys by a new handshake over the existing DTLS channel, protected by the current cipher suite, while media keeps flowing. When it completes, every outbound packet uses the new keys. RFC 8827, however, forbids DTLS renegotiation in WebRTC; there, new keys mean a **new DTLS association**, which RFC 8842 ties to an offer/answer exchange that changes the `tls-id`, a fingerprint or the setup role. 2. **Keep the old keys briefly.** Packets protected under the old keys can arrive after the switch, so receivers should hold both sets for a while. 3. **Pick the right key per packet.** With an MKI, the receiver uses the key set the MKI names and rejects a packet whose MKI matches none. Without one, it tries the new keys and, if authentication fails, may try the old set, accepting the packet only if that succeeds. ```pseudocode on_srtp_packet(p): if mki_in_use: keys = key_set_for(p.mki) if keys is none: reject(p) else: verify_then_decrypt(p, keys) else if verifies(p, new_keys): verify_then_decrypt(p, new_keys) else if old_keys_held and verifies(p, old_keys): verify_then_decrypt(p, old_keys) else: discard(p) ``` RFC 5764 notes the cost of trying k key sets: an n-bit tag is weakened to about n - log2(k) bits, negligible for two sets and an 80-bit tag. ## Re-keying with SDES SDES has no handshake. Re-keying is a new offer/answer exchange carrying fresh `a=crypto` keys. The `inline` key parameter can carry a **lifetime** and an **MKI**; RFC 3711 recommends the MKI for re-keying because each packet then names its master key, at the cost of extra bytes per packet. RFC 3711's other option, a `<From, To>` index range per key, is not supported by SDES and is advised only for simple single-stream cases. In both methods the **rollover counter carries on**: RFC 3711 says it must not be reset to zero after a re-key, and the SRTCP index likewise must not restart. ## Why the derivation rate does not help A non-zero `key_derivation_rate` re-derives session keys from the same master key every so many packets. That limits how much traffic any one session key protects, but RFC 3711 section 9.2 is explicit that it **does not extend the master key's lifetime**. Two packets must be processed either with different IVs or with different session keys, and both properties come from distinct packet indices. Once the index space under one master key is used up, nothing derived from that master key is safe, so only a new master key resets the budget.
- Why must the SRTP rollover counter not restart at zero after a re-key?RFC 3711 makes continuity a rule: the rollover counter keeps its sequence across master-key changes. It is part of each packet's index, which the receiver tracks and feeds into authentication. A sender restarting it at zero would leave the receiver estimating the wrong index, so packets would fail authentication or be judged replays.
- Why does RFC 3711 recommend the MKI rather than <From, To> ranges for re-keying?With an MKI each packet names its master key, so a receiver picks the right one even across reordering or several streams sharing a key. <From, To> ranges carry no per-packet marker and are hard to apply to several streams and to SRTCP near a switch. The MKI costs extra bytes per packet, and RFC 8827 forbids it in WebRTC.
saying these in an interview costs you the question
- SRTP keys never need replacing because a 48-bit index cannot run out.
- A non-zero key derivation rate lets one master key protect more than 2^48 packets.
- After a re-key the SRTP rollover counter starts again from zero.
- Receivers must discard any packet that fails authentication right after a rehandshake.
- A WebRTC endpoint re-keys by DTLS renegotiation over its existing association.