Re: FairQ ALTQ for PF - Patch #2

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

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

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

						-Matt