xdp-newbies.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Li <vincent.mc.li@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: xdp-newbies@vger.kernel.org
Subject: Re: Redirect packet back to host stack after AF_XDP?
Date: Mon, 9 Jan 2023 13:28:02 -0800	[thread overview]
Message-ID: <CAK3+h2xVrKPCusUa3B2QT83Sjq0mNU8c31qXTOGid+UOhaQ7SQ@mail.gmail.com> (raw)
In-Reply-To: <87bknh5fxf.fsf@toke.dk>

On Mon, Jan 2, 2023 at 3:34 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Vincent Li <vincent.mc.li@gmail.com> writes:
>
> > On Wed, Dec 14, 2022 at 2:53 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> >>
> >> Vincent Li <vincent.mc.li@gmail.com> writes:
> >>
> >> > Hi,
> >> >
> >> > If I have an user space stack like mTCP works on top of AF_XDP as tcp
> >> > stateful packet filter to drop tcp packet like tcp syn/rst/ack flood
> >> > or other tcp attack, and redirect good tcp packet back to linux host
> >> > stack after mTCP filtering, is that possible?
> >>
> >> Not really, no. You can inject it using regular userspace methods (say,
> >> a TUN device), or using AF_XDP on a veth device. But in both cases the
> >> packet will come in on a different interface, so it's not really
> >> transparent. And performance is not great either.
> >
> > I have thought about it more :) what about this scenario
> >
> >
> > good tcp rst/ack or bad flooding rst/ack -> NIC1 -> mTCP+AF_XDP ->NIC2
> >
> > NIC1 and NIC2 on the same host, drop flooding rst/ack by mTCP,
> > redirect good tcp rst/ack to NIC2, is that possible?
>
> You can do this if NIC2 is a veth device: you inject packets into the
> veth on the TX side, they come out on the other side and from the kernel
> PoV it looks like all packets come in on the peer veth. You'll need to
> redirect packets the other way as well.
>
> > any performance impact?
>
> Yes, obviously :)
>
> >> In general, if you want to filter traffic before passing it on to the
> >> kernel, the best bet is to implement your filtering in BPF and run it as
> >> an XDP program.
> >
> > I am thinking for scenario like tcp rst/ack flood DDOS attack to NIC1
> > above, I can't simply drop every rst/ack because there could be
> > legitimate rst/ack, in this case since mTCP can validate legitimate
> > stateful tcp connection, drop flooding rst/ack packet, redirect good
> > rst/ack to NIC2. I am not sure a BPF XDP program attached to NIC1 is
> > able to do stateful TCP packet filtering, does that make sense to you?
>
> It makes sense in the "it can probably be made to work" sense. Not in
> the "why would anyone want to do this" sense. If you're trying to
> protect against SYN flooding using XDP there are better solutions than
> proxying things through a user space TCP stack. See for instance Maxim's
> synproxy patches:
>

SYN flooding is just one of the example, what I have in mind is an
user space TCP/IP stack runs on top of AF_XDP as middle box/proxy for
packet filtering or load balancing, like F5 BIG-IP runs an user space
TCP/IP stack on top of AF_XDP. I thought open source mTCP + AF_XDP
could be a similar use case as middle box.  user space TCP/IP stack +
AF_XDP as middle box/proxy,  the performance is not going to be good?

> https://lore.kernel.org/r/20220615134847.3753567-1-maximmi@nvidia.com

thanks,  it appears it requires iptables rules setup to work with the
synproxy if I recall correctly

>
> -Toke
>

  reply	other threads:[~2023-01-09 21:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-14 20:49 Redirect packet back to host stack after AF_XDP? Vincent Li
2022-12-14 22:53 ` Toke Høiland-Jørgensen
2022-12-15  1:57   ` Vincent Li
2022-12-15 11:08     ` Toke Høiland-Jørgensen
2022-12-15 18:52       ` Vincent Li
2022-12-17  2:52   ` Vincent Li
2023-01-02 11:33     ` Toke Høiland-Jørgensen
2023-01-09 21:28       ` Vincent Li [this message]
2023-01-10 15:23         ` Toke Høiland-Jørgensen
2023-01-10 16:54           ` Vincent Li
2023-01-10 23:27             ` Toke Høiland-Jørgensen
2023-01-11  0:11               ` Vincent Li

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 \
    --in-reply-to=CAK3+h2xVrKPCusUa3B2QT83Sjq0mNU8c31qXTOGid+UOhaQ7SQ@mail.gmail.com \
    --to=vincent.mc.li@gmail.com \
    --cc=toke@redhat.com \
    --cc=xdp-newbies@vger.kernel.org \
    /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: 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).