Messages in this thread | | | Date | Sun, 12 Jun 2005 13:40:39 +0200 | From | Willy Tarreau <> | Subject | Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.) |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |