PaperlayerView exact revision on arXiv

Source-linked AI summary

Line-Rate GTP-U Admission Control at the Edge of a Cloud-Native 5G Core: An XDP-Based Design for Kubernetes-Hosted User Plane Functions

Simhadri Podala Narasimha

arXiv:2610.02296v1cs.NI

TL;DR

The UPF’s N3 ingress is exposed to tunnel-traffic threats, while cloud-native deployment complicates reliance on kernel-bypass frameworks. GTP-Guard designs a PFCP-aware XDP admission layer for Kubernetes-hosted UPFs; its stage-ordering and deployment approach are presented without measured results in this version.

  • Problem

    The UPF’s N3 ingress accepts traffic from a large population of gNBs and peer UPFs, making it a target for floods, TEID scanning, spoofed inner sources, and GTP-in-GTP injection.

    Source: §I · p. 1

  • Method

    GTP-Guard uses an XDP admission pipeline to validate GTP-U traffic against PFCP-derived session state before packets reach the UPF.

    Source: §I · p. 1, §IX · p. 6

  • Results

    The paper presents the admission-layer design and evaluation methodology, while measured results are deferred to a later version.

    Source: §I · p. 1

  • Takeaways & Limitations

    The stage-ordering result provides a basis for reconfiguring the pipeline when traffic shifts under attack.

    Source: §IX · p. 6

    GTP-Guard does not inspect payloads, enforce full PDR precedence, or apply downlink policy on N6.

    Source: §VIII · p. 6

Abstract

from arXiv · show

The User Plane Function (UPF) of a 5G Standalone core terminates every GPRS Tunnelling Protocol user-plane (GTP-U) packet arriving from the radio access network, which makes its N3 interface both the busiest and the most exposed point of the mobile data path. As operators migrate the core onto Kubernetes and public cloud, the UPF increasingly shares a general-purpose Linux kernel with other workloads, and kernel-bypass frameworks such as DPDK become harder to operate. This paper presents GTP-Guard, a design for line-rate GTP-U admission control built on the eXpress Data Path (XDP) hook of the Linux kernel. GTP-Guard drops illegitimate tunnel traffic in the network driver, before socket-buffer allocation, using six ordered stages: peer allow-listing, GTP-U header validation, Tunnel Endpoint Identifier (TEID) admission against session state derived from the Packet Forwarding Control Protocol (PFCP), bounded extension-header parsing, inner-packet anti-spoofing with GTP-in-GTP detection, and per-session policing. We formalize stage ordering as a cost-minimization problem and show that sorting stages by the ratio of per-packet cost to rejection probability minimizes expected per-packet work, which motivates run-time reordering through tail-call program arrays when traffic mix shifts under attack. We further describe a Kubernetes deployment model based on a node-level DaemonSet with pinned eBPF maps that survive agent upgrades, discuss constraints specific to public-cloud virtual NICs, and define a reproducible evaluation methodology, with explicit hypotheses, for throughput, latency, CPU efficiency and attack resilience. This paper presents the design and methodology; experimental results will be reported in a subsequent version.

I. INTRODUCTION

The UPF’s N3 ingress faces tunnel-traffic threats, while cloud-native operations make kernel-bypass frameworks a poor fit. The paper introduces GTP-Guard as an XDP admission layer and explains the receive-path hook it builds on.

I. INTRODUCTION

  • A UPF forwards traffic between the RAN and external data networks, and its N3 ingress faces floods, TEID scanning, spoofed inner sources, and GTP-in-GTP injection.The UPF receives uplink traffic encapsulated in GTP-U over UDP port 2152 and is programmed over N4 using PFCP.Source: §I · p. 1
  • Although XDP has been used for in-kernel UPFs and GTP-U-aware receive-side scaling –, less attention has gone to admission control in front of an existing UPF.This gap matters in cloud-native operations, where Kubernetes components and public-cloud virtual NICs assume the kernel owns the device.Source: §I · p. 1
  • GTP-Guard is a six-stage XDP pipeline that checks GTP-U traffic against PFCP-derived session state and drops illegitimate packets in the driver.The paper also contributes a stage-ordering cost model, a Kubernetes deployment model, and a reproducible evaluation methodology; measured results are deferred.Source: §I · p. 1

