QuicTransport for client-to-server

[shampson]

If you want to use a QuicTransport for client-to-server with the current API, you have to do two things that don't necessarily make sense:

• Security: Verify self signed certificates on both sides using remote fingerprints, instead of just verifying the server's certificate with a CA as the QUIC handshake currently supports.
• ICE: With a client-to-server case you don't necessarily need ICE, but this is required with the API by using an IceTransport. There are probably two solutions here:
  • Server terminates ICE (could be ICE lite, which wouldn't be difficult)
  • Don't require an IceTransport. Could support supplying a UDPTransport or Address/Port?

Thoughts? Problems? Concerns? Since client-to-server seems to be some of the main use cases for this API (file sharing, games, etc.), it seems like this is worth bringing up.

[aboba]

@shampson @alvestrand

What is the overall W3C philosophy for API support of QUIC in client-server scenarios?

Existing W3C APIs that utilize HTTP for client-server communications can utilize QUIC "under the covers" (e.g. QUIC used automatically as a reliable transport whenever HTTP chooses to use it instead of TCP). When using those existing APIs, certificate verification and use without ICE can be supported.

However, for communications between a browser and a WebRTC gateway, WebRTC-QUIC might be a better choice. For that scenario, requiring gateway support for ICE lite seems reasonable. Note that the way QUIC role determination works, a gateway with an ICE role of "controlled" would imply a QUIC role of "client", with the browser having an ICE role of "controlling" implying a QUIC role of "server". This can be a bit awkward for full validation of the gateway certificate.

[shampson]

After our last discussion, we envisioned a separate RTCQuicTransport interface for the server/client case. The client side could just supply a url, and there wouldn't be methods for certificates, parameters, etc.

Is the expectation that we would use ICE still? The server could terminate ICE LITE, and the client's RTCQuicTransport would still supply a RTCIceTransport in the constructor. Then we would be using ICE for the consent to communicate still. From the discussion in the TAG review, it seems that there would be some IETF spec work for QUIC before the this authentication can be done at the QUIC level.

[pthatcherg]

ICE doesn't provide a lot of value in a client-server model and not requiring it would make the life of a server implementation easier. So I think we should start with a model where there is no ICE for client-server and then maybe consider adding it later if we feel it's necessary.

I don't understand the issue with consent. QUIC won't send (many) packets unless the remote side responds to them. It's just like a websocket or XHR request with TCP: there's no special consent mechanism there as far as I know. Consent is more and issue with something like RTP that my just keep sending packets even with no response from the remote side. But perhaps I'm missing something.

[shampson]

As @martinthomson mentioned in the TAG review:

... a simple flag in the QUIC handshake would be all we need to signal consent to communicate with a web browser....That's a discussion I think that we should have with our friends at the IETF

I think the idea is if you're using QUIC for consent you'd need to add a flag to signal that the QUIC connection is coming from a browser.

[alvestrand]

Is this issue talking about client-to-server or peer-to-peer?
ICE is usually a peer-to-peer issue, and two-way mutual authentication is an issue where the responder has to be able to authenticate the initiator.

[aboba]

One of the important considerations with QUIC usage is fallback. With HTTP, we can fallback to TCP if the server doesn’t support QUIC. With WebRTC-QUIC, ICE takes care of finding an appropriate path, which in the event of a UDP blockage might imply something ugly like QUIC transport over TURN/TCP. So I’m trying to understand the circumstance where you would want C/S QUIC by itself.

For example, Websockets has no equivalent in HTTP/2 so it occurred to me that it might be usable for an application using the Websockets messaging API to be able to use QUIC instead of Websockets if the client and server supported QUIC. You could provide a library to do this using a C/S QUIC API as a short-term alternative to integrating QUIC natively. But ultimately you’d probably want to support QUIC natively, so it isn’t really a standalone C/S QUIC use case.

[jianjunz]

IMHO, QuicTransport for client-to-server mode is more like the WebSocket API which provides two-way communication between client and server. It's not limited to be used by WebRTC APIs.

I'm also trying to remove ICE in C/S mode. It might be possible in WebRTC NV as we're adding low level data access APIs. Then we are able to get encoded data and send it to server with any transport API between client and server (HTTP, WebSocket or C/S QUIC).

[pthatcherg]

Responding to Harald and jianjunz: lots of people are asking for either client-server use cases or an improved web socket that works over QUIC (depending on the way they think about it, but it amounts to the same things). We can provide that by basically just adding a constructor that takes a URL. Then we have one API that works well for all these cases. So I think we should.

Responding to Bernard, I think we should just never go to connected and let the JS decided what it wants to do. If it wants to fallback to a websocket or ICE or something else, it can. If someone wants a higher-level API to handle that, one can make a small JS library to do that.

[jianjunz]

Such a constructor will allow us to remove ICE with WebRTC 1.0 APIs. Not sure if this topic (and #67) is covered at the QUIC session of TPAC.

[pthatcherg]

I made a PR for this: #73

[aboba]

The client-server API is available for inspection here:
https://w3c.github.io/webrtc-quic/cs.html