Re: [rtcweb] JSEP: Why always offer actpass?
Christer Holmberg <christer.holmberg@ericsson.com> Thu, 04 December 2014 13:42 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0141AD38A for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 05:42:48 -0800 (PST)
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 sxsx_Af_fOyc for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 05:42:43 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA9E1A8976 for <rtcweb@ietf.org>; Thu, 4 Dec 2014 05:42:42 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-44-548064d03dde
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 4C.62.29772.0D460845; Thu, 4 Dec 2014 14:42:40 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 14:42:38 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Justin Uberti <juberti@google.com>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAHfyaaUAACD+YAAA3cSQP//9fwA///u34D//2vgsA==
Date: Thu, 04 Dec 2014 13:42:38 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se>
References: <1447FA0C20ED5147A1AA0EF02890A64B1D0D579E@ESESSMB209.ericsson.se> <CAOJ7v-1ztXies0-W3B2=zWaydeLTuR8tU7v15nqyTw+MwGE+rw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5A4B@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E63C45B@US70UWXCHMBA02.zam.alcatel-lucent.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0D5FB6@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E63C90D@US70UWXCHMBA02.zam.alcatel-lucent.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se> <CAD5OKxskhmnHO6rLB4t7vM6Y=fVf0PwYPXsfONJjM=wzx8vHoA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D53F719@ESESSMB209.ericsson.se> <CAD5OKxt+3Tn1SiHu7u_t7AixBVS1ev0Z=vdZg0mMwmm-Tg74yA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D54BB03@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E64233E@US70UWXCHMBA02.zam.alcatel-lucent.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E6423CC@US70UWXCHMBA02.zam.alcatel-lucent.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@ESESSMB209.ericsson.se> <CAOJ7v-191C=Jsf0vuBomgKXMYGRakatP9QS+mMYG1Try59yYrg@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D577322@ESESSMB209.ericsson.se> <CAOJ7v-2d0qMaWhNThW=ywfmBMp-7LMJNhi-fj8USk5D0=2RwCA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D577B77@ESESSMB209.ericsson.se> <CAOJ7v-3u6nL5J8wYpWN9SS8DboMh4WNYznJS-24TepZRweJz0w@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D577CB5@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D577CB5@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.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D578C4DESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3RvdCSkOIwdSNYhZbpwpZrP3Xzu7A 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgy1h+7yljwbSpzxZLZQg2Ma7qZuxg5OSQETCQW P1rEAmGLSVy4t54NxBYSOMIoceoBH4S9mFHi94nMLkYODjYBC4nuf9ogYRGBGIlffXcYQWxm AXWJO4vPsYPYwgKmEu/nHmGGqDGTWHhyAiOEHSax4kkXWJxFQEXi3NJJYPW8Ar4Su142AsW5 gFat55G49f4pWIJTwE9i9bsPYM2MQLd9P7WGCWKZuMStJ/OZIG4WkFiy5zzUL6ISLx//YwW5 U0JASWLa1jSI8nyJs4/uM0PsEpQ4OfMJywRG0VlIJs1CUjYLSdksoEnMApoS63fpQ5QoSkzp fsgOYWtItM6Zy44svoCRfRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYJwd3PLbYAfjy+eO hxgFOBiVeHgNz9WHCLEmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGxu5T2ldXLTXVzzXOrJA1CYvPd5taY2FiW8U3UUI/cmXpPTFxVqelTOt5yw45XWebY6Zi /t1UonKmW5Tjx709fc9WrimOP//306H1+rs+vf4/8YKWl6WBBP/fGfLm6yt3fcmdLu4xX2XX Y41QLoULq9aIyM5NUA1Z0H08Q3StsEfHxLe1ipJ3lViKMxINtZiLihMBfaAlTZQCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YzRWPlmQdIL8gFHlDrZAdrIMlaQ
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP: Why always offer actpass?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Dec 2014 13:42:48 -0000
What about the following text: 8.3.2. TLS Role Determination If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', the SDP setup attribute [RFC4145] is used to determine the 'active/ passive' status of the offerer and answerer. The 'active/passive' status will be used to determine the TLS roles, following the procedures in [RFC4572] (the 'active' endpoint will take the TLS client role). Once a DTLS connection has been established, if the 'active/passive' status of the endpoints change during a session, a new DTLS connection MUST be established. Therefore, endpoints SHOULD NOT change the ‘active/passive’ status in subsequent offers and answers, unless they want to establish a new DTLS connection (in which case the new 'active/passive' status of the offerer and answerer will be used to determine the TLS roles associated with the new DTLS connection). NOTE: The procedure above is identical to the one defined for SRTP- DTLS in [RFC5763]. Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 4. joulukuuta 2014 8:55 To: Justin Uberti Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Why always offer actpass? I’ve missed that. Awesome! :) So, if we’re ok with that approach, then we should use similar text in the SCTP-SDP draft. Regards, Christer From: Justin Uberti [mailto:juberti@google.com] Sent: 4. joulukuuta 2014 8:53 To: Christer Holmberg Cc: Stefan Håkansson LK; Makaraju, Maridi Raju (Raju); Roman Shpount; rtcweb@ietf.org<mailto:rtcweb@ietf.org> Subject: Re: [rtcweb] JSEP: Why always offer actpass? 5763, S 6.6 seems to imply that: Note that if the active/passive status of the endpoints changes, a new connection MUST be established. On Wed, Dec 3, 2014 at 10:30 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote: Hi, So, one suggestion would be to say that, IF one (there offerer or answerer) changes the previously negotiated roles, the DTLS connection MUST be re-established – even if the transport parameters etc aren’t changed. I think that would be a very useful clarification. Regards, Christer From: Justin Uberti [mailto:juberti@google.com<mailto:juberti@google.com>] Sent: 4. joulukuuta 2014 7:49 To: Christer Holmberg Cc: Stefan Håkansson LK; Makaraju, Maridi Raju (Raju); Roman Shpount; rtcweb@ietf.org<mailto:rtcweb@ietf.org> Subject: Re: [rtcweb] JSEP: Why always offer actpass? Currently, Chrome errors out (i.e. setRD fails). However, I suspect that teardown of the old DTLS association and setup of a new DTLS association is the desired behavior. On Wed, Dec 3, 2014 at 8:34 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote: Hi, Issue #72 talks about maintaining the previously negotiated role when actpass is received. I think that is a good approach, and could be used in Offer/Answer too. BUT, what does the browser do if e.g. the previous role is passive and active is received? Regards, Christer Sent from my Windows Phone ________________________________ From: Stefan Håkansson LK<mailto:stefan.lk.hakansson@ericsson.com> Sent: 03/12/2014 17:48 To: Justin Uberti<mailto:juberti@google.com> Cc: Makaraju, Maridi Raju (Raju)<mailto:Raju.Makaraju@alcatel-lucent.com>; Christer Holmberg<mailto:christer.holmberg@ericsson.com>; Roman Shpount<mailto:roman@telurix.com>; rtcweb@ietf.org<mailto:rtcweb@ietf.org> Subject: Re: [rtcweb] JSEP: Why always offer actpass? On 01/12/14 18:26, Justin Uberti wrote: > > > On Sun, Nov 30, 2014 at 7:26 AM, Stefan Håkansson LK > <stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com> > <mailto:stefan.lk.hakansson@ericsson.com>> wrote: > > On 30/11/14 16:06, Makaraju, Maridi Raju (Raju) wrote: > >> On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote: > >>>> Hi, > >>>> > >>>>>> RFC 7345 (UDPTL-DTLS) says the following: > >>>>>> > >>>>>> "Once an offer/answer exchange has been completed, either > >>>>>> endpoint > >>>> MAY > >>>>>> send a new offer in order to modify the session. The > >>>>>> endpoints > >>>> can > >>>>>> reuse the existing DTLS association if the key fingerprint > >>>>>> values > >>>> and > >>>>>> transport parameters indicated by each endpoint are unchanged. > >>>>>> Otherwise, following the rules for the initial offer/answer > >>>> exchange, > >>>>>> the endpoints can negotiate and create a new DTLS association > >>>>>> and, once created, delete the previous DTLS association, > >>>>>> following the same rules for the initial offer/answer exchange. > >>>>>> Each endpoint needs to be prepared to receive data on both the > >>>>>> new and old DTLS associations as long as both are alive." > >>>>>> > >>>>>> So, I guess that can be read in a way that the setup attribute > >>>>>> as such > >>>> does not impact previously > >>>>>> negotiated TLS roles - unless the key fingerprint values and/or > >>>>>> transport > >>>> parameters are modified. > >>>>>> > >>>>>> The SCTP-SDP draft currently says that a subsequent offer must > >>>>>> not change > >>>> the previously negotiated roles. But, I guess > >>>>>> we could say something similar as in RFC 7345. > >>>>> > >>>>> I have struggled with this language quite a bit from the > >>>>> implementation > >>>> perspective. I think we need to explicitly state > >>>>> that endpoints MUST reuse the existing association if the key > >>>>> fingerprint > >>>> values and transport parameters indicated > >>>>> by each endpoint are unchanged. > >>>> > >>>> We could take such general approach. > >>>> > >>>> However, for 'SCTP/DTLS' (DTLS over SCTP), I assume that the DTLS > >>>> connection will also be re-established if the underlying SCTP > >>>> association is re- established - even if no transport parameters > >>>> etc are changed. > >>>> > >>>> Also, RFC 6083 says: > >>>> > >>>> "Each DTLS connection MUST be established and terminated > within the > >>>> same SCTP association." > >>>> > >>>> > >>>>> The way this language reads to me is that endpoints can reuse the > >>>>> existing > >>>> association if they want to, but they can create a new one if they > >>>> don't. Also, when this new > >>>>> association is created, it is unclear if old setup roles MUST be > >>>>> preserved > >>>> or if they MUST be selected based on the current offer/answer > >>>> exchange. It seems the current > >>>>> specification language is not strong or clear enough on this > >>>>> topic. > >>>> > >>>> In my opinion, IF a new DTLS connection needs to be established > >>>> (for whatever reasons), the current roles should be used. > >>> > >>> <Raju> When ICE is NOT used, how does the offerer know that the > >>> answerer does not change the fingerprint and/or transport > parameters? > >>> I guess it does not know. So, offerer has to be prepared for > new DTLS > >>> association by offering actpass. When ICE is used, the answerer > can't > >>> change transport parameter unless offerer does ICE restart (which > >>> changes offerer transport parameters); Ref [1] is very clear on > this > >>> indicating "DTLS handshake procedure is repeated". However, > even when > >>> ICE is used, I do not find any restriction about answerer not > >>> changing fingerprint. So, even without ICE restart answerer can > >>> trigger a DTLS renegotiation by changing its fingerprint. > >>> > >>> To conclude all this, IMO whether ICE is used or not, sending > actpass > >>> for all new offers may be cover all possible scenarios. > >> > >> That is also my conclusion based on the discussion so far. > >> > >> I also think the JSEP draft as far as detailed out is correct, > but info > >> about how the implementation should behave for Subsequent answers is > >> missing. Text saying that the role must be maintained (unless > there is > >> an ICE restart) should be put in there. > > > > <Raju> > > Hi Stefan, > > Looks like, there is some misunderstanding here. > > Probably my fault in that case :) > > > My conclusion is to include > > actpass, but not the previously negotiated role, in all subsequent offers, > > not just during ICE-restarts. > > I think that is what the JSEP draft says - and my conclusion is that it > _is_ correct. > > My point was that the _answer_ should (when it is a subsequent answer) > should say the same role as in previous answers (unless there is an ICE > restart). > > I agree the JSEP text should indicate that roles should stay the same. > We have had this as a TODO for a while: > https://github.com/rtcweb-wg/jsep/issues/72 Great. I should have checked that out before.
- [rtcweb] JSEP: Why always offer actpass? Stefan Håkansson LK
- Re: [rtcweb] JSEP: Why always offer actpass? Justin Uberti
- Re: [rtcweb] JSEP: Why always offer actpass? Stefan Håkansson LK
- Re: [rtcweb] JSEP: Why always offer actpass? Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] JSEP: Why always offer actpass? Stefan Håkansson LK
- Re: [rtcweb] JSEP: Why always offer actpass? Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] JSEP: Why always offer actpass? Stefan Håkansson LK
- Re: [rtcweb] JSEP: Why always offer actpass? Roman Shpount
- Re: [rtcweb] JSEP: Why always offer actpass? Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Roman Shpount
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] JSEP: Why always offer actpass? Stefan Håkansson LK
- Re: [rtcweb] JSEP: Why always offer actpass? Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] JSEP: Why always offer actpass? Stefan Håkansson LK
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] JSEP: Why always offer actpass? Justin Uberti
- Re: [rtcweb] JSEP: Why always offer actpass? Stefan Håkansson LK
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Justin Uberti
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Justin Uberti
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Stefan Håkansson LK
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Stefan Håkansson LK
- Re: [rtcweb] JSEP: Why always offer actpass? Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Justin Uberti
- Re: [rtcweb] JSEP: Why always offer actpass? Christer Holmberg
- Re: [rtcweb] JSEP: Why always offer actpass? Makaraju, Maridi Raju (Raju)