On Mon, Jan 31, 2011 at 4:03 PM, Jason McIntyre <j...@kerhand.co.uk> wrote:
> On Mon, Jan 31, 2011 at 11:27:18PM +0100, Henning Brauer wrote:
>>
>> i don't understand the confusion. we have a state table (let me
>> nitpick: it's a tree). a packet comes in. we do a lookup in the table,
>> looking for an entry where the key fields match the packet. keys are:
>>
>> protocol
>> address family
>> src addr
>> dst addr
>> src port
>> dst port
>> rdomain
>>
>> if there is a match we found a state key, not a state yet. so we start
>> to walk the list of states that hangs off the state key to find the
>> right one - there can be multiple with interface bound states.
>>
>> now we have a state. that doesn't imply passing the packet yet, but at
>> this point we decided for that state and against ruleset evaluation.
>>
>> now some more checks - there is a bit of timeout handling and for tcp
>> the sequence number checks, and the flags etc. if these all go ok we pass
>> the packet (and apply actions if requested, like NAT, routing etc). if
>> not, we block it.
>>
>
> ok, got it. the confusion is this: when pf.conf.5 talks about "any
> state" in this context, it means there is a match in the state tree (as
> you say). the confusion is that being in "any state" in english can mean
> something else. consider that two paragraphs previous we say (of
> match rules): "the pass/block state of a packet remains unchanged". thus
> you can very easily think of a packet as being in a "block state". and
> wahay, let's now talk about how pf works by saying "for subsequent
> packets the filter checks whether the packet matches any state".
>
> so that abbreviation (just saying "state") is ambiguous. i suggest the
> diff below. note it may not be technically correct...
>
> Index: pf.conf.5
> ===================================================================
> RCS file: /cvs/src/share/man/man5/pf.conf.5,v
> retrieving revision 1.488
> diff -u -r1.488 pf.conf.5
> --- pf.conf.5 23 Jan 2011 23:34:18 -0000 1.488
> +++ pf.conf.5 1 Feb 2011 00:01:05 -0000
> @@ -127,7 +127,7 @@
> the first time a packet matches a
> .Ar pass
> rule, a state entry is created; for subsequent packets the filter checks
> -whether the packet matches any state.
> +whether the packet matches that state entry.
but the "subsequent packets" may match any existing states in the
packet filter. Being specific to "that state entry" is confusing
(misleading?) IMO.
You may wish to break apart the sentences so that the bit about
"subsequent packets" isn't implicitly related to the preceding
sentence.
the first time a packet matches a pass rule, a state
entry is created.
Also consider explaining what defines a state (protocol, family,
src/dst addr/port, rdomain).
Then continue fresh:
The packet filter examines each packet to see if
it matches any existing state; allowing it to pass
if such a match is found without evaluation of any
rules.
> If it does, the packet is passed without evaluation of any rules.
> After the connection is closed or times out, the state entry is
automatically
> removed.
--patrick
