From owner-freebsd-security Fri Jan 21 15:15: 9 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 712161563F for ; Fri, 21 Jan 2000 15:15:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA64608; Fri, 21 Jan 2000 15:15:05 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 15:15:05 -0800 (PST) From: Matthew Dillon Message-Id: <200001212315.PAA64608@apollo.backplane.com> To: Brett Glass Cc: Alfred Perlstein , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <4.2.2.20000120222630.01919150@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :At 10:21 PM 1/20/2000 , Matthew Dillon wrote: : :> I think it's a bad idea to make anything that breaks the protocol :> standard the default. : :I see your point. But isn't it really the protocol standard that's :broken? It might be worthwhile to set a de facto standard as part :of the process of moving for change in the formal one. (Extensions and :changes to IETF standards frequently happen this way.) If people at :the IETF meetings say, "FreeBSD now handles this situation this way, and :it's MUCH more robust," it'll be a strong selling point in favor of :a follow-on RFC. This has worked for e-mail standards, which Heaven :knows are STILL in need of enhancement. : :--Brett Glass 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message