Re: Redirect packet back to host stack after AF_XDP?

["Toke Høiland-Jørgensen" <toke@redhat.com>]

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 userspace TCP stack. See for instance Maxim's
synproxy patches:

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

-Toke