Fixing the border that SS7 and Diameter left wide open
“For decades, the interconnect between operators trusted any message that arrived. Location tracking, fraud, and interception followed. 5G’s answer stands at the border with a name: SEPP.”
— THE INTERCONNECT LESSON
Roaming was mobile networks’ softest underbelly. The SS7 and Diameter interconnects assumed every peer was honest, and attackers exploited that to locate subscribers, intercept calls, and commit fraud — across borders, anonymously. 5G introduces the SEPP (Security Edge Protection Proxy): a cryptographic guard through which all inter-operator signaling must pass. This chapter covers the SEPP, the N32 interface, TLS vs PRINS protection, IPX intermediaries, topology hiding, and message filtering.
🎯 Learning objectives
Explain why SS7/Diameter roaming was insecure, and what 5G changes.
Describe the SEPP’s role and the N32-c / N32-f interfaces.
Compare TLS mode and PRINS application-layer protection.
Explain IPX intermediaries and authorized modification.
Checked June 2026 — verify against the latest 3GPP version.
13.1 Why Roaming Was the Weakest Link
FIGURE 13.1Roaming Interconnect History — SS7 → Diameter → N32
Purpose: the historical arc. SS7’s “trust everyone” model survived into Diameter; the SEPP is the first interconnect designed assuming the peer — and everything between you and it — might be hostile.
FIGURE 13.2What the Old Interconnect Allowed
Purpose: the concrete harm. These weren’t exotic exploits — they were legitimate protocol messages sent by anyone with interconnect access, because nothing authenticated the sender.
13.2 The SEPP and N32
FIGURE 13.35G Roaming Architecture with SEPPs
Purpose: the roaming security model. Every cross-operator message funnels through two SEPPs; the IPX in the middle is treated as untrusted by design.
FIGURE 13.4SEPP Placement and Roles
Purpose: what the SEPP actually does. It terminates internal security, re-protects for the hostile interconnect, hides your topology, and filters what crosses.
FIGURE 13.5N32-c Handshake — Capability and Policy Exchange
Purpose: the two-channel design. N32-c negotiates the security relationship up front; only then does N32-f carry real traffic — so policy is agreed before any subscriber data flows.
13.3 TLS Mode vs PRINS
N32 can be protected two ways. TLS mode: a direct TLS connection between SEPPs — simplest, used when no IPX needs to read/modify anything. PRINS (PRotocol for N32 INterconnect Security): application-layer protection (JOSE — JWE/JWS over the JSON) that survives passing through IPX intermediaries, letting them make authorized modifications while the rest stays encrypted and integrity-protected end-to-end.
FIGURE 13.6N32 Security Mode Decision — TLS vs PRINS
Purpose: the mode choice. TLS is cleaner but opaque to intermediaries; PRINS exists precisely because the roaming ecosystem still has IPX providers that must touch certain fields.
FIGURE 13.7PRINS Application-Layer Protection (JOSE on JSON)
Purpose: how PRINS squares the circle — letting intermediaries do their job without trusting them with everything. Sensitive fields are encrypted; modifiable fields carry a signed audit trail of who changed what.
FIGURE 13.8Encryption and Modification Policies per IE
Purpose: the granularity of PRINS. Each IE is classified — encrypt, integrity-only, or modifiable — and the two SEPPs must agree. Getting this policy wrong is how sensitive fields leak or get tampered.
13.4 IPX, Topology Hiding, and Filtering
FIGURE 13.9IPX Provider — Authorized Modification
Purpose: intermediaries as accountable participants, not silent men-in-the-middle. An IPX can do its routing/mediation job, but every change it makes is bounded by policy and cryptographically attributable.
FIGURE 13.10Topology Hiding at the SEPP
Purpose: denying reconnaissance. A roaming partner (or an attacker who reaches it) should not learn your core’s internal addressing — topology hiding rewrites it to opaque references at the border.
FIGURE 13.11Message Filtering and Validation Pipeline
Purpose: the SEPP’s active defense. Encryption protects content; filtering stops malicious-but-valid messages — the exact gap that made SS7 dangerous.
FIGURE 13.12Inter-PLMN Certificate Management
Purpose: trust at the border is PKI at the border — across many operators. The federation’s certificate hygiene determines who your SEPP will accept N32 sessions from.
FIGURE 13.13Roaming Hub Models and Trust
Purpose: roaming at scale. Hubs simplify many-to-many connectivity but become high-value intermediaries — understand exactly what a hub can see and modify under your N32 policy.
FIGURE 13.14Roaming Attacks vs SEPP Controls
Purpose: the chapter’s payoff — each historic interconnect attack and the specific SEPP mechanism that now blocks it. This table is the argument for why the SEPP exists.
FIGURE 13.15Local Breakout vs Home-Routed — Security Comparison
Purpose: the architectural trade-off behind roaming security. Where traffic breaks out decides who sees user data and who controls policy — a security decision, not just a latency one.
13.5 The Practical Operator View
Route 100% of inter-PLMN signaling through the SEPP — no exceptions, no “temporary” bypasses (Chapter 1/25).
Enable and tune message filtering — it’s what actually stops SS7-style attacks; encryption alone doesn’t.
Choose TLS vs PRINS per partner based on whether an IPX must touch IEs; review per-IE policies carefully.
Manage SEPP certificates across the federation — rotation and revocation affect both availability and security.
Enable topology hiding so partners never see your internal structure.
Pull SEPP logs first for any roaming incident (Chapter 26/27).
Common misconfiguration risks
Message filtering disabled “temporarily” to onboard a partner → SS7-class exposure returns.
Over-permissive PRINS modification policy → IPX can alter sensitive fields.
Sensitive IEs not marked for encryption → keys/identities readable by intermediaries.
Topology hiding off → internal addressing leaked to partners.
Stale/over-trusted partner certificates accepted.
13.6 Threats and Mitigations
Threat
Vector
SEPP defense
Subscriber location tracking
interconnect query
message filtering, authorization per partner
Call/SMS interception
fake registration
authenticated N32, filtering
Key/vector theft
interception in transit
PRINS encryption / TLS
Topology recon
internal IDs in messages
topology hiding
Signaling DoS
flood from partner
rate limiting + anomaly filtering
Unauthorized IE modification
malicious IPX
PRINS modification policy + signatures
13.7 Terminology, Example, Checklist
Term
Meaning
SEPP
Security Edge Protection Proxy — the PLMN border guard
N32-c / N32-f
SEPP control (handshake/policy) / forwarding (protected signaling)
TLS mode / PRINS
Direct SEPP-to-SEPP TLS / application-layer JOSE protection across IPX
IPX
IP eXchange — roaming interconnect intermediary
topology hiding
Rewriting internal addresses/FQDNs to opaque references
JOSE (JWE/JWS)
JSON encryption/signature used by PRINS
Real network example. An operator onboarding a new roaming partner hit interop problems and, under launch pressure, disabled SEPP message filtering “just for this partner, just for now” to get traffic flowing. The bypass was forgotten. Months later, a security assessment found that partner’s interconnect could send subscriber-location queries straight into the core — a textbook SS7-era attack, reborn over 5G. No filtering meant no border. Fix: re-enable filtering with a partner-specific allowlist of message types, add a configuration-drift alarm on any SEPP with filtering disabled, and a policy that no partner goes live with filtering off. The SEPP only protects you if it’s actually inspecting traffic — encryption without filtering still lets malicious-but-valid messages through.
Confirm all inter-PLMN signaling traverses the SEPP; no bypasses.
Verify message filtering is enabled with per-partner allowlists.
Alarm on any SEPP with filtering/protection disabled (drift detection).
★ Chapter Summary
SS7/Diameter roaming trusted every peer; 5G’s SEPP is an authenticated, integrity-protected, filterable border between operators.
All inter-PLMN SBI crosses vSEPP ↔ hSEPP over N32; N32-c negotiates security, N32-f carries protected traffic.
TLS mode for transparent interconnect; PRINS (JOSE) when IPX intermediaries must read/modify specific IEs while the rest stays end-to-end protected.
Topology hiding denies recon; message filtering stops malicious-but-valid messages — the actual SS7-attack fix.
Per-IE protection policy and inter-PLMN certificate management are the configuration items that make or break interconnect security.
? Review Questions
Why were SS7 and Diameter interconnects insecure, and what core assumption did the SEPP overturn?
Distinguish N32-c and N32-f and what each carries.
When would you choose PRINS over TLS mode, and what does PRINS let an IPX do safely?
Explain how PRINS protects a message with encrypted, integrity-only, and modifiable IEs simultaneously.
Why does encryption alone not stop SS7-style attacks, and what SEPP feature does?
What is topology hiding and what attacker activity does it deny?
A partner is onboarded with SEPP filtering disabled. What specific attack becomes possible and how do you remediate?
Compare home-routed and local-breakout roaming from a security/trust standpoint.
🧪 Mini lab — design an N32 protection policy
On paper, build the N32 security configuration for a roaming partner whose IPX must read PLMN routing and adjust certain charging IEs: (1) Decide TLS vs PRINS and justify it. (2) Classify each of these IEs as encrypt / integrity-only / modifiable: SUPI, authentication vector, PLMN ID, charging characteristics, NF FQDN. (3) Write three message-filtering rules (which message types from this partner you allow/deny). (4) State your topology-hiding policy. (5) Red-team it: as a malicious IPX or a hostile partner, what would you try, and which of your settings stops it? You've now authored the exact configuration that turns a roaming agreement into a secure border.