On 16-04-19, Florian Westphal wrote: > 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. > I've just sent the kernel, libnftnl, and nft patches that add support for the ct id key to the list. Take a look, see what you think. > > > > 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.
