< draft-liu-ipsecme-ikev2-mtu-dect-00.txt		draft-liu-ipsecme-ikev2-mtu-dect-01.txt >
	Network Working Group D. Liu, Ed.		Network Working Group D. Liu, Ed.
	Internet-Draft D. Migault		Internet-Draft D. Migault
	Intended status: Standards Track R. Liu		Intended status: Standards Track R. Liu
	Expires: 25 August 2022 C. Zhang		Expires: 29 September 2022 C. Zhang
	Ericsson		Ericsson
	21 February 2022		28 March 2022
	IKEv2 MTU Detection Extension		IKEv2 MTU Detection Extension
	draft-liu-ipsecme-ikev2-mtu-dect-00		draft-liu-ipsecme-ikev2-mtu-dect-01
	Abstract		Abstract
	This document defines the Internet Key Exchange Version 2 (IKEv2)		This document defines the Internet Key Exchange Version 2 (IKEv2)
	allowed Maximum Transmission Unit (MTU) extension that enables to		allowed Maximum Transmission Unit (MTU) extension that enables to
	automatically detect MTU allowed on forwarding path of each IKEv2		automatically detect MTU allowed on forwarding path of each IKEv2
	session to prevent Encapsulating Security Payload (ESP) packets from		session to prevent Encapsulating Security Payload (ESP) packets from
	being fragmented.		being fragmented.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 25 August 2022.		This Internet-Draft will expire on 29 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. Allowed MTU Notify Message Types . . . . . . . . . . . . . . 3		3. Allowed MTU Notify Message Types . . . . . . . . . . . . . . 3
	4. IKEv2 Session MTU Detection . . . . . . . . . . . . . . . . . 4		4. IKEv2 Session MTU Detection . . . . . . . . . . . . . . . . . 4
	4.1. Allowed MTU Calculation for IPv4 ESP . . . . . . . . . . 4		4.1. Allowed MTU Calculation for IPv4 ESP . . . . . . . . . . 4
	4.2. Allowed MTU Calculation for IPv6 ESP . . . . . . . . . . 5		4.2. Allowed MTU Calculation for IPv6 ESP . . . . . . . . . . 5
	4.3. Send ALLOWED_MTU Notify Message . . . . . . . . . . . . . 5		4.3. Send ALLOWED_MTU Notify Message . . . . . . . . . . . . . 6
	5. Process Based on Detected MTU . . . . . . . . . . . . . . . . 5		4.4. Minimum MTU Consideration . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5. Processing Based on Detected MTU . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5.1. Processing Mechanism . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		5.2. Timeout Mechanism . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 7		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
			9.1. Normative References . . . . . . . . . . . . . . . . . . 8
			9.2. Informative References . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The basic function of IP Security (IPsec) is to securely transmit IP		The basic function of IP Security (IPsec) is to securely transmit IP
	packets on an untrusted network. In practical applications many		packets on an untrusted network. In practical applications many
	factors in this untrusted network, including MTU, are uncontrollable		factors in this untrusted network, including MTU, are uncontrollable
	which means that even cannot modify the configuration.		which means that even cannot modify the configuration.
	Therefore ESP packets may be fragmented because they exceed the MTU		Therefore ESP packets may be fragmented because they exceed the MTU
	of a router on the forwarding path which causes many problems.		of a router on the forwarding path which causes many problems.
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 31 ¶
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119] [RFC8174].		document are to be interpreted as described in [RFC2119] [RFC8174].
	3. Allowed MTU Notify Message Types		3. Allowed MTU Notify Message Types
	The following figure illustrates the Notify Payload format as		The following figure illustrates the Notify Payload format as
	described in Section 3.10 of [RFC7296] with a 4 bytes path allowed		described in Section 3.10 of [RFC7296] with a 4 bytes path allowed
	MTU value as Notification data.		MTU value as notification data.
	The ALLOWED_MTU notify SHOULD be used in an IKEv2 INFORMATIONAL		The ALLOWED_MTU notify SHOULD be used in an IKEv2 INFORMATIONAL
	exchange.		exchange.
	+=======+========================================+		+=======+========================================+
	| Value | NOTIFY MESSAGES - STATUS TYPES |		| Value | NOTIFY MESSAGES - STATUS TYPES |
	+=======+========================================+		+=======+========================================+
	| 16446 | ALLOWED_MTU |		| 16446 | ALLOWED_MTU |
	+-------+----------------------------------------+		+-------+----------------------------------------+
	skipping to change at page 3, line 39 ¶		skipping to change at page 4, line 4 ¶
	The ALLOWED_MTU notify SHOULD be used in an IKEv2 INFORMATIONAL		The ALLOWED_MTU notify SHOULD be used in an IKEv2 INFORMATIONAL
	exchange.		exchange.
	+=======+========================================+		+=======+========================================+
	| Value | NOTIFY MESSAGES - STATUS TYPES |		| Value | NOTIFY MESSAGES - STATUS TYPES |
	+=======+========================================+		+=======+========================================+
	| 16446 | ALLOWED_MTU |		| 16446 | ALLOWED_MTU |
	+-------+----------------------------------------+		+-------+----------------------------------------+
	Figure 1: ALLOWED_MTU Notify Message Type Value		Figure 1: ALLOWED_MTU Notify Message Type Value
	1 2 3		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		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 |		| Next Payload |C| RESERVED | Payload Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Protocol ID | SPI Size | Notify Message Type |		| Protocol ID | SPI Size | Notify Message Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Notification Data ~		~ Notification Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: REKEY_PRI Notify Message Format
			Figure 2: ALLOWED_MTU Notify Message Format
	* Next Payload - N(41), indicate this is Notify payload.		* Next Payload - N(41), indicate this is Notify payload.
	* Notify Message Type - ALLOWED_MTU (TDB).		* Notify Message Type - ALLOWED_MTU (TDB).
	* Notification Data - 4 octets for ALLOWED_MTU, see Figure 3:		* 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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	skipping to change at page 5, line 35 ¶		skipping to change at page 6, line 7 ¶
	Similar to IPv4, for IPv6 ESP the "Fragment Header" can identify		Similar to IPv4, for IPv6 ESP the "Fragment Header" can identify
	whether ESP packets are fragmented. The field "M" and "Fragment		whether ESP packets are fragmented. The field "M" and "Fragment
	Offset" indicate whether this fragment is initial (the "M" bit in the		Offset" indicate whether this fragment is initial (the "M" bit in the
	initial fragment MUST be 1, and the "Fragment Offset" field MUST be		initial fragment MUST be 1, and the "Fragment Offset" field MUST be
	0). And the MTU can be calculated from initial fragment length		0). And the MTU can be calculated from initial fragment length
	following the same method of IPv4.		following the same method of IPv4.
	4.3. Send ALLOWED_MTU Notify Message		4.3. Send ALLOWED_MTU Notify Message
	The "ALLOWED_MTU" notify message SHOULD be exchanged via the IKEv2		The ALLOWED_MTU notify message SHOULD be exchanged via the IKEv2
	INFORMATIONAL message to inform the peer the current MTU of this		INFORMATIONAL message to inform the peer the current MTU of this
	IKEv2 session.		IKEv2 session.
	Local Remote		Local Remote
	-----------------------------------------		-----------------------------------------
	HDR, SK {N[ALLOWED_MTU]} -->		HDR, SK {N[ALLOWED_MTU]} -->
	Figure 6: INFORMATIONAL Message for ALLOWED_MTU		Figure 6: INFORMATIONAL Message for ALLOWED_MTU
	5. Process Based on Detected 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.
			4.4. Minimum MTU Consideration
			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.
			5. Processing Based on Detected MTU
			5.1. Processing Mechanism
	After receiving the ALLOWED_MTU notify message the sending end of the		After receiving the ALLOWED_MTU notify message the sending end of the
	ESP packet knows the MTU allowed on the forwarding path, then the		ESP packet knows the MTU allowed on the forwarding path, then the
	sending end SHOULD take specific actions before sending ESP packets		sending end SHOULD take specific actions before sending ESP packets
	to prevent the ESP packet from being fragmented.		to prevent the ESP packet from being fragmented.
	Before performing IP packet encryption and ESP encapsulation firstly		Before performing IP packet encryption and ESP encapsulation firstly
	calculate the final packet MTU considering the additional ESP header		calculate the final packet MTU considering the additional ESP header,
	and tunnel header. If the final packet MTU does not exceed the		ESP tailor and tunnel header. If the final packet MTU does not
	negotiated MTU just follow the normal process. Otherwise the		exceed the negotiated MTU just follow the normal process. Otherwise
	following 2 options are proposed:		the following 2 options are proposed:
	* The IKEv2 end sends ICMP ("Destination Unreachable" for IPv4		* The IKEv2 end sends ICMP ("Destination Unreachable" for IPv4
	[RFC0792], and "Too Big" for IPv6 [RFC4443]) to the original IP		[RFC0792], and "Too Big" for IPv6 [RFC4443]) to the original IP
	packet sender, then the sender can reduce the IP packet size by		packet sender, then the sender can reduce the IP packet size by
	following ICMP standard.		following ICMP standard.
	* The local IKEv2 end directly frags the original packet according		* The local IKEv2 end directly frags the original packet according
	to the negotiated MTU, and then encrypts and encapsulates the		to the negotiated MTU, and then encrypts and encapsulates the
	fragments. This can guarantee the ESP packets are not fragmented		fragments. This can guarantee the ESP packets are not fragmented
	by routers on the forwarding path, and the IKEv2 peer receives the		by routers on the forwarding path, and the IKEv2 peer receives the
	ESP required to follow the normal process to decapsulate and		ESP required to follow the normal process to decapsulate and
	decrypt then forward the fragments of the original IP packets to		decrypt then forward the fragments of the original IP packets to
	the application, the application can reassemble them.		the application, the application can reassemble them.
			5.2. Timeout Mechanism
			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.
	6. Security Considerations		6. Security Considerations
	This document defines the new IKE Notify message types that are		This document defines the new IKE Notify message types that are
	naturally protected by the IKE encryption mechanism when the payloads		naturally protected by the IKE encryption mechanism when the payloads
	are applied. So, there is no security problem or potential risk.		are applied. So, there is no security problem or potential risk.
	7. IANA Considerations		7. IANA Considerations
	IANA needs to update the "IKEv2 Notify Message Types - Status Types"		IANA needs to update the "IKEv2 Notify Message Types - Status Types"
	registry (available at https://www.iana.org/assignments/ikev2-		registry (available at https://www.iana.org/assignments/ikev2-
	skipping to change at page 6, line 51 ¶		skipping to change at page 8, line 19 ¶
	+-------+----------------------------------------+		+-------+----------------------------------------+
	Figure 7		Figure 7
	8. Acknowledgements		8. Acknowledgements
	This document reproduces some parts of the similar IKEv2 document		This document reproduces some parts of the similar IKEv2 document
	[RFC7296], IP document [RFC0791], IPv6 document [RFC2460], and		[RFC7296], IP document [RFC0791], IPv6 document [RFC2460], and
	[RFC8900].		[RFC8900].
			The authors would like to thank Paul Wouters for his reviews and
			valuable comments and suggestions.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	DOI 10.17487/RFC0791, September 1981,		DOI 10.17487/RFC0791, September 1981,
	<https://www.rfc-editor.org/info/rfc791>.		<https://www.rfc-editor.org/info/rfc791>.
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, DOI 10.17487/RFC0792, September 1981,		RFC 792, DOI 10.17487/RFC0792, September 1981,
	<https://www.rfc-editor.org/info/rfc792>.		<https://www.rfc-editor.org/info/rfc792>.
End of changes. 14 change blocks.
	22 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/