I agree; changing fundamental TCP behavior, especially in a way that the
design explicitly prohibits, is problematic.

TCP does have the keepalive configuration which will force the
connection to close down, not immediately, but promptly.

On Wed, 2002-11-06 at 08:42, der Mouse wrote:
> > How does pf handle state from an outgoing connection that is closing?
> > Under ipf the state for an outgoing TCP connection appeared to be
> > torn down as soon as the local side closed the connection.  [...]  If
> > pf handled that state better and kept the TCP-filter state around for
> > 2xMSL that would be a vast improvement.
> 
> But still not very good.  There is no reason why a TCP connection
> cannot be closed in one direction and still keep streaming data in the
> other more or less indefinitely.  If ipf - or any such firewalling
> package - tears down its state as soon as one direction closes, I would
> call that a priority-1 bug.
> 
> Of course, the whole purpose of something like ipf is to (selectively)
> break interoperability, but this is breaking interoperability for
> connections that it has been configured to *not* break.
> 
> /~\ The ASCII				der Mouse
> \ / Ribbon Campaign
>  X  Against HTML	       mouse@rodents.montreal.qc.ca
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
-- 
Seth Kurtzberg
M. I. S. Corp
480-661-1849
Pager 888-605-9296, or 6059296@skytel.com