TelcomIQ

Overview

GTP-U — the user plane of the GPRS Tunnelling Protocol — carries subscriber IP packets through the mobile packet core. When a mobile phone sends a web request, that IP packet does not travel end-to-end through the network as a plain IP datagram. Instead, it is encapsulated inside a GTP-U packet at the first network-side tunnel endpoint, transported through the core as an opaque payload, and decapsulated at the far end before being routed to the internet.

This encapsulation design allows the mobile core to treat subscriber data as an abstracted tunnel rather than raw IP traffic. It enables per-bearer quality-of-service enforcement, subscriber mobility without IP address changes, and clean separation between the access network and the internet. The tunnel endpoint on each side is identified by a 32-bit Tunnel Endpoint Identifier (TEID), allocated during the GTP-C session establishment procedure that precedes any GTP-U data flow.

GTP-U was originally defined as GTPv1-U in the 3G GPRS era (TS 29.281) and has remained essentially unchanged through the 4G EPC and into 5G NSA deployments. In 5G SA, the user plane architecture changes significantly — the UPF replaces the P-GW and uses PFCP on the N4 control interface — but GTP-U is retained on the N3 interface between the gNB and UPF, making it the most persistent component of the GTP family.

Its security posture is the inverse of GTP-C's: the control plane creates sessions that are administratively controlled, but the user plane carries live subscriber traffic at high volumes with minimal run-time validation. Any attacker who can inject a valid GTP-U packet will have that packet delivered to the subscriber's device — or into the operator's network — as if it were legitimate.

How it works

A GTP-U packet consists of a mandatory fixed header and a payload carrying the inner IP packet (or other PDU type in 5G). The header is intentionally minimal to reduce per-packet processing overhead at line rate.

GTP-U header fields:

Version (3 bits) — Always set to 1 for GTPv1-U.
PT (Protocol Type, 1 bit) — Set to 1 for GTP, distinguishing from GTP' (charging).
E, S, PN flags (1 bit each) — Indicate presence of the optional extension header, sequence number, and N-PDU number fields respectively. If any flag is set, the optional four-byte field follows the mandatory header.
Message type (8 bits) — Identifies the message. Type 255 is a G-PDU: a user data packet. Type 26 is an Error Indication. Type 254 is an End Marker, used during handover.
Total length (16 bits) — Total length of the packet excluding the mandatory header.
TEID (32 bits) — The tunnel endpoint identifier on the receiving node. The sender uses the TEID that the receiver allocated and communicated during the GTP-C session establishment.

TEID lifecycle

The TEID is allocated by each tunnel endpoint during GTP-C setup. In a 4G EPC attach:

GTP-C Create Session Response from the S-GW includes the S1-U F-TEID (IP address + TEID) that the eNB must use for uplink GTP-U.
The MME provides the eNB with this F-TEID in the S1AP Initial Context Setup message.
The eNB allocates its own S1-U TEID and provides it to the S-GW via the MME in a Modify Bearer exchange.
Data flow begins: the eNB encapsulates uplink packets with the S-GW's TEID; the S-GW encapsulates downlink packets with the eNB's TEID.

Each hop in the data path has its own TEID pair: eNB↔S-GW on S1-U, S-GW↔P-GW on S5/S8.

End Marker and handover

During an X2 handover, the source eNB sends an End Marker GTP-U message to the S-GW to signal that it has forwarded all buffered packets. This tells the S-GW to switch the downlink TEID to the target eNB. The End Marker is a lightweight message — it carries no payload — but its function means it directly controls the destination of subscriber downlink traffic.

Architecture role

GTP-U is the data plane of the mobile packet core. Every byte of subscriber internet traffic passes through at least two GTP-U tunnels in a 4G network: one on S1-U between the eNB and the S-GW, and one on S5 or S8 between the S-GW and the P-GW.

The separation into two tunnel segments exists to support subscriber mobility. When a subscriber moves to a new eNB, only the S1-U segment changes — the S5/S8 tunnel between S-GW and P-GW remains intact, preserving the subscriber's IP address and active sessions. When a subscriber moves to a new S-GW coverage area, both segments are replaced, but the P-GW anchor and subscriber IP address remain constant.

In 4G EPC: The S1-U interface carries all subscriber data between the radio access network and the core. It is the highest-volume interface in the EPC by data rate. The S-GW acts as the GTP-U termination point on the core side of S1-U, and as the initiating endpoint on the S5/S8 side toward the P-GW.

In 3G UMTS, GTPv1-U runs between the SGSN and GGSN on the Gn (intra-PLMN) and Gp (inter-PLMN) interfaces. The architecture is conceptually identical: a tunnel per PDP context, with TEIDs allocated during the GTPv1-C Create PDP Context procedure.

In 5G SA, GTP-U is retained on the N3 interface between the gNB and UPF. The UPF takes over the S-GW/P-GW data plane anchoring role, and the SMF drives tunnel setup via PFCP rather than GTP-C. GTP-U itself is unchanged.

In 5G NSA (non-standalone), the 5G radio (NR) connects via an eLTE anchor eNB to the 4G EPC. GTP-U tunnels from the gNB are split or aggregated at the anchor eNB, and the EPC data path remains GTP-U on S1-U and S5/S8.

Key interfaces

Interface	Between	Direction	Purpose
S1-U	eNB ↔ S-GW	Bidirectional	Subscriber data between RAN and core in 4G
S5	S-GW ↔ P-GW	Bidirectional	Intra-PLMN data path between S-GW and P-GW
S8	V-PLMN S-GW ↔ H-PLMN P-GW	Bidirectional	Roaming data path; GTP-U crosses PLMN boundary
S4	SGSN ↔ S-GW	Bidirectional	3G/4G interworking; GTP-U for 3G UEs via S-GW
X2	eNB ↔ eNB	Bidirectional	Direct tunnel forwarding during X2 handover
Gn	SGSN ↔ GGSN	Bidirectional	3G user-plane data (GTPv1-U, intra-PLMN)
N3	gNB ↔ UPF	Bidirectional	5G SA user-plane data (GTPv1-U retained)

Security posture

GTP-U carries live subscriber traffic and imposes almost no run-time validation on the packets it delivers. The receiving node accepts any GTP-U packet addressed to a known TEID, decapsulates it, and delivers the inner IP packet to the subscriber's bearer. There is no source authentication, no payload validation, and no mechanism to verify that the inner IP packet was originated by the correct subscriber.

The critical constraint is the TEID: without a valid TEID value and the receiving node's IP address, an attacker cannot target a specific subscriber. But TEIDs are 32-bit integers, and the TEID space for any given P-GW or GGSN is not astronomically large — a sufficiently active network may have tens of thousands of active sessions, and TEIDs are sometimes allocated sequentially or with limited entropy.

The S8 roaming interface introduces network-boundary exposure. On S8, GTP-U traffic crosses between operator domains over the GRX/IPX. An attacker with GRX/IPX access who learns a valid TEID — through GTP-C reconnaissance, SS7 enumeration, or other means — can inject GTP-U packets across the roaming path.

Attack surface

Packet injection via known TEID

An attacker who learns a valid TEID and the IP address of the receiving GTP-U endpoint can inject arbitrary IP packets into the subscriber's data session. The injected packets appear to the subscriber's device as legitimate network responses — DNS responses, TCP connections, HTTP content — since they carry the subscriber's IP address as the inner destination.

Impact: Arbitrary network-layer injection into the subscriber's data session; enables DNS poisoning, man-in-the-middle against unencrypted sessions, or TCP connection hijacking.
Difficulty: Medium. Requires knowledge of a valid TEID, which can sometimes be obtained via GTP-C reconnaissance or correlation with other signalling data.

Subscriber traffic interception via tunnel impersonation

