Subject: [MMUSIC] DTLS-SRTP client/server role negotiation

From: Gustavo García <[email-masked]>
Date: Wed, 1 May 2013 11:26:52 -0700

RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and which side is the DTLS server must be established via some out-of-band mechanism such as SDP."

What is the specification on how to signal that in SDP?  

Specifically in case of 3pcc where both endpoints are SDP offerers which one should take the client and server roles for DTLS?    Should we tie that role to ICE controlled/controlling roles or should we negotiate it in the SDP somehow?

G.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 May 2013 16:56:59 -0400

> Specifically in case of 3pcc where both endpoints are SDP offerers which one should take the client and server roles for DTLS?    Should we tie that role to ICE controlled/controlling roles or shou…

See RFC4145.

---

From: Gustavo García <[email-masked]>
Date: Wed, 1 May 2013 14:10:46 -0700

I saw it, but that is all about TCP client/server role and not DTLS client/server role.   Are we supposed to use the same "setup" attribute for dtls role negotiation even if it is over UDP?

I think there is no reason to tie TCP and DTLS roles, but perhaps I'm misunderstanding something.

On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Justin Uberti <[email-masked]>
Date: Wed, 1 May 2013 15:26:37 -0700

I think Paul means the active/passive attributes in RFC 5763, but I'm still
not sure about how 3rd party call control would be handled in this case,
i.e. when both endpoints think they are offerers and set a=setup:actpass.

ICE has logic to determine roles in this scenario, as shows in RFC 5245,
B.11.

On Wed, May 1, 2013 at 2:10 PM, Gustavo García <[email-masked]> wrote:

> I saw it, but that is all about TCP client/server role and not DTLS
> client/server role.   Are we supposed to use the same "setup" attribute for
> dtls role negotiation even if it is over UDP?
>
> >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and
> which side is the DTLS server must be established via some out-of-band
> mechanism such as SDP."
> >>
> >> Specifically in case of 3pcc where both endpoints are SDP offerers
> which one should take the client and server roles for DTLS?    Should we
> tie that role to ICE controlled/controlling roles or should we negotiate it
> in the SDP somehow?
> >
> > See RFC4145.
> >

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 2 May 2013 04:04:07 +0000

A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the other leg will answer with active or passive but not actpass.

A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and alter SDP in complex ways to generate two answers from two offers, part of which is deciding which answer should become active and which should become passive.

The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unaltered by a B2BUA which delays offers on both legs. Generating two answers from two offers is much more complex than simply forwarding the offers as answers.

DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be actpass. TCP is harder since RFC 4145 allows offers to be active, passive, or actpass, causing more complex reinvites to resolve active/active or passive/passive conflicts.

Mo

On May 1, 2013, at 6:28 PM, "Justin Uberti" <[email-masked]<mailto:[email-masked]>> wrote:

I think Paul means the active/passive attributes in RFC 5763, but I'm still not sure about how 3rd party call control would be handled in this case, i.e. when both endpoints think they are offerers and set a=setup:actpass.

ICE has logic to determine roles in this scenario, as shows in RFC 5245, B.11.

On Wed, May 1, 2013 at 2:10 PM, Gustavo García <[email-masked]<mailto:[email-masked]>> wrote:
I saw it, but that is all about TCP client/server role and not DTLS client/server role.   Are we supposed to use the same "setup" attribute for dtls role negotiation even if it is over UDP?

On 01/05/2013, at 13:56, Paul Kyzivat wrote:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 2 May 2013 07:15:02 +0000

The RFC situation is not really clear, even confusing concerning client/server role negotiations (in case of transport security sessions over connection-oriented IP transport protocols).

·         RFC 4145 is only about TCP, i.e., TCP client/server role assignments. Thus, the RFC 4145 introduced SDP attribute is TCP specific.

·         draft-ietf-mmusic-sctp-sdp: seems to profile the "a=setup:" attribute for SCTP path establishment directions ... (?)

·         RFC 5763 uses the TCP SDP attribute for DTLS session establishment, i.e. DTLS client/server role assignments; that's actually a semantical change of this SDP element vs RFC 4145

... and DTLS is TLS based, leading to the question of role/assignments in case of TLS/TCP sessions?
I.e., the TCP client/server and also TLS client/server roles? Keeping in mind that the role assignments at IP transport layer and security session layer may principally be different!

The "a=setup" definition by RFC 4145 is unfortunate in my opinion.
Required seems to be a generic SDP specification (i.e., outside RFC 4145), which may be then tight to the concerned protocol. Sth like an explicit indication "a=setup:PROTOCOL:" or an implicit indication by adding an identifier.

