When two hosts or networks need to communicate securely using IPSec, they don't simply encrypt packets and hope the receiver can decrypt them. Instead, they establish a Security Association (SA)—a carefully negotiated agreement that defines exactly how security services will be applied to their communication.

Think of an SA as a security contract between two parties. Before any encrypted data flows, both sides must agree on:

• What cryptographic algorithms will be used
• What keys will protect the data
• How long this agreement remains valid
• Which traffic is covered by this agreement

Without Security Associations, IPSec would be chaos. Each packet would need to carry its own negotiation data, and receivers would have no way to know how to decrypt or verify incoming packets. SAs provide the essential framework that makes IPSec practical and scalable.

A Security Association (SA) is a simplex (one-way) logical connection that provides security services to the traffic carried over it. In formal terms, an SA is a set of security parameters that define a specific security relationship between two communicating entities.

The Formal Definition (RFC 4301):

An SA is:

"A simplex 'connection' that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of either AH or ESP, but not both."

Let's break this definition down systematically:

The unidirectional (simplex) nature of Security Associations is one of the most critical concepts to understand. This design choice isn't arbitrary—it provides flexibility and security benefits that a bidirectional model wouldn't allow.

Why Unidirectional?

Consider a scenario where Host A and Host B need secure communication:

Benefits of Unidirectional SAs:

When an IPSec-protected packet arrives at its destination, the receiver must determine which Security Association applies to that packet. How does it know which decryption key to use? Which integrity algorithm to apply? The answer lies in the Security Parameters Index (SPI).

What is the SPI?

The SPI is a 32-bit identifier included in every AH and ESP header. When combined with the destination IP address and the security protocol (AH or ESP), it uniquely identifies the SA to be used for processing that packet.

SPI Assignment Rules:

The SPI is chosen by the receiving party during SA negotiation, not the sender. This is crucial:

1. When Host A wants to send protected traffic to Host B, Host B chooses the SPI for that SA
2. Host B guarantees this SPI is unique among all its inbound SAs for that protocol
3. Host A includes this SPI in every packet it sends to Host B
4. When Host B receives a packet, it uses (SPI, Destination IP, Protocol) to look up the correct SA

Reserved SPI Values:

Certain SPI values are reserved and cannot be used for normal SAs:

A critical rule of IPSec architecture is that each SA is associated with exactly one security protocol—either AH or ESP, never both. This might seem limiting, but it provides clarity and flexibility in implementation.

Why One Protocol Per SA?

Each protocol has different header formats, different processing requirements, and different security services. Mixing them in a single SA would create complex state management and ambiguous packet processing. Instead, when both AH and ESP protection are needed, multiple SAs are used together through SA Bundling.

SA Bundling for Combined Protection:

When an application requires both AH and ESP protection (for example, encrypting the payload while also authenticating the IP header), multiple SAs are bundled together. There are two approaches:

Each Security Association operates in one of two modes: Transport Mode or Tunnel Mode. The mode determines how IPSec encapsulates the original IP packet and significantly affects the SA's behavior and use cases.

Transport Mode:

In transport mode, the original IP header is preserved, and only the IP payload (transport layer and above) is protected by IPSec. The security header (AH or ESP) is inserted between the original IP header and the transport layer header.

Tunnel Mode:

In tunnel mode, the entire original IP packet (header and payload) is encapsulated within a new IP packet. The security header protects the complete original packet, and a new outer IP header is added for routing.

Security Associations are not permanent structures. They have a defined lifecycle that includes establishment, active use, and termination. Understanding this lifecycle is essential for maintaining secure communications and implementing proper key management.

SA Lifecycle Phases:

SA Lifetime Types:

Security Associations have two types of lifetimes that determine when rekeying or termination occurs:

In modern IPSec implementations using IKEv2, there are two distinct types of Security Associations with different purposes and characteristics:

IKE SA (IKEv2 SA):

The IKE SA is a bidirectional security association used to protect the IKE protocol traffic itself. It's established during the initial IKE_SA_INIT and IKE_AUTH exchanges and provides:

• Encryption and integrity for all subsequent IKE messages
• Authentication of the communicating parties
• The secure channel over which Child SAs are negotiated
• Key material derivation for Child SAs

Child SA (IPSec SA):

Child SAs are the actual IPSec SAs (using AH or ESP) that protect user traffic. They're created under the protection of an existing IKE SA and are what we typically refer to when discussing IPSec SAs.

We've established a solid foundation for understanding Security Associations—the architectural cornerstone of IPSec. Let's consolidate the key concepts:

What's Next:

Now that we understand what Security Associations are and how they're identified, the next page dives into SA Parameters—the specific cryptographic and operational values that each SA contains. We'll examine encryption algorithms, authentication methods, sequence numbers, and all the other parameters that make an SA functional.