The Roaming Security Problem That SEPP Solves

In legacy 2G/3G/4G networks, roaming traffic between operators traverses the SS7 (for 2G/3G) or Diameter (for 4G) signaling networks via interconnect providers. These protocols were designed in an era of trusted, closed operator networks. The result is a well-documented history of vulnerabilities: SS7 location tracking attacks, Diameter-based subscriber information leaks, and fraudulent session manipulation.

5G's Service-Based Architecture (SBA) uses HTTP/2 over TLS for inter-NF communication. Extending this to roaming means that NF service requests (e.g., Nausf, Nudm, Npcf) must cross PLMN boundaries. Without a dedicated security gateway, operators would need to expose their internal NF APIs directly to partner networks -- an unacceptable security risk.

The Security Edge Protection Proxy (SEPP) is the 3GPP solution, defined in TS 33.501 Sections 9 and 13 and TS 29.573 (5G System -- Public Services). SEPP sits at the border of each PLMN and mediates all roaming signaling, providing authentication, encryption, integrity protection, topology hiding, and message filtering.

SEPP Architecture and N32 Interface

Reference Architecture

In a roaming scenario, the signaling path is:

NF (vPLMN) -> vSEPP -> [N32 interface] -> hSEPP -> NF (hPLMN)

Each PLMN deploys its own SEPP. The N32 interface between SEPPs carries all inter-PLMN signaling. 3GPP defines two sub-interfaces:

The N32-c interface is established first during SEPP-to-SEPP handshake. It negotiates which protection policy to apply on the N32-f forwarding plane.

SEPP vs Legacy Roaming Gateway Comparison

PRINS: Protocol for N32 Interconnect Security

The most innovative security mechanism in SEPP is PRINS (Protocol for N32 Interconnect Security), defined in TS 33.501 Section 13.2 and TS 29.573 Section 6.3. PRINS provides application-layer protection on top of transport-layer TLS, enabling selective encryption and integrity protection of specific JSON elements within HTTP/2 messages.

Why PRINS Is Needed Beyond TLS

TLS encrypts the entire transport connection between two endpoints. However, in many roaming scenarios, an IPX (IP eXchange) provider sits between the two SEPPs and may need to inspect or modify certain message elements for lawful intercept, billing mediation, or routing purposes. TLS alone would prevent this.

PRINS solves this by allowing operators to define which JSON elements are:

• Encrypted and integrity-protected (sensitive data the IPX cannot see)
• Integrity-protected only (the IPX can read but not modify)
• Neither (the IPX can read and modify, e.g., routing headers)

PRINS Message Structure

PRINS uses JOSE (JSON Object Signing and Encryption) standards:

• JWS (JSON Web Signature) for integrity protection (RFC 7515)
• JWE (JSON Web Encryption) for confidentiality protection (RFC 7516)

A PRINS-protected N32-f message contains:

PRINS Key Management

PRINS keys are negotiated during the N32-c handshake:

1. vSEPP and hSEPP exchange X.509 certificates and establish mutual TLS on N32-c
2. They negotiate a shared PRINS key using ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
3. The PRINS key is used to derive per-message encryption keys via HKDF
4. Key rotation occurs every 24 hours or after a configurable number of messages (typically 1 million)

Worked Example 1: Roaming Registration via SEPP

Scenario: A Deutsche Telekom subscriber roams to Vodafone UK. The UE registers on Vodafone's network, which triggers inter-PLMN signaling via SEPP. Step 1 -- UE registers on Vodafone (vPLMN):

UE sends Registration Request with SUCI (concealed identity) to Vodafone AMF. Vodafone AMF determines the home PLMN from the SUCI and routes the authentication request via SEPP.

Step 2 -- vSEPP processes the outbound request:

Vodafone's vSEPP receives the Nausf_UEAuthentication request from the AMF:

• Applies topology hiding: replaces internal NF instance IDs and IP addresses with vSEPP-generated pseudonyms
• Applies PRINS protection policy:

- SUCI: encrypted + integrity (dataToIntegrityProtectAndCipher)

- Authentication vector request parameters: integrity only

- Routing headers: unprotected (for IPX routing)

• Signs the message with JWS using the PRINS key
• Encrypts sensitive elements with JWE
• Forwards to hSEPP via N32-f (through IPX if applicable)

Step 3 -- hSEPP processes the inbound request:

Deutsche Telekom's hSEPP receives the N32-f message:

• Verifies JWS signature (integrity check) -- if invalid, message is rejected and alarm raised
• Decrypts JWE elements to recover SUCI
• Applies inbound message filtering: verifies that the message type and parameters are allowed per the roaming agreement
• Removes topology hiding information from the vPLMN
• Forwards the Nausf_UEAuthentication request to the AUSF

Step 4 -- Response path:

The authentication response (containing authentication vectors) follows the reverse path, with hSEPP applying PRINS protection before sending to vSEPP.

