In some email I received from ryan beasley, sie wrote: > > ipf4.0 will allow per-rule limits on the number of state sessions a > > rule may be responsible for. > > > > does that solve the problem well enough ? > > I think that's a step in the right direction, but I'm not entirely sure > it's a complete solution.
if you divide up the maximum space why not ? [...] > For a single service, we could set an artificial limit on that rule to > maybe 4000 state entries. The states-per-rule feature could work here, > but it doesn't scale too well. Rather than having a pool of state > entries that's spread across every service as they're needed, each > service is now limited to at most (IPSTATE_MAX / <amount of services>) - 1 > entries to leave room for management connections. I think that sort of change would be too intrusive to existing installations. > We know that resource exhaustion is always going to be a problem. If > you can't bump the state table size because you're running out of > physical memory, it's either time to buy more or transition to more / > larger machines. [...] > In addition to the state table limit defined by IPSTATE_MAX, rig up > an artificial limit that's IPSTATE_MAX - <x> entries large. (This is > similar to operating systems that reserve <x> processes for > exclusive use by the superuser.) When this artificial limit is hit, > then only special connections can consume the rest of table space. > > Example conditions include matching an "auth" rule, or matching a > rule with a yet-to-be-defined identifier (like priv? ;). ) > > e.g., pass in quick proto tcp from <bastion> to <tgt> port = 22 > flags S keep state priv Well, I don't particularly like the idea of not being able to use the entire state space because you don't have some special keywords. This does make me think of a couple of other ideas: - allow overcommitting by ipfilter, such that if you have a per-rule limit on state sessions, you can always have that many even if IPSTATE_MAX is smaller - use a keyword similar to "priv" to say state added because of this rule is always allowed (and/or only with a limit in the rule.) I'm inclined to go for the former idea (allow overcommitting) because it has some amount of sense/least surprise to it. Darren
