Wiki entry on Element timeouts in NFtables

Wiki entry on Element timeouts in NFtables

[Lars Noodén]

I am unclear on the differences between 'timeout' and 'expires' as
described in the Wiki entry¹ on Element timeouts.

If 'expires' is assigned, but no 'timeout' is given, then what happens?
Will the entry expire regardless of whether additional matching traffic
comes in?  Why do the two examples have 'timeout' with larger values
than the 'expires' in  both?

Thanks,
Lars

¹ https://wiki.nftables.org/wiki-nftables/index.php/Element_timeouts

Re: Wiki entry on Element timeouts in NFtables

[Kerin Millar]

On Sat, 7 Sep 2024, at 7:23 AM, Lars Noodén wrote:
> I am unclear on the differences between 'timeout' and 'expires' as
> described in the Wiki entry¹ on Element timeouts.
>
> If 'expires' is assigned, but no 'timeout' is given, then what happens?

One of three things can happen.

Firstly, if the set was not specified to support stateful elements, the kernel will raise EINVAL and nft(8) will print a rather generic diagnostic message.

Secondly, if the set was specified to support stateful elements and also has a defined 'timeout' value, the element will be added with the specified 'expires' value, but with no 'timeout' value of its own. Note that there is a distinction to be made between the 'timeout' values at set scope and at element scope.

Thirdly, if the set was specified to support stateful elements but has no defined 'timeout' value, the behaviour will be as if 'expires' had not been specified at all and the element will be added a permanent one, if it did not already exists. I consider this behaviour to be a bug because the outcome does not match the user's intent. I think that the kernel should instead raise EINVAL on the basis that the user is requesting for the element to be ephemeral but the request parameters make the request impossible to satisfy.

The set declaration shown in the wiki article contains 'flags timeout', which causes it to support dynamic set elements. However, the set has no 'timeout' value. Therefore, the third case of the aforementioned cases would apply.

> Will the entry expire regardless of whether additional matching traffic
> comes in?

The 'expires' value refers to a timer, the value of which automatically decreases until:

1) it reaches 0
2) a rule is matched which performs 'update @setname' upon the element

In the first case, the element will be removed from the set. In the second case, the 'expires' value will be reset so as to be equal to the 'timeout' value.

> Why do the two examples have 'timeout' with larger values
> than the 'expires' in both?

I do not know why the author of the article decided to present such an example without further explanation. However, it is perfectly legal to add an element where the 'expires' value is lower than the 'timeout' value.

Indeed, consider what happens when listing a ruleset. Unless the -s option is specified, the state of each element will be included in the output. That means that the element states can be persisted and subsequently restored.

# nft list ruleset > ruleset.nft                      # includes states
# { echo flush ruleset; cat ruleset.nft; } | nft -f - # restores states

-- 
Kerin Millar

Re: Wiki entry on Element timeouts in NFtables

[Pablo Neira Ayuso]

Hi,

On Sat, Sep 07, 2024 at 09:23:00AM +0300, Lars Noodén wrote:
> I am unclear on the differences between 'timeout' and 'expires' as
> described in the Wiki entry¹ on Element timeouts.
> 
> If 'expires' is assigned, but no 'timeout' is given, then what happens?
> Will the entry expire regardless of whether additional matching traffic
> comes in?  Why do the two examples have 'timeout' with larger values
> than the 'expires' in  both?

From timeout perspective, there are three type of sets:

1) Sets with no timeout. Adding an element with timeout results in an
   error.

2) Sets with:

        flags timeout

   that is, set supports timeouts but no default set timeout is specified
   in the declaration, in that case, if element is added with no timeout,
   then element never times out. On the other hand, elements that time out
   need an explicit "timeout" option to be used when they are added.

   The set listing always shows "timeout" and "expires" in this case.

3) Sets with default timeout, eg.

        timeout 1h

   In this case, an element that is added with no specific timeout
   uses the default set timeout and the set listing only shows
   "expires" to remove redundant "timeout" information, because
   default set timeout is assumed.

   However, it is possible to override the default set timeout, in that
   case, if element timeout is different than the default set timeout,
   then the set listing shows again both "timeout" and "expires".

   Therefore, "expires" with no "timeout" is only possible in this case,
   because "timeout" is assumed to be the default set timeout.

