From owner-freebsd-security Fri Jan 21 7:23:35 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 1E54B14D42 for ; Fri, 21 Jan 2000 07:23:29 -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 IAA19420; Fri, 21 Jan 2000 08:23:21 -0700 (MST) Message-Id: <4.2.2.20000121081444.01a2d480@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 08:23:18 -0700 To: Alfred Perlstein From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Matthew Dillon , security@FreeBSD.ORG In-Reply-To: <20000121003045.H14030@fw.wintelcom.net> References: <4.2.2.20000120222630.01919150@localhost> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:30 AM 1/21/2000 , Alfred Perlstein wrote: >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. Good point. But when you think about it, maybe we are learning a lesson here that at least should influence the future design of protocols. Think about it: What's the reason for that RST? It's a warning to the sender that he or she has done something wrong. This can be a good thing. But if the system takes it upon itself, always, to warn ANYONE who does anything weird, it can tie itself in knots. This appears to be what's happening here. So, we've learned something about what policy to follow. The current TCP/IP spec is an important standard, but it's not Holy Writ. There are still things we can learn, and we can fix both the current spec and future ones. Whether we implement changes immediately or not is really a matter of pragmatism. My priority is to keep my systems up and safe from attack, so I have no qualms about doing that so long as it won't break normal operation. I'd put in a "stick to the original spec" option for those who were willing to risk safety for conformance to Holy Writ. YMMV, of course. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message