A. eBPF and the XDP Hook

  • eBPF programs use maps to share state with user space, while XDP runs in the driver receive path and can drop frames before socket-buffer allocation.An earlier evaluation reported roughly 24 Mpps for single-core XDP packet dropping.Source: A. eBPF and the XDP Hook · pp. 1–2

B. Attach Modes and AF XDP

The paper describes XDP attach modes and AF XDP as the hand-off to user-space UPFs. It places GTP-Guard among prior XDP work on 5G user planes while distinguishing its UPF-agnostic admission-control role.

B. Attach Modes and AF XDP

  • Native XDP runs in the driver, generic mode works on interfaces such as veth but loses most performance benefit, and offload runs on capable SmartNICs.AF XDP can redirect selected frames to user-space memory; GTP-Guard uses it to hand packets to user-space UPFs while filtering remains in XDP.Source: B. Attach Modes and AF XDP · p. 2

C. The 5G User Plane and GTP-U

  • The GTPv1-U header contains a TEID, and N3 commonly sets the E bit for the PDU Session Container carrying the QFI; PFCP supplies the UPF’s valid TEIDs, UE addresses, and QERs.User data uses message type 255 (G-PDU), while signalling messages include Echo Request/Response, Error Indication, and End Marker.Source: C. The 5G User Plane and GTP-U · p. 2

III. RELATED WORK

  • Prior work includes XDP data planes, Kubernetes networking, and 5G UPF implementations –,, –[19]; GTP-Guard instead places a UPF-agnostic admission layer in front of existing UPFs.Its stated focus includes stage ordering, run-time adaptation, and cloud-native lifecycle concerns.Source: §III · p. 2

IV. THREAT MODEL

The threat model considers packet injection toward the UPF’s N3 or N9 address from several reachable sources. It trusts N4 and Kubernetes control, and excludes attacks that saturate the physical link before the host.

IV. THREAT MODEL

  • The adversary may inject packets from a compromised or misconfigured RAN node, a subscriber crafting packets inside its tunnel, or another reachable transport-network segment.The target addresses are the UPF’s N3 or N9 addresses.Source: §IV · p. 2
  • The model assumes that the N4 control channel and Kubernetes control plane are trusted.This trust boundary is part of the stated threat model.Source: §IV · p. 2
  • Attacks on PFCP itself, encrypted-payload attacks, and denial of service saturating the physical link before the host are out of scope.Physical-link saturation must be absorbed upstream.Source: §IV · p. 2

V. GTP-GUARD DESIGN

GTP-Guard is designed to drop rejected packets early, remain UPF-agnostic, derive session state from PFCP, and support Kubernetes operations. Its pipeline classifies GTP-U traffic through ordered checks before redirecting admitted packets.

A. Design Goals

  • The design goals are early drops, UPF-agnostic protection, PFCP-derived session state with pass-through on guard failure, and Kubernetes operability.The stated operational goals include declarative configuration, rolling upgrades, and Prometheus-native telemetry.Source: A. Design Goals · pp. 2–3

B. Pipeline

  • Non-IPv4/UDP frames not addressed to port 2152 pass immediately, then the peer allow-list checks the outer source and header validation checks GTP-U version and protocol type.Non-G-PDU messages pass to the UPF unmodified.Source: B. Pipeline · p. 3
  • TEID admission drops packets whose TEID is absent from the map of current uplink PDRs, and a bounded extension-header walk rejects overlong chains or frame overruns.The bounded walk accommodates the PDU Session Container used on N3.Source: B. Pipeline · p. 3
  • Inner checks require the source address to match the UE address bound to the TEID and drop inner UDP traffic addressed to port 2152 as GTP-in-GTP injection.These checks target spoofed subscriber addresses and tunnel-in-tunnel traffic.Source: B. Pipeline · p. 3
  • A token bucket keyed by QER index enforces a per-session ceiling, after which admitted packets are redirected to AF XDP or passed to the kernel stack.The AF XDP path applies when the UPF is an AF XDP application; otherwise, bpf_redirect_map provides the XDP_PASS fallback.Source: B. Pipeline · p. 3

