* Jason McIntyre <j...@kerhand.co.uk> [2011-01-31 21:45]:
> > 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.

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.

> > > 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.

you need to come to conferences and see my talks ;)
the slides above handle exactly that.

-- 
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