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

[Christer Holmberg <[e-mail]>]

Hi,

This would go into the SCTP-SDP draft. Sorry for not mentioning that :)

Regards,

Christer

From: Justin Uberti [mailto:[e-mail]]
Sent: 04 December 2014 18:47
To: Christer Holmberg
Cc: [e-mail]
Subject: Re: [rtcweb] JSEP: Why always offer actpass?

Sorry, which document would this be going into?

On Thu, Dec 4, 2014 at 5:42 AM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
What about the following text:


8.3.2.  TLS Role Determination

   If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', the
   SDP setup attribute [RFC4145] is used to determine the 'active/
   passive' status of the offerer and answerer.  The 'active/passive'
   status will be used to determine the TLS roles, following the
   procedures in [RFC4572] (the 'active' endpoint will take the TLS client
   role).

   Once a DTLS connection has been established, if the 'active/passive'
   status of the endpoints change during a session, a new DTLS
   connection MUST be established.  Therefore, endpoints SHOULD NOT
   change the ‘active/passive’ status in subsequent offers and answers,
   unless they want to establish a new DTLS connection (in which case
   the new 'active/passive' status of the offerer and answerer will be
   used to determine the TLS roles associated with the new DTLS
   connection).

   NOTE: The procedure above is identical to the one defined for SRTP-
   DTLS in [RFC5763].


Regards,

Christer


From: rtcweb [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Christer Holmberg
Sent: 4. joulukuuta 2014 8:55
To: Justin Uberti
Cc: [e-mail]<mailto:[e-mail]>

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

I’ve missed that. Awesome! :)

So, if we’re ok with that approach, then we should use similar text in the SCTP-SDP draft.

Regards,

Christer

From: Justin Uberti [mailto:[e-mail]]
Sent: 4. joulukuuta 2014 8:53
To: Christer Holmberg
Cc: Stefan Håkansson LK; Makaraju, Maridi Raju (Raju); Roman Shpount; [e-mail]<mailto:[e-mail]>
Subject: Re: [rtcweb] JSEP: Why always offer actpass?

5763, S 6.6 seems to imply that:

 Note that if the active/passive status of the endpoints changes, a new
 connection MUST be established.


On Wed, Dec 3, 2014 at 10:30 PM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

So, one suggestion would be to say that, IF one (there offerer or answerer) changes the previously negotiated roles, the DTLS connection MUST be re-established – even if the transport parameters etc aren’t changed. I think that would be a very useful clarification.

Regards,

Christer

From: Justin Uberti [mailto:[e-mail]<mailto:[e-mail]>]
Sent: 4. joulukuuta 2014 7:49
To: Christer Holmberg
Cc: Stefan Håkansson LK; Makaraju, Maridi Raju (Raju); Roman Shpount; [e-mail]<mailto:[e-mail]>

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

Currently, Chrome errors out (i.e. setRD fails).

However, I suspect that teardown of the old DTLS association and setup of a new DTLS association is the desired behavior.

On Wed, Dec 3, 2014 at 8:34 PM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
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:[e-mail]>
Sent: ‎03/‎12/‎2014 17:48
To: Justin Uberti<mailto:[e-mail]>
Cc: Makaraju, Maridi Raju (Raju)<mailto:[e-mail]>; Christer Holmberg<mailto:[e-mail]>; Roman Shpount<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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
> <[e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]>> 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.