[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pps or other unknown upper bound?



On 11/22/05, Travis H. <[email protected]> wrote:
> On 11/17/05, Kevin <[email protected]> wrote:
> > On 11/17/05, Jon Hart <[email protected]> wrote:
> > > The funny thing is, in my tests, despite having ~31000 source ports to
> > > choose from, the client is unlucky enough most of the time and very
> > > quickly manages to reuse a port.  It depends on what else the client is
> > > doing, but I saw a case earlier today that after about 300 connections,
> > > the source port was reused.
> >
> > Does Debian have random source ports?
> >
> > My thought is that the classic approach of using ephemeral ports
> > sequentially is acting as a poor man's "least recently used" algorithm
> > in choosing the source port for each new session.
> >
> > Depending on the implementation, source port randomization could cause
> > a source port to be reused much sooner than with the "classic"
> > approach.
>
> Classic birthday attack.  If the source ports are chosen randomly, and
> there are 31000 ports to choose from, one would expect to see re-use
> after approximately sqrt(n), or 176 tries.
>
> Shouldn't the client still check to see if the socket is involved in a
> 2MSL WAIT state, and pick another source port if it is?  Or better yet
> - choose randomly from sockets not involved in WAIT states, if there
> are any.  That is trickier, but not impossible.
I'm certain that the local host will not select a source port that has
an existing socket involved in 2MSL wait state, will choose the new
socket _randomly_ from sockets not _currently_ involved in wait states
in the local state table.
But randomly choosing the local source port from the available
ports,instead of using ports incrementally, vastly increases the
chance that the port chosen was involved in a wait state very recently
(as you stated, birthday problem).
In the degenerate case where a single source IP is rapidly opening and
closing TCP sessions to a single destination IP and port, reusing a
port "early", while the selected quad is still in a remote server of
firewall state table in a 2MSL wait state, causes the hang that
started this thread.
Thus my proposed "aggressive" tuning to permit with early reuse of a quad.
Kevin