dangerous? Setting mark in nat table

dangerous? Setting mark in nat table

[Amin Azez]

I want need to set a mark (-j MARK) in the nat table based on dnat'ing done.

This means changing the ipt_mark kernel module, at least for my own
consumption.

Are there any overpowering reasons why I should not do this, or even why
it should not be done at all?

I have powerful reasons which finally centre on the fact that the mark
is too small to use as as means of joining condition fragments spread
over different places.

(Is this also a good time to bring up why mangle and filter should not
be merged?)

Sam

Re: dangerous? Setting mark in nat table

[Jan Engelhardt]

On Mar 13 2007 15:25, Amin Azez wrote:
>
>I want need to set a mark (-j MARK) in the nat table based on dnat'ing done.
>
>This means changing the ipt_mark kernel module, at least for my own
>consumption.
>
>Are there any overpowering reasons why I should not do this, or even why
>it should not be done at all?

It is valid from a programming point of view (the @skb is always writable
a.k.a. it is not in a rodata section protected by hardware, which is why
it can also be modified from within matches which have const struct
sk_buff *skb), but it is perhaps some sort of layering violation (MARK is
for mangle only). I recognize that it would be cheapest to MARK packets
_after_ the whole lot of bad packets has been dropped in filter, rather
than having to mark them first in mangle and then just filter it out
again.

>I have powerful reasons which finally centre on the fact that the mark
>is too small to use as as means of joining condition fragments spread
>over different places.
>
>(Is this also a good time to bring up why mangle and filter should not
>be merged?)

nat only gets the first packet of a connection. You could perhaps do the
same with -t mangle -A ... -m conntrack --ctstate NEW -j MARK.


Jan
-- 

Re: dangerous? Setting mark in nat table

[Amin Azez]

* Jan Engelhardt wrote, On 13/03/07 15:36:
> On Mar 13 2007 15:25, Amin Azez wrote:
>> I want need to set a mark (-j MARK) in the nat table based on dnat'ing done.
>>
>> This means changing the ipt_mark kernel module, at least for my own
>> consumption.
>>
>> Are there any overpowering reasons why I should not do this, or even why
>> it should not be done at all?
> 
> It is valid from a programming point of view (the @skb is always writable
> a.k.a. it is not in a rodata section protected by hardware, which is why
> it can also be modified from within matches which have const struct
> sk_buff *skb), but it is perhaps some sort of layering violation (MARK is
> for mangle only). I recognize that it would be cheapest to MARK packets
> _after_ the whole lot of bad packets has been dropped in filter, rather
> than having to mark them first in mangle and then just filter it out
> again.


Heh, I spoke to soon.
1. x_tables.c already supports a null table name meaning no-restriction
(although this may be historic rather than planned) so I could just
remove the table name from xt_MARK
2. CONNMARK (as I used it) doesn't set a table restriction anyway,
so..... I'll just use CONNMARK for now.

Sam

Re: dangerous? Setting mark in nat table

[Jan Engelhardt]

On Mar 13 2007 16:12, Amin Azez wrote:
>* Jan Engelhardt wrote, On 13/03/07 15:36:
>> On Mar 13 2007 15:25, Amin Azez wrote:
>>> I want need to set a mark (-j MARK) in the nat table based on dnat'ing done.
>>>
>>> This means changing the ipt_mark kernel module, at least for my own
>>> consumption.
>>>
>>> Are there any overpowering reasons why I should not do this, or even why
>>> it should not be done at all?
>> 
>> It is valid from a programming point of view (the @skb is always writable
>> a.k.a. it is not in a rodata section protected by hardware, which is why
>> it can also be modified from within matches which have const struct
>> sk_buff *skb), but it is perhaps some sort of layering violation (MARK is
>> for mangle only). I recognize that it would be cheapest to MARK packets
>> _after_ the whole lot of bad packets has been dropped in filter, rather
>> than having to mark them first in mangle and then just filter it out
>> again.
>
>Heh, I spoke to soon.
>1. x_tables.c already supports a null table name meaning no-restriction
>(although this may be historic rather than planned) so I could just
>remove the table name from xt_MARK
>2. CONNMARK (as I used it) doesn't set a table restriction anyway,
>so..... I'll just use CONNMARK for now.

