Date: Fri, 21 Jan 2000 16:37:37 -0700 From: Brett Glass <brett@lariat.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Alfred Perlstein <bright@wintelcom.net>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <4.2.2.20000121163454.01a58e30@localhost> In-Reply-To: <200001212315.PAA64608@apollo.backplane.com> References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <4.2.2.20000120222630.01919150@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 04:15 PM 1/21/2000 , Matthew Dillon wrote: > There is nothing wrong with the protocol standard. Just because it > happens to appear to be vulernable to a DOS attack does not make it > 'broken'. RST handling is designed to deal with long network downtime > and host reboot resynchronization cases. Just dropping the RST response will > cause the other end to take a much longer to timeout then it would otherwise. > Dropping RST's in anything but a self-defense situation during a real life > attack is a bad idea. Perhaps one should stop dropping RSTs when it's clear that the number you're sending is greater than the number of connections you've had in a good long while! If that's so, you're clearly under attack. Also, trying to send a RST to an IP multicast address (which you'll do if the incoming bogus ACK had a multicast address as its source address) is something that we should definitely not do. We should definitely disable this in tcp_input.c at the label dropwithreset. Agreed? --Brett 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?4.2.2.20000121163454.01a58e30>