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>

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