Re: [rtcweb] JSEP: Why always offer actpass?
Justin Uberti <juberti@google.com> Thu, 04 December 2014 05:49 UTC
Return-Path: <juberti@google.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 3BDE81A87AD for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 21:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 pw9P8hQQ52s6 for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 21:49:32 -0800 (PST)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354391A00AA for <rtcweb@ietf.org>; Wed, 3 Dec 2014 21:49:32 -0800 (PST)
Received: by mail-vc0-f181.google.com with SMTP id le20so7644009vcb.12 for <rtcweb@ietf.org>; Wed, 03 Dec 2014 21:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=njEcOnpfnqNwZtNIDbrNCYRob1jQgrmBydtoCcUmgSo=; b=Tjd4pYK+ooP73+gQZHcPA9PpE+iQc2ZLSBwHfFSDSiT3Ot+/eLmJ4tC+xvvzaCF93A wmRa4g5pTt+aIvIq6S7FZGJugGQ275PE3MpYpRNf4Eez2kkRZQDxwZNFRDas6QZkAfSt zdgsPY9dje7c0JVKI7pvoci279vQRZ0RehymSytnjFgng910ZzMAqfDzpWxtg46a09yk U0JLvKO9AX66kGs7gLJs7AJ960lNOTLT+A3AqdJbn6LPJnXPN/4MN129EXpLWGeitv7b T6It9qHmrChvIBH5FbSuKALUxqm+82epqh2qdCbSsuCbQu2KLayhnoKYF6EcqSmIR7f/ Qxig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=njEcOnpfnqNwZtNIDbrNCYRob1jQgrmBydtoCcUmgSo=; b=JZVP2VPLQ9svSu5HUy5VBfDzfvc8wixjpSrziQ3HyVh29YFI8+ZpOLY1BlG8WeXjcU IyE8EmpmmXL6pEs61d32ZoIKDwn1354E2dT2zquQe7vAgqLgh6BDMw9j5z4tXuiVEIYv LwvwtG35CizbFRbuDcO42zvstLkeU+HKSzA4RMFWJyZ56fenc5iOcA/Kga/xIkbHTc5e ie2fFQMUlaEVWkAQKEt3pb34Y/oV8D0IBDkpdFltkvLazIa98+J6uRXgO9aebTBS9AG5 +039xW74sQCPGhdMxXjdYT0CLeFwy0MhOteDmKPr9maFaY+P4HHpK9ziJOIKf59hwgwK vuLQ==
X-Gm-Message-State: ALoCoQmCrqb41MIIO9yJlsNb2b7X2RmfJOxEOsG9kitJywTbEwZnee3nDxwHRNQt8aLwh2B5s+E8
X-Received: by 10.220.118.194 with SMTP id w2mr4914796vcq.24.1417672171300; Wed, 03 Dec 2014 21:49:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.237.130 with HTTP; Wed, 3 Dec 2014 21:49:11 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D577322@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>
From: Justin Uberti <juberti@google.com>
Date: Wed, 03 Dec 2014 21:49:11 -0800
Message-ID: <CAOJ7v-2d0qMaWhNThW=ywfmBMp-7LMJNhi-fj8USk5D0=2RwCA@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a1132f4ba2dc8eb05095d8646"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NkLiCU26TQfSHxck07eqz_Z1DI4
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 05:49:35 -0000
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> 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 <stefan.lk.hakansson@ericsson.com> > Sent: 03/12/2014 17:48 > To: Justin Uberti <juberti@google.com> > Cc: Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>; Christer > Holmberg <christer.holmberg@ericsson.com>; Roman Shpount > <roman@telurix.com>; 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 > <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)