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

[Stefan Håkansson LK <[e-mail]>]

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

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