Down with the mangle table! :-)

[Harald Welte]

On Thu, Jul 12, 2001 at 10:48:22AM +0200, Henrik Nordstrom wrote:
> Jozsef Kadlecsik wrote:
> 
> > It's not a big overhead having a 5-hook mangle table and using it at only
> > *one* hook, but it seems to me ugly. With such a table one could define
> > just the required table with the required granularity. There would be no
> > need to introduce "officially" any new table anymore.
> 
> Note: There are big differences between the different table types (mangle,
> filter, nat), and it is not too unlikely other table types may need to be
> introduced in the future.

Well, there is not too much technical difference between filter and mangle.

The nat table however, is totally different, as it is not directly attached
to the hooks, but some other code in between. And the table is only traversed
at certain points.

> I do see a benefit in optionally being able to control hook priorities for the
> tables, and for things like mangle and filter (but not 'nat') also in being
> able to have it duplicated at different priorities with different rulesets.
> This would nullify both current discussions on priorities: mangle before or
> after conntrack, filter before or after nat.

hm, to one degree it sounds interesting, yes. 

To the other degree, there are several difficulties, though:

1 how do you ever want to document all the different possibilities

2 just a map or priority ranges are _not_ enough for the matches/targets

3 from my point of view, you are giving too much flexibility

Yes, flexibility is nice. But this discussion is more about what kind of
interface on what kind of layer do we want to provide.  On the one hand,
you can give a huge set of extremely flexible, small tools, and leave it
up to the user what to do with them.  This would be a 'low-level' interface,
extremely close to the source code, enabling almost everything.

On the other hand, you can give him a sort-of organized set of tools, prepared
for most common sane configurations.  This would be a high level interface.
Gaining usability by sacrificing some features.

We need to find a compromise between those two.  I'm a hacker, so I'd usually
prefer The low-level interface.  

But whom do we write netfilter/iptables for?  For the linux packet mangling
guru who knows almost everything about the network code, netfilter and
iptables, who has as much knowledge as he would need fro writing new modules?

Or for the usual firewall admin, who wants to have a sort-of easy-to-use
infrastructure for satisfying his needs.

Ideally, of course, we would want to have all the features for the 'guru'
and all the ease-of-use and understandability for the standard network
admin.  We need to approximate to that goal.

And thus, sometimes we need to make decisions in favor of policy/integrity
instead of featuritis.

> > Should therefore the development stop and not to introduce new
> > features? :-)
> 
> I don't think so. Things should be allowed to evolve.

of course.

> > That is the problem :-). All matches/targets would need a map, at which
> > hooks and at which priorities (exactly one priority, below or above a
> > given priority) they could be used.
> 
> I imagine some targets may need a range.. not before X and not after Y.

It's not only about the map.

Please always remember that iptables are _totally_ independent from
netfilter. Nobody is forced to attach chains of tables to hooks. This is 
just how it works for the two particular instances mangle and filter.

As things look like, KLIPS2 (Freeswan next generation) will, for example,
use iptables at a totally different point - to implement and IPsec SPDB.


> Henrik Nordstrom

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)