Re: More on demultiplexing
Colin Perkins <csp@csperkins.org> Wed, 06 December 2017 23:44 UTC
Return-Path: <csp@csperkins.org>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829C3128AA1 for <quic@ietfa.amsl.com>; Wed, 6 Dec 2017 15:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 8MlsXGG8iaH4 for <quic@ietfa.amsl.com>; Wed, 6 Dec 2017 15:43:58 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CCC128954 for <quic@ietf.org>; Wed, 6 Dec 2017 15:43:58 -0800 (PST)
Received: from [81.187.2.149] (port=45465 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <csp@csperkins.org>) id 1eMjM4-00066Q-C2; Wed, 06 Dec 2017 23:43:56 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: More on demultiplexing
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CABcZeBO=WCTLuuxaOJXKzQdiBduOxLdoqNtMpvPatBOAwNjZkQ@mail.gmail.com>
Date: Wed, 06 Dec 2017 23:43:53 +0000
Cc: IETF QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <61C0885E-3363-4B70-B64F-C471A4A16B3C@csperkins.org>
References: <CABcZeBO=WCTLuuxaOJXKzQdiBduOxLdoqNtMpvPatBOAwNjZkQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cObmOnhdhJ-G0bdxW2VZ0p8a9zA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Dec 2017 23:44:00 -0000
> On 6 Dec 2017, at 18:41, Eric Rescorla <ekr@rtfm.com> wrote: > > I've been doing some thinking about the QUIC muxing story. It seems > like the case that everyone has in their head is WebRTC, so I'd like > to focus on that. It seems to me that there are two main deployment models > one might have in mind: > > - A browser unilaterally decides to support QUIC-WebRTC and just advertises > it in its SDP, so that if that browser encounters another such browser, > they do QUIC > > - A service provider decides to do QUIC-WebRTC and turns it on for > clients which can do it. > > These have different muxing requirements, and then there are also > some subchoices about whether you want everything in WebRTC to be QUIC > or just parts of it. > > > As background, current WebRTC stacks attempt to mux all of the > following protocols on the same 5-tuple: > > - STUN (for ICE and for TURN) > - TURN channels > - DTLS (for key management) > - SRTP (for media) > > Note that I don't say SCTP because that's encapsulated in DTLS. > > STUN > I think the general consensus is that we need to be able to mux STUN > with QUIC, because otherwise we would need to reinvent all of STUN > and ICE and that would be very not fun, and in some ways problematic > because the non-ICE parts of STUN don't assume any server authentication > so it’s not clear how you would ever think to do them with QUIC. Agree. > TURN > TURN can either run over STUN, in which case it's covered by the previous > case, or it can run in channels, which are not. If you're willing to > abandon channels, then you don't have a problem. If you're not, then you > need TURN channels to work. I've heard suggestions that we should run > TURN over QUIC but I don't think that's sensible because the point of > TURN channels is to reduce overhead, and at that point you probably > could run the non-channel version of TURN without too much overhead > loss vis-a-vis QUIC and then you wouldn't have to address other problems > (e.g., server auth) that we never really resolved with TURN-TLS and would > maybe come back with QUIC. Do TURN channels need to demux with QUIC? I was assuming we’d run STUN/TURN channels to a server, or QUIC+STUN+DTLS+SRTP to a server, but not both? (i.e., it’s either a TURN server or a media endpoint, but not both). > DTLS and SRTP > Exactly what you need here depends on the deployment model. One might > imagine having QUIC-WebRTC in which the media and data channels are both > carried on QUIC, but you might also imagine having the data channel be > QUIC but the media being carried over RTP. I know there's active work > on a mapping for media over QUIC, but it's obviously not as straightforward > as a datachannels mapping, for which QUIC is basically a drop-in replacement > for SCTP, so that's a consideration here. > > In the case where you wanted SRTP separately, you would then need to > either (a) figure out a way to demux SRTP and QUIC or (b) not run them > on the same 5-tuple. (b) seems natural at some level, but > we adopted BUNDLE for a reason and this would push against that. So, > it seems to me that if you want to run data-over-QUIC and > media-over-SRTP you probably do need to figure out how to demux. agree. > In the case where you mux SRTP and QUIC on the same 5-tuple, you then > have to address key management. You could, of course, run DTLS-SRTP > and demux DTLS, but it seems like you could probably just use QUIC's > TLS handshake the way you run DTLS-SRTP and do the SRTP exporter from > there, so maybe you don't need to mux DTLS. Exporting SRTP keys from the QUIC handshake seems sensible, but is an extra level of specification complexity. I suspect we’ll want SRTP demux short term, key export in medium term, and RTP-in-QUIC in longer term. -- Colin Perkins https://csperkins.org/
- More on demultiplexing Eric Rescorla
- Re: More on demultiplexing Ted Hardie
- Re: More on demultiplexing Mikkel Fahnøe Jørgensen
- Re: More on demultiplexing Eric Rescorla
- Re: More on demultiplexing Mikkel Fahnøe Jørgensen
- Re: More on demultiplexing Colin Perkins
- Re: More on demultiplexing Eric Rescorla
- Re: More on demultiplexing Cullen Jennings
- Re: More on demultiplexing Jana Iyengar
- Re: More on demultiplexing Christian Huitema
- Re: More on demultiplexing Jana Iyengar
- Re: More on demultiplexing Bernard Aboba
- Re: More on demultiplexing Bernard Aboba
- Re: More on demultiplexing Ian Swett