Conceptually, Yes
A TCP Server accepts multiple connections on the same port and correlates them to the right active socket connection. This is just vice versa.
Common knowledge about a TCP session states that when you connect to a website, your local machine uses an ephemeral port that is then paired with the other side as a "connection". Then that port is no longer available while the connection is open.
I suspect that a client-side TCP port can be reused, at least conceptually. This is because each packet has source IP, source port, destination IP, and destination port.
Scenario:
- Client A connects with TCP with 203.0.113.1:12345 to Host B 203.0.113.2:80
- Client A connects with TCP with the same port 203.0.113.1:12345 to Host C 203.0.113.3:80
- When Host B receives a packet from Client A, it sees the source IP:Port as 203.0.113.1:12345
- When Client A receives a packet from Host B, it sees the source IP:Port as 203.0.113.2:80 and can therefore correlate with the Host B TCP session
- When Client A receives a packet from Host C, it sees the source IP:Port as 203.0.113.3:80 and can correlate with the Host C TCP session.
Before, I used to think that a NAT IP address was limited to 65536 connections. That is 1xSourceIP X 65536xSourcePorts X 1xDestinationIP X 1xDestinationPort. However this scheme would make it possible to expand a single IP address much further:
- Theoretically: 15,891T connections - 1xSourceIP X 65536xSourcePorts X 3.7MxDestinationIPs X 65536xDestinationPort
- Practically: 242B connections - 1xSourceIP X 65536xSourcePorts X 3.7MxDestinationIPs X 1xDestinationPort
When the same destination is used multiple times by Client A, it would be limited to 65536 connections to that destination IP:Port. If the destination offered more destination port aliases, it would be able to connect to the same destination IP address 4.2M times.
Is it possible with TCP/IP stacks on any major OS today?
It is with UDP with modifications to QUIC protocol. This isn't TCP though.
Are there any engineering issues that make it impossible to implement?
No, the implementation is quite simple in code in the TCP/IP stack, and it's already a concept that's implemented successfully for TCP Listeners/Servers.
I haven't been able to find any documentation of this in an TCP/IP stack implementations. I haven't searched exhaustively though.
Are any new security issues created that are hard to mitigate?
No. Packets can already be spoofed, and the following aspects make it hard to exploit:
- Source/Destination coupling
- internal TCP features such as sequence numbers
- use of TLS channels on top of the TCP connection socket
Does this have a name already?
I don't know off the top of my head
Do carriers already do this on carrier-grade NAT?
I don't know off the top of my head
Are there any standards issues that for some reason disallow this? What would the reasoning be?
I don't know off the top of my head