Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?
"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Tue, 29 September 2015 08:24 UTC
Return-Path: <albrecht.schwarz@alcatel-lucent.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 3BC591A3B9F for <mmusic@ietfa.amsl.com>; Tue, 29 Sep 2015 01:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.31
X-Spam-Level:
X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ZiAo8Fbt8B06 for <mmusic@ietfa.amsl.com>; Tue, 29 Sep 2015 01:23:38 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CC21A3B9B for <mmusic@ietf.org>; Tue, 29 Sep 2015 01:23:35 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 49DD4F30E6BCE for <mmusic@ietf.org>; Tue, 29 Sep 2015 08:23:32 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t8T8NXUr005914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Tue, 29 Sep 2015 10:23:33 +0200
Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.183]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 29 Sep 2015 10:23:33 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?
Thread-Index: AdDx2gLCSWNnBQhESimZajIbwKOs+gIlWtiAAAgZAtA=
Date: Tue, 29 Sep 2015 08:23:33 +0000
Message-ID: <786615F3A85DF44AA2A76164A71FE1ACDF7907B1@FR711WXCHMBA01.zeu.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B37A85E29@ESESSMB209.ericsson.se> <560A2FC9.5030809@nteczone.com>
In-Reply-To: <560A2FC9.5030809@nteczone.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/9t9qNC5jJ225yv9OsWTky6hfB_8>
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: Tue, 29 Sep 2015 08:24:54 -0000
X-List-Received-Date: Tue, 29 Sep 2015 08:24:54 -0000
Hello Christer, there might be another approach by qualifying the "generic" attribute with protocol (stack) information. Paul made a good proposal as far as I remember: see Re: [MMUSIC] SCTP-SDP: SDP connection attribute considerations http://www.ietf.org/mail-archive/web/mmusic/current/msg14156.html => a=setup ... and "And do the same thing for a=connection." Regards, Albrecht -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves Sent: Dienstag, 29. September 2015 08:29 To: mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag? Hello Christer, I'm for keeping it simple and having a specific dtls_connection attribute. Regards, Christian On 18/09/2015 4:48 PM, Christer Holmberg wrote: > > Hi, > > Currently the draft-ietf-mmusic-dtls-sdp defines the usage of existing > SDP "connection" attribute for DTLS. The attribute is used to > explicitly indicate whether a new DTLS association shall be created or > not. > > One of the open questions is whether we should use existing > "connection" attribute for this purpose, define a new attribute > (working name: "dtls_connection") with similar semantics, or design a > new usage which is more robust in cases of 3PCC. > > Why would we use a different attribute? > > In most cases (e.g. UDP/DTLS) existing "connection" attribute works > well. However, if you layer other connection oriented protocols over > DTLS (e.g. 'SCTP/DTLS' or 'UDP/DTLS/SCTP') "connection" attribute > would apply to both the SCTP *and* DTLS layer. This might be an > acceptable usage, but are there use cases when DTLS connection would > need to be re-established, but SCTP connection still maintained? > > There are also more exotic use cases, when DTLS is layered over > connection oriented protocols (e.g. 'TCP/DTLS/SCTP'). In such cases > "connection" attribute would apply to the SCTP *AND* the DTLS *AND* > the TCP layer. > > Having a dedicated attribute would allow separate control over the > DTLS layer. E.g. in the case of 'UDP/DTLS/SCTP' it would be possible > to re-establish the SCTP association without touching the DTLS > association. > > Another option is to define a "ufrag" which identifies an end point in > DTLS association (working name: "dtls_ufrag"). Each endpoint in the > offer/answer exchange would generate its own "dtls-ufrag". If either > "dtls-ufrag" values changed, then new DTLS association would need to > be established. > > Why would we need something like this? > > ICE and 3PCC and oferless INVITEs. When ICE end point responds to an > offer-less INVITE, it will allocate new ufrag, collects the full set > of ICE candidates, but would still like to keep the existing DTLS > connection and local ICE candidates which it is currently using. It > will send the response with the generated answer with all this > information, but the value for old style "connection" SDP attribute is > unclear. If value "connection:new" is specified, none of the existing > ICE candidates can be used, complete new set would need to be > allocated to prevent transport pair reuse for multiple DTLS > associations, and new DTLS association would need to be created even > if the same two end-points get reconnected. If value > "connection:existing" is used, then existing DTLS association and > candidates can be used, but the generated offer cannot be used as an > initial offer to the new end point. > > If "dtls_ufrag" value is used, then in response to offer-less invite > the existing value of this attribute will be provided in the generated > offer. The answering party, if it is an end point which is already > communicating with the current end-point can respond with its current > "dtls_ufrag" value and the existing DTLS association will be re-used. > If answering party is a new end point which was not part of the > existing DTLS association, it will reply with new value of > "dtls_ufrag". Since one of the values changed, a new DTLS association > will be established. There is no risk of transport re-use for several > DTLS associations, since answering party will allocate a complete new > set of ICE candidates. > > What do you prefer, wasting resource in response to offer-less invite > and allocating a complete new set of ICE candidates every time such > INVITE is receive or dealing with a more complex attribute semantics? > > Comments? Preferences? > > Regards, > > Christer > > > > _______________________________________________ > 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
- [MMUSIC] DTLS-SDP: connection, dtls_connection, o… Christer Holmberg
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Paul Kyzivat
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Christian Groves
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Schwarz, Albrecht (Albrecht)
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Roman Shpount
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Paul Kyzivat
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Paul Kyzivat
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Roman Shpount
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Christer Holmberg
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Paul Kyzivat
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Roman Shpount
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Christer Holmberg
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Paul Kyzivat
- Re: [MMUSIC] DTLS-SDP: connection, dtls_connectio… Christer Holmberg