6

Can a client-side outbound TCP port be reused concurrently for multiple destinations?

If it's possible, this would let NAT gateways milk an IP Address much more, and make it practically impossible to have Ephemeral port exhaustion.

I guess there are a few layers to this question:

  1. Is it conceptually feasible?
  2. Are any new security issues created that are hard to mitigate?
  3. Does this have a name already?
  4. Are there any standards issues that for some reason disallow this? What would the reasoning be?
Community
  • 1
Kind Contributor
  • 973
  • 1
  • 8
  • 14

2 Answers2

5

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

Kind Contributor
  • 973
  • 1
  • 8
  • 14
4

TCP connections are uniquely defined by 4 parameters:

  • Local IP address
  • Local port
  • Remote IP address
  • Remote port

So putting aside NAT for now:

  • You can have multiple connections between the same IP addresses, provided one port is different. As usually the port on the server side is fixed, that means the port on the client side needs to change. That's why we have ephemeral ports.

  • You can have multiple connections using the same port numbers, but different IP addresses (usually the client).

If you look at the output of netstat (e.g. netstat -n46) you'll see that each connection listed does have these 4 parameters (as well as some state information), and that you often have many connections with at 2 or 3 common parameters, but never 4 common ones.

Apart from the obvious issue of the ressources this would take and related OS limits (and reserved ports), this means a server (with fixed local IP and port) could receive 65535 * 223*(1<<24) connections. A client (with fixed local IP) can open 65535 connections to a single server (with fixed IP and port), but 65535 * 223*(1<<24) connections to multiple servers all listening on a single port, and 65535 * 65535 * 223*(1<<24) connections to multiple servers listening on all possible ports.

Now when you introduce NAT, the issue is how you map internal IP addresses and ports to external ones. There are varied approaches (which have different requirements in terms of processing on the NAT device):

  • Some will reserve a given external port for a single (internal IP address, internal port) combination.
  • Others will include the remote IP address and/or port in the mapping.
  • Others still will use pools of IP addresses rather than just one.

This results in many different NAT translation methods with interesting names like "Full Cone", "Restricted Cone", "Port Restricted Cone" and whatnot.

This has consequences on NAT traversal for peer-to-peer (mostly for audio/video calls), and leads to the requirements for STUN, TURN, ICE, etc.

It may also make things more complex when you need to be able to report which user used what port at a given time, so carriers may have restrictions on how exactly they implement NAT.

jcaron
  • 1,003
  • 5
  • 10