Re: RFC1323 Window Scaling Issues
Hi Mark, I'm one of the people who managed to get in trouble due to this, and I thought I'd just mention that the situations where it can occur can be quite subtle, for example: block all pass in on $external proto tcp from $internet to $webserver port $http pass out on $internal keep state pass out on $external keep state I figured since the state would be floating that I'd create all the states on outgoing, but later learned that it's actually two different states, so the $external state will be created with the returning SYN+ACK packet, thus breaking wscale support. From what I can understand so far state entries are bound to either receive or send queues on interfaces, and floats between for example different receive queues on different interfaces, but not between different receieve and send queues... Now I love tools with sharp edges, and if I err and cut myself I'm to blame, but I think the tools also be documented enought to allow people to be creative without having the blade snap. From the OpenBSD manual: By default, packets coming in and out of any interface can match a state, [...], but if I create a state from A to B on the intial SYN packet on an _outgoing_ internal interface, the returning SYN+ACK will _not_ match it on the external interface (since it's returning and thus should be incoming I guess?), create a new state, and break window scaling. This to me, still after re-reading documentation, seems like an error in either the documentation or the implementation. Kind regards, Fredrik Widlund Mark Voelker wrote: 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
Re: RFC1323 Window Scaling Issues
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
Re: RFC1323 Window Scaling Issues
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
Re: RFC1323 Window Scaling Issues
Yeah, great explanation. I'm adding this to my list of things that should be in the docs list, hopefully I'll get a chance to submit some patches some day. -- Resolve is what distinguishes a person who has failed from a failure. Unix guru for sale or rent - http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
