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

Christian Groves <Christian.Groves@nteczone.com> Thu, 28 May 2015 00:06 UTC

Return-Path: <Christian.Groves@nteczone.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 E4EE91B2AFC for <mmusic@ietfa.amsl.com>; Wed, 27 May 2015 17:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mpZdxNHQZ__J for <mmusic@ietfa.amsl.com>; Wed, 27 May 2015 17:06:31 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56431B2AFB for <mmusic@ietf.org>; Wed, 27 May 2015 17:06:30 -0700 (PDT)
Received: from ppp118-209-70-122.lns20.mel4.internode.on.net ([118.209.70.122]:49940 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <Christian.Groves@nteczone.com>) id 1YxlL4-002Wq0-V3; Thu, 28 May 2015 10:06:23 +1000
Message-ID: <55665BFA.4020600@nteczone.com>
Date: Thu, 28 May 2015 10:06:18 +1000
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>, Roman Shpount <roman@telurix.com>, "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.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>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8689E9@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1256"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/yEjD38iUfQ-FS9HQqTR76K6kLhg>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
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 00:06:33 -0000

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>; 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
>