Re: FairQ ALTQ for PF - Patch #2

Previous thread: Re: FairQ ALTQ for PF - Patch #2 by Matthew Dillon on Sunday, April 6, 2008 - 4:23 pm. (1 message)

Next thread: Re: FairQ ALTQ for PF - Patch #2 by Matthew Dillon on Sunday, April 6, 2008 - 5:13 pm. (1 message)
From: Matthew Dillon
Date: Sunday, April 6, 2008 - 4:48 pm

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?

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

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

	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.

    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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>
From: Max Laier
Date: Sunday, April 6, 2008 - 5:32 pm

See the attached forward from the pf mailinglist.  The referenced paper is 


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 

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
Previous thread: Re: FairQ ALTQ for PF - Patch #2 by Matthew Dillon on Sunday, April 6, 2008 - 4:23 pm. (1 message)

Next thread: Re: FairQ ALTQ for PF - Patch #2 by Matthew Dillon on Sunday, April 6, 2008 - 5:13 pm. (1 message)