Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

[Roman Shpount <[e-mail]>]

If  "use_srtp" extension is specified, there is going to be SRTP/SRTCP
keying material present and associated with each DTLS cipher state. If DTLS
re-handshake occurs within the same session, the new RTP/RTCP keying
material will be negotiated. Since no SRTP/SRTCP packets would be exchanged
before SRTP/SRTCP stream was added to the bundle, these packets would not
contribute to cipher state expiration. Cipher state can still expire due to
the number of data packets transmitted or time, which can still cause new
SRTP/SRTCP keying material to be negotiated.

Technically speaking either DTLS client or server can initiate a
re-handshake at any time. It is an implementation detail on what would
cause a re-handshake, and it can be done based on the number of packets
sent or received, or based on time. If re-handshake is done based on the
number of packets, both SRTP/SRTCP and data packets should have separate
counters and cause a re-handshake once a certain value is passed.

As far as I know, DTLS re-handshake is not currently supported by either
Chrome or Firefox, which means keying material for both data and SRTP/SRTCP
will stay the same for the duration of the session.
_____________
Roman Shpount

On Wed, May 27, 2015 at 8:06 PM, Christian Groves <
[e-mail]> wrote:

> To be clear this means that the SRTP and SRTCP ( (because of the
> possibility of RTP/RTCP muxing) key negotiation occurs even before RTP/STRP
> media is added to the BUNDLE, and the keying material for both are
> maintained for the life of the BUNDLE? If the keys are unused they wouldn't
> expire because max lifetime is based on the number of protected packets.
>
> Christian
>
> On 28/05/2015 3:17 AM, Christer Holmberg wrote:
>
>> Hi,
>>
>> I guess we could add some text to the DTLS Considerations section.
>>
>> Regards,
>>
>> Christer
>>
>> Sent from my Windows Phone
>> ------------------------------------------------------------------------
>> From: Roman Shpount <mailto:[e-mail]>
>> Sent: ‎27/‎05/‎2015 23:31
>> To: Makaraju, Maridi Raju (Raju) <mailto:[e-mail]
>> >
>> Cc: Christer Holmberg <mailto:[e-mail]>; Christian
>> Groves <mailto:[e-mail]>; [e-mail] <mailto:
>> [e-mail]>gt;; [e-mail] <mailto:[e-mail]>
>> Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
>>
>>
>>
>> On Wed, May 27, 2015 at 7:37 AM, Makaraju, Maridi Raju (Raju) <
>> [e-mail] <mailto:[e-mail]>>
>> wrote:
>>
>>     > >One interesting question that Albrecht brought up in a separate
>> email
>>     > discussion is what happens if you first establish a >DTLS
>>     association
>>     > for datachannel and then at a later stage you add SRTP media? I
>>     take it
>>     > that you'd have to re-establish >the DTLS connection and perform a
>>     > handshake using the "use_srtp" extension. That makes transitioning
>>     > messy.
>>     >
>>     > There is a related (not BUNDLE specific) discussion on when one is
>>     > allowed to re-establish a DTLS connection, and the idea (I don't
>>     have
>>     > the exact details in front of me) is that it can happen only
>>     when an IP
>>     > address or port changes. That obviously does not have to occur
>>     if you
>>     > add SRTP.
>>     [Raju]
>>     Will there be an issue if "use_srtp" extension is always included
>>     even when
>>     SRTP media is not present at that time? I don't see any issue.
>>     This is how Chrome works today; it always includes the extension.
>>
>>
>> I agree, DTLS session should always be setup with "use_srtp" extension.
>> There is little or no additional overhead, but this removes the latency
>> required for a new DTLS session when and if SRTP is added. Since there is
>> no new DTLS session there is no need for a new underlying transport and
>> additional IPs. Nice and clean.
>>
>> This should probably be stated somewhere in the document.
>> _____________
>> Roman Shpount
>>
>>
>