From: Daniel Borkmann <email@example.com>
To: Pablo Neira Ayuso <firstname.lastname@example.org>
Cc: Lukas Wunner <email@example.com>,
Jozsef Kadlecsik <firstname.lastname@example.org>,
Florian Westphal <email@example.com>,
firstname.lastname@example.org, Martin Mares <email@example.com>,
Dmitry Safonov <firstname.lastname@example.org>,
Thomas Graf <email@example.com>, Alexei Starovoitov <firstname.lastname@example.org>,
David Miller <email@example.com>
Subject: Re: [PATCH nf-next 3/3] netfilter: Introduce egress hook
Date: Sat, 14 Mar 2020 01:12:02 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 3/13/20 3:55 PM, Pablo Neira Ayuso wrote:
> On Wed, Mar 11, 2020 at 03:05:16PM +0100, Daniel Borkmann wrote:
>> On 3/11/20 12:59 PM, Lukas Wunner wrote:
>>> Commit e687ad60af09 ("netfilter: add netfilter ingress hook after
>>> handle_ing() under unique static key") introduced the ability to
>>> classify packets on ingress.
>>> Allow the same on egress. Position the hook immediately before a packet
>>> is handed to tc and then sent out on an interface, thereby mirroring the
>>> ingress order. This order allows marking packets in the netfilter
>>> egress hook and subsequently using the mark in tc. Another benefit of
>>> this order is consistency with a lot of existing documentation which
>>> says that egress tc is performed after netfilter hooks.
>>> Egress hooks already exist for the most common protocols, such as
>>> NF_INET_LOCAL_OUT or NF_ARP_OUT, and those are to be preferred because
>>> they are executed earlier during packet processing. However for more
>>> exotic protocols, there is currently no provision to apply netfilter on
>>> egress. A common workaround is to enslave the interface to a bridge and
>> Sorry for late reply, but still NAK.
> I agree Lukas use-case is very specific.
> However, this is useful.
> We have plans to support for NAT64 and NAT46, this is the right spot
> to do this mangling. There is already support for the tunneling
But why is existing local-out or post-routing hook _not_ sufficient for
NAT64 given it being IP based?
> infrastructure in netfilter from ingress, this spot from egress will
> allow us to perform the tunneling from here. There is also no way to
> drop traffic generated by dhclient, this also allow for filtering such
> locally generated traffic. And many more.
This is a known fact for ~17 years  or probably more by now and noone
from netfilter folks cared to address it in all the years, so I presume
it cannot be important enough, and these days it can be filtered through
other means already. Tbh, it's a bit laughable that you bring this up as
an argument ...
> Performance impact is negligible, Lukas already provided what you
> asked for.
Sure, and the claimed result was "as said the fast-path gets faster, not
slower" without any explanation or digging into details on why this might
be, especially since it appears counter-intuitive as was stated by the
author ... and later demonstrated w/ measurements that show the opposite.
next prev parent reply other threads:[~2020-03-14 0:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 11:59 [PATCH nf-next 0/3] Netfilter egress hook Lukas Wunner
2020-03-11 11:59 ` [PATCH nf-next 1/3] netfilter: Rename ingress hook include file Lukas Wunner
2020-03-11 11:59 ` [PATCH nf-next 2/3] netfilter: Generalize ingress hook Lukas Wunner
2020-03-11 11:59 ` [PATCH nf-next 3/3] netfilter: Introduce egress hook Lukas Wunner
2020-03-11 14:05 ` Daniel Borkmann
2020-03-11 15:54 ` Lukas Wunner
2020-03-12 22:40 ` Daniel Borkmann
2020-03-13 14:55 ` Pablo Neira Ayuso
2020-03-14 0:12 ` Daniel Borkmann [this message]
2020-03-15 13:28 ` Pablo Neira Ayuso
2020-04-23 14:44 ` Laura Garcia
2020-04-23 16:05 ` Lukas Wunner
2020-04-27 23:44 ` Pablo Neira Ayuso
2020-04-28 20:11 ` Daniel Borkmann
2020-08-20 10:37 ` Lukas Wunner
2020-08-20 16:35 ` Lukas Wunner
2020-03-18 0:21 ` [PATCH nf-next 0/3] Netfilter " Pablo Neira Ayuso
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).