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

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Fri, 28 November 2014 14:59 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.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 51E431A1A68 for <rtcweb@ietfa.amsl.com>; Fri, 28 Nov 2014 06:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.41
X-Spam-Level:
X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 kFeQDwLX8hbj for <rtcweb@ietfa.amsl.com>; Fri, 28 Nov 2014 06:59:13 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82891A000B for <rtcweb@ietf.org>; Fri, 28 Nov 2014 06:59:12 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id E46B58BD68D19; Fri, 28 Nov 2014 14:59:06 +0000 (GMT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sASEx3OS032349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 09:59:08 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 09:59:05 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>, Justin Uberti <juberti@google.com>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JADFbzPw
Date: Fri, 28 Nov 2014 14:59:04 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E641248@US70UWXCHMBA02.zam.alcatel-lucent.com>
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>
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1D0D86B9@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HGMq7qEpdSoDISVMPKUqcP0W71w
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: Fri, 28 Nov 2014 14:59:15 -0000

> Thanks for a good overview!
> 
> On 25/11/14 19:30, Makaraju, Maridi Raju (Raju) wrote:
> >>
> >> Do you have an opinion on my main "topic": that subsequent offers
> >> should offer the already negotiated role, rather than always
> >> "actpass"?
> > [Raju] For non DTLS-SRTP associations, I think the key attribute here
> > is a=connection. If a subsequent offer has an explicit
> > "a=connection:existing" then per the reference[1] a=setup (and other
> > params) are ignored. Per [2] below, the default value for
> > a=connection is "new" in offer and answer. So, if an explicit
> > "a=connection:new" is present or "a=connection" is absent then, per
> > [3],  the existing association is closed and a new association will
> > be opened using new a=setup rules. Btw, I think section 7.3 of RFC
> > 4145 is just an example showing previously negotiated setup values
> > are used. But section 5.1 is normative and clearly says these
> > attributes must be ignored for a=connection:existing.
> >
> > Reference [4] and [5] are for DTLS-SRTP which does not allow
> > a=connection attribute and indicates new offer/answer compatibility
> > with old as the criteria to reuse or close/open new one. It also
> > notes that if a=setup changes then a new association is established.
> > This latter part also have to consider the a=setup defaults, which
> > may be different from previously negotiated values, if absent in new
> > offer/answer.
> 
> In this context we're dealing only with DTLS-SRTP I guess.
> 
> I read [5] as that subsequent offers should offer the negotiated role
> for existing connections (and not actpass), but I'm not sure. What is
> your interpretation?

<Raju>
IMO, the text does not say subsequent offer must send previously 
negotiated role. In fact there are issues in sending previously 
negotiated role.
The browser or the client is not aware if the sub-sequent offer
could result in an SDP answer which now have a new destination
address (e.g. a new middle box for conf), only the service logic 
in the communications server determines this.
To facilitate this, IMO, sending actpass is the right approach.
If it turns out to be SDP answer has not changed the destination,
fingerprint, and role (i.e. compatible to previous answer) then
previous association will continue to be used. This is per [6].

The above explanation is for DTLS-SRTP without use of ICE.
When ICE is used, if the destination is to be changed then 
per [6] ICE must be restarted. So, restarting ICE must also
set role as actpass instead of previously negotiated role.
When ICE is completed, the SDP answer to a subsequent offer 
can't change the Destination (m/c= lines) to a new 
candidate (it should be the selected candidate) unless ICE 
is restarted.
Please note that ICE restart can't be initiated in an SDP answer.

Unfortunately [7] did not talk about these interactions with ICE.

In conclusion, even for WebRTC use case of DTLS-SRTP, IMHO, it is better
if actpass is offered again for all cases independent of ICE restart.
The peer will simply respond to the previously negotiated role which
will keep the existing association.


[6] https://tools.ietf.org/html/rfc5245#section-9.1.1.1 
[7] https://tools.ietf.org/html/rfc5763#section-6.7.1

</Raju>

> 
> >
> > [1] https://tools.ietf.org/html/rfc4145#section-5.1
> >
> > "If the connection value resulting from an offer/answer exchange is
> > 'existing', the end-points continue using the existing connection.
> > Consequently, the port numbers, IP addresses, and 'setup' attributes
> > negotiated in the offer/answer exchange are ignored because there is
> > no need to establish a new connection."
> >
> > [2] https://tools.ietf.org/html/rfc4145#section-5.1 "The default
> > value of the connection attribute in both offers and answers is
> > 'new'. "
> >
> > [3] https://tools.ietf.org/html/rfc4145#section-5.2
> >
> > "If the connection value for an 'm' line resulting from an offer/
> > answer exchange is 'new', the endpoints SHOULD establish a new TCP
> > connection as indicated by the 'setup' attribute.  If a previous TCP
> > connection is still up, the endpoints SHOULD close it as soon as the
> > offer/answer exchange is completed.  It is up to the application to
> > ensure proper data synchronization between the two TCP connections."
> >
> > [4] DTLS SRTP RFC https://tools.ietf.org/html/rfc5763#section-5 " The
> > endpoint MUST NOT use the connection attribute defined in
> > [RFC4145]."
> >
> > [5] https://tools.ietf.org/html/rfc5763#section-6.6 "The peers can
> > reuse the existing associations if they are compatible (i.e., they
> > have the same key fingerprints and transport parameters), or
> > establish a new one following the same rules are for initial
> > exchanges, tearing down the existing association as soon as the
> > offer/answer exchange is completed.  Note that if the active/passive
> > status of the endpoints changes, a new connection MUST be
> > established."
> >
> > BR Raju
> >