From owner-freebsd-security  Fri Jan 21 15:21:30 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 64ED51563F
	for <security@FreeBSD.ORG>; Fri, 21 Jan 2000 15:21:28 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id PAA64674;
	Fri, 21 Jan 2000 15:21:25 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 21 Jan 2000 15:21:25 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200001212321.PAA64674@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 
References: <200001210417.PAA24853@cairo.anu.edu.au>   <200001210642.XAA09108@harmony.village.org>
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

:: 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