From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Enable eBPF XDP/TC kernel feature for IPFire Date: Thu, 18 Apr 2024 09:57:53 +0100 Message-ID: <6BD0D6A5-FCD2-4A3A-950F-3058AC35B509@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2152211896696880251==" List-Id: --===============2152211896696880251== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 17 Apr 2024, at 23:36, Vincent Li wrote: >=20 > On Wed, Apr 17, 2024 at 9:07=E2=80=AFAM Michael Tremer > wrote: >>=20 >> Hello Vincent, >>=20 >>> On 10 Apr 2024, at 19:01, Vincent Li wrote: >>>=20 >>> On Wed, Apr 10, 2024 at 8:17=E2=80=AFAM Peter M=C3=BCller wrote: >>>>=20 >>>> Hello Vincent, >>>>=20 >>>> thank you for your e-mail and the proposal. >>>>=20 >>>>> Hi Adolf, >>>>>=20 >>>>> Please see my reply inline >>>>>=20 >>>>> On Wed, Apr 10, 2024 at 2:04=E2=80=AFAM Adolf Belka wrote: >>>>>>=20 >>>>>> Hi Vincent, >>>>>>=20 >>>>>> I am not very familiar at all with this type of stuff but one thing th= at 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. >>>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> 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 traf= fic, >>>> which inherently requires thorough visibility on it. >>>=20 >>> 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. >>=20 >> I would like to understand what your need is to use XDP. >>=20 >> As Peter has stated, your system will pass packets with this, but 90% of t= he features that IPFire has won=E2=80=99t work any more: >>=20 >> * Connection Tracking won=E2=80=99t be up to date >> * QoS won=E2=80=99t be able to categorise packets correctly and won=E2=80= =99t be able to do its job >> * The IPS won=E2=80=99t be able to inspect any data >>=20 >=20 > I think I did not explain the XDP use case clearly, for now, most XDP > use cases and particularly my use case is to do DDoS protection at > the earliest packet receiving path in high efficiency since XDP works > inside the network driver. the things you mentioned above would work > fine even if the packets go through XDP program, yes XDP program can > drop, modify, reflect the packet, but in non-DDoS packet senario, XDP > simply passes the packet to Linux as if nothing happened. so it is up > to the XDP program logic, also even if ipfire has the kernel feature > enabled, users still need to attach XDP program to the interface, if > no XDP program is attached to the interface, nothing is in the way to > stop packet flowing to IPfire filtering. > Again this diagram is great to describe the packet path > https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.s= vg, > so the XDP_PASS action from XDP program is to pass packet to Linux as > usual. from the same diagram, you also see "AF_PACKET", right? that is > where tcpdump taking place to capture packet for network > troubleshooting, but tcpdump would not stops all the scenario above > you mentioned working, actually tcpdump is based on classic BPF > technology, the XDP/eBPF is to extended classic BPF technology, it not > only can clone (packet capture), but can also drop, redirect. Please > read more about eBPF/XDP in general if you would like, many online > resources explain better than me :) > Those three are just a few, but > they are commonly used features of IPFire and without them, it would > not be what it is. Thank you. I am very familiar with how Netfilter works, including BPF and XDP. I think your diagram just proves my point when I say that everything is going= to bypass the OS. That is the long arrow at the bottom. At least I am assuming that you are interested in forwarding packets instead = of going the =E2=80=9CXDP_PASS=E2=80=9D route, because for that you don=E2=80= =99t need XDP? I think you still haven=E2=80=99t explained what your goal is on a lower leve= l. DoS protection is incredibly broad and that does not strictly require XDP.= What kind of XDP program are you interested in using? >>=20 >>>> 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-tuni= ng >>>> to make such attacks less viable. >>>=20 >>> 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 >>=20 >> Is this only about SYN flooding? >> for layer 4 TCP DDoS, the most common scenario is SYN flooding, ACK floodi= ng, RST flooding. all these flooding can be stopped by SYN cookie that is alr= eady built in the Linux TCP host stack, but IPFire is a middle box firewall, = the packet destination endpoint is not IPFire, but the host/green network por= t forwarded by IPFire, so that is where the netfilter SYNPROXY module plays i= n, I don't see SYNPROXY module being referenced anywhere in IPFire, so even w= ithout XDP, I still recommend IPFire provides user option to use SYNPROXY for= TCP SYN/ACK/RST flood attack >>> 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. >>=20 >> Yes, IPFire runs in software. We cannot use hardware acceleration because = it is designed to pass packets and not to do what we are doing here. > hardware acceleration probably is not the right word here for XDP > because XDP is actually still in the software driver, not inside the > hardware, though there is one hardware vendor that supports running > XDP byte code inside the hardware itself for true hardware > acceleration, but that is not common. again XDP does not interfere > with the IPfire filter except in DDoS scenarios, users can have the > option to drop the packet early in the network driver without > consuming IPfire CPU/memory resource. > But do you have any kind of system out there that is under constant fire and = the OS cannot cope? What kind of packet rates or bandwidth are we talking abo= ut? >> IPFire uses SYN cookies by default for all incoming connections. We curren= tly do not use the SYNPROXY module, but that is simply because there has not = been any demand for it. If this suits your use-case I would rather implement = that than XDP. > home users very unlikely would have this demand because there isn't > much gain for attackers who would use DDoS to attack home users. For > small/medium size businesses, attackers could start DDoS because > business could be impacted and lose profit when under DDoS attack, > many businesses choose cloud DDoS providers if they could not afford > DDoS protection devices. XDP DDoS protection on IPFire provides DDoS > protection on inexpensive commodity hardware. There are already a lot > of open source XDP programs out there, including XDP SYNCookie from > Linux kernel source, I have ported it to xdp-tool repo and ported > xdp-tool to IPfire. Maybe share this code on the list here so that people understand better what = you are looking for. I am still not sure what kind of changes you are asking us to make. -Michael >>=20 >> -Michael >>=20 >>> Why not give IPFire users the options when the options already exist >>> in the IPFire kernel? >>>=20 >>>>=20 >>>> Therefore, I - personally - neither see the necessity nor benefit of pur= suing >>>> this proposal at this time. >>>>=20 >>>> Thanks, and best regards, >>>> Peter M=C3=BCller >>>>=20 >>>>>=20 >>>>>> 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 sec= tion unless it is being dropped or rejected already by the XDP process. >>>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>>>>>=20 >>>>>> On 09/04/2024 19:36, Vincent Li wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> 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%2= 0synproxy%20with%20XDP.pdf >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Please let me know what you think, thanks! >>>>>>>=20 >>>>>>> Vincent --===============2152211896696880251==--