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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 04 December 2014 04:34 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 549081A0053 for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 20:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level:
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 eJdLB2RFe9Ap for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 20:34:29 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828CF1A0047 for <rtcweb@ietf.org>; Wed, 3 Dec 2014 20:34:28 -0800 (PST)
X-AuditID: c1b4fb2d-f79fc6d000001087-87-547fe452aa49
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.12.04231.254EF745; Thu, 4 Dec 2014 05:34:26 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 05:34:26 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Justin Uberti <juberti@google.com>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JAHfyaaU
Date: Thu, 04 Dec 2014 04:34:25 +0000
Message-ID: <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>
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0EE2BC@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D577322ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGfG3RjfoSX2Iwc45qhZbpwpZNGy8wmox 48JUZou1/9rZHVg8Wp/tZfVYsKnUY8mSn0wet6YUBLBEcdmkpOZklqUW6dslcGVc7P7DUvDt ImPFlA8zWBsYN5xh7GLk5JAQMJHYt7aRDcIWk7hwbz2QzcUhJHCEUeL541lQzmJGiZlLWpm7 GDk42AQsJLr/aYM0iAiUShxY9IkVxGYWmMgo8XCGB4gtLGAq8X7uEWaIGjOJhScnMELYRhKL /v4DG8MioCJx/H4WSJhXwFfizPctLBCrLnNKTJl5CWwmp4CfRN/BXnYQmxHouO+n1jBB7BKX aPqykhXiaAGJJXvOM0PYohIvH/+Duidf4sDL64wQCwQlTs58wjKBUWQWkvZZSMpmISmbBXQe s4CmxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJ ERh7B7f81t3BuPq14yFGAQ5GJR5eg3P1IUKsiWXFlbmHGKU5WJTEeRedmxcsJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgdEhIjorhFE0pqnv3QqXlAtnY9sics6a/n1qr/yhXbGv9d3xg9Uz nNbsrjkzK21b17tDKRni/9xmLo6ItlmRGaDwTWKydK3nDqvlMhP55tndLlmaVTNtXRPv2Q83 DL9mP2P5XZjL82+/1f/dBWX1mWv3t/YWTElinqN539mF1WYyZwC37KL4VCWW4oxEQy3mouJE ADiEUVmeAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Zfm1MJJaLasgctshxni_jk722So
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 04:34:33 -0000

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>> 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.