An attacker on the data path between tunnel endpoints — or with the ability to inject GTP-C Modify Bearer messages — can redirect the downlink GTP-U stream to an IP address they control. All subscriber downlink traffic is then delivered to the attacker's node for inspection before forwarding.

Impact: Full visibility of unencrypted subscriber traffic; enables passive surveillance of HTTP, DNS, and unencrypted application data.
Difficulty: High for external attackers. More accessible for a compromised network element or an attacker with both GTP-C and GTP-U access.

Inner IP encapsulation abuse for firewall bypass

GTP-U encapsulation wraps an inner IP packet inside an outer GTP-U/UDP/IP packet. Firewalls and access control systems that do not perform GTP-aware deep packet inspection act only on the outer IP header. An attacker can craft inner IP packets with source addresses from RFC 1918 ranges, loopback, or operator management subnets to bypass access controls that would block those addresses on the un-encapsulated path.

Impact: Firewall and access control bypass; potential access to management interfaces or internal services behind the P-GW.
Difficulty: Medium. Requires GTP-U access to a P-GW that performs insufficient inner IP validation.

Tunnel steering via spoofed End Marker

The End Marker GTP-U message signals that a handover buffer drain is complete and the S-GW should switch downlink delivery to a new TEID. A spoofed End Marker from an attacker causes the S-GW to immediately redirect the subscriber's downlink stream to a TEID specified in the next Modify Bearer message, which the attacker can also send if they have GTP-C access.

Impact: Downlink traffic diverted from legitimate eNB to attacker-controlled endpoint.
Difficulty: High. Requires coordinated GTP-C and GTP-U access.

Mitigations

GTP firewall at the Gp and S8 boundary: All inbound GTP-U traffic from roaming partners should pass through a GTP-aware firewall that validates the source IP against the IR.21 whitelist for that partner. GTP-U from unlisted addresses should be dropped.
TEID state tracking: A stateful GTP inspection engine that correlates GTP-U TEIDs against active GTP-C sessions can detect and drop GTP-U traffic referencing TEIDs that were never established — either brute-forced or derived from a hijacked GTP-C session.
Inner IP address validation: The P-GW and UPF should validate that the inner source IP in uplink GTP-U packets matches the address assigned to the subscriber for that bearer. Inner packets with forged source addresses — particularly RFC 1918, loopback, or operator-allocated management ranges — should be discarded.
GTP-aware DPI in the core: Firewalls in the core network that inspect inter-domain GTP-U traffic should perform GTP decapsulation and apply access control rules to the inner IP headers, not merely the outer encapsulation.
Encryption via IPsec: On the S8 roaming interface, applying IPsec between the S-GW and P-GW prevents interception of GTP-U traffic in transit across the GRX/IPX. Deployment is inconsistent across the industry.

Spec references

3GPP TS 29.281 — The normative GTPv1-U specification. Section 5 defines the header format and extension headers. Section 6 defines the message types, including the critical G-PDU, Error Indication, and End Marker messages.
3GPP TS 29.274 — GTPv2-C specification, which is where TEID allocation for GTP-U is defined. The F-TEID IE in Section 8.22 specifies how IP addresses and TEIDs are communicated during session establishment.
3GPP TS 23.401 — The EPS architecture specification. The bearer activation and handover procedures in Section 5 describe the end-to-end context within which GTP-U TEIDs are allocated and used.

GTP-C is the control plane that creates and manages the sessions GTP-U carries. The TEID values used by GTP-U are allocated by GTP-C — the two protocols are inseparable in practice. In 5G SA, PFCP replaces GTP-C on the N4 control interface between the SMF and UPF, but GTP-U persists on N3.

The data path in 4G runs through the S-GW and P-GW; in 5G SA it terminates at the UPF. For the attack dimension, see GTP attacks for the full attack taxonomy. The roaming exposure of the S8 interface is covered in roaming architecture and S8 home routing.

Specifications

Relationships