Ephemeral port range (patch)

[Fernando Gont]

At 04:43 a.m. 03/03/2008, Mike Silbersack wrote:

>Earlier in the week, I had commented (via private e-mail?) that I 
>thought that Amit Klein's algorithm which I recently implemented in 
>ip_id.c might be adapted to serve as an ephemeral port 
>allocator.  Now that I've thought more about it, I'm not as certain 
>that it would fit well.  I'll try to sketch out my ideas and see if 
>I can figure out how it could fit.

(Shame on me... somehow you mail got stuck in my queue, and I didn't 
respond to it).

While I haven't look match at the scheme proposed by Amit, I think 
there's a "flaw" with the algorithm: IP IDs need to be unique for 
{source IP, des IP, Protocol}. And the algorithm still keeps a 
*global* IP ID. That means you'll cycle through the whole IP ID space 
when you probably didn't need to.

Here, two, a double-hash based scheme (a la RFC1948) will do. It 
would basically separate the IP ID space for every {source IP, dest 
IP, Protocol} tuple, and thus you'll cycle through the IP ID space 
only as fast as needed.

What's interesting is that when it comes to port randomization, IP ID 
randomization, and even timestamp randomization, the double-hash 
scheme seems to be the right solution.

That said, at least theoretically speaking, one could argue that 
there shouldn't be a problem with simply randomizing the IP ID 
number. For connection-oriented protocols, you should be doing PMTUD, 
and thus will not care about the IP ID. If your packets are doing 
fragmentation, then on links will large bandwidth-delay products 
you're already in trouble. For connection-less transport protocols 
(e.g., UDP), while they usually do not implement PMTUD, they also do 
not implement flow-control or congestion control. So you are either 
sending data to a local system (e.g., in a LAN), or you probably 
shouldn't be sending data that fast (and then you shouldn't have 
problems with trivially randomizing the IP ID).



>The double-hash concept sounds pretty good, but there's a major 
>problem with it.  If an application does a bind() to get a local 
>port before doing a connect(), you don't know the remote IP or the remote port.

Yes, this is described in Section 3.5 of our id 
(http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt). 
Our take is that in that scenario you could simply randomize the 
local port. (i.e., implement the double-hash scheme, and fall-back to 
trivial randomization when you face this scenario).



>There's a related "feature" in the BSD TCP stack that all local 
>ports are considered equal; even for applications that do a 
>connect() call and specify a remote IP/port, we do not let them use 
>the same local port to two different remote IPs at the same 
>time.  This puts a limit on the total number of outgoing connections 
>that one machine can have.

mmm... I see. So this could limit the number of outgoing connections 
to about (ephemeral_ports/TIME_WAIT). Any objections against changing 
this? At least for outgoing connections (i.e., non-listening 
sockets), this shouldn't be the case. I'd be interested in working on 
this issue...

Kind regards,

--
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1