Re: FairQ ALTQ for PF - Patch #2

[Max Laier <max@xxxxxxxxxxxxxx>]

On Monday 07 April 2008 01:48:28 Matthew Dillon wrote:
> :>     It's got to be something PF (packet filter) is doing.  I was
> :> using a Cisco with the T1.  I'm using a DFly box running PF with the
> :> DSL line. I'm trying to track it down.
> :
> :This is usually a symptom of creating state on a TCP packet other than
> : the initial SYN.  Make sure you add "flags S/SA" to all your tcp keep
> : state rules.  There is plenty on this in the FAQs and lists
> : (freebsd-pf@ and the OpenBSD pf list) for more detailed reference.
> :
> :--
> :/"\  Best regards,                      | mlaier@freebsd.org
> :\ /  Max Laier                          | ICQ #67774661
>
>     I kinda half understand that.  Are you saying that because creating
>     state on other then the initial syn has no information on the
> window scale (which is only handled in the SYN and SYN+ACK), that it
> will blow up?

Right.

>     Here are two questions:
>
>     (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.

>     (2) If I restart PF, and do not create state for pre-existing
> connections, won't that blow up the classification of those
> connections?

Yes, if you also flush states.

> 	In particular, if there are a lot of flows going through the router
> 	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.

>     What I would like to do, if (1) is true, is modify PF to flag that
> the state was created without a SYN, and have it automatically ignore
> sequence space comparisons for that case.

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
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--- Begin Message ---

From:	Ryan McBride <mcbride@xxxxxxxxxxxxxxxx>
Date:	Sun, 6 Apr 2008 19:53:39 +0900

On Wed, Apr 02, 2008 at 04:27:17PM -0700, Adam Richards wrote:
> Is there a "no state" directive for nat rules, similar to the
> no-state directive for filter rules?  Or another clever way to
> use nat/rdr/filter statements?  Even though I wasn't able to find
> any affirmative evidence in pf.conf(5) manpage I thought I'd ask
> anyway.
> 
> While I'd prefer a "yes pf can do this" answer, I will accept a
> "no...but here are the code sections you'll want to look at to
> start your patch work" answer.  ;)

No, PF does not do this.

Keeping state is required for NAT to work, because you need to keep
track of the mapping so that the return packets can be translated back
the other way; I'm guessing that your actual problem is not the basic
state mechanism, but the TCP sequence number tracking.

Look for the commend "Sequence tracking algorithm from Guido van Rooij's
paper" in sys/net/pf.c for this code; it should be relatively trivial to
add a bypass option for this in pfctl, and skip these checks in pf.c if
that option is present.

None of this is really a good idea though, and it shouldn't be seen as
an appropriate response to a nasty network design.

-Ryan

--- End Message ---