Internet-Draft on Port Randomisation

Internet-Draft on Port Randomisation

[Eugene Teo]

Has anyone read this Internet-Draft?
http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-02.txt

In this memo, there are descriptions of four different ephemeral port
randomisation algorithms (see page 17).

Algo #1 and #2 are simple port randomisation algorithms. Algo #3 is
what we have in Linux. The memo suggested algorithm #4, double-hash
randomisation algorithm, which is an improvement to algo #3 (see page
15).

Does anyone have any thought about the improved algorithm? Is this
worth implementing, given the possible additional overhead that it
has?

Thanks, Eugene

Re: Internet-Draft on Port Randomisation

[Stephen Hemminger]

Eugene Teo wrote:
> Has anyone read this Internet-Draft?
> http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-02.txt
>
> In this memo, there are descriptions of four different ephemeral port
> randomisation algorithms (see page 17).
>
> Algo #1 and #2 are simple port randomisation algorithms. Algo #3 is
> what we have in Linux. The memo suggested algorithm #4, double-hash
> randomisation algorithm, which is an improvement to algo #3 (see page
> 15).
>
> Does anyone have any thought about the improved algorithm? Is this
> worth implementing, 
No the added lock overhead of a global next free port array is not worth 
it. Think of big web server under
DoS pressure. The existing port search can run in parallel, Algo #4 was 
suggested by people
who don't work on a real SMP OS.

Re: Internet-Draft on Port Randomisation

[Eugene Teo]

On Tue, Sep 9, 2008 at 12:58 PM, Stephen Hemminger
<stephen.hemminger@vyatta.com> wrote:
> Eugene Teo wrote:
>>
>> Has anyone read this Internet-Draft?
>>
>> http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-02.txt
>>
>> In this memo, there are descriptions of four different ephemeral port
>> randomisation algorithms (see page 17).
>>
>> Algo #1 and #2 are simple port randomisation algorithms. Algo #3 is
>> what we have in Linux. The memo suggested algorithm #4, double-hash
>> randomisation algorithm, which is an improvement to algo #3 (see page
>> 15).
>>
>> Does anyone have any thought about the improved algorithm? Is this
>> worth implementing,
>
> No the added lock overhead of a global next free port array is not worth it.
> Think of big web server under
> DoS pressure. The existing port search can run in parallel, Algo #4 was
> suggested by people
> who don't work on a real SMP OS.

Thanks Stephen.

Eugene

Re: Internet-Draft on Port Randomisation

[Andi Kleen]

Stephen Hemminger <stephen.hemminger@vyatta.com> writes:

> Eugene Teo wrote:
>> Has anyone read this Internet-Draft?
>> http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-02.txt
>>
>> In this memo, there are descriptions of four different ephemeral port
>> randomisation algorithms (see page 17).
>>
>> Algo #1 and #2 are simple port randomisation algorithms. Algo #3 is
>> what we have in Linux. The memo suggested algorithm #4, double-hash
>> randomisation algorithm, which is an improvement to algo #3 (see page
>> 15).
>>
>> Does anyone have any thought about the improved algorithm? Is this
>> worth implementing,
> No the added lock overhead of a global next free port array is not
> worth it. 

[haven't read the draft] But you don't necessarily need a full global
lock for such a scheme. What works too is to access global state only
ever N accesses and pre-allocate a small range per CPU. While there's
still some global overhead then, it happens significantly less. My old
alternative ipid setup algorithm worked this way.

One drawback of such a scheme today: on RT kernels the per CPU state
tends to be become a problem.

-Andi
-- 
ak@linux.intel.com

Re: Internet-Draft on Port Randomisation

[David Miller]

From: Andi Kleen <andi@firstfloor.org>
Date: Tue, 09 Sep 2008 16:28:30 +0200

> [haven't read the draft] But you don't necessarily need a full global
> lock for such a scheme. What works too is to access global state only
> ever N accesses and pre-allocate a small range per CPU. While there's
> still some global overhead then, it happens significantly less. My old
> alternative ipid setup algorithm worked this way.

Should work well on a 64K cpu system.

Re: Internet-Draft on Port Randomisation

[Andi Kleen]

On Tue, Sep 09, 2008 at 01:04:24PM -0700, David Miller wrote:
> From: Andi Kleen <andi@firstfloor.org>
> Date: Tue, 09 Sep 2008 16:28:30 +0200
> 
> > [haven't read the draft] But you don't necessarily need a full global
> > lock for such a scheme. What works too is to access global state only
> > ever N accesses and pre-allocate a small range per CPU. While there's
> > still some global overhead then, it happens significantly less. My old
> > alternative ipid setup algorithm worked this way.
> 
> Should work well on a 64K cpu system.

If you make N large enough it can work with pretty much any number of CPUs. 
The main drawback is that it's losing random bits the larger N is, but then 
64k is not really remotely secure anyways.

Due to the later reason I doubt such a change is very interesting.
Also there's the issue on fully preemptible kernels.

If you wanted a more secure port space what would like make more 
sense is to use IPv6 and use e.g. 32bit out of the local network
address space for port randomization too.

-Andi
-- 
ak@linux.intel.com