Re: More on demultiplexing

[Eric Rescorla <[e-mail]>]

On Wed, Dec 6, 2017 at 3:43 PM, Colin Perkins <[e-mail]> wrote:

>
> > 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).
>

You might (for instance) start sending data to a TURN server and then have
a srflx candidate succeed.



> > 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


Note that if you don't expert keys, then you need DTLS demux (or no bundle)


-Ekr