From owner-freebsd-current@FreeBSD.ORG Mon Nov 10 02:05:20 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7282816A4CE for ; Mon, 10 Nov 2003 02:05:20 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C0EE43FF3 for ; Mon, 10 Nov 2003 02:05:17 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 67221 invoked from network); 10 Nov 2003 10:08:05 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 10 Nov 2003 10:08:05 -0000 Message-ID: <3FAF62BE.BEA1B3EE@pipeline.ch> Date: Mon, 10 Nov 2003 11:04:46 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack References: <3FAE68FB.64D262FF@pipeline.ch> <20031110005543.C532@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: mb@imp.ch cc: ume@freebsd.org cc: sam@errno.com Subject: Re: tcp hostcache and ip fastforward for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 10:05:20 -0000 Mike Silbersack wrote: > > On Sun, 9 Nov 2003, Andre Oppermann wrote: > > > Hello all, > > > > this patch contains three things (to be separated for committing): > > I don't have much time free in the next week, so I cannot do a complete > review. However, I just did a quick readthrough. > > > tcp_hostcache > > This looks good to me, I've been waiting for you to finish it for a long > time. You actually missed a point: > > - Ensures that a cached entry isn't added until the 3WHS is completed. > > This should help make synfloods with random source addresses less > damaging. The cache will only be updated if the tcp connection is being closed. All updates are done in tcp_drop. The T/TCP updates have to be done inline during connection setup. I've converted all places which updated the T/TCP rtmetrics in routing table with updates to the hostcache. > Would it be possible to provide a way for netstat to view the host cache > table? I think that it would be useful. At the moment is visible via "sysctl -a net.inet.tcp.hostcache.list". Syncache ain't visible via netstat either. So far you had to use route get x.x.x.x to see the rtmetrics for a (host-)route. So I'm sure whether netstat is the right place for it. But I can do that in a second step. > > ip_fastforward > > No comment, I didn't read through this part, and I'm not familiar with > the forwarding code. > > > tcp bug fixes and MSS DoS attack prevention > > Generally good, but: > > > - adds tcp_minmssoverload which disconnects a TCP session if > > it receives too many (1000) packets per second whose average > > segement size is lower than tcp_minmss > > - DoS attack 2: make MSS very low on local side of connection > > and send maaaany small packet to remote host. For every packet > > (eg. 2 bytes payload) a sowakeup is done to the listening > > process. Consumes a lot of CPU there. > > I don't think that your patch for this really solves anything. Anyone who > would write such a program could just as easily make it use concurrent > connections, have it auto-reconnect, and/or have it only send 900 packets > per second. I think that you should remove this section of the patch, but > leave a comment about this problem existing so that it will be thought > more about in the future. The actually solves the problem. Let me explain in more detail. When we get so many small packets per second the CPU will become pretty saturated. Depending on how much data is sent it can go on for minutes or hours. This code jumps in there and disconnects the within a second. Of course someone can immediatly reconnect and do it again. But that needs the 3WHS again and gives some delay. In the end this code is like the ICMP rate limiter code. It there to migitate a problem to manageable level, not to make it go away. > After the rest of the code is in, we can brainstorm on other possible > solutions... I think that Mini's idea of approaching it as an optimization > is the correct one. Ok, for brainstorming. For Mini's idea see my answer to him. -- Andre