Ugh. Whoops.
Well, that will teach me to cut & paste from the documentation. I scanned
it enough to verify that it discussed the different closure methods, but
not carefully enough to see what it was actually saying.
Clarifications in-line.
At 09:51 PM 02/23/2000 +0100, Mikael Olsson wrote:
>I'm a bit curious here....
>
>Lisa Napier wrote:
> >
> > From the documentation:
> >
> > The connection timewait option is necessary for end host applications whose
> > default TCP terminating sequence is simultaneous close instead of the
> > normal shutdown sequence (see RFC 793). In simultaneous close, four TCP
> > segments are exchanges in the shutdown instead of the normal three.
>
>Errr.. Exqueeze me? "Normal three"? Doesn't graceful TCP close always do
>
>A ----- FIN -----> B
>A <--- FIN+ACK --- B
>A <---- FIN ------ B
>A ---- FIN+ACK --> B
>
>?
Yeah, that's how I've always generally expected to see it.
> > The default behavior of the PIX Firewall is to track the normal three
> > shutdown sequence and release the connection after the third segment. This
> > quick release heuristic enables the PIX Firewall to sustain a high
> > connection rate.
>
>Does it do immediate close after the FIN from B to A?
>or directly after the FIN+ACK from A to B?
I believe the PIX closes a connection when it sees a FIN in each direction,
and the FIN-ACK following. So, in your example, we'd see the connection
close after FIN-ACK from A to B. Normal close sequence, PIX tears down
connection when we'd expect, after both sides have sent FIN & FIN-ACK.
We see strange behavior when the order is a little different, as in a
simultaneous close.
A ----- FIN ----> B
A <--- FIN------ B
A ---- FIN-ACK --> B
A <---- FIN-ACK ------ B
In this case, PIX sees a FIN from each side, then waits for the FIN-ACK,
and closes the connection. The final FIN-ACK from B -> A is
dropped. Unless you've enabled 'sysopt timewait'.
I'll check with the doc people & see if we can clean up the explanation in
the documentation.
Thanks for pointing this out,
Lisa Napier
Product Security Incident Response Team
Cisco Systems
>Either way, this sounds like you're begging for drop entries, since there is a
>very high possibility that this last segment will get lost in transit and
>get retransmitted.
>
>IMHO, a 70 second linger after the final packet is a good way to catch
>FIN / FIN+ACK retransmits.
>
>Connections like these are splendid candidates for connection replacement
>if your connection pool grows full, so overload won't be a real concern
>I think. Of course, if they are replaced, you'll inevitably see drops.
>
>Regards,
>/Mike
>
>--
>Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 �RNSK�LDSVIK
>Phone: +46 (0)660 105 50 Fax: +46 (0)660 122 50
>Mobile: +46 (0)70 248 00 33
>WWW: http://www.enternet.se E-mail: [EMAIL PROTECTED]
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
