On 8/17/05, Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > On Wed, Aug 17, 2005 at 03:52:54AM -0500, Kevin wrote: > > Some applications include code to throttle the number of concurrent > > inbound connections from any CIDR block, this is a common request > > for SMTP listeners. > > Sounds like a nice feature. If you volunteer to implement it,
I think I'll just buy Frantzen another nice bottle of scotch and let him do the coding -- It's been a long time since I looked under the hood of pf. > there will probably be some technical questions regarding > "from any CIDR block". For instance, you might implement something like > > pass ... keep state (max-src-states 20 combine /24) > which partitions the entire address space into non-overlapping /24 > blocks (so any possible address falls within exactly one of those > blocks), and enforces a maximum of 20 states for each such block. Rather than "combine", I'd use suggest making this an option to source-track, e.g. "source-track mask /24", and implement the feature by the expedient hack of using the mask with AND to zero out the bits beyond the mask before updating or checking state counters. So setting "source-track mask /24" globally or one any individual state rule would accomplish what the OP requested. > A broader interpretation of "any /24 block" would involve overlapping > blocks, and some sliding window algorithms, which can easily become > expensive. > > I.e. if you had > > -----|---------|---------|---------|----- > 10.1.1/24 10.1.2/24 10.1.3/24 > 15 10 > |---------| > > with 15 states from the "right" side of 10.1.1/24 (say, from source > 10.1.1.253) and 10 states from the "left" side of 10.1.2/24 (say, from > source 10.1.2.2), would that be a violation, because all these 15+10=25 > addresses are within one block of the size of a /24? I agree. We need to creatively interpret the users request to mean CIDR blocks so the specifications become a trivial set of diffs instead of a grad student's entire summer project. So where I said "all arbitrary /24 blocks", substitute the more technically accurate phrase "all network prefixes". Some users, such as in your example above, might choose to use a /22 mask so they can aggregate 10.1.0.0 - 10.1.3.255 with a single set source-track counters. Kevin Kadow
