Design document to outline goals, requirements and semantics for networking and network security in WASI

[worldhopper]

There have been various discussions about networking in WASI scattered across other issues or in pull requests, such as 1, 2, 3, 4 and 5.

As discussed in the WASI meeting today, it would be good to discuss the abstractions that WASI intends to provide and the layers that they operate at (sockets? http(s)? TLS? mTLS?). Furthermore, security and trust in the context of networking is an important consideration, with tradeoffs to WASI implementations and applications, as well as to users/operators.

It would be good to create a design document that outlines the goals, requirements and associated semantics of networking in WASI, and associated network security tradeoffs.

[sbc100]

Regardless of the high level APIs that get added, I think a low level raw UDP API is always useful for application that want to innovate in userspace. For example, I don't think modern protocols such as QUIC (https://en.wikipedia.org/wiki/QUIC) would have been able to develop if chromium developers had not been able to gain access the to the UDP socket layer on all the major operating system. So, while I agree that providing secure abstractions is great, it can sometimes restrict user space development if its the only option.

[sbc100]

(also, video game authors will most likely demand raw UDP).

[worldhopper]

Independent of what gets chosen/decided, am suggesting that we document the goals, requirements and tradeoffs in a design document.

[martinduke]

I encourage this group to not reinvent the wheel that is being forged in the IETF Transport Services working group:
https://datatracker.ietf.org/wg/taps/documents/

[sunfishcode]

Thanks for starting the conversation! Here some ideas:

We may end up with multiple networking APIs. We already have an HTTP proxy proposal and a Berkeley sockets proposal, and we'll likely add more. There will be theoretical overlap, but we have several tools for managing overlap:

• Modularization, so not all implementations need to implement all the APIs
• Virtualization so that one can implement higher-level APIs in pure wasm code using lower-level APIs. When this is feasible, it gives implementations that wish to support both APIs an easy path to doing so.
• Focusing on use cases - it's technically possible to do some of the same things with HTTP proxy APIs and Berkeley socket APIs, but they address significantly non-overlapping use cases.
• Abstracting initialization separately from use (eg. streams, where creating a new stream depends on the network API, but using a stream is just read and write.).

Some of our constraints include:

• Access to external resources should be done through handles, to support lightweight and composable virtualization, though we have a lot of flexibility in terms of what handles mean.
• For the foreseeable future, many use cases will want to keep private keys and other crypto artifacts outside of wasm instances. So protocols which involve crypto will likely want to have APIs that handle the crypto in the implementation, rather than relying on applications bundling their own crypto libraries.

Concerning TAPS -- thanks for bringing that up! Ultimately, the decision of which specific protocols and system APIs WASI supports will come down to people stepping up to help us figure out what APIs for them should look like, and ultimately champion them through the process. If anyone is interested in writing up a report on what TAPS is, how it fits into the overall network landscape, and a rough overview of what the API might look like, that'd be a great first step!

[martinduke]

If you want a writeup, the TAPS architecture draft is a good place to start:
https://www.ietf.org/id/draft-ietf-taps-arch-08.html

Some of the other documents in there show what capabilities the API would have and how you would connect them to lower-level APIs.

That's a lot of text that provides the details, so here's the TL;DR:
TAPS is designed to get applications out of the business of choosing the specific transport. Instead, applications establish a connection or listener with required or desired properties: reliability, in-order delivery, encryption, authentication, address migration, message boundaries, etc.

The TAPS middleware handles this to pick a transport (or pseudo-transport) that meets the requirement, based on what's available in the system. Note that transports and pseudo-transports don't just include TCP, UDP, QUIC, SCTP, etc. but also TLS over TCP, DTLS over UDP, and even HTTP.

So an application developer doesn't have to write different code to operate over platforms with different protocol capabilities. This fits in really well with the WASM ethic of writing code once for all platforms. I would be the job of the WASM engine on any particular platform to identify the available transports and pick the one that best meets the application needs. For instance, a browser engine would take the kernel sockets, the TLS library it uses, and its own HTTP1/2/3 implementation to offer a number of potential transports.

I am pretty new to TAPS, but I understand Apple is investing in this area, and I expect others to follow suit.

[sunfishcode]

I see that TAPS is event-based and asynchronous; do you know if it will mandate a particular callback model, or if we'll likely have the flexibility to integrate it with a future wasm async model?

[martinduke]

I cannot speak for the whole working group, but I believe they recognize that different languages and environments will have different ways to instantiate asynchronous ops.

[worldhopper]

Continuing the discussion from the meeting, it's important to discuss the attributes of security (AuthN, AuthZ, etc.) in relation to (and likely independent of) the approaches used for networking/connectivity. Specifically how does one define Identity of a peer.

More specifically whether applications can/should use a weak identity (e.g., IP address or domain name) or a strong identity (x.509 cert? JWT?) to authenticate and authorize a remote peer, and the potential tradeoffs of WASI suggesting to the application that either or both should be used.

[worldhopper]

@martinduke @sunfishcode What are the anticipated timelines of something like TAPS progressing through the IETF process and making it's way into real world implementations? Also the implications for changes along the way and impact to relying on it for WASI.

[sunfishcode]

These are good questions! It'd be great to hear from people about what approaches WASI might take here.

[martinduke]

@worldhopper the specs are already overdue, but I would hope that they could be RFCs as soon as six months from now, and probably in more or less their final form well before that. They are prepping for a "Working Group Last Call" in the next month or two.

[sunfishcode]

For anyone looking at the TAPS API, an updated URL is here: https://www.ietf.org/archive/id/draft-ietf-taps-arch-09.html

[zanieb]

There's been additional progress on TAPS, there are three documents covering architecture, implementation, and interfaces. It seems like they're moving very slowly though.

It may be good to clarify how this issue relates to #370 and https://github.com/WebAssembly/wasi-sockets, perhaps it is no longer relevant?