TCP Timeouts

[vmolinaro]

Guys,

I'm looking for a single document that describes the timeouts configurable in the PIX for the following:

1) Half-Open TCP Connections

2) Idle Connections,

3) Half-Closed Connections

I remember seeing a table that describes these (other related timeouts or limits-embryonmic) paramters but I can't seem to find it on the website now.

Thanks in advance for your help,

Vito

[scoclayton]

Vito,

Take a look at the following doc. This is from the command ref on the timeout command. I am not aware of any other related docs but if this doesn't help, let us know.

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/tz.htm#wp1026093

Scott

[vmolinaro]

Scott thanks for response. How does the PIX handle half-open connections? That is, peer client sends a SYN which matches a ACL and the PIX permits the packet. The target host is down and therefore does not reply with a SYN/ACK. The peer client will continually to try sending the SYN as per TCP Stack spec. What would the PIX do in these scenarios?

Vito

[scoclayton]

Vito,

Not a problem. As long as the SYN's are valid, the PIX will continue to let them pass provided the embryonic limit has not been reached. There is no "health check" per se on the PIX to see if the internet host is alive. That is more a function of the load balancer line of products. Is this what you were looking for?

Scott

[vmolinaro]

Scott,

This means the TCP session never gets added to the state table thus no need for a half-open timeout configurable paramater in the PIX, right?

Thanks for the reponses mate.

[scoclayton]

I don't know that I quite understand your point here. The PIX does keep track of the "half-open" connections. This is defined as any connection that has not completed the 3-way handshake (SYN, SYN-ACK, ACK). In most DDoS attacks, you will see a SYN from the attacker, a SYN-ACK from the server back to the attacker and then nothing more. This is what starves the resources on the machine you are trying to protect.

To the point that you have been asking about, the normal TCP backoff timer for sending re-transmissions is 1, 2, 4, and 16 secs (I think). The PIX will not add a new state for each one of these assuming the same source address, source port, dest address, dest port but if your server is down, you can probably assume that there is going to be more than 1 host trying to access this box. You need the PIX to clear these connections from time to time so that memory is not consumed.

Does that clarify at all or just muddy the waters more?

Scott

[vmolinaro]

Scott, this makes things very clear. If I may refer you to your comments "You need the PIX to clear these connections from time to time so that memory is not consumed". I am referring to the clearing done by the PIX. Is it timer based, and if so which timeout command, or is the embryonic limit that takes are of this?

Appologies for not explaining things clearer.

Vito

[scoclayton]

Vito,

Yes, this cleaning process is indeed timer based (the half-open conn timer to be exact). The embryonic connection limit tells the PIX how many half-open connections to allow in to an individual server before getting "aggressive" with the conns. When the embryonic connection is reached, the PIX intercepts any new SYN packets and spoofs the SYN-ACK from the host we are protecting. If we don't get an ACK back within a set amount of time, we clear the conn from the PIX and therefore keep the traffic off of the host we are protecting.

Scott

[vmolinaro]

Scott,

Can I configure the half-open conn timer? If so what is the command? Or if there is no command what is the default setting?

This will answer all my question.

Thanks heaps for your help and sorry for the long-winded thread.

Vito

[scoclayton · Accepted solution]

Ahhh, finally got ya. No, the half-open connection timer is not configurable. It is set for 2 mins however. Meaning, once we get the initial SYN packet in, the seesion has 2 mons to complete before we clear it.

And no problem on the long thread.

Scott

[vmolinaro]

Hey Scott, thanks for working this through with me mate. Got all the answers I need now thanks to you.

Vito