Date: Fri, 21 Jan 2000 15:21:25 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Warner Losh <imp@village.org> Cc: Darren Reed <avalon@coombs.anu.edu.au>, brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001212321.PAA64674@apollo.backplane.com> References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:: 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
Yes, you can theoretically drop any packet and still adhere to the protocol,
but at the cost of odd degredation cases occuring on the remote end (such as
the remote end taking a longer amount of time figuring out that you've
rebooted). Therefore it should only be done when absolutely necessary.
The ICMP_BANDLIM code does precisely this: It detects a potential attack
and limits the response to it. The current ICMP_BANDLIM code is limited
to two cases:
(1) ICMP responses
(2) TCP packets sent to bad ports
It would take perhaps ten seconds to extend the mechanism to cover other TCP
RST cases but the above two cases usually handle the vast majority of
these sorts of attacks so if this exploit code is stopped cold by ICMP_BANDLIM,
we're done. If it isn't then we spend a few seconds extending the cases
covered by ICMP_BANDLIM and we are done.
Either way this is not a big deal. Lobotomizing TCP is not necessary.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200001212321.PAA64674>