Part 5 · Privacy, Slicing, Edge, and Special Networks

Network Slicing Security

Selling many logical networks on one infrastructure — and keeping them apart

"A slice boundary is a business boundary, a regulatory boundary, and — whether you designed it that way or not — a security boundary." — THE SLICING PRINCIPLE

Network slicing lets one physical 5G network present as many logical networks — an eMBB slice for consumers, a URLLC slice for a factory, an isolated slice for a hospital. Each slice may have a different tenant, SLA, and security requirement. This chapter covers the S-NSSAI, the NSSF, slice-specific authentication (NSSAA), and — the heart of it — isolation: keeping one tenant's traffic, data, and failures out of another's.

🎯 Learning objectives

Explain S-NSSAI and the NSSAI variants.
Describe the NSSF role and NSSAI privacy.
Explain NSSAA — slice-specific authentication.
Cover isolation: control plane, user plane, management, resources.
Address tenant isolation and enterprise slice protection.

📘 Standards reference box — Chapter 20

Specification	Title	Release / version verified
TS 33.501	5G security — NSSAA, slice security	Rel-18, v18.11.0 (2026-04)
TS 23.501	S-NSSAI, NSSF, slice architecture	Rel-19, v19.6.0
GSMA	Network slicing security guidance	current

Checked June 2026 — verify against the latest 3GPP version.

20.1 Slicing in One Page

FIGURE 20.1Slicing — One Infrastructure, Many Logical Networks

Purpose: the slicing value proposition and its risk. One infrastructure, many tenants — so isolation between them becomes a primary security concern.

FIGURE 20.2S-NSSAI Structure — SST + SD

Purpose: the slice identifier. SST says what kind of slice; SD distinguishes tenants — and because SD can identify a specific enterprise, it has privacy implications on the air.

FIGURE 20.3NSSAI Variants — Requested, Allowed, Configured, Rejected

Purpose: slice access is negotiated. The network grants "allowed" slices from the UE's "requested" set — an authorization checkpoint, not an automatic grant.

FIGURE 20.4NSSF in Slice Selection

Purpose: who decides which slices a UE gets. The NSSF combines the request, subscription, and policy — integrity of this decision underpins tenant isolation.

FIGURE 20.5NSSAI Privacy — RRC vs NAS Exposure

Purpose: slice IDs are metadata that can identify a tenant. Exposing them in clear can reveal that a device belongs to, say, a specific defense contractor — protect them like the privacy data they are.

20.2 Isolation — the Core of Slice Security

FIGURE 20.6Slice Isolation Layers

Purpose: isolation is not one thing. A slice can be perfectly signaling-isolated yet still be starved of resources by a noisy neighbor — true isolation means all four layers.

20.3 NSSAA — Slice-Specific Authentication

FIGURE 20.7NSSAA — Architecture

Purpose: slices can demand their own authentication. NSSAA lets an enterprise require its own credential check (to its own AAA) before a subscriber may use its slice — defense in depth at the slice level.

FIGURE 20.8NSSAA Message Flow (EAP to AAA)

Purpose: the NSSAA exchange. EAP runs to the tenant's AAA after network authentication; only on success is the slice granted — the enterprise controls its own slice membership.

FIGURE 20.9NSSAA Revocation and Re-authentication

