Re: bad interaction between TCP delayed ack and RSTs

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

On Tue, Jun 16, 2009 at 05:03:40AM -0400, Joanne M Mikkelson wrote:
> > Ahem. IMHO, the problem isn't that a RST is lost. It is that it is
> > sent at all!
> 
> No RSTs were lost in the creation of my problem. :-)
> 
> I will not argue with the assertion that the connection *should* be
> shut down with a FIN. However, I am reporting what is *actually*
> happening.
> 
> > I believe the RST checking foo in our code is for a partial defense
> > against 3rd-party rogue RSTs. It's not meant, and can't be, to ACK
> > data-on-the-fly when a RST is receive- because by definition, when 
> 
> I have several packet traces showing NetBSD sending an ACK after the
> RST. And I can generate more at will. If it's a third party (attack)
> RST the ACK is harmless. If it's not a third party RST the ACK will
> generate another RST, unless there's a firewall dropping the ACK.

Well... the problem is still the RST.

If the RST wasn't abused, the firewall's behaviour would be
reasonable.

But yes, maybe there should be an easy way to defend against this
behaviour - but weakening the rogue RST defense is a dangerous
thing to do.

Less dangerous seem:

Ack-on-push, if thats enough for you
SO_KEEPALIVE on the server sockets. 

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