Date: Wed, 28 May 2003 11:59:14 -0400 From: Barney Wolff <barney@databus.com> To: freebsd-net@freebsd.org Subject: [dab@BSDI.COM: Re: [e2e] TCP-SYN and delayed TCB allocation] Message-ID: <20030528155914.GA4573@pit.databus.com>
next in thread | raw e-mail | index | archive | help
I found this message interesting. Can someone point me to the rationale for putting all conns through the syncache? Thanks, Barney ----- Forwarded message from David Borman <dab@BSDI.COM> ----- To: end2end-interest@postel.org Date: Wed, 28 May 2003 09:46:00 -0500 (CDT) > > B) has it been modified that it is now done after the 1st ACK? It all depends on what OS you are talking about... FreeBSD makes use of the syncaching code that I wrote back in the days of the the original SYN flood attacks. They now use it for all their incoming connections, so only minimal state is kept for connections in SYN-RCVD state. When the ACK is received in response to the SYN,ACK, the full blown TCP is created. However, since the original syncache code was only used when the normal mechanism overflowed, it did not do any SYN,ACK retransmissions for connections in the syncache. But since FreeBSD now sends all their connections through the SYN cache, they had to add timers so that they can do SYN,ACK retransmissions out of the syncache. But that means that during a real synflood attack, they are doing more work sending out SYN,ACK retransmissions for all those bogus connections. And for most connections, you are eventually going to create a full blown TCB anyway, so there really isn't any cost savings in defering the full TCB creation until transition from SYN-RCVD to ESTABLISHED. BSD/OS still uses the standard creation of a full TCB block when a SYN is received, and only when that queue overflows do connections get created in the syncache, and we don't do SYN,ACK retransmissions out of the syncache. So, we can hang valid connections in the syncache if our SYN,ACK is received by the other side, but the returning ACK is lost. (If our SYN,ACK is lost, the other side will retransmit the SYN, causing us to generate another SYN,ACK). But when you are under attack, I figure its better to be able to maintain connectivity for the majority of the valid connections, rather than buckle over and die. > > if not, any reason why not B? we would so the same if we had a > > "NAT/Firewall" with delayed binding etc > > If B), where do you put the data that could have been sent in the SYN? > I'm not sure you can ACK the SYN without ACKing the data therein (though > you don't deliver it until receiving the ACK and transitioning to > ESTABLISHED)... As long as you don't ACK the data, you don't need to save it. Throw away the data and just ACK the SYN. The other side will have retained a copy of the data, and will have to retransmit it. Slow, but it will work. -David Borman ----- End forwarded message ----- -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030528155914.GA4573>