Summary

  • RFC 2407 assigned a common IPsec DOI, Situation bits, identity types, protocol and transform numbers, SA attributes and notification meanings. Those discriminants made bytes interpretable; they did not authenticate a claim or choose a host policy.
  • The document explicitly left security policy to the host. A complete operational receipt had to join the encoded request to peer authentication, the matched local rule, the selected proposal, SA installation, receiver choices and the later packet or application result.

Imagine receiving an ISAKMP Security Association payload whose DOI field contains 1. Four octets later, a Situation bit says identity matters. An Identification payload names an address, an FQDN or a key selector. A proposal offers ESP and a collection of attributes. Every value is syntactically recognizable. None of that, by itself, answers the question the machine must act on: should this peer receive this protection under this rule now?

That gap was not a flaw hidden between the lines. It was the architecture. Published in November 1998, RFC 2407 instantiated the generic ISAKMP framework for IPsec. ISAKMP supplied exchange and payload forms. The DOI supplied a shared namespace and the interpretation of DOI-specific content. Peers could therefore agree that one byte meant ESP, another meant an IPv4 subnet identity, and a status code meant the responder had enabled replay checking.

The common vocabulary solved a real coordination problem. Without a DOI, the same numeric field could acquire incompatible meanings in different protocol families. RFC 2407 registered the IPsec DOI as number 1 and placed protocol identifiers, AH and ESP transforms, IP compression transforms, SA attributes, identity types, label domains and notifications into governed spaces. It also reserved private ranges for systems that deliberately cooperated outside the public registry.

But a name is not its referent. PROTO_IPSEC_ESP described a protocol suite available to a proposal. It did not prove which encryption and authentication attributes accompanied it. A transform identifier sometimes required a particular attribute combination; other combinations were explicitly undefined. A lifetime attribute said seconds or kilobytes and supplied a value. It did not prove when a running implementation began counting or whether rollover completed before expiration.

RFC 2407 made the boundary explicit in its policy section: the IPsec DOI imposed no specific security-policy requirements, and host policy was outside scope. Its implementation notes imagined anything from a static list of addresses, masks and security-required flags to wildcard DNS names, direction bits and proxy-firewall addresses. The wire grammar could be common while the decision table remained local.

The Situation field dramatized that division. It was a 32-bit bitmap with SIT_IDENTITY_ONLY, SIT_SECRECY and SIT_INTEGRITY. Every implementation had to support the identity-only case and abort an association setup that never supplied an Identification payload. If secrecy or integrity labeling was asserted, a Labeled Domain Identifier and the relevant levels and category bitmaps followed.

The label-domain number identified the namespace in which those levels and categories were said to exist. It was not the policy itself. It did not prove that two organizations attached the same operational consequence to a category, that a local rule authorized the flow, or that enforcement happened after negotiation. The IANA section was unusually revealing: a label-domain assignment could be granted on demand without accompanying documentation. The number prevented collision. It did not manufacture shared governance.

Identity worked the same way. RFC 2407 defined types for IPv4 and IPv6 addresses, subnets and ranges; FQDNs and user FQDNs; ASN.1 distinguished and general names; and an opaque key identifier. The responder could use the initiator identity to select local policy. Yet the bytes were a claim whose evidentiary weight depended on the exchange authentication and the credential binding.

The certificate rule acknowledged this. When certificates authenticated the exchange, identities used for local policy decisions should be contained in the authenticating certificate. The gap between “the payload says this FQDN” and “the authenticated certificate binds this FQDN” was material. ID_KEY_ID made the limit even clearer: it was an opaque, possibly vendor-specific stream used to select a pre-shared key. A portable type code surrounded data whose meaning could remain local.

Even malformed metadata had an ownership boundary. During Phase I, the ID protocol and port fields had to be zero or UDP 500. Other values required abort and should be auditable. “Should be auditable” still did not mean a durable record existed. The implementation and operator had to produce, store and retain it.

Proposal syntax offered another temptation to confuse representation with result. ISAKMP could negotiate multiple Phase II protocol suites at once. RFC 2407 listed ISAKMP, AH, ESP and IPComp, but said which suites might be negotiated together was a host-policy decision. The proposal carried alternatives and preferences. The responder selected. Key management installed. Packet processing later used—or failed to use—the resulting SA.

A successful negotiation receipt was therefore insufficient on its own. It might show that both peers parsed the same transform and attributes. It did not show that the kernel accepted the installation, that the selector caught the intended traffic, that anti-replay stayed enabled, that counters did not exhaust, or that the protected packet reached an application. Each transition needed its own receipt.

The DOI-private status messages expose this layered truth. RESPONDER-LIFETIME let the responder communicate the lifetime it actually chose. REPLAY-STATUS could positively report its election to enable or disable anti-replay. The presence of a sender sequence field did not answer that receiver-side question. The notification did.

INITIAL-CONTACT was more dangerous. A peer could say this was its first SA with the remote system. The receiver might infer that the sender had rebooted and delete old SAs the sender could no longer use. The RFC used careful verbs: the sender wished to inform; the receiver might elect; the deletion rested on an assumption. A protected message authenticated the speaker and bound the statement to an exchange. It did not independently observe a reboot or prove that every older association was disposable.

Protection of the status message itself also varied by exchange. RFC 2407 prohibited status notifications in Aggressive Mode because it lacked the required binding. It distinguished partial protection in Main Mode from full inclusion in the Quick Mode hash. The same semantic code could carry different evidentiary strength depending on placement.

The document's many “magic numbers” thus did two things at once. They reduced ambiguity between cooperating implementations, and they revealed exactly what remained outside the registry. IANA could assign a discriminant. It could not own a site's certificate database, policy rule, kernel API, audit system or application consequence.

This is where Lu Heng's minimum-specification lens becomes practical. The shared layer should be just thick enough to make independent systems interoperable. Future decisions remain with the actors who bear their cost. RFC 2407 named the common symbols and openly left suite grouping and host policy local. Trouble begins when an operator promotes those symbols into claims about reality that the running path has not supplied.

The agency problem runs through the implementation. A key-management daemon speaks for a host. A certificate administrator speaks for an identity namespace. A kernel executes an SA. A firewall enforces traffic selection. An application decides whether the result is useful. A dashboard that compresses them into “IKE succeeded” gives one agent credit for decisions owned by several.

RFC 4306 replaced RFCs 2407, 2408 and 2409 in 2005 by combining the separated IKEv1 documents into IKEv2. In 2023 the IESG moved the older trio to Historic, citing wide IKEv2 deployment, lack of new IKEv1 work and defects including amplification exposure. RFC 7296 later advanced IKEv2 to Internet Standard. RFC 2407 should therefore be read as a historical allocation of responsibility, not present-day algorithm advice.

Its durable lesson is narrower and more useful than nostalgia. A common name can make a message intelligible without making the message true, authorized or effective. The DOI named the vocabulary. Authentication bound some claims. Local policy made a decision. The responder selected. The kernel installed. Packets ran. Only a chain of receipts can say which of those events actually occurred.

Sources