* Jason McIntyre <j...@kerhand.co.uk> [2011-01-31 18:14]:
> On Mon, Jan 31, 2011 at 11:28:13AM +0100, Henning Brauer wrote:
> > then i change my mind and we should add a note that the default pass
> > behaviour (NOT rule, even tho there kinda is a default rule
> > internally...) doesn't lead to state creation.
> it's not going to be easy deciding where to insert this text, but we can
> have a go. but first, i have questions ;(
> 
> firstly, what is the reason for the "no state" of packets passed by
> default (i.e. without matching a rule)? we do say:

well, gotta do something when nothing matches. and we do basically
nothing, i. e. not dropping the packet. that makes pf enabled but no
ruleset pretty much equivalent to pf disabled (well, practicallt
speaking at least). and i that's sane semantics imho.

>       By default pf(4) filters packets statefully...
> but it does not then, for these (default ;( packets.

when you have no matching rules it doesn't filter ;)

> secondly i;m not sure i like our explanation of state:
> 
>         By default pf(4) filters packets statefully: the first time
>         a packet matches a pass rule, a state entry is created; for
>         subsequent packets the filter checks whether the packet
>         matches any state.
> 
> that "any state" text at the end is horribly ambiguous. should that say
> "any state entry"?

puh. not sure we're on the road to overengineering here.
basically, the flow is like this:
-we do a state lookup. if we find a mathcing state, we apply actions
 associated with it and are done.
-if no state matched we traverse the ruleset. then there are 3 cases:
 1) the combo of match rules that matched and a pass rule decide on the
    actions and state creation
 2) last matching rule was a block rule. we might send back an RST or
    an icmp error, then drop the packet
 3) nothing matched, we do nothing, basically

> and what does a state entry look like?

i don't get what you're after with that - a state is a struct, with a
couple of associated structs. a more detailed explanation of the new
state table logic is in my "faster packets" slides:
http://quigon.bsws.de/papers/2009/eurobsdcon-faster_packets/
especially slide 40 to 52

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Reply via email to