In IPsec, what job does IKE do before any protected packet flows, and how did IKEv1's two phases divide that job?

## Why IPsec needs a key-exchange protocol **ESP** and **AH** are the IPsec protocols that actually protect packets. Neither can do anything until both gateways agree on four things: which algorithms to use, which keys to use, which SPI (Security Parameter Index) labels each security association, and which traffic each association covers. Typing keys into both ends by hand is possible but never rotates them and does not scale. The **Internet Key Exchange (IKE)** automates the agreement: - it **authenticates** the two peers to each other (a pre-shared key, signatures with certificates, or another method); - it **negotiates** algorithms from proposals one side offers and the other selects from; - it runs a **Diffie-Hellman** exchange so both sides derive the same secret without sending it; - it **derives keys** and hands them, with SPIs and traffic selectors, to the IPsec layer. IKE itself runs over **UDP port 500** (moving to 4500 when a NAT is detected, which is the NAT-traversal leaf's subject). The data packets never pass through IKE; IKE only builds and maintains the state they will use. ## IKEv1 Phase 1: Main Mode or Aggressive Mode IKEv1 is specified in RFC 2409, on top of ISAKMP (RFC 2408) and the IPsec Domain of Interpretation (RFC 2407). Its first phase builds an **ISAKMP SA** — a protected, authenticated channel between the two IKE daemons. RFC 2409 offers two ways to do it: | | Main Mode | Aggressive Mode | |---|---|---| | Messages | 6 | 3 | | Messages 1-2 | negotiate policy (SA proposal) | policy, Diffie-Hellman values, nonces and identities together | | Messages 3-4 | Diffie-Hellman values and nonces | message 3 authenticates the initiator | | Messages 5-6 | identities and authentication, encrypted | — | | Identity protection | yes | no, except with the public-key-encryption methods | | Diffie-Hellman group | negotiable | cannot be negotiated | RFC 2409 required Main Mode and made Aggressive Mode a SHOULD. Aggressive Mode saves round trips at a price: identities cross the network unprotected, and with a pre-shared key the responder's hash in message 2 is computed only from values visible on the wire plus the key, so whoever sees it can test candidate keys offline. That is a reason defenders avoided it, not a configuration trick. ## IKEv1 Phase 2: Quick Mode **Quick Mode** runs inside the protection of the Phase 1 SA (every payload after the header is encrypted). It is three messages: the initiator sends a hash, an SA proposal and a nonce (optionally a KE payload and client identities); the responder answers in kind; the initiator confirms with a final hash. It negotiates the **IPsec SAs** that ESP or AH will use. Without the optional KE payload, Quick Mode refreshes keying material derived from the Phase 1 exponentiation and does not provide perfect forward secrecy; with it, an extra Diffie-Hellman exchange runs per Quick Mode. One Phase 1 SA can carry many Quick Modes. ## How IKEv2 maps onto the same job IKEv2, now RFC 7296, replaced what it calls eight different IKEv1 initial exchanges with a single four-message exchange: 1. `IKE_SA_INIT` (request and response) — algorithms, Diffie-Hellman values and nonces, in the clear. 2. `IKE_AUTH` (request and response) — identities, authentication and the **first Child SA**, encrypted. 3. `CREATE_CHILD_SA` — more Child SAs, and rekeying of Child SAs and the IKE SA; RFC 7296 says some of its function was called a Phase 2 exchange in IKEv1. 4. `INFORMATIONAL` — deletes, errors and liveness checks. So the order is the same — protected channel first, data SAs negotiated under it — but a tunnel that needs one Child SA is up after two round trips. IKEv2 is also reliable (every request gets a response) and was designed to resist state-exhaustion floods with cookies. ## Status: IKEv1 is deprecated RFC 9395 (April 2023) deprecates IKEv1 and moves RFCs 2407, 2408 and 2409 to **Historic**. Its reasons include IKEv1 code that no longer receives development, its use for packet amplification, and the dated algorithms (AES-CBC, SHA-1, Diffie-Hellman groups 1 or 2) that IKEv1 deployments tend to negotiate in practice. It also says IKEv2 implementations SHOULD NOT import IKEv1 configurations without updating the algorithms. ## What to take into an interview - IKE negotiates and authenticates; ESP and AH protect the packets. - IKEv1: Phase 1 (Main Mode with 6 messages, or Aggressive Mode with 3) then Phase 2 (Quick Mode with 3). - IKEv2: `IKE_SA_INIT` + `IKE_AUTH` give the IKE SA and the first Child SA in four messages. - Describe Aggressive Mode as history and a known exposure, never as the faster option to pick.