The "m=" line <proto> element does not really help to reduce ambiguity (as Paul reminded again: ""Unfortunately SDP has a pretty confusing idea of "transport". The proto field identifies a whole stack of protocol layers.").

Albrecht
PS
I would see following parameter values for a SDP "a=setup:PROTOCOL:" attribute extension:
L4: TCP, SCTP, DCCP(?)
L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling ...)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Mo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 May 2013 10:17:45 -0400

Replying to everybody,

Yes, 4145 was just for TCP, but the same notation has subsequently been 
applied in several other contexts that need the same kind of decision, 
as pointed out by others in this thread.

And yes, it would be better if there was a separate specification of 
a=setup, divorced from its application to any particular proto. But 
doing that would violate the rich tradition and spirit of SDP evolution. :-)

Mo has covered the 3pcc case well. It is a solved problem for a=setup.

	Thanks,
	Paul

On 5/2/13 3:15 AM, Schwarz, Albrecht (Albrecht) wrote:
> The RFC situation is not really clear, even confusing concerning
> client/server role negotiations (in case of transport security sessions
> over connection-oriented IP transport protocols).
>
> ·RFC 4145 is only about TCP, i.e., TCP client/server role assignments.
> Thus, the RFC 4145 introduced SDP attribute is TCP specific.
>
> ·draft-ietf-mmusic-sctp-sdp: seems to profile the “a=setup:” attribute
> for SCTP path establishment directions … (?)
>
> ·RFC 5763 uses the TCP SDP attribute for DTLS session establishment,
> i.e. DTLS client/server role assignments; that’s actually a semantical
> change of this SDP element vs RFC 4145
>
> … and DTLS is TLS based, leading to the question of role/assignments in
> case of TLS/TCP sessions?
>
> I.e., the TCP client/server and also TLS client/server roles? Keeping in
> mind that the role assignments at IP transport layer and security
> session layer may principally be different!
>
> The “a=setup” definition by RFC 4145 is unfortunate in my opinion.
>
> Required seems to be a generic SDP specification (i.e., outside RFC
> 4145), which may be then tight to the concerned protocol. Sth like an
> explicit indication “a=setup:PROTOCOL:” or an implicit indication by
> adding an identifier.
>
> The “m=” line <proto> element does not really help to reduce ambiguity
> (as Paul reminded again: ““Unfortunately SDP has a pretty confusing idea
> of "transport". The proto field identifies a whole stack of protocol
> layers.”).
>
> Albrecht
>
> PS
>
> I would see following parameter values for a SDP “a=setup:PROTOCOL:”
> attribute extension:
>
> L4: TCP, SCTP, DCCP(?)
>
> L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling …)
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Mo Zanaty (mzanaty)
> *Sent:* Donnerstag, 2. Mai 2013 06:04
> *To:* Justin Uberti
> *Cc:* Paul Kyzivat; [email-masked]
> *Subject:* Re: [MMUSIC] DTLS-SRTP client/server role negotiation
>
> A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so
> the other leg will answer with active or passive but not actpass.
>
> A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze
> and alter SDP in complex ways to generate two answers from two offers,
> part of which is deciding which answer should become active and which
> should become passive.
>
> The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded
> unaltered by a B2BUA which delays offers on both legs. Generating two
> answers from two offers is much more complex than simply forwarding the
> offers as answers.
>
> DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be
> actpass. TCP is harder since RFC 4145 allows offers to be active,
> passive, or actpass, causing more complex reinvites to resolve
> active/active or passive/passive conflicts.
>
> Mo
>
>
>
> I think Paul means the active/passive attributes in RFC 5763, but I'm
> still not sure about how 3rd party call control would be handled in this
> case, i.e. when both endpoints think they are offerers and set
> a=setup:actpass.
>
> client/server role.   Are we supposed to use the same "setup" attribute
> for dtls role negotiation even if it is over UDP?
>
> tie that role to ICE controlled/controlling roles or should we negotiate
> it in the SDP somehow?
>  >
>  > See RFC4145.
>  >
>  > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 2 May 2013 12:05:02 -0500

Interestingly, I have yet to see any browser use a=setup for DTLS-SRTP.  Is
this attribute really needed?  How do things work if one or both browsers
don't include it?

- Alan -

On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) <
[email-masked]> wrote:

