From owner-freebsd-security Thu Jan 20 22:43:16 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 98DA514D46 for ; Thu, 20 Jan 2000 22:42:53 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA82475; Thu, 20 Jan 2000 23:42:50 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA09108; Thu, 20 Jan 2000 23:42:49 -0700 (MST) Message-Id: <200001210642.XAA09108@harmony.village.org> To: Darren Reed Subject: Re: stream.c worst-case kernel paths Cc: brett@lariat.org (Brett Glass), security@FreeBSD.ORG In-reply-to: Your message of "Fri, 21 Jan 2000 15:17:34 +1100." <200001210417.PAA24853@cairo.anu.edu.au> References: <200001210417.PAA24853@cairo.anu.edu.au> Date: Thu, 20 Jan 2000 23:42:49 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001210417.PAA24853@cairo.anu.edu.au> Darren Reed writes: : > Normally, we'll wind up at the label "dropwithreset", which means we'll : > send back a RST. This suggests that restricting RSTs will help with the : > DoS. (Does anyone know if not sending an RST violates any RFCs if there : > was never a connection?) : : Yes. RFC 793, figure 11, page 35, describes the prescribed behaviour. You are allowed to drop the RST in high load situations, are you not? The remote end must be robust enough to deal with that and retransmit. A simpleminded solution would be to randomly drop RSTs when under attack, since that would statitically result in bad conncetions being disconnected in a reasonable amount of time, but still save resources... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message