RE: Is it possible to derease gradually the number of Client port (add up time table) ?

["Rob Shein" <shoten () starpower net>]

There's more than one way to gut a fish, but the answer as to why one
performs the method is the same: To gut the fish. :)

> -----Original Message-----
> From: David LeBlanc [mailto:dleblanc () exchange microsoft com] 
> Sent: Wednesday, March 10, 2004 4:03 PM
> To: Rob Shein; Todd Jang; incident
> Cc: leehong () coponet com
> Subject: RE: Is it possible to derease gradually the number 
> of Client port (add up time table) ?
>
>
> Rob Shein [mailto:shoten () starpower net] said:
>
> > As for why client ports have to change, the answer is simple; if the
> client were to use the same source port every time, it would 
> only be able to make one connection at a time, and every 
> application would have to cooperate to make sure that they 
> knew which one was talking at any point in time.  
>
> This isn't quite correct. An application can make a number of 
> outbound connections from the same port if that app uses 
> SO_REUSEADDR when it creates and binds the socket. A non-PASV 
> mode FTP server does exactly this - lots of outbound 
> connections from the same source port. Port scanners that 
> enable the source port to be set do exactly the same thing. 
> With a TCP connection, remote address, remote port and local 
> port all 3 go into establishing uniqueness. A UDP socket 
> would usually have to coordinate because it is connectionless.
>
> There's some overhead to reusing sockets, which I think is 
> the major reason why they change under normal conditions.


---------------------------------------------------------------------------
Free 30-day trial: firewall with virus/spam protection, URL filtering, VPN,
wireless security

Protect your network against hackers, viruses, spam and other risks with Astaro
Security Linux, the comprehensive security solution that combines six
applications in one software solution for ease of use and lower total cost of
ownership.

Download your free trial at 
http://www.securityfocus.com/sponsor/Astaro_incidents_040301
----------------------------------------------------------------------------