From: Thomas Heinz <creatix@hipac.org>
To: Venkatesh Prasad Ranganath <vranganath@cox.net>
Cc: netfilter@lists.netfilter.org, nf@hipac.org
Subject: Re: ACCEPT/DROP
Date: Fri, 20 Dec 2002 12:36:48 +0100 [thread overview]
Message-ID: <3E0300D0.4020307@hipac.org> (raw)
In-Reply-To: 3E02F42E.3080306@cox.net
Hi Venkatesh
You wrote:
> I was looking into the iptables implementation and was intrigued about
> how iptables would handle a situation in which we have identical rules
> except for their targets which are contradicting, say ACCEPT and DROP.
> By looking at ipt_do_table() function it seems that the first
> non-IPT_RETURN verdict from any standard target will end the traversal
> of a chain of a table, which seems to be a bit odd. First, such
> conflicting rules must not be allowed. Even beyond, this fails in the
> situation where you have a dropping rule added after an accepting rule.
You misunderstand the definition of conflicting rules in the context
of the packet classification problem. A conflict occurs if there are
two or more matching rules with the same minimal cost. Since the cost of
a rule is equivalent to its position in the chain[1] and the position is
unique there are no conflicts by definition.
This holds for both iptables and nf-hipac.
[1] at least if you're not using user-defined chains; but even if user-
defined chains come into play the costs are in fact unique
> For example, a packet from m.n.o.p to a.b.c.d would be accepted at
> a.b.c.d because of the first rule, although it had to be dropped
> according to the second rule. And this would result because of the
> order in which the rules are added to the table.
This behaviour is intended. The packet classification problem is about
finding the matching rule with minimal cost.
Thomas
prev parent reply other threads:[~2002-12-20 11:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-20 10:42 ACCEPT/DROP Venkatesh Prasad Ranganath
2002-12-20 11:36 ` Thomas Heinz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E0300D0.4020307@hipac.org \
--to=creatix@hipac.org \
--cc=netfilter@lists.netfilter.org \
--cc=nf@hipac.org \
--cc=vranganath@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.