netdev - Re: PFCP support in kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 9 Mar 2022 19:16:18 +0100
From:   Harald Welte <laforge@...monks.org>
To:     "Drewek, Wojciech" <wojciech.drewek@...el.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "michal.swiatkowski@...ux.intel.com" 
        <michal.swiatkowski@...ux.intel.com>,
        Marcin Szycik <marcin.szycik@...ux.intel.com>
Subject: Re: PFCP support in kernel

Hi Wojciech,

On Wed, Mar 09, 2022 at 12:27:01PM +0000, Drewek, Wojciech wrote:
> First of all I want to thank you for your revision of our GTP changes,
> we've learned a lot from your comments.

Happy to help!

> So, as you may know our changes were focused around implementing offload of GTP traffic.

Of course, that was what the kernel GTP driver always was about.
Unfortunately it didn't receive a lot of love from the telecom industry,
and hence it is stuck in "2G/3G land", i.e. at a time before the EPS
with its dedicated bearers.  So you cannot use it for IMS/VoLTE, for
example, as it can only match on the source IP address and doesn't have
the capability of using packet classification to put packets in
different tunnels based on [inner IP] port numbers, etc.

> We wanted to introduce a consistent solution so we followed the approach used for geneve/vxlan.
> In general this approach looks like that:
> - create tunnel device (geneve/vxlan/GTP)
> - use that device in tc filter command
> - based on the type of the device used in tc filter, our driver knows what traffic should be offloaded

I'm sorry, I have very limited insight into geneve/vxlan.  It may
be of interest to you that within Osmocom we are currently implementing
a UPF that uses nftables as the backend.  The UPF runs in userspace,
handles a minimal subset of PFCP (no qos/shaping, for example), and then
installs rules into nftables to perform packet matching and
manipulation.  Contrary to the old kernel GTP driver, this approach is
more flexible as it can also cover the TEID mapping case which you find
at SGSN/S-GW or in roaming hubs.  We currently are just about to
complete a prof-of-concept of that.

> Going to the point, now we want to do the same with PFCP. 
> The question is: does it even make sense to create PFCP device and
> parse PFCP messages in kernel space?

I don't think so.  IMHO, PFCP is a rather complex prootocol and it
should be handled in a userspace program, and that userspace program can
then install whatever kernel configuration - whether you want to use
nftables, or tc, or ebpf, or whatever other old or new subsystem in the
kernel network stack.

> My understanding is that PFCP is some kind of equivalent of GTP-C and since GTP-C was purposely not
> implemented in the kernel I feel like PFCP wouldn't fit there either.

I'm sorry, but PFCP is not a replacement of GTP-C.  It serves a rather
different purpose, i.e. to act as protocol between control and user
plane.  GTP-C is control plane, GTP-U is user plane.  PFCP is used in
between the control and user plane entities to configure the user plane.
It's purpose is primarily to be able to mix and match control plane
implementations with user plane implementations. - and to be able to
reuse the same user plane implementation from multiple different network
elements,  like SGW, PGW, HNBGW, roaming hubs, ...

On an abstract / architectural level, PFCP can be compared a bit to
NETLINK:  A protocol between the control plane (linux userspace, routing
daemons, etc.) and the data plane (kernel network stack).

Not sure if there is anything new in it for you, but a while ago in the
osmocom developer call covered CUPS, see the following video recording:
https://media.ccc.de/v/osmodevcall-20211125-laforge-cups-pfcp

> Lastly, if you are wrong person to ask such question then I'm sorry.
> Maybe you know someone else who could help us?

I'm a bit overloaded, but happy to help as far as time permits.

Regards,
	Harald

-- 
- Harald Welte <laforge@...monks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)