ipf.conf "age" parameter and kernel timeout values

[Michael T. Davis]

I'm trying to understand what connections there are, if any, between
the values you can set for the age parameter on ipf.conf rules you're using to
keep state (i.e. "... age fwd-secs[/rev-secs]") and the various fr_*time*
kernel variables. These are the values of the IPF kernel variables on my
"stock" NetBSD 5.1 (release) i386 system, per `ipf -T list|grep time'...

fr_tcpidletimeout min 0x1 max 0x7fffffff current 864000
fr_tcptimeout min 0x1 max 0x7fffffff current 480
fr_tcptimewait min 0x1 max 0x7fffffff current 480
fr_udptimeout min 0x1 max 0x7fffffff current 240
fr_udpacktimeout min 0x1 max 0x7fffffff current 24
fr_icmptimeout min 0x1 max 0x7fffffff current 120
fr_icmpacktimeout min 0x1 max 0x7fffffff current 12
fr_iptimeout min 0x1 max 0x7fffffff current 120

Presumably, there's some form of mapping between these variables and
use of the value(s) for the age parameter that go something like this:

...proto tcp...keep state...age... -> fr_tcp*

...proto udp...keep state...age... -> fr_udp*

...proto icmp...keep state...age... -> fr_icmp*

(any other IP-based packet)...age... -> fr_iptimeout

(Related to the last item, can IPFilter [v4.1.29, in particular] actually keep
state for anything other than TCP, UDP, and/or ICMP?) Anyway, I would
appreciate it if someone might clarify this and/or correct it if I'm completely
off-base. Also, are all these values expressed in terms of seconds?

Thanks,
Mike

[Darren Reed]

Post by Michael T. Davis
I'm trying to understand what connections there are, if any, between
the values you can set for the age parameter on ipf.conf rules you're using to
keep state (i.e. "... age fwd-secs[/rev-secs]") and the various fr_*time*
kernel variables. These are the values of the IPF kernel variables on my
"stock" NetBSD 5.1 (release) i386 system, per `ipf -T list|grep time'...
fr_tcpidletimeout min 0x1 max 0x7fffffff current 864000
fr_tcptimeout min 0x1 max 0x7fffffff current 480
fr_tcptimewait min 0x1 max 0x7fffffff current 480
fr_udptimeout min 0x1 max 0x7fffffff current 240
fr_udpacktimeout min 0x1 max 0x7fffffff current 24
fr_icmptimeout min 0x1 max 0x7fffffff current 120
fr_icmpacktimeout min 0x1 max 0x7fffffff current 12
fr_iptimeout min 0x1 max 0x7fffffff current 120
Presumably, there's some form of mapping between these variables and
...proto tcp...keep state...age... -> fr_tcp*
...proto udp...keep state...age... -> fr_udp*
...proto icmp...keep state...age... -> fr_icmp*
(any other IP-based packet)...age... -> fr_iptimeout
(Related to the last item, can IPFilter [v4.1.29, in particular] actually keep
state for anything other than TCP, UDP, and/or ICMP?) Anyway, I would
appreciate it if someone might clarify this and/or correct it if I'm completely
off-base. Also, are all these values expressed in terms of seconds?

The value that you use in the rule will replace those from above with a matching name, as you've rightly guessed.

Darren

[Michael T. Davis]

Post by Michael T. Davis

Post by Michael T. Davis
I'm trying to understand what connections there are, if any, between
the values you can set for the age parameter on ipf.conf rules you're using

to

