< draft-ietf-ipsecme-iptfs-09.txt		draft-ietf-ipsecme-iptfs-10.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 July 5, 2021		Intended status: Standards Track September 3, 2021
	Expires: January 6, 2022		Expires: March 7, 2022
	IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP		IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP
	Traffic Flow Security		Traffic Flow Security
	draft-ietf-ipsecme-iptfs-09		draft-ietf-ipsecme-iptfs-10
	Abstract		Abstract
	This document describes a mechanism for aggregation and fragmentation		This document describes a mechanism for aggregation and fragmentation
	of IP packets when they are being encapsulated in ESP payload. This		of IP packets when they are being encapsulated in ESP payload. This
	new payload type can be used for various purposes such as decreasing		new payload type can be used for various purposes such as decreasing
	encapsulation overhead for small IP packets; however, the focus in		encapsulation overhead for small IP packets; however, the focus in
	this document is to enhance IPsec traffic flow security (IP-TFS) by		this document is to enhance IPsec traffic flow security (IP-TFS) by
	adding Traffic Flow Confidentiality (TFC) to encrypted IP		adding Traffic Flow Confidentiality (TFC) to encrypted IP
	encapsulated traffic. TFC is provided by obscuring the size and		encapsulated traffic. TFC is provided by obscuring the size and
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 January 6, 2022.		This Internet-Draft will expire on March 7, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 7, line 23 ¶		skipping to change at page 7, line 23 ¶
	number based sliding window can be used to correct re-ordering of the		number based sliding window can be used to correct re-ordering of the
	outer packet stream. Receiving a larger (newer) sequence number		outer packet stream. Receiving a larger (newer) sequence number
	packet advances the window, and received older ESP packets whose		packet advances the window, and received older ESP packets whose
	sequence numbers the window has passed by are dropped. A good choice		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		for the size of this window depends on the amount of re-ordering the
	user may normally experience.		user may normally experience.
	As the amount of reordering that may be present is hard to predict,		As the amount of reordering that may be present is hard to predict,
	the window size SHOULD be configurable by the user. Implementations		the window size SHOULD be configurable by the user. Implementations
	MAY also dynamically adjust the reordering window based on actual		MAY also dynamically adjust the reordering window based on actual
	reordering seen in arriving packets. Finally, note that as IP-TFS is		reordering seen in arriving packets.
	sending a continuous stream of packets there is no requirement for
	timers (although there's no prohibition either) as newly arrived		Please note when IP-TFS sends a continuous stream of packets, there
	packets will cause the window to advance and older packets will then		is no requirement for an explicit drop timer; however, using a drop
	be processed as they leave the window. Implementations that are		timer is RECOMMENDED. If an implementation does not use a drop timer
	concerned about memory use when packets are delayed (e.g., when an SA		and only considers an outer packet lost when the reorder window moves
	deletion is delayed), or non-IP-TFS uses of AGGFRAG mode, can of		by it, the inner traffic can be delayed by up to the reorder window
	course use timers to drop packets as well.		size times the per packet send rate. This amount of delay could be
			significant for slower send rates or when larger reorder window sizes
			are in use.
	While ESP guarantees an increasing sequence number with subsequently		While ESP guarantees an increasing sequence number with subsequently
	sent packets, it does not actually require the sequence numbers to be		sent packets, it does not actually require the sequence numbers to be
	generated with no gaps (e.g., sending only even numbered sequence		generated with no gaps (e.g., sending only even numbered sequence
	numbers would be allowed as long as they are always increasing).		numbers would be allowed as long as they are always increasing).
	Gaps in the sequence numbers will not work for this document so the		Gaps in the sequence numbers will not work for this document so the
	sequence number stream MUST increase monotonically by 1 for each		sequence number stream MUST increase monotonically by 1 for each
	subsequent packet.		subsequent packet.
	When using the AGGFRAG_PAYLOAD in conjunction with replay detection,		When using the AGGFRAG_PAYLOAD in conjunction with replay detection,
	the window size for both MAY be reduced to the smaller of the two		the window size for both MAY be reduced to the smaller of the two
	window sizes. This is because packets outside of the smaller window		window sizes. This is because packets outside of the smaller window
	but inside the larger would still be dropped by the mechanism with		but inside the larger would still be dropped by the mechanism with
	the smaller window size. However, there is also no requirement to		the smaller window size. However, there is also no requirement to
	make these values the same. Indeed, in some cases, such as slow		make these values the same. Indeed, in some cases, such as slow
	tunnels where a very small or zero reorder window size is		tunnels where a very small or zero reorder window size is
	appropriate, the user may want a large replay detection window to log		appropriate, the user may still want a large replay detection window
	replayed packets. Additionally, large replay windows can be		to log replayed packets. Additionally, large replay windows can be
	implemented with very little overhead compared to large reorder		implemented with very little overhead compared to large reorder
	windows.		windows.
	Finally, as sequence numbers are reset when switching SAs (e.g., when		Finally, as sequence numbers are reset when switching SAs (e.g., when
	re-keying a child SA), senders MUST NOT send initial fragments of an		re-keying a child SA), senders MUST NOT send initial fragments of an
	inner packet using one SA and subsequent fragments in a different SA.		inner packet using one SA and subsequent fragments in a different SA.
	2.2.3.1. Optional Extra Padding		2.2.3.1. Optional Extra Padding
	When the tunnel bandwidth is not being fully utilized, a sender MAY		When the tunnel bandwidth is not being fully utilized, a sender MAY
End of changes. 5 change blocks.
	14 lines changed or deleted		16 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/