Date: Mon, 03 Mar 2008 12:45:17 -0200 From: Fernando Gont <fernando@gont.com.ar> To: Mike Silbersack <silby@silby.com> Cc: Rui Paulo <rpaulo@fnop.net>, freebsd-net@freebsd.org, Kevin Oberman <oberman@es.net> Subject: Re: Ephemeral port range (patch) Message-ID: <200803031454.m23EsVeZ006812@venus.xmundo.net> In-Reply-To: <20080303002815.U37933@odysseus.silby.com> References: <Your message of "Sat, 01 Mar 2008 11:34:27 -0200." <200803011338.m21DcY9Z026418@venus.xmundo.net> <20080301224217.33F0A45047@ptavv.es.net> <200803020034.m220YJ6t018608@venus.xmundo.net> <20080303002815.U37933@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803031454.m23EsVeZ006812>