TelcomIQ

Overview

GTP-C — the control plane of the GPRS Tunnelling Protocol — is the protocol that creates, modifies, and deletes the packet data sessions used by mobile subscribers. Every time a phone connects to mobile data, a GTP-C exchange sets up a tunnel through the core network. Every handover, every change in bearer parameters, every graceful disconnect runs through GTP-C procedures.

The protocol exists in two major versions. GTPv1-C, defined in 3GPP TS 29.060, handles packet data contexts in 3G UMTS networks, running between the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN) over the Gn (intra-PLMN) and Gp (inter-PLMN roaming) interfaces. GTPv2-C, defined in TS 29.274, is the 4G EPC variant. It is architecturally more capable — carrying bearer-level granularity, handover state, and richer mobility procedures — and runs across a much wider set of interfaces between the MME, S-GW, P-GW, and, for handovers between SGSNs and MMEs, the S4 and S3 interfaces.

Both versions run over UDP, typically on port 2123. There is no session-layer authentication, no transport-layer encryption in the base specification, and no mechanism for a receiving node to verify that the sender is who it claims to be. GTP-C was designed for closed operator IP backbones. Its exposure across the GRX/IPX roaming interconnect — where the Gp and S8 interfaces cross between operator domains — makes it a realistic attack surface against any operator with international roaming.

How it works

GTP-C messages consist of a fixed header followed by Information Elements (IEs) that carry the procedure-specific parameters. The header carries a version field (1 or 2), flags, message type, total length, and a Tunnel Endpoint Identifier (TEID) — a 32-bit value that identifies which session this message concerns on the receiving node. In GTPv2-C, the header also carries a sequence number and spare fields.

Message structure (GTPv2-C):

TEID — 32-bit endpoint identifier. The sender uses the TEID assigned by the receiver in the preceding exchange. On the initial Create Session Request, TEID is set to zero.
Sequence number — Request/response matching and duplicate detection.
Information Elements — Type-length-value encoded. Each IE carries a specific piece of data: IMSI, APN, bearer QoS, F-TEID (fully qualified TEID — includes IP address and TEID), ULI (User Location Information), and many others.
Message type — Identifies the procedure: 32=Create Session Request, 33=Create Session Response, 34=Modify Bearer Request, 36=Delete Session Request, and so on.

Create Session procedure (4G EPC attach)

The sequence when a UE attaches to 4G and requests a PDN connection:

The MME selects an S-GW and sends a Create Session Request (CSR) to it. The CSR carries the subscriber's IMSI, MSISDN, the requested APN, the MME's F-TEID for the S11 interface, and bearer QoS requirements.
The S-GW allocates its own TEIDs for the S11 and S5 interfaces, then forwards a Create Session Request to the P-GW on the S5 interface, including its own F-TEID and the upstream parameters.
The P-GW allocates an IP address for the subscriber, establishes the PDN connection, and returns a Create Session Response (CSR-A) containing its assigned TEIDs, the subscriber's allocated IP address, and the bearer contexts.
The S-GW completes its own setup and returns a Create Session Response to the MME with the S11 TEID and the full bearer context, including the S1-U F-TEID that the eNB will use for GTP-U.

Modify Bearer and handover

When a UE moves between eNBs (X2 handover) or between S-GWs (S1 handover), the MME sends a Modify Bearer Request to the S-GW to update the downlink TEID for the new destination. For inter-SGW handovers, the process involves a new CSR to the target S-GW and a corresponding Delete Session on the source.

Delete Session

On detach, the MME sends a Delete Session Request toward the S-GW, which propagates it to the P-GW. Both nodes release their session state and the subscriber's IP address is returned to the pool.

Architecture role

GTP-C is the session management protocol of the 4G EPC data path. It is the protocol over which the MME orchestrates the network — allocating bearers, driving handovers, and initiating detaches. Without functioning GTP-C, no data sessions can be established regardless of the state of the radio access network.

