Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: Daniel Borkmann <email@example.com> To: "Laura García Liébana" <firstname.lastname@example.org> Cc: Lukas Wunner <email@example.com>, John Fastabend <firstname.lastname@example.org>, Pablo Neira Ayuso <email@example.com>, Jozsef Kadlecsik <firstname.lastname@example.org>, Florian Westphal <email@example.com>, Netfilter Development Mailing list <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Alexei Starovoitov <email@example.com>, Eric Dumazet <firstname.lastname@example.org>, Thomas Graf <email@example.com>, David Miller <firstname.lastname@example.org> Subject: Re: [PATCH nf-next v3 3/3] netfilter: Introduce egress hook Date: Fri, 18 Sep 2020 22:31:09 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CAF90-Wiof1aut-KoA=uA-T=UGmUpQvZx_ckwY7KnBbYB8Y3+PA@mail.gmail.com> On 9/17/20 12:28 PM, Laura García Liébana wrote: > On Tue, Sep 15, 2020 at 12:02 AM Daniel Borkmann <firstname.lastname@example.org> wrote: >> On 9/14/20 1:29 PM, Laura García Liébana wrote: >>> On Fri, Sep 11, 2020 at 6:28 PM Daniel Borkmann <email@example.com> wrote: >>>> On 9/11/20 9:42 AM, Laura García Liébana wrote: >>>>> On Tue, Sep 8, 2020 at 2:55 PM Daniel Borkmann <firstname.lastname@example.org> wrote: >>>>>> On 9/5/20 7:24 AM, Lukas Wunner wrote: >>>>>>> On Fri, Sep 04, 2020 at 11:14:37PM +0200, Daniel Borkmann wrote: >>>>>>>> On 9/4/20 6:21 PM, Lukas Wunner wrote: >>>>>> [...] >>>>>>>> The tc queueing layer which is below is not the tc egress hook; the >>>>>>>> latter is for filtering/mangling/forwarding or helping the lower tc >>>>>>>> queueing layer to classify. >>>>>>> >>>>>>> People want to apply netfilter rules on egress, so either we need an >>>>>>> egress hook in the xmit path or we'd have to teach tc to filter and >>>>>>> mangle based on netfilter rules. The former seemed more straight-forward >>>>>>> to me but I'm happy to pursue other directions. >>>>>> >>>>>> 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 and nf, to name one >>>>> >>>>> That sounds good but I'm afraid that it would take too much back and >>>>> forth discussions. We'll really appreciate it if this small patch can >>>>> be unblocked and then rethink the refactoring of ingress/egress hooks >>>>> that you commented in another thread. >>>> >>>> I'm not sure whether your comment was serious or not, but nope, this needs >>>> to be addressed as mentioned as otherwise this use case would regress. It >>> >>> This patch doesn't break anything. The tc redirect use case that you >>> just commented on is the expected behavior and the same will happen >>> with ingress. To be consistent, in the case that someone requires both >>> hooks, another tc redirect would be needed in the egress path. If you >>> mean to bypass the nf egress if tc redirect in ingress is used, that >>> would lead in a huge security concern. >> >> I'm not sure I parse what you're saying above ... today it is possible and >> perfectly fine to e.g. redirect to a host-facing veth from tc ingress which >> then goes into container. Only traffic that goes up the host stack is seen >> by nf ingress hook in that case. Likewise, reply traffic can be redirected >> from host-facing veth to phys dev for xmit w/o any netfilter interference. >> This means netfilter in host ns really only sees traffic to/from host as >> intended. This is fine today, however, if 3rd party entities (e.g. distro >> side) start pushing down rules on the two nf hooks, then these use cases will >> break on the egress one due to this asymmetric layering violation. Hence my >> ask that this needs to be configurable from a control plane perspective so >> that both use cases can live next to each other w/o breakage. Most trivial > > Why does it should be symmetric? Fast-paths create "asymmetric > layering" continuously, see: packet hit XDP to user space bypassing > ingress, but in the response will hit egress. So the "breakage" is > already there. Not quite sure what you mean exactly here or into which issue you ran. Either you push the xdp buffer back out from XDP layer for load balancer case so upper stack never sees it, or you push it to upper stack, and it goes through the ingress/egress hooks e.g. from tc side. AF_XDP will bypass either. If you mean the redirect from XDP layer to the veth devs where they have XDP support, then the reply path also needs to operate /below/ netfilter on tc layer exactly for the reason /not/ to break, as otherwise we get potentially hard to debug skb drops on netfilter side when CT is involved and it figures it must drop due to invalid CT state to name one example. That is if there is an opt-in to such data path being used, then it also needs to continue to work, which gets me back to the earlier mentioned example with the interaction on the egress side with that hook that it needs to /interoperate/ with tc to avoid breakage of existing use cases in the wild. Reuse of skb flag could be one option to move forward, or as mentioned in earlier mails 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). Thanks, Daniel
next prev parent reply other threads:[~2020-09-18 20:31 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 [this message] 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 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe 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).