Subject: [tcpm] ip_local_reserved_ports impact on inet_csk_get_port (Linux)

From: Erik Hugne <[email-masked]>
Date: Mon, 18 May 2015 11:53:08 +0200

I raised this on netdev a few weeks ago, but there was no recognition.
Short story; Linux has a sysctl knob (net.ipv4.ip_local_reserved_ports)
that can be used to exclude ports from the random local port assignment
(net.ipv4.ip_local_port_range).
If the initial random port is within the reserved ports subset, the port
will be selected in an incremental/linear fashion.
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ipv4/inet_connection_sock.c#n115

I believe this port reservation is a Linux specific thing, but i was hoping
that i could get a tcpm comment if this is considered ok, or if the port
selection algorithm needs to be smartened up in the case where there are
reserved port ranges.

//E

----- Forwarded message from Erik Hugne <[email-masked]> -----

Date: Tue, 5 May 2015 14:47:59 +0200
From: Erik Hugne <[email-masked]>
To: [email-masked], [email-masked]
Cc: Richard Alpe <[email-masked]>, Onar Olsen <[email-masked]>, [email-masked]
Subject: tcp: ip_local_reserved_ports impact on inet_csk_get_port()
User-Agent: Mutt/1.5.21 (2010-09-15)

Defining a port range in net.ipv4.ip_local_reserved_ports can cause a linear
and predictable behavior of inet_csk_get_port().
This occurs when smallest_rover = rover = prandom_u32() % remaining + low;
hits a value in the reserved range. The algorithm will then try the next
consecutive port number until a free port is found.

Example:
net.ipv4.ip_local_port_range = 32768	61000
net.ipv4.ip_local_reserved_ports = 35000-61000

This will give ~92% chance that the initial random port will be in the
reserved range, and that the port selection will be done linearly
starting from 32768.
Section 3.3 in RFC6056[1] describes several port selection algorithms, and Linux
seems to follow #1. This does not seem to be the best alternative since
e3826f1e946e ("net: reserve ports for applications using fixed port numbers")

If the local port range is set not to overlap with the reserved ports,
inet_csk_get_port will give a better randomness in the port selection.

//E

[1] https://tools.ietf.org/html/rfc6056

----- End forwarded message -----

---

From: [email-masked] (Christos Zoulas)
Date: Mon, 18 May 2015 09:11:08 -0400

On May 18, 11:53am, [email-masked] (Erik Hugne) wrote:
-- Subject: [tcpm] ip_local_reserved_ports impact on inet_csk_get_port (Linux

| I believe this port reservation is a Linux specific thing, but i was hoping
| that i could get a tcpm comment if this is considered ok, or if the port
| selection algorithm needs to be smartened up in the case where there are
| reserved port ranges.

As another data point, NetBSD also has the port reservation feature, but
does not suffer from the linear scan:

    http://nxr.netbsd.org/xref/src/sys/netinet/portalgo.c

christos

---

From: Erik Hugne <[email-masked]>
Date: Mon, 18 May 2015 16:40:24 +0000

The default algo_bsd does seem to revert to a linear (pick next lower) if the initial port hits a reserved range..

//E

On 18 May 2015 15:11, Christos Zoulas <[email-masked]> wrote:
On May 18, 11:53am, [email-masked] (Erik Hugne) wrote:
-- Subject: [tcpm] ip_local_reserved_ports impact on inet_csk_get_port (Linux

christos

---

From: [email-masked] (Christos Zoulas)
Date: Mon, 18 May 2015 13:08:36 -0400

On May 18,  4:40pm, [email-masked] (Erik Hugne) wrote:
-- Subject: Re: [tcpm] ip_local_reserved_ports impact on inet_csk_get_port (L

| The default algo_bsd does seem to revert to a linear (pick next lower) if
| the initial port hits a reserved range..

algo_bsd is the "Traditional BSD Port Selection Algorithm" which is always
linear as described in RFC 6056 section 2.2.

christos