Summary

  • RFC 2411 divided the original IPsec corpus into seven responsibility groups so that architecture, ESP, AH, algorithms, assigned values and key management would not keep copying one another's rules.
  • The roadmap made specifications easier to extend, but it was Informational and could not prove which revisions an implementation followed, which algorithms two peers negotiated, whether keys reached the kernel or whether protected traffic worked.

The most consequential diagram in RFC 2411 contains no packet.

At its top sits an architecture box. ESP and AH sit beneath it. Algorithm documents fan out at the sides. A Domain of Interpretation occupies the middle, where assigned values let the pieces name one another. Key management enters from below. Arrows cross the page like plumbing in a machine room.

It is tempting to read this as documentation about documentation—a filing guide produced after the real engineering was done. The opposite is closer to the truth. By November 1998, IPsec had become a family of specifications whose internal boundaries could determine whether future extensions remained comprehensible. A cipher document that restated ESP, a key-management draft that invented its own key lengths, or two authentication documents that copied the same rule differently could fracture interoperability without changing a single packet diagram.

RFC 2411 tried to prevent that failure before it happened. Its subject was not merely where papers should be stored. Its subject was where a rule should acquire authority.

The authors called one danger the “draft explosion” effect. New encryption and authentication algorithms would keep appearing after the base IPsec documents became RFCs. Reopening the architecture or packet-format specification for each algorithm would make the common layer unstable. Repeating the common layer in every algorithm draft would produce redundant, eventually inconsistent accounts of the same system. The roadmap offered a third course: keep shared behavior in shared documents, and make each new algorithm document describe only the binding that was genuinely new.

That is minimum specification practiced as editorial architecture.

The architecture document owned general concepts, security requirements and the shape of the IPsec system. The ESP and AH documents owned their packet formats and general processing. An encryption-algorithm document explained how a particular cipher fit into ESP. An authentication-algorithm document described a mechanism once when the same behavior applied to ESP and AH. The DOI supplied common names and negotiable values. Key-management documents owned establishment and handling of keying material.

The separation sounds obvious only after it has worked.

Consider key length. A key-management protocol could not generate the right quantity of material without knowing what the chosen algorithms required. Yet putting every algorithm's length, weak-key treatment, parity rule and ordering convention into key management would make that protocol a catalogue of cryptographic details it did not own. RFC 2411 assigned those attributes to the algorithm documents. Key management had to produce material of adequate size and strength. The architecture explained how multiple keys could be extracted when ESP combined confidentiality and authentication.

Then the roadmap stopped.

Whether an implementation passed the entire material block into a kernel and let the kernel perform the “slicing and dicing,” or divided the keys in its key-management process first, was an implementation issue. The wire behavior and cryptographic result had to agree. The internal boundary did not.

That sentence contains a compact design ethic. Standardize what independent systems must share. Do not centralize an internal choice merely because a document has room to pronounce on it.

Optionality received the same treatment. Algorithm designers were asked to fix optional parameters when a common value was technically reasonable. Every parameter negotiated at runtime enlarged the failure surface: more proposal combinations, more code paths, more chances for two conforming products to share no usable choice. Fixed values could reduce that cost.

But the roadmap did not demand uniformity for its own sake. If an option needed to remain open, its document should say why, describe the relevant defaults or ranges, and explain the effect on formatting and processing. Optional behavior still needed a boundary. “Configurable” was not a substitute for a specification.

The recommended contents were strikingly operational. Algorithm documents should discuss minimum, maximum and recommended key sizes; weak keys; random-number generation; refresh intervals; performance; block and field formats; padding; interactions with other algorithms; known attacks; implementation traps; validation methods and test vectors. RFC 2411 did not perform those tests. It insisted that the documents nearest to the mechanism make the evidence possible.

This is why the roadmap must not be mistaken for the evidence itself.

RFC 2411 was Informational. Its status notice said it did not specify an Internet standard. Its security section sent the reader back to the architecture, protocol and algorithm documents for actual security procedures. Even its warning that many encryption algorithms are unsafe without authentication was a direction to assemble the right sources, not a certificate that any deployed system had done so.

A roadmap entry can show that an algorithm document exists. It cannot show that a particular build implements that document. A product declaration can show claimed support. It cannot show what two peers selected. A negotiation log can show a selected proposal. It cannot show that both endpoints installed the resulting SAs. An installed SA can show local state. It cannot show that a useful packet crossed the network and reached an application.

The distinctions matter most when the documents change at different speeds.

Packet formats may remain stable while cryptographic judgment changes. A registered identifier may persist after an algorithm becomes unwise. An implementation may continue to carry an old transform for compatibility. An operator may disable it. Two peers may negotiate something else. A roadmap is excellent at locating those questions. It is incapable of answering all of them from its own page.

The later history made that limit explicit. RFC 6071 obsoleted RFC 2411 in 2011 after the IPsec and IKE corpus had proliferated across the original working group, its descendants and other groups using IPsec. The replacement called itself a snapshot. It listed categories and requirement levels as they stood in February 2011, warned that later RFCs could change them, and said that another RFC prevailed if the roadmap conflicted with it.

The map declared its own subordination.

RFC 6071 also recorded two realities at once. New IPsec specifications had obsoleted the old set, yet the older version remained common in operational use. IKEv2 had replaced IKEv1, while IKEv1 still existed in deployed systems. Formal succession did not erase installed code. Conversely, installed code did not prevent a document from becoming obsolete. Standards status and operational population were different facts.

The shape of the map evolved as well. Combined-mode algorithms gained their own place. Mandatory algorithm requirements moved into standalone guidance. IKEv2 consolidated material that IKEv1 had spread across several, sometimes contradictory, documents. The original modularity had made extension possible; the accumulated modules had also created a discovery problem. Good boundaries can age. They remain hypotheses about the cheapest place to manage change.

Modern algorithm guidance preserves the central insight. RFC 8221 separates changing cryptographic implementation requirements from the more stable ESP and AH packet specifications. It explains that stronger algorithms emerge, older ones weaken and hardware ranges from large gateways to constrained devices. The mandatory-to-implement algorithm of tomorrow should already be widely available before the requirement changes.

That careful staging is not the same as saying every registered algorithm is recommended. An IANA number makes a value unambiguous. It does not make the algorithm current, secure, enabled or selected. RFC 9395 later deprecated IKEv1 and obsolete algorithms that older registries and documents still described. The historical record remained; the operational guidance moved.

RFC 2411 therefore belongs in the history of the Internet for a reason deeper than its list of IPsec papers. It captured a method for scaling agreement without making one document sovereign over the stack.

Put a shared rule in the smallest layer that all implementations need. Put a specialized rule beside the mechanism it constrains. Give negotiable values stable names. Fix options when interoperability benefits; leave them open only with an explanation. Let internal design remain local when the network does not need to see it. And never confuse the document that tells you where evidence belongs with the evidence that a running system produced.

The roadmap put every rule in its place. Running code still had to put each rule into service.

Sources