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

Roman Shpount <roman@telurix.com> Thu, 28 May 2015 02:20 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F951A8AAD for <mmusic@ietfa.amsl.com>; Wed, 27 May 2015 19:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTLhgI6E0qbN for <mmusic@ietfa.amsl.com>; Wed, 27 May 2015 19:20:29 -0700 (PDT)
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0B71A8A83 for <mmusic@ietf.org>; Wed, 27 May 2015 19:20:29 -0700 (PDT)
Received: by igbhj9 with SMTP id hj9so103143201igb.1 for <mmusic@ietf.org>; Wed, 27 May 2015 19:20:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NaWD7k5RDAjHkuj6xDjVOc9KEz3hnrQ4aqfOn15xmNE=; b=ZiNJNomXc6q++aMhBQKwh0kDss0BZk8+mgLR3EVFFTxfekEsq8Ie3te2BuuIf3pn3y RbxuAl4xKc9vw9X5sFAsYnq5xYCbzOWkf464M4EnCI558+E6bTYvzkHWk2PVh4GTBvnT YaPtvXpLtYWBUzadUfndXlP7Lf/jOqslp1Zx+/BimwOpY5Rwv4hUQyxHv+iRKueozv8t nSYwahZWmFYSEgOaJtkZzzKAYgjB6nytlXOsXedixao6SVJardNcRtR89ybymXCkdEJW 544qRUr6CI0DC6bPB7pAXIiVC2B66ZLlXum118uQg06N3Y9zPIimNVbSKNx5HKseoche SXPQ==
X-Gm-Message-State: ALoCoQk4gSwWZGsL7C9oVbXg01LHMO7UhHvqGnqK+zM2cqPwZ2S3g5QJzqDT0T0qfLdSdLtkeUtb
X-Received: by 10.50.112.73 with SMTP id io9mr41698524igb.18.1432779628821; Wed, 27 May 2015 19:20:28 -0700 (PDT)
Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com. [209.85.223.173]) by mx.google.com with ESMTPSA id qt1sm1028738igb.5.2015.05.27.19.20.26 for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 May 2015 19:20:27 -0700 (PDT)
Received: by iepj10 with SMTP id j10so27982169iep.3 for <mmusic@ietf.org>; Wed, 27 May 2015 19:20:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.43.89.133 with SMTP id be5mr6904296icc.2.1432779625981; Wed, 27 May 2015 19:20:25 -0700 (PDT)
Received: by 10.36.89.70 with HTTP; Wed, 27 May 2015 19:20:25 -0700 (PDT)
In-Reply-To: <55665BFA.4020600@nteczone.com>
References: <7594FB04B1934943A5C02806D1A2204B1D852384@ESESSMB209.ericsson.se> <55634C34.4080304@alum.mit.edu> <5565838D.2020005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D866141@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E7D3EEB@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAD5OKxuEpmMVfScf62bs=y+9PyYbejfa2OmsHYq=dStTZmjdVg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D8689E9@ESESSMB209.ericsson.se> <55665BFA.4020600@nteczone.com>
Date: Wed, 27 May 2015 22:20:25 -0400
Message-ID: <CAD5OKxsukfKG=bW-5QWu35AQQX_Eve8YM0cQ=xc=B=obnzKQdQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christian Groves <Christian.Groves@nteczone.com>
Content-Type: multipart/alternative; boundary=bcaec5196a2da5f48b05171b00c3
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/BdLSeCWy4zvFIDhXVrgj2gvuQHM>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 02:20:31 -0000

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 <
Christian.Groves@nteczone.com> 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:roman@telurix.com>
>> Sent: ‎27/‎05/‎2015 23:31
>> To: Makaraju, Maridi Raju (Raju) <mailto:Raju.Makaraju@alcatel-lucent.com
>> >
>> Cc: Christer Holmberg <mailto:christer.holmberg@ericsson.com>; Christian
>> Groves <mailto:Christian.Groves@nteczone.com>; mmusic@ietf.org <mailto:
>> mmusic@ietf.org>gt;; pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
>> Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
>>
>>
>>
>> On Wed, May 27, 2015 at 7:37 AM, Makaraju, Maridi Raju (Raju) <
>> Raju.Makaraju@alcatel-lucent.com <mailto:Raju.Makaraju@alcatel-lucent.com>>
>> 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
>>
>>
>