Re: inadequate NEW, INVALID state definitions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 2, 2010 at 2:35 PM, Jeremiah Crockett <jrmhcrcktt@xxxxxxxxx> wrote:
> On Wed, Jun 2, 2010 at 1:27 PM, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote:
>> . The five
>> --ctstates {NEW, ESTABLISHED, RELATED, INVALID, UNTRACKED} _are
>> mutually exclusive_ to another.
>
> Are they all inclusive, i.e., is it possible for a packet not to match any
> of these states?  Or do packets "fall-through" into UNTRACKED if nothing
> else matches?

I believe that the default is INVALID, not UNTRACKED.  From my limited
understanding, UNTRACKED is used for traffic that was sent to the
NOTRACK target.

On Wed, Jun 2, 2010 at 1:27 PM, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote:
> Packets basically start without any associated connection, that is,
> will be matched by -m conntrack --ctstate INVALID.

Thanks Jan.  So two important points that I gleaned from your post are
(1) the states are mutually exclusive and (2) all packets start with a
default of INVALID.

This seems to get a bit murkier as some conditions that match INVALID,
including invalid combinations of TCP flags, seem to be an "active
match" instead of a "passive default."  In other words, if the state
starts as INVALID, and conntrack determines that it should be state
NEW, something somehow must be applied afterwards to force it back to
INVALID due to it being a malformed packet.  How does that "something"
fit in with this chain of events, and what does it check for?
Alternately, do the checks for placing a packet into the other states
check for malformed packets, in which case no second check for
malformed packets needs to be done because anything that moves from
INVALID is already known to be well-formed?

I think part of the confusion stems from this: Based on my reading of
the admittedly suboptimal documentation, there are two ways that
packets can be marked INVALID:

The packet is not part of any connection marked NEW, RELATED,
ESTABLISHED, or UNTRACKED.
The packet is malformed or otherwise problematic.

The first is determined in the context of the conntrack system, and
takes into consideration conntrack's knowledge of the state of the
network and the connections therein.  The second treats packets in a
vacuum and evaluates parts of the packet against other parts to
determine its consistency.

It's likely that my confusion stems from a still-incomplete knowledge
of how packets traverse the different parts of netfilter and xtables.

Thanks again, everyone!

--Mike
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux