[VOIPSEC] SRTP rekeying in the real world

[Waters Geoffrey-ra6722]

Hello,
 
    I'm looking for information related to SRTP rekeying synchronization
which multiple readings of RFC3711 didn't resolve for me.
 
If a video on demand (VOD) application is considered with the following
configuration

-          one sender (SRTP Tx stream, SRTCP Tx stream), one receiver
(SRTP Rx stream, SRTCP Rx stream)

-     SRTP and SRTCP streams have different SSRCs, but are using the
same master key

-          re-key is based on the first stream using the master key to
detect a key lifetime limit has been reached

 

When the 'To' is reached in the <From, To> range, the SRTP Tx stream
begins using a new master key. Suppose that around the same time that
the SRTP packet is received by the receiver, the receiver sends an SRTCP
packet. How does the sender know if the old or new master key is being
used by the receiver generated SRTCP packet? SRTCP index?  Does the
sender need to support both master keys for a certain amount of time? If
both master keys need to be supported for a certain amount of time, for
how long? 

 

If the MKI method was used for re-keying instead of the <From, To>
method, the SRTP packet would include the MKI field. Does the choice to
use MKI in the SRTP stream guarantee that the MKI will be used in the
SRTCP stream?

 

If anyone knows of a 'SRTP Rekeying Issues' document, similar to the
excellent IKE/IPSec rekeying document (Draft-Jenkins), I'd very much
appreciate a pointer to it.  

 

Encrypted Key Transport for Secure RTP (draft-mcgrew-srtp-ekt-01) is
tackling the signalling issues associated with SRTP/SRTCP key
switch-over, but existing systems must be dealing with SRTP/SRTCP key
linkage and switch over issues some other way.  Are SRTCP streams
getting their own SSRCs to avoid linkage issues?

 

Regards,

 

Geoff Waters