Re: [rtcweb] JSEP: Why always offer actpass?
Christer Holmberg <christer.holmberg@ericsson.com> Sun, 30 November 2014 15:29 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 563D31A0367 for <rtcweb@ietfa.amsl.com>; Sun, 30 Nov 2014 07:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level:
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 NEfFNlc2LgA5 for <rtcweb@ietfa.amsl.com>; Sun, 30 Nov 2014 07:29:09 -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 A37C11A0362 for <rtcweb@ietf.org>; Sun, 30 Nov 2014 07:29:08 -0800 (PST)
X-AuditID: c1b4fb30-f79d66d00000744c-db-547b37c2ae6d
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.00.29772.2C73B745; Sun, 30 Nov 2014 16:29:06 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 16:29:06 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, Roman Shpount <roman@telurix.com>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAEtdFdA
Date: Sun, 30 Nov 2014 15:29:05 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D55BDBE@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>
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@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.150]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje4h8+oQg5aL6hYNG6+wWsy4MJXZ Yu2/dnYHZo/WZ3tZPZYs+cnkcWtKQQBzFJdNSmpOZllqkb5dAlfG82N3GAu6dCt+d3xja2Dc o9LFyMkhIWAisenWBmYIW0ziwr31bCC2kMARRokzJ8y6GLmA7CWMEj//PWXvYuTgYBOwkOj+ pw0SFxHYySjxYccxFpAGZgF1iTuLz7GD2MICphLv5x4BGyoiYCax8OQERgjbSKK1ayoTiM0i oCrx6NlJsBpeAV+JhXNAekGWneKQWPLkC9hQTgE/iTN7r4FdxAh03fdTa5gglolL3Hoynwni agGJJXvOQ30gKvHy8T9WCFtJYsX2S4wQ9XoSN6ZOYYOwtSWWLXwNtVhQ4uTMJywTGMVmIRk7 C0nLLCQts5C0LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGFMHt/w22MH48rnjIUYB DkYlHt4NP6pChFgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD o/hct6aUXS9OXEmo+HF517TVt3OO12v2cLAqeVvXzWo9rvhObLaGjLiYhIVAd76Z4sljc4Im bf38lrmwY4lPr6BaVYgSR9WX/XujXhZ/k3q7+U7E7X/7DPb/dmphWcZgYXt/xQzfzVXVZefU uwNlHXrvPWY1eKfetiHv9pWvT28JWealX3gnocRSnJFoqMVcVJwIAM1CKNCKAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WC1YfmLFWKL2Tlb87nuzob0qxL0
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: Sun, 30 Nov 2014 15:29:11 -0000
Hi, If some clarification regarding this is needed, I don't think it should be in the JSEP draft. If it's related to SDP Offer/Answer in general, it should be in an MMUSIC spec, referenced by JSEP. Regards, Christer -----Original Message----- From: Stefan Håkansson LK Sent: 30 November 2014 17:27 To: Makaraju, Maridi Raju (Raju); Christer Holmberg; Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP: Why always offer actpass? 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). > This is to handle the scenario of answerer changing fingerprint, which > is allowed (i.e. not explicitly disallowed), in a more natural way by > renegotiating the roles. Entity which wants to change fingerprint may > also want to renegotiate the role even when transport parameters are not changed. > > Also, when ICE is not used answerer can change transport parameters > which needs renegotiation of roles. > > So, to have uniform rules for ICE (restart or not) and no ICE it is > better to send the role in subsequent offer as if it is an initial offer (i.e. actpass). That is also my understanding (and what the JSEP draft says). > </Raju> > > BR > Raju > >
- [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)