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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Wed, 15 May 2013 20:06 UTC

Return-Path: <eckelcu@cisco.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 884C421F872E for <mmusic@ietfa.amsl.com>; Wed, 15 May 2013 13:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level:
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
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 XwnW7yUC5je1 for <mmusic@ietfa.amsl.com>; Wed, 15 May 2013 13:05:55 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFA621F871D for <mmusic@ietf.org>; Wed, 15 May 2013 13:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3634; q=dns/txt; s=iport; t=1368648355; x=1369857955; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G0VRIKnLn2LxKM3Dq7KGVExJGib9IGahU9irmoiy5tc=; b=P9dflqbV3n0filItAy9b0rkwMf8bI+mEczU6ghUtV749xr1yBVTX31ch P3ekGZa4gqjPS+dcciDeg45N8BAINA2bockJBCuhkG8ZmK7cxXGqEjqh/ 6r2oZYQuPRLsxnqemQIt6YeGJxOjVQ7luhRFOqnZQ5T1ZEhAQiI7HNezE 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAFjqk1GtJXG//2dsb2JhbABbgwc3gzy9Gw1wFnSCHwEBAQQjEUUMBAIBCA4DBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIh3IDDgEMq1CIbw2IUYEmiyKCJRYbBwaCPDJhA5VPgw2KcoUjgxCCJw
X-IronPort-AV: E=Sophos;i="4.87,679,1363132800"; d="scan'208";a="210930646"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 15 May 2013 20:05:54 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4FK5sDM007475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 May 2013 20:05:54 GMT
Received: from xmb-aln-x08.cisco.com ([169.254.3.28]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 15 May 2013 15:05:54 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Justin Uberti <juberti@google.com>, Martin Thomson <martin.thomson@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation
Thread-Index: AQHORpl+ckZ1WP/E2EKwDjm+4RXvEJjxI3aAgAAD2gCAABUxgIAAXkyAgAA1WACAAKTYAIAACOAAgADN64CAAMJ9gIAADKaAgBKmOJA=
Date: Wed, 15 May 2013 20:05:53 +0000
Message-ID: <92B7E61ADAC1BB4F941F943788C0882804833FA6@xmb-aln-x08.cisco.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> <CABkgnnX_fy77UthxAJxen=Eoam0CABdAMvCiTZSt0NoG=s3M7Q@mail.gmail.com> <CAOJ7v-0bCeqXj7tMsZjFFSr6VvozdXtdxST2q5PS_wgtaZ+W8A@mail.gmail.com>
In-Reply-To: <CAOJ7v-0bCeqXj7tMsZjFFSr6VvozdXtdxST2q5PS_wgtaZ+W8A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [171.68.16.44]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Alan Johnston <alan.b.johnston@gmail.com>, "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: Wed, 15 May 2013 20:06:01 -0000

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Justin Uberti
> Sent: Friday, May 03, 2013 11:15 AM
> To: Martin Thomson; Eric Rescorla
> Cc: Paul Kyzivat; Alan Johnston; mmusic@ietf.org
> Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
> 
> 
> 
> 
> On Fri, May 3, 2013 at 10:29 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> 
> 
> 	On 2 May 2013 22:53, Justin Uberti <juberti@google.com> 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?
> 
> 
> 	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.
> 
> 
> 
> 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.

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