-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel,
Thanks very much for your reply and the description of your
algorithm. My apologies for not making my question clear. Let me
rephrase to be more specific.
Given a pf.conf with:
set timeout udp.multiple 2700
set timeout { adaptive.start 6000, adaptive.end 12000 }
Here's a simplistic question:
UDP packet 1 creates state 1 and gets replied to once at time t = 0
sec.
UDP packet 9000 creates state 9000 and gets replied to once at time t
= 100 sec.
UDP packet 12000 creates state 12000 and gets replied to once at time
t = 1400 sec.
UDP packet 1 will expire at:
A) t = 2700 sec
B) t = 1350 sec (2700/2)
UDP packet 9000 expires at:
A) t = 1450
B) t = 1400 (immediately when state 12000 is created)
I know that in reality states are created continuously between
1-12000.
How often does pf check and adjust expiry times for all states?
A) Once, when the state is created
B) All states expirations are checked/adjusted after each state
creation
C) Some other time/state interval (e.g.. every 100 milliseconds, 100
states)
What is the proper syntax to create adaptive timeouts per rule? The
following rule doesn't work in 3.3-stable:
# Allow dnscache out
pass out quick proto udp from $dnscache to any port domain keep state
\
set timeout { adaptive.start 6000, adaptive.end 12000 }
Thank you very much for your detailed answers and, of course, the
best firewall! (Sonic Wall is selling heavily to our campus; I'm
having fun flustering their engineers when they show up for demos.)
***************************
* Adam Getchell [EMAIL PROTECTED]
* System Architect/Programmer (530) 752-1584
* Human Resources Information Systems http://www.hr.ucdavis.edu/
***************************
"Invincibility is in oneself, vulnerability in the opponent." -- Sun
Tzu
> -----Original Message-----
> From: Daniel Hartmeier [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 02, 2003 4:39 PM
> To: Adam Getchell
> Cc: [EMAIL PROTECTED]
> Subject: Re: Adaptive timeouts
>
>
> I'm not sure I understand what you meant exactly. The age of
> a state (the time since it was created) doesn't matter at
> all. Only the number of states does.
>
> The number of states (that exist at the given time) decides
> the scaling factor. As long as the number is lower than
> adaptive.start, the factor is 100%. If it reaches
> adaptive.end, the factor is 0%. In between, the factor
> decreases linearly as the number of states increases. So, in
> the example
>
> > set timeout { adaptive.start 6000, adaptive.end 12000 }
>
> states factor
> 1 100%
> 1000 100%
> 5000 100%
> 6000 100%
> 7500 75%
> 9000 50%
> 10500 25%
> 12000 0%
>
> Each state entry uses a specific base timeout value,
> depending on protocol and condition of the state (like, an
> established TCP connection uses a base value of
> tcp.established, 86400 seconds by default). For each state,
> its particular base value is multiplied by the factor
> calculated above (same factor for all states).
>
> If you specify adaptive.start/.end in a rule (as compared to
> the global settings), the scaling for states created by that
> rule is based on the number of existing states created by
> that rule and the specific start and end values (and the
> total number of states and the global start/end values are
> irrelevant for states created by the rule, only one scaling
> factor gets applied, not both the global and per-rule one).
>
> Maybe it's easier to understand if I describe the algorithm
> which calculates when a given state entry expires (this is
> recalculated whenever an input parameter changed):
>
> 1) does the rule that created the state have its own adaptive.start
> and adaptive.end values?
>
> a) if so, use those two values and the number of states that
> currently exist that were created from the same rule
>
> b) if not, use the global values, and the total number of
> states that currently exist (created by any rule)
>
> 2) calculate the scale factor, based on the number of states, start
> and end, either from a) or b)
>
> 3) check the protocol and condition of state entry to get the
> base timeout value (tcp.first, tcp.opening, tcp.established,
> etc.), note that a rule can also override the global timeout
> values with its own, applying to all states created from the
> rule
>
> 4) multiply the base value with the factor, this is the number
> of seconds that the state entry is kept alive without matching
> a packet
>
> 5) add this number to the last time a packet matched the state,
> this is the time when the state should expire
>
> 6) if that time lies in the past, remove the state
>
> So, the age of a state entry is irrelevant, what matters is
> the last time a packet matched the state. And how many other
> states exist (scale factor). And the base timeout value.
>
> A flood of new connections can't kill existing established
> connections, since they'll get the same scale factor, and
> tcp.first/tcp.opening is much smaller than tcp.established.
> But additional new connections can cause an established
> _idle_ connection to get removed earlier than it would be
> without additional connections. But that's the point :)
>
> HTH,
> Daniel
>
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
iQA/AwUBPwR+Do68FtGOL2f4EQKiRQCg/mn0rmf8u3i6GOFeC6y/A9NnNJIAoOtC
j0bpFeAGvH9yyVL1ZGIAxBZB
=VJH1
-----END PGP SIGNATURE-----
