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) <
albrecht.schwarz@alcatel-lucent.com> 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:* mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] *On
> Behalf Of *Mo Zanaty (mzanaty)
> *Sent:* Donnerstag, 2. Mai 2013 06:04
> *To:* Justin Uberti
> *Cc:* Paul Kyzivat; mmusic@ietf.org
> *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****
>
>
>
> On May 1, 2013, at 6:28 PM, "Justin Uberti" <juberti@google.com> 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 <ggb@tokbox.com> 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?
>
> 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:
>
> > On 5/1/13 2:26 PM, Gustavo García wrote:
> >> 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?
> >
> > See RFC4145.
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic****
>
> ** **
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic****
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>