http://lkml.org/lkml/2006/8/22/26

CONNMARK does in filter, MARK does not - I do not know what is
supposed to be going on.


Jan
-- 

Re: dangerous? Setting mark in nat table

[Henrik Nordstrom]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

tis 2007-03-13 klockan 15:25 +0000 skrev Amin Azez:
> I want need to set a mark (-j MARK) in the nat table based on dnat'ing done.

Note: This mark will only apply to the first packet of the connection,
the rest bypasses the nat table as the NAT mappings have already been
set up.

> (Is this also a good time to bring up why mangle and filter should not
> be merged?)

mangle reroutes packets on certain changes such as mark. filter does
not..

Regards
Henrik

[-- Attachment #2: Detta är en digitalt signerad meddelandedel --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: dangerous? Setting mark in nat table

[Henrik Nordstrom]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

tis 2007-03-13 klockan 17:18 +0100 skrev Jan Engelhardt:

> http://lkml.org/lkml/2006/8/22/26
> 
> CONNMARK does in filter, MARK does not - I do not know what is
> supposed to be going on.

It's due to the relation of the per-packet nfmark being as a channel to
return routing information from netfilter to the kernel. The
per-connection conntrack mark used by CONNMARK does not have this
property and does not need to be restricted in where it's modified.

The restore operation of CONNMARK have the same restrictions as MARK as
it too modifies the packet nfmark, and can therefore only be used from
mangle just as MARK.

Regards
Henrik
Author of CONNMARK

[-- Attachment #2: Detta är en digitalt signerad meddelandedel --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: dangerous? Setting mark in nat table

[Patrick McHardy]

Henrik Nordstrom wrote:
> It's due to the relation of the per-packet nfmark being as a channel to
> return routing information from netfilter to the kernel.

Thats true, routing by nfmark in the OUTPUT chain needs the rerouting
done by the mangle table, but nowadays there are other uses for nfmark,
so if someone feels motivated to send a patch to get rid of this pretty
arbitary restriction I think I would take it.

Re: dangerous? Setting mark in nat table

[Amin Azez]

* Henrik Nordstrom wrote, On 14/03/07 10:35:
> tis 2007-03-13 klockan 17:18 +0100 skrev Jan Engelhardt:
>
>   
>> http://lkml.org/lkml/2006/8/22/26
>>
>> CONNMARK does in filter, MARK does not - I do not know what is
>> supposed to be going on.
>>     
>
> It's due to the relation of the per-packet nfmark being as a channel to
> return routing information from netfilter to the kernel. 
Thats exactly how I'm trying to use it, which is why I need to set it in
the nat table.

(I know that nat only applies to the first packet in a flow, I also use
CONNMARK later to save the mark combined with other data.)

> The
> per-connection conntrack mark used by CONNMARK does not have this
> property and does not need to be restricted in where it's modified.
>
> The restore operation of CONNMARK have the same restrictions as MARK as
> it too modifies the packet nfmark, and can therefore only be used from
> mangle just as MARK.
>   
Now this at least makes a little sense.

Sam

Re: dangerous? Setting mark in nat table

[Henrik Nordstrom]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

ons 2007-03-14 klockan 12:02 +0100 skrev Patrick McHardy:

> Thats true, routing by nfmark in the OUTPUT chain needs the rerouting
> done by the mangle table, but nowadays there are other uses for nfmark,
> so if someone feels motivated to send a patch to get rid of this pretty
> arbitary restriction I think I would take it.

If you do, please remove the same restriction from CONNMARK restore

Regards
Henrik

[-- Attachment #2: Detta är en digitalt signerad meddelandedel --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

[PATCH 1/1] Re: dangerous? Setting mark in nat table

[Amin Azez]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

* Henrik Nordstrom wrote, On 14/03/07 12:43:
> ons 2007-03-14 klockan 12:02 +0100 skrev Patrick McHardy:
>
>   
>> Thats true, routing by nfmark in the OUTPUT chain needs the rerouting
>> done by the mangle table, but nowadays there are other uses for nfmark,
>> so if someone feels motivated to send a patch to get rid of this pretty
>> arbitary restriction I think I would take it.
>>     
>
> If you do, please remove the same restriction from CONNMARK restore
>   
Let it at least be said that some of my patches are used :-)

(Henrick, are you interested in my per-flow patch for connmark, so that
each side of the flow can have a seperate mark? Also dumped thus out of
/proc/net/ip-conntrack and libnfnetlink)

Signed-off-by: Sam Liddicott <azez@ufomechanic.net>

Sam



[-- Attachment #2: mark-mangle.patch --]
[-- Type: text/x-patch, Size: 2052 bytes --]

Index: linux-2.6.17.1/net/netfilter/xt_CONNMARK.c
===================================================================
--- linux-2.6.17.1.orig/net/netfilter/xt_CONNMARK.c
+++ linux-2.6.17.1/net/netfilter/xt_CONNMARK.c
@@ -133,13 +133,6 @@ checkentry(const char *tablename,
 {
        struct xt_connmark_target_info *matchinfo = targinfo;
 
-       if (matchinfo->mode == XT_CONNMARK_RESTORE) {
-           if (strcmp(tablename, "mangle") != 0) {
-                   printk(KERN_WARNING "CONNMARK: restore can only be called from \"mangle\" table, not \"%s\"\n", tablename);
-                   return 0;
-           }
-       }
-
        if (matchinfo->mark > 0xffffffff || matchinfo->mask > 0xffffffff) {
                printk(KERN_WARNING "CONNMARK: Only supports 32bit mark\n");
                return 0;
Index: linux-2.6.17.1/net/netfilter/xt_MARK.c
===================================================================
--- linux-2.6.17.1.orig/net/netfilter/xt_MARK.c
+++ linux-2.6.17.1/net/netfilter/xt_MARK.c
@@ -116,7 +116,6 @@ static struct xt_target ipt_mark_reg_v0 
        .name           = "MARK",
        .target         = target_v0,
        .targetsize     = sizeof(struct xt_mark_target_info),
-       .table          = "mangle",
        .checkentry     = checkentry_v0,
        .me             = THIS_MODULE,
        .family         = AF_INET,
@@ -127,7 +126,6 @@ static struct xt_target ipt_mark_reg_v1 
        .name           = "MARK",
        .target         = target_v1,
        .targetsize     = sizeof(struct xt_mark_target_info_v1),
-       .table          = "mangle",
        .checkentry     = checkentry_v1,
        .me             = THIS_MODULE,
        .family         = AF_INET,
@@ -138,7 +136,6 @@ static struct xt_target ip6t_mark_reg_v0
        .name           = "MARK",
        .target         = target_v0,
        .targetsize     = sizeof(struct xt_mark_target_info),
-       .table          = "mangle",
        .checkentry     = checkentry_v0,
        .me             = THIS_MODULE,
        .family         = AF_INET6,

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Patrick McHardy]

Amin Azez wrote:
> Signed-off-by: Sam Liddicott <azez@ufomechanic.net>
> ------------------------------------------------------------------------
> 
> Index: linux-2.6.17.1/net/netfilter/xt_CONNMARK.c
> Index: linux-2.6.17.1/net/netfilter/xt_MARK.c

There are quite a few more that are restricted to mangle without
good reason:

net/netfilter/xt_CLASSIFY.c:            .table          = "mangle",
net/netfilter/xt_CONNSECMARK.c:         .table          = "mangle",
net/netfilter/xt_DSCP.c:                .table          = "mangle",
net/netfilter/xt_MARK.c:                .table          = "mangle",
net/netfilter/xt_SECMARK.c:             .table          = "mangle",
net/ipv4/netfilter/ipt_ECN.c:   .table          = "mangle",
net/ipv4/netfilter/ipt_TOS.c:   .table          = "mangle",
net/ipv4/netfilter/ipt_TTL.c:   .table          = "mangle",
net/ipv6/netfilter/ip6t_HL.c:   .table          = "mangle",

If we're going to remove this, I think we should do it for all of them.
The manpages also need to be updated.

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Henrik Nordstrom]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

ons 2007-03-14 klockan 12:52 +0000 skrev Amin Azez:

> Henrick, are you interested in my per-flow patch for connmark, so that
> each side of the flow can have a seperate mark? Also dumped thus out of
> /proc/net/ip-conntrack and libnfnetlink

I am not objecting it, just not sure it will be used that much
warranting yet another 32-bit conntrack field.

I said earlier that it probably makes more sense to add shift to the
save/restore operations, allowing it to be split in multiple marks while
keeping sanity (possible today, but the marks in one direction will be a
bit odd, scaled up).. For most uses you described earlier 16 bit marks
should be sufficient.

Adding some kind of generic framework for conntrack extension values
would also make sense, allowing modules to associate new values with a
conntrack entry when needed without having to redefine the conntrack
entry for each such module.

Regards
Henrik

[-- Attachment #2: Detta är en digitalt signerad meddelandedel --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Jozsef Kadlecsik]

Hi,

On Wed, 14 Mar 2007, Patrick McHardy wrote:

> Amin Azez wrote:
>> Signed-off-by: Sam Liddicott <azez@ufomechanic.net>
>> ------------------------------------------------------------------------
>>
>> Index: linux-2.6.17.1/net/netfilter/xt_CONNMARK.c
>> Index: linux-2.6.17.1/net/netfilter/xt_MARK.c
>
> There are quite a few more that are restricted to mangle without
> good reason:
>
> net/netfilter/xt_CLASSIFY.c:            .table          = "mangle",
> net/netfilter/xt_CONNSECMARK.c:         .table          = "mangle",
> net/netfilter/xt_DSCP.c:                .table          = "mangle",
> net/netfilter/xt_MARK.c:                .table          = "mangle",
> net/netfilter/xt_SECMARK.c:             .table          = "mangle",
> net/ipv4/netfilter/ipt_ECN.c:   .table          = "mangle",
> net/ipv4/netfilter/ipt_TOS.c:   .table          = "mangle",
> net/ipv4/netfilter/ipt_TTL.c:   .table          = "mangle",
> net/ipv6/netfilter/ip6t_HL.c:   .table          = "mangle",
>
> If we're going to remove this, I think we should do it for all of them.

Sorry, but I disagree. The DSCP, ECN, TOS, TTL, HL targets modify the 
packet itself and thus all belong to the mangle table alone.

> The manpages also need to be updated.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
           H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Jozsef Kadlecsik]

On Wed, 14 Mar 2007, Jozsef Kadlecsik wrote:

>> net/netfilter/xt_CLASSIFY.c:            .table          = "mangle",
>> net/netfilter/xt_CONNSECMARK.c:         .table          = "mangle",
>> net/netfilter/xt_DSCP.c:                .table          = "mangle",
>> net/netfilter/xt_MARK.c:                .table          = "mangle",
>> net/netfilter/xt_SECMARK.c:             .table          = "mangle",
>> net/ipv4/netfilter/ipt_ECN.c:   .table          = "mangle",
>> net/ipv4/netfilter/ipt_TOS.c:   .table          = "mangle",
>> net/ipv4/netfilter/ipt_TTL.c:   .table          = "mangle",
>> net/ipv6/netfilter/ip6t_HL.c:   .table          = "mangle",
>> 
>> If we're going to remove this, I think we should do it for all of them.
>
> Sorry, but I disagree. The DSCP, ECN, TOS, TTL, HL targets modify the packet 
> itself and thus all belong to the mangle table alone.

Umm, probably I was too terse in the sentence above...

Tecnically speaking, the targets could be "released" from the mangle 
table. However, all the tables have got a specific function. By breaking 
up the tie between the given targets ("mangle packet content thus and 
thus") and the table which carries the functionality ("mangle" table) just 
confuse the internal logic behind the system.

The MARK/CONNMARK targets can be used to carry neutral information all 
around the netfilter framework (besides triggering routing). So I agree 
that let those be available in all tables.

Personally, I'm not so convinced about CLASSIFY, SECMARK and CONNSECMARK.
The targets make possible to alter/modify the behaviour of external 
systems. Is there any functionality lost if the targets are restricted to
the mangle table (taking into account the ctstate match)?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
           H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Amin Azez]

* Jozsef Kadlecsik wrote, On 14/03/07 13:21:
> Hi,
>
> On Wed, 14 Mar 2007, Patrick McHardy wrote:
>
>> Amin Azez wrote:
>>> Signed-off-by: Sam Liddicott <azez@ufomechanic.net>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> Index: linux-2.6.17.1/net/netfilter/xt_CONNMARK.c
>>> Index: linux-2.6.17.1/net/netfilter/xt_MARK.c
>>
>> There are quite a few more that are restricted to mangle without
>> good reason:
>>
>> net/netfilter/xt_CLASSIFY.c: .table = "mangle",
>> net/netfilter/xt_CONNSECMARK.c: .table = "mangle",
>> net/netfilter/xt_DSCP.c: .table = "mangle",
>> net/netfilter/xt_MARK.c: .table = "mangle",
>> net/netfilter/xt_SECMARK.c: .table = "mangle",
>> net/ipv4/netfilter/ipt_ECN.c: .table = "mangle",
>> net/ipv4/netfilter/ipt_TOS.c: .table = "mangle",
>> net/ipv4/netfilter/ipt_TTL.c: .table = "mangle",
>> net/ipv6/netfilter/ip6t_HL.c: .table = "mangle",
>>
>> If we're going to remove this, I think we should do it for all of them.
>
> Sorry, but I disagree. The DSCP, ECN, TOS, TTL, HL targets modify the
> packet itself and thus all belong to the mangle table alone.
I'd like to be with Jozsef on that (while we have the current framework,
although I hate the mangle/filter distinction) except that local-out
packets at least have a FILTER after DNAT before routing, but
bridged/routed packets don't have anything betweenPREROUTING DNAT and
routing. With the current framework we could do with a FILTER and MANGLE
both before and after NAT on PREROUTING and communicate using marks.

However, to me, NAT is just a 1-packet MANGLE; and FILTER and MANGLE are
an arbitrary distinction.

It would make more sense to have only 1 table and let users invent
NAT/MANGLE/FILTER chains if they wanted (for old times sake); and just
treat snat and dnat targets as if they had an implicit "-m ctstate
--ctstate NEW".

Am I right, or do tables still help?

Sam

Re: One unified table of nat/mangle/filter

[Henrik Nordstrom]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

ons 2007-03-14 klockan 14:11 +0000 skrev Amin Azez:

> It would make more sense to have only 1 table and let users invent
> NAT/MANGLE/FILTER chains if they wanted (for old times sake); and just
> treat snat and dnat targets as if they had an implicit "-m ctstate
> --ctstate NEW".

I generally agree on this.

Ideally I'd like to se a single table capable of the functions of nat
+mangle+filter, and hooking into the hooks for which there is rules
only.

However, nat is a bit too different due to the heavy tuple assignment
code and the fact that it only makes sense on the first packet of a
session so it's not entirely obvious how to mix it. But I have done this
for a customer in the past by separating the nat engine from the table,
and making custom NAT targets capable of setting the NAT tuples outside
of the nat table if not assigned already.. wasn't too hard in the old
NAT code, and probably not very hard today either.. If it makes much
sense is another question, but to that customer it did but only so in
combination with other changes to mimic the behavior of the nat table
(only first packet, kind of..).

> Am I right, or do tables still help?

To some it probably helps. But for most building automated rulesets it's
just an annoyance I think, placing almost arbitrary restrictions on how
rulesets can be built.

Generally the split in different tables is a good idea to structure the
ruleset management, but not always depending on the origin of the
ruleset..

Regards
Henrik

[-- Attachment #2: Detta är en digitalt signerad meddelandedel --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Jozsef Kadlecsik]

Hi,

On Wed, 14 Mar 2007, Amin Azez wrote:

>> Sorry, but I disagree. The DSCP, ECN, TOS, TTL, HL targets modify the
>> packet itself and thus all belong to the mangle table alone.
> I'd like to be with Jozsef on that (while we have the current framework,
> although I hate the mangle/filter distinction) except that local-out
> packets at least have a FILTER after DNAT before routing, but
> bridged/routed packets don't have anything betweenPREROUTING DNAT and
> routing. With the current framework we could do with a FILTER and MANGLE
> both before and after NAT on PREROUTING and communicate using marks.

Something I miss here: the mangle table has got all the hooks. Before and 
after routing (DNAT), both for local and forwarded packets.

> However, to me, NAT is just a 1-packet MANGLE; and FILTER and MANGLE are
> an arbitrary distinction.
>
> It would make more sense to have only 1 table and let users invent
> NAT/MANGLE/FILTER chains if they wanted (for old times sake); and just
> treat snat and dnat targets as if they had an implicit "-m ctstate
> --ctstate NEW".

That is doable, but someting else, not iptables (plural :-).

> Am I right, or do tables still help?

I believe the tables help to distinguis among functionalities. You can 
argue that the targets *are* the functionalities and not the tables and 
you were right. But we have got hooks *and* priorities at the hooks in 
netfilter. So in the one table model the user had to keep in mind not only 
the hooks (chains) but the priorities as well: before conntrack, after 
conntrack, before routing, after routing, at the same hook. Exactly what 
is solved by the tables in iptables.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
           H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Jan Engelhardt]

On Mar 14 2007 14:11, Amin Azez wrote:
>
>It would make more sense to have only 1 table and let users invent
>NAT/MANGLE/FILTER chains if they wanted (for old times sake); and just
>treat snat and dnat targets as if they had an implicit "-m ctstate
>--ctstate NEW".

I agree on that. It lets users filter stuff out first, then use - perhaps heavy
- targets on the remaining packets. And it also eliminates the abuse of
filtering in the mangle and nat tables :)


Jan
-- 

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Patrick McHardy]

