From owner-freebsd-security Sun Jan 23 19:18:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 4115214D5D for ; Sun, 23 Jan 2000 19:18:35 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com ident=200 years too late) by mail.xmission.com with esmtp (Exim 3.03 #3) id 12Ca1R-0007LV-00; Sun, 23 Jan 2000 20:18:34 -0700 Message-ID: <388BC59A.1AD012C5@softweyr.com> Date: Sun, 23 Jan 2000 20:23:06 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Richard Steenbergen , freebsd-security@FreeBSD.ORG Subject: Re: stream.c References: <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > * Richard Steenbergen [000123 07:53] wrote: > > > > The correct "sorta-fix" is to rate limit the number of dropwithreset's per > > second, else kick them down to straight drop. I believe this has been done > > effectively in http://www.freebsd.org/~alfred/tcp_fix.diff (though I > > question what its aimed to be accomplished with that checksum work :P). > > The idea is to reduce the amount of time spent doing checksums on invalid > packets, why checksum if the destination port isn't open or no such > connection is open? Because you don't have any idea if the TCP header information is valid until you've completed a checksum. > Unfortunatly even after moving the checksum quite far into tcp_input's > path it still seems pretty easy to eat all CPU on a box, in fact I > didn't notice any improvement at all. > > Maybe i'm missing something, those interested can have a try at: > http://www.freebsd.org/~alfred/tcp_fix_untested.diff > > maybe someone can tell me what i'm screwing up. You're fixing the wrong problem. The problem stems from injecting multicast RST packets, which generate multicast replies on all attached interfaces. The real solution seems to be to reject the invalid multicast TCP packets without generating a reply, since they cannot possibly be valid packets. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message