SPD

Security Policy Database

Security →
Introduced in Rel-8 Also in: Services

SPD is a database that stores IPsec security policies to define and enforce the security services applied to IP packets traversing a secure interface.

Category
Security
Introduced
Rel-8
Where
Core Network › Evolved Packet Core
Also touches
1 segments
Specifications
8 specs
SPD Description Purpose Related Classification Detected Changes Specifications

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

Part ofIPSec
Related approachesSAD

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-15 1 change

In Release 15, the SPD function was updated to expand its scope within the NDS/IP framework. This update specifically introduced the integration of application layer cryptographic profiles.

  • Update NDS/IP scope with application layer crypto profiles TS 33.210CR0050
Rel-16 2 changes

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.

  • Update NDS/IP scope with application layer crypto profiles TS 33.210CR0056
  • Editorial corrections to NDS/IP TS 33.210CR0068
Rel-17 3 changes

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.

  • Security updates for algorithms and protocols for 33.210 TS 33.210CR0072
  • Update IPSec references to rfc8221 TS 33.210CR0073
  • Update IPSec reference from obsolete RFC 7296 to RFC 8247 TS 33.210CR0074

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.

SpecificationTitleRelease
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