Date: Wed, 13 Dec 2000 14:40:54 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: "Richard A. Steenbergen" <ras@e-gerbil.net> 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.0012131431570.13447-100000@achilles.silby.com> In-Reply-To: <Pine.BSF.4.21.0012131512230.816-100000@overlord.e-gerbil.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. Mike "Silby" Silbersack 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.0012131431570.13447-100000>