[change proposal] Re: bad interaction between TCP delayed ack and RSTs

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

Hi,

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

> Fortunately I am not trying to run a big server talking to lots of
> clients that send RST to close the connection down after sending data
> that doesn't expect a response, and apparently neither is anyone
> else. :-)
> 
> 
> This is the code change I tried out:
> 
>       if (tiflags & TH_RST) {
>               if (th->th_seq != tp->last_ack_sent
>                   && !((tp->t_flags & TF_DELACK)
>                        && th->th_seq == tp->rcv_nxt))
>                       goto dropafterack_ratelim;
> 
> I'm not positive this is exactly correct because I am not familiar with
> all the details of this code, but the idea was to drop the packet only
> if the sequence number doesn't match the last ack *and* the sequence
> number doesn't match what would be the last ack if everything had been
> acked.

Ok, after reading lots of stuff, I reluctantly[1] agree that this
seems desirable.

Just for the record 1: FreeBSD did a similar (in spirit) adjustment
to their RST spoof defence code (which uses a different strategy);
see their tcp_input.c, 1.316 and their log entry.

Just for the record 2: I'm not sure we do all the sequence number
checks for RST that draft-ietf-tcpm-tcpsecure suggests before the
ack-probe is sent (else the RST segement should be silently dropped!).
However, this is a different issue, and should probably only
addressed after draft-ietf-tcpm-tcpsecure is formally accepted as
PROPOSED STANDARD by IETF.

[1] I suspect we might need a generic defense against blackholed RSTs
leading to accumulated waiting server processes; but then again, 
maybe the servers in question should have their own timeout handling
outside of the kernel.

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