src/connectivity/network/netstack3/docs/DEMULTIPLEXING_PRINCIPLE.md

# The Demultiplexing Principle

Just as a kernel is responsible for isolating programs from one another,
protecting each program's memory, CPU budget, etc from interference by other
programs, a network stack is responsible for isolating programs' network
resources, protecting them from interference by other programs.

More generally, we can say that a network stack is responsible for isolating the
resources of different *security domains*, where a security domain might be a
process, a collection of processes (for example, a collection of processes owned
by the same user on a UNIX system), a sandbox within a process (for example, a
web assembly program run inside of a VM which runs multiple such programs at a
time), etc.

Isolation of network resources is a security property. Imagine a security
domain, A, that initiates a TCP connection with a remote server, and accepts
instructions over that connection. If another domain, B, on the system is able
to inject data into the TCP stream, then an important security property of
domain A has been violated.

Since all interaction with the network stack (excepting management plane
interaction, which is not relevant to this discussion) is via sockets, this
implies that the stack is responsible for isolating sockets from each other. A
given security domain may opt to allow two or more of its sockets to interfere
with each other since that doesn't violate that domain's security, but this must
not be the default, at least for sockets owned by different domains.

We define "interference" here as one socket either receiving traffic that was
meant for another one, or causing traffic that should be received by it to be
received by a different socket instead. In other words, when a remote host
receives a packet and then responds with a packet of its own, it intends for the
response to be received by the original sender. Conversely, when a remote host
sends a packet unprompted, it intends for that packet *not* to appear as though
it is the response to some previously-sent packet. A socket has "interfered"
with another socket if either of these properties don't hold.

Outbound traffic from multiple sockets is multiplexed together into a single
outbound stream of IP packets or link-layer frames. Inbound traffic - in the
form of a single stream of IP packets or link-layer frames - is demultiplexed in
order to deliver each packet to the appropriate socket. Different sockets may
employ different demultiplexing schemes (for example, TCP and UDP use the
four-tuple of remote and local IP address and remote and local port, while ICMP
echoes use the three-tuple of remote and local IP address and ICMP ID), but the
fundamental requirement of being able to demultiplex a single stream of inbound
traffic into multiple different sockets remains the same.

Together, these security requirements and the multiplexed nature of network
traffic imply what we refer to as the **demultiplexing principle**. The
demultiplexing principle states:

    1. Every socket is associated with a set of packet addresses such that it
       would be valid for the socket to receive a packet with any of the
       addresses in that set. This is called the socket's "address set".
    2. No two sockets may exist at the same time whose address sets overlap.
    3. A socket must never send a packet that would prompt a response whose
       address is not in the socket's address set.

    If two sockets, A and B, are owned by the same security domain, then the
    rules are relaxed as follows:
    4. Sockets A and B may exist at the same time even if their address sets
       overlap so long as the owning security domain has opted into it.

Note that (3) depends on the semantics of the protocol in question.

If we follow rules (1) through (3), then we can guarantee two things. First, we
can guarantee that it can never be ambiguous which socket to deliver a packet to
(if it were ambiguous, it would imply that rule (2) had been broken). Second, we
can guarantee that, given sockets A and B, socket A can never interfere with
soket B by sending traffic whose response will be delivered to socket B (if it
could, this would imply either that the response traffic could be delivered to
either A or B, violating rule (2), or that the traffic was unambiguously
destined to socket B, violating rule (3)).

Consider what might happen if we don't abide by this principle. We might have
two UDP sockets - socket A with local address `1.1.1.1:1234` and remote address
`*:*`, and socket B with local address `1.1.1.1:1234` and remote address
`2.2.2.2:5678`. If an inbound packet is received from `2.2.2.2:5678` to
`1.1.1.1:1234`, which socket should it be delivered to? It's possible that the
remote host is attempting to communicate with socket A. It's also possible that
socket B previously sent a packet, and the remote host is responding to it.
There's no way to tell which is the case, and so it's ambiguous which socket
should receive the packet.