When an ESP packet reaches an IPsec gateway, how does the receiver use the SPI and the SAD, and what does it check afterwards?
answer
- a receiver-assigned index
- 32 bits, chosen locally
- no entry, no processing
- inner headers versus selectors
basics
~20 sThe receiver looks up the packet's 32-bit SPI, which it chose itself, in its Security Association Database; no match means discard. It applies ESP with that entry's keys, then checks the inner headers against the SA's selectors.
solid answer
~40 sThe Security Parameters Index is a 32-bit value the receiving end picked when the SA was created, so for a unicast SA the `SPI` alone, or `SPI` plus protocol, finds the SAD entry. That entry holds everything the packet needs: keys and algorithms, mode, the anti-replay window, lifetimes and the selectors negotiated for the SA. An unknown SPI is discarded and logged as an auditable event; over an existing IKEv2 SA the receiver may report it with `INVALID_SPI`. After AH or ESP processing, RFC 4301 requires a second check: the packet's addresses, protocol and ports must fall inside the SA's selectors, or it is discarded and the peer may be told with `INVALID_SELECTORS`. That check stops traffic for one policy arriving on an SA negotiated for another.
go deeper
Remember that the SPI in an ESP header tells the receiver which SA, and therefore which keys, to use for the packet.
Walk through the inbound path in order: SPI lookup in the SAD, discard on no match, AH or ESP processing, then the selector check on the inner headers.
Read the audit events: unknown-SPI drops and selector-check drops point to different faults, typically stale state in one case and mismatched policy in the other.
Decide how selector checks, audit logging and notification rate limits are set across a gateway fleet so drops are visible without becoming a load amplifier.
## The SPI is the receiver's index Every AH and ESP packet carries a **Security Parameters Index (SPI)**, a 32-bit value that RFC 4303 (ESP) and RFC 4302 (AH) describe as arbitrary and used by a receiver to identify the SA to which an incoming packet is bound. RFC 4301 adds that the SPI is **selected by the receiving end** of the SA. Two consequences follow: - The receiver can guarantee that the SPI is unique among its own inbound SAs, which is why it alone can identify a unicast SA. - The SPI means nothing to anyone else; it is a local key into the receiver's **Security Association Database (SAD)**. A few values are set aside: RFC 4303 reserves SPIs 1 through 255 for IANA, and SPI 0 for local, implementation-specific use that MUST NOT be sent on the wire. ## What the SAD entry holds The SAD is a nominal database with one entry per SA. RFC 4301 lists the data items it must carry: | SAD item | Used for | |---|---| | `SPI` | Building outbound headers; finding inbound SAs | | Sequence number counter (a 64-bit counter that also accommodates 32-bit sequence numbers) | Numbering outbound packets | | Sequence counter overflow flag | Whether overflow stops the SA or is allowed | | Anti-replay window | Rejecting replayed inbound packets | | AH or ESP algorithms and keys | Integrity and encryption | | Lifetime, by time, bytes or both | Replacing or ending the SA | | Mode, tunnel or transport | How the packet is wrapped | | Selectors negotiated for the SA | Checking inbound traffic after processing | | Tunnel header addresses, path MTU, DSCP and DF handling | Building and sizing outer packets | For inbound traffic, the SAD doubles as the policy cache: RFC 4301 calls the entry selected by the SPI the cache for the selectors that arriving packets must match. ## Inbound processing, step by step RFC 4301 section 5.2 describes what happens to a packet arriving on the unprotected side: 1. **Demultiplex.** A packet addressed to this device with AH or ESP as its protocol goes to the SAD; anything else goes to the inbound bypass/discard policy. 2. **Look up the SA.** For a unicast SA, use the SPI alone, or the SPI plus the protocol; which one is a local choice because the receiver chose the SPI. Multicast SAs add the destination, or the destination and source, and the longest match wins. 3. **No match: discard.** The packet is dropped and the event is auditable; the audit record should carry the time, SPI, source, destination and protocol. RFC 7296 adds that if an IKE SA exists to the source, the receiver MAY send an `INVALID_SPI` notification naming the unknown SPI. 4. **Process.** Apply AH or ESP using the keys, algorithms and replay state from the entry; the order of integrity, replay and decryption steps is part of the AH and ESP specifications themselves. 5. **Check selectors.** Match the now-readable packet against the selectors stored in the SAD entry. If its addresses, next-layer protocol or ports fall outside them, the packet MUST be discarded, the event is auditable, and the system should be able to send the peer an IKE `INVALID_SELECTORS` notification, with a rate limit an administrator can configure. ## Why the selector check comes after decryption In tunnel mode the addresses that matter are inside the encrypted payload, so they can only be compared once ESP has been removed. The check exists because a valid SPI and a valid integrity check prove only that the packet came from the peer holding the key. They do not prove the peer used the right SA. RFC 7296 gives the case where host A requires one algorithm for traffic to one address and another algorithm for the rest of the subnet; if A negotiates an SA covering the whole subnet, peer B may legitimately send traffic from the special address on it, and A drops those packets. Without the check, a peer could push traffic for one policy down an SA negotiated for another. ## Edge cases worth knowing - **What is not checked.** The DSCP values recorded for an SA select among parallel SAs on the way out; RFC 4301 says they are not checked against inbound traffic, because DSCP may change en route. - **Same SPI from two peers.** Each receiver's SPIs are unique only to itself. RFC 4301 warns that two hosts behind the same NAT can choose the same SPI, so a sender's outbound policy cache must not identify its SAs by (peer address, SPI) alone. - **Manual keys.** With manually keyed SAs, anti-replay is normally disabled, because the replay service requires automated SA management.
- Why can a receiver identify a unicast SA by SPI alone, when a sender cannot rely on the peer's address plus SPI?The receiver chose every inbound SPI itself, so it can keep them unique. A sender stores SPIs chosen by many different peers; RFC 4301 notes two hosts behind one NAT may pick the same value, or a reused DHCP address may inherit an old peer's SAs, so pairing remote address and SPI can point at the wrong SA.
- Why does RFC 4301 tell implementations to rate-limit INVALID_SELECTORS notifications?The notification is triggered by inbound packets the receiver has already decided to drop. A misconfigured or hostile peer could provoke a stream of them and turn the receiver into a source of IKE traffic, so RFC 4301 asks for an administrative switch to send or not send the notification and a rate limit when it is on.
saying these in an interview costs you the question
- The sender picks the SPI and the receiver accepts it.
- An unknown SPI makes the gateway start IKE for that SPI.
- A packet that passes ESP integrity is always delivered.
- The receiver checks the DSCP value against the SA.
- The SAD and the SPD are the same database.