target MARK in filter table?

target MARK in filter table?

[Poltorak Serguei]

Why not to allow MARK packets in filter table? As i know it doesn't mangle
(change) the packet, it changes only information about it on local this
router. So, why not to use it widely in filter table?

PoltoS/

target MARK in filter table?

[Poltorak Serguei]

Why not to allow MARK packets in filter table? As i know it doesn't mangle
(change) the packet, it changes only information about it on local this
router. So, why not to use it widely in filter table?

PoltoS/

Re: target MARK in filter table?

[Patrick Schaaf]

> Why not to allow MARK packets in filter table? As i know it doesn't mangle
> (change) the packet, it changes only information about it on local this
> router. So, why not to use it widely in filter table?

The fwmark influences the routing decision. In the filter table, the
routing decision has already been made. This raises the following
decision problem;

- should rerouting be done when MARK is used in the filter table
- or not?

This decision problem will have different answers for different uses.
Thus, an implementation must make an arbitrary decision.

How would _you_ make that decision?

I have no idea if that is the real reason why nobody made MARK for filter,
but to me, it's a good reason not to make it. Arbitrary decisions always
bite you, later.

Traditional counterquestion: what do you want to accomplish, that lets
you look for MARK in filter?

best regards
  Patrick

Re: target MARK in filter table?

[Poltorak Serguei]

;Traditional counterquestion: what do you want to accomplish, that lets
;you look for MARK in filter?
I yould like to mark packets that passes through several chains. I don't
want allow packets there, I want them to continue their live (to be DROPed :)
This has nothing to do with routing, i'm using iproute without fwmark.
And after all in mangle table there are chains placed after routing. so
what about using mangle in a chain like that?

MAy be u know another way to mark packets. For me it's only a flag that
packets have when the pass a chain.

