PFCP

Overview

PFCP — Packet Forwarding Control Protocol — is the 3GPP protocol that separates the control plane from the user plane in 5G SA and in 4G networks that have adopted the CUPS (Control and User Plane Separation) architecture. Defined in 3GPP TS 29.244, it operates on the N4 interface between the Session Management Function (SMF) and the User Plane Function (UPF). It is also used between the SGW-C and SGW-U, and between the PGW-C and PGW-U, in 4G CUPS deployments.

The fundamental purpose of PFCP is control-data plane separation. In legacy 4G EPC, the S-GW and P-GW integrated both session management logic and packet forwarding in the same network element. CUPS and 5G SA disaggregate these: the SMF handles all session management, subscriber policy, and traffic steering decisions; the UPF handles per-packet processing at line rate based on rules that the SMF installs via PFCP. This separation allows the UPF to be scaled and placed independently — deployed at the edge for low-latency user plane anchoring while the SMF remains centralised — which is a key architectural enabler for 5G edge computing use cases.

PFCP replaces GTP-C for the SMF-to-UPF control path. Rather than the session-oriented Create/Modify/Delete structure of GTPv2-C, PFCP uses a rule-based model: the SMF installs a set of rules into the UPF that govern how every packet in a session is processed, and modifies those rules as session conditions change.

---

How it works

PFCP operates in two modes: node-level procedures (establishing the PFCP association between SMF and UPF) and session-level procedures (managing the per-subscriber packet forwarding rules).

Node-level procedures:

Before any sessions can be managed, the SMF and UPF must establish a PFCP association. The PFCP Association Setup Request/Response exchange verifies that both nodes support compatible PFCP feature sets and shares the node identifiers. The SMF can then send session management requests to that UPF.

Session-level procedures:

Each PDU session (the 5G equivalent of a bearer) is managed as a PFCP session. The three core session procedures are:

• PFCP Session Establishment Request/Response — Creates a new PFCP session for a PDU session. The SMF sends the full rule set for the session: all PDRs, FARs, URRs, QERs, and BARs.
• PFCP Session Modification Request/Response — Modifies an existing session's rules. Used during handover (to update the downlink forwarding address), QoS policy changes, or activation of charging rules.
• PFCP Session Deletion Request/Response — Removes all rules for a session and tears down the UPF state.

The rule model:

PFCP installs five types of rules into the UPF:

• PDR (Packet Detection Rule) — Defines matching criteria for incoming packets. Each PDR specifies a precedence, a Packet Detection Information (PDI) field (which can match on GTP-U TEID, UE IP address, source interface, or application ID), and the identifier of the FAR to apply when the PDR matches.
• FAR (Forwarding Action Rule) — Defines what to do with packets that match a PDR: forward them (specifying the destination interface, GTP-U TEID, and outer header creation parameters), duplicate them (for lawful intercept), buffer them (when the UE is in idle mode), or drop them.
• URR (Usage Reporting Rule) — Defines traffic measurement triggers. The UPF measures volume or time against URR thresholds and reports usage to the SMF for online/offline charging via a PFCP Session Report.
• QER (QoS Enforcement Rule) — Defines bit rate enforcement for a session or QoS flow. The UPF applies gating and policing according to the QER parameters.
• BAR (Buffer Action Rule) — Controls the downlink data buffering behaviour when the UE is idle. When the UPF receives downlink data for a buffered session, it sends a PFCP Session Report (Downlink Data Report) to the SMF, which pages the UE.

---

Architecture role

PFCP sits at the heart of the 5G SA user plane architecture. The SMF is the PFCP controller: it translates high-level session management decisions (PDU session establishment from the AMF, policy from the PCF, charging from the CHF) into concrete rule sets that it programs into the UPF via PFCP. The UPF then applies those rules at line rate for every packet of every active PDU session.

In 5G SA: Every subscriber's internet traffic passes through forwarding rules that the SMF installed via PFCP. If those rules are wrong — misconfigured, modified by an attacker, or installed by a rogue SMF — the UPF will faithfully execute them. The UPF has no independent view of session correctness; it does exactly what the PFCP rules say.

In 4G CUPS, PFCP plays the same role but the nodes are named differently. The SGW-C (S-GW Control Plane) and PGW-C (P-GW Control Plane) are the PFCP controllers; the SGW-U and PGW-U are the PFCP-controlled user plane elements. PFCP replaces the internal GTP-C procedures that formerly linked control and user plane within the combined S-GW and P-GW.

The N4 interface is a 3GPP-internal interface — there is no standardised or expected reason for PFCP traffic to cross operator boundaries. Unlike GTP-C on S8 or Diameter on the roaming interface, PFCP is intended to be entirely within the operator's management domain. This reduces the external attack surface but increases the importance of protecting the internal network against lateral movement.

---

Key interfaces

---

Security posture

PFCP's security posture is defined by its architectural position. The protocol itself is simple — request-response message pairs over UDP port 8805, with no mandatory authentication in the base specification. Transport-layer security (mutual TLS or IPsec) between SMF and UPF is recommended in 3GPP TR 33.846 but not mandated in all configurations. In virtualised deployments where SMF and UPF run as containers in the same cloud infrastructure, PFCP may traverse shared network segments rather than dedicated links.

