Network Working Group D. Liu, Ed. Internet-Draft D. Migault Intended status: Standards Track R. Liu Expires: 25 August 2022 C. Zhang Ericsson 21 February 2022 IKEv2 MTU Detection Extension draft-liu-ipsecme-ikev2-mtu-dect-00 Abstract 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. 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. Liu, et al. Expires 25 August 2022 [Page 1] Internet-Draft IKEv2 MTU Detection Extension February 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Allowed MTU Notify Message Types . . . . . . . . . . . . . . 3 4. IKEv2 Session MTU Detection . . . . . . . . . . . . . . . . . 4 4.1. Allowed MTU Calculation for IPv4 ESP . . . . . . . . . . 4 4.2. Allowed MTU Calculation for IPv6 ESP . . . . . . . . . . 5 4.3. Send ALLOWED_MTU Notify Message . . . . . . . . . . . . . 5 5. Process Based on Detected MTU . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 Liu, et al. Expires 25 August 2022 [Page 2] Internet-Draft IKEv2 MTU Detection Extension February 2022 * 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 | +-------+----------------------------------------+ Figure 1: ALLOWED_MTU Notify Message Type Value 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Liu, et al. Expires 25 August 2022 [Page 3] Internet-Draft IKEv2 MTU Detection Extension February 2022 Figure 2: REKEY_PRI Notify Message Format * 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Notification Data for ALLOWED_MTU 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 4.1. Allowed MTU Calculation for IPv4 ESP [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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IPv4 Header Liu, et al. Expires 25 August 2022 [Page 4] Internet-Draft IKEv2 MTU Detection Extension February 2022 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. 4.2. Allowed MTU Calculation for IPv6 ESP [RFC2460] section 4.5 defines standard IPv6 fragment header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: 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. 4.3. Send ALLOWED_MTU Notify Message 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]} --> Figure 6: INFORMATIONAL Message for 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. Liu, et al. Expires 25 August 2022 [Page 5] Internet-Draft IKEv2 MTU Detection Extension February 2022 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 | +-------+----------------------------------------+ Figure 7 8. Acknowledgements This document reproduces some parts of the similar IKEv2 document [RFC7296], IP document [RFC0791], IPv6 document [RFC2460], and [RFC8900]. 9. References Liu, et al. Expires 25 August 2022 [Page 6] Internet-Draft IKEv2 MTU Detection Extension February 2022 9.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, . Authors' Addresses Daiying Liu (editor) Ericsson Email: harold.liu@ericsson.com Liu, et al. Expires 25 August 2022 [Page 7] Internet-Draft IKEv2 MTU Detection Extension February 2022 Daniel Migault Ericsson Email: daniel.migault@ericsson.com Renwang Liu Ericsson Email: renwang.liu@ericsson.com Congjie Zhang Ericsson Email: congjie.zhang@ericsson.com Liu, et al. Expires 25 August 2022 [Page 8]