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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 02 May 2013 14:17 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 0A42921F8B2B for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 07:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.038
X-Spam-Level:
X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, 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 vzP9zSvnXjMt for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 07:17:47 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 665B121F8B3A for <mmusic@ietf.org>; Thu, 2 May 2013 07:17:46 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta01.westchester.pa.mail.comcast.net with comcast id Wz7i1l0040xGWP8512HlcM; Thu, 02 May 2013 14:17:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id X2Hl1l01B3ZTu2S3Y2HlmP; Thu, 02 May 2013 14:17:45 +0000
Message-ID: <51827589.4060509@alum.mit.edu>
Date: Thu, 02 May 2013 10:17:45 -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: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.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>
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367504266; bh=U1KHQrp7AoKm1yA+QhWcP/aqhnrguIUjZipk+XTGUiI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y+LVBYdBujYrSLEr7LY4ulUYnktD1JAK+N0nKrRw5vIec6cC0esApmohGrfmz7Lhp Bph++kwsA8uZ172CaR/7CQMShvKRYJYrf6EFIOunGrkUbRWYyCvJN8oVJ0VU1kmR53 RfVb1OYh99Yb+TsQYuy/7pMJiCs6TWN4tZ24M+9k3AnXlYPyl6ZEnaQJAR1gLcJXiA BkVBcLA5YYPwlCza8Cf8UA7/Ut39aaCUEVZu0q+3oDYoZV21jrNFzI5Ts3ZS8EyacE tVf9Kx7zLwPCX5kVlbY8kP/jUR99/qTksZksqKBmrk/mnP/HWJd76gLS94WjCOHVpE 6hT16y7kBvm1Q==
Cc: "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: Thu, 02 May 2013 14:17:53 -0000

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:*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
> <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
>