Basic Networking
Communication over a network is essential for every TEE application. The TEE platform that Oyster uses, AWS Nitro Enclaves, only implements networking through a vsock interface. This means any application that uses the network needs to be modified to use vsocks instead of IP sockets. This is easier said than done because any reasonably complex application uses networking libraries that assume the existence and usage of IP stacks. Networking libraries, especially high-level libraries like http servers/clients, that use vsocks are virtually non-existent in most languages. Simple command line utilities like curl and wget do not support vsock. Nor do essential programs like Caddy, Nginx, PostgreSQL, etc. All in all, rewriting applications and workflows to use vsocks is a gargantuan task.
But don't fret, Oyster does the hard job of hiding all of the above complexity from applications and provides a simple IP interface.
Read more about Oyster's networking journey here - https://blog.marlin.org/networking-within-aws-nitro-enclaves-a-tale-of-two-proxies
Oyster families
Oyster has evolved over the years and currently supports two families of enclaves - salmon and tuna. Each of these families implements networking differently.
Networking in Salmon
Salmon provides separate networking paths for incoming and outgoing connections. In both cases, a combination of iptables, SO_ORIGINAL_DST and networking proxies work together to properly forward data between the application and an endpoint. The proxies run at the TCP layer by making new connections when needed, which means certain behaviour like timeouts and proper connection closing might not work as expected. The proxy implementations can be found here - https://github.com/marlinprotocol/oyster-monorepo/tree/master/networking/tcp-proxy.
Networking in Tuna
Tuna provides a common direction-agnostic networking path for both incoming and outgoing connections while having separate paths for incoming and outgoing packets (note that the diagram mentions packets, not connections). A combination of iptables, raw packets, NFQUEUE, and networking proxies work together to properly forward data between the application and an endpoint. Unlike salmon, the proxies run at the IP layer (like a router for example) by forwarding raw TCP packets, which means everything in the TCP layer works as expected. The proxy implementations can be found here - https://github.com/marlinprotocol/oyster-monorepo/tree/master/networking/raw-proxy.
Another important benefit to Tuna is no longer having to define and run separate proxies for every exposed port in the enclave. The raw proxies take care of exposing an entire public interface which programs can listen on in order to get expose ports automatically.
Security
Note that the TCP connection chain that is set up above is not fully secure. The proxy components running on the host instance are untrusted and may behave maliciously. Hence, another protocol is required to ensure integrity and privacy of communication with the endpoint. However, note that this is not a new problem - routers on the internet (e.g. ISP routers, home routers) are also untrusted components that can behave maliciously.
Fortunately, HTTPS (more specifically TLS) was built to solve exactly this problem. Therefore, any HTTPS or TLS based connections that terminate inside the enclave Just WorkTM with security and privacy preserved.
Of course, TLS is not the only protocol that provides this, applications are free to use their own protocols to maintain integrity and privacy. Spoiler alert, Oyster provides an enclave native TLS protocol called Scallop which does not rely on Web PKI.