Date: Fri, 21 Jan 2000 18:45:07 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Keith Stevenson <k.stevenson@louisville.edu>, freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <200001220245.SAA66403@apollo.backplane.com> References: <4.2.2.20000120194543.019a8d50@localhost> <Pine.BSF.4.10.10001211419010.3943-100000@tetron02.tetronsoftware.com> <20000121162757.A7080@osaka.louisville.edu> <xzpk8l2lul4.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
:That's because the ICML_BANDLIM code comes *before* the
:TCP_RESTRICT_RST code, and costs more to run. A kernel with
:TCP_RESTRICT_RST but no ICMP_BANDLIM will fare better than a kernel
:with ICMP_BANDLIM.
:
:DES
:--
:Dag-Erling Smorgrav - des@flood.ping.uio.no
I'm sorry, but this is just plain wrong. First you are counting a
few extra instructions and coming to the conclusion that, somehow,
this magically makes TCP_RESTRICT_RST a better option because its
'faster'. Oh please, give me a break. Nobody is going to notice
a few extra instructions per packet. Faster does not mean better.
Second, you purport that TCP_RESTRICT_RST is a better solution.
I'll tell you something about TCP_RESTRICT_RST: It's garbage. It should
never have been committed into the tree. It takes out *EVERY* single
goddamn RST response in the entire TCP input chain, even the ones that
couldn't possibly be related to an attack. It does it *all the time*,
whether the machine is under attack or not. It is not something I
would ever, *EVER* turn on in any kernel I ever construct, and it is not
something any sysadmin with any brains should use. It lobotomizes
an important part of the TCP protocol for no good reason.... it's
someone's quick fix to a problem that already had a better solution
if they had bothered to read the code more carefully.
ICMP_BANDLIM is a much, much better solution and applying it to the
relatively few TCP RST cases that can become a bandwidth problem due to
an attack is trivial. The extra couple of instructions - there to prevent
it from tearing up the protocol spec - cost us nothing. Zilch. Nil.
Nada. TCP_RESTRICT_RST gleefully screws with the protocol spec,
ICMP_BANDLIM picks its fights more carefully and can trivially be
extended to cover the relatively few additional TCP RST cases that
might conceivably cause a problem.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200001220245.SAA66403>