> over connection-oriented IP transport protocols).****
>
> ** **
>
> **·         **RFC 4145 is only about TCP, i.e., TCP client/server role
> assignments. Thus, the RFC 4145 introduced SDP attribute is TCP specific.*
> ***
>
> **·         **draft-ietf-mmusic-sctp-sdp: seems to profile the “a=setup:”
> attribute for SCTP path establishment directions … (?)****
>
> **·         **RFC 5763 uses the TCP SDP attribute for DTLS session
> establishment, i.e. DTLS client/server role assignments; that’s actually a
> semantical change of this SDP element vs RFC 4145 ****
>
> ** **
>
> case of TLS/TCP sessions?****
>
> mind that the role assignments at IP transport layer and security session
> layer may principally be different!****
>
> ** **
>
> The “a=setup” definition by RFC 4145 is unfortunate in my opinion.****
>
> Required seems to be a generic SDP specification (i.e., outside RFC 4145),
> which may be then tight to the concerned protocol. Sth like an explicit
> indication “a=setup:PROTOCOL:” or an implicit indication by adding an
> identifier.****
>
> ** **
>
> The “m=” line <proto> element does not really help to reduce ambiguity (as
> Paul reminded again: ““Unfortunately SDP has a pretty confusing idea of
> "transport". The proto field identifies a whole stack of protocol layers.
> ”).****
>
> ** **
>
> Albrecht****
>
> PS****
>
> attribute extension:****
> L4: TCP, SCTP, DCCP(?)****
>
> L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling …)****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> *Subject:* Re: [MMUSIC] DTLS-SRTP client/server role negotiation****
>
> ** **
>
> A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the
> other leg will answer with active or passive but not actpass.****
>
> ** **
>
> and alter SDP in complex ways to generate two answers from two offers, part
> of which is deciding which answer should become active and which should
> become passive.****
>
> ** **
>
> offers as answers. ****
> ** **
> actpass. TCP is harder since RFC 4145 allows offers to be active, passive,
> or actpass, causing more complex reinvites to resolve active/active or
> passive/passive conflicts.****
>
> ** **
>
> Mo****
>
>
>
> On May 1, 2013, at 6:28 PM, "Justin Uberti" <[email-masked]> wrote:***
> *
>
> a=setup:actpass. ****
> ** **
> B.11. ****
> ** **
> On Wed, May 1, 2013 at 2:10 PM, Gustavo García <[email-masked]> wrote:****
>
> I think there is no reason to tie TCP and DTLS roles, but perhaps I'm
> misunderstanding something.****
>
>
> https://www.ietf.org/mailman/listinfo/mmusic****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/mmusic****
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 May 2013 17:31:16 +0000

Hi,

RFC 4572 specifies that the "active" endpoint also takes the role as TLS client. At least MSRP refers to RFC 4572.

AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act as TLS client - ie it separates the TCP setup from TLS roles - which I think is very good. 

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Alan Johnston [[email-masked]]
Sent: Thursday, 02 May 2013 8:05 PM
To: Schwarz, Albrecht (Albrecht)
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Interestingly, I have yet to see any browser use a=setup for DTLS-SRTP.  Is this attribute really needed?  How do things work if one or both browsers don't include it?

- Alan -

On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) <[email-masked]<mailto:[email-masked]>> wrote:
The RFC situation is not really clear, even confusing concerning client/server role negotiations (in case of transport security sessions over connection-oriented IP transport protocols).

•         RFC 4145 is only about TCP, i.e., TCP client/server role assignments. Thus, the RFC 4145 introduced SDP attribute is TCP specific.

•         draft-ietf-mmusic-sctp-sdp: seems to profile the “a=setup:” attribute for SCTP path establishment directions … (?)

•         RFC 5763 uses the TCP SDP attribute for DTLS session establishment, i.e. DTLS client/server role assignments; that’s actually a semantical change of this SDP element vs RFC 4145

… and DTLS is TLS based, leading to the question of role/assignments in case of TLS/TCP sessions?
I.e., the TCP client/server and also TLS client/server roles? Keeping in mind that the role assignments at IP transport layer and security session layer may principally be different!

The “a=setup” definition by RFC 4145 is unfortunate in my opinion.
Required seems to be a generic SDP specification (i.e., outside RFC 4145), which may be then tight to the concerned protocol. Sth like an explicit indication “a=setup:PROTOCOL:” or an implicit indication by adding an identifier.

The “m=” line <proto> element does not really help to reduce ambiguity (as Paul reminded again: ““Unfortunately SDP has a pretty confusing idea of "transport". The proto field identifies a whole stack of protocol layers.”).

