RFC1323 Window Scaling Issues

[Mark Voelker]

Lately I've run into a couple of instances where folks I work
with have had problems with TCP window scaling like those
referred to here:

http://kerneltrap.org/node/6723
and here:
http://marc.theaimsgroup.com/?l=linux-kernelm=114478906522646w=2

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. 
Can anyone clarify if there is indeed such a problem?  I gather
from the linux folk that they think it has something to do with
statefullness when window scaling is enabled?  If there is such
a problem, are there know ways to mitigate it?  I'm curios
because I keep hearing references to this mysterious problem
with OpenBSD firewalls in conversations and newsgroup posts,
but haven't really found anyone who can describe if it really
exists (or still exists) and what the problem actually is.  This
seems to be coming up more frequently lately because some folks
around me are using very recent linux kernels (2.6.17-x), in
which the send/receive buffering has changed a bit (see commit
7b4f4b5ebceab67ce440a61081a69f0265e17c2a in the 2.6.17
changelog).  I think there is a good deal of confusion and some
finger-pointing out there about all this, so I'd love to get
some clarity on the issue.  Thanks!

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: RFC1323 Window Scaling Issues

[Mark Voelker]

Daniel,

Thanks for a very lucid explanation!  I had wondered if it might
be more of a user error situation (and thankfully I've only
discovered one such erroneously configured OpenBSD machine so
far!).

Mark

--- Daniel Hartmeier [EMAIL PROTECTED] wrote:

 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
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com