< draft-ietf-ipsecme-iptfs-03.txt		draft-ietf-ipsecme-iptfs-04.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 November 15, 2020		Intended status: Standards Track December 18, 2020
	Expires: May 19, 2021		Expires: June 21, 2021
	IP Traffic Flow Security		IP Traffic Flow Security Using Aggregation and Fragmentation
	draft-ietf-ipsecme-iptfs-03		draft-ietf-ipsecme-iptfs-04
	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 May 19, 2021.		This Internet-Draft will expire on June 21, 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 13 ¶		skipping to change at page 2, line 13 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	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. IPTFS_PROTOCOL Payload Content . . . . . . . . . . . . . 4		2.2. Payload Content . . . . . . . . . . . . . . . . . . . . . 5
	2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . . . . 6		2.2.4. Empty Payload . . . . . . . . . . . . . . . . . . . . 7
	2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 7		2.2.5. IP Header Value Mapping . . . . . . . . . . . . . . . 7
	2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7		2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7
	2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 7		2.4. Modes of Operation . . . . . . . . . . . . . . . . . . . 7
	2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 7		2.4.1. Non-Congestion Controlled Mode . . . . . . . . . . . 8
	2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 8		2.4.2. Congestion Controlled Mode . . . . . . . . . . . . . 8
	3. Congestion Information . . . . . . . . . . . . . . . . . . . 9		3. Congestion Information . . . . . . . . . . . . . . . . . . . 9
	3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10		3.1. ECN Support . . . . . . . . . . . . . . . . . . . . . . . 10
	4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 11		4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 11		4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 11
	4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11		4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11
	5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. USE_TFS Notification Message . . . . . . . . . . . . . . 11		5.1. USE_AGGFRAG Notification Message . . . . . . . . . . . . 11
	6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12		6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12
	6.1. IP-TFS Payload . . . . . . . . . . . . . . . . . . . . . 12		6.1. AGGFRAG_PAYLOAD Payload . . . . . . . . . . . . . . . . . 12
	6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12		6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format 13
	6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13		6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format . . 13
	6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 15		6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 15
	6.1.4. IKEv2 USE_IPTFS Notification Message . . . . . . . . 17		6.1.4. IKEv2 USE_AGGFRAG Notification Message . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	7.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 18		7.1. AGGFRAG_PAYLOAD Sub-Type Registry . . . . . . . . . . . . 18
	7.2. IPTFS_PROTOCOL Sub-Type Registry . . . . . . . . . . . . 18		7.2. USE_AGGFRAG Notify Message Status Type . . . . . . . . . 18
	7.3. USE_IPTFS Notify Message Status Type . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . 19		9.1. Normative References . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . 19		9.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 21		Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 21
	Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 22		Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 21
	Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 22		Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 22
	C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 22		C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 22
	C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 22		C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 22
	C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 23		C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 23
	C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 24		C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 24
	C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 25		C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 24
	C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 25		C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 25
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27
	Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 27		Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 27
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
	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],
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	This document assumes familiarity with IP security concepts described		This document assumes familiarity with IP security concepts described
	in [RFC4301].		in [RFC4301].
	2. The IP-TFS Tunnel		2. The IP-TFS Tunnel
	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
	of 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 can be
	determined through the use of Path MTU discovery [RFC1191] and		determined through the use of Path MTU discovery [RFC1191] and
	[RFC8201].		[RFC8201].
	Given the encapsulating packet size and the requested tunnel		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 payload		packet send rate is the requested bandwidth divided by the size of
	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.
	2.1. Tunnel Content		2.1. Tunnel Content
	As previously mentioned, one issue with the TFC padding solution in		As previously mentioned, one issue with the TFC padding solution in
	[RFC4303] is the large amount of wasted bandwidth as only one IP		[RFC4303] is the large amount of wasted bandwidth as only one IP
	packet can be sent per encapsulating packet. In order to maximize		packet can be sent per encapsulating packet. In order to maximize
	bandwidth IP-TFS breaks this one-to-one association.		bandwidth IP-TFS breaks this one-to-one association.
	IP-TFS aggregates as well as fragments the inner IP traffic flow into		IP-TFS aggregates as well as fragments the inner IP traffic flow into
	fixed-sized encapsulating IPsec tunnel packets. Padding is only		fixed-sized encapsulating IPsec tunnel packets. Padding is only
	added to the the tunnel packets if there is no data available to be		added to the the tunnel packets if there is no data available to be
	sent at the time of tunnel packet transmission, or if fragmentation		sent at the time of tunnel packet transmission, or if fragmentation
	has been disabled by the receiver.		has been disabled by the receiver.
	This is accomplished using a new Encapsulating Security Payload (ESP,		This is accomplished using a new Encapsulating Security Payload (ESP,
	[RFC4303]) type which is identified by the number IPTFS_PROTOCOL		[RFC4303]) type which is identified by the number AGGFRAG_PAYLOAD
	(Section 6.1).		(Section 6.1).
	2.2. IPTFS_PROTOCOL Payload Content		Other non-IP-TFS uses of this aggregation and fragmentation
			encapsulation have been identified, such as increased performance
			through packet aggregation, as well as handling MTU issues using
			fragmentation. These uses are not defined here, but are also not
			restricted by this document.
	The IPTFS_PROTOCOL payload content defined in this document is		2.2. Payload Content
			The AGGFRAG_PAYLOAD payload content defined in this document is
	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 IPTFS_PROTOCOL payload within the ESP packet. See		illustrates this payload within the ESP packet. See Section 6.1 for
	Section 6.1 for the exact formats of the IPTFS_PROTOCOL payload.		the exact formats of the AGGFRAG_PAYLOAD payload.
	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	. Outer Encapsulating Header ... .		. Outer Encapsulating Header ... .
	. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	. ESP Header... .		. ESP Header... .
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| ... : BlockOffset |		| ... : BlockOffset |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	: [Optional Congestion Info] :		: [Optional Congestion Info] :
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 38 ¶
	known location and is guaranteed to be present is enough to fetch the		known location and is guaranteed to be present is enough to fetch the
	length field from the subsequent encapsulating packet payload. Only		length field from the subsequent encapsulating packet payload. Only
	when there is no data to encapsulated is end padding required, and		when there is no data to encapsulated is end padding required, and
	then an explicit "Pad Data Block" would be used to identify the		then an explicit "Pad Data Block" would be used to identify the
	padding.		padding.
	2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads		2.2.3. Fragmentation, Sequence Numbers and All-Pad Payloads
	In order for a receiver to be able to reassemble fragmented inner-		In order for a receiver to be able to reassemble fragmented inner-
	packets, the sender MUST send the inner-packet fragments back-to-back		packets, the sender MUST send the inner-packet fragments back-to-back
	in the logical IP-TFS packet stream (i.e., using consecutive ESP		in the logical outer packet stream (i.e., using consecutive ESP
	sequence numbers). However, the sender is allowed to insert "all-		sequence numbers). However, the sender is allowed to insert "all-
	pad" IP-TFS packets (i.e., packets having payloads with a		pad" payloads (i.e., payloads with a "BlockOffset" of zero and a
	"BlockOffset" of zero and a single pad "DataBlock") in between the		single pad "DataBlock") in between the packets carrying the inner-
	IP-TFS packets carrying the inner-packet fragment payloads. This		packet fragment payloads. This possible interleaving of all-pad
	possible interleaving of all-pad packets allows the sender to always		payloads allows the sender to always be able to send a tunnel packet,
	be able to send an IP-TFS tunnel packet, regardless of the		regardless of the encapsulation computational requirements.
	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" IP-TFS tunnel packet, it increments the expected sequence		"all-pad" payload, it increments the expected sequence number that
	number that the next inner-packet fragment is expected to arrive in.		the next inner-packet fragment is expected to arrive in.
	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-IP-TFS enabled SA, IP-TFS allows for the		(described later) on a non-AGGFRAG_PAYLOAD enabled SA, IP-TFS allows
	sending of an IP-TFS payload with no data blocks (i.e., the ESP		for the sending of an AGGFRAG_PAYLOAD payload with no data blocks
	payload length is equal to the IP-TFS header length). This special		(i.e., the ESP payload length is equal to the AGGFRAG_PAYLOAD header
	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
	[RFC4301] provides some direction on when and how to map various		[RFC4301] provides some direction on when and how to map various
	values from an inner IP header to the outer encapsulating header,		values from an inner IP header to the outer encapsulating header,
	namely the Don't-Fragment (DF) bit ([RFC0791] and [RFC8200]), the		namely the Don't-Fragment (DF) bit ([RFC0791] and [RFC8200]), the
	Differentiated Services (DS) field [RFC2474] and the Explicit		Differentiated Services (DS) field [RFC2474] and the Explicit
	Congestion Notification (ECN) field [RFC3168]. Unlike [RFC4301], IP-		Congestion Notification (ECN) field [RFC3168]. Unlike [RFC4301], IP-
	TFS may and often will be encapsulating more than one IP packet per		TFS may and often will be encapsulating more than one IP packet per
	ESP packet. To deal with this, these mappings are restricted		ESP packet. To deal with this, these mappings are restricted
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 36 ¶
	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.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 IP-TFS enabled SA. In other words, an SA that has IP-TFS		of an AGGFRAG_PAYLOAD enabled SA. In other words, an SA that has
	enabled is exclusively for IP-TFS use and MUST NOT have non-IP-TFS		AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads
	payloads such as IP (IP protocol 4), TCP transport (IP protocol 6),		such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad
	or ESP pad packets (protocol 59) intermixed with non-empty IP-TFS (IP		packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD
	protocol TBD1) payloads. While it's possible to envision making the		payloads. While it's possible to envision making the algorithm work
	algorithm work in the presence of sequence number skips in the IP-TFS		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
	IPsec uses can configure and use their own SAs.		IPsec uses can configure and use their own SAs.
	2.4. Modes of Operation		2.4. Modes of Operation
	Just as with normal IPsec/ESP tunnels, IP-TFS tunnels are		Just as with normal IPsec/ESP tunnels, IP-TFS tunnels are
	unidirectional. Bidirectional IP-TFS functionality is achieved by		unidirectional. Bidirectional IP-TFS functionality is achieved by
	setting up 2 IP-TFS tunnels, one in either direction.		setting up 2 IP-TFS tunnels, one in either direction.
	An IP-TFS tunnel can operate in 2 modes, a non-congestion controlled		An IP-TFS tunnel can operate in 2 modes, a non-congestion controlled
	skipping to change at page 9, line 38 ¶		skipping to change at page 9, line 45 ¶
	circuit breakers are outside the scope of this document.		circuit breakers are outside the scope of this document.
	3. Congestion Information		3. Congestion Information
	In order to support the congestion control mode, the sender needs to		In order to support the congestion control mode, the sender needs to
	know the loss event rate and also be able to approximate the RTT		know the loss event rate and also be able to approximate the RTT
	([RFC5348]). In order to obtain these values the receiver sends		([RFC5348]). In order to obtain these values the receiver sends
	congestion control information on it's SA back to the sender. Thus,		congestion control information on it's SA back to the sender. Thus,
	in order to support congestion control the receiver must have a		in order to support congestion control the receiver must have a
	paired SA back to the sender (this is always the case when the tunnel		paired SA back to the sender (this is always the case when the tunnel
	was created using IKEv2). If the SA back to the sender is a non-IP-		was created using IKEv2). If the SA back to the sender is a non-
	TFS enabled SA then an IPTFS_PROTOCOL empty payload (i.e., header		AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload
	only) is used to convey the information.		(i.e., header only) is used to convey the information.
	In order to calculate a loss event rate compatible with [RFC5348],		In order to calculate a loss event rate compatible with [RFC5348],
	the receiver needs to have a round-trip time estimate. Thus the		the receiver needs to have a round-trip time estimate. Thus the
	sender communicates this estimate in the "RTT" header field. On		sender communicates this estimate in the "RTT" header field. On
	startup this value will be zero as no RTT estimate is yet known.		startup this value will be zero as no RTT estimate is yet known.
	In order for the sender to estimate it's "RTT" value, the sender		In order for the sender to estimate it's "RTT" value, the sender
	places a timestamp value in the "TVal" header field. On first		places a timestamp value in the "TVal" header field. On first
	receipt of this "TVal", the receiver records the new "TVal" value		receipt of this "TVal", the receiver records the new "TVal" value
	along with the time it arrived locally, subsequent receipt of the		along with the time it arrived locally, subsequent receipt of the
	skipping to change at page 10, line 19 ¶		skipping to change at page 10, line 27 ¶
	current transmission delay on the tunnel (i.e., the average time		current transmission delay on the tunnel (i.e., the average time
	between sending packets on it's half of the IP-TFS tunnel). When the		between sending packets on it's half of the IP-TFS tunnel). When the
	sender receives back it's "TVal" in the "TEcho" header field it		sender receives back it's "TVal" in the "TEcho" header field it
	calculates 2 RTT estimates. The first is the actual delay found by		calculates 2 RTT estimates. The first is the actual delay found by
	subtracting the "TEcho" value from it's current clock and then		subtracting the "TEcho" value from it's current clock and then
	subtracting "Echo Delay" as well. The second RTT estimate is found		subtracting "Echo Delay" as well. The second RTT estimate is found
	by adding the received "Transmit Delay" header value to the senders		by adding the received "Transmit Delay" header value to the senders
	own transmission delay (i.e., the average time between sending		own transmission delay (i.e., the average time between sending
	packets on it's half of the IP-TFS tunnel). The larger of these 2		packets on it's half of the IP-TFS tunnel). The larger of these 2
	RTT estimates SHOULD be used as the "RTT" value. The two estimates		RTT estimates SHOULD be used as the "RTT" value. The two estimates
	are required to handle different combinations of faster or slow		are required to handle different combinations of faster or slower
	tunnel packet paths with fast or slow fixed tunnel rates. Choosing		tunnel packet paths with faster or slower fixed tunnel rates.
	the larger of the two values guarantees that the "RTT" is never		Choosing the larger of the two values guarantees that the "RTT" is
	considered faster than the aggregate transmission delay based on the		never considered faster than the aggregate transmission delay based
	IP-TFS tunnel rate (the second estimate), as well as never being		on the IP-TFS tunnel rate (the second estimate), as well as never
	considered faster than the actual RTT along the tunnel packet path		being considered faster than the actual RTT along the tunnel packet
	(the first estimate).		path (the first estimate).
	The receiver also calculates, and communicates in the "LossEventRate"		The receiver also calculates, and communicates in the "LossEventRate"
	header field, the loss event rate for use by the sender. This is		header field, the loss event rate for use by the sender. This is
	slightly different from [RFC4342] which periodically sends all the		slightly different from [RFC4342] which periodically sends all the
	loss interval data back to the sender so that it can do the		loss interval data back to the sender so that it can do the
	calculation. See Appendix B for a suggested way to calculate the		calculation. See Appendix B for a suggested way to calculate the
	loss event rate value. Initially this value will be zero (indicating		loss event rate value. Initially this value will be zero (indicating
	no loss) until enough data has been collected by the receiver to		no loss) until enough data has been collected by the receiver to
	update it.		update it.
	3.1. ECN Support		3.1. ECN Support
	In additional to normal packet loss information IP-TFS supports use		In additional to normal packet loss information IP-TFS supports use
	of the ECN bits in the encapsulating IP header [RFC3168] for		of the ECN bits in the encapsulating IP header [RFC3168] for
	identifying congestion. If ECN use is enabled and a packet arrives		identifying congestion. If ECN use is enabled and a packet arrives
	at the egress endpoint with the Congestion Experienced (CE) value		at the egress endpoint with the Congestion Experienced (CE) value
	set, then the receiver considers that packet as being dropped,		set, then the receiver considers that packet as being dropped,
	although it does not drop it. The receiver MUST set the E bit in any		although it does not drop it. The receiver MUST set the E bit in any
	IPTFS_PROTOCOL payload header containing a "LossEventRate" value		AGGFRAG_PAYLOAD payload header containing a "LossEventRate" value
	derived from a CE value being considered.		derived from a CE value being considered.
	As noted in [RFC3168] the ECN bits are not protected by IPsec and		As noted in [RFC3168] the ECN bits are not protected by IPsec and
	thus may constitute a covert channel. For this reason ECN use SHOULD		thus may constitute a covert channel. For this reason ECN use SHOULD
	NOT be enabled by default.		NOT be enabled by default.
	4. Configuration		4. Configuration
	IP-TFS is meant to be deployable with a minimal amount of		IP-TFS is meant to be deployable with a minimal amount of
	configuration. All IP-TFS specific configuration should be able to		configuration. All IP-TFS specific configuration should be able to
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 42 ¶
	Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized		Path MTU discovery (see [RFC1191] and [RFC8201]). No standardized
	configuration method is required.		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_TFS Notification Message		5.1. USE_AGGFRAG Notification Message
	When using IKEv2, a new "USE_IPTFS" Notification Message is used to		As mentioned previously IP-TFS tunnels utilize ESP payloads of type
	enable operation of IP-TFS on a child SA pair. The method used is		AGGFRAG_PAYLOAD.
	similar to how USE_TRANSPORT_MODE is negotiated, as described in
	[RFC7296].
	To request IP-TFS operation on the Child SA pair, the initiator		When using IKEv2, a new "USE_AGGFRAG" Notification Message is used to
	includes the USE_IPTFS notification in an SA payload requesting a new		enable use of the AGGFRAG_PAYLOAD payload on a child SA pair. The
	Child SA (either during the initial IKE_AUTH or during non-rekeying		method used is similar to how USE_TRANSPORT_MODE is negotiated, as
	CREATE_CHILD_SA exchanges). If the request is accepted then response		described in [RFC7296].
	MUST also include a notification of type USE_IPTFS. If the responder
	declines the request the child SA will be established without IP-TFS
	enabled. If this is unacceptable to the initiator, the initiator
	MUST delete the child SA.
	The USE_IPTFS notification MUST NOT be sent, and MUST be ignored,		To request using the AGGFRAG_PAYLOAD payload on the Child SA pair,
			the initiator includes the USE_AGGFRAG notification in an SA payload
			requesting a new Child SA (either during the initial IKE_AUTH or
			during non-rekeying CREATE_CHILD_SA exchanges). If the request is
			accepted then response MUST also include a notification of type
			USE_AGGFRAG. If the responder declines the request the child SA will
			be established without AGGFRAG_PAYLOAD payload use enabled. If this
			is unacceptable to the initiator, the initiator MUST delete the child
			SA.
			The USE_AGGFRAG notification MUST NOT be sent, and MUST be ignored,
	during a CREATE_CHILD_SA rekeying exchange as it is not allowed to		during a CREATE_CHILD_SA rekeying exchange as it is not allowed to
	change IP-TFS operation during rekeying.		change use of the AGGFRAG_PAYLOAD payload type during rekeying.
	The USE_IPTFS notification contains a 1 octet payload of flags that		The USE_AGGFRAG notification contains a 1 octet payload of flags that
	specify any requirements from the sender of the message. If any		specify any requirements from the sender of the message. If any
	requirement flags are not understood or cannot be supported by the		requirement flags are not understood or cannot be supported by the
	receiver then the receiver should not enable IP-TFS mode (either by		receiver then the receiver should not enable use of AGGFRAG_PAYLOAD
	not responding with the USE_IPTFS notification, or in the case of the		payload type (either by not responding with the USE_AGGFRAG
	initiator, by deleting the child SA if the now established non-IP-TFS		notification, or in the case of the initiator, by deleting the child
	operation is unacceptable).		SA if the now established non-AGGFRAG_PAYLOAD using SA is
			unacceptable).
	The notification type and payload flag values are defined in		The notification type and payload flag values are defined in
	Section 6.1.4.		Section 6.1.4.
	6. Packet and Data Formats		6. Packet and Data Formats
	6.1. IP-TFS Payload		6.1. AGGFRAG_PAYLOAD Payload
	ESP Payload Type: 0x5		ESP Payload Type: 0x5
	An IP-TFS payload is identified by the ESP payload type		An IP-TFS payload is identified by the ESP payload type
	IPTFS_PROTOCOL which has the value 0x5. The first octet of this		AGGFRAG_PAYLOAD which has the value 0x5. The first octet of this
	payload indicates the format of the remaining payload data.		payload indicates the format of the remaining payload data.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-
	| Sub-type | ...		| Sub-type | ...
	+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-
	Sub-type:		Sub-type:
	An 8 bit value indicating the payload format.		An 8 bit value indicating the payload format.
	This specification defines 2 payload sub-types. These payload		This specification defines 2 payload sub-types. These payload
	formats are defined in the following sections.		formats are defined in the following sections.
	6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format		6.1.1. Non-Congestion Control AGGFRAG_PAYLOAD Payload Format
	The non-congestion control IPTFS_PROTOCOL payload is comprised of a 4		The non-congestion control AGGFRAG_PAYLOAD payload is comprised of a
	octet header followed by a variable amount of "DataBlocks" data as		4 octet header followed by a variable amount of "DataBlocks" data as
	shown below.		shown below.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sub-Type (0) | Reserved | BlockOffset |		| Sub-Type (0) | Reserved | BlockOffset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DataBlocks ...		| DataBlocks ...
	+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-
	skipping to change at page 13, line 35 ¶		skipping to change at page 13, line 41 ¶
	block being re-assembled. If the "BlockOffset" extends into		block being re-assembled. If the "BlockOffset" extends into
	subsequent packets it continues to only count subsequent		subsequent packets it continues to only count subsequent
	"DataBlocks" data (i.e., it does not count subsequent packets		"DataBlocks" data (i.e., it does not count subsequent packets
	non-"DataBlocks" octets).		non-"DataBlocks" octets).
	DataBlocks:		DataBlocks:
	Variable number of octets that begins with the start of a data		Variable number of octets that begins with the start of a data
	block, or the continuation of a previous data block, followed by		block, or the continuation of a previous data block, followed by
	zero or more additional data blocks.		zero or more additional data blocks.
	6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format		6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format
	The congestion control IPTFS_PROTOCOL payload is comprised of a 24		The congestion control AGGFRAG_PAYLOAD payload is comprised of a 24
	octet header followed by a variable amount of "DataBlocks" data as		octet header followed by a variable amount of "DataBlocks" data as
	shown below.		shown below.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sub-type (1) | Reserved |E| BlockOffset |		| Sub-type (1) | Reserved |E| BlockOffset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LossEventRate |		| LossEventRate |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 14, line 48 ¶		skipping to change at page 14, line 48 ¶
	LossEventRate:		LossEventRate:
	A 32 bit value specifying the inverse of the current loss event		A 32 bit value specifying the inverse of the current loss event
	rate as calculated by the receiver. A value of zero indicates no		rate as calculated by the receiver. A value of zero indicates no
	loss. Otherwise the loss event rate is "1/LossEventRate".		loss. Otherwise the loss event rate is "1/LossEventRate".
	RTT:		RTT:
	A 22 bit value specifying the sender's current round-trip time		A 22 bit value specifying the sender's current round-trip time
	estimate in microseconds. The value MAY be zero prior to the		estimate in microseconds. The value MAY be zero prior to the
	sender having calculated a round-trip time estimate. The value		sender having calculated a round-trip time estimate. The value
	SHOULD be set to zero on non-IP-TFS enabled SAs. If the value is		SHOULD be set to zero on non-AGGFRAG_PAYLOAD enabled SAs. If the
	equal to or larger than "0x3FFFFF" it MUST be set to "0x3FFFFF".		value is equal to or larger than "0x3FFFFF" it MUST be set to
			"0x3FFFFF".
	Echo Delay:		Echo Delay:
	A 21 bit value specifying the delay in microseconds incurred		A 21 bit value specifying the delay in microseconds incurred
	between the receiver first receiving the "TVal" value which it is		between the receiver first receiving the "TVal" value which it is
	sending back in "TEcho". If the value is equal to or larger than		sending back in "TEcho". If the value is equal to or larger than
	"0x1FFFFF" it MUST be set to "0x1FFFFF".		"0x1FFFFF" it MUST be set to "0x1FFFFF".
	Transmit Delay:		Transmit Delay:
	A 21 bit value specifying the transmission delay in microseconds.		A 21 bit value specifying the transmission delay in microseconds.
	This is the fixed (or average) delay on the receiver between it		This is the fixed (or average) delay on the receiver between it
	sending packets on the IPTFS tunnel. If the value is equal to or		sending packets on the IPTFS tunnel. If the value is equal to or
	larger than "0x1FFFFF" it MUST be set to "0x1FFFFF".		larger than "0x1FFFFF" it MUST be set to "0x1FFFFF".
	TVal:		TVal:
	An opaque 32 bit value that will be echoed back by the receiver in		An opaque 32 bit value that will be echoed back by the receiver in
	later packets in the "TEcho" field, along with a "Delay" value of		later packets in the "TEcho" field, along with an "Echo Delay"
	how long that echo took.		value of how long that echo took.
	TEcho:		TEcho:
	The opaque 32 bit value from a received packet's "TVal" field.		The opaque 32 bit value from a received packet's "TVal" field.
	The received "TVal" is placed in "TEcho" along with a "Delay"		The received "TVal" is placed in "TEcho" along with an "Echo
	value indicating how long it has been since receiving the "TVal"		Delay" value indicating how long it has been since receiving the
	value.		"TVal" value.
	DataBlocks:		DataBlocks:
	Variable number of octets that begins with the start of a data		Variable number of octets that begins with the start of a data
	block, or the continuation of a previous data block, followed by		block, or the continuation of a previous data block, followed by
	zero or more additional data blocks. For the special case of		zero or more additional data blocks. For the special case of
	sending congestion control information on an non-IP-TFS enabled SA		sending congestion control information on an non-IP-TFS enabled SA
	this value MUST be empty (i.e., be zero octets long).		this value MUST be empty (i.e., be zero octets long).
	6.1.3. Data Blocks		6.1.3. Data Blocks
	skipping to change at page 17, line 16 ¶		skipping to change at page 17, line 16 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x0 | Padding ...		| 0x0 | Padding ...
	+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-
	Type:		Type:
	A 4 bit value of 0x0 indicating a padding data block.		A 4 bit value of 0x0 indicating a padding data block.
	Padding:		Padding:
	extends to end of the encapsulating packet.		extends to end of the encapsulating packet.
	6.1.4. IKEv2 USE_IPTFS Notification Message		6.1.4. IKEv2 USE_AGGFRAG Notification Message
	As discussed in Section 5.1 a notification message USE_IPTFS is used		As discussed in Section 5.1 a notification message USE_AGGFRAG is
	to negotiate IP-TFS operation in IKEv2.		used to negotiate use of the ESP AGGFRAG_PAYLOAD payload type.
	The USE_IPTFS Notification Message State Type is (TBD2).		The USE_AGGFRAG Notification Message State Type is (TBD2).
	The notification payload contains 1 octet of requirement flags.		The notification payload contains 1 octet of requirement flags.
	There are currently 2 requirement flags defined. This may be revised		There are currently 2 requirement flags defined. This may be revised
	by later specifications.		by later specifications.
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|0|0|0|0|0|0|C|D|		|0|0|0|0|0|0|C|D|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	0:		0:
	skipping to change at page 17, line 46 ¶		skipping to change at page 17, line 46 ¶
	Congestion Control bit. If set, then the sender is requiring that		Congestion Control bit. If set, then the sender is requiring that
	congestion control information MUST be returned to it periodically		congestion control information MUST be returned to it periodically
	as defined in Section 3.		as defined in Section 3.
	D:		D:
	Don't Fragment bit, if set indicates the sender of the notify		Don't Fragment bit, if set indicates the sender of the notify
	message does not support receiving packet fragments (i.e., inner		message does not support receiving packet fragments (i.e., inner
	packets MUST be sent using a single "Data Block"). This value		packets MUST be sent using a single "Data Block"). This value
	only applies to what the sender is capable of receiving; the		only applies to what the sender is capable of receiving; the
	sender MAY still send packet fragments unless similarly restricted		sender MAY still send packet fragments unless similarly restricted
	by the receiver in it's USE_IPTFS notification.		by the receiver in it's USE_AGGFRAG notification.
	7. IANA Considerations		7. IANA Considerations
	7.1. IPTFS_PROTOCOL Type		7.1. AGGFRAG_PAYLOAD Sub-Type Registry
	This document requests a protocol number IPTFS_PROTOCOL be allocated
	by IANA from "Assigned Internet Protocol Numbers" registry for
	identifying the IP-TFS payload.
	Type:
	TBD1
	Description:
	An IP-TFS payload.
	Reference:
	This document
	7.2. IPTFS_PROTOCOL Sub-Type Registry
	This document requests IANA create a registry called "IPTFS_PROTOCOL		This document requests IANA create a registry called "AGGFRAG_PAYLOAD
	Sub-Type Registry" under "IPTFS_PROTOCOL Parameters" IANA registries.		Sub-Type Registry" under a new category named "ESP AGGFRAG_PAYLOAD
	The registration policy for this registry is "Standards Action"		Parameters". The registration policy for this registry is "Standards
	([RFC8126] and [RFC7120]).		Action" ([RFC8126] and [RFC7120]).
	Name:		Name:
	IPTFS_PROTOCOL Sub-Type Registry		AGGFRAG_PAYLOAD Sub-Type Registry
	Description:		Description:
	IPTFS_PROTOCOL Payload Formats.		AGGFRAG_PAYLOAD Payload Formats.
	Reference:		Reference:
	This document		This document
	This initial content for this registry is as follows:		This initial content for this registry is as follows:
	Sub-Type Name Reference		Sub-Type Name Reference
	--------------------------------------------------------		--------------------------------------------------------
	0 Non-Congestion Control Format This document		0 Non-Congestion Control Format This document
	1 Congestion Control Format This document		1 Congestion Control Format This document
	3-255 Reserved		3-255 Reserved
	7.3. USE_IPTFS Notify Message Status Type		7.2. USE_AGGFRAG Notify Message Status Type
	This document requests a status type USE_IPTFS be allocated from the		This document requests a status type USE_AGGFRAG be allocated from
	"IKEv2 Notify Message Types - Status Types" registry.		the "IKEv2 Notify Message Types - Status Types" registry.
	Value:		Value:
	TBD2		TBD2
	Name:		Name:
	USE_IPTFS		USE_AGGFRAG
	Reference:		Reference:
	This document		This document
	8. Security Considerations		8. Security Considerations
	This document describes a mechanism to add Traffic Flow		This document describes a mechanism to add Traffic Flow
	Confidentiality to IP traffic. Use of this mechanism is expected to		Confidentiality to IP traffic. Use of this mechanism is expected to
	increase the security of the traffic being transported. Other than		increase the security of the traffic being transported. Other than
	the additional security afforded by using this mechanism, IP-TFS		the additional security afforded by using this mechanism, IP-TFS
	skipping to change at page 22, line 33 ¶		skipping to change at page 22, line 21 ¶
	which is provided by the receiver).		which is provided by the receiver).
	In addition the algorithm in [RFC5348] also uses an "X_recv" value		In addition the algorithm in [RFC5348] also uses an "X_recv" value
	(the receiver's receive rate). For IP-TFS one MAY set this value		(the receiver's receive rate). For IP-TFS one MAY set this value
	according to the sender's current tunnel send-rate ("X").		according to the sender's current tunnel send-rate ("X").
	The IP-TFS receiver, having the RTT estimate from the sender can use		The IP-TFS receiver, having the RTT estimate from the sender can use
	the same method as described in [RFC5348] and [RFC4342] to collect		the same method as described in [RFC5348] and [RFC4342] to collect
	the loss intervals and calculate the loss event rate value using the		the loss intervals and calculate the loss event rate value using the
	weighted average as indicated. The receiver communicates the inverse		weighted average as indicated. The receiver communicates the inverse
	of this value back to the sender in the IPTFS_PROTOCOL payload header		of this value back to the sender in the AGGFRAG_PAYLOAD payload
	field "LossEventRate".		header field "LossEventRate".
	The IP-TFS sender now has both the "R" and "p" values and can		The IP-TFS sender now has both the "R" and "p" values and can
	calculate the correct sending rate. If following [RFC5348] the		calculate the correct sending rate. If following [RFC5348] the
	sender SHOULD also use the slow start mechanism described therein		sender SHOULD also use the slow start mechanism described therein
	when the IP-TFS SA is first established.		when the IP-TFS SA is first established.
	Appendix C. Comparisons of IP-TFS		Appendix C. Comparisons of IP-TFS
	C.1. Comparing Overhead		C.1. Comparing Overhead
	skipping to change at page 27, line 27 ¶		skipping to change at page 27, line 8 ¶
	Figure 10: Added Latency		Figure 10: Added Latency
	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.		this work. We would also like to thank Valery Smyslov for reviews
			and suggestions for 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. 56 change blocks.
	127 lines changed or deleted		123 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/