Security association
A security association (SA) is a simplex logical connection in the Internet Protocol Security (IPsec) architecture that provides a set of security services, such as confidentiality, data integrity, and authentication, to the IP traffic it carries between two communicating parties.[1] It is unidirectional, meaning a pair of SAs is typically required for bidirectional communication, and it is identified uniquely by a combination of a 32-bit Security Parameters Index (SPI), the destination IP address, and the security protocol identifier (either Authentication Header (AH) or Encapsulating Security Payload (ESP), but not both on the same SA).[1] SAs are established either manually or automatically, most commonly through the Internet Key Exchange (IKE) protocol, and they apply consistent cryptographic processing to all traffic traversing them.[2] In IPsec, SAs form the core mechanism for implementing security at the network layer, supporting both IPv4 and IPv6 environments.[3] Each SA specifies critical parameters stored in the Security Association Database (SAD), including cryptographic algorithms and keys for encryption or authentication, a sequence number counter for replay protection, an anti-replay window, and lifetime limits based on time or data volume after which the SA expires and must be renegotiated.[4] The Security Policy Database (SPD) complements the SAD by defining which traffic requires SA protection and selecting appropriate SAs based on traffic selectors like IP addresses, ports, and protocols.[5] SAs operate in one of two modes: transport mode, which secures the payload of an IP packet end-to-end, or tunnel mode, which encapsulates the entire IP packet for gateway-to-gateway or host-to-gateway VPN scenarios.[6] The establishment and management of SAs ensure scalable and secure communications, with IKE handling key negotiation and SA parameters to maintain forward secrecy and resist attacks.[2] While SAs primarily support unicast traffic, extensions allow for multicast group security, enabling applications like secure video conferencing.[7] Overall, the SA concept abstracts the complexities of cryptographic operations, allowing IPsec implementations to provide robust protection against eavesdropping, tampering, and impersonation in diverse network topologies.[8]Fundamentals
Definition
A security association (SA) is a simplex (unidirectional) connection between two IPsec endpoints that specifies the security parameters for protecting network traffic flowing in one direction, including mechanisms for encryption, authentication, and integrity.[1] This construct ensures that all packets traversing the SA receive identical security treatment, implemented via either the Authentication Header (AH) or Encapsulating Security Payload (ESP) protocol, but not both simultaneously.[1] The concept of an SA was introduced as part of the IPsec protocol suite to establish a shared security context between communicating parties without requiring per-packet negotiation, thereby enabling efficient protection of IP-layer traffic.[9] It originated in the initial IPsec architecture defined in RFC 2401 (November 1998) and was updated and refined in RFC 4301 (December 2005), which obsoletes the earlier specification to incorporate improvements in processing models and protocol integration.[10] RFC 4301 maintains the core SA framework while enhancing support for both IPv4 and IPv6 environments.[11] Core attributes of an SA include its uniqueness, achieved through a 32-bit Security Parameter Index (SPI) that, combined with the destination IP address and security protocol identifier, distinguishes it from other SAs at the receiver.[12] Due to its unidirectional nature, inbound and outbound SAs are maintained separately; bidirectional communication thus requires a pair of SAs, one for each direction.[1] For unicast traffic, the SPI and destination IP address suffice for identification, whereas for multicast SAs, the source IP address is also required.[5] For instance, in a virtual private network (VPN) tunnel, an SA might define AES-256 in cipher block chaining (CBC) mode for encryption alongside HMAC-SHA-256 for authentication, ensuring confidentiality and data integrity for the protected traffic.Key Components
A security association (SA) in IPsec consists of a set of parameters that define the security services applied to traffic between two endpoints. These components ensure confidentiality, integrity, authentication, and protection against replay attacks, with specifics varying based on the protocol used, such as Encapsulating Security Payload (ESP) or Authentication Header (AH).[4] Essential parameters include the cryptographic algorithms selected for the SA. For ESP, these encompass an encryption algorithm (e.g., AES in CBC mode), its associated symmetric key, initialization vector (IV) handling, an integrity algorithm (e.g., HMAC-SHA-256), and its key; combined-mode algorithms providing both encryption and integrity may also be specified. For AH, the parameters focus on an authentication algorithm (e.g., HMAC-SHA-1) and its symmetric key, without encryption. Keying material comprises these symmetric keys, which are established for cryptographic operations within the SA. Sequence numbers, typically a 64-bit counter (with only the low-order 32 bits transmitted in headers), provide ordering and support anti-replay mechanisms. Path MTU considerations are also included, particularly for tunnel-mode SAs, where the endpoint tracks the maximum transmission unit to avoid fragmentation issues during processing.[4][13][14][15] The Security Parameter Index (SPI) is a 32-bit unsigned integer that uniquely identifies an SA for a given endpoint, appearing in the ESP or AH header to map incoming packets to the correct SA parameters. The sender selects and inserts the SPI into outbound packets, while the receiver uses it for lookup and application of the associated security services.[1][16] Lifetime parameters govern the duration of an SA's validity, expressed as soft and hard timeouts measured in seconds or bytes processed. A soft lifetime serves as a warning threshold to initiate rekeying before expiration, while the hard lifetime enforces termination of the SA to limit exposure if rekeying is delayed.[4] The anti-replay window prevents duplicate packet acceptance by maintaining a sliding window of recent sequence numbers, with a minimum supported size of 32 packets but a preferred default of 64 packets. This mechanism, enabled by default for SAs with integrity protection, discards packets falling outside the window or duplicating those within it, using a bit-map to track received sequences efficiently.[17][18] For instance, a typical ESP-based SA might specify AES-128 in CBC mode for encryption with a 128-bit key, HMAC-SHA-256 for integrity with a 256-bit key, a 64-packet anti-replay window, and a lifetime of 3600 seconds (1 hour).[13]Role in IPsec
Integration with IPsec Protocols
IPsec employs security associations (SAs) as the fundamental building blocks to deliver security services at the IP layer, primarily through the Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols.[19] AH provides connectionless integrity, data origin authentication, and optional protection against replay attacks, while ESP offers confidentiality via encryption, along with optional integrity and authentication services.[20][21] Each SA represents a simplex (one-way) connection between communicating parties, identified by a Security Parameter Index (SPI), the destination IP address, and the protocol identifier (AH or ESP), enabling the application of these services to specific traffic flows.[19] In outbound traffic processing, IPsec implementations select an SA based on matching the packet against entries in the Security Policy Database (SPD), which dictates whether protection is required and specifies the applicable SA parameters such as algorithms and keys.[19] The selected SA then guides the addition of AH or ESP headers to the packet before transmission. For inbound packets, the receiver uses the SPI from the AH or ESP header, combined with the destination IP address and protocol, to locate the corresponding SA in the Security Association Database (SAD), after which the packet undergoes decryption, authentication, and validation using the SA's parameters.[19] Security associations operate in two primary modes within IPsec: transport mode and tunnel mode. Transport mode secures only the payload of the IP packet, protecting upper-layer protocols between hosts without altering the original IP header, making it suitable for end-to-end communications.[19] In contrast, tunnel mode encapsulates the entire original IP packet within a new IP header, securing both the payload and the inner header, which is typically used between security gateways for site-to-site VPNs. Both modes rely on SAs to define the security parameters applied during processing.[19] Integration with key management protocols, such as Internet Key Exchange version 2 (IKEv2), allows SAs to be dynamically established and maintained for IPsec operations. IKEv2 creates an initial IKE SA for authentication and key derivation, followed by child SAs that directly support AH and ESP traffic protection, negotiating transforms like encryption algorithms and traffic selectors to align with IPsec policies.[22] If no matching SA is found during inbound processing, the packet is discarded, and an auditable security event is logged, including details such as the SPI, source and destination addresses, and protocol type, to facilitate diagnostics without compromising security.[19] Similarly, outbound packets without a policy match in the SPD result in discard, potentially triggering an ICMP error message if appropriate.[19]Security Association Database
The Security Association Database (SAD) serves as the primary repository in IPsec implementations for storing parameters associated with active Security Associations (SAs). It maintains a collection of entries, each corresponding to an individual SA, which defines the security processing applied to inbound and outbound traffic. These entries are essential for efficient packet handling, enabling the system to apply cryptographic protections without repeated negotiation.[4] The structure of the SAD consists of a list of SA entries, typically indexed by the Security Parameter Index (SPI)—a 32-bit value uniquely identifying the SA—along with the destination IP address and the IPsec protocol (such as Authentication Header [AH] or Encapsulating Security Payload [ESP]). For unicast SAs, indexing relies primarily on the SPI and protocol; multicast SAs additionally incorporate source and destination IP addresses to resolve ambiguities, using a longest-match algorithm. Each entry encapsulates comprehensive SA parameters, including cryptographic keys, selected algorithms for authentication and encryption, sequence number counters (32-bit for basic sequence numbers, 64-bit for Extended Sequence Numbers),[23] anti-replay windows (a bit-map for detecting duplicates), lifetimes (soft and hard limits based on time or byte/packet counts), IPsec protocol mode (transport or tunnel), and additional fields like Path MTU, Differentiated Services Code Point (DSCP) handling, and stateful fragment checking flags. These parameters ensure consistent security application while supporting features like replay protection and efficient key management.[4][24][1] Operations on the SAD focus on maintaining its integrity during traffic processing. For inbound packets, the system performs a lookup using the SPI extracted from the AH or ESP header, potentially augmented by IP addresses for multicast scenarios, to retrieve the corresponding SA entry and apply decryption, authentication, or both. Insertion occurs when an SA is established, populating the entry with negotiated parameters from key management protocols; this links the SA to selectors derived from the Security Policy Database (SPD). Deletion happens automatically upon SA expiration (based on lifetime thresholds) or manually during teardown, though entries may persist briefly post-SPD updates to avoid disrupting active sessions. These operations ensure low-latency processing, with lookups designed for rapid access in high-throughput environments.[25][26][27] The SAD interacts closely with the SPD to enforce security policies. After an inbound packet matches an SPD entry requiring protection, the SAD is consulted using the packet's SPI to validate and apply the SA; mismatches result in discard. For outbound traffic, once the SPD selects a policy, the corresponding SA is either created (inserting a new SAD entry with selectors from the SPD and packet details) or retrieved if extant. This integration ensures policy-driven security without redundant checks, where SAD entries may include "populate from packet" flags to refine selectors dynamically from SPD values like address ranges or port specifications. SAD entries can exist independently of the SPD for manually configured SAs, providing flexibility in hybrid setups.[27][26] In practical implementations, the SAD is maintained in kernel space for performance, allowing direct access during packet processing without user-space overhead. This kernel-level storage, part of frameworks like Linux's XFRM, minimizes latency and supports high-speed networks. To mitigate denial-of-service risks from resource exhaustion—such as excessive SA creation via flooded negotiations—implementations often enforce limits on SAD size and incorporate mechanisms like rate-limiting or cookie-based validation during SA establishment.[28][29][29] For example, in Linux environments, tools such as strongSwan or ipsec-tools interface with the kernel to manage SAD entries. Administrators can view active SAs using theip xfrm state command from the iproute2 suite, which displays details like SPIs, endpoints, algorithms, and lifetimes, aiding in monitoring and troubleshooting. This command-line visibility supports operational efficiency in production deployments.[30][31]