IETF Logo Mail Archive

Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 30 September 2015 07:38 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 A12AD1A1BC9 for <mmusic@ietfa.amsl.com>; Wed, 30 Sep 2015 00:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 6PjQdsWRP6j9 for <mmusic@ietfa.amsl.com>; Wed, 30 Sep 2015 00:38: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 1A0F11A1BC6 for <mmusic@ietf.org>; Wed, 30 Sep 2015 00:38:48 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-88-560b91860dec
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 09.96.17026.6819B065; Wed, 30 Sep 2015 09:38:47 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.171]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 09:38:42 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?
Thread-Index: AdDx2gLCSWNnBQhESimZajIbwKOs+gIlWtiAAAgZAtAAE4UmAAADtCmAAAIjngAAFzeZoA==
Date: Wed, 30 Sep 2015 07:38:42 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37AE5E08@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B37A85E29@ESESSMB209.ericsson.se> <560A2FC9.5030809@nteczone.com> <786615F3A85DF44AA2A76164A71FE1ACDF7907B1@FR711WXCHMBA01.zeu.alcatel-lucent.com> <CAD5OKxvzw7P2x6D91mrGfkDcdvMAX+nawdJFUzU+K4k3JmysrA@mail.gmail.com> <560B01FB.2090809@alum.mit.edu> <CAD5OKxvt1bM1d-PpcE=MjQs=ABSpA4QaQYj4dcA_kQRRyH9L+g@mail.gmail.com>
In-Reply-To: <CAD5OKxvt1bM1d-PpcE=MjQs=ABSpA4QaQYj4dcA_kQRRyH9L+g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37AE5E08ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rrd9IneYwbarTBZTlz9msVix4QCr xYwLU5kdmD3+vv/A5LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyDi24wlKwKaWiYe5JlgbG K4ldjJwcEgImEr8ff2eDsMUkLtxbD2RzcQgJHGWUuLpvFyOEs4RR4vGHXSxdjBwcbAIWEt3/ tEEaRAS8Jfr6OthBwswC6hJXFweBhIWBwm/mr2SFKPGRWL73KJQdJvH8+F6wXSwCqhK3O2+x gNi8Ar4SuzY9YYFY9YlJ4tLtk8wgCU6BQImnz48ygtiMQMd9P7WGCcRmFhCXuPVkPhPE0QIS S/acZ4awRSVePv7HCnKPhICixPJ+OYjyfIlpb98xQewSlDg58wnLBEbRWUgmzUJSNgtJ2Syw zzQl1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2M wOg7uOW37g7G1a8dDzEKcDAq8fAqOHGHCbEmlhVX5h5ilOZgURLnbWF6ECokkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBcUnnt1Bhgcp8oc2rp82+u1T1L+/dBTa7PZqNbxv/Tfx//rTFt8s8 ccmdskULNzB3rT4cNv2zRLNXdcIyo3WTZpnudq/LbJw3jzk/zf/ySafrdfP8Z8azeQUIHpdb Yap25dyNba3RaRv7z/371GqSv26W8EOFr3a82oXp5so7YwrkeObkNMbFKrEUZyQaajEXFScC ADByBXufAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/q7PLYHAk9mUgaOq4zLmiileA3qg>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 30 Sep 2015 07:38:51 -0000

Hi,

The scope of the document is to define generic SDP offer/answer procedures for DTLS. That includes re-using/clarifying the existing procedures in DTLS-SRTP as much as possible, and make some technical changes (mainly related to how/if a change transport address information affects a DTLS association), and define an attribute that can be used to explicitly indicate whether to create a new DTLS association.

The intention is NOT to change the existing setup attribute, or do to anything else.

Regards,

Christer

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 30. syyskuuta 2015 1:28
To: Paul Kyzivat
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

On Tue, Sep 29, 2015 at 5:26 PM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:
This proposal is good except that it is unclear how to deduce which
version of connection or setup attribute is supported by the remote end
point. Without such indication there is a high chance that remote end
point will not be able to correctly parse and process the connection or
setup attribute with transport suffix.

Can you clarify what situation you are concerned about?

As long as we are defining behavior for cases that aren't currently supported at all, then it is simply a matter of writing the specs the way we want them.

Are you concerned with backward compatibility with implementations in the wild?

I am concerned about existing implementations which are currently in the wild. There are plenty of implementations that do support "setup" attribute for DTLS (including all the WebRTC enabled browsers). If existing "setup" attribute would be extended to include the protocol suffix it will not be properly handled by current implementations. If setup attribute is used with protocol prefix, it is unclear if it will be correctly recognized by the remote party.

On the other hand we can definitely use protocol attribute syntax for the connection attribute for DTLS, since this behavior is not defined anywhere yet.

Also, please let me know if you need a more detailed explanation of dtls_ufrag option and its rational or if you simply need more time to get it sorted out.

Regards,
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email