A had a look in iptables: iptables doesn't check the table for MARK target.
In kernel source there are only one check that does nothing (except check :)
        if (strcmp(tablename, "mangle") != 0) {
                printk(KERN_WARNING "MARK: can only be called from \"mangle\" table, not \"%s\"\n",
                return 0;
        }
may be that will suffice

thanks for help

PoltoS/

Re: target MARK in filter table?

[Poltorak Serguei]

I tested MARK target with kernel without following line in linux/net/ipv4/netfilter/ipt_MARK.c
        if (strcmp(tablename, "mangle") != 0) {
                printk(KERN_WARNING "MARK: can only be called from \"mangle\" table, not \"%s\"\n",
                return 0;
        }

For now everything works including MARK target in chain INPUT of table filter.

If you do know a reason why this must not be done, please tell me. MARK is
usefull even without advanced routing.

PoltoS/

Re: target MARK in filter table?

[Patrick Schaaf]

On Sun, Jul 13, 2003 at 04:43:13PM +0400, Poltorak Serguei wrote:
> 
> I tested MARK target with kernel without following line in linux/net/ipv4/netfilter/ipt_MARK.c
>         if (strcmp(tablename, "mangle") != 0) {
>                 printk(KERN_WARNING "MARK: can only be called from \"mangle\" table, not \"%s\"\n",
>                 return 0;
>         }
> 
> For now everything works including MARK target in chain INPUT of table filter.
> 
> If you do know a reason why this must not be done, please tell me. MARK is
> usefull even without advanced routing.

I do not disagree, the rerouting indecision was just the one possible reason
I could think of.

What do other developers think? What other reasons were there to keep the MARK
target from working in the filter table?

While we are on the topic of seemingly arbitrary "sanity" checks, why is
it that using the TCPMSS option throws a vague "invalid argument" error
when one forgets to also specify --syn? Can't that target just check for
tcp/syn dynamically, i.e. become a NOOP for non-syn packets, instead of
forcing me to specify --syn at rule insertion time?

best regards
  Patrick

Re: target MARK in filter table?

[Harald Welte]

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

On Sun, Jul 13, 2003 at 04:19:44PM +0200, Patrick Schaaf wrote:
> > If you do know a reason why this must not be done, please tell me. MARK is
> > usefull even without advanced routing.
> 
> I do not disagree, the rerouting indecision was just the one possible reason
> I could think of.
> 
> What do other developers think? What other reasons were there to keep the MARK
> target from working in the filter table?

Because it violates our idea of the iptables framework.  It is a policy
kind of decision, not a 'what is technically possible' decision.

The idea is to have targets for filtering in the filter table - and
anything that modifies the packet [or potentially affect other kernel
subsystems such as policy routing] in 'mangle'.

We could enable almost all mangle targets to be used in the filter
table, there is no inherent technical limitation.

But it just feels wrong with regard to the policy we are trying to
enforce.

In that particular practical case, I think Poltorak Serguei is 'abusing'
the mark mechanism for something that we didn't think it should be 

> While we are on the topic of seemingly arbitrary "sanity" checks, why is
> it that using the TCPMSS option throws a vague "invalid argument" error
> when one forgets to also specify --syn? Can't that target just check for
> tcp/syn dynamically, i.e. become a NOOP for non-syn packets, instead of
> forcing me to specify --syn at rule insertion time?

Error reporting is a whole discussion that I've had at least once a
couple of years ago.  There is no sane way to add verbose error
reporting back to iptables userspace because of the set/getsockopt
interface :(

the best we can do is printk() the error and ask the user to check dmesg
in case we receive -EINVAL.

But returning an error in this case is IMHO the correct behaviour.  What
is the idea behind blindly accepting rules that don't make sense for
non-syn packets?

And if there is one mechanism of checking for SYN, why should we
implement this check in other places as well?

Also, it gives the user/administrator a chance to see what is really
happening.  The user will know that TCPMSS will only affect SYN packets,
not any other (something he most likely doesn't know when it just
magically works).

> best regards
>   Patrick

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: target MARK in filter table?

[Poltorak Serguei]

;The idea is to have targets for filtering in the filter table - and
;anything that modifies the packet [or potentially affect other kernel
;subsystems such as policy routing] in 'mangle'.
And if I'm using fwmark mechanism not to change packet, but to
mark it and remember that this one I need to treat differantly.

May be you know a better way to do it...
In my case i need to know if the examined packet had entered into a chain
or it didn't mached all of them. Because it may traverse 0,1 or 2 chains.
I'm marking the packet on the entrance of each chain and checking at the
end of FORWARD if it is marked. I'm marking packets i don't disallow, but
i'm not sure to accept, and if no chain will DROP it and it had passed at 
least one chain, it would be accepted.

;In that particular practical case, I think Poltorak Serguei is 'abusing'
;the mark mechanism for something that we didn't think it should be 
;
;> While we are on the topic of seemingly arbitrary "sanity" checks, why is
;> it that using the TCPMSS option throws a vague "invalid argument" error
;> when one forgets to also specify --syn? Can't that target just check for
;> tcp/syn dynamically, i.e. become a NOOP for non-syn packets, instead of
;> forcing me to specify --syn at rule insertion time?
I'm not abusing, it was text of Patrick Schaaf, not mine :)

now i'm using MARK in filter table. it works. i commented the checking of
table. may this cause problems (apart philosophy)? is it safe to use?

I think fwmark is very usefull not only with routing and qos to tell what
to change/mangle/nat/... It makes iptables more programmable :)

PoltoS/

Re: target MARK in filter table?

[Patrick Schaaf]

On Tue, Jul 15, 2003 at 08:26:17AM +0400, Poltorak Serguei wrote:
> ;The idea is to have targets for filtering in the filter table - and
> ;anything that modifies the packet [or potentially affect other kernel
> ;subsystems such as policy routing] in 'mangle'.
> And if I'm using fwmark mechanism not to change packet, but to
> mark it and remember that this one I need to treat differantly.
> 
> May be you know a better way to do it...

The workaround that I used in some situations, was to create suitable
classification chains at mangle/PREROUTING, which set MARK values,
and then consistently match these marks in the filter table, instead
of using various criteria directly.

It is a bad workaround, because it complicates the ruleset by one layer.
In the filter table, I can no longer locally see _when_ something is done,
only _what_ is done; for the full picture, I have to jump back and forth
between reading filter and mangle chains.

This is bearable, but not really nice.

> I think fwmark is very usefull not only with routing and qos to tell what
> to change/mangle/nat/... It makes iptables more programmable :)

Exactly my feeling.

best regards
  Patrick