3GPP TS 33.513
1. Scope
▶This document specifies security requirements and test cases for the UPF (User Plane Function) and GW (Gateway) network product class. The UPF handles all user plane traffic in 5GC, performing packet routing, forwarding, QoS enforcement, and GTP-U encapsulation/decapsulation on N3, N9, and N6 interfaces.
Extends TS 33.117 with UPF-specific requirements. All TS 33.117 tests apply in addition to those defined here.
2. References
▶4. UPF Network Product Class Definition
▶| Interface | Peer | Protocol | Traffic |
|---|---|---|---|
| N3 | gNB | GTP-U | User plane data to/from RAN |
| N9 | UPF (I-UPF) | GTP-U | User plane between UPFs (UL-CL, branching) |
| N6 | Data Network | IP | PDU session to Internet / DN |
| N4 | SMF | PFCP | Control: session establishment, modification, deletion |
5. UPF-Specific Threats
▶The UPF is the most GTP-exposed element in the 5G architecture. It is the primary target for GTP-based attacks:
TR 33.926 §5.3.6.15 GTP traffic isolation — THE critical UPF threat ▶
TR 33.926 §5.3.3.5 IP spoofing on GTP-U source addresses ▶
TR 33.926 §5.3.4 DoS via GTP-U flooding or malformed packets ▶
TR 33.926 §5.3.7.3 Insecure network services exposed by UPF ▶
- GTP-U TEID prediction: Sequential TEIDs may allow attacker to inject packets into user sessions
- GTP-in-GTP: Malicious encapsulation bypassing outer tunnel filtering
- N6 data exfiltration: Compromised UPF could exfiltrate all user traffic to external destination
- N4 PFCP manipulation: Unauthorized PFCP session modification could redirect traffic
- Cross-slice leakage: UPF serving multiple slices may leak data between them
6. UPF-Specific Security Requirements and Test Cases
▶6.1 GTP-U Filtering (N3/N9)
▶Verify that the UPF correctly filters GTP-U packets on N3 and N9 interfaces, preventing unauthorized GTP traffic.
- Establish a valid PDU session with known TEID on N3
- Source IP check: Send GTP-U packets with valid TEID but from unauthorized source IP → verify DROPPED
- Invalid TEID: Send GTP-U packets from valid source IP but with unknown/invalid TEID → verify DROPPED
- GTP-U port check: Verify UPF only accepts GTP-U on UDP port 2152
- GTP version check: Send GTP-U with invalid version field → verify DROPPED
- GTP-in-GTP: Send GTP-U packet containing inner GTP-U encapsulation → verify DROPPED or inner packet not forwarded to N6
- Post-session teardown: After PDU session deletion, send GTP-U with old TEID → verify DROPPED
- TEID randomization: Verify that TEIDs are randomly assigned (not sequential)
- Rate limiting: Flood GTP-U traffic → verify UPF applies rate limiting or overload protection
- Oversized packets: Send GTP-U packets exceeding configured MTU → verify handled correctly
Only GTP-U packets with (1) valid source IP matching known gNB/UPF, (2) valid assigned TEID, and (3) correct protocol version/format are forwarded. All other GTP-U packets are dropped silently.
TR 33.926 §5.3.6.15 Mitigates GTP traffic isolation failure ▶
6.2 GTP-C Processing
▶Verify that the UPF does not process GTP-C (control plane) messages directly. In 5G architecture, the UPF receives control instructions only via PFCP (N4) from the SMF — not via GTP-C.
- Send GTP-C Create Session Request to UPF N3/N9 IP on port 2123 → verify DROPPED or port closed
- Send GTP-C Modify Bearer Request → verify no response
- Verify UPF does not listen on UDP 2123 (GTP-C port)
- For combined UPF/PGW-U: if GTP-C v2 is supported on S5/S8, verify it's restricted to configured SGW peers only
Pure 5G UPF: port 2123 is closed, no GTP-C processing. Combined UPF/PGW-U: GTP-C only accepted from configured peers.
6.3 N4 PFCP Security
▶Verify that the N4 interface (PFCP) between SMF and UPF is properly secured and cannot be abused.
- Verify N4 is protected by IPsec or TLS (DTLS for PFCP over UDP)
- Send PFCP Session Establishment from unauthorized source → verify REJECTED
- Send PFCP with manipulated Node ID → verify REJECTED
- Verify PFCP Association Setup requires authentication
- Verify PFCP session modification from different SMF than original → verify REJECTED
Only the authorized SMF (via established PFCP association) can create/modify/delete sessions on the UPF. Unauthorized PFCP messages are silently dropped.
6.4 N6 Interface Security
▶Verify security at the N6 interface (UPF ↔ Data Network / Internet).
- Verify that traffic from N6 cannot reach the N3/N9 GTP plane (plane separation)
- Verify that N6 ingress traffic is filtered (anti-spoofing: source IP must match allocated UE IP)
- Verify that the UPF does not route N6 traffic to internal management interfaces
- Verify UPF ACL/PDR rules enforce per-session traffic filtering
6.5 Traffic Separation and Slice Isolation
▶Verify that the UPF maintains strict separation between different traffic types and network slices.
- Plane separation: Verify user plane (N3/N9/N6) traffic cannot reach management/OAM plane
- Slice isolation: If UPF serves multiple S-NSSAIs, verify that PDU sessions for different slices cannot access each other's data
- GTP-U to management: Verify that GTP-U decapsulated packets cannot be routed to the UPF's management IP
- N4/N6 separation: Verify PFCP (N4) traffic is on a separate interface or VLAN from N6 data
TR 33.926 §5.3.6.15 Lack of traffic isolation between GTP and other network planes ▶
6.6 N9 Inter-UPF Security
▶- Verify N9 GTP-U traffic is protected by IPsec when crossing security domain boundaries
- Verify that N9 GTP-U only accepts traffic from configured peer UPF IPs
- Verify TEID validation on N9 (same filtering as N3)
7. SCAS Test Case Summary
▶| Test Case ID | Category | Threat Ref | Priority |
|---|---|---|---|
| TC_UPF_GTP_U_FILTERING | GTP-U Security | §5.3.6.15, §5.3.3.5 | CRITICAL |
| TC_UPF_GTP_C_VALIDATION | GTP-C Security | §5.3.6.15 | CRITICAL |
| TC_UPF_PFCP_SECURITY | N4 Security | §5.3.5 | CRITICAL |
| TC_UPF_N6_SECURITY | N6 Security | §5.3.6 | HIGH |
| TC_UPF_TRAFFIC_SEPARATION | Plane Separation | §5.3.6.15 | CRITICAL |
| TC_UPF_N9_SECURITY | N9 Security | §5.3.6.15 | HIGH |
| Plus ALL test cases from TS 33.117 | |||