[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fully transparent ftp-proxy?



On Thu, 31 Oct 2002, Henning Brauer wrote:
> On Thu, Oct 31, 2002 at 01:03:23PM +1000, Rukh wrote:
> > Actually, there wouldn't be any real performance penalty, because these
> > embrionic states are in effect only a tree sorted list of one shot rules.
>
> oh yes, and the lookup is absolutely for free, sure.
of course not
> > And if you don't like using embrionic states, then you would have an empty
> > embrionic state tree and it would then only require one extra pointer
> > comparison (and seeing that it's NULL), before moving on to evaluating the
> > rule set.
>
> yes. extra cost. a little extra cost here, a little extra cost there,
> summarized is more than just a little extra cost.
>
first let me get some stuff clear in my head.
an embryo state is required where we have almost all the information
required for a state entry as determined by a userland proxy such as
ftp-proxy or tircproxy (ftp and irc seem to be the only offenders i can
think of). the most common bit of missing information being the remote
hosts src port (this info could make code simpler). the fact that pf in
its current state doesnt seem to address this problem well has led to this
discussion.
tne current idea seems to be having an embryo tree (like the state
tree but with wildcards for certain fields) in between the state
tree and the rule list. henning has correctly stated that
this would give a performance hit.
rukh has suggested that instead of having an embryo tree in between the
states and the rules, you have a rule that lets pf traverse the tree.
therefore, users that dont need it dont get affected by it.
rather than having an "embryo" flag on a rule tho, id make it its own
directive and have it before the normal filter rules, therefore evaluated
before the normal rules. state is checked before rules. since embryo
states are almost states, it makes sense to me that they get checked
before the rules as well.
having such a rule (or rules) has several other advantages, you could
create several trees, one for each proxy that requires it (include a
mechanism for the proxy to talk to its own tree). you could specify which
field of the state entry is variable (id still say that remote src port
would be th only one, but its nice to be flexible). you could specify tcp
flags and state modulation. whatever is needed for connections created by
the proxy.
im sorry if i havent explained well. fatigue is not a friend when you're
trying to be smart. or creative. which is why im going to stop typing now.
thanks,
David Gwynne.