Summary

  • RFC 2408 gave ISAKMP separate fields for an anti-clogging cookie pair, Phase 2 Message ID, Exchange Type and payload chain. Each maintained a different scope of state; none was a credential.
  • A complete result still required strong authentication, a matched local policy, accepted proposals, SA installation, packet use and an independently observed service outcome. Even CONNECTED and Delete messages carried narrower claims than their names suggested.

The first ISAKMP packet arrived with an Initiator Cookie and zeros where the Responder Cookie and Message ID would later appear. That was enough for a host to begin a bounded conversation. It was not enough to know who had spoken.

This difference sat in the first eight octets. RFC 2408 called the cookie an anti-clogging token, a cheap value meant to make denial-of-service attacks more expensive before a server performed costly public-key work. The issuing host could recreate or validate its own token using endpoint material, a local secret and time. An outsider should not be able to mint a value the host would accept.

Those properties were useful. They were also deliberately smaller than identity. An address and UDP port could be inputs to a cookie without becoming an authenticated principal. A locally secret hash could prove that the receiver had issued a token without proving that the sender controlled a durable name, certificate or account. Time-varying material could reduce replay without showing that the path remained stable.

RFC 2408 was unusually candid about the limit. Absolute denial-of-service protection was impossible. A server could still allocate state for floods of forged packets, so implementations needed garbage-state collection and aggressive memory management. A valid-looking exchange marker did not turn resource exhaustion into a solved problem.

The cookie's second job came after that first defense. ISAKMP used the Initiator and Responder Cookie pair to identify an ISAKMP Security Association. At the start, only the initiator supplied one. The response supplied both. Once Phase 1 completed, subsequent communications carried the pair. The pair selected a protected negotiation context.

“Selected a context” is not “identified a peer”. RFC 2408 separately required strong authentication. It warned that without authentication an entity's identification could not be trusted. The framework deliberately supported different authentication mechanisms and key exchanges. The cookie fields were present before those methods had finished their work.

That ordering matters to an audit. A trace can show a stable cookie pair across packets. It can show that a receiver recognized the pair. It cannot, without the authentication transcript and credential decision, establish which principal the implementation bound to that state. Correlation is not attribution.

The Message ID drew another boundary. RFC 2408 assigned the four-octet value to protocol state during Phase 2. The initiator generated it, and simultaneous Phase 2 negotiations under one ISAKMP SA were expected to have different values. During Phase 1 it had to be zero because the cookie pair already identified the ISAKMP SA.

This was not a redundant serial number. It let one protected relationship carry several in-progress negotiations without confusing their responses, proposals or notifications. The cookies named the parent state. Message ID named one child negotiation. Proposal SPIs named the security associations being negotiated. Later, an ESP or AH packet used the SPI in its own protocol header to select the installed runtime state.

Four identifiers therefore answered four questions. Which ISAKMP SA? Which Phase 2 negotiation? Which proposed protocol SA? Which running packet-processing SA? Collapsing them into “the tunnel ID” destroyed exactly the distinctions the protocol created.

The rest of the fixed header formed a parsing contract. Exchange Type chose the grammar. Next Payload named the first payload, and every generic payload header linked to the next. Version, flags and total length constrained interpretation. The receiver validated those fields in a prescribed order before it walked the payload chain.

That chain could contain an SA, proposal, transform, key exchange, identity, certificate, certificate request, hash, signature, nonce, notification, delete or vendor identifier. The modular design let different exchanges assemble different conversations from shared components. It also made validation local and incremental. Passing the cookie check did not pass the version check. Passing the version check did not authenticate the signature. Parsing the final payload did not install an SA.

RFC 2408's error path exposes the ownership of those transitions. Invalid cookies, payload types, versions, exchange types, flags and Message IDs caused discard. Logging the event was optional. Sending an Informational notification was often optional. Local security policy dictated the response. The standard named the error; the host decided the consequence and whether evidence would persist.

This is why a packet capture with an INVALID-COOKIE notification is not the entire story. It may show that one implementation reported a validation failure. It does not prove which local rule fired, whether the peer received the notice, whether the event entered a durable log or whether a resource attack ended. The notification is an observation from one layer.

