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

["Jan Zorz @ go6.si" <[e-mail]>]

Pierre, hi.

[e-mail] wrote:
> This is a good question.
Thnx. Let's wait for an answer to pop up (if) :)
> I'm also wondering, currently how many OSs and how many NATs do 
> implement a good randomization function?
Not sure... but rather than port randomization I would prefer to see 
dnssec implemented in clients, maybe also combined with dnscurve.
>  
> More generally, in port range solutions we (I include myself) propose 
> sophisticated functions that surely make sense.
We have no other option. But, how sophisticated (complex) may we get? 
Where is the balance between "good enough" usability and complexity on 
the other hand?
> 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.
If we want to assure at least minimum compatibility between different 
vendors equipment and still have a solution, that makes sense to 
customer, then we need to set, what minimum means. I suspect every 
vendor will speculate with it's own proprietary features, so we need to 
set basics straight. You are perfectly right.
> 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.
Did you implement non-contiguous port allocations?

regards, Jan Zorz
>  
>  
>  
> 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