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

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 03 May 2013 17:19 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5221F969C for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 10:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.762
X-Spam-Level: **
X-Spam-Status: No, score=2.762 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMq459Ji0dfM for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 10:19:55 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A675321F993A for <mmusic@ietf.org>; Fri, 3 May 2013 08:54:58 -0700 (PDT)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta02.westchester.pa.mail.comcast.net with comcast id XPzz1l0051wpRvQ51Tulqu; Fri, 03 May 2013 15:54:45 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:a060:a4d2:13be:538b]) by omta18.westchester.pa.mail.comcast.net with comcast id XTuj1l00c0bDVez3eTujok; Fri, 03 May 2013 15:54:45 +0000
Message-ID: <5183DDC2.9000602@alum.mit.edu>
Date: Fri, 03 May 2013 11:54:42 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Justin Uberti <juberti@google.com>
References: <E888F149-12FE-4F23-A270-F861123BAC7B@tokbox.com> <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <CAOJ7v-2XUzVr3kL=emR_7w49th3mowa_WQG4wVVmD7__uA8APw@mail.gmail.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> <CAKhHsXGEiNLod6fXbOSP3HvVYtFi4iBQEUBe2x-5YQdwz8LAOQ@mail.gmail.com> <F72A5B11-D5D4-41D1-8118-C5BCBBAAE567@tokbox.com> <CAOJ7v-1rt2RA17oC0kCxC2wD310ghp2pwLF1jit6ikLfCSCiQA@mail.gmail.com>
In-Reply-To: <CAOJ7v-1rt2RA17oC0kCxC2wD310ghp2pwLF1jit6ikLfCSCiQA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367596485; bh=Vwcop7LBcbFBjKhhnyVtyamJQdK1yEqMv2sM7r64eT8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=iyC4V2rzIckywaw0MoCE9SewLFdyWU+O0FIUpkyxK53cHrBdAOeE8pnJqQ3eqD/ZS zjfPv8RUi7mbmxyAvpohtrev3BkizJiIe1DjF4ETOuIpxMAisBoShBpA5ZluP4gq+Z akDtf//TkEGNVmeeGXn6ElfICrRCNFLKyFSdTyyGSiSfWSDwDM3HRnSeiPpQprrwiE baHePmA9di++4SiU4w9fPx8KDta08yQJoWG6DI9zCzwNx+e71EwPO87wzjRWVTDA9T gSV00ubu5frJOd7G5SJeD302BvaGxDxn3Ug8dgh3EeNqdBZA5gAxrnmrfVvdxl5QeB rbCO3omhH23wg==
Cc: Alan Johnston <alan.b.johnston@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 May 2013 17:19:59 -0000

On 5/3/13 1:53 AM, Justin Uberti wrote:
> 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?

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

> On Thu, May 2, 2013 at 10:36 AM, Gustavo García <ggb@tokbox.com
> <mailto:ggb@tokbox.com>> wrote:
>
>     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:
>
>      > 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
>     <mailto: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>
>     [mailto: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 <mailto: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
>     <mailto: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
>     <mailto: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 <mailto:mmusic@ietf.org>
>      > > https://www.ietf.org/mailman/listinfo/mmusic
>      >
>      > _______________________________________________
>      > mmusic mailing list
>      > mmusic@ietf.org <mailto:mmusic@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/mmusic
>      >
>      >
>      >
>      > _______________________________________________
>      > mmusic mailing list
>      > mmusic@ietf.org <mailto:mmusic@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/mmusic
>      >
>      >
>      > _______________________________________________
>      > mmusic mailing list
>      > mmusic@ietf.org <mailto:mmusic@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/mmusic
>      >
>      >
>      > _______________________________________________
>      > mmusic mailing list
>      > mmusic@ietf.org <mailto:mmusic@ietf.org>
>      > https://www.ietf.org/mailman/listinfo/mmusic
>
>     _______________________________________________
>     mmusic mailing list
>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>