IKEv2 MTU Detection Extension

The basic function of IP Security (IPsec) is to securely transmit IP packets on an untrusted network. In practical applications many factors in this untrusted network, including MTU, are uncontrollable which means that even cannot modify the configuration. Therefore ESP packets may be fragmented because they exceed the MTU of a router on the forwarding path which causes many problems. describes in detail the negative impact of IP packet fragmentation. Here are some weakness of IP fragmentation quoted from section 3 of : Virtual Reassembly Policy-Based Routing Network Address Translation (NAT) Stateless Firewalls IPv4 Reassembly Errors at High Data Rates Security Vulnerabilities Black-Holing Due to Filtering or Loss For IPsec the previously listed effects are more obvious and directly affect the security, stability, and performance of IPsec. So this document recommend an IKEv2 allowed MTU extension to enable a determinate mechanism to automatically detect MTU allowed on each IKEv2 session forwarding path to prevent ESP packets from being fragmented.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The following figure illustrates the Notify Payload format as described in Section 3.10 of with a 4 bytes path allowed MTU value as notification data. The ALLOWED_MTU notify SHOULD be used in an IKEv2 INFORMATIONAL exchange.

Next Payload - N(41), indicate this is Notify payload. Notify Message Type - ALLOWED_MTU (TDB). Notification Data - 4 octets for ALLOWED_MTU, see :

The device SHOULD continuously check whether the received ESP packet is fragmented. If the ESP packet is fragmented the device needs to calculate the MTU allowed on the forwarding path from fragments and notify the sender to deal with accordingly.

section 3.1 defines standard IPv4 header:

The "Flags" field identifies whether ESP packets are fragmented. The "Fragment Offset" field indicates whether this fragment is initial (the "MF" bit in the initial fragment "Flags" field MUST be 1, and the "Fragment Offset" field MUST be 0). It can use the "Total Length" field of initial fragment to calculate the MTU of the router that fragments on the forwarding path, that is the maximum MTU allowed on the current forwarding path.

section 4.5 defines standard IPv6 fragment header:

Similar to IPv4, for IPv6 ESP the "Fragment Header" can identify whether ESP packets are fragmented. The field "M" and "Fragment Offset" indicate whether this fragment is initial (the "M" bit in the initial fragment MUST be 1, and the "Fragment Offset" field MUST be 0). And the MTU can be calculated from initial fragment length following the same method of IPv4.

The ALLOWED_MTU notify message SHOULD be exchanged via the IKEv2 INFORMATIONAL message to inform the peer the current MTU of this IKEv2 session.

]]> The device SHOULD continuously check whether the received ESP packet is fragmented even after ALLOWED_MTU notify message is sent, because new MTU changes may occur as paths over the internet change.

If a malicious entity able to filter on path would "fragment" the packet into tiny bits. It would reduce the MTU of the IPsec link to unhealthy size. Therefore, the minimum MTU value MUST be defined. If the MTU of a fragmented packet is smaller than the minimum MTU, it SHOULD be considered as a malicious attack. Therefore, the packet SHOULD be discarded instead of sent the ALLOWED_MTU notify message to protect the entire system. A recommendation for implementation is that the minimum MTU SHOULD be user-configurable for different deployments. This is to consider the complexity and variability of the network, configurable minimum MTU can make deployment more flexible.

After receiving the ALLOWED_MTU notify message the sending end of the ESP packet knows the MTU allowed on the forwarding path, then the sending end SHOULD take specific actions before sending ESP packets to prevent the ESP packet from being fragmented. Before performing IP packet encryption and ESP encapsulation firstly calculate the final packet MTU considering the additional ESP header, ESP tailor and tunnel header. If the final packet MTU does not exceed the negotiated MTU just follow the normal process. Otherwise the following 2 options are proposed: The IKEv2 end sends ICMP ("Destination Unreachable" for IPv4 , and "Too Big" for IPv6 ) to the original IP packet sender, then the sender can reduce the IP packet size by following ICMP standard. The local IKEv2 end directly frags the original packet according to the negotiated MTU, and then encrypts and encapsulates the fragments. This can guarantee the ESP packets are not fragmented by routers on the forwarding path, and the IKEv2 peer receives the ESP required to follow the normal process to decapsulate and decrypt then forward the fragments of the original IP packets to the application, the application can reassemble them.

The specific actions on sender device after receiving ALLOWED_MTU SHOULD have a "time limit". When the "time limit" is exceeded, no specific actions is performed on the original packet and the normal process is returned. This "time limit" ensures that the session reverts to its original state - process original packets normally - after a certain amount of time, it is equivalent to a redetection of the path MTU. If the path MTU does not meet the current ESP transmission, the ESP receiver can detect the new MTU value (as described in ) and notify the ESP sender via ALLOWED_MTU notify message again. This mechanism is designed to cover the path MTU change case, especially MTU increases due to path changes. It RECOMMENDED that this "time limit" should be flexible, in other words configurable at the implementation level. Because in theory, the path MTU does not change frequently, and redetection of the MTU may temporarily introduce packet loss caused by ESP fragmented packets. Therefore, users should decide the "time limit" value based on actual network conditions.

This document defines the new IKE Notify message types that are naturally protected by the IKE encryption mechanism when the payloads are applied. So, there is no security problem or potential risk.

IANA needs to update the "IKEv2 Notify Message Types - Status Types" registry (available at https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16) with the following definition:

This document reproduces some parts of the similar IKEv2 document , IP document , IPv6 document , and . The authors would like to thank Paul Wouters for his reviews and valuable comments and suggestions.