OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
FreeBSD Security Archives: Re: stream.c worst-case kernel paths

Re: stream.c worst-case kernel paths

Subject: Re: stream.c worst-case kernel paths
From: Brett Glass (brettlariat.org)
Date: Fri Jan 21 2000 - 09:23:18 CST

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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

This archive was generated by hypermail 2b27 : Fri Jan 21 2000 - 09:24:50 CST