Summary

  • Revision 08 of draft-nir-ipsecme-big-payload was posted on 10 September 2026. The substantive design is unchanged from revision 07; the diff updates dates, fixes one word and refreshes a Classic McEliece reference.
  • The proposal uses one Large bit to replace the generic payload header’s 16-bit length with a 32-bit length, after a peer has sent the boolean LARGE_PAYLOAD_SUPPORTED notification in IKE_SA_INIT.
  • That notification carries no maximum size, exchange or payload scope, memory allowance, work budget or concurrency commitment. The draft expressly permits implementation sanity limits.
  • Datatracker currently presents the document as an active Internet-Draft candidate for IPSECME, with “Call For Adoption By WG Issued,” no shepherd and no IESG approval. The requested IANA value is not in the current registry.

A capability with no units

A boolean can answer a narrow question well: can this peer parse the alternative header format? It cannot answer a quantitative question unless the protocol gives it units and bounds.

The proposed LARGE_PAYLOAD_SUPPORTED notification has neither. It does not say 256 kilobytes, four megabytes or any other ceiling. It does not distinguish a certificate payload from a DELETE payload, identify exchanges in which the peer will admit a large object, reserve memory for reassembly, state a CPU-work limit or tell the sender how many oversized requests may be live at once. Reading “supported” as “send whatever fits in 32 bits” would therefore invent a resource commitment that the message never made.

That distinction matters because the draft is solving a real encoding boundary. RFC 7296 gives the complete IKE message a four-octet Length field, but the generic payload header has a two-octet Payload Length field. The latter keeps an individual payload below 65,536 octets even when the enclosing message format can describe more. The draft assigns a previously reserved bit as L; when set, the payload header carries a four-octet length instead.

This is a format change, not a memory-allocation protocol.

The wider header has rules

The draft does more than turn on an extra field. A peer advertises support with a status notification during IKE_SA_INIT. Large-format payloads are not themselves allowed in that initial exchange. Where large initial key-exchange material is needed, the text points to the IKE Intermediate Exchange defined by RFC 9242.

Support may also be asymmetric. A peer that sends the notification says it can process the extended format. A peer that does not receive the same notification from the other side cannot send large-format payloads back. This is another reason to keep capability separate from capacity: the negotiation establishes which parser each direction may use, not a shared allocation of resources.

On receipt, the implementation compares the promised payload length with the bytes that remain in the IKE message. If the length exceeds what is available, the draft calls for INVALID_SYNTAX. If enough bytes exist, the receiver is to process the item like another payload. It cannot reject a correctly encoded item merely because the extended form was unnecessary for that particular length.

Those rules protect wire interpretation. They still leave a different question open: how large an otherwise well-formed item should a particular deployment accept before local resource controls intervene?

The DELETE example exposes the operational edge

The document’s most useful stress case is not an abstract maximum. An IKEv2 DELETE payload can list IPsec Security Parameter Index values. With a two-octet payload length, one payload cannot carry every possible entry count. Under the extended layout, the draft calculates that a list of 65,535 four-octet SPIs would occupy 262,150 octets.

That number demonstrates why the extra length bits can be useful. It does not require every implementation to allocate enough memory for every syntactically representable object. The draft explicitly says implementations may apply sanity limits to the number of SPIs in a DELETE, and the same resource principle reaches beyond that example. A parser can understand the format while an admission layer rejects an object that exceeds a configured memory, work or operational threshold.

The governance error would be to hide that policy behind the capability bit. Senders would then discover a receiver’s real ceiling through timeouts, generic errors, memory pressure or inconsistent vendor behaviour. Operators would possess no stable record of the limit they intended to enforce, and interoperability reports could confuse a deliberate resource control with failure to implement the format.

Fragmentation and TCP answer different questions

IKE fragmentation in RFC 7383 helps an encrypted message cross paths that cannot carry it as one IP packet. RFC 9329 permits IKE and IPsec to use TCP when UDP is blocked or impaired. Neither mechanism tells a sender how much application-level payload state a peer has agreed to hold.

Transport can reduce path loss, packet-size trouble or retransmission cost while leaving the receiver’s resource exposure untouched. A large object split into fragments still has to be received, validated and processed. A stream transport can deliver more reliably and still feed work faster than a constrained peer wishes to admit. The draft’s Large bit, fragmentation and TCP are therefore three separate controls: payload encoding, carriage and local resource acceptance.

Revision 08 is maintenance, not a redesign

Revision 08 was uploaded on 10 September. The official comparison with revision 07 shows date and expiry changes, a correction from “than” to “that,” and an updated Classic McEliece citation. It does not add a numeric resource negotiation or materially change the Large-payload design.

Status language also needs care. Datatracker identifies the draft as active, associates it with IPSECME and records “Call For Adoption By WG Issued.” The history shows the group and stream assignments and the adoption call on 22 July; the mailing-list call said comments were due by 15 August. The automated I-D announcement described the document as a work item of IPSECME. At the same time, the current Datatracker page still labels it a candidate, shows no shepherd, gives the IESG state as “I-D Exists,” and lists no responsible area director or telechat.

Those records should be reported together, not collapsed into an adoption verdict. The draft-nir filename is consistent with an individual-author name, but a filename is not a decision record. Likewise, the body says the intended status is Standards Track and that RFC 7296 would be updated if approved, while current Datatracker metadata displays intended status as “(None).” That is a metadata difference, not evidence that approval has occurred.

The IANA IKEv2 Notify Message Status Types registry does not presently list LARGE_PAYLOAD_SUPPORTED. The draft requests a code point; a request is not an allocation. There is no evidence in the reviewed record of IETF consensus, IESG approval, RFC publication, implementation, interoperability testing, deployment or an operational incident.

Sources