| Internet-Draft | IKEv2 MTU Detection Extension | March 2022 |
| Liu, et al. | Expires 29 September 2022 | [Page] |
This document defines the Internet Key Exchange Version 2 (IKEv2) allowed Maximum Transmission Unit (MTU) extension that enables to automatically detect MTU allowed on forwarding path of each IKEv2 session to prevent Encapsulating Security Payload (ESP) packets from being fragmented.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 September 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
[RFC8900] describes in detail the negative impact of IP packet fragmentation. Here are some weakness of IP fragmentation quoted from section 3 of [RFC8900]:¶
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 [RFC2119] [RFC8174].¶
The following figure illustrates the Notify Payload format as described in Section 3.10 of [RFC7296] with a 4 bytes path allowed MTU value as notification data.¶
The ALLOWED_MTU notify SHOULD be used in an IKEv2 INFORMATIONAL exchange.¶
+=======+========================================+
| Value | NOTIFY MESSAGES - STATUS TYPES |
+=======+========================================+
| 16446 | ALLOWED_MTU |
+-------+----------------------------------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MTU Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
[RFC0791] section 3.1 defines standard IPv4 header:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
[RFC2460] section 4.5 defines standard IPv6 fragment header:¶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
Local Remote
-----------------------------------------
HDR, SK {N[ALLOWED_MTU]} -->
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 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 Section 4) 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:¶
+=======+========================================+
| Value | NOTIFY MESSAGES - STATUS TYPES |
+=======+========================================+
| TBD | ALLOWED_MTU |
+-------+----------------------------------------+
This document reproduces some parts of the similar IKEv2 document [RFC7296], IP document [RFC0791], IPv6 document [RFC2460], and [RFC8900].¶
The authors would like to thank Paul Wouters for his reviews and valuable comments and suggestions.¶