Security Policy Database

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.

Key Features

• Stores ordered security policy rules for IP packet classification
• Defines actions: PROTECT (IPsec), BYPASS, or DISCARD for matched packets
• Uses packet selectors (IP addresses, ports, protocol) for rule matching
• Interworks with the Security Association Database (SAD) to enforce cryptography
• Applied to both inbound and outbound traffic for comprehensive policy enforcement
• Central to the 3GPP Network Domain Security/IP (NDS/IP) architecture

Evolution Across Releases

Defining Specifications