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

Filling in relative information from @martinthomson's [post](https://github.com/w3ctag/design-reviews/issues/296#issuecomment-418572658) in the original TAG review:
> ## 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 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). 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.

-- 
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/304#issuecomment-419521935