Re: [rtcweb] JSEP: Why always offer actpass?

Justin Uberti <juberti@google.com> Thu, 04 December 2014 16:47 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 5C2DE1A024C for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 08:47:46 -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 s0JTjz6CnBMr for <rtcweb@ietfa.amsl.com>; Thu, 4 Dec 2014 08:47:42 -0800 (PST)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847F81A889A for <rtcweb@ietf.org>; Thu, 4 Dec 2014 08:47:37 -0800 (PST)
Received: by mail-vc0-f171.google.com with SMTP id hy4so8120830vcb.2 for <rtcweb@ietf.org>; Thu, 04 Dec 2014 08:47:36 -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=TM2hrgwHXVizG4e8HYrlt7LY/DKUiKKoXOauAoeCKZY=; b=bOjMhyVDk8ZTSn3XiNVWhbyq/ypX0A3DhfSfb1fu6VAqt7i6OTWDvq5JSE79CV4v9f xTNE60nxQbLyHiWFYnaq3U+qFBmRfEtsfS2AmFU/jthEVzGZrrNPvcmOU2edEESmj6Vl 1777mrfl+vWiXO7EfSWWKyID0Q7r8MmlS4v1NS7/InocTdQCjwSe0+cZM8vKlN9RE+lz 41e6ZGm6jiIbFCATIPeGt2rMJIsAPwZ7we9d1zXVCsooC3ortmB7CipRariPVOjZRjQu ER+Sd9ANbvh5sqJMUlt6PD6PXW3pdfq0nTIY9NU9K+LpUXApFD2YovS94gh50QRcyaiQ YQrA==
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=TM2hrgwHXVizG4e8HYrlt7LY/DKUiKKoXOauAoeCKZY=; b=a4MIpJtwBkCe7nV8IDvt3MJyiO12cUxpWJl9un2Y+51zApALHjQUNahVZXC+HqgI6k Q0JZFDmUm81BhK39i35C6osQr0xhYrxCHKCzuonEUvBcwncIkI8y7RKpGpUV6BbIDeWR g6iJ444XlxbhpcICXC+SMTR8vLWeJDXJrgK/GdsDxyCJGOgZNb4nT11ISdrKeQ04xpzW koJOCNlGbp9vAAMF9zxzg6sdUyBq0OU6blLwSUgsufM6ywX0k3y9eS5ytf6Qo+7y5BYx 4HkIG6gJQApTpa8FqMkMatDMW+YHNrS89/PxMPR/meetIm3GZYq+51f9HdSYqjCr8mwu morA==
X-Gm-Message-State: ALoCoQkYL2cie0mIToiwlhu91kqtqCyXge/MTY/Yjo9eDsBeNIy8+Xtz6q89Ug0TkZCF80QQGtUS
X-Received: by 10.220.178.3 with SMTP id bk3mr4753774vcb.16.1417711656537; Thu, 04 Dec 2014 08:47:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.237.130 with HTTP; Thu, 4 Dec 2014 08:47:16 -0800 (PST)
In-Reply-To: <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> <7594FB04B1934943A5C02806D1A2204B1D578C4D@ESESSMB209.ericsson.se>
From: Justin Uberti <juberti@google.com>
Date: Thu, 4 Dec 2014 08:47:16 -0800
Message-ID: <CAOJ7v-0i7zM_JODtEwVQptfFd6iYq3KJrPoUbUP4aA2dMpFemw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=001a11c1d370aeb142050966b7e2
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sZ0owVlLrTOB69lWDQnCuFe0PAU
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 16:47:46 -0000

Sorry, which document would this be going into?

On Thu, Dec 4, 2014 at 5:42 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>  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 <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
> *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> 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]
> *Sent:* 4. joulukuuta 2014 7:49
> *To:* Christer Holmberg
> *Cc:* Stefan Håkansson LK; Makaraju, Maridi Raju (Raju); Roman Shpount;
> 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> 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>om>; Christer
> Holmberg <christer.holmberg@ericsson.com>om>; Roman Shpount
> <roman@telurix.com>om>; 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.
>
>
>
>
>