IPsec and IKEv2: The Two-Plane Model

I want to make the case for one way of organizing the confusion: everything in IPsec is either a control-plane thing, a data-plane thing, or a record that connects the two. IKEv2 negotiates, ESP enforces, and two small databases hold the agreement between those moments. Call it the two-plane model. Hold it in your head and the acronym soup sorts itself.

To keep it concrete, we’ll watch one session get built—a laptop connecting to an office gateway—and follow it through every layer, ending with a single packet wearing the armor all of this was for.

The Problem: What Should We Even Protect?

Before we build anything, let’s be clear about what we’re defending against. Here’s what a packet capture looks like on an open network:

GET /api/user/profile HTTP/1.1
Host: internal.example.com
Cookie: session=eyJhbGciOiJIUzI1NiIs...

That’s a postcard. Anyone on the path sees it, reads it, copies it. The fix is obvious: encrypt everything. But “everything” is where it gets complicated.

Not every packet leaving your laptop needs to be encrypted. Traffic to your local printer? Probably fine in cleartext. DNS queries to your internal resolver? Maybe. Traffic to the office file server? Absolutely yes.

So before we even think about encryption, we need a policy. We need to know: which traffic gets protected, and how?

This is where the SPD (Security Policy Database) lives. It’s the bouncer at the door. Every packet leaving your network stack passes through the SPD first, and the SPD decides: protect this, don’t protect that.

# On Linux, you can see your actual SPD with:
ip xfrm policy show

# A typical rule looks like:
src 192.168.1.100/32 dst 10.0.0.0/8 
    dir out priority 100 
    tmpl src 192.168.1.100 dst 203.0.113.5
        proto esp mode tunnel

That rule says: “Any traffic from this laptop heading to the office network (10.0.0.0/8) gets protected. Protect it by wrapping it in an ESP tunnel to 203.0.113.5.”

The SPD is static configuration. It’s your intent. But intent isn’t enough—you need the actual cryptographic keys to do the protecting.

The Control Plane: IKEv2 Negotiates the Agreement

Here’s the problem: you can’t just pick encryption keys and start using them. The gateway doesn’t know what keys you picked. You don’t know what keys it wants. And even if you both picked the same keys, how do you know you’re talking to the right gateway and not an impostor?

This is the control plane’s job. IKEv2 (Internet Key Exchange version 2) is the protocol that runs before any real data moves. It’s two peers meeting in a neutral room, verifying each other’s identity, and negotiating the terms of engagement.

The exchange looks like this:

After this six-message dance, both sides have agreed on:

• Which encryption algorithm to use (AES-256-GCM, say)
• Which authentication method (certificates, pre-shared keys)
• The actual cryptographic keys for the data plane
• What traffic this covers (the “traffic selectors”)

All of this gets written down. But where?

The Shared Record: Where the Keys Live

The SAD (Security Association Database) is where the agreement lives. It’s the ledger that connects the control plane to the data plane.

Every time IKEv2 completes a negotiation, it creates a Security Association (SA) and writes it to the SAD. The SA contains:

• The SPI (Security Parameter Index)—a short identifier for this connection
• The encryption algorithm and keys
• The authentication algorithm and keys
• The lifetime (when to rekey)
• The traffic selectors (what this SA covers)

On Linux, you can see your actual SAD:

$ ip xfrm state show
src 192.168.1.100 dst 203.0.113.5
    proto esp spi 0x00000001 reqid 1 mode tunnel
    replay-window 32 flag af-unspec
    auth-trunc hmac(sha256) 0x... 128
    enc cbc(aes) 0x...
    sel src 0.0.0.0/0 dst 0.0.0.0/0

That’s one SA. It says: “Use ESP with this SPI, these keys, for traffic matching these selectors.”

Now the data plane can do its job.

The Data Plane: ESP Wraps the Packet

ESP (Encapsulating Security Payload) is the data plane’s enforcer. It’s the armor. Every packet that the SPD says “protect this” gets handed to ESP, which wraps it:

Original packet:
[IP header | TCP header | payload]

ESP-wrapped packet (tunnel mode):
[New IP header | ESP header | Original packet (encrypted) | ESP trailer | ESP auth]

The new outer IP header has the gateway’s address as the destination. The original packet—your actual data—is encrypted inside. To anyone watching on the network, it’s just noise.

When the gateway receives it, it looks at the SPI in the ESP header, finds the matching SA in its SAD, uses the keys to decrypt and verify the packet, and then processes the original packet inside.

One Packet’s Journey

Let’s trace a single packet from your laptop to the office file server.

1. Your browser sends an HTTP request to files.office.example.com.
2. The network stack routes it toward 10.0.0.50.
3. The SPD checks the packet: source 192.168.1.100, destination 10.0.0.50. Rule matches: protect this.
4. ESP wraps it: looks up the SA for this traffic in the SAD, encrypts the original packet, adds the outer IP header pointing to 203.0.113.5 (the gateway).
5. The encrypted packet travels across the internet. Anyone watching sees only encrypted payload to the gateway’s address.
6. The gateway receives it: sees the ESP header, extracts the SPI (0x00000001), finds the matching SA in its SAD.
7. The gateway decrypts and verifies the packet using the keys from the SAD.
8. The original packet emerges: source 192.168.1.100, destination 10.0.0.50. The gateway routes it onto the office network.
9. The file server receives your request and never knew it was ever encrypted.

That’s the whole system. The SPD decides. IKEv2 negotiates. The SAD records. ESP enforces.

The Takeaway: It’s a Conversation

Here’s what I wish someone had told me on day one: IPsec isn’t a thing you configure. It’s a conversation between layers.

The encryption doesn’t work without the negotiation. The negotiation is pointless without the databases to store the results. The databases are empty without policies telling them what to protect. SPD, IKEv2, SAD, ESP—they’re not independent tools. They’re one system that only makes sense when you see the relationships.

The two-plane model—control plane negotiating, data plane enforcing, records connecting them—is a handle for thinking about any tunnel protocol. WireGuard does it differently (no separate control plane; keys are static). Tailscale does it differently (control plane is centralized). But the structure is the same: agreement, enforcement, and the record that connects them.

When you’re staring at a packet capture trying to understand why a tunnel isn’t working, you’re almost always asking: which part of this conversation broke? Did the SPD not match? Did IKEv2 fail to negotiate? Is the SAD missing the SA? Is ESP using the wrong keys?

The map is simple once you have it.

What We Skipped

We didn’t cover authentication headers (AH)—mostly unused now. We didn’t cover transport mode vs tunnel mode (we assumed tunnel). We didn’t cover Diffie-Hellman math, NAT traversal, MOBIKE for mobile clients, or rekeying (what happens when keys expire). Those are all important, but they’re variations on the two-plane model, not exceptions to it.

In a follow-up, I’d like to cover rekeying—how IKEv2 handles key rotation without dropping the tunnel—and MOBIKE, which lets a laptop change networks (say, from WiFi to cellular) without tearing down the session. Both are elegant, and both make more sense once you’ve internalized the model we built here.

If any of this was wrong, I’d like to know. The internet is full of people who understand IPsec better than I do, and I’m still forming my thoughts. But clarity comes through writing, not before it.