From owner-freebsd-net Wed Dec 13 13:10:26 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 13:10:23 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 5EECF37B698; Wed, 13 Dec 2000 13:10:20 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id 11581E4F4D; Wed, 13 Dec 2000 16:09:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by overlord.e-gerbil.net (Postfix) with ESMTP id D1F24E4F4C; Wed, 13 Dec 2000 16:09:50 -0500 (EST) Date: Wed, 13 Dec 2000 16:09:50 -0500 (EST) From: "Richard A. Steenbergen" To: Mike Silbersack Cc: Bosko Milekic , freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Dec 2000, Mike Silbersack wrote: > On Wed, 13 Dec 2000, Richard A. Steenbergen wrote: > > > > Hm, true. I was thinking of limiting the outgoing side, which would mean > > > ipfw comes later in the string, but I suppose that if you limit on the > > > incoming ipfw's sooner. > > > > Historically bandlim has been the process of stopping the processing at > > input of things which would result in output... Do you want to (or need > > to) extend this? > > Since this code actually has to read the incoming packets before decidied > to not send the outgoing reply, I consider it to be dropping the > outgoing. However, since there's no useful info in a icmp request, > reading isn't really anything... We appear to be caught in a semantical > argument, I'm not proposing anything new. There is a difference though, if you're stopping excessive requests at input, or stopping the replies from hitting the network after bothing to process them, which is what I ment about using ipfw at input. Right now it has to be classified as dropping on incoming, with the qualifier that we're dropping at incoming things which would result in further processing and an outgoing reply. Entirely semantics but still. > > Same question as above, is this to be built in Denail of Service > > prevention, or is this limiting of packets which could potentially > > generate excessive processing or replies? Might as well do it right > > instead of kludging this up any more... :P > > It just limits the bandwidth of mostly useless packets. What constitutes > a "DoS" is beyond the scope of this message, and we're starting to > nitpick. I'll roll an updated patch with less casual messages so we can > get it committed soon. Well my point is, if you're compiling BANDLIM into your kernel and end up getting messages on possible port scans, this is backwards. If you really want to make a DoS analysis and prevention system, I think it should be seperate from this. -- Richard A Steenbergen http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message