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

From: Justin Uberti <[email-masked]>
Date: Mon, 1 Dec 2014 09:26:28 -0800

On Sun, Nov 30, 2014 at 7:26 AM, Stefan Håkansson LK <
[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 3 Dec 2014 15:48:45 +0000

On 01/12/14 18:26, Justin Uberti wrote:
>
>
> On Sun, Nov 30, 2014 at 7:26 AM, Stefan Håkansson LK
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > actpass, but not the previously negotiated role, in all subsequent offers,
> I agree the JSEP text should indicate that roles should stay the same.
> We have had this as a TODO for a while:

Great. I should have checked that out before.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 04:34:25 +0000

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:[email-masked]>
Sent: ‎03/‎12/‎2014 17:48
To: Justin Uberti<mailto:[email-masked]>
Cc: Makaraju, Maridi Raju (Raju)<mailto:[email-masked]>; Christer Holmberg<mailto:[email-masked]>; Roman Shpount<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] JSEP: Why always offer actpass?

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Dec 2014 21:49:11 -0800

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 <
[email-masked]> 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.
>
>  ------------------------------
> From: Stefan Håkansson LK <[email-masked]>
> To: Justin Uberti <[email-masked]>
> Cc: Makaraju, Maridi Raju (Raju) <[email-masked]>; Christer
> Holmberg <[email-masked]>; Roman Shpount
> <[email-masked]>; [email-masked]
> > <mailto:[email-masked]
> <[email-masked]>>> wrote:
> >

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 06:30:18 +0000

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:[email-masked]]
Sent: 4. joulukuuta 2014 7:49
To: Christer Holmberg
Cc: Stefan Håkansson LK; Makaraju, Maridi Raju (Raju); Roman Shpount; [email-masked]
Subject: Re: [rtcweb] JSEP: Why always offer actpass?

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

On 01/12/14 18:26, Justin Uberti wrote:
> <[email-masked]<mailto:[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Dec 2014 22:52:34 -0800

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 <
[email-masked]> 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:[email-masked]]
> *Sent:* 4. joulukuuta 2014 7:49
> *To:* Christer Holmberg
> *Cc:* Stefan Håkansson LK; Makaraju, Maridi Raju (Raju); Roman Shpount;
> [email-masked]
>
> *Subject:* Re: [rtcweb] JSEP: Why always offer actpass?
>
>
>
> However, I suspect that teardown of the old DTLS association and setup of
> a new DTLS association is the desired behavior.
>
>
>
> *From: *Stefan Håkansson LK <[email-masked]>
> *Sent: *‎03/‎12/‎2014 17:48
> *To: *Justin Uberti <[email-masked]>
> *Cc: *Makaraju, Maridi Raju (Raju) <[email-masked]>; Christer
> *Subject: *Re: [rtcweb] JSEP: Why always offer actpass?
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 06:55:22 +0000

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:[email-masked]]
Sent: 4. joulukuuta 2014 8:53
To: Christer Holmberg
Cc: Stefan Håkansson LK; Makaraju, Maridi Raju (Raju); Roman Shpount; [email-masked]
Subject: Re: [rtcweb] JSEP: Why always offer actpass?

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

Regards,

Christer

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

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 13:42:38 +0000

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:[email-masked]] On Behalf Of Christer Holmberg
Sent: 4. joulukuuta 2014 8:55
To: Justin Uberti
Cc: [email-masked]
Subject: Re: [rtcweb] JSEP: Why always offer actpass?

Regards,

Christer

Regards,

Christer

Regards,

Christer

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 4 Dec 2014 13:57:42 +0000

>     change the ‘active/passive’ status in subsequent offers and answers,

Did not the discussion (for rtcweb) conclude that subsequent offers 
should offer actpass, but that subsequent answers must say the same as 
the previous answer?

