IKEv2 MTU Detection Extension

Status of This Memo

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 25 August 2022.¶

Copyright Notice

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.¶

Table of Contents

1. Introduction

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]:¶

• 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.¶

2. Requirements Language

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].¶

3. Allowed MTU Notify Message Types

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                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Next Payload - N(41), indicate this is Notify payload.¶
• Notify Message Type - ALLOWED_MTU (TDB).¶
• Notification Data - 4 octets for ALLOWED_MTU, see Figure 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          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.¶

4. IKEv2 Session MTU Detection

    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Local                              Remote
              -----------------------------------------
              HDR, SK {N[ALLOWED_MTU]}  -->

5. Process Based on Detected MTU

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 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 [RFC0792], and "Too Big" for IPv6 [RFC4443]) 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.¶

6. Security Considerations

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.¶

7. IANA Considerations

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               |
           +-------+----------------------------------------+

8. Acknowledgements

This document reproduces some parts of the similar IKEv2 document [RFC7296], IP document [RFC0791], IPv6 document [RFC2460], and [RFC8900].¶

Authors' Addresses