Subject: Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 01:21:30 +0000

Hi Albrecht,

If I understand your proposal correctly, the change would be to relax the rule for assigning the SDP setup attribute value in the SDP Offer. Instead of mandating actpass, we would also allow active and passive.

Right?

Regards,

Christer

Lähettäjä: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Lähetetty: 14. marraskuuta 2013 3:11
Vastaanottaja: Christer Holmberg
Kopio: [email-masked]; LANDAIS, BRUNO (BRUNO)
Aihe: AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hello Christer,
guess it's time to come back on this topic since the WG adopted the draft.

In brief ("don't want to repeat again the thread"):
a) problem statement: existing SDP O/A rules define a tighly coupled mode between the establishment direction of the SIP session and the establishment direction of the DTLS session, but there's not any reasoning for such tightly coupled behaviour.

b) change proposal:
Revise in clause 3.1 following list item

   o  The endpoint MUST use the SDP setup attribute [RFC4145].  The

      offerer MUST assign the SDP setup attribute with setup:actpass

      value, and MUST be prepared to receive a DTLS client_hello message

      before it receives the SDP answer.  The answerer MUST assign the

      SDP setup attribute with either setup:active value or

      setup:passive value.  The answerer SHOULD assign the SDP setup

      attribute with the setup:active value.  Whichever party is active

      MUST initiate a DTLS handshake by sending a ClientHello over each

      flow (host/port quartet).

by

   o  The endpoint MUST use the SDP setup attribute [RFC4145].  The

      offerer MUST assign the SDP setup attribute with a setup:actpass, setup:active or setup:passive

      value, and, in case of setup:actpass or setup:passive, MUST be prepared to receive a DTLS client_hello message

      before it receives the SDP answer.  The answerer MUST assign the

      SDP setup attribute with either setup:active value or

      setup:passive value.  The answerer SHOULD assign the SDP setup

      attribute with the setup:active value, in case of setup:actpass or setup:passive.  Whichever party is active

      MUST initiate a DTLS handshake by sending a ClientHello over each

      flow (host/port quartet).

We would limit ourselves with the existing, restrictive SDP O/A rule. And without any justification for such a constraint.

Any comments?

Regards,
Albrecht

________________________________
Von: Christer Holmberg [[email-masked]]
Gesendet: Montag, 7. Oktober 2013 13:11
An: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Betreff: VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS session
Hi Albrecht,

At this point, the community is making a decision about whether to start working on this.

Once that is done, we will start looking into, and discuss, individual technical issues etc, and your input will be highly appreciated.

Regards,

Christer

Lähettäjä: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Lähetetty: 7. lokakuuta 2013 13:56
Vastaanottaja: Christer Holmberg
Kopio: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Aihe: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hello Christer,
I may not commit to submit a problem statement in the next couple of weeks, just due to time reasons.
At least a note (or editor's note) should be added to draft mmusic-udptl-dtls in order to indicate the issue and that a solution proposal is still pending.

Thanks,
Albrecht

From: Christer Holmberg [mailto:[email-masked]]
Sent: Dienstag, 24. September 2013 16:01
To: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hi Albrecht,

I don't think putting a note somewhere in the fax draft is going to solve anything.

As you indicate, the issue exists in multiple documents, so it's a generic issues.

So, my suggestion is that you put together a short draft which describes the problem, and how you want to change it, and then we can have a more generic discussion about it. The WG can then decide whether we shall fix something, and if so, in which specs.

Regards,

Christer

________________________________
From: Schwarz, Albrecht (Albrecht) [[email-masked]]
Sent: Tuesday, 24 September 2013 4:22 PM
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session
Hello Christer,

the "copy & paste" action (across at least three "RFCs") seems to be the root cause of the issue :-(

SIP session establishment and L4 security session (DTLS, TLS) establishment directions should be principally decoupled because application specific.

We got here (wrt DTLS) three (different!) applications:
1) Key exchange (RFC 5763)
2) Conference control (rfc4582bis)
3) Document transmission (udptl-dtls)

All three applications are different in terms of number/type of supported network models, security models or/and communication topology.

