From owner-freebsd-security Fri Jan 21 18:45:21 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 68A6E150B2 for ; Fri, 21 Jan 2000 18:45:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA66403; Fri, 21 Jan 2000 18:45:07 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 18:45:07 -0800 (PST) From: Matthew Dillon Message-Id: <200001220245.SAA66403@apollo.backplane.com> To: Dag-Erling Smorgrav Cc: Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message