Re: More on demultiplexing

[Colin Perkins <[e-mail]>]

> On 6 Dec 2017, at 18:41, Eric Rescorla <[e-mail]> 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/