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: Wed, 17 Apr 2024 17:07:26 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7663104600122852301==" List-Id: --===============7663104600122852301== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Vincent, > 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 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 w= hich 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 traffi= c, >> 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. 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 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-tuning >> 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-p= lease/11046/43 Is this only about SYN flooding? > 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. IPFire uses SYN cookies by default for all incoming connections. We currently= do not use the SYNPROXY module, but that is simply because there has not bee= n any demand for it. If this suits your use-case I would rather implement tha= t than XDP. -Michael > 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 pursu= ing >> 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 bu= t I would expect that nothing should be allowed to bypass the netfilter secti= on 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-fl= ow.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%20s= ynproxy%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 --===============7663104600122852301==--