skip to content

How does an IPsec Security Policy Database decide whether a packet is protected, bypassed or discarded, and why does the order of its entries matter?

level: middleimportance: should knowfreq 26%

answer

  1. an ordered access list
  2. three dispositions
  3. overlapping ranges
  4. IKE needs its own exemption
  5. a final catch-all

basics

~20 s

The SPD is an ordered list of entries keyed by selectors such as addresses, protocol and ports, each saying PROTECT, BYPASS or DISCARD. Overlapping ranges make order decide which entry applies, and traffic matching nothing is discarded.

solid answer

~40 s

RFC 4301 requires the Security Policy Database to be consulted for all traffic crossing the IPsec boundary, inbound and outbound, including IKE itself. Each entry is keyed by selectors: local and remote address ranges, the next-layer protocol, and local and remote ports (or ICMP type and code). Its disposition is `DISCARD`, `BYPASS` or `PROTECT`, and a `PROTECT` entry also names the protocol, mode and algorithms to use. Because ranges overlap, the SPD is ordered like a firewall access list, and the administrator's order decides which entry applies. Traffic that matches no entry MUST be discarded, every SPD SHOULD end with a catch-all `DISCARD`, and IKE needs an explicit `BYPASS` entry, or the gateway's own IKE packets would be discarded and no SA could be negotiated.

go deeper

for a junior

Recall that IPsec policy has three outcomes, protect, bypass or discard, chosen by matching addresses, protocol and ports.

for a middle

Explain ordered first-match evaluation, why overlapping ranges make order matter, the required BYPASS for IKE and the default discard.

for a senior

Audit an SPD for shadowing: a broad BYPASS above a specific PROTECT leaks traffic in clear and breaks the tunnel silently at the peer.

for a principal

Choose policy granularity, PFP and split versus full tunnelling for an estate, trading SA count and state against isolation and auditability.

## What the SPD is The **Security Policy Database (SPD)** is the policy half of the IPsec architecture in RFC 4301. The SAD holds SAs that already exist; the SPD says which traffic should have one. RFC 4301 requires it to be consulted for **all** traffic crossing the IPsec boundary in either direction, including traffic that ends up unprotected and IPsec's own management traffic such as IKE. The form of the database is left to implementations, but the behaviour it must produce is specified. ## The three dispositions | Disposition | Meaning | What the entry also carries | |---|---|---| | `PROTECT` | Apply IPsec | Protocol (AH or ESP), mode, algorithms and how to derive SA selectors | | `BYPASS` | Cross the boundary without IPsec | Nothing more | | `DISCARD` | Not allowed to cross in that direction | Nothing more | RFC 4301 splits the SPD logically into **SPD-S** (entries for protected traffic), **SPD-O** (outbound bypass or discard) and **SPD-I** (inbound bypass or discard). A `PROTECT` entry is written once with local and remote swapped to express both directions, so it yields an SA pair; bypass and discard entries can be written separately for inbound and outbound to allow one-way flows. ## Selectors Every implementation must support these selectors: - **Remote and local IP addresses**, each a list of ranges, so one entry can cover a subnet behind a peer gateway. - **Next-layer protocol**, from the IPv4 Protocol or IPv6 Next Header field; AH (51) and ESP (50) count as next-layer protocols here. - **Local and remote ports** for protocols that have them, or a 16-bit ICMP type-and-code selector, or the IPv6 Mobility Header type. - **Name**, which RFC 4301 lists alongside the selectors although it is not taken from the packet: a symbolic identity such as a user or DNS name, used for example by a responder serving remote users whose addresses are not known in advance. Selectors can also take the special value `ANY`, and fields that may be missing or encrypted, such as ports in a non-initial fragment, can be marked `OPAQUE`. ## Why order matters Ranges overlap, so a packet can match several entries. RFC 4301 therefore treats the SPD as an **ordered** database, like the access lists of a stateless packet filter, and requires the administrator to be able to order it; there is no canonical order the system could impose. Consider gateway A at `203.0.113.1` peering with B at `198.51.100.1`: 1. `BYPASS` UDP 500 between `203.0.113.1` and `198.51.100.1` (IKE; also UDP 4500 if NAT traversal is in use) 2. `PROTECT` local `10.1.0.0/16`, remote `10.2.0.0/16`, ESP, tunnel mode to `198.51.100.1` 3. `BYPASS` local `10.1.0.0/16`, remote `ANY` (ordinary internet traffic) 4. `DISCARD` everything else Swap entries 2 and 3 and traffic for `10.2.0.0/16` matches the broad `BYPASS` first and leaves unprotected; B, whose policy requires that traffic to arrive on an SA, drops it as plaintext. Delete entry 1 and IKE's own packets fall to entry 4, so the SA can never be negotiated; RFC 4301 states that IKE traffic MUST have an explicit `BYPASS` entry. ## No match, caches and decorrelation - If no entry matches, the packet MUST be discarded, and every SPD SHOULD end with a catch-all `DISCARD` entry. - For speed, outbound lookups use an **SPD cache**. Caching overlapping, ordered entries is unsafe, so RFC 4301 describes **decorrelating** them into non-overlapping entries first; the result must behave exactly like the ordered search. - Inbound ESP addressed to the gateway is not looked up in SPD-I at all: it goes to the SAD by SPI, and the SAD entry's selectors act as the inbound policy check. - When the SPD changes while SAs exist, RFC 4301 says the implementation SHOULD check the effect on them and let the administrator choose whether to delete or keep them. ## Split tunnelling is SPD policy On a remote-access client, a split tunnel is simply an SPD with `PROTECT` entries for the organisation's prefixes, a `BYPASS` entry for everything else, and the order that puts the specific `PROTECT` entries first. A full tunnel replaces them with one `PROTECT` entry for remote `ANY`, below the IKE bypass. Which design to choose, and what the split exposes, is a VPN design question; the mechanism that implements it in IPsec is this ordered list. ## Granularity: the PFP flag A `PROTECT` entry also decides how many SAs it creates. With the **populate from packet (PFP)** flag set on a selector, the new SA takes that selector's value from the triggering packet, so a remote range of ten hosts yields a separate SA pair for each host that sends traffic; without it, the SA takes the whole range from the entry and the hosts share one pair.

  • What happens to an outbound packet that matches a PROTECT entry when no SA exists yet?
    The SPD lookup finds PROTECT with no SA in the cache, so the key-management protocol, usually IKEv2, is invoked to create one. If it succeeds, an outbound cache entry and both inbound and outbound SAD entries are created; if it fails, the packet is discarded. The triggering packet itself may be dropped or sent once the SA exists.
  • Why does an inbound plaintext packet never cause an SA to be created?
    RFC 4301 creates SAs only from outbound PROTECT matches or from a peer's proposal. Inbound traffic that is not AH or ESP is checked only against inbound bypass and discard policy, so a plaintext packet that should have arrived protected is not bypassed and is dropped, which is an auditable event.

saying these in an interview costs you the question

  • The most specific SPD entry wins regardless of order.
  • Traffic matching no SPD entry is forwarded unprotected.
  • IKE traffic needs no policy entry of its own.
  • The SPD is only consulted for traffic to be encrypted.
  • A receiver negotiates an SA when plaintext arrives that should be protected.