Subject: Re: pf for NetBSD
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Seth Kurtzberg <email@example.com>
Date: 11/06/2002 09:07:46
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 firstname.lastname@example.org
> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
M. I. S. Corp
Pager 888-605-9296, or email@example.com