[Bug 1185] counter flag proposal for sets and maps

[bugzilla-daemon at netfilter.org]

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

--- Comment #7 from Karel Rericha <karel at unitednetworks.cz> ---
(In reply to Pablo Neira Ayuso from comment #6)
> 
> OK, we can do this via anonymous stateful objects, needs to be implemented.
> 
> We can also support it with maps like this, proposed syntax (please suggest
> any better if you like):
> 
>          map m {
>              type inet_service : ipv4_addr, counter;
>          }
>   
> Where the counter is an anonymous stateful object.
> 
> Semantics would be:
> 
> 1) Look up for inet_service key.
> 2) If found, bump counter and then fetch ipv4_addr in the mapping.
> 
> Let me know.

Easy way:
I dont think that extending map definition syntax is good idea. Adding counter
flag seems to be much cleaner and intuitive for this purpose. See my Comment 5.
Semantic would be exactly as you are proposing.

Hard (generic) way:
Let sets, maps, vmaps and flow tables can specify actions if element was hit.
And let this action return accept when we "accept" hit or drop when we "drop"
hit and signal upper levels that element is not there. See syntax:

table x {
    chain y {
        ...
        set s {
            type ipv4_addr . type inet_service; flags action;
        }

        map m {
            type inet_service : ipv4_addr; flags action;
        }
    }
}

# this will count hits of set items (the original idea)
nft add element x s { 192.168.1.1 . 80 counter accept}

# this will hit packets from the start until their payload reaches 50MB
nft add element x s { 192.168.1.2 . 8080 quota 50 mbytes accept}

# this will count packets and hit only first 10 packets per second
nft add element x s { 192.168.1.3 . 22 counter limit rate 10/second accept}

# this will count packets and hit only packets over 10 packets per second
nft add element x s { 192.168.1.4 . 443 counter limit rate 10/second drop}

# this will hit only packets over 10 packets per second and count false hits
(drops)
nft add element x s { 192.168.1.4 . 443 limit rate 10/second count drop}

# same as previous, but for map
nft add element x m { 88: 192.168.1.5 counter limit rate 10/second drop}

Default verdict for action is accept so "accept" keyword is redundant here.

Is is little bit similar like vmaps, but no verdict is used and original
functionality of sets, maps, flows and even vmaps is unchanged.

Seems to me as best idea, but I am not sure if it is worth the effort.


Regarding anonymous stateful objects:
Anonymous stateful objects, which you proposed, are not exactly what I wanted,
but they seems to me as nice thing to have too. And they would fit right into
syntax because we already have anonymous sets, maps, counters, limits etc. So
idea is if we can have anonymous stateful objects bonded to rule, why couldnt
we have anonymous stateful object bonded to map element.

-- 
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/20171017/a15aa7b2/attachment-0001.html>