Jozsef Kadlecsik wrote:
> On Wed, 14 Mar 2007, Jozsef Kadlecsik wrote:
> 
>> Sorry, but I disagree. The DSCP, ECN, TOS, TTL, HL targets modify the
>> packet itself and thus all belong to the mangle table alone.
> 
> 
> Umm, probably I was too terse in the sentence above...
> 
> Tecnically speaking, the targets could be "released" from the mangle
> table. However, all the tables have got a specific function. By breaking
> up the tie between the given targets ("mangle packet content thus and
> thus") and the table which carries the functionality ("mangle" table)
> just confuse the internal logic behind the system.

Well, my opinion is that the mangle table is misnamed. The only
functional difference to filter is rerouting in LOCAL_OUT if any
of the routing keys changes, so it would be better called route
table.

> The MARK/CONNMARK targets can be used to carry neutral information all
> around the netfilter framework (besides triggering routing). So I agree
> that let those be available in all tables.
> 
> Personally, I'm not so convinced about CLASSIFY, SECMARK and CONNSECMARK.
> The targets make possible to alter/modify the behaviour of external
> systems. Is there any functionality lost if the targets are restricted to
> the mangle table (taking into account the ctstate match)?

Not lost. but it requires people to duplicate rules in some cases for
no real reason.

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Henrik Nordstrom]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

