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

Alan Johnston <alan.b.johnston@gmail.com> Thu, 02 May 2013 17:05 UTC

Return-Path: <alan.b.johnston@gmail.com>
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 5221421F8F0F for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 10:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 eZeHtua9nMVo for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 10:05:05 -0700 (PDT)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CC00B21F8F0D for <mmusic@ietf.org>; Thu, 2 May 2013 10:05:04 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id s10so668077wey.17 for <mmusic@ietf.org>; Thu, 02 May 2013 10:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/tB3WQ2U4ZXLm5tjcaA+3ni/qR4HFIB4CtqXje4abFw=; b=fe/83I2hboXgoF9BxGG+3vxSDoVtioCjiQF9WOATU13adtfVQJChrqmZ7KjpZf16lq Pn3JDV0sNdRLdQSYw0DfGV2rcq+Evr0xPheDy7mFxpixunYCEro92oq2TO/qnIfEkAsN PJdB8JUwFVkkiNAHZv6qT2Y0nGPXOTji9l44hQ+FymM2bHNTRvm/ecbe8LpyZThQZcX3 FJUnbKYYsICaYl518y+8Pvi4IKj4bmHMPFCGj/qgHcrherq8ONkzRBkTt9PKYutzOVaC cyCn2YBpY1/5DIwoNxR1W/ZZUm6eM22InaR2M1fn+xbGeEjfNX6WlfPboRP/PbtxRh2H 8yFQ==
MIME-Version: 1.0
X-Received: by 10.180.189.41 with SMTP id gf9mr8957274wic.32.1367514302549; Thu, 02 May 2013 10:05:02 -0700 (PDT)
Received: by 10.216.173.134 with HTTP; Thu, 2 May 2013 10:05:02 -0700 (PDT)
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.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>
Date: Thu, 2 May 2013 12:05:02 -0500
Message-ID: <CAKhHsXGEiNLod6fXbOSP3HvVYtFi4iBQEUBe2x-5YQdwz8LAOQ@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary=001a11c348303a973404dbbf3c85
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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 17:05:06 -0000

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