C. State Model and Control-Plane Synchronization

GTP-Guard combines operator-managed peer allow-listing, PFCP-derived session state, and data-plane policing state. A user-space agent synchronizes session entries and uses consistency checks to favor availability when state cannot be trusted.

C. State Model and Control-Plane Synchronization

  • Session entries map each TEID to a compact record containing the UE IPv4 address, an IPv6 prefix, and a QER index.The agent translates PFCP Session Establishment, Modification, and Deletion into map updates, preferably from UPF-exported lifecycle events rather than re-parsing N4.Source: C. State Model and Control-Plane… · p. 3
  • Insert-before-use and delete-after-drain keep entries aligned with session signaling while avoiding penalties to in-flight uplink packets.Updates within the PFCP round trip satisfy insert-before-use; removal follows acknowledged session deletion.Source: C. State Model and Control-Plane… · p. 3
  • A watchdog compares map cardinality with the UPF session count and switches to pass-through if drift exceeds a threshold.This favors availability over filtering when session state cannot be trusted.Source: C. State Model and Control-Plane… · p. 3

D. Stage Ordering

Stage ordering minimizes expected packet-processing cost by placing inexpensive, high-rejection tests early, with runtime reordering available when attack traffic changes the mix. Per-session policing uses per-CPU buckets and can redirect packets by TEID when outer-header hashing provides too little entropy.

D. Stage Ordering

  • Expected per-packet cost is minimized by ordering stages by ascending cost-to-rejection-probability ratio, r_i = c_i/(1 − p_i).Here c_i is stage cost and p_i is the probability a packet reaching that stage is forwarded.Source: D. Stage Ordering · p. 3
  • A TEID-scanning flood makes S3 reject most traffic while S1 rejects almost none, so runtime reordering can improve the order despite lookup cost.The agent estimates forwarding probabilities from counters and rewrites tail-call program-array slots; it uses a fused program in steady state and switches when drop rates cross a threshold.Source: D. Stage Ordering · p. 3

E. Policing and Receive-Side Scaling

VI. CLOUD-NATIVE DEPLOYMENT ON KUBERNETES

GTP-Guard runs as a node-level DaemonSet, with pinned eBPF objects preserving filtering and session state across agent restarts and upgrades. Interface attachment differs between SR-IOV-based clusters and public-cloud nodes.

A. Packaging and Lifecycle

  • A node-affinity DaemonSet loads one CO-RE object across kernel versions, and reopening pinned maps and links preserves filtering and session state across agent restarts.Program upgrades atomically replace the attached link; libxdp can chain other XDP programs with defined priorities.Source: A. Packaging and Lifecycle · p. 4

B. Interface Attachment

  • For SR-IOV interfaces, native XDP attaches in the host namespace before VF movement or inside the pod via an init container; the latter couples guard lifecycle to the UPF.On public cloud, the guard attaches in the host namespace to the node's dedicated elastic network interface.Source: B. Interface Attachment · p. 4

C. Privilege Scoping

GTP-Guard confines privileged operations to its agent and accounts for cloud NIC constraints that can affect native XDP attachment and capacity. The evaluation methodology treats cycles per packet as its primary efficiency metric.

C. Privilege Scoping

  • The agent holds CAP_BPF and CAP_NET_ADMIN privileges, while the UPF remains unprivileged on the kernel path and map access is restricted.Older kernels require CAP_SYS_ADMIN; telemetry is exposed through an unprivileged sidecar.Source: C. Privilege Scoping · p. 4

D. Public-Cloud NIC Considerations

  • Cloud NIC support may require reduced MTU, limited queues, or specific buffer sizes, and generic-mode fallback can silently forfeit most performance benefits.The agent requests native mode and alerts rather than silently accepting generic mode, exports attach-mode and per-queue metrics, and plans around provider packet-rate limits.Source: D. Public-Cloud NIC Considerations · p. 4

A. Per-Packet Budget

  • At 3 GHz, sustaining 14.88 Mpps on one core allows about 200 cycles per packet; cycles per packet is the primary efficiency metric.The methodology reports both packet and bit rates because attack traffic need not use realistic packet sizes.Source: A. Per-Packet Budget · p. 4

