[VPN] Application timeouts over VPN...HELP!

[Dana J. Dawson]

 > You make it sound as it's a commonly accepted fact . Well, it's not.
 > There is nothing wrong with 'abnormally' Long/short TCP sessions.
 > Consider SSH, IMAP, PPTP and multitude of instant messaging protocols
 > as few examples.

There may be nothing wrong with "abnormally long" TCP sessions from a TCP or a 
security standpoint (I'm ignoring the concept of an "abnormally short" TCP 
session, since I don't believe such a thing exists), but when devices that track 
the states of those sessions are involved, such as firewalls, then there are 
very real issues that could be considered problems.  Such devices have to 
allocate resources for each connection, so they must impose an idle timeout of 
some sort or risk eventual failure due to lack of resources.  The fact that 
firewalls are as common as they are today implies to me that it is now, indeed, 
bad practice for a developer to assume that a TCP session can be left idle for 
an arbitrary length of time.  Similarly, I think it's also bad practice for a 
firewall administrator to impose an excessively short timeout period for idle 
sessions.  What are reasonable times?  That's obviously open to individual 
opinion, but more extreme time periods will elicit more universal agreement. 
For example, I doubt anyone would think a one year idle timeout is reasonable, 
nor that a ten second timeout is reasonable.  The most common timeouts I 
encounter are in the range of half an hour up to a small number of hours 
(usually less than 8).  Within that range there is still room for much debate. 
I believe the original post in this topic referred to a 65 second timeout, which 
I think is unreasonably short.  However, I also think that it's not reasonable 
to assume that an idle TCP session should always survive for several (perhaps 
even just a few) hours, and that developers should avoid such situations by 
either closing a connection when it's not "immediately" needed (whatever that 
means), by using a keepalive and/or recovery mechanism, or by using a 
connectionless protocol such as UDP.

Dana

-- 

Dana J. Dawson                     djdawso at qwest.com
Senior Staff Engineer              CCIE #1937
Qwest Communications               (612) 664-3364
600 Stinson Blvd., Suite 1S        (612) 664-4779 (FAX)
Minneapolis  MN  55413-2620

"Hard is where the money is."