Every time a site-to-site VPN tunnel comes up between two routers, or a road warrior connects via strongSwan, or two cloud regions establish an encrypted backbone link, there's a good chance IKE is doing the handshake. RFC 2409 defined the original Internet Key Exchange protocol — the thing that lets two IPsec peers agree on cryptographic keys without ever sending those keys over the wire. Despite being superseded by IKEv2 (RFC 7296) in 2005, IKEv1 is still alive in an astonishing amount of production hardware.

The problem. IPsec (RFC 2401) defined how to encrypt and authenticate IP packets using Security Associations — bundles of keys, algorithms, and SPIs. But IPsec deliberately punted on the question of how peers establish those SAs. You could configure keys manually, but that doesn't scale past two devices and a long weekend. You need automated key agreement that survives an active attacker watching the wire.

The design. IKE is a hybrid built on top of two earlier specifications: ISAKMP (RFC 2408), which defined a generic framework for negotiating security parameters, and the Oakley key determination protocol (RFC 2412), which provided authenticated Diffie-Hellman. IKE glues them together with two distinct phases:

• Phase 1 establishes the ISAKMP SA — a bidirectional, authenticated, encrypted channel between the two peers. It comes in two flavors: Main Mode (six messages, identity-protecting) and Aggressive Mode (three messages, faster but leaks identity hashes — the source of countless offline PSK-cracking attacks).
• Phase 2 (Quick Mode) runs inside the Phase 1 tunnel and negotiates the actual IPsec SAs used to protect user traffic. One Phase 1 can spawn many Phase 2 SAs, and Phase 2 supports Perfect Forward Secrecy via a fresh DH exchange.

Authentication modes. RFC 2409 specified four ways to authenticate Phase 1: pre-shared keys, digital signatures (RSA/DSA), and two flavors of public-key encryption. PSK with Aggressive Mode became the de facto choice for small deployments — and the source of widespread vulnerability, since the hash of the PSK is sent in cleartext and is offline-crackable. This is why modern best practice forbids Aggressive Mode + PSK.

Why it was a mess. IKEv1 is notorious for complexity. The spec is spread across three RFCs, has eight possible Phase 1 exchanges, ambiguous error handling, no built-in NAT traversal (added later in RFC 3947), no dead peer detection (RFC 3706), and no reliable retransmission. Two compliant implementations frequently failed to interoperate. The standard joke was that "IKE" stood for "Incompatible Key Exchange." Cryptographers Ferguson and Schneier published a famously scathing 1999 analysis titled A Cryptographic Evaluation of IPsec, calling the protocol's complexity its greatest weakness.

Why it matters today. IKEv2 fixed most of the warts — single RFC, four-message initial exchange, built-in NAT-T, MOBIKE for mobility, EAP for client auth — and is what you should deploy on anything new. But IKEv1 persists in a long tail: legacy Cisco ASAs, older Juniper SRX configs, industrial VPN appliances, and countless site-to-site tunnels nobody wants to touch. If you're debugging why a tunnel won't come up and the logs mention MM_WAIT_MSG2 or QM_IDLE, you're reading the state machine RFC 2409 defined. It also seeded ideas that propagated everywhere: cookie-based DoS resistance, separation of authentication from key agreement, and the two-phase pattern that TLS 1.3's 0-RTT echoes.