In the 4G EPC, every interface carrying GTP-C is an intra-core interface except for the Gp (3G) and S8 (4G) interfaces, which cross PLMN boundaries for roaming subscribers. The S8 interface is functionally identical to S5 but runs between a Visited PLMN S-GW and the Home PLMN P-GW, making it the critical GTP-C exposure point for roaming attack scenarios.

In 4G EPC: The S11 interface carries GTPv2-C between the MME and S-GW. Every subscriber attach, idle-to-active transition, and detach event is a GTPv2-C exchange on S11. It is among the most active control-plane interfaces in a live EPC.

In 3G UMTS, GTPv1-C carries the PDP context lifecycle between the SGSN and GGSN. The procedures are less granular — PDP context activation, modification, and deactivation — but conceptually identical: a request from the SGSN, a response from the GGSN, and a tunnel state maintained at both ends.

In 5G SA, GTP-C is eliminated. The N4 interface between the SMF and UPF uses PFCP (Packet Forwarding Control Protocol) for equivalent session management functions, with a richer rule-based model that allows fine-grained per-packet forwarding decisions. GTP-U is retained between the gNB and UPF on the N3 interface, but the control plane is entirely PFCP.

In 5G NSA and EPS-5GC interworking, GTPv2-C interfaces survive on the S-GW side of the architecture, since the 4G EPC infrastructure remains in the path.

Key interfaces

Interface	Between	Direction	Purpose
S11	MME ↔ S-GW	Bidirectional	Bearer creation, modification, deletion; idle mode notify
S5	S-GW ↔ P-GW	Bidirectional	PDN connection setup; intra-PLMN data path control
S8	V-PLMN S-GW ↔ H-PLMN P-GW	Bidirectional	Roaming PDN connection control (GTPv2-C equivalent of S5)
S4	SGSN ↔ S-GW	Bidirectional	3G/4G interworking; S-GW serving 3G attached UEs
S3	SGSN ↔ MME	Bidirectional	3G/4G handover context transfer
S10	MME ↔ MME	Bidirectional	Context transfer during inter-MME TAU or handover
Gn	SGSN ↔ GGSN	Bidirectional	3G PDP context control (GTPv1-C, intra-PLMN)
Gp	SGSN ↔ GGSN	Bidirectional	3G roaming PDP context control (GTPv1-C, inter-PLMN)

Security posture

GTP-C carries no authentication at the protocol level. The message header contains no sender credential; the receiving node accepts any well-formed message addressed to a known TEID as legitimate. In a closed operator backhaul, this is defensible — the sender is identified by IP address, and IP-layer controls restrict which addresses can reach GTP-C endpoints.

The roaming interfaces undermine this model entirely. The Gp and S8 interfaces route GTP-C traffic between operator domains over the GRX/IPX, where any interconnected operator — or any party with access to that network — can send GTP-C messages to any reachable GGSN or P-GW. There is no GTP-C equivalent of the GSMA FS.11/FS.19 category filtering framework, and GTP firewalling at the Gp/S8 boundary is far less consistently deployed than SS7 or Diameter firewalls.

Beyond the roaming boundary, GTP-C's TEID model is a latent risk inside the operator network. TEIDs are short 32-bit values assigned per session — an attacker with knowledge of a valid TEID and the IP address of the receiving node can send arbitrary GTP-C messages for that session without any further credential.

Attack surface

Session hijacking via spoofed Create Session Request

An attacker with access to the Gp or S8 interface sends a Create Session Request targeting the home GGSN or P-GW, asserting a valid IMSI. If the GGSN or P-GW does not validate the originating SGSN/S-GW address against an IP whitelist, it will allocate a new PDP context — potentially displacing the legitimate subscriber's existing context — and return a tunnel TEID that the attacker can use for data plane access.

Impact: Subscriber data session displaced; attacker gains data plane access to the home network at the subscriber's IP address.
Difficulty: Medium. Requires access to the GRX/IPX and knowledge of a target IMSI.

Bearer deletion via forged Delete Session Request

