Summary

  • draft-smyslov-ipsecme-ikev2-psp-02 proposes a childless IKEv2 SA followed by a modified CREATE_CHILD_SA exchange in which each endpoint sends the PSP key that its peer should use when transmitting to it. This closes a control-plane gap left outside the PSP Architecture Specification.
  • An authenticated Key Download response can prove that a peer supplied an SPI, selectors and wrapped key material. It does not prove sender-side NIC installation, receiver-side derivation, packet protection, ICV acceptance, traffic cutover during rekey or old-master-key eviction.
  • PSP delegates replay protection to another layer and provides no individual derived-key revocation. Operators therefore need separate receipts for installation, packet verdicts, rekey, rotation, replay and application delivery.

The key exchange ends where the packet inquiry begins

Consider two hosts preparing to protect east-west traffic in a large data centre. Their IKE peers authenticate. They agree a Key Wrap Algorithm and establish an IKE Security Association without a Child SA. A later CREATE_CHILD_SA request carries a PSP proposal, Traffic Selectors, an SPI and a Key Download payload. The response returns the other direction's SPI and wrapped key. Both sides record success.

It is tempting to label the link encrypted at that moment. The proposed exchange does not justify that conclusion. It has delivered the material from which a sender may construct its transmit state. It has not observed the sender's host-to-NIC handoff, the selected egress queue, the first PSP header, the receiver's key derivation, the AES-GCM verdict or the application payload beyond it.

That distinction is the useful centre of draft-smyslov-ipsecme-ikev2-psp-02. The draft is narrow: it explains how IKEv2 can supply keys for PSP. It does not define a deployment receipt. Its HTML and XML carry the same seven-page mechanism. Most importantly, its Security Considerations section still says only “To be added.” That is a reason to keep claims bounded, not an invitation to write the missing assurance into the margins.

PSP reverses the ordinary direction of key choice

Ordinary IKEv2 derives Child-SA key material from secrets and nonces contributed through its exchanges. RFC 7296 defines that architecture: SK_d feeds later Child-SA key derivation, and CREATE_CHILD_SA can create or rekey SAs. PSP needs something different.

The PSP Architecture Specification is designed to avoid storing every receive key in NIC memory. A receiver holds two 256-bit master keys. For an incoming packet it uses the high bit of the SPI to choose one master key and derives the per-SA key from that master key and the SPI. Because only the receiver knows its active master-key state, the receiver must select the SPI and the matching key. The sender then needs that receiver-generated key in order to encrypt packets travelling toward the receiver.

This produces a direction that can sound backwards until the roles are stated precisely. In a Key Download payload, an endpoint supplies the key its peer should use as a sender, so that the endpoint itself can later receive and derive the same key. Bidirectional traffic requires the same arrangement in reverse, because a PSP SA is unidirectional. Two authenticated peers do not create one shared data-plane fact; they exchange two direction-specific promises and materials.

The PSP specification deliberately left the key-exchange protocol outside its scope. The new draft tries to fill that gap by reusing the Key Download machinery standardized for group key management in RFC 9838, while applying it to unicast peer-to-peer SAs. The reuse is structurally sensible. It also makes the evidence boundary visible: transporting arbitrary wrapped material is not the same event as installing and using it.

Authentication must finish before the sensitive material moves

The proposed sequence begins in IKE_SA_INIT. Peers negotiate a Key Wrap Algorithm. A PSP-capable responder also sends CHILDLESS_IKEV2_SUPPORTED. RFC 6023 introduced childless IKE initiation for cases in which peers need an authenticated IKE SA before any traffic-protecting Child SA exists.

The separation is not cosmetic. The PSP draft says the initiator must not send its receive key during IKE_AUTH, because the responder is not yet authenticated when the initiator would have to expose the sensitive material. The peers therefore complete authentication first. Only afterwards do they use the modified CREATE_CHILD_SA exchange.

This is a strong sequencing property. It still has a narrow meaning. A CHILDLESS_IKEV2_SUPPORTED notification proves support for that initiation form, not PSP installation. Negotiating the Key Wrap Algorithm proves an agreed wrapping method, not that the IKE SA will be used only for PSP; the draft explicitly allows the same IKE SA to create both ESP and PSP SAs. Successful IKE_AUTH proves the authenticated IKE peer according to the selected method. It does not prove that a particular NIC, queue, VM or application is entitled and ready to consume a later PSP key.

The control plane therefore has at least three receipts before any protected packet: capability, peer authentication and key-delivery exchange. Collapsing them into “PSP is up” erases the very sequencing that keeps the sensitive key away from an unauthenticated responder.

CREATE_CHILD_SA carries a proposal, not a hardware state transition

The modified exchange replaces ordinary Child-SA key derivation inputs with explicit Key Download payloads. The PSP proposal uses a new protocol identifier and a new PSP-parameter transform type, both still marked <TBA by IANA>. It includes Traffic Selectors. Each side sends exactly one Key Download payload containing one or more Group Key Bags; the SPI in a bag must match a PSP proposal. An SA_KEY attribute carries wrapped material protected by the default wrapping key SK_w = prf+(SK_d, "Key Wrap for PSP").

Those bindings matter. They allow an operator to preserve a coherent control record: which authenticated peer, which IKE SA, which proposal, which selectors, which SPI, which PSP parameter and which wrapped key response belonged together. They do not define how a host passes the returned key into its transmit data path.

The open Google PSP repository makes the missing implementation surface concrete without proving any deployment. Its reference software reads configuration containing master keys, an SPI, encapsulation mode, algorithm and offsets. The architecture's transmit appendix allows several designs: an on-chip flow table, an SA database in RAM, or key material associated with a transmit descriptor. Each design has a different installation boundary, capacity constraint and failure mode.

