Re: FairQ ALTQ for PF - Patch #2

[Max Laier <max@xxxxxxxxxxxxxx>]

On Monday 07 April 2008 03:26:32 Matthew Dillon wrote:
> :>     (1) I'm using keep state, not synproxy.  Is PF still attempting
> :> to do window sequence space comparisons and dropping packets if they
> :> do not match?  If it is, do you know where in the code that is (I've
> :> been staring at it a while trying to find just such a comparison but
> :> not having a whole lot of luck).
> :
> :See the attached forward from the pf mailinglist.  The referenced
> : paper is a good read, too.
>
>     (reading that right now)
>
> :> 	and it drops some of its state, won't those flows wind up being
> :> 	left out of the state code from that point on?  They would not be
> :> 	identifiable to the fairq code, then, which would be a fairly
> :> 	significant problem.
> :
> :Usually you won't drop active states.  You'd simply time them out more
> :aggressively (see adaptive.{start,end} in pf.conf(5) if your version
> : has that already) or not allow a new state to be created.
> :...
> :It really depends on what you want to achieve.  If you are after
> : security for a network of clients with bad/broken TCP stacks then
> : leaving out the window checks is not a good idea.  I can see that
> : there are cases where you'd want to check only the
> : (src,dst,proto)-tuple and pass every matching packet regardless. 
> : Currently pf doesn't allow for this to happen statefully and I don't
> : think OpenBSD is going to make that change, ever.  If you think of pf
> : as a security first and foremost mechanism this makes sense.  I'm
> : also somewhat reluctant to make that change in FreeBSD, otoh there
> : are cases where you'd want that rope.
> :
> :--
> :/"\  Best regards,                      | mlaier@freebsd.org
> :\ /  Max Laier                          | ICQ #67774661
>
>     Yah, we have the adaptive.start/end stuff.  I think I have a pretty
>     good handle on the issues now.   I understand NetBSD's viewpoint on
>     connection tracking.
>
>     But for my own network I am extremely uncomfortable allowing a
> router to drop a good TCP connection, and even more uncomfortable
> having the router control timeouts considering that the only way to
> overcome such a situation in the face of overload would be to drop the
> keepalive timeouts on all my machines down to fairly small values.  I
> don't want a reboot of my router to blow up the several hundred active
> TCP connections from half a dozen servers that are running through it.
>
>     At the same time I really want to use the keep-state mechanic to
> serve as a basis for caching that hash code for my fairq.  I don't want
> to roll my own like the WFQ code does... that would be a massive
> duplication of work.

Agreed.  The code in WFQ is historical when there was altqd and /dev/altq 
and the altq_classifier.  pf (or any firewall for that matter) really is 
the place to do the classification.

>     I think the solution is to add another flavor of keep state that
>     is explicitly meant for use with fairq (or fairq-like) mechanisms,
>     or for middle-of-network routing (verses edge routing), which want
>     that hash code or want some sort of identification entity for
> flows.
>
>     If I create a 'hash state' keyword that would be fairly obvious
>     in its function.  It would basically operate the same as keep
> state, but explicitly omit any checks which cannot be done if the state
> is picked up in the middle of the connection.
>
>     I definitely want to make fairq portable to other OS's.  What do
> you think about a 'hash state' keyword?  From a coding perspective it's
> a little work in parse.y and maybe three or four conditionals in the
> TCP state code (to omit the sequence space checks for that case).

I think "reduced state tracking" and the fairq are orthogonal.  You can 
have either independent of each other.  If I were to do reduced states, 
I'd probably make it a "state-opt" (see pf.conf(5) BNF) so that it could 
be applied to any keep state rule with various effects.  This way you 
could even do modulate state or synproxy state as long as you see the 
initial SYN.  If not, you fall back to creating a reduced state.  This 
option would, of course, also have a setting where it would always just 
create a reduced state and be done with it.

As for the name ... maybe, 'extra-tcp-state' with a possible setting 
of 'on' (default), 'off' and 'force-off' or something like that.  This 
could also be a global setting similar to the timeouts which can also be 
set on a per-rule basis.

-- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News