Most Internet Key Exchange (IKEv2) messages are usually small. IP defines a mechanism for fragmentation of oversized UDP messages, but implementations vary in the maximum message size supported. Some NAT and/or Firewall implementations and intermittent routers do not handle IP fragments and these fragmented packets might be dropped. This can cause issues when large IKEv2 messages like digital certificates are transferred over the network.

With this feature, IPSec can fragment large messages at IKEv2 itself and replace them with a series of smaller messages as defined in RFC 7383. The IP datagrams are small enough that fragmentation does not occur at the IP level.

Only messages that contain an Encrypted payload are subject to IKE fragmentation. For the purpose of construction of IKE Fragment messages, the original (unencrypted) content of the Encrypted payload is split into chunks. The content is treated as a binary blob and is split regardless of the boundaries of inner payloads. Each of the resulting chunks is treated as an original content of the Encrypted Fragment payload, and is encrypted and authenticated. The Encrypted Fragment payload thus contains a chunk of the original content of the Encrypted payload in encrypted form. The Encrypted Fragment payload, if present in a message, will be the last payload in the message.

The maximum fragmentation size is selected based on the value configured through the CLI under the Crypto Template Configuration Mode. For more information, refer Configuring MTU Size for the IKEv2 Payload.

IPSec receives the encrypted IKEv2 packets and decrypts the encrypted payload. If all fragments are not received, IPSec maintains a timer of 10 seconds, after which the fragments are discarded.

IPSec drops the received fragmented packets during the following scenarios:

• When the received fragment is already present in the buffer.

• When the received fragment exceeds the maximum IKEv2 fragments (255) allowed.

• When each fragment's size exceeds 1932 bytes for IPv4 and 1912 bytes for IPv6.

• When the packet size exceeds 10,000 bytes after re-assembly.

This section identifies limitations and restrictions for IKEv2 fragmentation:

• Since IKE Fragment messages are cryptographically protected, SK_a and SK_e must already be calculated. In general, the original message can be fragmented if and only if it contains an encrypted payload. Unprotected payloads cannot be fragmented.

• Among existing IKEv2 extensions, messages of an IKE_SESSION_RESUME exchange, as defined in RFC 5723 cannot be fragmented.

• The Gateway allows fragmenting of IKEv2 packet in downlink, and re-assembling of received IKEv2 packet only if "fragmentation_supported" is negotiated by both peers.

• If the received IKEv2 fragments are greater than 255, the fragments are dropped.

This feature complies with the following standards:

• RFC 7383 - Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation

• RFC 7296 - Internet Key Exchange Protocol Version 2 (IKEv2) (for cryptographic processing)

Use the following configuration to enable or disable IKESA fragmentation (Tx) and re-assembly (Rx):

configure 
    context context_name 
        crypto template template_name ikev2-dynamic 
            [ no | default ] ikev2-ikesa fragmentation 
            end 

Notes:

• If previously configured, use the no keyword to disable IKESA fragmentation and re-assembly support.

• Use the default keyword to set the configuration to its default value. By default, IKESA fragmentation and re-assembly is allowed.

Use the following configuration to set the Maximum Transmission Unit (MTU) size for the IKEv2 payload over the IPv4 and/or IPv6 tunnels:

configure 
    context context_name 
        crypto template template_name ikev2-dynamic 
            { ip | ipv6 } ikev2-mtu ikev2_mtu_size 
            end 

Notes:

• Use the default ip ikev2-mtu or default ipv6 ikev2-mtu commands to set the IKEv2 payload to its default value.

• Default (IPv4): 1384 bytes

• Default (IPv6): 1364 bytes

• ikev2_mtu_size (IPv4)must be an integer from 460 through 1932.

• ikev2_mtu_size (IPv6)must be an integer from 1144 through 1912.

The following bulks statistics included in the System schema support this feature: