Re: bad interaction between TCP delayed ack and RSTs

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

Hi Joanne,

I found time to look up the relevant NetBSD Security Advisory, which
tells more than the cvs log:

On Tue, Jun 16, 2009 at 03:08:27AM -0400, Joanne M Mikkelson wrote:

> - The client sends some data.
> - Delayed ack causes NetBSD to send no ack for this packet.
> - The client exits (or closes the socket).
> - Windows sends an RST/ACK to close the TCP connection (it does this a
>   lot, if not most of the time -- I do not know when it uses a FIN).
> - When the RST message arrives, NetBSD responds to the RST with an ACK
>   and then drops the RST.
...
> I assume this code is intended as defense against RST spoofing? The log
> message (revision 1.194) for this says: "respond to RST by ACK, as
> suggested in NISCC recommendation". I can't find any recommendation like
> this; advisory 236929 seems likely but it makes no such recommendations
> (its primary recommendation seems to be to use IPsec!).

You'll find the full official explanation from the NetBSD side in our
security advisory SA2004-006[1].

As far as I can tell, the behaviour is roughly along the lines of
draft-ietf-tcpm-tcpsecure-11.txt[2] (was -0.txt back then). I'll
have to read more code to tell exactly, especialy as [2] has evolved
and is still not finalized.

So you're right, NetBSD has changed the protocol from RFC 793.

We have done so in a manner which we expected to be official shortly
afterwards. Only it still is in the discussion state...

Regards,
        -is

[1] 
ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc
[2] http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure-11

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