The consequence of this architecture is that the UPF is fully controlled by whoever can send valid PFCP messages on the N4 interface. A compromised or impersonated SMF — or any node that can reach the UPF on UDP port 8805 — can install forwarding rules that redirect, duplicate, or drop any subscriber's traffic without the subscriber's knowledge. There is no subscriber-visible indicator of compromised forwarding rules; the attack is transparent at the application layer.

The threat model is primarily internal: a compromised VNF (Virtual Network Function) in the same network slice, a misconfigured service mesh that routes PFCP traffic across tenant boundaries, or an insider who has access to the management plane. External attackers targeting PFCP would first need to breach the operator's internal network perimeter.

---

Attack surface

Traffic redirection via malicious FAR injection

The most damaging PFCP attack is the installation of a Forwarding Action Rule that redirects subscriber traffic to an attacker-controlled endpoint. A FAR specifies the destination interface and GTP-U TEID for forwarding; a modified FAR can change the destination to any IP address. The UPF executes the forwarding rule without verification.

Impact: All traffic for targeted subscribers delivered to the attacker; enables full passive interception of unencrypted sessions.
Difficulty: High. Requires either a compromised SMF, lateral movement within the core network, or the ability to reach the UPF on UDP 8805.

Rogue UPF impersonation

If PFCP uses no transport-layer authentication, an attacker who can send packets on the N4 address can respond to SMF session establishment requests, claiming to be a legitimate UPF. The SMF sends PFCP Session Establishment Requests; the rogue UPF acknowledges them and receives GTP-U traffic intended for the legitimate UPF, then forwards it onward (acting as a transparent relay) or drops it.

Impact: Subscriber traffic intercepted at the UPF level; potentially all traffic for sessions routed through the rogue UPF.
Difficulty: High. Requires access to the internal network segment used for N4.

QoS policy bypass via malformed QER

A QoS Enforcement Rule (QER) specifies the guaranteed and maximum bit rates for a PDU session. An attacker who can install or modify a QER with unlimited bit rate parameters effectively removes throttling from a subscriber session — enabling a prepaid subscriber to consume unlimited data, or a consumer plan to circumvent enterprise QoS controls.

Impact: Revenue bypass; QoS enforcement failure across affected subscribers.
Difficulty: Medium. Less operationally disruptive than FAR attacks, but financially damaging at scale.

Session teardown via spoofed PFCP Session Deletion

A PFCP Session Deletion Request causes the UPF to remove all rules for a specified session and release associated resources. A spoofed deletion causes the UPF to silently tear down the subscriber's PDU session. The subscriber loses connectivity until the UE re-triggers PDU session establishment.

Impact: Targeted denial of service; subscribers lose data connectivity.
Difficulty: Medium. Requires knowledge of the PFCP session SEID (Session Endpoint Identifier) and the ability to reach the UPF.

---

Mitigations

• Network isolation of the N4 interface: PFCP should never be reachable from outside the operator's core management network. Deploy dedicated network segments for N4 traffic, and enforce strict ingress/egress controls that allow only the provisioned SMF instances to reach each UPF.

• Mutual TLS between SMF and UPF: TLS with mutual certificate authentication ensures that the UPF accepts PFCP only from the legitimate SMF, and the SMF only installs rules on the legitimate UPF. Certificate management for PFCP endpoints should use the operator's internal PKI.

• SEID validation and session state correlation: The SMF should maintain authoritative state for all active PFCP sessions. Any PFCP message referencing an unknown SEID should be rejected. The SMF should verify that modification and deletion requests correspond to sessions it created.

• FAR destination address validation at the UPF: The UPF can apply a policy layer that rejects FARs specifying forwarding destinations outside the operator's IP space. This limits the impact of a compromised SMF to traffic manipulation within the operator's network rather than exfiltration to external addresses.

• Anomaly monitoring on usage reports: The URR mechanism produces per-session traffic volume reports. Unexpected traffic volumes, anomalous forwarding destinations in PFCP session modification messages, or session deletions for large numbers of subscribers in a short period are reliable indicators of a compromised PFCP node.

---

Spec references

• 3GPP TS 29.244 — The normative PFCP specification. Section 5 defines the message format and information elements. Section 6 defines the node-level procedures. Section 7 defines the session-level procedures (Establishment, Modification, Deletion, Report). The primary reference for SMF-UPF interface implementation and security analysis.

• 3GPP TS 23.501 — The 5G SA system architecture specification. Section 6.2 defines the N4 reference point and its function. Section 5.7 covers the UPF architecture and the PFCP rule model in the context of the 5G QoS framework.

• 3GPP TS 29.281 — GTPv1-U specification, referenced because the outer header creation parameters in PFCP FARs specify GTP-U encapsulation parameters used for the N3/N9 interfaces — PFCP controls the GTP-U tunnels that carry actual subscriber data.

---

Related topics

PFCP's relationship to GTP-U is direct: the FAR rules that PFCP installs specify the GTP-U TEIDs and IP addresses that the UPF uses to encapsulate and forward user plane traffic. PFCP is the control protocol; GTP-U is the bearer it drives.

PFCP supersedes GTP-C for the control-data plane interface in 5G SA. The two protocols solve similar problems — managing session and forwarding state — but PFCP's rule-based model is substantially more expressive than GTP-C's session-oriented procedures. The SMF and UPF are the nodes that originate and terminate PFCP on the N4 interface; in 4G CUPS the equivalent nodes are SGW-C/SGW-U and PGW-C/PGW-U. The broader 5G SA architecture context is in 5G SA and the HTTP/2 SBI specification that governs all other 5G service interfaces.