What happens in IKEv1 quick mode, message by message?
Show the answer
Say this first
Quick mode is phase 2: three messages, all protected by the ISAKMP SA. The initiator sends its proposals (transform sets with the SPI it wants for its inbound SA), a nonce, its proxy IDs and a DH value if PFS is on. The responder checks the proxy IDs against its own policy, picks a proposal and answers with its SPI, nonce and DH value. The third message is a hash that confirms the initiator has the keys, after which both sides use the new inbound and outbound SAs.
Go deeper
The three messages
| Msg | Direction | Payloads |
|---|---|---|
| 1 | initiator to responder | HASH(1), SA proposals with initiator SPI, nonce, optional KE, proxy IDs |
| 2 | responder to initiator | HASH(2), chosen SA with responder SPI, nonce, optional KE, proxy IDs |
| 3 | initiator to responder | HASH(3) |
Keys
IPsec keys are derived from the phase 1 key material (SKEYID_d) plus both nonces and the SPI, or also from a fresh DH secret when PFS is on.
SPIs
Each side chooses the SPI for its own inbound SA and tells the peer, so the outbound SPI on one router is the inbound SPI on the other.
One quick mode per selector pair
A crypto ACL with three lines to three remote subnets triggers three quick modes and three SA pairs, and each pair is rekeyed separately.
They will ask next
What if my crypto ACL is wider than what the peer proposes?
Many implementations, IOS included, accept a proposal that falls inside their own policy and build the SA for exactly what was proposed. A proposal wider than the local policy is rejected. Do not rely on that behaviour, especially between vendors: mirror the selectors exactly.
Why does the third message exist?
It proves to the responder that the initiator received message 2 and derived the same keys. Until then the responder cannot be sure the initiator is ready to receive on the new SA.
Traps
- Saying quick mode happens once per tunnel. It happens once per proxy ID pair and again at every rekey.