From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?=
 <stefan.lk.hakansson@ericsson.com>
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>,
 Christer Holmberg <christer.holmberg@ericsson.com>, Roman Shpount
 <roman@telurix.com>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JA==
Date: Sun, 30 Nov 2014 14:20:56 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D0E3909@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>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/y3TUxLbLonIbjgwh65ZqP5p7ygo
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] JSEP: Why always offer actpass?
Precedence: list

On 30/11/14 14:51, Makaraju, Maridi Raju (Raju) wrote:=0A=
>> Hi,=0A=
>>=0A=
>>>> RFC 7345 (UDPTL-DTLS) says the following:=0A=
>>>>=0A=
>>>> "Once an offer/answer exchange has been completed, either=0A=
>>>> endpoint=0A=
>> MAY=0A=
>>>> send a new offer in order to modify the session.  The=0A=
>>>> endpoints=0A=
>> can=0A=
>>>> reuse the existing DTLS association if the key fingerprint=0A=
>>>> values=0A=
>> and=0A=
>>>> transport parameters indicated by each endpoint are unchanged.=0A=
>>>> Otherwise, following the rules for the initial offer/answer=0A=
>> exchange,=0A=
>>>> the endpoints can negotiate and create a new DTLS association=0A=
>>>> and, once created, delete the previous DTLS association,=0A=
>>>> following the same rules for the initial offer/answer exchange.=0A=
>>>> Each endpoint needs to be prepared to receive data on both the=0A=
>>>> new and old DTLS associations as long as both are alive."=0A=
>>>>=0A=
>>>> So, I guess that can be read in a way that the setup attribute=0A=
>>>> as such=0A=
>> does not impact previously=0A=
>>>> negotiated TLS roles - unless the key fingerprint values and/or=0A=
>>>> transport=0A=
>> parameters are modified.=0A=
>>>>=0A=
>>>> The SCTP-SDP draft currently says that a subsequent offer must=0A=
>>>> not change=0A=
>> the previously negotiated roles. But, I guess=0A=
>>>> we could say something similar as in RFC 7345.=0A=
>>>=0A=
>>> I have struggled with this language quite a bit from the=0A=
>>> implementation=0A=
>> perspective. I think we need to explicitly state=0A=
>>> that endpoints MUST reuse the existing association if the key=0A=
>>> fingerprint=0A=
>> values and transport parameters indicated=0A=
>>> by each endpoint are unchanged.=0A=
>>=0A=
>> We could take such general approach.=0A=
>>=0A=
>> However, for =91SCTP/DTLS=92 (DTLS over SCTP), I assume that the DTLS=0A=
>> connection will also be re-established if the underlying SCTP=0A=
>> association is re- established - even if no transport parameters=0A=
>> etc are changed.=0A=
>>=0A=
>> Also, RFC 6083 says:=0A=
>>=0A=
>> =93Each DTLS connection MUST be established and terminated within the=0A=
>> same SCTP association.=94=0A=
>>=0A=
>>=0A=
>>> The way this language reads to me is that endpoints can reuse the=0A=
>>> existing=0A=
>> association if they want to, but they can create a new one if they=0A=
>> don't. Also, when this new=0A=
>>> association is created, it is unclear if old setup roles MUST be=0A=
>>> preserved=0A=
>> or if they MUST be selected based on the current offer/answer=0A=
>> exchange. It seems the current=0A=
>>> specification language is not strong or clear enough on this=0A=
>>> topic.=0A=
>>=0A=
>> In my opinion, IF a new DTLS connection needs to be established=0A=
>> (for whatever reasons), the current roles should be used.=0A=
>=0A=
> <Raju> When ICE is NOT used, how does the offerer know that the=0A=
> answerer does not change the fingerprint and/or transport parameters?=0A=
> I guess it does not know. So, offerer has to be prepared for new DTLS=0A=
> association by offering actpass. When ICE is used, the answerer can't=0A=
> change transport parameter unless offerer does ICE restart (which=0A=
> changes offerer transport parameters); Ref [1] is very clear on this=0A=
> indicating "DTLS handshake procedure is repeated". However, even when=0A=
> ICE is used, I do not find any restriction about answerer not=0A=
> changing fingerprint. So, even without ICE restart answerer can=0A=
> trigger a DTLS renegotiation by changing its fingerprint.=0A=
>=0A=
> To conclude all this, IMO whether ICE is used or not, sending actpass=0A=
> for all new offers may be cover all possible scenarios.=0A=
=0A=
That is also my conclusion based on the discussion so far.=0A=
=0A=
I also think the JSEP draft as far as detailed out is correct, but info =0A=
about how the implementation should behave for Subsequent answers is =0A=
missing. Text saying that the role must be maintained (unless there is =0A=
an ICE restart) should be put in there.=0A=