Post by Michael T. Davis
keep state (i.e. "... age fwd-secs[/rev-secs]") and the various fr_*time*
kernel variables. These are the values of the IPF kernel variables on my
"stock" NetBSD 5.1 (release) i386 system, per `ipf -T list|grep time'...
fr_tcpidletimeout min 0x1 max 0x7fffffff current 864000
fr_tcptimeout min 0x1 max 0x7fffffff current 480
fr_tcptimewait min 0x1 max 0x7fffffff current 480
fr_udptimeout min 0x1 max 0x7fffffff current 240
fr_udpacktimeout min 0x1 max 0x7fffffff current 24
fr_icmptimeout min 0x1 max 0x7fffffff current 120
fr_icmpacktimeout min 0x1 max 0x7fffffff current 12
fr_iptimeout min 0x1 max 0x7fffffff current 120
Presumably, there's some form of mapping between these variables and
...proto tcp...keep state...age... -> fr_tcp*
...proto udp...keep state...age... -> fr_udp*
...proto icmp...keep state...age... -> fr_icmp*
(any other IP-based packet)...age... -> fr_iptimeout
(Related to the last item, can IPFilter [v4.1.29, in particular] actually

keep

Post by Michael T. Davis
state for anything other than TCP, UDP, and/or ICMP?) Anyway, I would
appreciate it if someone might clarify this and/or correct it if I'm

completely

Post by Michael T. Davis
off-base. Also, are all these values expressed in terms of seconds?

The value that you use in the rule will replace those from above with a
matching name, as you've rightly guessed.
Darren

OK, in general this makes sense. Please note that I specified all the
IPF kernel variables that have "time" somewhere in their names, so I don't see
how the age parameter could affect them all. I believe that age actually only
deals with fr_<proto>timeout values, right?

I did a little digging through some old sources and ip_state.c often
used a given base value and then multiplied by two:

#define FIVE_DAYS (2 * 5 * 86400) /* 5 days: half closed connection */

#define TCP_MSL 240 /* 2 minutes */

u_long fr_tcpidletimeout = FIVE_DAYS,
/* [...] */
fr_tcptimeout = 2 * TCP_MSL,
/* [...] */
fr_udptimeout = 240,
fr_icmptimeout = 120;

These values are reflected in the "modern" version of IPF from which the
above values were cited. If the value is expressed in seconds, why the 2x
multiplier? Doesn't this really mean FIVE_DAYS actually represents 10 days?
Or is whatever you're using to track time based on a granularity of 0.5
seconds? If I use the age parameter, I just want to make sure the value(s)
I specify really mean what I think they mean.

Thanks,
Mike

[Saša Nedvědický]

Hi,

Post by Michael T. Davis
Or is whatever you're using to track time based on a granularity of 0.5
seconds?

yes, that's correct, all timeout values are defined in number of ticks.
and there are 2 ticks in 1 second.

regards
sasha

Post by Michael T. Davis

Post by Michael T. Davis

     I'm trying to understand what connections there are, if any, between
the values you can set for the age parameter on ipf.conf rules you're using

to

keep state (i.e. "... age fwd-secs[/rev-secs]") and the various fr_*time*
kernel variables.  These are the values of the IPF kernel variables on my
"stock" NetBSD 5.1 (release) i386 system, per `ipf -T list|grep time'...
fr_tcpidletimeout       min 0x1 max 0x7fffffff  current 864000
fr_tcptimeout   min 0x1 max 0x7fffffff  current 480
fr_tcptimewait  min 0x1 max 0x7fffffff  current 480
fr_udptimeout   min 0x1 max 0x7fffffff  current 240
fr_udpacktimeout        min 0x1 max 0x7fffffff  current 24
fr_icmptimeout  min 0x1 max 0x7fffffff  current 120
fr_icmpacktimeout       min 0x1 max 0x7fffffff  current 12
fr_iptimeout    min 0x1 max 0x7fffffff  current 120
     Presumably, there's some form of mapping between these variables and
 ...proto tcp...keep state...age... -> fr_tcp*
 ...proto udp...keep state...age... -> fr_udp*
 ...proto icmp...keep state...age... -> fr_icmp*
 (any other IP-based packet)...age... -> fr_iptimeout
(Related to the last item, can IPFilter [v4.1.29, in particular] actually

keep

state for anything other than TCP, UDP, and/or ICMP?)  Anyway, I would
appreciate it if someone might clarify this and/or correct it if I'm

completely

off-base.  Also, are all these values expressed in terms of seconds?

The value that you use in the rule will replace those from above with a
matching name, as you've rightly guessed.
Darren

       OK, in general this makes sense.  Please note that I specified all the
IPF kernel variables that have "time" somewhere in their names, so I don't see
how the age parameter could affect them all.  I believe that age actually only
deals with fr_<proto>timeout values, right?
       I did a little digging through some old sources and ip_state.c often
#define FIVE_DAYS (2 * 5 * 86400) /* 5 days: half closed connection */
#define TCP_MSL 240 /* 2 minutes */
u_long fr_tcpidletimeout = FIVE_DAYS,
 /* [...] */
      fr_tcptimeout = 2 * TCP_MSL,
 /* [...] */
      fr_udptimeout = 240,
      fr_icmptimeout = 120;
These values are reflected in the "modern" version of IPF from which the
above values were cited.  If the value is expressed in seconds, why the 2x
multiplier?  Doesn't this really mean FIVE_DAYS actually represents 10 days?
Or is whatever you're using to track time based on a granularity of 0.5
seconds?  If I use the age parameter, I just want to make sure the value(s)
I specify really mean what I think they mean.
Thanks,
Mike