ons 2007-03-14 klockan 21:35 +0100 skrev Patrick McHardy:

> Well, my opinion is that the mangle table is misnamed. The only
> functional difference to filter is rerouting in LOCAL_OUT if any
> of the routing keys changes, so it would be better called route
> table.

And frankly speaking, that rerouting could just as well be done by a
target.

Regards
Henrik

[-- Attachment #2: Detta är en digitalt signerad meddelandedel --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Jan Engelhardt]

On Mar 14 2007 21:45, Henrik Nordstrom wrote:
>ons 2007-03-14 klockan 21:35 +0100 skrev Patrick McHardy:
>
>> Well, my opinion is that the mangle table is misnamed. The only
>> functional difference to filter is rerouting in LOCAL_OUT if any
>> of the routing keys changes, so it would be better called route
>> table.
>
>And frankly speaking, that rerouting could just as well be done by a
>target.

Haha... are you implying ipt_ROUTE? :p


Jan
-- 

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Henrik Nordstrom]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

ons 2007-03-14 klockan 21:48 +0100 skrev Jan Engelhardt:

> >And frankly speaking, that rerouting could just as well be done by a
> >target.
> 
> Haha... are you implying ipt_ROUTE? :p

Or whatever it will be in the successor to iptables..

just spewing ideas at this time. As Patrick I do not consider the core
iptables worth the effort of such redesign and if redesigning stuff then
something significantly better should be done. nf-HiPAC is one possible
alternative where a lot is done much smarter even if communication
between the projects is pretty distant at the moment.

