Date: Thu, 20 Jan 2000 23:42:49 -0700 From: Warner Losh <imp@village.org> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001210642.XAA09108@harmony.village.org> In-Reply-To: Your message of "Fri, 21 Jan 2000 15:17:34 %2B1100." <200001210417.PAA24853@cairo.anu.edu.au> References: <200001210417.PAA24853@cairo.anu.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001210642.XAA09108>