ISAKMP divided negotiation into two phases. Phase 1 established an ISAKMP SA that could protect later management activity. Phase 2 used that channel to establish SAs for other protocols. The initial cost could be amortized across several later negotiations, and error or deletion messages could use the protected path instead of re-authenticating from scratch.

The phases could also authenticate different subjects. RFC 2408 noted that Phase 1 might authenticate servers or hosts while Phase 2 might concern users or applications. A dashboard that attached one peer name to every child SA risked erasing that change in subject. The cookie pair located the parent context; it did not decide which identity a particular policy should authorize below it.

Proposal control remained local too. An initiator could offer a single choice and retain tight control, or send several proposals in preference order. Once it offered alternatives, the responder selected according to its own security policy. A well-formed proposal was an option set, not a command. A returned selection was a negotiated choice, not proof that the kernel had accepted the resulting state.

The Commit bit existed because the distinction between negotiated choice and readiness was operationally dangerous. Either party could ask the other to wait until a protected Informational Exchange carried CONNECTED. That message reused the Phase 2 Message ID so it could be attached to the right negotiation. It narrowed a synchronization gap.

It did not make the gap disappear. RFC 2408 acknowledged that the final message could be lost and left recovery behavior unstandardized. A waiting peer might infer success from verifiable protected traffic, or retransmit the last negotiation message. Implementations might retain the last message until they were confident. CONNECTED was therefore one receipt in a fallible transport sequence, not a cosmic assertion that every downstream component was ready.

Delete had a similarly precise meaning. The sender used a protected Informational Exchange to say that it had removed the named SA from its own database. RFC 2408 explicitly said this was an advisory, not a request that the receiver delete its copy. The responder was not expected to acknowledge it. Local policy governed what happened next.

That wording prevents a common forensic error. Seeing a Delete payload proves neither that the receiver processed it nor that local cleanup succeeded. At most, after protection checks, it records the sender's statement about sender-side state. A complete deletion receipt needs the authenticated message, receiver decision, local database mutation, affected selectors, rejected subsequent traffic and any recovery action.

The same discipline applies to the encryption flag. When set, it said that payloads after the header were encrypted using the algorithm in the selected ISAKMP SA. The header remained the state selector. The flag did not establish algorithm suitability, credential validity, policy authorization or application success. It described treatment of a message region under already selected state.

RFC 2408's architecture thus assembled a ladder of receipts. Cookie issuance and validation bounded resource and replay claims. The cookie pair correlated the ISAKMP SA. Message ID correlated Phase 2 work. Exchange Type and Next Payload drove parsing. Authentication bound a peer. DOI semantics explained proposals. Local policy chose. Key management installed. The security protocol processed packets. The application experienced—or failed to experience—the result.

Lu Heng's reality-layer lens makes this ladder visible. A symbol in a header belongs to the message layer. A successful parser belongs to the implementation layer. A verified signature or MAC belongs to an authentication context. A policy match belongs to an authority system. An installed SA belongs to running state. A delivered and useful operation belongs to the service. One layer cannot borrow proof from another merely because the UI uses a single green badge.

The agency problem is equally concrete. The protocol registry owns numbers. The framework authors own grammar. Credential administrators own identity bindings. Security teams own policy. A daemon owns negotiation. A kernel owns packet state. Applications own outcomes. If the daemon reports “connected” and the organization treats that as evidence for every later agent, responsibility disappears at the most consequential handoffs.

Running-code primacy supplies the remedy. Preserve the exact cookie pair and Message ID, but join them to the authentication result, credential fingerprint, policy version, proposal choice, kernel installation receipt, runtime SPI, selectors, counters, packet verdict and application observation. The original fields become valuable precisely because they are not asked to certify more than they contain.

RFC 2408 was published in November 1998. RFC 4306 obsoleted the separated RFC 2407, 2408 and 2409 family in 2005 by defining IKEv2. In 2023 the IESG moved the IKEv1 family to Historic, and RFC 9395 closed related registries. RFC 7296 later became the IKEv2 Internet Standard. The old framework is history, not present-day algorithm advice.

Its historical lesson remains current. Systems still confuse correlation identifiers with identity, parser success with authorization and negotiated state with running outcome. RFC 2408 did not make that mistake. It assigned separate fields to separate jobs. The cookie identified the exchange. Authentication still had to identify the peer.

Sources