The point is that with a good infrastructure a lot can be acheived,
without having to hardcode behavior such as mangle rerouting in the
infrastructure.

And with a little (not much) clever thinking not even the nat/filer
distinction is needed even if nat mostly applies to the first packet
only.. And regarding the ability to filter after nat: Remember that you
have the connection backing you. A NAT mapping is not much different
from a CONNMARK or other connection state.. it's just data which is
known about the packet once the rule has executed.

Regards
Henrik

[-- Attachment #2: Detta är en digitalt signerad meddelandedel --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Carl-Daniel Hailfinger]

On 14.03.2007 23:21, Henrik Nordstrom wrote:
> Or whatever it will be in the successor to iptables..
> 
> just spewing ideas at this time. As Patrick I do not consider the core
> iptables worth the effort of such redesign and if redesigning stuff then
> something significantly better should be done. nf-HiPAC is one possible
> alternative where a lot is done much smarter even if communication
> between the projects is pretty distant at the moment.

Speaking of HiPAC, when is it going to be merged? IIRC the merge was
discussed at the netfilter workshop 2005 with the goal to merge it in
2.6.16. Has this decision been overturned/revised/forgotten or was
the report I read about that netfilter workshop inaccurate?

Regards,
Carl-Daniel

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Patrick McHardy]

