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 08:12 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 D2FAA1B2D50; Wed, 5 Aug 2015 01:12:40 -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 5_lZoqoYJGOs; Wed, 5 Aug 2015 01:12:38 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A5F1B2D8E; Wed, 5 Aug 2015 01:12:37 -0700 (PDT)
X-AuditID: c1b4fb2d-f79176d00000321c-55-55c1c5730748
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B1.40.12828.375C1C55; Wed, 5 Aug 2015 10:12:35 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.36]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Wed, 5 Aug 2015 10:12:34 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "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+g
Date: Wed, 5 Aug 2015 08:12:34 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B348E8E9F@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>
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADB9197@FR711WXCHMBA03.zeu.alcatel-lucent.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_7594FB04B1934943A5C02806D1A2204B348E8E9FESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rrf46MFQg32zhCz+tP5itFj7r53d 4tP5LkYHZo/WZ3tZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHk9yTWgnmXGSvOHT/C1MB45Sxj FyMnh4SAicT8dV/YIWwxiQv31rN1MXJxCAkcZZRY3bWYFcJZxCjxaO0DoCoODjYBC4nuf9og DSIChRKPG7+DDWIWMJD4e+I6mC0sUCVxcN59VoiaaokHp66zQ9hGEp3PP4LFWQRUJJb9uscC YvMK+Eo0/2pngdh1glmic/88sCJOgViJp7/PMYPYjEDXfT+1hglimbjErSfzmSCuFpBYsuc8 M4QtKvHy8T9WCFtRYufZdmaI+nyJSxOeMEEsE5Q4OfMJywRG0VlIRs1CUjYLSdksoJeZBTQl 1u/ShyhRlJjS/ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwOg7 uOW37g7G1a8dDzEKcDAq8fAq5B0MFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGxu62y4XrW0u56ub0XHxxhfk17zH7T+u2zN5bYW5n+zDwwxNLP4mpyVwn Poe2Ve0tEjv/yvzzj3VL/AWt5hue9flqnLOqUFzzevvbH4oKDfNEY052fj51bfN5rgmSP+K2 Klm7nBKY+PNZxaRdO0/dEHjF9HnpjNMxztJnbMWv7ezPKtu8jLtK4LASS3FGoqEWc1FxIgA8 UH6XnwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/C19NmwEm2Ophuo6sfnRh1LS7R3M>
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 08:12:41 -0000

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>
Cc: TLS@ietf.org (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>.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>]n>].

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.