> I don't think adding such a mechanism to the rule set improves > performance, quite the opposite. A single pointer comparison (for an > empty tree of embryonic states) is about as cheap as it gets. Look at
Here's that infernal "Single pointer comparison" again. You mean, if someone isn't using embryonic states (ie - embryonic list is null) there is a single pointer comparison. I'll buy that. Then again, if the feature is useful for proxies, it will probably eventually find its way into ftp-proxy, and there will be very few empty embryonic state tables out there. But again, I hate arguing against something based on "performance" data that is hypothetical. Thus, I'll reserve judgement. > The point of an embryonic state inserted by a proxy is that it's an > exception from the static filter policy. If you could allow these > connections using a static rule set, there would be no need for > embryonic states. If you can't, you also have troubles expressing, > statically, _what_ embryonic states to allow. A proxy making use of such > a feature would require access to /dev/pf and it would have to be written > as carefully as authpf, for instance. Actually, now that I try to construct something, it is quite hard to get the block rules correct without some idea like templating. Consider a passive FTP Server protected by a pf firewall: The ephemeral rule is: pass in on $evil_if proto tcp from any port * to $ftp_server port $pasvport uid proxy keep state ephemeral How much can we lock down a rule like this, to limit the damage the proxy can cause? Ideally, we'd want to restrict things so that the source port must be ephemeral, and so that the list of ports acceptible for the $pasvport choice are limited to a fixed range. If the ftp server was on the firewall box, we'd also want to limit things so that only sockets owned by user proxy could be connected to. I can't see a way, short of templating. Now, having argued myself into a complete circle, I'm going to just sit down and shut up for a bit. -kj
