From owner-freebsd-security Fri Jan 21 15:39:40 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id CB2CF15718 for ; Fri, 21 Jan 2000 15:39:26 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id QAA25724; Fri, 21 Jan 2000 16:39:16 -0700 (MST) Message-Id: <4.2.2.20000121163454.01a58e30@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 16:37:37 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Alfred Perlstein , security@FreeBSD.ORG 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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