Hi Paul, On Sun, Oct 11, 2020 at 10:09:11PM -0400, Paul Moore wrote: > Harald, Pablo - I know you both suggested taking a slow iterative > approach to merging functionality, perhaps you could also help those > of us on the SELinux side better understand some of the common GTP use > cases? There really only is one use case for this code: The GGSN or P-GW function in the 3GPP network architecture. There are open source implementations like OsmoGGSN and (at least older/previos versions) of ergw, but also non-FOSS-but-shared-source (like OpenAirInterface) and proprietary software that use the existing kernel GTP for that. In a GGSN (2G/3G) or P-GW (4G), you have a control plane instance talking a control plane protocol GTP-C (GTPv1-C or GTPv2-C) with other elements in the network, such as the SGSN (2G/3G) or S-GW (4G) This control plane instance will then talk to the user plane instance (which is, in the case of the kernel GTP module, netlink) to crate PDP contexts (2G/3G) or "barers" (4G). Those PDP contexts / bearers are constantly being created, modified and torn down. Creation happens at the time your modern phone attaches to the network (once you have "mobile data" enabled). Modification happens when you start roaming around the country / coverage area as you change between larger regions. Deletion happens once you disable "mobile data' or go into airplane mode. The kernel GTP "tun" device typically represents an "APN", i.e. one specific IP network your phones/modems want to attach to. There could be multiple in parallel (e.g. public internet, private operator network for VoLTE, company-private networks). So you have one tun device per APN which is mostly static configuration, stable for months, years, ... and then you have the hightly volatile PDP contexts / bearers within each of those APN. That's why I was hinting from a security policy point of view, it makes sense to separate those two, as one only happens at system boot / application start time, and the other happens at any point during runtime of your GGSN/PGW. If you want to see how that looks on the wire, check the OsmoGGSN automatic test suite, where every test case generates a pcap file: overview at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test/ actual artefacts including per-test pcap files: https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test/lastSuccessfulBuild/artifact/logs/ggsn-tester/ specifically, if you open https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test/lastSuccessfulBuild/artifact/logs/ggsn-tester/GGSN_Tests.TC_pdp6_act_deact_gtpu_access.pcap.gz in wirehark and filter on 'gtp', you will see the GTP-C traffic on udp port 2123, and the GTP-U traffic on UDP port 2152. This second part is where you would use the kernel-GTP-U implementation to avoid the kernel-userspace-kernel roundtrip for every user IP packet. There are many other use cases for GTP in general in other network elements such as a S-GW (which basically acts as a proxy for GTP-U), but those are not implemented in the existing Linux kernel GTP module. I think OsmoGGSN is about the most simple to understand user out there, due to its very limited code size. Check https://git.osmocom.org/osmo-ggsn/tree/lib/gtp-kernel.c for the libgtpnl interface and https://git.osmocom.org/osmo-ggsn/tree/ggsn/ggsn.c for the hearth of the logic, including the calls to the gtp_kernel_tunnel_*() API. Hope this helps, Harald -- - Harald Welte <laforge@xxxxxxxxxxxx> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
