Re: new ABI

[Massimiliano Hofer <max@nucleus.it>]

On Thursday 24 August 2006 12:15 pm, Jozsef Kadlecsik wrote:

> I think the current system is pushed to its limits and it is time for
> radical changes. Non-radical change proposals can of course explore the
> current problems and point to directions toward the proper solutions, so
> such efforts are not wasted.

I've been thinking of a few things we can do in an incremental way, but the 
reality is that the most important features require a drastically different 
interaction with userspace and one of the primary goals is to reduce the 
number of user space visible changes. This does not apply to development 
versions of course. There are lots of small incremental steps we can do 
in "developer mode".

> > > > + Allow grouping of rules in some way. Really large firewall needs
> > > > this.
> > >
> > > Sub-tables can probably help. It seems to me non-trivial how not to
> > > loose efficiency, though. Multiple toplevel tables (i.e active/passive,
> > > active/backup) should also be considered.
> >
> > Is this the same thing I'm calling expression chains? We could have an
> > expression table with user defined chains that system chains can use.
> > I don't think it would be inefficient. Just jump to a chain and see what
> > it returns. If we want to optimize it we could cache results so that
> > people can use sub-chains several times (in different combinations)
> > withou worrying about it.
>
> Could you show an example?

iptables -t macro -N trustedclient
iptables -t macro -A trustedclient ... -j TRUE
...
iptables -t macro -A trustedclient ... -j FALSE

iptables -t macro -N trustedserver
...


iptables -I FORWARD --macro trustedclient --macro trustedserver -j ACCEPT


Of course, the real usefulness comes when you use multiple combinations.
Another user could be to have a single macro in FORWARD and in nat 
POSTROUTING. This poses the problem of what matches to allow in macro chains. 
The maximum common set? Ignore non applicable ones? Separate macros for every 
context?

We could cache the result of a macro the first time we run into it (for a 
single packet) and avoid traversing the chain when we reuse it.

I have lots of firewalls where I use a script to generate combinations of 
rules. This feature would simplify all of them.

> Sub-tables as I name are complete tables of the given type (filter,
> mangle, etc):
>
> # Define new, empty filter type of table foo:
> -t filter --new-table foo
> # Fill it up with rules, define default policies, etc
> -t foo -A ...
> ...
>
> # Then you could chain filter type of tables one after another
> # using the default as an always existing one:
> -t filter --prepend-table foo
> -t filter --append-table bar
> # Now we'd have foo, default, bar as filter tables to be evaluated

Similar goal, different style.
Why not just:
-t filter --evaluate-table foo

This way you could mix it with other rules and allow for more flexible mixing 
of more than 2 sub-tables.
Would you forbid {prepend|append|evalute}-table in sub-tables in order to 
avoid infinite recursion or would you check for cyclicity at load time or run 
time?

> > What level of runtime synchronization do you need? We have to allow some
> > delay between 2 firewalls.
>
> It depends on the active-active setup and the modules in question. If the
> TCP/UDP/etc. streams can pass any of the firewalls then strong
> syncronization is required. If the streams always pass the same firewall
> in both directions (except after failover), then loose syncronization
> can be enough. recent/set modules probably always require strong sync.

This is feasible only with ip_conntrack_tcp_be_liberal. I don't think you will 
ever keep a completerly up to date mirror state down to the last sequence 
number unless you use some special and really fast means of communication.
Synchronous remote communication in the middle of packet processing is out of 
the question.
Do you have a something specific in your mind?
If you settle for loose synchronization we can certainly have a way to send 
kernel generated change events to userspace and then you could send them to 
the other members of the cluster.

> > If we implement generic module data tables (with event notification to
> > userspace), this wouldn't be a kernel problem anymore.
>
> Yes, we just need such an infrastructure to back the module writers.

This is one of the few things we could add without breaking backward 
compatibility.

-- 
Saluti,
   Massimiliano Hofer
        Nucleus