Consequently, the basic, application independent SDP O/A rules for DTLS session establishment would need to support that flexibility.
The application specific SIP/SDP profile could then still narrow down the required SDP O/A rules.

What we got so far: SDP O/A rules in three application specific "RFCs" (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-(

There might be two options to correct that copy & paste issue in "udptl-dtls" in my opinion:
a) expand the SDP O/A rules for more flexibility
or
b) add a WARNING / NOTE about the inherent limitations (due to the assumption of a network and communication environment according RFC 5763)

What do you think?
Best regards,
Albrecht

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Montag, 23. September 2013 11:54
To: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hi Albrecht,

I don't know what model people were focusing on when writing RFC 5763, but the RFC does say:

"The endpoint that is the offerer MUST use the setup attribute value of setup:actpass"

...which we also copied into the udptl-dtls draft.

Now, if you want to change that, and allow the Offerer to "force" the direction, I think you should start a separate thread about that. Because, it is not specific to fax, in my opinion.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: 23. syyskuuta 2013 12:31
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hello Christer,

the decision about "DTLS session establishment direction" is ALWAYS up to the SDP ANSWERER (according present 3.1).

In order to decouple SIP session and DTLS session establishment directions, then the SDP OFFERER should also to be able to use "setup:active" and "setup:passive" (besides codepoint "setup:actpass") in my understanding.

I'm not sure whether the reference to RFC 5763 helps because I could imagine that the subject comes down to the indicated network scenarios, lets look again at:
a) T - T
b) T -GW

The existing udptl-dtls & RFC 5763 text seems to focus on model (a) only: SDP O/A between two peering, terminal located SIP UAs (there is NOT any SIP B2BUA).
But I could imagine that the SIP/SDP profiles for "T" and "GW" are not necessarily the same in case of model (b): "T" as SDP Offerer may not allowed to decide the DTLS session establishment direction, but "GW" as SDP offerer may need to enforce the DTLS session establishment direction (either way).

Regards,
Albrecht

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Donnerstag, 19. September 2013 10:02
To: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hi Albrecht,

The direction of the SIP session establishment and the DTLS session establishment are NOT tightly coupled. The draft enables the Answerer to select whether it wants to act as DTLS client or DTLS server.

Section 3.1 states:

.... The
offerer MUST assign the SDP setup attribute with setup:actpass value, and MUST be prepared to receive a DTLS client_hello message before it receives the SDP answer. The answerer MUST assign the SDP setup attribute with either setup:active value or setup:passive value. The answerer SHOULD assign the SDP setup attribute with the setup:active value. Whichever party is active MUST initiate a DTLS handshake by sending a ClientHello over each flow (host/port quartet).

The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we base the procedure on that RFC.

BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP procedures for DTLS server determination.

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

The T.38 endpoint could be located in a terminal (= T.38 IAF) or in a gateway, leading to three possible scenarios of
a) T - T
b) T -GW
c) GW-GW

I'd like to scope on scenario (b) due to its asymmetry of user- and network-side located T.38 endpoints.

Christer,
I thought that the two directions of
1) SIP session establishment and
2) DTLS session establishment
should be NOT tightly coupled (as currently supposed to be in clause 3.1)?
The ietf draft should offer the flexibility in decoupling both establishment directions.

E.g., there might be the demand to limit DTLS session establishment in T-to-GW direction (and apply rather the reverse direction) due ClientHello associated security threats, resource requests in terms of memory, ...

In my opinion:
the IETF should allow the flexibility,
other SDOs could still profile/limit this capability.

Best regards,
Albrecht

PS
We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects could influence TLS session establishment direction. However, I guess that NAT-T is minor for DTLS/UDP.

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 14 Nov 2013 01:10:54 +0000

Hello Christer,

b) change proposal:

by

Any comments?

Regards,
Albrecht

Cc: [email-masked]; LANDAIS, BRUNO (BRUNO)

Hi Albrecht,

Regards,

Christer

Hello Christer,
I may not commit to submit a problem statement in the next couple of weeks, just due to time reasons.
At least a note (or editor’s note) should be added to draft mmusic-udptl-dtls in order to indicate the issue and that a solution proposal is still pending.

Thanks,
Albrecht

Hi Albrecht,

Regards,

Christer

