Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
Extracted elements (22)
Fragmentation is performed before cryptographic protection is applied so that each IKE Fragment message receives individual encryption and authentication. This prevents a DoS attack where an attacker injects forged but valid-looking post-encryption fragments that cannot be detected until the full message is reassembled and its authenticity check fails.
PMTU discovery in IKE is performed downward (largest to smallest threshold) unlike RFC 4821's upward approach. Since IKE typically sends only one large message per SA establishment, probing upward from the minimum would cause that single large message to be fragmented using the smallest possible threshold with no further benefit.
IKE_SA_INIT messages cannot be fragmented because SK_a and SK_e have not yet been calculated; fragmentation requires a pre-existing Encrypted payload. This means IP-level fragmentation of IKE_SA_INIT (e.g., with long algorithm lists or large MODP groups) cannot be prevented by this mechanism.
Messages of the IKE_SESSION_RESUME exchange (RFC 5723) cannot be fragmented using this mechanism because they do not contain an Encrypted payload. Large ticket-based session resumption messages should instead use a 'ticket by reference' approach to avoid IP fragmentation.
When IKE fragmentation is used alongside RFC 6311 High Availability, IKE Message ID Synchronization messages (which deliberately use Message ID zero) MUST NOT be sent fragmented, since standard replay detection based on Message ID is not applicable for them.
For messages sent over IPv6, a maximum IP datagram size of 1280 bytes is RECOMMENDED as the fragmentation threshold; for IPv4, 576 bytes is RECOMMENDED. Implementations may use other values if appropriate.
If a peer has information that IP fragmentation is likely to interfere with an IKE exchange, that peer SHOULD use IKE fragmentation. If IKE fragmentation was used in a previous exchange on the current SA, peers SHOULD continue using it for messages larger than the fragmentation threshold.
If a retransmitted fragment of a request is received after the responder has already sent a response, it MUST trigger retransmission of the response only if the Fragment Number field is 1; otherwise it MUST be ignored.
If messages containing unprotected payloads are fragmented, all unprotected payloads MUST be placed in the first fragment (Fragment Number = 1), and the Encrypted Fragment payload MUST be present in every IKE Fragment message as its last payload.
If reassembling has already started and a new fragment arrives with a higher Total Fragments value, the receiver MUST discard all previously stored fragments and restart reassembly with just the newly received fragment.
IKE fragmentation MUST NOT be used unless both peers have indicated their support for it by exchanging the IKEV2_FRAGMENTATION_SUPPORTED notification in the IKE_SA_INIT exchange.
In the first IKE Fragment message (Fragment Number = 1), the Next Payload field MUST be set to the payload type of the first inner payload. In all subsequent fragments, it MUST be set to zero.
PMTU discovery is OPTIONAL in IKE fragmentation. When performed, the initiator MUST start from larger fragment sizes and reduce them; when starting a new probe, it MUST reset retransmission timers. After reaching the smallest allowed fragmentation threshold, it MUST continue retransmitting until the exchange completes or times out.
The Fragment Number and Total Fragments fields in the Encrypted Fragment payload MUST NOT be zero, and Fragment Number MUST be less than or equal to Total Fragments. Invalid fragments MUST be silently discarded.
When PMTU discovery is used, the sender MUST ensure that the Total Fragments field strictly increases with each successive probe (i.e., each new smaller fragmentation threshold must result in more fragments) so the receiver can distinguish between different probe sets.
When using IKE fragmentation, the Fragment Number and Total Fragments fields MUST be used along with the Message ID to detect retransmissions and replays.
The IKEV2_FRAGMENTATION_SUPPORTED notification is included in the IKE_SA_INIT request by the initiator and echoed in the response by the responder to negotiate use of IKE fragmentation. The notification contains no data, Protocol ID MUST be 0, SPI Size MUST be 0, and Notify Message Type MUST be 16430.
This document assigns notify message type value 16430, labeled 'IKEV2_FRAGMENTATION_SUPPORTED', in the IANA 'IKEv2 Notify Message Types - Status Types' registry.
This document assigns payload type value 53, labeled 'Encrypted and Authenticated Fragment' (SKF), in the IANA 'IKEv2 Payload Types' registry.
An attacker can complete IKE_SA_INIT, compute SK_a and SK_e, and then send a large but incomplete set of IKE_AUTH fragments that pass ICV checks and fill reassembly buffers indefinitely, potentially exhausting memory. To mitigate this, it is RECOMMENDED that receivers limit total buffered fragment content to less than 64 KB; if exceeded, the receiver SHOULD drop the connection and discard all received fragments.
The receiver MUST NOT parse or act on partially reassembled message content before all fragments have arrived. Fragments received out of order might be followed by payloads that change the meaning of earlier ones, and an attacker could exploit early parsing to manipulate behavior.
The Encrypted Fragment payload (SKF, payload type 53) contains a 2-octet Fragment Number (starting from 1), a 2-octet Total Fragments field, followed by an Initialization Vector, encrypted content, padding, Pad Length, and Integrity Checksum Data — identical structure to the Encrypted payload except for the two additional header fields.