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

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 25 May 2015 07:14 UTC

Return-Path: <christer.holmberg@ericsson.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 4589A1B2AF6 for <mmusic@ietfa.amsl.com>; Mon, 25 May 2015 00:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 e0aM-YRYT_hg for <mmusic@ietfa.amsl.com>; Mon, 25 May 2015 00:14:49 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250A81B2AF7 for <mmusic@ietf.org>; Mon, 25 May 2015 00:14:48 -0700 (PDT)
X-AuditID: c1b4fb2d-f794d6d000004501-a2-5562cbe6cce0
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EB.CD.17665.6EBC2655; Mon, 25 May 2015 09:14:47 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Mon, 25 May 2015 09:14:46 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christian Groves <Christian.Groves@nteczone.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Bundling data channel and RTP? - Text proposal
Thread-Index: AdCWueoLsROxlWDYR6SbmQrUuOlHng==
Date: Mon, 25 May 2015 07:14:46 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D852384@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvre7z00mhBssP8lp8ed/IYjF1+WMW ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSvjx+GHrAU3lCrurXJtYPwr3cXIySEhYCLx 69BLZghbTOLCvfVsXYxcHEICRxklbn0+zQrhLGaU+NLTyNTFyMHBJmAh0f1PG6RBRCBaYtLC ZjYQW1jAReLXkh4WiLirxIrnv5khbD2Jn20PWUFsFgFVic8TfzGC2LwCvhITl5xjArEZgRZ/ P7UGzGYWEJe49WQ+E8RBAhJL9pyHOk5U4uXjf6wQtpLE2sPbWSDq9SRuTJ3CBmFrSyxb+JoZ Yr6gxMmZT1gmMArPQjJ2FpKWWUhaZiFpWcDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMj MOgPbvmtu4Nx9WvHQ4wCHIxKPLwKTUmhQqyJZcWVuYcYpTlYlMR5vbpCQoUE0hNLUrNTUwtS i+KLSnNSiw8xMnFwSjUwMt/s2eXYdiBzybP9K++fmcqR8PyWVJPY52sMUWpduVozFl7xYaqr 2724tmBGIOf5OzsWnRLUupod9TlhavVb0WK250UxVf+1Vl8yn2N5cX+dzpmdXfznhE4uWaYU vebjhaXODe7fmmd+bVINbt33VfbJtn9JezvStkTti+N80jg9szC7pMxvnRJLcUaioRZzUXEi AIHoAOdbAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/nKs9XKeb1jKcxsHCLPpqa54DijQ>
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: Mon, 25 May 2015 07:14:54 -0000

Hi,

Below is a suggestion for a "DTLS considerations" section. Let me know if you think there are more rules/restrictions that we should document.

--------------------

X.  DTLS Considerations

	One or more media streams within a BUNDLE group can use
	the Datagram Transport Layer Security (DTLS) protocol [RFC6347]
	in order to encrypt the data, or to negotiate encryption keys
	if another encryption mechanism is used to encrypt media.

	When DTLS is used for more than one media stream within a BUNDLE
	group, the following rules apply:

	o  A single DTLS association [RFC6347] MUST be used for all media
	using DTLS; and
	
   	o  Each media protocol using DTLS MUST use the same mechanism for
	determining which endpoint (the offerer or answerer) becomes DTLS client and DTLS server.

--------------------

Regards,

Christer   



-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 25 May 2015 04:59
To: Christian Groves; mmusic@ietf.org
Subject: Re: [MMUSIC] Bundling data channel and RTP?

Hi,

I wonder whether we should have a "DTLS considerations" section in BUNDLE, and specify that all bundled media MUST use the same DTLS connection for key management, encryption etc.

Would it even be possible to establish multiple DTLS connections on a single 5-tuple?

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves
Sent: 22 May 2015 10:20
To: mmusic@ietf.org
Subject: Re: [MMUSIC] Bundling data channel and RTP?

Hello Magnus and Martin,

Thanks for confirming that.

It would be good to cover bundling the SRTP and DTLS/SCTP m-lines the BUNDLE and JSEP drafts.

Regards, Christian



On 20 May 2015 at 17:21, Christian Groves<Christian.Groves@nteczone.com>  wrote:

> Can anyone confirm the intention that a single DTLS connection is used 
> for SRTP key exchange and also SCTP packets?

Yes, the record layer carries SCTP and exporters from the same session are used to key SRTP.



On 21/05/2015 7:34 PM, Magnus Westerlund wrote:
> Christian Groves skrev den 2015-05-21 02:21:
>> Can anyone confirm the intention that a single DTLS connection is 
>> used for SRTP key exchange and also SCTP packets?
>>
>> draft-ietf-rtcweb-transports-08 indicates:
>>
>> /WebRTC implementations MUST support multiplexing of DTLS and RTP over//
>> //   the same port pair, as described in the DTLS_SRTP specification//
>> //   [RFC5764], section 5.1.2.  All application layer protocol 
>> payloads//
>> //   over this DTLS connection are SCTP packets./
>>
>> To me this implies a single DTLS connection. However in RFC5764 
>> clause
>> 4.1 it says:
>> /Once the "use_srtp" extension is negotiated, the RTP or RTCP//
>> //   application data is protected solely using SRTP. Application 
>> data is//
>> //   never sent in DTLS record-layer "application_data" packets.  
>> Rather,//
>> //   complete RTP or RTCP packets are passed to the DTLS stack, which//
>> //   passes them to the SRTP stack, which protects them appropriately.//
>> /
>> In the second sentence "application data" is not qualified with "RTP 
>> or RTCP" so it could be taken that its not possible to use the DTLS 
>> connection for anything else. However I take it that as the rest of 
>> the paragraph talks about RTP or RTCP that these were meant when 
>> application data is mentioned?
>>
>> Can only one add some clarity?
>>
>
> Yes, that is clearly the intention as I understand it in WebRTC.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic