From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Li To: development@lists.ipfire.org Subject: Re: Enable eBPF XDP/TC kernel feature for IPFire Date: Wed, 17 Apr 2024 15:41:39 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7702473741900297435==" List-Id: --===============7702473741900297435== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable sorry the previous reply might be messed up since gmail alerting me to attach something in the attachment because gmail saw I typed the "attach" word in my reply email, so I copy and pasted the whole email from external text editor. On Wed, Apr 17, 2024 at 3:36=E2=80=AFPM Vincent Li wrote: > > On Wed, Apr 17, 2024 at 9:07=E2=80=AFAM Michael Tremer > wrote: > > > > Hello Vincent, > > > > > On 10 Apr 2024, at 19:01, Vincent Li wrote: > > > > > > On Wed, Apr 10, 2024 at 8:17=E2=80=AFAM Peter M=C3=BCller 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=E2=80=AFAM Adolf Belka 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 h= as a line labelled XDP_TX which completely bypasses the whole Netfilter secti= on 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 ex= act > > >> 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 tr= affic, > > >> 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. > > > > I would like to understand what your need is to use XDP. > > > > As Peter has stated, your system will pass packets with this, but 90% of = the features that IPFire has won=E2=80=99t work any more: > > > > * 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 > > > > 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. > > > > >> 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-tu= ning > > >> 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 > > > > 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. > > > > 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. > > > IPFire uses SYN cookies by default for all incoming connections. We curre= ntly 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. > > > > -Michael > > > > > 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 p= ursuing > > >> this proposal at this time. > > >> > > >> Thanks, and best regards, > > >> Peter M=C3=BCller > > >> > > >>> > > >>>> I don't understand what the difference is between XDP_PASS and XDP_T= X but I would expect that nothing should be allowed to bypass the netfilter s= ection 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 IPFi= re, > > >>>>> please refer to > > >>>>> https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packe= t-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 > > > > --===============7702473741900297435==--