Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux
Christer Holmberg <christer.holmberg@ericsson.com> Wed, 05 August 2015 12:39 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23571B2E41; Wed, 5 Aug 2015 05:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6fmQIGrG47I; Wed, 5 Aug 2015 05:39:16 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998001A89C5; Wed, 5 Aug 2015 05:39:14 -0700 (PDT)
X-AuditID: c1b4fb3a-f79356d000006281-96-55c203f0936d
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.E4.25217.0F302C55; Wed, 5 Aug 2015 14:39:12 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Wed, 5 Aug 2015 14:39:12 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Asveren, Tolga" <tasveren@sonusnet.com>, "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux
Thread-Index: AQHQz1VVWzrNLwNmjUSvQIGN1uVQpZ39Df+ggAAl8YCAACS3wA==
Date: Wed, 05 Aug 2015 12:39:10 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B348E9576@ESESSMB209.ericsson.se>
References: <SN1PR0301MB1551DF037806CA3522EF0BFAB2760@SN1PR0301MB1551.namprd03.prod.outlook.com> <7594FB04B1934943A5C02806D1A2204B348E82CA@ESESSMB209.ericsson.se> <SN1PR0301MB15517DD9BF2570136FFD312EB2760@SN1PR0301MB1551.namprd03.prod.outlook.com> <CAD5OKxtj6nTSuFt=0xdFvJbaThRrE1YEazrU5W3bELkE7UKH=A@mail.gmail.com> <05B3C43B-2823-4590-889E-7A192FC8A3AD@gmail.com> <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B348E8E9F@ESESSMB209.ericsson.se> <SN1PR0301MB15511B00C3FE2072E861B044B2750@SN1PR0301MB1551.namprd03.prod.outlook.com>
In-Reply-To: <SN1PR0301MB15511B00C3FE2072E861B044B2750@SN1PR0301MB1551.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B348E9576ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvje4H5kOhBhsuaFn8af3FaLH2Xzu7 xezO90wWn853MTqweLQ+28vqsWTJTyaPS5//swcwR3HZpKTmZJalFunbJXBl9C9eyFTwaAlT xbxTG9kaGHvmMnUxcnJICJhI9P39zghhi0lcuLeeDcQWEjjKKLHmUngXIxeQvYhR4tbSJ0AN HBxsAhYS3f+0QeIiArMZJVZ/OAU2iFnAQOLvietgg4QFqiQOzrvPCmKLCFRLPDh1nR3CdpL4 0jGZGWQOi4CKxM5zfiBhXgFfiXOrVrBA7HrMIvF4zx+wIzgFEiUe71sANp8R6Ljvp9ZA7RKX uPVkPtQDAhJL9pxnhrBFJV4+/scKYStK7DzbzgxRny/x8tdSVohlghInZz5hmcAoOgvJqFlI ymYhKZsFdCqzgKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxaXJybbmSkl1qUmVxc nJ+nl5dasokRGI8Ht/y22sF48LnjIUYBDkYlHl6FvIOhQqyJZcWVuYcYpTlYlMR5Z2zOCxUS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6La67PucjdlxH3fM/fHyV0nCv4smShcOqNZfenls 5gchzist1ZZBVxfFZx25krZnpV/EttxHpve5jKRPvc7UizEXntRy7UnIkxnRe63imUNv7A7J bCh8oXH1s9zUg9uVhZ6JxpxaEMzW2s0vkB7Go6gdtITfyCP/X9CVBeUl/Jd16vhfLTc+pMRS nJFoqMVcVJwIAISUnwSoAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/-CVsHvDPhno2VXwcn8h8NeJRUkw>
X-Mailman-Approved-At: Tue, 11 Aug 2015 10:49:32 -0700
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2015 12:39:19 -0000
Hi, I guess we could add some clarification text to the SDP-DTLS draft. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 5. elokuuta 2015 15:27 To: Christer Holmberg; Schwarz, Albrecht (Albrecht); <rtcweb@ietf.org> Cc: TLS@ietf.org (tls@ietf.org) Subject: RE: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Yes, completely agree. And I think what Albrecht proposes below is the right way of addressing the “no-rtcp-mux implementation difficulties” problem: Adding clarifications/amendments in the respective normative specification rather than disallowing a combination in a profile because it is “confusing”. Honestly, I think the number of DTLS connections to use, when bundling/muxing is not used, is not really that hard to figure out (for somebody who actually understands the whole story) but obviously no harm of adding some clarifications. DataChannel aspects need to be crisply specified though. What is the main advantage of letting DataChannel potentially use one of the exsiting DTLS connections? Just to save some time on negotiation? Thanks, Tolga From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, August 05, 2015 4:13 AM To: Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com<mailto:albrecht.schwarz@alcatel-lucent.com>>; <rtcweb@ietf.org<mailto:rtcweb@ietf.org>> <rtcweb@ietf.org<mailto:rtcweb@ietf.org>> Cc: TLS@ietf.org<mailto:TLS@ietf.org> (tls@ietf.org<mailto:tls@ietf.org>) <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Hi, We shall not make RFC 5764 corrections in the RTCWEB specs. Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Schwarz, Albrecht (Albrecht) Sent: 5. elokuuta 2015 11:04 To: <rtcweb@ietf.org<mailto:rtcweb@ietf.org>> Cc: TLS@ietf.org<mailto:TLS@ietf.org> (tls@ietf.org<mailto:tls@ietf.org>) Subject: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux Roman, Bernard, right, RFC 5764 is too vague on that aspect. Thanks for confirming the number of DTLS sessions, which is inline with our understanding. Would appreciate if this could be somewhere fixed in an rtcweb draft due to significant side effects. This topic is also an ongoing FAQ. The most simple case is given by a scenario with usage of bundling plus usage of RTP/RTCP transport multiplexing, leading to a single DTLS session/DTLS connection, which could be then also shared for WebRTC data. Both capabilities are mandated in the rtp usage draft: https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.4 => bundling https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5 => RTP/RTCP transport multiplexing Now, IF bundling is not used OR RTP/RTCP transport multiplexing is not used THEN there will be more than one DTLS session/DTLS connection (either 2 or 4 in case of audio & video). Raising the question which DTLS connection is used for additional WebRTC data traffic? - Because https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5 indicates the sharing option. Would then be a 3rd (or 5th) self-contained DTLS session/DTLS connection for WebRTC data traffic? Proposal: Add explicit text to clause https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5 about (in red), something like: WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764], section 5.1.2<https://tools.ietf.org/html/rfc5764#section-5.1.2>. All application layer protocol payloads over this DTLS connection are SCTP packets. Note 1: There will be two DTLS sessions/DTLS connections when RTP/RTCP transport multiplexing is not applied. WebRTC data traffic could still share one of these DTLS connections … (“which one?”) … or There should be then a separate, self-contained DTLS session/DTLS connection established exclusively for WebRTC data. Note 2: There are similar considerations in case of bundling. Protocol identification MUST be supplied as part of the DTLS handshake, as specified in [I-D.ietf-rtcweb-alpn<https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#ref-I-D.ietf-rtcweb-alpn>]. Comments? Regards, Albrecht PS Using (D)TLS terminology according to http://tools.ietf.org/id/draft-guballa-tls-terminology-01.txt From: Bernard Aboba [mailto:bernard.aboba@gmail.com] Sent: Mittwoch, 5. August 2015 04:04 To: Roman Shpount Cc: Asveren, Tolga; Christer Holmberg; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); <rtcweb@ietf.org<mailto:rtcweb@ietf.org>> Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux On Aug 4, 2015, at 16:33, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote: Most of the people implement this wrong, since you need to create two DTLS sessions: one for RTP and another for RTCP. And then use different keys or possibly even encryption profiles for RTP and RTCP. I commonly see one session for RTP and keys negotiated there used for both RTP and RTCP, which is wrong. [BA] Yes, that is only one of several common mistakes. Unfortunately, RFC 5764 does not rule out all of these and the security documents are not crystal clear on how things must be done. It is much harder to mess up RTP/RTCP mux. Given what I've seen so far, non-mux could become a support nightmare.
- [TLS] Number of DTLS sessions/DTLS connections; R… Schwarz, Albrecht (Albrecht)
- Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS c… Schwarz, Albrecht (Albrecht)
- Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS c… Christer Holmberg
- Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS c… Asveren, Tolga
- Re: [TLS] [rtcweb] Number of DTLS sessions/DTLS c… Christer Holmberg