What do you think?
Best regards,
Albrecht

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Montag, 23. September 2013 11:54
To: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hi Albrecht,

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: 23. syyskuuta 2013 12:31
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hello Christer,

Regards,
Albrecht

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Donnerstag, 19. September 2013 10:02
To: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hi Albrecht,

Section 3.1 states:

.... The

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Christer,

In my opinion:

Best regards,
Albrecht

PS

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 14 Nov 2013 01:31:13 +0000

Right.

Gesendet: Donnerstag, 14. November 2013 02:21

Hi Albrecht,

Right?

Regards,

Christer

Hello Christer,

b) change proposal:

by

Any comments?

Regards,
Albrecht

Regards,

Christer

Hello Christer,

Thanks,
Albrecht

Hi Albrecht,

Regards,

Christer

What do you think?
Best regards,
Albrecht

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Montag, 23. September 2013 11:54
To: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hi Albrecht,

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: 23. syyskuuta 2013 12:31
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hello Christer,

Regards,
Albrecht

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Donnerstag, 19. September 2013 10:02
To: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Hi Albrecht,

Section 3.1 states:

.... The

Regards,

Christer

-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

Christer,

In my opinion:

Best regards,
Albrecht

PS

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Nov 2013 18:08:16 -0800

I believe that the a=setup attribute was first defined by rfc 4145, for TCP.

There it governs who listens for an incoming connection. And the main 
concern was that NATs/FWs might prevent one end or the other from 
accepting incoming connections. Even so, it didn't have any normative 
behavior about what should be in the offer.

As this same attribute is used in different contexts, the implications 
of using it may vary. In particular, if it is intended that either end 
should be able to take either the active or passive role, then the 
considerations for use may vary.

ISTM that actpas SHOULD be used in the offer, except in cases where the 
offerer has a particular preference for active or passive, and would 
prefer to have the connection fail than use the other mode.

	Thanks,
	Paul

