Summary

  • RFC 8247's algorithm requirements create an interoperability baseline for IKEv2 implementations; they do not identify an algorithm negotiated by a particular pair of peers.
  • A selected transform, local policy decision, authenticated IKE SA, Child SA, ESP packet and service outcome each require their own time-bound evidence.

The phrase “mandatory to implement” answers a capability question. It helps an implementation designer know which common algorithms should exist so two conforming implementations have a chance to interoperate. It does not answer the operational question that an incident report usually means: what did these two peers actually use at this time?

RFC 8247 makes the distinction visible in its opening scope. IKE negotiates IPsec Security Association parameters, including algorithms. But peers may negotiate different algorithms according to their individual local policy. The requirement table therefore cannot replace a proposal/selection transcript. A client can implement an algorithm yet omit it from one offer; a responder can support it yet select another permitted transform; policy can reject an otherwise implementable choice. “MUST implement” is neither an offer nor an acceptance.

The next boundary is association state. Even a captured proposal and selection does not itself prove that authentication completed and an IKE SA was established. A created Child SA adds another record, with selectors, keys and lifetimes that need their own identifiers. A cryptographic configuration claim should preserve peer identities, proposal order, selected transforms, authentication result, SA identifiers, timestamps and failure notifications rather than use a standards table as a substitute.

RFC 8247 also blocks a familiar overreach. It explicitly does not update algorithms used for ESP packet encryption. The document's IKEv2 guidance cannot become a blanket label for the data plane. To say that ESP encrypted a packet needs ESP and SA evidence; to say a peer received a packet needs an observation at that peer; to say a service worked needs an application-level result. Those facts may follow a successful negotiation in a real system, but they are not contained in an implementation requirement.

Time changes the meaning again. RFC 8247 observes that algorithms in use today have no guarantee of becoming mandatory tomorrow. A dated compliance assertion is not a perpetual inventory. IANA's IKEv2 registries identify transform names and numbers; they do not show what any live peer implemented or negotiated.

Heng Lu's Minimum Initial Specification and Running-Code Primacy offer the appropriate reporting discipline. Record the smallest fact the evidence supports: a document requires implementation; a build reports support; a peer offered a transform; a responder selected it; authentication created a named SA; an ESP counter observed protected packets. Each is valuable. Combining them into “the VPN used secure algorithm X” without the intervening joins creates a conclusion no source supplied.

Wouters is one of four authors of this collective IETF standard. His public IETF profile supports that attribution, not authority over a vendor, customer, endpoint or operating network. The contribution worth preserving is the standard's restraint: interoperability guidance sets a floor for implementations, while negotiated and observed security remains a different ledger.

Sources