Re: Wiki entry on Element timeouts in NFtables

[Pablo Neira Ayuso <pablo@netfilter.org>]

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
>