Carl-Daniel Hailfinger wrote:
> On 14.03.2007 23:21, Henrik Nordstrom wrote:
> 
>>Or whatever it will be in the successor to iptables..
>>
>>just spewing ideas at this time. As Patrick I do not consider the core
>>iptables worth the effort of such redesign and if redesigning stuff then
>>something significantly better should be done. nf-HiPAC is one possible
>>alternative where a lot is done much smarter even if communication
>>between the projects is pretty distant at the moment.
> 
> 
> Speaking of HiPAC, when is it going to be merged? IIRC the merge was
> discussed at the netfilter workshop 2005 with the goal to merge it in
> 2.6.16. Has this decision been overturned/revised/forgotten or was
> the report I read about that netfilter workshop inaccurate?


Unfortunately the discussion pretty much came to a halt over a year
ago because of some disagreements. I still consider merging it a
good idea, but since there is no progress in this area I will start
working on a netlink based iptables replacement myself in the next
months.

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Jan Engelhardt]

On Mar 15 2007 00:02, Patrick McHardy wrote:
>
>Unfortunately the discussion pretty much came to a halt over a year
>ago because of some disagreements. I still consider merging it a
>good idea, but since there is no progress in this area I will start
>working on a netlink based iptables replacement myself in the next
>months.

Does not iptables (like iproute2 and /usr/sbin/conntrack) use netlink already?

