Re: [w3ctag/design-reviews] TAG Review Request: RTCIceTransport & RTCQuicTransport (#296)

I'm adding this comment here, because I think that this needs attention from the TAG (and probably a broader audience, but we'll start with the TAG).

## Background

These two specifications are very different, and should probably be the subject of separate analyses, but it is convenient that they appear together.  I'll get back to QUIC later, but I want to first look at ICE.

The WebRTC WG has, for a number of years, been dedicated to establishing peer-to-peer communications.  ICE is a fundamental part of that.  ICE exists primarily to facilitate connection establishment in challenging network conditions (NATs, etc...).  It does this by testing all possible communication paths, looking for the best one that works. The part that I want to focus on here is its function in providing confirmation of a willingness to communicate.  As part of the testing process, ICE also confirms that the entity at the other end understands the communication and consents to it continuing.

For classic WebRTC uses cases, ICE exists primarily as a defense against denial of service: you don't want to be responsible for sending a fat stream of video to someone who doesn't want it.  This is what ensures that web browsers can't be turned into a DoS platform.

The ICE transport spec represents an effort by the WebRTC community to provide lower-level tools for web developers.  This is complementary to other efforts to decompose the giant ball of wax that is WebRTC into reusable components.

## Consent to Communicate on the Web

We most often think of consent to communicate in the context of CORS.  User agents use CORS to confirm that the server understands and is willing to continue communication.  Though we let some requests through for legacy reasons, we first confirm (with a preflight request) that the server consents to receiving the request.

Some of the more onerous and awkward provisions in CORS derive from it being retrofitted to the web.  The web for a long time didn't have programmatic access to HTTP requests, and a number of servers were deployed that were not prepared for that access.  This was worst in cases where servers made the (bad) assumption that access to the network was sufficient for authorization.  If browsers allowed random sites to generate requests toward those internal servers without checking first, bad things would happen.

The parallels between ICE and CORS is something that earlier versions of WebRTC didn't really concern themselves with.  [WebRTC 1.0](https://w3c.github.io/webrtc-pc/) is a relatively high-level API that provides the ability to exchange media and data between peers.  In that narrow context, limiting the consent function of ICE to simple denial-of-service protection makes sense.

## ICE and Raw Socket Access

If we look at ICE as a more fundamental building block, we end up with new possibilities.  We've struggled in the past with APIs that enabled raw socket access (such as the [TCP and UDP socket API](https://www.w3.org/TR/tcp-udp-sockets/)).  ICE presents an option that would enable those uses.

The primary concern with those previous attempts is in exposing a capability to the web platform that enables communications with arbitrary, unprepared hosts.  The scope of problems with CORS would be a pale shadow of the problems with services that operate at the next layer down in the stack.

ICE provides a way of verifying that a peer is willing to communicate.  That suggests that it might be used to enable communication for more than just WebRTC.  Sure, you aren't going to enable access to existing services without first teaching them how to indicate their consent to communicate, but that's the feature we needed.  The consent parts of ICE are fairly simple, and deploying them could allow new services to become web-accessible.

The RTCIceTransport spec makes no effort to address these possibilities.  It says nothing about how it might be used, which leaves the field fairly open.  It probably assumes the narrow set of existing peer-to-peer use cases.  Given that this could enable much more, some consideration of its broader applicability is wise.  For instance, though it might enable DNS to UDP port 53, I would argue that it shouldn't on the basis that we should not be enabling the creation of unencrypted and unauthenticated communications channels from the web.

## The Role of QUIC

As a generic building block, ICE has some fairly dire limitations.  ICE relies on some out-of-band arrangement (in RTC terms, a signaling channel) that establishes session identifiers (in ICE terms ufrag and password) that are used to indicate consent.  That makes it difficult to use.  Servers that want to provide their own access would need to provide an HTTP server that provided a rendezvous capability.

QUIC presents a new possibility.  Right now, deployment of QUIC is non-existent in its standardized form.  The QUIC handshake provides the same sort of consent that ICE provides, without the awkward signaling requirements.  So it is possible that we could decide that the web could support direct QUIC connections from browsers.

That is, direct access to QUIC connections, with no additional protections other than its inherent consent-to-communicate mechanisms and an expectation that QUIC deployments do not assume that access to the network implies authorization.  That might be too risky, but a simple flag in the QUIC handshake would be all we need to signal consent to communicate with a web browser.  No need for ICE, except where it is necessary for establishing peer-to-peer communications.

That's a discussion I think that we should have with our friends at the IETF.  I don't think that shipping an RTC-based API for QUIC is advisable without having some discussion of the more fundamental issues (and possibilities).

That discussion might take some time, because it's not currently a priority for the QUIC WG.  At least, that is my understanding, but you could check with @mnot and @larseggert for a more authoritative view on that, I'm merely a document editor.

One immediate consequence of this for the proposed QUIC API is in the way in which it does authentication.  The mechanisms presently replicate the mechanisms we have for peer-to-peer, which would not fit with a more generic model.  They assume that the site that oversees the signaling is trusted to decide identity and do not attribute any particular identity to communication peers (absent other work, which allows that authority to be shifted to a third party).

Of course, there are many other things to consider here, such as how an API like this potentially results in multiple connections from the same browser to the same server because multiple origins use the same capability, or how this might interact with the service worker lifecycle.

## Other Issues

These are relatively minor concerns, but I thought I append them anyway, so there is a record in text.  The editors of the WebRTC QUIC API spec (and chairs of the WG) haven't been particularly receptive to these comments, and will no doubt provide some defense, but I'll list them anyway.  These are minor points relative to the rest of this, but it's worth pointing out.

1. QUIC isn't finished.  The IETF getting closer to finishing the core transport, but the protocol is still subject to change.  In particular, there are very few HTTP/QUIC implementations, so we are concerned that we might learn something important.  The response to this has been something like "we intend to be ready when QUIC is and the basic API contracts seem to be stable".  That is fine for experiments, but it seems like there is shipping code, or there soon will be.  That might have long-term consequences.  Waiting a little is probably wise.

2. If the QUIC API contracts are stable, then the API is failing to implement them.  Critically, it fails to provide support for unidirectional streams.  As a low-level API, it might also be necessary to allow more control over other protocol features like transport parameters, ALPN, and the aforementioned authentication snarl.  The API doesn't do anything for 0-RTT either, though here I agree with the spec editors: 0-RTT is hard, so deferring support is sensible.

3. The QUIC API uses the same awful flow control mapping pioneered by websockets.  Websockets was developed before streams existed, but that is no reason to keep the bad API.  The solution to the consistency problem is to retrofit streams on websockets, not to propagate its infidelities.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/296#issuecomment-418572658