Description
The Security Policy Database (SPD) is a fundamental element within the 3GPP IPsec security architecture, as defined in specifications such as 33.210. It operates in conjunction with the Security Association Database (SAD) to enforce security policies for IP traffic. The SPD contains an ordered list of policy entries, each specifying selectors (such as source/destination IP addresses, transport protocol, and port numbers) and an associated action for packets matching those selectors. The possible actions are typically PROTECT (apply IPsec), BYPASS (allow without IPsec), or DISCARD (block). When a packet is processed (either inbound or outbound), the system consults the SPD to determine the appropriate security treatment based on the packet's header fields.
The SPD's role is critical for packet classification. For outbound traffic, the SPD entry dictates whether the packet requires IPsec protection and, if so, points to the specific Security Association (SA) in the SAD that contains the cryptographic algorithms, keys, and parameters to use. The system uses the selectors from the matched SPD entry to search the SAD for an existing SA or to trigger the creation of a new one via IKEv2. For inbound traffic, after IPsec processing (decryption/authentication), the packet is again checked against the SPD to ensure the applied security matches the policy, providing a final security validation.
Architecturally, the SPD is a logical construct that can be implemented in various network elements requiring IPsec, such as the Security Gateway (SEG) in the NDS/IP framework or the user equipment. Its management is crucial; policies can be provisioned statically or dynamically. The SPD's ordered nature means the first matching rule is applied, requiring careful policy design to avoid conflicts. It enables granular control, allowing operators to define different security levels for different types of traffic (e.g., signaling vs. user plane) between network domains, forming the policy enforcement cornerstone of the 3GPP Network Domain Security (NDS) model.
Purpose & Motivation
The SPD was introduced to address the critical need for standardized, policy-driven security in the IP-based core network interfaces defined by 3GPP. As mobile networks evolved from circuit-switched to all-IP architectures, the signaling and user data traversing inter-operator and intra-operator interfaces became vulnerable to eavesdropping, spoofing, and other attacks. The primary problem was the lack of a unified, configurable mechanism to mandate and apply cryptographic protection selectively to different traffic flows.
Prior to the formalization of the SPD within 3GPP's NDS/IP, security implementations were often ad-hoc. The SPD, as a concept borrowed and adapted from IETF IPsec standards, provides a structured database that solves the problem of 'what to protect.' It allows network architects and security officers to explicitly define which IP packets must be protected, which can pass in the clear, and which should be blocked. This moves security from an implicit, hard-coded feature to an explicitly managed policy. Its creation was motivated by the requirement for a scalable, interoperable security framework that could accommodate the diverse and growing number of network interfaces (e.g., Nn, Np, S1, X2) while allowing operators flexibility in their security posture based on risk assessment and regulatory requirements.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (6 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 16, the SPD function was updated to extend its scope to include application layer cryptographic profiles, allowing security policies to govern higher-layer protocols. Additionally, the release included editorial corrections to the NDS/IP (Network Domain Security for IP) specifications to improve clarity.
In Release 17, the SPD function was updated by modernizing its foundational IPSec protocol references. Specifically, the obsolete RFC 7296 reference was replaced with RFC 8247, and additional updates were made to align with RFC 8221. These changes ensured the SPD's policies and procedures were based on current and maintained security standards.
Explore further
Broader topics and technologies where SPD plays a role.
Defining Specifications
3GPP specifications that define or reference SPD, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 26.071 vj00 | AMR Speech Codec Introduction | Rel-19 |
| TS 26.102 vj00 | Mapping of AMR and other codecs to interfaces | Rel-19 |
| TS 26.171 vj00 | Introduction to AMR-WB Speech Processing | Rel-19 |
| TS 26.202 vj00 | AMR-WB Speech Codec Mapping Specification | Rel-19 |
| TS 29.204 vj00 | SS7 Security Gateway Functional Description | Rel-19 |
| TS 33.204 vj00 | TCAP Security (TCAPsec) Stage 2 Specification | Rel-19 |
| TS 33.210 vj20 | UMTS Security for IP Networks | Rel-19 |
| TR 33.916 vj00 | 3GPP Security Assurance Methodology (SECAM) | Rel-19 |