IKEv2 MTU Detection Extension
draft-liu-ipsecme-ikev2-mtu-dect-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Daiying Liu , Daniel Migault , Renwang Liu , Congjie Zhang | ||
| Last updated | 2022-02-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-ipsecme-ikev2-mtu-dect-00
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,
<https://www.rfc-editor.org/info/rfc791>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[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,
<https://www.rfc-editor.org/info/rfc4443>.
[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, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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,
<https://www.rfc-editor.org/info/rfc8900>.
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]