Albrecht
PS
I would see following parameter values for a SDP “a=setup:PROTOCOL:” attribute extension:
L4: TCP, SCTP, DCCP(?)
L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling …)

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Mo

---

From: Gustavo García <[email-masked]>
Date: Thu, 2 May 2013 10:36:48 -0700

In previous versions of Chrome the offerer was always the DTLS server.

In newest version of Chrome the ICE controlling agent is always the DTLS server.  (controlling and offerer are not the same in case of offerer being ice-lite implementation)

I think in case of 3pcc we need "a=setup" with proxy/B2BUA modifying the SDPs or using the ICE roles to resolve the conflicts.    I prefer to not use ICE to solve this and decouple ICE and DTLS roles.

G.

On 02/05/2013, at 10:05, Alan Johnston wrote:

> On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht) <[email-masked]> wrote:
> ·         draft-ietf-mmusic-sctp-sdp: seems to profile the “a=setup:” attribute for SCTP path establishment directions … (?)
> 
> ·         RFC 5763 uses the TCP SDP attribute for DTLS session establishment, i.e. DTLS client/server role assignments; that’s actually a semantical change of this SDP element vs RFC 4145
> 
>  
> 
> On May 1, 2013, at 6:28 PM, "Justin Uberti" <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 May 2013 13:53:06 -0400

> AFAIR, BFCP specifies its own rule, saying that the SDP offerer always act as TLS client - ie it separates the TCP setup from TLS roles - which I think is very good.

I think that approach has limitations. What does one do when doing a 
subsequent o/a, especially in the opposite direction?
And how does one distinguish when in a subsequent o/a you do/don't want 
to reestablish the connection rather than retaining the existing one?

	Thanks,
	Paul

---

From: Francois Audet <[email-masked]>
Date: Thu, 2 May 2013 17:52:24 +0000

You think a rule the binds TLS client role to offer/answer is *good*.... Really, why?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 2 May, 2013 10:31
To: Alan Johnston; Schwarz, Albrecht (Albrecht)
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Hi,

Regards,

Christer

- Alan -

.         RFC 4145 is only about TCP, i.e., TCP client/server role assignments. Thus, the RFC 4145 introduced SDP attribute is TCP specific.

.         draft-ietf-mmusic-sctp-sdp: seems to profile the "a=setup:" attribute for SCTP path establishment directions . (?)

.         RFC 5763 uses the TCP SDP attribute for DTLS session establishment, i.e. DTLS client/server role assignments; that's actually a semantical change of this SDP element vs RFC 4145

. and DTLS is TLS based, leading to the question of role/assignments in case of TLS/TCP sessions?
I.e., the TCP client/server and also TLS client/server roles? Keeping in mind that the role assignments at IP transport layer and security session layer may principally be different!

Albrecht
PS
I would see following parameter values for a SDP "a=setup:PROTOCOL:" attribute extension:
L4: TCP, SCTP, DCCP(?)
L4+: TLS, DTLS, DTLS-SRTP(?, due to RFC 5764 SDP profiling .)

Mo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 May 2013 18:09:37 +0000

Hi,

One good reason is if both clients are behind NATs, connected to SBCs. The SBCs will typically make the clients "active", in order to make the TCP connection traverse the NAT. Hence both clients will also become TLS clients. But, TLS does not define a mechanism to handle "collisions" when both endpoints act as TLS client, which means some intermediary needs to act as TLS server towards the clients.

Now, I realize that may not be a "valid" reason in IETF, and with ICE it may not be a long-term problem :) 

But, is there a reason why it is NOT be a good idea?

Regards,

Christer
________________________________________
From: Francois Audet [[email-masked]]
Sent: Thursday, 02 May 2013 8:52 PM
To: Christer Holmberg; Alan Johnston; Schwarz, Albrecht (Albrecht)
Cc: [email-masked]; Paul Kyzivat
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 2 May, 2013 10:31
To: Alan Johnston; Schwarz, Albrecht (Albrecht)
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Hi,

Regards,

Christer

- Alan -

Albrecht
PS

Mo

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 2 May 2013 20:05:54 +0000

> role assignments at IP transport layer and security session layer may principally be different!

If you mean TCP and TLS client/server roles can differ, I don't see that flexibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense for SDP to describe flexibility which is not supported in the underlying protocol.