Purpose: the enterprise keeps the keys to its own slice. Revocation lets a tenant cut off a device (e.g., a departed employee's phone) without involving the operator's subscription system.

20.4 Tenant Isolation and Shared NFs

FIGURE 20.10Shared NF Risk — One AMF, Many Slices

Purpose: the central isolation trade-off. Sharing NFs is efficient but creates cross-tenant exposure; sensitive slices may warrant dedicated NFs.

FIGURE 20.11Tenant Isolation in a Multi-Tenant Core

Purpose: what tenant isolation means in practice. Each tenant sees only its own world — data, KPIs, and management — and cannot even discover the existence of others.

FIGURE 20.12Slice Resource Starvation Attack

Purpose: the availability face of slicing security. Without resource isolation, one slice can starve another — turning a noisy neighbor (or attacker) into an SLA-breaking weapon.

FIGURE 20.13Enterprise Slice — Reference Security Architecture

Purpose: the blueprint for a serious enterprise slice. Combine tenant-controlled authentication, multi-layer isolation, required UP integrity, and (often) edge breakout — not the eMBB defaults (Chapter 9 example).

FIGURE 20.14Slice Security SLA Parameters

Purpose: slice security is contractual. These parameters are what an enterprise and operator negotiate — security becomes a line-item in the slice SLA.

FIGURE 20.15Slice Security Audit Checklist

Purpose: the slice audit on one card. The recurring failure is enterprise slices silently inheriting consumer (eMBB) defaults — this checklist catches it.

20.5 The Practical Operator View

Verify all four isolation layers per slice — CP, UP, management, resource. CP-isolated ≠ isolated.
Never inherit eMBB defaults into enterprise/critical slices (set UP integrity = required, Chapter 9).
Offer NSSAA so tenants control their own slice membership and revocation.
Enforce resource quotas — slicing's SLA promise is hollow without anti-starvation.
Treat S-NSSAI/SD as sensitive metadata — protect it to avoid leaking tenant membership.

Common misconfiguration risks

Enterprise slice inheriting eMBB UP-security defaults (no integrity).
Only control-plane isolation; no resource isolation → starvation.
Shared NFs for highly sensitive slices without dedication.
S-NSSAI/SD exposed in clear → tenant membership leaked.
NSSAA absent where a tenant needs to control/revoke access.

20.6 Threats and Mitigations

Threat	Vector	Defense
Cross-slice leakage	shared NF bug/compromise	isolation, dedicated NFs for sensitive slices
Resource starvation	noisy/attacking slice	resource quotas/reservations
Unauthorized slice access	weak slice authorization	NSSAA, subscription checks
Tenant membership leak	S-NSSAI in clear	protect NSSAI under security
Stale access	departed users keep slice	NSSAA revocation
Weak enterprise slice	eMBB defaults inherited	per-slice security policy

20.7 Terminology, Example, Checklist

Term	Meaning
S-NSSAI (SST+SD)	Slice identifier: type + tenant differentiator
NSSAI variants	Configured / Requested / Allowed / Rejected
NSSF	Network Slice Selection Function
NSSAA / NSSAAF	Slice-specific authentication / its AAA-relay function
isolation (4 layers)	Control plane, user plane, management, resource

Real network example. An operator sold a "secure isolated slice" to a hospital. An audit found the slice had dedicated UPFs (UP isolation) but shared signaling NFs with no resource quotas. During a busy event, a consumer eMBB slice's signaling surge exhausted the shared AMF/SMF capacity, and the hospital slice's session setups began failing — its life-safety SLA breached not by an attack on it, but by a noisy neighbor it was supposed to be isolated from. The contract said "isolated"; only one of four isolation layers was real. Fix: resource reservations for the hospital slice and dedicated signaling capacity for critical slices. "Isolated" is a four-part claim — verify all four, or the word is marketing.

Verify CP, UP, management, and resource isolation per slice.
Confirm enterprise/critical slices use required UP integrity (not eMBB defaults).
Confirm NSSAA + revocation where the tenant needs control.
Confirm resource quotas/reservations against starvation.
Confirm S-NSSAI/SD is protected (no clear-text tenant leak).
Test tenant management isolation (no cross-tenant visibility).

★ Chapter Summary

A slice (S-NSSAI = SST+SD) is a logical network for a tenant; the slice boundary is a security boundary.
The NSSF authorizes slice access; S-NSSAI/SD can leak tenant membership — protect it.
NSSAA lets a tenant run its own authentication (and revocation) to its AAA, on top of network 5G-AKA.
Isolation has four layers — control plane, user plane, management, resource; all must hold for true separation.
The classic failures: enterprise slices inheriting eMBB defaults, and "isolation" that omits resource quotas (starvation).

? Review Questions

What does an S-NSSAI contain, and why can the SD be privacy-sensitive?
Distinguish requested, allowed, configured, and rejected NSSAI.
What is NSSAA, when is it used, and what control does it give a tenant?
Name the four isolation layers and give an attack that defeats a slice isolated on only some of them.
Why is resource isolation essential to slicing's SLA promise?
What is the risk of shared NFs across slices, and the mitigation for sensitive slices?
How should an enterprise slice differ in security config from a consumer eMBB slice?
A "secure isolated" slice fails during a neighbor's traffic surge. Diagnose and fix.

🧪 Mini lab — design a hospital slice

On paper (or in Open5GS with multiple S-NSSAIs configured): (1) Define the S-NSSAI for a hospital slice and decide whether the SD reveals the tenant. (2) Specify all four isolation layers — what's dedicated vs shared, and the resource reservation. (3) Decide whether NSSAA applies and to whose AAA. (4) Set the UP security policy (required, not preferred — Chapter 9). (5) Now red-team it: as a noisy consumer slice or a malicious tenant, how would you degrade or peek into the hospital slice — and which of your four isolation layers stops each attempt? You've now written a slice security SLA that distinguishes "isolated" from "marketing."