Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau <willy@w.ods.org>]

On Sun, Jun 12, 2005 at 08:30:20PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 10:34:09AM +0200, Willy Tarreau wrote:
> >
> > > Sorry but this patch is pointless.  If I wanted to prevent you from
> > > connecting to www.kernel.org 80 and I knew your source port number
> > > I'd be directly sending you fake SYN-ACK packets which will kill
> > > your connection immediately.
> > 
> > Only if your ACK was within my SEQ window, which adds about 20 bits of
> > random when my initial window is 5840. You would then need to send one
> > million times more packets to achieve the same goal.
> 
> Nope, no sequence validity check is made on the SYN-ACK.

Sorry Herbert, but both RFC793 page 32 figure 9 and my Linux box disagree
with this statement. Look: at line 5, A rejects the SYN-ACK because the
ACK is wrong during the session setup.

And if you send the SYN-ACK on an established session, either it's in the
window in which case the other end will send an RST, or it's outside the
window, in which case the other end will resend an ACK to tell you what
it expects. So I maintain my statement that the SYN-ACK must be within the
window to cause a session reset. That's why I considered cisco's approach
a total bullshit, because they mangled the TCP implementation to protect
against in-window RSTs, but they failed to see that SYN-ACK would do exactly
the same.

I fail to find a case where both the SEQ and the ACK are ignored. This
is why I believe that the simultaneous connect mode introduces a weakness.

Cheers,
Willy