I agree it is somewhat confusing for DTLS-SRTP to use an attribute originally defined for TCP, but I don't see any practical problem or deficiency that would be solved by the proposed "a=setup:PROTOCOL:" attribute extension.

Mo

From: Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: Thursday, May 02, 2013 3:15 AM
To: Mo Zanaty (mzanaty); Justin Uberti
Cc: Paul Kyzivat; [email-masked]
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation

Albrecht
PS

Mo

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 2 May 2013 20:36:06 +0000

I think the TLS client/server role rule in BFCP over TCP/TLS is unfortunate since it contradicts BFCP over UDP/DTLS as well as TLS itself. Perhaps one reason why there is no known BFCP over TCP/TLS implementation.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, May 02, 2013 1:31 PM
To: Alan Johnston; Schwarz, Albrecht (Albrecht)
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Hi,

Regards,

Christer

- Alan -

Albrecht
PS

Mo

---

From: Justin Uberti <[email-masked]>
Date: Thu, 2 May 2013 22:53:49 -0700

This is where the OP's question came from - the differing policy between
Chrome and Firefox. I (regarding Chrome) had figured that if ICE had made a
determination regarding which side was in charge, the other layers in the
stack should do the same, but it sounds like there are already established
rules on how to do this.

>From this thread, it sounds like the recommendation is to use
a=setup:actpass in the offer, and then the answerer can use a=setup:active
to choose the client role. In 3pcc cases, the B2BUA can select a=setup
appropriately to avoid any issue.

Is that an accurate summary, and is there consensus on this?

On Thu, May 2, 2013 at 10:36 AM, Gustavo García <[email-masked]> wrote:

> In newest version of Chrome the ICE controlling agent is always the DTLS
> server.  (controlling and offerer are not the same in case of offerer being
> ice-lite implementation)
>
> I think in case of 3pcc we need "a=setup" with proxy/B2BUA modifying the
> SDPs or using the ICE roles to resolve the conflicts.    I prefer to not
> use ICE to solve this and decouple ICE and DTLS roles.
>
> G.
>
> > Interestingly, I have yet to see any browser use a=setup for DTLS-SRTP.
>  Is this attribute really needed?  How do things work if one or both
> browsers don't include it?
> >
> > - Alan -
> >
> >
> > ·         RFC 4145 is only about TCP, i.e., TCP client/server role
> assignments. Thus, the RFC 4145 introduced SDP attribute is TCP specific.
> >
> > ·         draft-ietf-mmusic-sctp-sdp: seems to profile the “a=setup:”
> attribute for SCTP path establishment directions … (?)
> >
> > ·         RFC 5763 uses the TCP SDP attribute for DTLS session
> semantical change of this SDP element vs RFC 4145
> >
> >
> >
> layer  may principally be different!
> >
> >
> >
> explicit indication “a=setup:PROTOCOL:” or an implicit indication by adding
> an identifier.
> >
> >
> >
> (as Paul reminded again: ““Unfortunately SDP has a pretty confusing idea of
> "transport". The proto field identifies a whole stack of protocol layers.”).
> >
> >
> >
> > Albrecht
> >
> > PS
> >
> become passive.
> passive/passive conflicts.
> >
> >
> >
> > Mo
> >
> >
> >
> misunderstanding something.
> >
> >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 06:39:07 +0000

Hi Justin,

Are you talking about DTLS-SRTP only, or more general?

If I understood you correctly, what you suggest is what RFC 4572 says, ie that the TLS role is determined based on the setup role.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 3. toukokuuta 2013 8:54
To: Gustavo García
Cc: Alan Johnston; [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

This is where the OP's question came from - the differing policy between Chrome and Firefox. I (regarding Chrome) had figured that if ICE had made a determination regarding which side was in charge, the other layers in the stack should do the same, but it sounds like there are already established rules on how to do this.

From this thread, it sounds like the recommendation is to use a=setup:actpass in the offer, and then the answerer can use a=setup:active to choose the client role. In 3pcc cases, the B2BUA can select a=setup appropriately to avoid any issue.

On Thu, May 2, 2013 at 10:36 AM, Gustavo García <[email-masked]<mailto:[email-masked]>> wrote:
In previous versions of Chrome the offerer was always the DTLS server.

G.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 06:39:53 +0000

Hi Alan,

> Interestingly, I have yet to see any browser use a=setup for DTLS-SRTP.  Is this attribute really needed?  How do things work if one or both browsers don't include it?

How is the TLS role determined in the cases you've seen?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 06:58:59 +0000

Hi Paul,

> I think that approach has limitations. What does one do when doing a subsequent o/a, especially in the opposite direction?

Well, I could ask you to look it up in the BFCP RFC, but I doubt you'll find an answer there :)

> And how does one distinguish when in a subsequent o/a you do/don't want to reestablish the connection rather than retaining the existing one?

I would need some more time to think about that, but a few questions that came to my mind:

1) If the TLS connection already exists, is there a reason to reestablish it to begin with?