> *From:*rtcweb [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 4. joulukuuta 2014 8:55
> *To:* Justin Uberti
> *Cc:* [email-masked]
> *From:*Justin Uberti [mailto:[email-masked]]
> *Sent:* 4. joulukuuta 2014 8:53
> *To:* Christer Holmberg
> [email-masked] <mailto:[email-masked]>
> On Wed, Dec 3, 2014 at 10:30 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> Hi,
>
> 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:[email-masked]
> <mailto:[email-masked]>]
> [email-masked] <mailto:[email-masked]>
>
>
> 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
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> Hi,
>
> actpass is received. I think that is a good approach, and could be used
> in Offer/Answer too.
>
> ------------------------------------------------------------------------
>
> *From: *Stefan Håkansson LK <mailto:[email-masked]>
> *To: *Justin Uberti <mailto:[email-masked]>
> *Cc: *Makaraju, Maridi Raju (Raju)
> <mailto:[email-masked]>; Christer Holmberg
> <mailto:[email-masked]>; Roman Shpount
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> <[email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 14:08:03 +0000

Hi,

>>     If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', 
>>     the SDP setup attribute [RFC4145] is used to determine the 'active/
>>     procedures in [RFC4572] (the 'active' endpoint will take the TLS 
>>     client role).
>>
> Did not the discussion (for rtcweb) conclude that subsequent offers should offer actpass, but that subsequent answers must say the same as the previous answer?

In the Offer/Answer section, I can define more details regarding the values (actpass etc) to use.

BUT, the question is whether we want to allow the endpoints to trigger a new DTLS connection by changing the active/passive status or not. The text above says SHOULD NOT change the active/passive status.

Regards,

Christer

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 4 Dec 2014 14:42:58 +0000

>>> 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,
>>
>> should offer actpass, but that subsequent answers must say the same
>> as the previous answer?
>
> BUT, the question is whether we want to allow the endpoints to
> trigger a new DTLS connection by changing the active/passive status
> or not. The text above says SHOULD NOT change the active/passive
> status.

OK, makes sense to me.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 4 Dec 2014 15:15:23 +0000

> >>> SHOULD NOT change the 'active/passive' status in subsequent
> >>> offers and answers,
> >>

<Raju>
I am ok with it as well.

The strength "SHOULD NOT" seems intentional and I think that is right; so it is still allowed but not recommended.
May be obvious, but please be sure to mention that, independent of last offer/answer direction, new offerer SHOULD include actpass and answerer SHOULD answer with previously negotiated role.

</Raju>

BR
Raju

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 16:45:03 +0000

Hi,

>>>>> SHOULD NOT change the 'active/passive' status in subsequent offers 
>>>>> and answers,
>>>>

Yes.

> May be obvious, but please be sure to mention that, independent of last offer/answer direction, new 
> offerer SHOULD include actpass and answerer SHOULD answer with previously negotiated role.

Yes.

Of course, if the fingerprint and/or transport parameters change, a new DTLS connections MUST be established. And, in that case I guess it doesn't matter if the TLS roles are also re-negotiated?

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 4 Dec 2014 08:47:16 -0800

Sorry, which document would this be going into?

On Thu, Dec 4, 2014 at 5:42 AM, Christer Holmberg <
[email-masked]> wrote:

> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *From:* Justin Uberti [mailto:[email-masked] <[email-masked]>]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Dec 2014 16:56:13 +0000

Hi,

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

Regards,

Christer

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

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

Regards,

Christer

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

Regards,

Christer

Regards,

Christer

Regards,

Christer

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 4 Dec 2014 18:32:14 +0000

> Of course, if the fingerprint and/or transport parameters change, a new DTLS
> connections MUST be established. And, in that case I guess it doesn't matter
> if the TLS roles are also re-negotiated?

<Raju>
Especially for transport parameter changes (in SDP answer), it could be a different entity now doing the negotiation and needs fresh renegotiation of roles.
</Raju>

BR
Raju