B. Testbed and Workloads

The evaluation pairs a reference GTP-U testbed with a public-cloud Kubernetes profile and tests benign traffic, attack traffic, and PFCP session churn.

B. Testbed and Workloads

  • The reference testbed combines a stateless GTP-U traffic generator, a native-XDP-capable device under test, an open-source 5G core, and session-establishment tools; a second profile uses managed public-cloud Kubernetes.The device under test runs a recent long-term-support kernel; the UPF can use kernel or AF XDP mode.Source: B. Testbed and Workloads · p. 4
  • Workloads cover benign traffic with 10^4–10^6 active TEIDs, random-TEID scans, forged inner sources on valid TEIDs, and GTP-in-GTP datagrams.The scan adds random-TEID G-PDUs to benign background traffic at rates up to line rate.Source: B. Testbed and Workloads · pp. 4–5
  • The churn workload increases PFCP establishment and deletion rates while measuring map-update latency and insert-before-use violations.The condensed IPv4 program’s drop() function increments a per-CPU reason counter before returning XDP_DROP.Source: B. Testbed and Workloads · p. 5, Figure 2 · p. 5

C. Baselines and Metrics

The evaluation compares filtering baselines across throughput, drop capacity, efficiency, latency, CPU use, and false drops; the discussion identifies verifier, fragmentation, state, kernel-trust, and filtering-scope constraints.

C. Baselines and Metrics

  • The baselines are no filtering, equivalent nftables rules, generic GTP-Guard, native fused GTP-Guard, and native adaptive ordering, assessed with throughput, per-core drop capacity, cycles per packet, latency, attack CPU use, and false-drop rate.Table III’s literature performance figures are context only, not directly comparable because hardware and pipelines differ.Source: C. Baselines and Metrics · p. 5, Table III · p. 6

VIII. DISCUSSION AND LIMITATIONS

  • Verifier limits on stack size, bounded loops, and instruction complexity require bounded parsing; tail-called stages help keep verification cost manageable.IPv6 inner packets with extension headers need a separately bounded parser.Source: §VIII · p. 5
  • The Kubernetes agent manages program lifecycle and map population, while the XDP program and maps persist across agent restarts.Source: Figure 3 · p. 6
  • Outer IP fragments cannot be validated in XDP, so GTP-Guard passes them to the stack for reassembly before the UPF.The transport MTU should be engineered to avoid N3 fragmentation in normal operation.Source: §VIII · p. 6
  • Stale PFCP-derived session state can make TEID misses black-hole legitimate traffic; operators should monitor insert-to-first-packet latency before enabling strict mode.A watchdog and pass-through flag bound the impact of state divergence.Source: §VIII · p. 6
  • XDP improves UPF isolation from hostile traffic but enlarges the node’s trusted computing base, so loading should be limited to one audited agent.The paper recommends program signing where the platform supports it.Source: §VIII · p. 6
  • GTP-Guard does not inspect payloads, enforce full PDR precedence, or apply downlink policy on N6.The N6 policy could reuse the framework with a UE-address-keyed map.Source: §VIII · p. 6

IX. CONCLUSION AND FUTURE WORK

GTP-Guard places PFCP-aware admission control in the driver receive path of a Kubernetes-hosted UPF, before illegitimate traffic consumes socket buffers or UPF cycles. The paper presents a design and evaluation hypotheses, with execution of the evaluation and extensions identified as future work.

IX. CONCLUSION AND FUTURE WORK

  • GTP-Guard provides a line-rate admission layer in the driver receive path of a Kubernetes-hosted UPF, independent of the UPF’s forwarding technology.The design’s stage-ordering result provides a basis for reconfiguring the pipeline as traffic shifts under attack.Source: §IX · p. 6
  • Table IV lists hypotheses that the evaluation is designed to test; the next step is to execute the evaluation of H1–H5.Source: Table IV · p. 6, §IX · p. 6
  • Future work will extend the pipeline to IPv6 and N6, evaluate SmartNIC hardware offload, and explore automated control of telemetry, allow-lists, ordering, and policing thresholds.Source: §IX · p. 6
Loading 2610.02296v1…