< draft-ietf-ipsecme-iptfs-08.txt		draft-ietf-ipsecme-iptfs-09.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 March 30, 2021		Intended status: Standards Track July 5, 2021
	Expires: October 1, 2021		Expires: January 6, 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-08		draft-ietf-ipsecme-iptfs-09
	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 October 1, 2021.		This Internet-Draft will expire on January 6, 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 41 ¶		skipping to change at page 7, line 41 ¶
	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 can 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.		the smaller window size. However, there is also no requirement to
			make these values the same. Indeed, in some cases, such as slow
			tunnels where a very small or zero reorder window size is
			appropriate, the user may want a large replay detection window to log
			replayed packets. Additionally, large replay windows can be
			implemented with very little overhead compared to large reorder
			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
	pad-out the current encapsulating packet in order to deliver an inner		pad-out the current encapsulating packet in order to deliver an inner
	packet un-fragmented in the following outer packet. The benefit		packet un-fragmented in the following outer packet. The benefit
End of changes. 5 change blocks.
	6 lines changed or deleted		12 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/