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

[<[e-mail]>]

This is a good question.
I'm also wondering, currently how many OSs and how many NATs do implement a good randomization function?
 
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