Date: Fri, 21 Jan 2000 13:51:07 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Gene Harris <zeus@tetronsoftware.com> Cc: Brett Glass <brett@lariat.org>, freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <200001212151.NAA63804@apollo.backplane.com> References: <Pine.BSF.4.10.10001211534020.4003-100000@tetron02.tetronsoftware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
When I was working on ICMP_BANDLIM I ran a number of tests on Best's
machines. I found that the machines could handle a high incoming packet
rate just fine, and that the problems tended to occur when the machines
tried to respond to the packets. Hence ICMP_BANDLIM focuses on limiting
the error-packet response rate.
I do not think optimizing the input path will gain you any significant
improvement for the risk involved (the input path works, changing it
might break it). Instead I would concentrate on ensuring that the machine
does not overly-respond to these sorts of attacks. The very last thing I
would worry about is whether we do an extra hash table lookup or run the
packet checksum early or late!
What I would recommend is that the ICMP_BANDLIM mechanism simply be
extended to include the sending of TCP RST packets in certain cases.
I strongly disagree with anything that will break the TCP protocol...
for example, I think using the TCP_RESTRICT_RST option (or even having
it in the kernel in first place) is a *bad* idea.
-Matt
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?200001212151.NAA63804>