Total additional latency from SEPP processing: 2--5 ms per direction (measured by GSMA in interoperability tests), compared to 50--200 ms for the underlying authentication procedure.

Worked Example 2: SEPP Message Filtering Policy

Scenario: An operator discovers that a roaming partner is sending unauthorized Nudm_SDM (Subscriber Data Management) queries to extract subscriber profiles beyond what is needed for basic roaming service. SEPP filter configuration on hSEPP: `

Rule 1: ALLOW Nausf_UEAuthentication (all methods) from partner PLMN 234-15

Rule 2: ALLOW Nudm_UECM_Registration from partner PLMN 234-15

Rule 3: ALLOW Nudm_SDM_Get for data types: [AM-Data, SMF-Selection-Data]

Rule 4: BLOCK Nudm_SDM_Get for data types: [SMS-Data, Trace-Data, LCS-Privacy-Data]

Rule 5: BLOCK Nudm_SDM_Subscribe (no subscription to data change notifications)

Rule 6: BLOCK ALL other NF service requests from PLMN 234-15

Default: BLOCK and log

`

This policy allows the roaming partner to authenticate subscribers and register them for mobility management, but blocks attempts to retrieve SMS routing data, trace configurations, or location privacy settings. Each blocked request generates a security log entry for auditing.

Impact:

• Before SEPP filtering: 340 unauthorized Nudm_SDM queries per day from this partner
• After SEPP policy enforcement: 0 unauthorized queries, 100% block rate
• No impact on legitimate roaming service (authentication, session setup, mobility)

Operator Deployment Data

GSMA OPG Roaming Hub Trials (2024--2025)

The GSMA Operator Platform Group conducted multi-operator SEPP interoperability trials in 2024--2025:

• Participating operators: 28 operators from 19 countries
• SEPP vendors tested: Ericsson, Nokia, Huawei, Mavenir, Oracle
• N32-c handshake success rate: 99.2% on first attempt (0.8% failures due to certificate chain issues)
• PRINS interoperability: 97.5% success rate across different vendor SEPPs
• Average N32-f message processing time: 3.2 ms (vSEPP) + 2.8 ms (hSEPP) = 6 ms total overhead
• Message filtering accuracy: 100% (zero false positives in 4.2 million test messages)

Rakuten Mobile (Japan) SEPP Deployment

Rakuten Mobile, running a fully cloud-native 5G SA core, deployed SEPP for international roaming in 2024:

• SEPP vendor: built in-house on cloud-native microservices (Kubernetes)
• Roaming partners connected via SEPP: 42 operators (as of Q4 2024)
• N32 connections: 12 direct (bilateral SEPP-to-SEPP), 30 via IPX providers
• PRINS mode: enabled for all direct connections; TLS-only for IPX-mediated connections (IPX requires message visibility)
• Security incidents blocked: 156 unauthorized NF service requests in first 6 months (all from misconfigured partner SEPPs, not deliberate attacks)
• Topology hiding effectiveness: partner networks see zero internal NF topology information

TLS Configuration for N32

SEPP N32 connections require TLS with specific cipher suite requirements defined in TS 33.210 and TS 33.501:

The GSMA has established a dedicated PKI infrastructure for 5G roaming under the SAS-SM (Security Accreditation Scheme for Subscription Management) umbrella. Each operator's SEPP certificate must be signed by a GSMA-accredited Certificate Authority, creating a global trust chain for N32 connections.

SEPP Deployment Models

Operators have three deployment options for SEPP:

Most large operators are adopting the hybrid model: direct bilateral SEPP connections with PRINS for their top 10--20 roaming partners (by traffic volume), and IPX-mediated connections with TLS-only for the long tail of smaller partners.

Migration from Diameter to SEPP

Operators running both 4G (Diameter-based roaming) and 5G SA (SEPP-based roaming) need an interworking function. The N32-f to Diameter translation is handled by the Interworking Function (IWF) defined in TS 29.573 Section 7. During the transition period:

• 4G roaming: Diameter over IPX (existing infrastructure)
• 5G NSA roaming: Diameter over IPX (NSA uses EPC core)
• 5G SA roaming: SEPP over N32 (new infrastructure)
• Combined: IWF translates between Diameter and HTTP/2 for operators at different migration stages

Key Takeaway: SEPP is the 5G security gateway that replaces the vulnerable SS7/Diameter roaming infrastructure with authenticated, encrypted, and policy-controlled HTTP/2 signaling over the N32 interface. PRINS provides application-layer protection that enables selective encryption of sensitive elements while allowing IPX providers to perform necessary routing and mediation. GSMA interoperability trials across 28 operators demonstrate 99.2% handshake success and 6 ms processing overhead. Operators like Rakuten Mobile have already blocked hundreds of unauthorized NF service requests through SEPP message filtering, validating the security model. The transition from Diameter to SEPP is a multi-year migration that will ultimately close the roaming security gaps that have plagued mobile networks for decades.