Netdev Archive on
help / color / mirror / Atom feed
From: Lukas Wunner <>
To: Daniel Borkmann <>
Cc: John Fastabend <>,
	Pablo Neira Ayuso <>,
	Jozsef Kadlecsik <>,
	Florian Westphal <>,,,, Alexei Starovoitov <>,
	Eric Dumazet <>, Thomas Graf <>,
	Laura Garcia <>,
	David Miller <>
Subject: Re: [PATCH nf-next v3 3/3] netfilter: Introduce egress hook
Date: Sun, 11 Oct 2020 09:59:05 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Sep 08, 2020 at 02:55:36PM +0200, Daniel Borkmann wrote:
> I would strongly prefer something where nf integrates into existing
> tc hook, not only due to the hook reuse which would be better,
> but also to allow for a more flexible interaction between tc/BPF
> use cases
> one option to move forward [...] overall rework of ingress/egress
> side to be a more flexible pipeline (think of cont/ok actions
> as with tc filters or stackable LSMs to process & delegate).

Interaction between netfilter and tc is facilitated by skb->mark.
Both netfilter and tc are able to set and match by way of the mark.
E.g. a netfilter hook may set the mark and tc may later perform an
action if a matching mark is found.

Because the placement of netfilter and tc hooks in the data path
has been unchanged for decades, we must assume that users depend
on their order for setting and matching the mark.

Thus, reworking the data path in the way you suggest (a flexible
pipeline) must not change the order of the hooks.  It would have
to be a fixed pipeline.  But what's the benefit then compared to
separate netfilter and tc hooks which are patched in at runtime
and become NOPs if not used?  (Which is what the present series is
aiming for.)

> to name one example... consider two different entities in the system
> setting up the two, that is, one adding rules for nf ingress/egress
> on the phys device for host fw and the other one for routing traffic
> into/from containers at the tc layer, then traffic going into host ns
> will hit nf ingress and on egress side the nf egress part; however,
> traffic going to containers via existing tc redirect will not see the
> nf ingress as expected but would on reverse path incorrectly
> hit the nf egress one which is /not/ the case for dev_queue_xmit() today.

Using tc to bounce ingress traffic into a container -- is that actually
a thing or is it a hypothetical example?  I think at least Docker uses
plain vanilla routing and bridging to move packets in and out of

However you're right that if tc *is* used to redirect ingress packets
to a container veth, then the data path would look like:

host tc -> container tc -> container nft

Whereas the egress data path would look like:

container nft -> container tc -> host nft -> host tc

But I argue that the egress data path is actually correct because the
host must be able to firewall packets coming out of the container
in case the container has been compromised.

> And if you check a typical DHCP client that is present on major
> modern distros like systemd-networkd's DHCP client then they
> already implement filtering of malicious packets via BPF at
> socket layer including checking for cookies in the DHCP header
> that are set by the application itself to prevent spoofing [0].
> [0]

That's an *ingress* filter so that user space only receives DHCP
packets and nothing else.

We're talking about the ability to filter *egress* DHCP packets
(among others) at the kernel level to guard against unwanted
packets coming from user space.



  parent reply	other threads:[~2020-10-11  7:59 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27  8:55 [PATCH nf-next v3 0/3] Netfilter egress hook Lukas Wunner
2020-08-27  8:55 ` [PATCH nf-next v3 1/3] netfilter: Rename ingress hook include file Lukas Wunner
2020-08-27  8:55 ` [PATCH nf-next v3 2/3] netfilter: Generalize ingress hook Lukas Wunner
2020-08-27  8:55 ` [PATCH nf-next v3 3/3] netfilter: Introduce egress hook Lukas Wunner
2020-08-28 18:52   ` John Fastabend
2020-09-03  5:00     ` John Fastabend
2020-09-04  8:54       ` Laura García Liébana
2020-09-04 15:46         ` John Fastabend
2020-09-05 11:13           ` Laura García Liébana
2020-09-04 16:21       ` Lukas Wunner
2020-09-04 21:14         ` Daniel Borkmann
2020-09-05  5:24           ` Lukas Wunner
2020-09-08 12:55             ` Daniel Borkmann
2020-09-11  7:42               ` Laura García Liébana
2020-09-11 16:27                 ` Daniel Borkmann
2020-09-14 11:29                   ` Laura García Liébana
2020-09-14 22:02                     ` Daniel Borkmann
2020-09-17 10:28                       ` Laura García Liébana
2020-09-18 20:31                         ` Daniel Borkmann
2020-09-19 15:52                           ` Pablo Neira Ayuso
2020-09-21  7:07                           ` Laura García Liébana
2020-10-11  8:26                       ` Lukas Wunner
2020-11-21 18:59                         ` Pablo Neira Ayuso
2020-11-22  3:24                           ` Alexei Starovoitov
2020-11-22 11:01                             ` Pablo Neira Ayuso
2020-11-24  3:34                               ` Alexei Starovoitov
2020-11-24  7:31                                 ` Lukas Wunner
2020-11-24 22:55                                   ` Alexei Starovoitov
2020-10-11  7:59               ` Lukas Wunner [this message]
2020-09-05 11:18           ` Laura García Liébana
2020-09-07 22:11             ` Daniel Borkmann
2020-09-08  6:19               ` Laura García Liébana
2020-09-08 11:46           ` Arturo Borrero Gonzalez
2020-09-08 13:27             ` Daniel Borkmann
2020-09-08 18:58         ` John Fastabend
2020-09-19 15:54   ` Pablo Neira Ayuso
2020-09-28 12:20     ` Lukas Wunner
2020-08-27 10:36 ` [PATCH nf-next v3 0/3] Netfilter " Laura García Liébana
2020-08-28  7:14 ` Daniel Borkmann
2020-08-28  9:14   ` Eric Dumazet

Reply instructions:

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).