A completed IKE response cannot report which design is present. It cannot say that an asynchronous device command succeeded, that a descriptor used the intended key, that policy selected the protected path or that a packet avoided a cleartext exception. If an operator needs to claim encryption rather than key availability, it needs a local installation receipt bound to the exact SPI and key reference, followed by packet evidence.

The receiver's stateless scale still has state

PSP is often described through “stateless encryption.” The phrase is easy to overread. The architecture avoids per-SA receive-key storage by deriving a key from the SPI and a receiver master key. It does not abolish state.

The receiver still holds master keys, tracks which one is active, allocates non-reusable SPIs within an epoch, selects algorithms, enforces SA lifetimes and decides when old material can be evicted. The sender still stores or otherwise supplies each transmit key. Upper layers may still maintain an approved SPI list for a socket. Host and NIC software still need policy, queues, descriptors, counters and error handling.

The IPsec architecture offers a useful comparison: a Security Association binds selectors, processing and cryptographic state, while management and data processing remain distinct. ESP similarly separates SA establishment from per-packet processing. PSP changes the receive-key storage model; it does not make the rest of the operational chain disappear.

This matters to capacity claims as well. The PSP specification discusses millions of SAs and very high key-update rates as design considerations. Those are not benchmark results for a named NIC or proof that a particular installation kept up. A control-plane success rate can remain green while the local transmit database is full, device programming is delayed or the selected data path bypasses the programmed object.

A packet verdict needs different evidence

The PSP specification asks implementations to expose counters for successfully processed TX and RX packets and bytes, authentication failures, encryption failures, malformed packets and other errors. It also calls for a flag indicating successful decryption/authentication and for SPI metadata to reach upper-layer software. These requirements point to the evidence that a control exchange lacks.

For a bounded canary, an operator can retain the IKE transaction, a sender installation acknowledgement, the transmitted PSP SPI and IV, a TX-success counter increment, the receiver's derived-key epoch, an RX-authentication success counter increment, the ICV verdict and the upper-layer receipt. That chain can support a limited statement about one packet or flow. It still should not be inflated into continuous protection for every packet.

Negative evidence is equally important. A response with the correct SPI does not explain a missing RX counter. The fault might be egress selection, encapsulation, routing, master-key epoch, unsupported PSP version, ICV failure or upper-layer rejection. Treating CREATE_CHILD_SA as the final health signal hides all of those possibilities behind the last control event.

Rekey is a period of overlapping truth

The draft allows REKEY_SA to indicate the PSP SA being replaced. RFC 7296 describes the general rekey pattern: create a new SA, move traffic and delete the old one. The response to the creation exchange is not the same as completion of the move.

For PSP, the receiver's master-key design adds another clock. One master key is active for new SPI allocations while the other can remain available for existing SAs. A rotation stops creating new SAs under the old active key, but it does not immediately invalidate every old SA. The PSP specification says a “double rotation” is required to evict a master key and guarantee that data using its SPIs is no longer usable. Connections must rekey before that next rotation.

An operator therefore needs a rekey ledger, not a single success bit. It should record the new SPI and key, installation on the sender, first accepted packet on the new SA, last accepted packet on the old SA, traffic cutover, deletion acknowledgement and the master-key epoch in which old derivation remained possible. Without those facts, a clean control exchange can coexist with traffic still using the old SA or with a premature eviction that creates loss.

The draft does not supply this ledger. Nor does it solve individual derived-key revocation. The PSP architecture says rotation is the available method for invalidating derived keys. A policy console that marks one SA “revoked” must therefore distinguish an administrative decision from the cryptographic state that actually stops accepting traffic.

Replay does not become someone else's proof just because it is outside PSP

The PSP Architecture Specification states that PSP does not provide replay protection and assumes another layer, such as a transport, will do so. The modified IKEv2 exchange does not change that property. A fresh key and a valid ICV can coexist with a replay question that PSP itself does not answer.

This is not evidence that PSP traffic is necessarily replayable in a deployed stack. TCP or another layer may provide the required control. It is evidence that the proof has moved. If an operator claims replay rejection, it must name the layer, state the policy and retain the verdict from that layer. A Key Download receipt cannot testify for a transport sequence check that happens later.

This boundary also prevents an adjacent mistake. The presence of an IV or SPI is not itself a replay verdict. The receiver must observe, classify and reject according to the actual control in use. Cryptographic packet authenticity, replay handling and application duplicate suppression are related but separate propositions.

Revision 02 renews the draft; it does not add deployment evidence

The frozen Datatracker API reports revision 02, uploaded 30 September 2026, expiring 3 April 2027. The document page classifies it as an active individual Internet-Draft. The history records three submitted revisions.

A comparison with revision 01 shows that revision 02 changes the dates, revision number, expiry and running headers; its protocol text is unchanged. That is not a criticism. Internet-Drafts are renewed as work continues. It does mean the 30 September timestamp should not be narrated as a new security design, completed review or implementation milestone.

The Datatracker record has no RFC number, stream, responsible Area Director or intended standards level. The document header says Experimental. The IANA IKEv2 Parameters registry is an authority for assigned values, while the draft still displays placeholders. Neither publication nor a registry request proves that an endpoint implements PSP, accepts these messages or protects live traffic.

Sources and limits

The mechanism is grounded in revision 02 text, HTML and XML, bounded by its Datatracker API, status and history. Protocol context comes from RFC 7296, RFC 6023, RFC 9838, RFC 4301, RFC 4303, the IANA registry, the archived PSP repository and its Architecture Specification.

These sources do not establish adoption, production use, conformance, performance, interoperability, a vulnerability, an incident or an observed service result. They define a proposal and adjacent architectures from which a bounded operating proof can be designed.