5

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?
Improve this question
6
  • Removed the off-topic host/server OS implementation questions, and the question about networks not under your direct control.
    – Ron Maupin ♦
    Jan 26 '21 at 2:39
  • Also, ephemeral port exhaustion would be difficult to achieve on a host OS, and is not actually a problem on the NAT device. Both due to other resource exhaustion before port exhaustion. For example, a NAT device maintains three tables: TCP, UDP, and ICMP. Each table maintains it own source/destination IPv4/transport address tuples. It is not limited to one port number per host process because it is based on four criteria per protocol per connection. You will run out of RAM long before exhausting port numbers for even one protocol.
    – Ron Maupin ♦
    Jan 26 '21 at 2:44
  • Thanks @RonMaupin - I didn't realise that network engineering forum was only about conceptual networking questions.
    – Kind Contributor
    Jan 26 '21 at 2:51
  • It really isn't, but hosts/servers are off-topic here. We can deal with specific implementations for on-topic network devices (routers, switches, etc. for which the manufacturer offers optional, paid support). Questions about protocol theory (for OSI layers 1 to 4) are on-topic, but not specific host/server OS implementations.
    – Ron Maupin ♦
    Jan 26 '21 at 2:53
  • 1
    Windows, Linux, etc, are host/server OSes that are supported on other SE sites, including the OS internals like the network stack, but not here. If you want to make such a point, then you can post on Network Engineering Meta to let the community decide, but at this point, this community has decided that host/server OSes are off-topic here.
    – Ron Maupin ♦
    Jan 26 '21 at 13:31
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

Improve this answer
9
  • 6
    Please do not use real public IP addresses that do not belong to you. IANA has set aside three ranges for example addresses: 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24. Use addresses from one or more of those ranges as your example addresses, and then people will know they are example addresses.
    – Ron Maupin ♦
    Jan 26 '21 at 2:50
  • @RonMaupin That would make the answer a lot less readable. Are IP address copyrighted or something? This is a strange request to me.
    – Kind Contributor
    Jan 26 '21 at 2:53
  • 5
    The problem is the same as why movies and TV use the 555-xxxx telephone numbers. You can attract unwanted traffic to sites you do not own. That is why IANA has set aside the example ranges.
    – Ron Maupin ♦
    Jan 26 '21 at 2:55
  • @RonMaupin Oh I see, you didn't change my post, you asked my politely. So it isn't a rule, but it's a good recommendation. Thankyou. I incorrectly interpreted it as being abrupt and imagined the post might get deleted if I didn't. It looks like you are using canned responses - I believe outcome-oriented language works best on the internet "Kindly change your post to use IPs from the IANA example address range...". It would be great if you could update your canned response text accordingly to slightly improve the friendliness.
    – Kind Contributor
    Jan 26 '21 at 6:22
  • 7
    That was not a canned response. I made it up as I typed, and I asked with, "Please," which is the polite thing to do. I find your proposed response to be a soft order. I asked you to please not do that, but your response is saying to fix it. I was not telling you what to do (as in your response), but I was simply pointing out the correct way to do it.
    – Ron Maupin ♦
    Jan 26 '21 at 13:27
3

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.