On Mon, Jan 31, 2011 at 08:41:02PM +0100, Henning Brauer wrote: > * 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. >
ok > > 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 > it's this thing about matching any state. i can;t get my head properly round it. being blocked, that's a state. so is being excited. so i'm asking if "keep state" works by matching packets to entries in the state table (or whatever it is) or if it really is correct that pf checks whether it matches "any state". any state equals all possible states. > > 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 > i'm just curious - it would help me understand the "any state" text. jmc
