Date: Sun, 23 Jan 2000 20:23:06 -0700 From: Wes Peters <wes@softweyr.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Richard Steenbergen <ras@above.net>, freebsd-security@FreeBSD.ORG Subject: Re: stream.c Message-ID: <388BC59A.1AD012C5@softweyr.com> References: <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > > * Richard Steenbergen <ras@above.net> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?388BC59A.1AD012C5>