On 11/13/13 5:31 PM, Schwarz, Albrecht (Albrecht) wrote:
> Right.
>
> ------------------------------------------------------------------------
> *Von:* Christer Holmberg [[email-masked]]
> *Gesendet:* Donnerstag, 14. November 2013 02:21
> *An:* Schwarz, Albrecht (Albrecht)
> *Cc:* [email-masked]; LANDAIS, BRUNO (BRUNO)
> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS
> session
>
> Hi Albrecht,
>
> If I understand your proposal correctly, the change would be to relax
> the rule for assigning the SDP setup attribute value in the SDP Offer.
> Instead of mandating actpass, we would also allow active and passive.
>
> Right?
>
> Regards,
>
> Christer
>
> *Lähettäjä:*Schwarz, Albrecht (Albrecht)
> [mailto:[email-masked]]
> *Lähetetty:* 14. marraskuuta 2013 3:11
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* [email-masked]; LANDAIS, BRUNO (BRUNO)
> *Aihe:* AW: [mmusic-udptl-dtls-01] Establishment direction of DTLS session
>
> Hello Christer,
> a) problem statement: existing SDP O/A rules define a tighly coupled
> mode between the establishment direction of the SIP session and the
> establishment direction of the DTLS session, but there's not any
> reasoning for such tightly coupled behaviour.
>
> b) change proposal:
>        value, and, in case of setup:actpass or setup:passive, MUST be
> prepared to receive a DTLS client_hello message
>
>        attribute with the setup:active value, in case of setup:actpass
> or setup:passive.  Whichever party is active
>
> We would limit ourselves with the existing, restrictive SDP O/A rule.
> And without any justification for such a constraint.
>
> Any comments?
>
> Regards,
> Albrecht
>
>
> ------------------------------------------------------------------------
>
> *Von:*Christer Holmberg [[email-masked]]
> *Gesendet:* Montag, 7. Oktober 2013 13:11
> *An:* Schwarz, Albrecht (Albrecht)
> *Cc:* [email-masked] <mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
> *Betreff:* VS: [mmusic-udptl-dtls-01] Establishment direction of DTLS
> session
>
> Hi Albrecht,
>
> Once that is done, we will start looking into, and discuss, individual
> technical issues etc, and your input will be highly appreciated.
>
> Regards,
>
> Christer
>
> *Lähettäjä:*Schwarz, Albrecht (Albrecht)
> [mailto:[email-masked]]
> *Lähetetty:* 7. lokakuuta 2013 13:56
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* [email-masked] <mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
> *Aihe:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS session
>
> Hello Christer,
>
> At least a note (or editor’s note) should be added to draft
> mmusic-udptl-dtls in order to indicate the issue and that a solution
> proposal is still pending.
>
> Thanks,
>
> Albrecht
>
> *From:*Christer Holmberg [mailto:[email-masked]]
> *Sent:* Dienstag, 24. September 2013 16:01
> *To:* Schwarz, Albrecht (Albrecht)
> *Cc:* [email-masked] <mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS
> session
>
> Hi Albrecht,
>
> So, my suggestion is that you put together a short draft which describes
> the problem, and how you want to change it, and then we can have a more
> generic discussion about it. The WG can then decide whether we shall fix
> something, and if so, in which specs.
>
> Regards,
>
> Christer
>
> ------------------------------------------------------------------------
>
> *From:*Schwarz, Albrecht (Albrecht) [[email-masked]]
> *Sent:* Tuesday, 24 September 2013 4:22 PM
> *To:* Christer Holmberg
> *Cc:* [email-masked] <mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
> *Subject:* RE: [mmusic-udptl-dtls-01] Establishment direction of DTLS
> session
>
> Hello Christer,
>
> SIP session establishment and L4 security session (DTLS, TLS)
> establishment directions should be principally decoupled because
> application specific.
>
> All three applications are different in terms of number/type of
> supported network models, security models or/and communication topology.
>
> Consequently, the basic, application independent SDP O/A rules for DTLS
> session establishment would need to support that flexibility.
> What we got so far: SDP O/A rules in three application specific "RFCs"
> (RFC 5763, rfc4582bis, udptl-dtls), which are all tight to RFC 5773 :-(
>
> b) add a WARNING / NOTE about the inherent limitations (due to the
> assumption of a network and communication environment according RFC 5763)
>
> What do you think?
> Best regards,
> Albrecht
>
>
> Cc: [email-masked] <mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
> Now, if you want to change that, and allow the Offerer to "force" the
> direction, I think you should start a separate thread about that.
> Because, it is not specific to fax, in my opinion.
>
> Regards,
>
> Christer
>
> From: Schwarz, Albrecht (Albrecht)
> [mailto:[email-masked]]
> Cc: [email-masked] <mailto:[email-masked]>; LANDAIS, BRUNO (BRUNO)
> the decision about "DTLS session establishment direction" is ALWAYS up
> to the SDP ANSWERER (according present 3.1).
>
> In order to decouple SIP session and DTLS session establishment
> directions, then the SDP OFFERER should also to be able to use
> "setup:active" and "setup:passive" (besides codepoint "setup:actpass")
> in my understanding.
>
> I'm not sure whether the reference to RFC 5763 helps because I could
> imagine that the subject comes down to the indicated network scenarios,
> lets look again at:
> a) T - T
> b) T -GW
>
> The existing udptl-dtls & RFC 5763 text seems to focus on model (a)
> only: SDP O/A between two peering, terminal located SIP UAs (there is
> NOT any SIP B2BUA).
> But I could imagine that the SIP/SDP profiles for "T" and "GW" are not
> necessarily the same in case of model (b): "T" as SDP Offerer may not
> allowed to decide the DTLS session establishment direction, but "GW" as
> SDP offerer may need to enforce the DTLS session establishment direction
> (either way).
>
> Regards,
> Albrecht
>
>
> Cc: [email-masked] <mailto:[email-masked]>
> The direction of the SIP session establishment and the DTLS session
> establishment are NOT tightly coupled. The draft enables the Answerer to
> select whether it wants to act as DTLS client or DTLS server.
>
> Section 3.1 states:
>
> .... The
> offerer MUST assign the SDP setup attribute with setup:actpass value,
> and MUST be prepared to receive a DTLS client_hello message before it
> receives the SDP answer. The answerer MUST assign the SDP setup
> attribute with either setup:active value or setup:passive value. The
> answerer SHOULD assign the SDP setup attribute with the setup:active
> value. Whichever party is active MUST initiate a DTLS handshake by
> sending a ClientHello over each flow (host/port quartet).
>
> BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the
> DTLS-SRTP procedures for DTLS server determination.
>
> Regards,
>
> Christer
>
>
>
>
>
> From: Schwarz, Albrecht (Albrecht)
> [mailto:[email-masked]]
> Cc: [email-masked] <mailto:[email-masked]>
> The T.38 endpoint could be located in a terminal (= T.38 IAF) or in a
> gateway, leading to three possible scenarios of
> a) T - T
> b) T -GW
> c) GW-GW
>
> E.g., there might be the demand to limit DTLS session establishment in
> T-to-GW direction (and apply rather the reverse direction) due
> ClientHello associated security threats, resource requests in terms of
> memory, ...
>
> In my opinion:
> We had a similar discussion with TLS, there NAT traversal (NAT-T)
> aspects could influence TLS session establishment direction. However, I
> guess that NAT-T is minor for DTLS/UDP.
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Nov 2013 05:52:21 +0000

