Summary

  • RFC 2401 separated an ordered Security Policy Database from the Security Association Database: the first decided whether traffic was discarded, bypassed or protected, while the second held the parameters of active one-way associations.
  • Neither a rule nor an association was a receipt for a packet. Outbound traffic still had to receive the specified AH or ESP processing; inbound traffic had to pass cryptographic processing and a further check that the associations actually used matched an applicable policy.

Imagine two pieces of evidence presented after an incident. One is a screenshot of a rule requiring protection. The other is a database row for a live cryptographic association. Together they look persuasive. Yet neither shows that the packet in question matched that rule, traversed that association, received the required transformation, reached its peer or was accepted by an application.

RFC 2401, published in November 1998 as the first consolidated Security Architecture for the Internet Protocol, supplied a language for keeping those claims apart. It described IP-layer access control, integrity, origin authentication, anti-replay protection, confidentiality and limited traffic-flow confidentiality for IPv4 and IPv6. But it did not compress all of them into one promise. AH, ESP, modes, algorithms and key-management procedures could be combined differently according to the required service.

At the policy layer stood the Security Policy Database, or SPD. Its scope was exhaustive in effect: all inbound and outbound IP traffic, including traffic that would not use IPsec, had to receive a disposition. Entries were ordered and selected traffic by addresses and upper-layer fields. A match could discard the packet, bypass IPsec or require IPsec protection. A protection entry also specified the needed protocol or bundle, mode, algorithms and nesting.

Order made policy executable rather than merely descriptive. A broad entry placed before a narrow one could decide a packet before the narrow entry was considered. The policy was therefore not just a collection of approved sentences; it was a sequence whose selector match and position affected the result. Direction mattered too. The fields and required processing for an outbound decision were not simply a mirror image of the inbound check.

Beside the SPD stood the Security Association Database, or SAD. Each Security Association was simplex: it protected traffic in one direction. Ordinary bidirectional protection therefore required two associations. An SA was identified by a Security Parameters Index, a destination address and the choice of AH or ESP. Its database entry could hold sequence and anti-replay state, algorithms and keys, lifetimes, mode and path-MTU information.

That was indispensable operating state, but it answered a different question. The existence of an SAD entry showed that an association with certain parameters was available. It did not show which packet selected it or that any packet used it. Nor did it prove peer receipt, application authorization or a service outcome. RFC 2367’s PF_KEY interface, published shortly before this architecture, made management of such state visible to applications; RFC 2401 placed that state inside a larger packet-processing contract.

For an outbound packet, the joins had to happen in order. The implementation matched the packet against the SPD. Discard ended the path. Bypass allowed ordinary transmission without IPsec. A protection rule selected a suitable existing association or initiated creation of the required SA or bundle. Only then could the specified AH or ESP operations be applied, in the required order, before forwarding or transmission. A stored intention and an active association remained upstream of the transformation they were meant to cause.

The inbound path imposed a second boundary that is easy to miss. Destination address, security protocol and SPI selected an SA. AH or ESP processing could then verify integrity or origin, reject replays, and decrypt where the chosen service provided confidentiality. Success at that stage was still not the complete authorization decision.

After the IPsec headers were processed, the resulting packet had to match an inbound SPD entry. The implementation then had to verify that the associations actually used—and their order—satisfied that policy. If a candidate entry failed the comparison, other applicable entries had to be considered. Only after the policy check succeeded could the packet pass to the transport layer or be forwarded. Cryptographic validity under an SA and authorization under the governing policy were deliberately separate receipts.

AH and ESP also resisted a convenient shorthand. The 1998 Authentication Header supplied integrity and data-origin authentication, with optional anti-replay service, but not confidentiality. ESP could supply confidentiality and optionally authentication and integrity, with a different coverage boundary. “IPsec encrypted it” was not a universal description, and bypass explicitly meant no IPsec protection at all.

RFC 2401 did not pretend its architecture could compensate for everything around it. Overall security still depended on implementation quality, operating-system protection, random-number sources and administration. Nor is the document current operational advice. RFC 3168 later updated the treatment of Explicit Congestion Notification, and RFC 4301 replaced the architecture in 2005, refining policy databases, selectors, fragment handling and peer authorization.

The durable historical lesson is narrower. Policy intent, installed association state and packet execution occupy different evidence layers. In Lu Heng’s terms, a symbolic claim acquires operational force only through running systems and local validation. That is an analytical lens, not language used by the RFC. Applied carefully, it yields an eleven-step custody chain: source and version, loaded rule, ordered match, required protection, current association, actual transform or validation, inbound policy comparison, delivery to a network or transport boundary, peer receipt, application processing and finally service outcome.

No early rung can honestly stand in for a later one.

Sources