2) Would you need an o/a to reestablish the TLS connection to begin with? Once the roles have been determined (in the initial o/a), can't everything be handled on the TLS layer?

3) If the TLS connection already exists, is there a reason to renegotiate the TLS roles?

4) If a subsequent o/a is needed in order to reestablish the connection, and/or renegotiate the TLS roles, could the TLS connection first be terminated on the TLS layer, before the subsequent of/a is sent?

Regards,

Christer

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 3 May 2013 13:28:33 +0000

Accurate summary, and I agree with the recommendation, which is a MUST in DTLS-SRTP (RFC 5763 section 5).

Mo

On May 3, 2013, at 1:54 AM, "Justin Uberti" <[email-masked]<mailto:[email-masked]>> wrote:

G.

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Fri, 3 May 2013 14:13:23 +0000

Mo

> If you mean TCP and TLS client/server roles can differ, I don't see that flexibility in TLS itself (RFC 5246 section 7.4), so it doesn't make sense for SDP to describe flexibility which is not supp…

I disagree with your refered justification, primarily because

1.  RFC 5246, sec. 7.4 does not provide such info explicitly ("can't find any TCP related info")

2.  TLS itself (RFC 5246) is designed to be transport protocol independent (see section 1: "At the lowest level, layered on top of some reliable transport protocol ...")

3.  TLS-over-SCTP (RFC 3436): there is not any client/server concept in SCTP (RFC 2960)! SCTP associations are established between two SCTP endpoints ... (rather a peer-to-peer concept than client/server)

4.  TLS-over-TCP: the establishment of a TLS session could be principally delayed wrt the TCP connection establishment; the TCP client/server role is ONLY relevant during the state transitioning from CLOSED to ESTAB (RFC 793); ie the TCP roles "dissolve" with a successfully established TCP connection state.

I fail to see any tight coupling between TLS and TCP.

Regards,
Albrecht

From: Mo Zanaty (mzanaty) [mailto:[email-masked]]
Sent: Donnerstag, 2. Mai 2013 22:06
To: Schwarz, Albrecht (Albrecht); Justin Uberti
Cc: Paul Kyzivat; [email-masked]
Subject: RE: [MMUSIC] DTLS-SRTP client/server role negotiation

Mo

Albrecht
PS

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
Sent: Donnerstag, 2. Mai 2013 06:04
To: Justin Uberti
Cc: Paul Kyzivat; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Mo

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 May 2013 11:54:42 -0400

On 5/3/13 1:53 AM, Justin Uberti wrote:
> Chrome and Firefox. I (regarding Chrome) had figured that if ICE had
> made a determination regarding which side was in charge, the other
> layers in the stack should do the same, but it sounds like there are
> already established rules on how to do this.
>
> a=setup:actpass in the offer, and then the answerer can use
> a=setup:active to choose the client role. In 3pcc cases, the B2BUA can
> select a=setup appropriately to avoid any issue.
>

More or less. It is generally recommended that the initial offerer use 
actpass if it can, and be more restrictive if it knows it has 
corresponding restrictions. Presumably use of ICE can make anybody 
capable of being passive.

	Thanks,
	Paul