> ¹ https://wiki.nftables.org/wiki-nftables/index.php/Element_timeouts

Re: Wiki entry on Element timeouts in NFtables

[Pablo Neira Ayuso]

Hi,

Just a few clarification.

On Sun, Sep 08, 2024 at 01:07:44AM +0100, Kerin Millar wrote:
> On Sat, 7 Sep 2024, at 7:23 AM, Lars Noodén wrote:
> > I am unclear on the differences between 'timeout' and 'expires' as
> > described in the Wiki entry¹ on Element timeouts.
> >
> > If 'expires' is assigned, but no 'timeout' is given, then what happens?
> 
> One of three things can happen.
> 
> Firstly, if the set was not specified to support stateful elements, the kernel will raise EINVAL and nft(8) will print a rather generic diagnostic message.
> 
> Secondly, if the set was specified to support stateful elements and also has a defined 'timeout' value, the element will be added with the specified 'expires' value, but with no 'timeout' value of its own. Note that there is a distinction to be made between the 'timeout' values at set scope and at element scope.
> 
> Thirdly, if the set was specified to support stateful elements but has no defined 'timeout' value, the behaviour will be as if 'expires' had not been specified at all and the element will be added a permanent one, if it did not already exists. I consider this behaviour to be a bug because the outcome does not match the user's intent. I think that the kernel should instead raise EINVAL on the basis that the user is requesting for the element to be ephemeral but the request parameters make the request impossible to satisfy.

flags timeout provides a hint to the kernel that element with timeouts
are possible, but default behaviour is "element times out" if not
specified. Forcing the user to provide a timeout does not sound very
flexible to me.

In summary, it is the default set timeout that determines the default
behaviour.

> The set declaration shown in the wiki article contains 'flags timeout', which causes it to support dynamic set elements. However, the set has no 'timeout' value. Therefore, the third case of the aforementioned cases would apply.
> 
> > Will the entry expire regardless of whether additional matching traffic
> > comes in?
> 
> The 'expires' value refers to a timer, the value of which automatically decreases until:
> 
> 1) it reaches 0
> 2) a rule is matched which performs 'update @setname' upon the element
> 
> In the first case, the element will be removed from the set. In the second case, the 'expires' value will be reset so as to be equal to the 'timeout' value.
> 
> > Why do the two examples have 'timeout' with larger values
> > than the 'expires' in both?
> 
> I do not know why the author of the article decided to present such an example without further explanation. However, it is perfectly legal to add an element where the 'expires' value is lower than the 'timeout' value.

Correct. This is to allow to restore a listing that have been
previously saved to disk.

> Indeed, consider what happens when listing a ruleset. Unless the -s option is specified, the state of each element will be included in the output. That means that the element states can be persisted and subsequently restored.
> 
> # nft list ruleset > ruleset.nft                      # includes states
> # { echo flush ruleset; cat ruleset.nft; } | nft -f - # restores states
> 
> -- 
> Kerin Millar
> 

Re: Wiki entry on Element timeouts in NFtables

[Pablo Neira Ayuso]

On Thu, Sep 12, 2024 at 11:35:04AM +0200, Pablo Neira Ayuso wrote:
> On Sun, Sep 08, 2024 at 01:07:44AM +0100, Kerin Millar wrote:
> > On Sat, 7 Sep 2024, at 7:23 AM, Lars Noodén wrote:
[...]
> > Thirdly, if the set was specified to support stateful elements but has no defined 'timeout' value, the behaviour will be as if 'expires' had not been specified at all and the element will be added a permanent one, if it did not already exists. I consider this behaviour to be a bug because the outcome does not match the user's intent. I think that the kernel should instead raise EINVAL on the basis that the user is requesting for the element to be ephemeral but the request parameters make the request impossible to satisfy.
> 
> flags timeout provides a hint to the kernel that element with timeouts
> are possible, but default behaviour is "element times out" if not
> specified. Forcing the user to provide a timeout does not sound very
> flexible to me.

Sorry, wording is not correct:

... are possible, but default behaviour is "element never times out" if not
specified....