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

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Jan Zorz @ go6.si
> Sent: Thursday, March 12, 2009 1:49 PM
> To: [e-mail]
> Subject: 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.

This is what today's NAPT devices do today, but without a separate
protocol to request each port.

And, the CPE does not necessarily need to request each port; it
could ask for ~5 or ~10 ports and then utilize them as it needs,
and then get another batch of ~10 ports.  It comes down to
the design decisions for the protocol between the CPE and the 
PRR so that it is possible to utilize the entire 64K port 
range.

-d

> 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
> 
>