Security Edge Protection Proxy

Description

The Security Edge Protection Proxy (SEPP) is a fundamental security node introduced in the 5G Core (5GC) architecture. It operates as a non-transparent proxy for all HTTP/2-based Service-Based Interface (SBI) messages that traverse network boundaries, primarily between different Public Land Mobile Networks (PLMNs) in roaming scenarios. The SEPP's primary function is to protect the N32 interface, which is the reference point for interconnectivity between SEPPs of different operators. It sits at the perimeter of a network, inspecting all inbound and outbound SBI traffic to and from Network Functions (NFs) like the AMF, SMF, and NRF.

Architecturally, the SEPP is a dedicated Network Function that implements application-layer security. It works in conjunction with the Network Repository Function (NRF) for service discovery and policy control. For outbound messages destined for another PLMN, the home SEPP receives the SBI request from a producer NF, applies security processing (including potential encryption and integrity protection), and forwards it to the visited PLMN's SEPP. The visited SEPP then validates the message, removes the security encapsulation, and routes it to the appropriate consumer NF within its network. This hop-by-hop security model ensures that the internal network topology and NF identities are hidden from external entities.

The SEPP employs two main security mechanisms for the N32 interface: N32-c and N32-f. N32-c is a control plane interface used for security context establishment and parameter negotiation between two SEPPs before data exchange. N32-f is the forwarding interface that carries the actual protected SBI messages. Protection can be applied using JSON Web Encryption (JWE) for confidentiality and JSON Web Signature (JWS) for integrity and authentication of the HTTP messages. The SEPP also performs message filtering and topology hiding, stripping or modifying sensitive routing information in headers to prevent external networks from mapping the internal NF deployment. Its role is critical for enabling secure roaming, network slicing across operators, and the exposure of network capabilities to third-party application providers via the Network Exposure Function (NEF).

Purpose & Motivation

The SEPP was created to address the significant security challenges introduced by the 5G Core's Service-Based Architecture (SBA) and its reliance on HTTP/2 APIs (the SBI). In previous generations (4G EPC), inter-operator signaling used diameter-based protocols like S6a and S8, which had their own security mechanisms (e.g., IPsec, diameter security). The shift to RESTful APIs and the need for more flexible network exposure created a new attack surface. Without a dedicated edge proxy, HTTP/2 messages between operators would be vulnerable to eavesdropping, tampering, and spoofing, and would expose internal network structures.

The primary problems the SEPP solves are securing the inter-PLMN communication for roaming and enabling safe third-party access. Roaming in 5G requires numerous SBI messages to flow between the home and visited network for authentication, session management, and policy control. The SEPP ensures these messages are authenticated, authorized, and protected end-to-end between the network perimeters. Furthermore, it facilitates topology hiding, which is a regulatory and security requirement for operators to conceal their internal network configuration from partners and potential attackers.

Its creation was motivated by the 3GPP's push for a cloud-native, web-friendly core network. The SBA allows for agile service deployment but inherits web security concerns. The SEPP is the standardized answer to applying robust, application-layer security tailored for telecom needs, replacing ad-hoc security gateways and ensuring a consistent, interoperable security baseline for global 5G deployment, especially for network slicing across administrative domains.

Key Features

• Application-layer security for HTTP/2-based SBI messages
• Hop-by-hop protection for the inter-PLMN N32 interface
• Support for JSON Web Encryption (JWE) and JSON Web Signature (JWS)
• Topology hiding of internal Network Function identities and configuration
• Message filtering and policy enforcement at the network boundary
• Integration with the NRF for security policy discovery and control

Evolution Across Releases

Defining Specifications