< draft-ietf-ipsecme-iptfs-04.txt		draft-ietf-ipsecme-iptfs-05.txt >
	Network Working Group C. Hopps		Network Working Group C. Hopps
	Internet-Draft LabN Consulting, L.L.C.		Internet-Draft LabN Consulting, L.L.C.
	Intended status: Standards Track December 18, 2020		Intended status: Standards Track December 20, 2020
	Expires: June 21, 2021		Expires: June 23, 2021
	IP Traffic Flow Security Using Aggregation and Fragmentation		IP Traffic Flow Security Using Aggregation and Fragmentation
	draft-ietf-ipsecme-iptfs-04		draft-ietf-ipsecme-iptfs-05
	Abstract		Abstract
	This document describes a mechanism to enhance IPsec traffic flow		This document describes a mechanism to enhance IPsec traffic flow
	security by adding traffic flow confidentiality to encrypted IP		security by adding traffic flow confidentiality to encrypted IP
	encapsulated traffic. Traffic flow confidentiality is provided by		encapsulated traffic. Traffic flow confidentiality is provided by
	obscuring the size and frequency of IP traffic using a fixed-sized,		obscuring the size and frequency of IP traffic using a fixed-sized,
	constant-send-rate IPsec tunnel. The solution allows for congestion		constant-send-rate IPsec tunnel. The solution allows for congestion
	control as well as non-constant send-rate usage.		control as well as non-constant send-rate usage.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 June 21, 2021.		This Internet-Draft will expire on June 23, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 3		1.1. Terminology & Concepts . . . . . . . . . . . . . . . . . 3
	2. The IP-TFS Tunnel . . . . . . . . . . . . . . . . . . . . . . 4		2. The IP-TFS Tunnel . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4		2.1. Tunnel Content . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5		2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5
	2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 6		2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 6
	2.2.2. No Implicit End Padding Required . . . . . . . . . . 6		2.2.2. No Implicit End Padding Required . . . . . . . . . . 6
	2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads 6		2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads 6
	2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 7		2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 7
	2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 7		2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 8
	2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7		2.2.6. IP Time-To-Live (TTL) and Tunnel errors . . . . . . . 8
	2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 7		2.2.7. Effective MTU of the Tunnel . . . . . . . . . . . . . 8
	2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 8		2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 8
	2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 8		2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 9
	3. Congestion Information . . . . . . . . . . . . . . . . . . . 9		2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 9
	3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10		2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 9
	4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 11		3. Congestion Information . . . . . . . . . . . . . . . . . . . 10
	4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 11		3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 11		4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11		4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 12
	5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 11		4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 12
	6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12		5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 12		5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 13
	6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 13		6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 13
	6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 13		6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 13
	6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 15		6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 14
	6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 17		6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 16
	7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 18		6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 18
	7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 21		9.1. Normative References . . . . . . . . . . . . . . . . . . 20
	Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 22		Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 22
	C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 22		Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 23
	C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 22		Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 23
	C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 23		C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 23
	C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 24		C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 23
	C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 24		C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 24
	C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 25
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27		C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 25
	Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 27		C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 25
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27		C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 26
			Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 28
			Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 28
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting		Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting
	information about data being sent through a network. While one may		information about data being sent through a network. While one may
	directly obscure the data through the use of encryption [RFC4303],		directly obscure the data through the use of encryption [RFC4303],
	the traffic pattern itself exposes information due to variations in		the traffic pattern itself exposes information due to variations in
	it's shape and timing ([I-D.iab-wire-image], [AppCrypt]). Hiding the		it's shape and timing ([I-D.iab-wire-image], [AppCrypt]). Hiding the
	size and frequency of traffic is referred to as Traffic Flow		size and frequency of traffic is referred to as Traffic Flow
	Confidentiality (TFC) per [RFC4303].		Confidentiality (TFC) per [RFC4303].
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 16 ¶
	As mentioned in Section 1 IP-TFS utilizes an IPsec [RFC4303] tunnel		As mentioned in Section 1 IP-TFS utilizes an IPsec [RFC4303] tunnel
	(SA) as it's transport. To provide for full TFC, fixed-sized		(SA) as it's transport. To provide for full TFC, fixed-sized
	encapsulating packets are sent at a constant rate on the tunnel.		encapsulating packets are sent at a constant rate on the tunnel.
	The primary input to the tunnel algorithm is the requested bandwidth		The primary input to the tunnel algorithm is the requested bandwidth
	used by the tunnel. Two values are then required to provide for this		used by the tunnel. Two values are then required to provide for this
	bandwidth, the fixed size of the encapsulating packets, and rate at		bandwidth, the fixed size of the encapsulating packets, and rate at
	which to send them.		which to send them.
	The fixed packet size may either be specified manually or can be		The fixed packet size MAY either be specified manually or could be
	determined through the use of Path MTU discovery [RFC1191] and		determined through the other methods such as the Packetization Layer
	[RFC8201].		MTU Discovery (PLMTUD) ([RFC4821], [RFC8899]) or Path MTU discovery
			(PMTUD) ([RFC1191], [RFC8201]). PMTUD is known to have issues so
			PLMTUD is considered the more robust option.
	Given the encapsulating packet size and the requested tunnel used		Given the encapsulating packet size and the requested tunnel used
	bandwidth, the corresponding packet send rate can be calculated. The		bandwidth, the corresponding packet send rate can be calculated. The
	packet send rate is the requested bandwidth divided by the size of		packet send rate is the requested bandwidth divided by the size of
	the encapsulating packet.		the encapsulating packet.
	The egress of the IP-TFS tunnel MUST allow for and expect the ingress		The egress of the IP-TFS tunnel MUST allow for and expect the ingress
	(sending) side of the IP-TFS tunnel to vary the size and rate of sent		(sending) side of the IP-TFS tunnel to vary the size and rate of sent
	encapsulating packets, unless constrained by other policy.		encapsulating packets, unless constrained by other policy.
	skipping to change at page 5, line 18 ¶		skipping to change at page 5, line 18 ¶
	comprised of a 4 or 24 octet header followed by either a partial, a		comprised of a 4 or 24 octet header followed by either a partial, a
	full or multiple partial or full data blocks. The following diagram		full or multiple partial or full data blocks. The following diagram
	illustrates this payload within the ESP packet. See Section 6.1 for		illustrates this payload within the ESP packet. See Section 6.1 for
	the exact formats of the AGGFRAG_PAYLOAD payload.		the exact formats of the AGGFRAG_PAYLOAD payload.
	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	. Outer Encapsulating Header ... .		. Outer Encapsulating Header ... .
	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	. ESP Header... .		. ESP Header... .
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| ... : BlockOffset |		| [AGGFRAG subtype/flags] : BlockOffset |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	: [Optional Congestion Info] :		: [Optional Congestion Info] :
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| DataBlocks ... ~		| DataBlocks ... ~
	~ ~		~ ~
	~ |		~ |
	+---------------------------------------------------------------|		+---------------------------------------------------------------|
	. ESP Trailer... .		. ESP Trailer... .
	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	skipping to change at page 5, line 46 ¶		skipping to change at page 5, line 46 ¶
	Conversely, if the "BlockOffset" value is non-zero it points to the		Conversely, if the "BlockOffset" value is non-zero it points to the
	start of the new data block, and the initial "DataBlocks" data		start of the new data block, and the initial "DataBlocks" data
	belongs to a previous data block that is still being re-assembled.		belongs to a previous data block that is still being re-assembled.
	The "BlockOffset" can point past the end of the "DataBlocks" data		The "BlockOffset" can point past the end of the "DataBlocks" data
	which indicates that the next data block occurs in a subsequent		which indicates that the next data block occurs in a subsequent
	encapsulating packet.		encapsulating packet.
	Having the "BlockOffset" always point at the next available data		Having the "BlockOffset" always point at the next available data
	block allows for recovering the next full inner packet in the		block allows for recovering the next inner packet in the presence of
	presence of outer encapsulating packet loss.		outer encapsulating packet loss.
	An example IP-TFS packet flow can be found in Appendix A.		An example IP-TFS packet flow can be found in Appendix A.
	2.2.1. Data Blocks		2.2.1. Data Blocks
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| Type | rest of IPv4, IPv6 or pad.		| Type | rest of IPv4, IPv6 or pad.
	+--------		+--------
	Figure 2: Layout of IP-TFS data block		Figure 2: Layout of IP-TFS data block
	skipping to change at page 7, line 5 ¶		skipping to change at page 6, line 50 ¶
	pad" payloads (i.e., payloads with a "BlockOffset" of zero and a		pad" payloads (i.e., payloads with a "BlockOffset" of zero and a
	single pad "DataBlock") in between the packets carrying the inner-		single pad "DataBlock") in between the packets carrying the inner-
	packet fragment payloads. This possible interleaving of all-pad		packet fragment payloads. This possible interleaving of all-pad
	payloads allows the sender to always be able to send a tunnel packet,		payloads allows the sender to always be able to send a tunnel packet,
	regardless of the encapsulation computational requirements.		regardless of the encapsulation computational requirements.
	When a receiver is reassembling an inner-packet, and it receives an		When a receiver is reassembling an inner-packet, and it receives an
	"all-pad" payload, it increments the expected sequence number that		"all-pad" payload, it increments the expected sequence number that
	the next inner-packet fragment is expected to arrive in.		the next inner-packet fragment is expected to arrive in.
			Given the above, the receiver will need to handle out-of-order
			arrival of outer ESP packets prior to reassembly processing. ESP
			already provides for detecting replay attacks (normally) utilizing a
			window. A similar sequence number based sliding window can be used
			to correct re-ordering of the outer packet stream. Receiving a
			larger (newer) sequence number packet advances the window, and
			received older ESP packets whose sequence numbers the window has
			passed by are dropped. A good choice for the size of this window
			depends on the amount of re-ordering the user may normally
			experience. As the amount of reordering that may be present is hard
			to predict the window size SHOULD be configurable by the user.
			Implementations MAY also dynamically adjust the reordering window
			based on actual reordering seen in arriving packets. Finally, we
			note that as IP-TFS is sending a continuous stream of packets there
			is no requirement for timers (although there's no prohibition either)
			as newly arrived packets will cause the window to advance and older
			packets will then be processed as they leave the window.
			2.2.3.1. Optional Extra Padding
			When the tunnel bandwidth is not being fully utilized, an
			implementation MAY pad-out the current encapsulating packet in order
			to deliver an inner packet un-fragmented in the following outer
			packet. The benefit would be to avoid inner-packet fragmentation in
			the presence of a bursty offered load (non-bursty traffic will
			naturally not fragment). The cost is complexity and added delay of
			inner traffic. The main advantage to avoiding fragmentation is to
			minimize inner packet loss in the presence of outer packet loss.
			When this is worthwhile (e.g., how much loss and what type of loss is
			required, given different inner traffic shapes and utilization, for
			this to make sense), and what values to use for the allowable/added
			delay may be worth researching, but is outside the scope of this
			document.
			While use of padding to avoid fragmentation does not impact
			interoperability, used inappropriately it can reduce the effective
			throughput of a tunnel. Implementations implementing the above
			approach will need to take care to not reduce the effective capacity,
			and overall utility, of the tunnel through the overuse of padding.
	2.2.4. Empty Payload		2.2.4. Empty Payload
	In order to support reporting of congestion control information		In order to support reporting of congestion control information
	(described later) on a non-AGGFRAG_PAYLOAD enabled SA, IP-TFS allows		(described later) on a non-AGGFRAG_PAYLOAD enabled SA, IP-TFS allows
	for the sending of an AGGFRAG_PAYLOAD payload with no data blocks		for the sending of an AGGFRAG_PAYLOAD payload with no data blocks
	(i.e., the ESP payload length is equal to the AGGFRAG_PAYLOAD header		(i.e., the ESP payload length is equal to the AGGFRAG_PAYLOAD header
	length). This special payload is called an empty payload.		length). This special payload is called an empty payload.
	2.2.5. IP Header Value Mapping		2.2.5. IP Header Value Mapping
	skipping to change at page 7, line 33 ¶		skipping to change at page 8, line 25 ¶
	unrelated to the IP-TFS tunnel functionality; IP-TFS never IP		unrelated to the IP-TFS tunnel functionality; IP-TFS never IP
	fragments the inner packets and the inner packets will not affect the		fragments the inner packets and the inner packets will not affect the
	fragmentation of the outer encapsulation packets. Likewise, the ECN		fragmentation of the outer encapsulation packets. Likewise, the ECN
	value need not be mapped as any congestion related to the constant-		value need not be mapped as any congestion related to the constant-
	send-rate IP-TFS tunnel is unrelated (by design!) to the inner		send-rate IP-TFS tunnel is unrelated (by design!) to the inner
	traffic flow. Finally, by default the DS field SHOULD NOT be copied		traffic flow. Finally, by default the DS field SHOULD NOT be copied
	although an implementation MAY choose to allow for configuration to		although an implementation MAY choose to allow for configuration to
	override this behavior. An implementation SHOULD also allow the DS		override this behavior. An implementation SHOULD also allow the DS
	value to be set by configuration.		value to be set by configuration.
			2.2.6. IP Time-To-Live (TTL) and Tunnel errors
			[RFC4301] specifies how to modify the inner packet TTL ([RFC0791]).
			Any errors (e.g., ICMP errors arriving back at the tunnel ingress due
			to tunnel traffic) should be handled the same as with non IP-TFS
			IPsec tunnels.
			2.2.7. Effective MTU of the Tunnel
			Unlike [RFC4301], there is normally no effective MTU (EMTU) on an IP-
			TFS tunnel as all IP packet sizes are properly transmitted without
			requiring IP fragmentation prior to tunnel ingress.
			If IP-TFS fragmentation has been disabled, then the tunnel's EMTU and
			behaviors are the same as normal IPsec tunnels ([RFC4301]).
	2.3. Exclusive SA Use		2.3. Exclusive SA Use
	It is not the intention of this specification to allow for mixed use		It is not the intention of this specification to allow for mixed use
	of an AGGFRAG_PAYLOAD enabled SA. In other words, an SA that has		of an AGGFRAG_PAYLOAD enabled SA. In other words, an SA that has
	AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads		AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads
	such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad		such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad
	packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD		packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD
	payloads. While it's possible to envision making the algorithm work		payloads. While it's possible to envision making the algorithm work
	in the presence of sequence number skips in the AGGFRAG_PAYLOAD		in the presence of sequence number skips in the AGGFRAG_PAYLOAD
	payload stream, the added complexity is not deemed worthwhile. Other		payload stream, the added complexity is not deemed worthwhile. Other
	skipping to change at page 11, line 31 ¶		skipping to change at page 12, line 40 ¶
	Bandwidth is a local configuration option. For non-congestion		Bandwidth is a local configuration option. For non-congestion
	controlled mode the bandwidth SHOULD be configured. For congestion		controlled mode the bandwidth SHOULD be configured. For congestion
	controlled mode one can configure the bandwidth or have no		controlled mode one can configure the bandwidth or have no
	configuration and let congestion control discover the maximum		configuration and let congestion control discover the maximum
	bandwidth available. No standardized configuration method is		bandwidth available. No standardized configuration method is
	required.		required.
	4.2. Fixed Packet Size		4.2. Fixed Packet Size
	The fixed packet size to be used for the tunnel encapsulation packets		The fixed packet size to be used for the tunnel encapsulation packets
	can be configured manually or can be automatically determined using		MAY be configured manually or can be automatically determined using
	Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized		other methods such as PLMTUD ([RFC4821], [RFC8899]) or PMTUD
	configuration method is required.		([RFC1191], [RFC8201]). As PMTUD is known to have issues, PLMTUD is
			considered the more robust option. No standardized configuration
			method is required.
	4.3. Congestion Control		4.3. Congestion Control
	Congestion control is a local configuration option. No standardized		Congestion control is a local configuration option. No standardized
	configuration method is required.		configuration method is required.
	5. IKEv2		5. IKEv2
	5.1. USE_AGGFRAG Notification Message		5.1. USE_AGGFRAG Notification Message
	skipping to change at page 20, line 30 ¶		skipping to change at page 21, line 30 ¶
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <https://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for		[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
	Datagram Congestion Control Protocol (DCCP) Congestion		Datagram Congestion Control Protocol (DCCP) Congestion
	Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,		Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
	DOI 10.17487/RFC4342, March 2006,		DOI 10.17487/RFC4342, March 2006,
	<https://www.rfc-editor.org/info/rfc4342>.		<https://www.rfc-editor.org/info/rfc4342>.
			[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
			Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
			<https://www.rfc-editor.org/info/rfc4821>.
	[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP		[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
	Friendly Rate Control (TFRC): Protocol Specification",		Friendly Rate Control (TFRC): Protocol Specification",
	RFC 5348, DOI 10.17487/RFC5348, September 2008,		RFC 5348, DOI 10.17487/RFC5348, September 2008,
	<https://www.rfc-editor.org/info/rfc5348>.		<https://www.rfc-editor.org/info/rfc5348>.
	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code		[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
	Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January		Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
	2014, <https://www.rfc-editor.org/info/rfc7120>.		2014, <https://www.rfc-editor.org/info/rfc7120>.
	[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,		[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
	skipping to change at page 21, line 15 ¶		skipping to change at page 22, line 20 ¶
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,		[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
	"Path MTU Discovery for IP version 6", STD 87, RFC 8201,		"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
	DOI 10.17487/RFC8201, July 2017,		DOI 10.17487/RFC8201, July 2017,
	<https://www.rfc-editor.org/info/rfc8201>.		<https://www.rfc-editor.org/info/rfc8201>.
			[RFC8899] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
			T. Voelker, "Packetization Layer Path MTU Discovery for
			Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
			September 2020, <https://www.rfc-editor.org/info/rfc8899>.
	Appendix A. Example Of An Encapsulated IP Packet Flow		Appendix A. Example Of An Encapsulated IP Packet Flow
	Below an example inner IP packet flow within the encapsulating tunnel		Below an example inner IP packet flow within the encapsulating tunnel
	packet stream is shown. Notice how encapsulated IP packets can start		packet stream is shown. Notice how encapsulated IP packets can start
	and end anywhere, and more than one or less than 1 may occur in a		and end anywhere, and more than one or less than 1 may occur in a
	single encapsulating packet.		single encapsulating packet.
	Offset: 0 Offset: 100 Offset: 2900 Offset: 1400		Offset: 0 Offset: 100 Offset: 2900 Offset: 1400
	[ ESP1 (1500) ][ ESP2 (1500) ][ ESP3 (1500) ][ ESP4 (1500) ]		[ ESP1 (1500) ][ ESP2 (1500) ][ ESP3 (1500) ][ ESP4 (1500) ]
	[--800--][--800--][60][-240-][--4000----------------------][pad]		[--800--][--800--][60][-240-][--4000----------------------][pad]
	skipping to change at page 27, line 9 ¶		skipping to change at page 28, line 9 ¶
	Notice that the latency values are very similar between the two		Notice that the latency values are very similar between the two
	solutions; however, whereas IP-TFS provides for constant high		solutions; however, whereas IP-TFS provides for constant high
	bandwidth, in some cases even exceeding native Ethernet, ESP with		bandwidth, in some cases even exceeding native Ethernet, ESP with
	padding often greatly reduces available bandwidth.		padding often greatly reduces available bandwidth.
	Appendix D. Acknowledgements		Appendix D. Acknowledgements
	We would like to thank Don Fedyk for help in reviewing and editing		We would like to thank Don Fedyk for help in reviewing and editing
	this work. We would also like to thank Valery Smyslov for reviews		this work. We would also like to thank Valery Smyslov for reviews
	and suggestions for improvements.		and suggestions for improvements as well as Joseph Touch for the
			transport area review and suggested improvements.
	Appendix E. Contributors		Appendix E. Contributors
	The following people made significant contributions to this document.		The following people made significant contributions to this document.
	Lou Berger		Lou Berger
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	Email: lberger@labn.net		Email: lberger@labn.net
End of changes. 13 change blocks.
	52 lines changed or deleted		126 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/