Re: Enable eBPF XDP/TC kernel feature for IPFire

[Vincent Li <vincent.mc.li@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4481 bytes --]

On Wed, Apr 10, 2024 at 8:17 AM Peter Müller <peter.mueller(a)ipfire.org> wrote:
>
> Hello Vincent,
>
> thank you for your e-mail and the proposal.
>
> > Hi Adolf,
> >
> > Please see  my reply inline
> >
> > On Wed, Apr 10, 2024 at 2:04 AM Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> >>
> >> Hi Vincent,
> >>
> >> I am not very familiar at all with this type of stuff but one thing that I noticed is that in the image you provided a link to, the XDP section has a line labelled XDP_TX which completely bypasses the whole Netfilter section which doesn't seem to be a good idea to me.
> >>
> > XDP_TX is to redirect the packet out after processing the packet at
> > XDP stage, yes, netfilter will not see these packets.
> >  for example for DDoS SYN flood attack scenario, when the SYN packet
> > is received, XDP program can generate SYN+ACK with syncookie and send
> > the SYN+ACK out, netfilter/Linux tcp stack knows nothing about it,
> > which actually saves host CPU cycles to process the SYN in
> > netfilter/TCP stack, which is actually good thing.
> >
> > Also, XDP_DROP, XDP_PASS, XDP_TX action is depending on the XDP
> > program attached to the network interface, so it is the XDP program
> > author decide what to do with the packet, if no XDP program attached
> > to the network interface, everything works as usual, no interference
> > from XDP.
>
> If my understanding of this is correct, then this would lead to the exact
> opposite of what IPFire is designed to do. Rather than having packets
> processed below any level of operating system influence, the objective of
> IPFire in particular and firewalls in general is to control network traffic,
> which inherently requires thorough visibility on it.

Kernel  still has the traffic statistics processed by XDP program and
store in eBPF maps so the user space program can query and view. you
can still view XDP as part of the firewall except it processes packets
early at the driver layer for efficiency.

>
> As far as I am aware, IPFire is currently able to handle 25 GBit/sec. on
> the right hardware, and SYN flooding attacks are not a major threat to
> IPFire users, given that we have historically implemented some fine-tuning
> to make such attacks less viable.

DDoS attacks to  IPFire users do not happen now does not mean it will
not happen in the future, SYN flood is just one scenario, so better be
prepared than sorry later :) One IPFire user had asked for help
https://community.ipfire.org/t/filter-out-ddos-attacks-anyone-can-help-me-please/11046/43

I have studied IPFire, I do not see relevant SYN flooding or DDoS
tuning, where is it?  netfilter with SYNPROXY module? or the TCP stack
syncookie implementation, or  suricata ddos rules...etc? keep in mind
all these are handled in software, no hardware acceleration.

Why not give  IPFire users the options when the options already exist
in the IPFire kernel?

>
> Therefore, I - personally - neither see the necessity nor benefit of pursuing
> this proposal at this time.
>
> Thanks, and best regards,
> Peter Müller
>
> >
> >> I don't understand what the difference is between XDP_PASS and XDP_TX but I would expect that nothing should be allowed to bypass the netfilter section unless it is being dropped or rejected already by the XDP process.
> >>
> >
> > XDP_PASS is to pass the packet to netfilter/TCP stack as usual after
> > XDP program packet processing, XDP_TX is to redirect the packet back
> > out through the same network interface after XDP program packet
> > processing.
> >
> >> Regards,
> >>
> >> Adolf.
> >>
> >> On 09/04/2024 19:36, Vincent Li wrote:
> >>> Hi,
> >>>
> >>> I have been working on enabling eBPF XDP/TC kernel feature for IPFire,
> >>> please refer to
> >>> https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
> >>> for where XDP fit in Linux network datapath, XDP will not interfere
> >>> with existing IPFire firewall rules. XDP is especially good at DDoS
> >>> packet filtering at high speed, see
> >>> https://netdevconf.info/0x15/slides/30/Netdev%200x15%20Accelerating%20synproxy%20with%20XDP.pdf
> >>>
> >>> I think we only need to enable XDP/TC network filtering capability
> >>> without eBPF tracing capability which some users are concerned about
> >>> potential host security information leaks.
> >>>
> >>> Please let me know what you think, thanks!
> >>>
> >>> Vincent