>     In newest version of Chrome the ICE controlling agent is always the
>     DTLS server.  (controlling and offerer are not the same in case of
>     offerer being ice-lite implementation)
>
>     I think in case of 3pcc we need "a=setup" with proxy/B2BUA modifying
>     the SDPs or using the ICE roles to resolve the conflicts.    I
>     prefer to not use ICE to solve this and decouple ICE and DTLS roles.
>
>     G.
>
>      > Interestingly, I have yet to see any browser use a=setup for
>     DTLS-SRTP.  Is this attribute really needed?  How do things work if
>     one or both browsers don't include it?
>      >
>      > - Alan -
>      >
>      >
>      > On Thu, May 2, 2013 at 2:15 AM, Schwarz, Albrecht (Albrecht)
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     client/server role negotiations (in case of transport security
>     sessions over connection-oriented IP transport protocols).
>      >
>      >
>      >
>      > ·         RFC 4145 is only about TCP, i.e., TCP client/server
>     role assignments. Thus, the RFC 4145 introduced SDP attribute is TCP
>     specific.
>      >
>      > ·         draft-ietf-mmusic-sctp-sdp: seems to profile the
>     “a=setup:” attribute for SCTP path establishment directions … (?)
>      >
>     establishment, i.e. DTLS client/server role assignments; that’s
>     actually a semantical change of this SDP element vs RFC 4145
>      >
>      >
>      >
>      > … and DTLS is TLS based, leading to the question of
>     role/assignments in case of TLS/TCP sessions?
>      >
>      > I.e., the TCP client/server and also TLS client/server roles?
>     Keeping in mind that the role assignments at IP transport layer and
>     security session layer  may principally be different!
>      >
>      >
>      >
>      > Required seems to be a generic SDP specification (i.e., outside
>     RFC 4145), which may be then tight to the concerned protocol. Sth
>     like an explicit indication “a=setup:PROTOCOL:” or an implicit
>     indication by adding an identifier.
>      >
>      >
>      >
>      > The “m=” line <proto> element does not really help to reduce
>     ambiguity (as Paul reminded again: ““Unfortunately SDP has a pretty
>     confusing idea of "transport". The proto field identifies a whole
>     stack of protocol layers.”).
>      >
>      >
>      >
>      > Albrecht
>      >
>      > PS
>      >
>      > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of Mo Zanaty (mzanaty)
>      > Cc: Paul Kyzivat; [email-masked] <mailto:[email-masked]>
>      > A simple 3PCC/B2BUA only delays offers toward one leg like
>     RFC3725, so the other leg will answer with active or passive but not
>     actpass.
>      >
>      >
>      >
>      > A complex 3PCC/B2BUA delays offers toward both legs, so it must
>     analyze and alter SDP in complex ways to generate two answers from
>     two offers, part of which is deciding which answer should become
>     active and which should become passive.
>      >
>      >
>      >
>      > The flow in RFC 5245 B.11 is oversimplified. SDP can't be
>     forwarded unaltered by a B2BUA which delays offers on both legs.
>     Generating two answers from two offers is much more complex than
>     simply forwarding the offers as answers.
>      >
>      >
>      >
>      > DTLS-SRTP is actually an easy case since RFC 5763 requires offers
>     to be actpass. TCP is harder since RFC 4145 allows offers to be
>     active, passive, or actpass, causing more complex reinvites to
>     resolve active/active or passive/passive conflicts.
>      >
>      >
>      >
>      > Mo
>      >
>      >
>      >
>      > I think Paul means the active/passive attributes in RFC 5763, but
>     I'm still not sure about how 3rd party call control would be handled
>     in this case, i.e. when both endpoints think they are offerers and
>     set a=setup:actpass.
>      >
>      >
>      >
>      > I saw it, but that is all about TCP client/server role and not
>     DTLS client/server role.   Are we supposed to use the same "setup"
>     attribute for dtls role negotiation even if it is over UDP?
>      >
>      > >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client
>     and which side is the DTLS server must be established via some
>     out-of-band mechanism such as SDP."
>      > >>
>      > >> Specifically in case of 3pcc where both endpoints are SDP
>     offerers which one should take the client and server roles for DTLS?
>         Should we tie that role to ICE controlled/controlling roles or
>     should we negotiate it in the SDP somehow?
>      > >
>      > > See RFC4145.
>      > >

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 3 May 2013 16:53:59 +0000

TLS RFC 5246 section 7.4.1.2:
When a client first connects to a server, it is required to send the ClientHello as its first message.

TCP RFC 793 section 2.7:
The OPEN call also specifies whether the connection establishment is to be actively pursued, or to be passively waited for.

You are correct that TLS does not specify any tight coupling to TCP, but how can you interpret the above to mean anything other than "clients actively connect to passive servers"?

Since TLS and DTLS do not support negotiating client/server roles, but rather derive them from the connection (and DTLS-SRTP specifies how to negotiate the connection as active/passive/actpass in SDP O/A), how would you support the role inversion you propose? How would a TCP listener know whether it can invert roles from server to client and send TLS ClientHello?

Perhaps EKR can chime in, but I just don't see the flexibility you describe being supported in TLS, so I don't see why SDP would need extensions to signal such flexibility.

Mo

Sent: Friday, May 03, 2013 10:13 AM

Mo

Regards,
Albrecht

Mo

Albrecht
PS

Mo

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 May 2013 12:20:08 -0400