Hi,

I guess 'SHOULD use actpass' would work.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat <[email-masked]> wrote:

        Thanks,
        Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 15 Nov 2013 22:56:41 +0000

TBH I didn't see a compelling reason to make the change in the first place. If it is important to Albrecht, I think this proposal is fine and seems innocuous to the proposed solution.

Gonzalo

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 22 Nov 2013 18:54:39 +0000

Within the BFCPBIS working group, we debated this same point. In the end,
we decided it was best to align with RFC 5763. Here is the thread for your
reference:
http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00167.html

Cheers,
Charles

On 11/15/13 2:56 PM, "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
wrote:

>TBH I didn't see a compelling reason to make the change in the first
>place. If it is important to Albrecht, I think this proposal is fine and
>seems innocuous to the proposed solution.
>
>Gonzalo
>
>
>>> At this point, the community is making a decision about whether to
>>>start
>>> working on this.
>>> 
>>> At least a note (or editor¹s note) should be added to draft
>>> the "copy & paste" action (across at least three "RFCs") seems to be
>>>the
>>> root cause of the issue :-(
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 23 Nov 2013 12:39:31 +0000

Hi Charles,

In the thread you refer to, I don't think you considered the alternative we are discussing now :)

The discussion was more about whether the setup attribute shall be used to determine the TLS role to begin with, and the outcome was that the attribute IS used. We are NOT changing that for UDPTL-DTLS, we are simply relaxing the MUST-indicate-actpass-in-the-offer rule.

Regards,

Christer

"Charles Eckel (eckelcu)" <[email-masked]> wrote:

Cheers,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 25 Nov 2013 21:00:53 +0000

Hi Christer,

Yes, I understand and agree with that. As mentioned in the BFCPBIS thread,
indicating "actpass" in the offer is important for B2BUAs that rely on
this in order to be able to match up the two sides of a call. For example,
such a B2BUA would send an INVITE without an offer and expect to receive
back an offer with the capabilities of the remote endpoint. If that
endpoint sends back "actpass" in its offer, the B2BUA is free to answer
with either "active" or "passive" in order to match this up with the
associated call on the other side of the B2BUA. This way the B2BUA can
participate in the SIP/SDP signaling yet not be in the path of the the
BFCP over DTLS channel.

Cheers,
Charles

On 11/23/13 4:39 AM, "Christer Holmberg" <[email-masked]>
wrote:

>The discussion was more about whether the setup attribute shall be used
>to determine the TLS role to begin with, and the outcome was that the
>attribute IS used. We are NOT changing that for UDPTL-DTLS, we are simply
>relaxing the MUST-indicate-actpass-in-the-offer rule.
>
>Regards,
>
>Christer
>
>>>>       offerer MUST assign the SDP setup attribute with a
>>>>setup:actpass,
>>>> setup:active or setup:passive
>>>>
>>>> "The endpoint that is the offerer MUST use the setup attribute value
>>>>of
>>>> setup:actpass"
>>>>
>>>> The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In
>>>>fact,
>>>> we base the procedure on that RFC.
>>>>