Date: Fri, 21 Jan 2000 00:30:45 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Brett Glass <brett@lariat.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121003045.H14030@fw.wintelcom.net> In-Reply-To: <4.2.2.20000120222630.01919150@localhost>; from brett@lariat.org on Thu, Jan 20, 2000 at 10:30:37PM -0700 References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <200001210521.VAA56412@apollo.backplane.com> <4.2.2.20000120222630.01919150@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
* Brett Glass <brett@lariat.org> [000120 21:54] wrote: > 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. There's no reason to break the protocol when a simple bandwidth limiting solution will suffice: "Ok, i'll follow the spec as long as it looks like i'm not under attack." seems more reasonable than totally breaking the spec for normal day to day operation. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] 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?20000121003045.H14030>