Re: More on demultiplexing

[Ted Hardie <[e-mail]>]

Howdy,

Some additional thoughts and clarifying questions in-line.

On Wed, Dec 6, 2017 at 10:41 AM, 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:
>
>
I think there is a case zero here that we all agree should just work:
downloading the javascript application for WebRTC should be the same over
HTTPS-QUIC as it is for HTTPS-TLS.  It's worth saying out loud only because
we have to remember that this support is orthogonal: it neither helps nor
hurts the WebRTC application's functioning once it is loaded in the browser.


> - 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.
>
>
Probably worth pasting the usual ascii art here for the benefit of folks
who think about QUIC and haven't thought about WebRTC much:

                +-----------+             +-----------+
                |   Web     |             |   Web     |
                |           |  Signaling  |           |
                |           |-------------|           |
                |  Server   |   path      |  Server   |
                |           |             |           |
                +-----------+             +-----------+
                     /                           \
                    /                             \ Application-defined
                   /                               \ over
                  /                                 \ HTTPS/WebSockets
                 /  Application-defined over         \
                /   HTTPS/WebSockets                  \
               /                                       \
         +-----------+                           +-----------+
         |JS/HTML/CSS|                           |JS/HTML/CSS|
         +-----------+                           +-----------+
         +-----------+                           +-----------+
         |           |                           |           |
         |           |                           |           |
         |  Browser  | ------------------------- |  Browser  |
         |           |          Media path       |           |
         |           |                           |           |
         +-----------+                           +-----------+


In your case one, the SDP flows over the signaling path, which is why this
isn't an 'open box with enclosed ax' situation.  For your case two, I'm
assuming you mean a conference bridge situation, where the clients notify
the bridge that they can handle QUIC and the bridge speaks some QUIC and
some non-QUIC flavors of WebRTC.


> 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.
>
>
> 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.
>
>
> 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.
>
>
I agree that the QUIC substitution for the current data channel stack is
pretty straight forward.

On the media side, I have a question about using a PERC-like approach with
QUIC.  PERC's framework document gives this summary of its goals and
methods:

   This solution framework focuses on the end-to-end privacy and
   integrity of the participant's media by limiting access of the end-
   to-end key information to trusted entities.  However, this framework
   does give a Media Distributor access to RTP headers and all or most
   header extensions, as well as the ability to modify a certain subset
   of those headers and to add header extensions.  Packets received by a
   Media Distributor or an endpoint are authenticated hop-by-hop.

   To enable all of the above, this framework defines the use of two
   security contexts and two associated encryption keys: an "inner" key
   (an E2E key distinct for each transmitted media flow) for
   authenticated encryption of RTP media between endpoints and an
   "outer" key (HBH key) known only to media distributor and the
   adjacent endpoint) for the hop between an endpoint and a Media
   Distributor or between Media Distributor.  Reference the following
   figure.

If I am reading this correctly, the parallel method to use in PERC for QUIC
would have a set of private keys for the media and would carry the media
encrypted with those keys in one set of streams, but would make the header
information available on a different set of streams, encrypted only at the
transport layer .  That makes the header information something that QUIC
can pass up to the media distributor (presuming the endpoints were speaking
QUIC to the media distributor), but the RTP protected as PERC intends.

That looks fairly do-able to me, but my familiarity with PERC is glancing
at best, so it would be useful if someone with more familiarity could
comment.  Supporting PERC has a lot of benefits for privacy, and I would
like to make architectural support for it a requirement, if the timing
allows.

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.
>
> I think if you bundled all the media on one 5-tuple and had QUIC on
another, the core NAT exhaustion problem would not be that bad.  There are
some corner cases where the media is meant to be tightly synced to the
media and might end up on a different path because it is a different
5-tuple.  If the paths are not equivalent latency, that can bite you.


> 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.
>
>
Having to run DTLS for DTLS-SRTP seems kind of sub-optimal to me, but
that's a gut reaction rather than a measured analysis.

Ted



> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>