Jan
-- 

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Patrick McHardy]

Jan Engelhardt wrote:
> On Mar 15 2007 00:02, Patrick McHardy wrote:
> 
>>Unfortunately the discussion pretty much came to a halt over a year
>>ago because of some disagreements. I still consider merging it a
>>good idea, but since there is no progress in this area I will start
>>working on a netlink based iptables replacement myself in the next
>>months.
> 
> 
> Does not iptables (like iproute2 and /usr/sbin/conntrack) use netlink already?

No, it has an ugly blob-passing setsockopt-based interface,
which is reponsible for a lot of the problems we have with
iptables.

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Henrik Nordstrom]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

ons 2007-03-14 klockan 23:58 +0100 skrev Carl-Daniel Hailfinger:

> Speaking of HiPAC, when is it going to be merged?

Hard to say. The goals and implementation of HiPAC is pretty much in
line with the long term goals of Netfilter, but merging such big
projects is not easy with complications at many levels most of which
outside the code as such.

On the negative side of HiPAC there isn't very many people fully
understanding HiPAC, and as with most complex tree operations it's not
very easy to penetrate which is a bit scary from a maintenance point of
view. But thankfully at least the end results (the lookup tree) is
pretty simple, and so is the reasoning on what the lookup tree should
look like based on a given ruleset.. just what happens inbetween there
on rule updates is a little bit magic..

