[Bug 1471] New: consider quick accept verdict and delayed drop policy

[bugzilla-daemon at netfilter.org]

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

            Bug ID: 1471
           Summary: consider quick accept verdict and delayed drop policy
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: markinholiveira at gmail.com

Considering that nftables allows creation of multiple chains for the same hook,
it would be nice if we were able to make use of this feature in a more
practical way, for accepting and droping packets in different chains according
to its priorities.

So, we could write something like this for accepting a packet without going
through another chains of the same hook:

chain input { 
  type filter hook input priority 0; policy drop;
  ip saddr 10.0.0.1 counter quick-accept;
}


As for delayed drop, we should have an option for dropping packets only after
the last chain of a hook gets processed. So accepted packets in other chains
only get dropped if explicitly match a rule in a chain of higher priority. This
is different from quick accept because packets can still be explicitly dropped.
Something like:

chain input {
  type filter hook input priority 0; policy delayed-drop;
}

Then, packets not matching an accept or drop rule gets dropped immediately
after last input chain. Imo, this could be default and would lead to less
confusion, as seen in #1305.

Implementing something like this would allow for complex chaining to be
achieved easily while using just nftables, but if it was default, we could even
keep iptables for things that still uses it (like libvirt and lxd) and write
our custom rules in nft, knowing that packets allowed by iptables would be
honored by nftables.

For reference, I took the quick accept idea from OpenBSD PF's
(https://www.openbsd.org/faq/pf/filter.html#quick)

-- 
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/20200923/e2f38fe1/attachment-0001.html>