skip to content

In IPsec, what is a Security Association, and why does protecting two-way traffic between two gateways take a pair of them?

level: juniorimportance: must knowfreq 42%

answer

  1. simplex, not a connection
  2. one direction, one protocol
  3. the receiver names it
  4. created as a pair

basics

~20 s

An IPsec Security Association is one-way state: the keys, algorithms, counters and selectors protecting traffic in a single direction with AH or ESP. Two-way traffic therefore needs two SAs, one per direction, each with its own SPI.

solid answer

~40 s

RFC 4301 defines a Security Association as a simplex "connection": one direction, one security protocol (AH *or* ESP), with its own keys, algorithms, sequence counter, lifetime and traffic selectors held in an entry of the Security Association Database (SAD). Gateway A's outbound SA is gateway B's inbound SA, and the reverse path needs a second SA; IKE creates the two as a pair, both in the same mode, with separate keying material for each direction. Each SA is named by a 32-bit `SPI` that its *receiving* end chose, so the two halves of a pair carry independently chosen SPIs. Protecting the same traffic with both AH and ESP takes one more SA in each direction, because an SA uses one protocol, never both.

go deeper

for a junior

Recall that an IPsec SA is one-way and uses AH or ESP, so a two-way tunnel needs a pair, one per direction.

for a middle

Explain what an SA's SAD entry holds and why the SPI, keys, counters and replay window are naturally per direction, and who chooses each SPI.

for a senior

Use the pair to localise faults: read per-SA counters on both gateways to find which half of a tunnel is broken before touching keys or proposals.

for a principal

Weigh SA granularity: one pair per subnet pair, per host pair or per traffic class changes how much state, rekeying and failure isolation a gateway estate carries.

## What a Security Association is IPsec does not keep a "tunnel object" with two ends. Its unit of state is the **Security Association (SA)**, which RFC 4301 defines as a *simplex* "connection" that affords security services to the traffic carried by it. Three properties follow from that definition: - **One direction.** An SA protects packets flowing from one sender to one receiver. The reverse path is a different SA. - **One protocol.** An SA uses **AH or ESP, but not both**. Traffic that must be protected by both needs two SAs per direction, applied one after the other. - **One set of parameters.** Keys, algorithms, mode, counters and the traffic it may carry are fixed per SA and stored in that SA's entry in the **Security Association Database (SAD)**. RFC 4301 is the current architecture; it obsoleted RFC 2401 and dropped the requirement to support RFC 2401's "SA bundles", so stacking AH and ESP is now built from separate SAs plus policy and forwarding configuration. ## Why the state is one-way The parameters that matter on the wire really are per direction: | Per-SA item | Why it belongs to one direction | |---|---| | `SPI` | Chosen by the **receiver** to find its own SAD entry; each side picks the SPI for the SA it receives on | | Keys | IKEv2 takes the keys for initiator-to-responder SAs from its key material before those for the reverse direction, so the two SAs get separate keys | | Sequence number counter | Kept by the sender of that SA | | Anti-replay window | Kept by the receiver of that SA | | Lifetime counters | Time and byte counts measured on that SA's traffic alone | A single two-way object would have to share one SPI, one key and one counter between two senders, which breaks the receiver-chosen SPI and the replay check at once. Keeping each direction separate means each receiver owns the identifier it looks up and the window it enforces. ## How a pair comes about RFC 4301 notes that typical bi-directional communication requires **a pair of SAs, one in each direction**, and that IKE explicitly creates SA pairs in recognition of that. In IKEv2 (RFC 7296): 1. The first Child SA pair is created inside the initial exchanges; more pairs come from `CREATE_CHILD_SA` exchanges (negotiation itself is IKE's subject). 2. Each side supplies, in its proposal, the SPI it wants the *other* side to put on packets sent to it. 3. Both SAs of a pair use the same mode, transport or tunnel, which RFC 4301 requires for simplicity. 4. When an SA is closed, RFC 7296 requires both members of the pair to be closed; each endpoint closes its incoming SA. The IKE SA that negotiates all this is a separate, two-way control channel; the simplex rule applies to the AH and ESP SAs that carry user traffic. ## Counting the SAs on a real tunnel A site-to-site tunnel between gateway A (`203.0.113.1`) and gateway B (`198.51.100.1`) protecting `10.1.0.0/16` to `10.2.0.0/16` with ESP holds: - SA 1: A to B, SPI chosen by B, sitting in A's SAD as **outbound** and in B's SAD as **inbound**. - SA 2: B to A, SPI chosen by A, outbound at B and inbound at A. That is two SAs and four SAD entries, two on each gateway. More pairs appear when: - the policy protects several separate subnet pairs and the peers negotiate one SA pair for each; - the same traffic is protected with both AH and ESP (two SAs per direction); - the sender splits traffic of different DSCP classes with the same selectors onto parallel SAs, which RFC 4301 says it SHOULD do so the receiver's anti-replay window does not discard delayed low-priority packets. ## What the pair means for the operator Because each direction is its own SA, each can fail on its own. A tunnel whose IKE SA is up can still carry traffic one way only: one half of the pair is missing on one gateway, or the traffic in one direction never matches the policy that would put it on its SA. Per-SA packet and byte counters are therefore the first thing to read: an outbound counter rising on A with the matching inbound counter flat on B locates the fault to that one SA. ## Common misreadings - "An SA is the tunnel." A tunnel, in the operator's sense, is at least two SAs plus the IKE SA that keys them. - "Both ends share one SPI." Each SA has the SPI its receiver chose, so the two directions carry independently chosen values. - "AH and ESP can be switched on together in one SA." An SA uses exactly one of them.

  • Why does the receiver, not the sender, choose an SA's SPI?
    The SPI is the receiver's lookup key into its own SAD. If the receiver picks it, it can guarantee the value is unique among its inbound SAs and fast to index, for example as a hash key. A sender-chosen value could collide with another peer's choice and leave the receiver unable to tell two SAs apart.
  • Is the IKE SA also one-way?
    No. The IKE SA is a single two-way control channel identified by an initiator SPI and a responder SPI, used for negotiation, rekeying and notifications in both directions. The one-way rule applies to the AH and ESP SAs, which IKEv2 calls Child SAs, that carry user traffic.
  • Why might a sender run two SAs with identical selectors in the same direction?
    RFC 4301 says a sender SHOULD put traffic of different DSCP classes with the same selectors on different SAs. On one shared SA, high-priority packets can advance the receiver's anti-replay window past delayed low-priority ones, which are then discarded as if replayed. Parallel SAs give each class its own window.

Two neighbours swapping notes through letterboxes: each one numbers the box on their own door and tells the other that number. Notes going each way land in a different box, and only the box's owner chose its number.

saying these in an interview costs you the question

  • One SA protects both directions of a tunnel.
  • The two directions of a tunnel share one negotiated SPI.
  • The sender chooses the SPI for its outbound packets.
  • A single SA can apply AH and ESP together.
  • If IKE is up, both directions must be working.