The hipac core is about 11000 lines of C, compared to ca 2000 for
iptables..

On the good side the current release is a whole lot easier to follow
than the earlier release for 2.4..

Regards
Henrik

[-- Attachment #2: Detta är en digitalt signerad meddelandedel --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Roberto Nibali]

>>> just spewing ideas at this time. As Patrick I do not consider the core
>>> iptables worth the effort of such redesign and if redesigning stuff then
>>> something significantly better should be done. nf-HiPAC is one possible
>>> alternative where a lot is done much smarter even if communication
>>> between the projects is pretty distant at the moment.
>>
>> Speaking of HiPAC, when is it going to be merged? IIRC the merge was
>> discussed at the netfilter workshop 2005 with the goal to merge it in
>> 2.6.16. Has this decision been overturned/revised/forgotten or was
>> the report I read about that netfilter workshop inaccurate?
> 
> Unfortunately the discussion pretty much came to a halt over a year
> ago because of some disagreements. I still consider merging it a
> good idea, but since there is no progress in this area I will start
> working on a netlink based iptables replacement myself in the next
> months.

Cough ... could we guys over at ../ipv4/ipvs/ synchronise with your 
ideas? I've once started a port of IPVS to the netlink framework 
together with Thomas Graf, but stopped the project because I didn't find 
enough time. I'll be offline for at least one year soon but my fellow 
hackers (Horms at the moment) over at IPVS sure would like to combine 
efforts; maybe we can even completely integrate IPVS into the new (fast 
and memory-efficient like nf-hipac) netfilter framework and share the 
netlink code in user space with regards to iptables and ipvsadm.

Best regards,
Roberto Nibali, ratz
-- 
echo 
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Re: [PATCH 1/1] Re: dangerous? Setting mark in nat table

[Patrick McHardy]

Roberto Nibali wrote:
>> Unfortunately the discussion pretty much came to a halt over a year
>> ago because of some disagreements. I still consider merging it a
>> good idea, but since there is no progress in this area I will start
>> working on a netlink based iptables replacement myself in the next
>> months.
> 
> 
> Cough ... could we guys over at ../ipv4/ipvs/ synchronise with your
> ideas? I've once started a port of IPVS to the netlink framework
> together with Thomas Graf, but stopped the project because I didn't find
> enough time.


We could try, but I'm not sure how much it would be possible to share.
But to be honest I don't know much about IPVS, looking over the code,
I can't even find something that looks like ruleset evaluation.

> I'll be offline for at least one year soon but my fellow
> hackers (Horms at the moment) over at IPVS sure would like to combine
> efforts; maybe we can even completely integrate IPVS into the new (fast
> and memory-efficient like nf-hipac) netfilter framework and share the
> netlink code in user space with regards to iptables and ipvsadm.


I didn't have plans to invent a new classification algorithm so far
(would be a bit of a waste of time since there already is nf-hipac),
just a better userspace interface dealing with individual rules
that doesn't use the ABI structures inside the kernel for anything
else. This will give us a lot more flexibility than what we currently
have.

Anyway, its probably going to be a few months from now before I
begin, I'll make sure to talk to Horms once I have a clearer picture.
But feel free to already push ideas.