A Delete Session Request carrying a target subscriber's IMSI and TEID causes the P-GW to tear down the subscriber's active PDN connection. The subscriber loses data service until the UE re-attaches. No session state beyond the TEID is required, and the TEID can sometimes be predicted or brute-forced.

Impact: Targeted denial of service; loss of data service for the duration of the re-attach cycle.
Difficulty: Medium. TEID prediction increases difficulty; TEID is only 32 bits and session density may be low on small networks.

Topology disclosure via Echo Request probing

The Echo Request / Echo Response procedure is a keepalive mechanism — nodes send Echo Requests to verify that peers are still active, and peers respond with an Echo Response carrying version and recovery information. An attacker sending Echo Requests to a range of IP addresses on the GRX/IPX can enumerate active GTP-C nodes, identify node software versions (included in the response recovery IE), and build a topology map of the target operator's core.

Impact: Network topology exposed; node software versions enable targeted exploit selection.
Difficulty: Low. Echo Request requires only knowledge of potential GTP-C endpoint addresses.

Handover abuse via spoofed Modify Bearer Request

A spoofed Modify Bearer Request sent to a P-GW can redirect downlink traffic for an active bearer to a TEID and IP address controlled by the attacker. All subsequent downlink data for the subscriber is then delivered to the attacker rather than the legitimate S-GW.

Impact: Subscriber downlink traffic intercepted transparently; no subscriber-visible indication.
Difficulty: High. Requires knowledge of an active TEID and the P-GW's GTP-C address, which typically requires either prior reconnaissance or network access.

Mitigations

The primary defence is a GTP firewall deployed at the Gp and S8 roaming interfaces, analogous to the SS7 signalling firewall on the interconnect.

IP-based access control at Gp/S8: Only allow GTP-C traffic from IP addresses listed in the IR.21 data for roaming partners. Reject Create Session Requests from unregistered source IPs unconditionally.
IMSI/MSISDN-to-PLMN validation: A Create Session Request carrying an IMSI must originate from a PLMN that corresponds to that IMSI's country code. A message claiming to originate from a German PLMN but carrying an IMSI with a UK MCC prefix is either misconfigured or an attack.
TEID correlation and state tracking: A GTP firewall that tracks active TEID state can reject Delete Session and Modify Bearer messages that reference TEIDs not observed in preceding Create Session exchanges on the same interface.
Rate limiting per source IP and IMSI: Legitimate roaming generates predictable GTP-C rates. Burst Create Session Requests from a single source IP indicate either equipment malfunction or an attack.
Echo Request filtering: Block Echo Requests from IPs not whitelisted as valid GTP-C peers. Echo Responses from the network expose node availability and version information to unauthenticated senders.

Spec references

3GPP TS 29.274 — The normative GTPv2-C specification for 4G EPC. Section 5 defines the protocol elements; Section 7 defines the Information Elements; Section 8 defines the procedures (Create Session, Modify Bearer, Delete Session, etc.). The primary reference for S11, S5, and S8 implementation and security analysis.
3GPP TS 29.060 — The GTPv1-C specification for 3G GPRS. Section 7 defines the message formats; Section 9 defines the PDP context procedures on Gn/Gp. Essential for understanding the legacy 3G attack surface.
3GPP TS 23.401 — The EPS architecture specification. Section 5.3 defines the attach procedure end-to-end; Section 5.10 covers the handover procedures that drive the Modify Bearer exchanges.

GTP-C and GTP-U are two halves of the same protocol family: GTP-C manages session lifecycle while GTP-U carries the actual subscriber data once the session is established. The two work in lockstep — a GTP-C Create Session Response provides the TEIDs that GTP-U will use for data encapsulation.

In the 4G core, GTP-C touches nearly every node: the MME drives session establishment from the control plane, while the S-GW and P-GW allocate the tunnel endpoints. In 5G SA, PFCP on the N4 interface replaces GTP-C for the SMF-to-UPF control plane.

For the attack dimension, see GTP attacks for the full taxonomy, and roaming architecture for the network context that exposes the Gp and S8 interfaces to external actors.

Specifications

Relationships