Date: Wed, 13 Dec 2000 13:36:02 -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.0012131325470.13447-100000@achilles.silby.com> In-Reply-To: <Pine.BSF.4.21.0012131408570.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: > I would be extremely careful with those descriptions... When you tell > people directly that something is an attack, even if its not, there are > enough who will jump to immediate conclusions and begin making false > accusations. While it may be highly likely that the reasons for those rate > limits is some kind of attack, it is not guaranteed, and I would be very > reluctant to so blatantly tell people that it is... > > Personally I'd recommend straight forward descriptions like "RST due to no > listening socket". Well, as no IPs are listed, I'm not too concerned about libelous attack accusations resulting from the messages. However, I'm not opposed to changing the messages, as long as the distinction between the cases is clear. Do you have exact replacements for each case along the line of what you're thinking of? (Making it fit into 80 characters is the tough part.) > I also see no compelling reason to put ICMP Timestamp > in a seperate queue, but what I would recommend is seperate queues for > ICMP messages which would be defined as "query/response" and those which > would be called "error" messages. If someone needs more specific > protection they can use dummynet. Well, I should make a clarification here. My use of the word queue is wrong. All the rate limiting does is count packets per second and drop those above the allowed amount. Hence, there's no significant overhead to having counters for each seperate type. The main reason tstamp is distinct from echo is so that they can be reported correctly. Given that they are distinctly different packets, I think this makes sense. (And has less overhead than dummynet would.) 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.0012131325470.13447-100000>