netfilter buglog - Jun 2023 - [Bug 1687] New: Define set of set with in ipset list:sets

https://bugzilla.netfilter.org/show_bug.cgi?id=1687

            Bug ID: 1687
           Summary: Define set of set with in ipset list:sets
           Product: nftables
           Version: 1.0.x
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: willyam.android at gmail.com

Is there a plan to implement a list of sets? 

An example of use would be the use of GeoIP lists where I have several lists
(one per country) and use multiple lists in the definition of the source IP in
the rule, example:

ip6 saddr { @FR, @MC, @CH } drop

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230602/c2b05b2c/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1687

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phil at nwl.cc

--- Comment #1 from Phil Sutter <phil at nwl.cc> ---
Not planned per se. If you use anonymous sets, they are merged automatically.
E.g.:

ip saddr { { 1.1.1.1, 2.2.2.2 }, { 3.3.3.3, 4.4.4.4 } }

The example is non-sense, but you may use defines to "refer" to sets
in a rule.

A classic workaround for your example rule though is:

ip6 saddr @FR drop
ip6 saddr @MC drop
ip6 saddr @CH drop

You could put this into a separate chain for convenience.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230602/d64fffaa/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1687

--- Comment #2 from wcts <willyam.android at gmail.com> ---
(In reply to Phil Sutter from comment #1)
> Not planned per se. If you use anonymous sets, they are merged
> automatically. E.g.:
> 
> ip saddr { { 1.1.1.1, 2.2.2.2 }, { 3.3.3.3, 4.4.4.4 } }
> 
> The example is non-sense, but you may use defines to "refer" to
sets in a
> rule.
> 
> A classic workaround for your example rule though is:
> 
> ip6 saddr @FR drop
> ip6 saddr @MC drop
> ip6 saddr @CH drop
> 
> You could put this into a separate chain for convenience.

Right, if i went by example separate per continent, i would have to create
multiples rules. In the ipset we have the type "list", so I ask if
there is any
implementation plan from lists with available in ipset.

I understand that in this example case I could create a list with the multiple
countries that make up the continent. But it would be very useful to reuse the
sets already instanced in nftables and just reference them directly in a single
rule instead of applying multiple rules.

Thanks for attention.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230605/8b284a2a/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1687

--- Comment #3 from Pablo Neira Ayuso <pablo at netfilter.org> ---
You could do this:

define FR = {
        1.1.1.1,
}

define MC = {
        2.2.2.2
}

define CH = {
        3.3.3.3
}

table ip4 filter {
        set geoip {
                type ipv4_addr
                elements = { $FR, $MC, $CH }
        }
}

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230608/169801c6/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1687

--- Comment #4 from wcts <willyam.android at gmail.com> ---
In terms of performance, does it make a difference to use an anonymous or named
list? I ask this because there is a list of a single country with more than
20,000 IP blocks.

Tks for attention

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230612/5f701151/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1687

--- Comment #5 from Phil Sutter <phil at nwl.cc> ---
(In reply to wcts from comment #4)
> In terms of performance, does it make a difference to use an anonymous or
> named list? I ask this because there is a list of a single country with
more
> than 20,000 IP blocks.
Anonymous *sets* as used in a rule like, e.g. 'ip saddr { 1.1.1.1, 2.2.2.2
}'
are implemented internally exactly identical to named sets. The only difference
is they are dropped along with the rule using them, and users have no means of
changing them (obviously).

The kernel chooses a set backend based on different aspects, set size is one of
them. With named sets, one may specify a max size and with anonymous sets the
size is fixed (and known). A small anonymous set may therefore utilize a faster
data structure than a small named one which doesn't specify a max size.

Just for clarification as I'm not sure where to pick you up:

Pablo's example makes use of defines which resolve in user space (i.e., when
parsing input. The three sets FR, MC and CH he defines merge into the geoip
named set before the whole thing is applied in kernel space, creating a single
set containing all the elements.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230613/0a577c4d/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1687

Pablo Neira Ayuso <pablo at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #6 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to Phil Sutter from comment #5)
> Just for clarification as I'm not sure where to pick you up:
> 
> Pablo's example makes use of defines which resolve in user space (i.e.,
when
> parsing input. The three sets FR, MC and CH he defines merge into the geoip
> named set before the whole thing is applied in kernel space, creating a
> single
> set containing all the elements.
No plans to support for this multi-lookup feature.

If you would like to know what country this IP belongs to, then you could
combine this with mark.

define FR = {
        1.1.1.1 : 1,
}

define MC = {
        2.2.2.2 : 2,
}

define CH = {
        3.3.3.3 : 3,
}

table ip filter {
        map geoip {
                type ipv4_addr : mark
                elements = { $FR, $MC, $CH }
        }
}

In this example above, mark 1 corresponds to FR, mark 2 to MC and mark 3 to CH.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230913/851f70e6/attachment.html>