Brett Mastbergen <bmastbergen@xxxxxxxxxxxx> wrote: > This patch looks great. That would greatly improve the usefulness of keying > off of the conntrack id. If it gets accepted I can send a kernel patch and > an nft patch to support the ct id key. That would be really nice to have. > > > For a more in depth description of how things work I suggest reading the doc > > > in the first link I posted, but below are a few simple examples of what is > > > possible using dict expressions: > > > > > > nft add rule ip filter forward dict sessions ct id application long_string > > > NETFLIX reject > > > > > > If I were to describe that rule in plain English it would be: > > > > > > For traffic passing through the ip filter table forward hook, use the > > > conntrack id as a key to lookup an entry in the sessions table. For that > > > entry check if it has an application field set to a string value of NETFLIX, > > > if so, reject the traffic. > > > > > > How did that field get set to NETFLIX? That is up to some other entity. In > > > > Why isn't it possible to use the existing nftables set infrastructure > > for this? > > > > The nft sets store arbitrary octets/bytes as keys, so we could at least > > from kernel side store arbitrary identifiers (strings, integers etc). > > > > I wanted to use the existing set infrastructure, but I ran into two issues > wrt to what we were trying to acheive: > > 1. As far as I can tell the current sets are only set up to hold elements > of a particular data type, where as we are storing elements of many different > types in a particular dictionary. Yes, a set is only one data type (They support combining types though). > 2. sets are associated with a particular table and therefore can only be > accessed by rules in that table. If you want to associate some piece of > information with a particular connection and use it from rules in multiple > different tables, you'd have to populate it in a set in each of those tables. Yes, but thats intentional, a table forms a namespace; so crossing it is not desireable. The idea is that different entities each can manage their own tables without clashing with chain or set names of another table. Still looking at dicts code, I am trying to understand where normal nft set infra can't be used (or is too cumbersome) to best understand how we can fit dicts ideas into nftables' architecture.
