Re: [shara] port randomization (draft-ymbk-aplusp-03)

[Lars Eggert <[e-mail]>]

On 2009-3-13, at 10:08, [e-mail] wrote:
> I'm also wondering, currently how many OSs and how many NATs do  
> implement a good randomization function?

No need to wonder, at least for OS: http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization-02#appendix-A

Lars

> More generally, in port range solutions we (I include myself)  
> propose sophisticated functions that surely make sense.
> However, I do believe that, if we want to see vendors rapidly  
> implement port range capabilities, we have to agree on a minimum set  
> of functionalities that makes it possible to build a viable port  
> range solution.
> I'm very convinced, for example, that it is straighforward (I mean  
> almost no cost and without any performance lost) for all vendors to  
> upgrade their routers to PRRs (Port Range Router), we did that on  
> Linux only by configuration.
>
>
>
> Pierre
>
> De : [e-mail] [mailto:[e-mail]] De la  
> part de Jan Zorz @ go6.si
> Envoyé : jeudi 12 mars 2009 21:49
> À : [e-mail]
> Objet : Re: [shara] port randomization (draft-ymbk-aplusp-03)
>
>
>
> Dan Wing wrote:
>>
>>> How important is port randomization and how big is the impact in  
>>> real
>>> life,
>>>
>>
>> Over the last 10 years there have been several attacks against
>> TCP and DNS that have exploited predictable emphemeral ports.  The
>> industry response to those attacks has been to (a) randomize
>> ephemeral port selection (rather than incrementing to the next
>> port number) and (b) increase the ephemeral port range used by
>> the OS.
>>
>> See
>> http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization-02#section-1
>> for more detailed answer to your question.
>>
> Dan, hi.
>
> I'm well aware of that draft, it is also referenced in in A+P draft.  
> Maybe I was not clear enough in my question, let me re-phrase it.
> In shared IP solutions we are taking away ports from customers, we  
> are taking away resources and everything is a compromise.
> Being said that, if we are happy with compromise, why not introduce  
> compromise also in a dirty hack as port randomization is.
>  So, can we live with randomization within for example range of 512  
> ports? Is this "good enough"? We are quite fond of accepting
> the compromise of shared IP as "good enough", because we have no  
> other option, so can we accept also the compromise of less  
> randomness in
> port randomization hack?
>
> I'm also curious to hear some aproximation from any HW vendor, what  
> does allocating "one port per request" means for PRR in larger  
> scale. I suspect this
> might very well be performance suicide, but this is only my  
> speculation. If not - good, we can go in that direction, which I  
> recognise as good also in several other ways.
>
> Thank you for your time and effort, Jan Zorz
> <ATT00001.txt>