Christer,

After rereading this and checking 4583, I realize my comment was based 
on a misunderstanding of what BFCP was doing. I thought you were saying 
that BFCP didn't use a=setup, and that the active party for the TCP/TLS 
connection was always the offerer. I see that was wrong - that it uses 
a=setup for that and says that the answer is the TLS server.

BFCP seems to have arranged its authentication so either end is capable 
of being the TLS server, and it is only necessary to have *some* 
mechanism for deciding which one will be. As long as that is the case, I 
don't have a particular problem with it.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 May 2013 10:29:55 -0700

> Is that an accurate summary, and is there consensus on this?

The answer should probably be a=setup:passive, so that you don't have
any disconnect on what candidate pair is nominated.  And you don't pay
an extra half-RTT.  But otherwise, yes.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 17:37:48 +0000

Hi,

>a=setup for that and says that the answer is the TLS server.

Correct. BFCP does use a=setup for the TCP connection establishment. Sorry if I was unclear.

Regards,

Christer

        Thanks,
        Paul

---

From: Justin Uberti <[email-masked]>
Date: Fri, 3 May 2013 11:15:11 -0700

On Fri, May 3, 2013 at 10:29 AM, Martin Thomson <[email-masked]>wrote:

> made a
> a=setup:active

http://tools.ietf.org/html/rfc5763 recommends a=setup:active for the
answerer, and Eric convinced me that any perf benefit from doing anything
different was nominal.

If the answerer's initial ICE checks reach the offerer, the client hello
can be sent by the answerer in 1.5 RTT, or the offerer in 2.0 RTT:
0.0: A: offer
0.5 B: answer
0.5 B: binding request
1.0 A: binding response
1.0 A: triggered binding request (USE-CANDIDATE)
1.5 B: DTLS client hello

If not, the client hello is sent by the answerer in 2.5 RTT, or the offerer
in 2.0 RTT:
0.0: A: offer
0.5 B: answer
0.5 B: binding request (dropped)
1.0 A: binding request (USE-CANDIDATE)
1.5 B: binding response
1.5 B: triggered binding request
2.0 A: binding response
2.5 B: DTLS client hello

So overall it's a bit of a wash, and therefore simpler to stick with 5763's
recommendation.

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Mon, 6 May 2013 12:40:21 +0000

Mo

the root cause in your argumentation seems to be related to the term "client/server".
Looks like that you are equating "TLS client" equal to "TCP client" etc, right?

However (in our discussion), "client/server" is a protocol, - and thus a protocol layer -, specific concept.
RFC 793 is about TCP client/server entities.
RFC 5246 is about TLS client/server entities (and NOT TCP client/server).

RFC 4975 defines MSRP client and servers (such as a MSRP conference server) as an example of application protocol related client/server concepts (e.g., MSRP/TLS/TCP).

RFC 4582 defines BFCP floor control client/server entities as an example of application protocol related client/server concepts (e.g., BFCP/TLS/TCP).

Second: RFCs for user plane (protocols) (above list) and control plane (here SIP and SDP) are different items. An SDP RFC can't "redefine" above RFCs.
Right, there might be gaps, hidden assumptions, not documented requirements in some of the referred SDP RFCs, but we shouldn't mix both areas.

Regards,
Albrecht

Sent: Freitag, 3. Mai 2013 18:54

TCP RFC 793 section 2.7:

Mo

Mo

Regards,
Albrecht

Mo

Albrecht
PS

Mo

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 15 May 2013 20:05:53 +0000

> Sent: Friday, May 03, 2013 11:15 AM
> To: Martin Thomson; Eric Rescorla
> Cc: Paul Kyzivat; Alan Johnston; [email-masked]
> On Fri, May 3, 2013 at 10:29 AM, Martin Thomson
> <[email-masked]> wrote:
> 
> 
> If the answerer's initial ICE checks reach the offerer, the client hello can be
> sent by the answerer in 1.5 RTT, or the offerer in 2.0 RTT:
> 0.0: A: offer
> 0.5 B: answer
> 0.5 B: binding request
> 1.0 A: binding response
> If not, the client hello is sent by the answerer in 2.5 RTT, or the offerer in 2.0
> RTT:
> 0.0: A: offer
> 0.5 B: answer

Sorry for the delayed comment on this thread, but I wanted to state than I agree. In addition, this is consistent with the recommendations provided by the BFCPBIS WG when using DTLS with BFCP over UDP:
http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-07#section-9

Cheers,
Charles