The Reasoning Behind TCP and UDP Multiplexing Tuple

Question

I understand that TCP and UDP are multiplexed protocols, and the multiplexing key in them is the (sender.ip, sender.port, receiver.ip, receiver.port) tuple. I understand the reasoning behind sender.ip, sender.port and receiver.port but can't really see how receiver.ip helps with identifying the corresponding socket on the receiver side.

I am very new to the whole idea but on the other hand, it appears to me that by removing receiver.ip from the tuple, a whole new range of Internet censorship bypassing techniques could arise. Fragmenting IP diagrams into diagrams with various IP addresses of the same receiver could at least in theory help Internet freedom.

So my question is what is the reasoning behind having receiver.ip in TCP and UDP multiplexing key tuple? What would break if we just went with (sender.ip, sender.port, receiver.port)? I apologize in advance if this is a stupid question.

Answer 1

From a host stack's perspective, different local IP addresses mean different logical interfaces on the network layer. Whether they are bound to a single or multiple physical interfaces is of little interest here.

Likewise, the local TCP ports 192.0.2.1:80 and 192.0.2.2:80 can be bound and listened to by entirely different server processes, or the same process but handled differently, or the same.

From the remote perspective, both addresses represent different hosts anyway.

More generally, an IP:port combination defines a unique socket (for port-based transport protocols). Each unique pairing of sockets (source to destination, if you wish) represents an unambiguous connection (for connection-based protocols) or dialogue. From the perspective of a participant, that connection is defined by the SourceIP:SourcePort:DestinationIP:DestinationPort tuple.

Answer 2

You assume a host has one, and only one, IP address. This is rarely true. If you count loopback, which every machine has, there will always be at least two. In the modern world, it's very likely you'll have many, on many interfaces. Considering IPv6, a host will ABSOLUTELY have multiple addresses.

Answer 3

A server can have multiple IP addresses, even if it only has 1 NIC.

In fact, every host has at least 2 IP addresses: The host's Layer 3 identifier, and the host's loopback address.

A service can choose to bind to the same port for all addresses (usually denoted by 0.0.0.0:<port> in case of IPv4), or just a certain address:port tuple.

For a made up example:

Let's say I have a (dev) web server + Varnish. The server has 3 addresses (but 1 NIC):

• 192.168.123.5
• 192.168.123.19
• 127.x.x.x (loopback)

I have explicitly configured the web server to bind to 192.168.123.19:80 and 127.0.0.1:80. The former to allow access from other endpoints in the LAN, the latter to receive redirected requests from Varnish.

The Varnish service is explicitly configured to bind to only 192.168.123.5:80, so all requests coming to that IP address goes through Varnish first before being redirected to 127.0.0.1:80 to be handled by the actual web server.

This way, if I receive errors accessing http://192.168.123.5, I can switch over to http://192.168.123.19 and determine if the error is due to Varnish or due to the web server itself.

Because the server has multiple addresses, every TCP connection needs to be recorded using a 4-tuple of (source.address, source.port, dest.address, dest.port) to ensure that the right response goes through the right connection.

Answer 4

Because the receiver address is required to uniquely identify a given flow.

Consider the case where two different clients connect to the same web server, and they happen to pick the same ephemeral port for their outbound connection. The flow from those two clients to the web server is uniquely identified in this case only by the sender address. But web servers send data back, and when that happens, the sender/receiver roles are reversed. If you don’t include the receiver address as part of the multiplexing key, you cannot uniquely identify the return traffic in such a case.

That sounds like a possibly rare situation, but there are only 16383 ephemeral ports. That means you’re obviously guaranteed to get overlap if the node is serving more than that many clients simultaneously (which is absolutely reasonable for a large site), but it’s actually worse than that. Assuming that each host picks an ephemeral port randomly with a uniform probability distribution, you only need 152 clients to get a 50% chance of two picking the same port, and 389 for a 99% chance (this is a generalized case of the Birthday Problem).

---

Also, because the addresses involved are always inherently part of the individual packets anyway, not using them in the multiplexing key doesn’t actually hide anything from nodes that those packets are traversing, which means it’s not really any use in trying to defeat censorship or information harvesting.

Answer 5

First of all the address parts are in the IP layer, not the TCP/UDP/Transport layer itself. But answering the question further regardless.

I would list all purposes that come to mind:

• you need the receiver address in the packet so that routers know where to forward your packet, otherwise they wouldn't know whether packet is for them as a device or to be forwarded
• receiver itself needs to know whether the packet is for them. In some networks, nodes can see packets for other nodes. For example when using hubs or if improperly speced switch is used with too many connected nodes
• receiver should know which of the local addresses needs to be used. Locally you may use different services on the different IPs
• there are also multicast and broadcast addresses that usually use UDP for transport. Obviously routers and receivers need to know what kind of address the packet is destined for
• useful for firewalls

Fragmenting IP diagrams into diagrams with various IP addresses of the same receiver could at least in theory help Internet freedom.

Where would you put all these "various IP addresses"?