On Fri, Jun 30, 2006 at 09:40:38PM -0700, Mark Voelker wrote:

> I'm frequently hearing (not only in these threads) that pf is
> thought to be buggy with regards to window scaling that and that
> it can cause problems like those described in these threads. 

Problems like this occur when people use pf to filter statefully,
but do not create state on the initial SYN of TCP connections.

Window scaling support is negotiated in the SYN and SYN+ACK
packets of connection establishment. pf can only support it
properly when both these packets are seen and associated with
a state entry (i.e. you create state on SYN and SYN+ACK matches
the state).

If the ruleset passes the SYN packet statelessly (without 'keep
state'), but then creates state on the returning SYN+ACK, the
state entry has missed the window scaling negotiation. There
were a couple of reports of people who managed to do this, all
by mistake (if you intend to create state, you most certainly
want to do it on the initial packet).

Most people would call these misconfigurations (buggy rulesets),
but some people feel that only a buggy program would allow a
user to make such a mistake, hence pf must be buggy. Hence the
myth of "pf is buggy wrt window scaling". I suggest these people
don't use tools with sharp edges, they could hurt themselves ;)

If you want a simple way to ensure this is not happening with
your ruleset, make sure that

  a) there is a default block policy
  b) all 'pass' rules that can match TCP have 'flags S/SA'
  c) all 'pass' rules have 'keep state'

And, no, other packet filters have no magical way of deducing the
proper scaling factors if they missed the handshake. If they don't
stall connections in this scenario, it just means they are using
sloppy TCP window restrictions or don't check TCP sequence numbers
at all. We are proud of our strict window checks :)

Daniel

Reply via email to