Re: bad interaction between TCP delayed ack and RSTs

[Ignatios Souvatzis <is%netbsd.org@localhost>]

On Tue, Jun 16, 2009 at 12:17:40PM -0400, Miles Nordin wrote:
> >>>>> "jmm" == Joanne M Mikkelson <jmmikkel%MIT.EDU@localhost> writes:
> >>>>> "is" == Ignatios Souvatzis <is%netbsd.org@localhost> writes:
> 
>     is> If the RST wasn't abused, the firewall's behaviour would be
>     is> reasonable.
> 
> It seems like you're not listening.  She says Linux sends an RST the
> same way when you call close() on a socket with unread data, and it
> seems reasonable to me---why bother acknowledging data that can never
> be read?

Please forgive me. You are both right in this respect; this behaviour
is in the official protocol.
 
> The firewall and NetBSD are both playing around with the
> interpretation of TCP.  The problem is, NetBSD's allowed to, and it's
> the firewall's job to accomodate NetBSD, not the other way round.

As I wrote in my other message: we're actually changing the protocol
as in a recommendation then (and still) discussed by the IETF TCP
maintainance working group. So yes, to a certain degree we are to
blame, but what to do about it? After all, packets (e.g. the ACK
that is intended to provoke the 2nd RST, or the 2nd RST) can be
lost for ... legitimate (well, non-firewall-related) reasons.

Maybe we should start a timer that guards against this condition, 
and tears down our end of the connection anyway after some reasonable
time, but what is reasonable, and what are the security implications
in this case?

I guess this issue should be discussed with IETF TCPM.

        -is
-- 
seal your e-mail: http://www.gnupg.org/