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

Justin Uberti <juberti@google.com> Mon, 01 December 2014 17:26 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 45A191A86E9 for <rtcweb@ietfa.amsl.com>; Mon, 1 Dec 2014 09:26:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.088
X-Spam-Level:
X-Spam-Status: No, score=-1.088 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, MIME_8BIT_HEADER=0.3, 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 qh5w7oNcxg3R for <rtcweb@ietfa.amsl.com>; Mon, 1 Dec 2014 09:26:55 -0800 (PST)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895F71A86F6 for <rtcweb@ietf.org>; Mon, 1 Dec 2014 09:26:49 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id le20so4922453vcb.38 for <rtcweb@ietf.org>; Mon, 01 Dec 2014 09:26:48 -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=ur1MzORuc7PPRKPxJbGCSZi5rWIranjTJgvukvBzl8g=; b=m2RR1ouF5qFPlJaoESDE0SMIN2umpMesmT4AmM0OO/dm+BHq5a8D2cqoNIozA5Y2AD TfSXYj1y0uhlEZss/Nt1ISIzwslztVHh6YsKq+Zz3ATx6rOId5A9bKkPjiXEMY4EmZXI O/a57OPkKNyENuD9kRHt3R0PTMV25FNth88qIOgBWOqyj7mxL/lnR99gD5py1iGHzPmA IAa8FqJ0uKHJEjAoOCJuIygg9R0QoTWkhVFSj01v5RrNQ3V8ktR99lJQQw5lDvxy/QF5 0v+jEAq8vGdOc+Psz8n9erPQLTAy8B/G2MMOLti3aADpR9sUNpGr/OeaBX9bllt2kHbA pbOw==
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=ur1MzORuc7PPRKPxJbGCSZi5rWIranjTJgvukvBzl8g=; b=e3TIR6ATopCb0bYMU/6eHwQMgPXvNMFwVGIRPZF6/mi1VaIPU2W3UbP1fN83opJhKZ pfLpsOl2My4da5LdDnpOGx3RLBje/naijMvVPz3SaXsquvqQLflWP6ShFS0Wy88k/cN8 ChTnLkDUnqqpVdjGuMMh+kix6Wr9+WJp+EL5W+VTTt46/mmHdZbdTRHkmzvDwDQqT2hl vHklMqq7REzXbYY6nqaidnE1lDN5dfgLRLwVastGktY/EgnvbdtPpdm874qjrPWoMh0v y380eArYv51QTMuTCdhFUTdNnDXQyHGpHaCdYbYRcsR1HZSpZqjGcct17TVZuu2XWiGf zqDg==
X-Gm-Message-State: ALoCoQl5wKMWzXtyBLEydil61E9fm/GbETwDLj5eqtioHGPxm6HteD165xXVgRcyIkqEoCO/ACxz
X-Received: by 10.52.136.80 with SMTP id py16mr24458967vdb.54.1417454808197; Mon, 01 Dec 2014 09:26:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.237.130 with HTTP; Mon, 1 Dec 2014 09:26:28 -0800 (PST)
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0E39A9@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>
From: Justin Uberti <juberti@google.com>
Date: Mon, 1 Dec 2014 09:26:28 -0800
Message-ID: <CAOJ7v-191C=Jsf0vuBomgKXMYGRakatP9QS+mMYG1Try59yYrg@mail.gmail.com>
To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
Content-Type: multipart/alternative; boundary=bcaec52d4dad54169105092aea35
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HyQfLyZz2yUIMwkkM74blCR7WIk
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: Mon, 01 Dec 2014 17:26:57 -0000

On Sun, Nov 30, 2014 at 7:26 AM, Stefan Håkansson LK <
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


> > 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 mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>