Date: Wed, 13 Dec 2000 16:09:50 -0500 (EST) From: "Richard A. Steenbergen" <ras@e-gerbil.net> To: Mike Silbersack <silby@silby.com> Cc: Bosko Milekic <bmilekic@technokratis.com>, freebsd-net@freebsd.org, green@freebsd.org Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) Message-ID: <Pine.BSF.4.21.0012131544450.816-100000@overlord.e-gerbil.net> In-Reply-To: <Pine.BSF.4.21.0012131431570.13447-100000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ras@e-gerbil.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0012131544450.816-100000>