:...
:could even do modulate state or synproxy state as long as you see the
:initial SYN. If not, you fall back to creating a reduced state. This
:option would, of course, also have a setting where it would always just
:create a reduced state and be done with it.
:
:As for the name ... maybe, 'extra-tcp-state' with a possible setting
:of 'on' (default), 'off' and 'force-off' or something like that. This
:could also be a global setting similar to the timeouts which can also be
:set on a per-rule basis.
:
:\ / Max Laier | ICQ #67774661
I came across an interesting item. I believe (but I'm not entirely
sure if I am correct) that NetBSD implies S/SA for TCP keep
state and it no longer needs to be specified in the rule. Is this
correct? It makes sense since keep state is completely broken for
TCP if S/SA isn't specified sans the type of augmentation we've been
discussing.
With that in mind here is my proposed state_opt_item feature. I am
soliciting opinions on the feature:
[additions to state_opt_item]
pickups
Specify that mid-stream pickups are to be allowed. The default
is to NOT allow mid-stream pickups and implies flags S/SA for TCP
connections. If pickups are enabled, flags S/SA are not implied
for TCP connections and state can be created for any packet.
The implied flags parameters need not be specified in either case
unless you explicitly wish to override them, which also allows
you to roll-up several protocols into a single rule.
Certain validations are disabled when mid-stream pickups occur.
For example, the window scaling options are not known for
TCP pickups and sequence space comparisons must be disabled.
This does not effect state representing fully quantified
connections (for which the SYN/SYN-ACK passed through the routing
engine). Those connections continue to be fully validated.
nopickups
Specify that mid-stream pickups are not to be allowed. This is the
default and this keyword does not normally need to be specified.
However, if you are concerned about rule set portability then
specifying this keyword guarantees flags S/SA for TCP connections,
and pfctl generates a parse-time error if it doesn't understand the
feature.
hashonly
Implies pickups and maintains a state table entry but disables
most validations whether or not the connection has been fully
quantified. This feature is used if you do not wish to
validate connection state, for example for a router operating in the
center of a large network where such validations would be impossible
to maintain.
However, even though such validations may not be desired you may
still require keep state for the purposes of driving the FAIRQ
ALTQ. FAIRQ depends on keep state to generate the hash codes
identifying the buckets in which it should place packets.
You might also want to use this feature to identify high-bandwidth
connections via the state table for analysis purposes, even at
the center of a large network.
-Matt
