Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)
Extracted elements (31)
Data block type values (0x0 for pad, 0x4 for IPv4, 0x6 for IPv6) were chosen to coincide with the IPv4/IPv6 version field values so that no per-data-block type overhead is required — the encapsulated IP packet begins immediately at the data block boundary.
TCP was explicitly not chosen as the encapsulation for IP-TFS (instead using AGGFRAG over UDP-based ESP) because TCP is considered a fallback-only solution for IPsec and is highly not preferred.
The ECN DF bit and ECN field are not mapped from inner to outer headers in AGGFRAG mode. The DF bit is irrelevant because AGGFRAG handles fragmentation internally; the ECN field need not be mapped because constant-send-rate tunnel congestion is by design unrelated to inner traffic flow.
Two RTT estimates are computed — one from the timestamp echo path delay, one from the sum of both endpoints' transmission delays — and the larger is used. This guarantees RTT is never underestimated regardless of whether the tunnel rate or the path speed is the dominant latency factor.
An AGGFRAG_PAYLOAD empty payload (header only, no DataBlocks) is defined to allow reporting congestion control information on a paired SA that is not itself AGGFRAG_PAYLOAD-enabled. This is currently only applicable in non-IKEv2 deployments.
When AGGFRAG_PAYLOAD is used together with ESP replay detection, the replay window and the reorder window MAY both be reduced to the smaller of the two window sizes, since packets outside the smaller window would be dropped anyway. However, there is no requirement to unify them.
A sender MUST only send AGGFRAG_PAYLOAD payloads over an SA configured for AGGFRAG mode; mixed use of an AGGFRAG_PAYLOAD-enabled SA is not specified.
If the responder accepts the USE_AGGFRAG request, the IKEv2 response MUST also include a USE_AGGFRAG notification. If AGGFRAG is unacceptable to the initiator and the SA is established without it, the initiator MUST delete the Child SA.
Implementations supporting the non-congestion-controlled mode SHOULD implement circuit breakers (RFC 8084) as a recovery mechanism of last resort, and SHOULD also enable congestion control reporting when circuit breakers are enabled.
In congestion-controlled mode, congestion information MUST be sent from the receiver and from the sender at least once per RTT; not receiving this information over multiple consecutive RTT intervals MUST be treated as a congestion event causing the sender to lower its rate.
RTT field values equal to or larger than 0x3FFFFF MUST be clamped to 0x3FFFFF; Echo Delay and Transmit Delay values equal to or larger than 0x1FFFFF MUST be clamped to 0x1FFFFF.
Senders MUST NOT send initial fragments of an inner packet using one SA and subsequent fragments in a different SA, because sequence numbers are reset when switching SAs (e.g., on rekeying).
The DS (Differentiated Services) field SHOULD NOT be copied from inner to outer headers by default in AGGFRAG mode, since multiple inner packets may have different DS values; a sender SHOULD allow the DS value to be set by configuration.
The egress (receiving) side of the AGGFRAG tunnel MUST allow for and expect the ingress (sending) side to vary the size and rate of sent encapsulating packets, unless constrained by other policy.
The ESP sequence number stream for AGGFRAG_PAYLOAD MUST increase monotonically by 1 for each subsequent packet, since gaps in sequence numbers break the fragmentation reassembly mechanism.
The non-congestion-controlled mode MUST only be used where the user has full administrative control over any path the tunnel will take and MUST NOT be used otherwise, to avoid negatively affecting network congestion.
The USE_AGGFRAG notification MUST NOT be combined with the USE_TRANSPORT_MODE notification, as AGGFRAG_PAYLOAD is only defined for non-transport-mode (tunnel-mode) SAs.
When an ECN Congestion Experienced (CE) value is received and counted as a loss event, the receiver MUST set the E bit in the AGGFRAG_PAYLOAD congestion header containing the LossEventRate derived from that CE event.
AGGFRAG mode introduces a new ESP Next Header value AGGFRAG_PAYLOAD (144) that aggregates and fragments inner IP packets into fixed-size IPsec tunnel packets, enabling Traffic Flow Confidentiality by obscuring the size and frequency of IP traffic.
All-pad payloads (BlockOffset of zero with a single Pad Data Block) may be inserted between inner packet fragments, allowing the sender to always send tunnel packets regardless of encapsulation computation time. Receivers increment the expected sequence number when they receive an all-pad payload during reassembly.
Congestion information is communicated via a timestamp echo mechanism: the sender sets TVal; the receiver echoes it back in TEcho with an Echo Delay (time since first receipt). The sender computes RTT as (current_time - TEcho - EchoDelay), also bounding by the sum of both sides' Transmit Delays.
The USE_AGGFRAG IKEv2 notification enables the AGGFRAG_PAYLOAD payload on a Child SA pair, using a method similar to USE_TRANSPORT_MODE negotiation. The initiator includes it in an SA payload; if accepted, both sides include it in the response.
IANA has allocated IP protocol number 144 with keyword 'AGGFRAG' from the 'Protocol Numbers - Assigned Internet Protocol Numbers' registry for the AGGFRAG encapsulation payload for ESP.
IANA has allocated status type USE_AGGFRAG (decimal 16442) from the 'IKEv2 Notify Message Types - Status Types' registry for use in negotiating AGGFRAG_PAYLOAD on Child SAs.
IANA has created the 'AGGFRAG_PAYLOAD Sub-Types' registry under a new 'ESP AGGFRAG_PAYLOAD' category with Expert Review policy. Initial values: 0 (Non-Congestion-Control Format), 1 (Congestion Control Format), 3–255 (Reserved).
ECN bits in the outer encapsulating IP header are not protected by IPsec and thus may constitute a covert channel. For this reason, ECN use SHOULD NOT be enabled by default.
For Traffic Flow Confidentiality to be maintained in congestion-controlled mode, the shape and timing of the encapsulated inner traffic must not be directly affecting outer network congestion in a predictable way; if it would be, non-congestion-controlled mode should be used instead.
A Data Block begins with a 4-bit Type field: 0x0 indicates a Pad Data Block, 0x4 indicates an IPv4 data block (the start of the IPv4 packet), and 0x6 indicates an IPv6 data block. The type values were intentionally chosen to match IPv4/IPv6 version field values, eliminating per-block type overhead.
The congestion-control AGGFRAG_PAYLOAD payload uses a 24-octet header: Sub-Type (1 octet, value 1), 6-bit Reserved, P flag (PLMTUD probe in progress), E flag (CE ECN used), BlockOffset (16-bit), LossEventRate (32-bit), RTT (22-bit, microseconds), Echo Delay (21-bit), Transmit Delay (21-bit), TVal (32-bit opaque), and TEcho (32-bit opaque), followed by DataBlocks.
The non-congestion-control AGGFRAG_PAYLOAD payload uses a 4-octet header: Sub-Type (1 octet, value 0), Reserved (1 octet), and BlockOffset (16-bit unsigned integer), followed by variable-length DataBlocks.
The USE_AGGFRAG IKEv2 notification payload contains 1 octet of requirement flags with two defined bits: C (Congestion Control required) and D (Don't Fragment — sender cannot receive inner packet fragments). The notification type value is 16442.