From owner-freebsd-security Fri Jan 21 13:51:15 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 1BF521553D for ; Fri, 21 Jan 2000 13:51:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA63804; Fri, 21 Jan 2000 13:51:07 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 13:51:07 -0800 (PST) From: Matthew Dillon Message-Id: <200001212151.NAA63804@apollo.backplane.com> To: Gene Harris Cc: Brett Glass , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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