< draft-ietf-ipsecme-iptfs-00.txt		draft-ietf-ipsecme-iptfs-01.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 16, 2019		Intended status: Standards Track March 2, 2020
	Expires: June 18, 2020		Expires: September 3, 2020
	IP Traffic Flow Security		IP Traffic Flow Security
	draft-ietf-ipsecme-iptfs-00		draft-ietf-ipsecme-iptfs-01
	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.		control as well.
	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 18, 2020.		This Internet-Draft will expire on September 3, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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. IPTFS_PROTOCOL Payload Content . . . . . . . . . . . . . 4
	2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 5		2.2.1. Data Blocks . . . . . . . . . . . . . . . . . . . . . 5
	2.2.2. No Implicit Padding Required . . . . . . . . . . . . 6		2.2.2. No Implicit End Padding Required . . . . . . . . . . 6
	2.2.3. Empty Payload . . . . . . . . . . . . . . . . . . . . 6		2.2.3. Empty Payload . . . . . . . . . . . . . . . . . . . . 6
	2.2.4. IP Header Value Mapping . . . . . . . . . . . . . . . 6		2.2.4. IP Header Value Mapping . . . . . . . . . . . . . . . 6
	2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7		2.3. Exclusive SA Use . . . . . . . . . . . . . . . . . . . . 7
	2.4. Initiating IP-TFS Operation On The SA. . . . . . . . . . 7		2.4. Initiating IP-TFS Operation On The SA. . . . . . . . . . 7
	2.5. Modes of Operation . . . . . . . . . . . . . . . . . . . 7		2.5. Modes of Operation . . . . . . . . . . . . . . . . . . . 7
	2.5.1. Non-Congestion Controlled Mode . . . . . . . . . . . 7		2.5.1. Non-Congestion Controlled Mode . . . . . . . . . . . 7
	2.5.2. Congestion Controlled Mode . . . . . . . . . . . . . 8		2.5.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 . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 10		4.1. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 10		4.2. Fixed Packet Size . . . . . . . . . . . . . . . . . . . . 10
	4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11		4.3. Congestion Control . . . . . . . . . . . . . . . . . . . 11
	5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. TFS Type Transform Type . . . . . . . . . . . . . . . . . 11		5.1. USE_TFS Notification Message . . . . . . . . . . . . . . 11
	5.2. IPTFS_REQUIREMENTS Status Notification . . . . . . . . . 11		6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 11
	6. Packet and Data Formats . . . . . . . . . . . . . . . . . . . 12		6.1. IP-TFS Payload . . . . . . . . . . . . . . . . . . . . . 11
	6.1. ESP IP-TFS Payload . . . . . . . . . . . . . . . . . . . 12
	6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12		6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format 12
	6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13		6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format . . 13
	6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 14		6.1.3. Data Blocks . . . . . . . . . . . . . . . . . . . . . 14
			6.1.4. IKEv2 USE_IPTFS Notification Message . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 16		7.1. IPTFS_PROTOCOL Type . . . . . . . . . . . . . . . . . . . 16
	7.2. IKEv2 Transform Type TFS Type . . . . . . . . . . . . . . 16		7.2. IPTFS_PROTOCOL Sub-Type Registry . . . . . . . . . . . . 16
	7.3. TFS Type Transform IDs Registry . . . . . . . . . . . . . 17		7.3. USE_IPTFS Notify Message Status Type . . . . . . . . . . 17
	7.4. IPTFS_REQUIREMENTS Notify Message Status Type . . . . . . 17
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 17		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9.1. Normative References . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . 18
	9.2. Informative References . . . . . . . . . . . . . . . . . 18		9.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 19		Appendix A. Example Of An Encapsulated IP Packet Flow . . . . . 20
	Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 20		Appendix B. A Send and Loss Event Rate Calculation . . . . . . . 20
	Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 21		Appendix C. Comparisons of IP-TFS . . . . . . . . . . . . . . . 21
	C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 21		C.1. Comparing Overhead . . . . . . . . . . . . . . . . . . . 21
	C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 21		C.1.1. IP-TFS Overhead . . . . . . . . . . . . . . . . . . . 21
	C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 21		C.1.2. ESP with Padding Overhead . . . . . . . . . . . . . . 21
	C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 22		C.2. Overhead Comparison . . . . . . . . . . . . . . . . . . . 22
	C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 23		C.3. Comparing Available Bandwidth . . . . . . . . . . . . . . 23
	C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 23		C.3.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . 23
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 25		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 25
	Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 25		Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 25
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting		Traffic Analysis ([RFC4301], [AppCrypt]) is the act of extracting
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 25 ¶
	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
	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 payload
	size of the encapsulating packet.		size of the encapsulating packet.
	The egress of the IP-TFS tunnel MUST allow for, and expect the		The egress of the IP-TFS tunnel MUST allow for and expect the ingress
	ingress (sending) side of the IP-TFS tunnel to vary the size and rate		(sending) side of the IP-TFS tunnel to vary the size and rate of sent
	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.
	With IP-TFS we aggregate as well as fragment the inner IP traffic		With IP-TFS we aggregate as well as fragment the inner IP traffic
	flow into fixed-sized encapsulating IPsec tunnel packets. We only		flow into fixed-sized encapsulating IPsec tunnel packets. We only
	pad the tunnel packets if there is no data available to be sent at		pad the tunnel packets if there is no data available to be sent at
	the time of tunnel packet transmission, or if fragmentation has been		the time of tunnel packet transmission, or if fragmentation has been
	disabled by the receiver.		disabled by the receiver.
	In order to do this we use a new Encapsulating Security Payload (ESP,		In order to do this we use a new Encapsulating Security Payload (ESP,
	[RFC4303]) payload type which is the new IP protocol number		[RFC4303]) type which is identified by the IP protocol number
	IPTFS_PROTOCOL (TBD1).		IPTFS_PROTOCOL (TBD1).
	2.2. IPTFS_PROTOCOL Payload Content		2.2. IPTFS_PROTOCOL Payload Content
	The IPTFS_PROTOCOL ESP payload is comprised a 4 or 16 octet header		The IPTFS_PROTOCOL payload content defined in this document is
	followed by either a partial, a full or multiple partial or full data		comprised of a 4 or 16 octet header followed by either a partial, a
	blocks. The following diagram illustrates the IPTFS_PROTOCOL ESP		full or multiple partial or full data blocks. The following diagram
	payload within the ESP packet. See Section 6.1 for the exact formats		illustrates this IPTFS_PROTOCOL payload within the ESP packet. See
	of the IPTFS_PROTOCOL payload.		Section 6.1 for the exact formats of the IPTFS_PROTOCOL 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 9 ¶		skipping to change at page 6, line 9 ¶
	Figure 2: Layout of IP-TFS data block		Figure 2: Layout of IP-TFS data block
	A data block is defined by a 4-bit type code followed by the data		A data block is defined by a 4-bit type code followed by the data
	block data. The type values have been carefully chosen to coincide		block data. The type values have been carefully chosen to coincide
	with the IPv4/IPv6 version field values so that no per-data block		with the IPv4/IPv6 version field values so that no per-data block
	type overhead is required to encapsulate an IP packet. Likewise, the		type overhead is required to encapsulate an IP packet. Likewise, the
	length of the data block is extracted from the encapsulated IPv4 or		length of the data block is extracted from the encapsulated IPv4 or
	IPv6 packet's length field.		IPv6 packet's length field.
	2.2.2. No Implicit Padding Required		2.2.2. No Implicit End Padding Required
	It's worth noting that there is never a need for an implicit pad at		It's worth noting that since a data block type is identified by its
	the end of an encapsulating packet. Even when the start of a data		first octet there is never a need for an implicit pad at the end of
	block occurs near the end of a encapsulating packet such that there		an encapsulating packet. Even when the start of a data block occurs
	is no room for the length field of the encapsulated header to be		near the end of a encapsulating packet such that there is no room for
	included in the current encapsulating packet, the fact that the		the length field of the encapsulated header to be included in the
	length comes at a known location and is guaranteed to be present is		current encapsulating packet, the fact that the length comes at a
	enough to fetch the length field from the subsequent encapsulating		known location and is guaranteed to be present is enough to fetch the
	packet payload. Only when there is no data to encapsulate is padding		length field from the subsequent encapsulating packet payload. Only
	required, and then an explicit "Pad Data Block" would be used to		when there is no data to encapsulated is end padding required, and
	identify the padding.		then an explicit "Pad Data Block" would be used to identify the
			padding.
	2.2.3. Empty Payload		2.2.3. 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-IP-TFS enabled SA, IP-TFS allows for the
	sending of an IP-TFS payload with no data blocks (i.e., the ESP		sending of an IP-TFS payload with no data blocks (i.e., the ESP
	payload length is equal to the IP-TFS header length). This special		payload length is equal to the IP-TFS header length). This special
	payload is called an empty payload.		payload is called an empty payload.
	2.2.4. IP Header Value Mapping		2.2.4. IP Header Value Mapping
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 12 ¶
	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. TFS Type Transform Type		5.1. USE_TFS Notification Message
	When IP-TFS is used with IKEv2 a new "TFS Type" Transform Type (TBD2)		When using IKEv2, a new "USE_IPTFS" Notification Message is used to
	is used to negotiate (as defined in [RFC7296]) the possible operation		enable operation of IP-TFS on a child SA pair. The method used is
	of IP-TFS on a child SA pair. This document defines 3 "TFS Type"		similar to how USE_TRANSPORT_MODE is negotiated, as described in
	Transform IDs for the new "TFS Type" Transform Type: None (0),		[RFC7296].
	TFS_IPTFS_CC (1) for congestion-controlled IP-TFS mode or
	TFS_IPTFS_NOCC (2) for non-congestion controlled IP-TFS mode. The
	selection of a proposal with a "TFS Type" Transform ID TFS_IPTFS_CC
	or TFS_IPTFS_NOCC does not mandate the use of IP-TFS, rather it
	indicates a willingness or intent to use IP-TFS on the SA pair. In
	addition, a new Notify Message Status Type IPTFS_REQUIREMENTS (TBD3)
	MAY be used by the initiator as well as the responder to further
	refine any operational requirements.
	Additional "TFS Type" Transform IDs may be defined in the future, and		To request IP-TFS operation on the Child SA pair, the initiator
	so readers are referred to [IKEV2IANA] for the most up to date list.		includes the USE_IPTFS 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_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.
	5.2. IPTFS_REQUIREMENTS Status Notification		The USE_IPTFS notification MUST NOT be sent, and MUST be ignored,
			during a CREATE_CHILD_SA rekeying exchange as it is not allowed to
			change IP-TFS operation during rekeying.
	As mentioned in the previous section, a new Notify Message Status		The USE_IPTFS notification contains a 1 octet payload of flags that
	Type IPTFS_REQUIREMENTS (TBD3) MAY be sent by the initiator and/or		specify any requirements from the sender of the message. If any
	the responder to further refine what will be supported. This		requirement flags are not understood or cannot be supported by the
	notification is sent during IKE_AUTH and new CREATE_CHILD_SA		receiver then the receiver should not enable IP-TFS mode (either by
	exchanges; however, it MUST NOT be sent, and MUST be ignored, during		not responding with the USE_IPTFS notification, or in the case of the
	a CREATE_CHILD_SA rekeying exchange as the requirements are not		initiator, by deleting the child SA if the now established non-IP-TFS
	allowed to change during rekeying.		operation is unacceptable).
	The IPTFS_REQUIREMENTS notification contains a 1 octet payload of		The notification type and payload flag values are defined in
	flags that specify any extra requirements from the sender of the		Section 6.1.4.
	message. The flag values (currently a single flag) are defined
	below. If the IPTFS_REQUIREMENTS notification is not sent then it
	implies that all the flag bits are clear.
	+-+-+-+-+-+-+-+-+		6. Packet and Data Formats
	|0|0|0|0|0|0|0|D|
	+-+-+-+-+-+-+-+-+
	0:		6.1. IP-TFS Payload
	MUST be zero on send and MUST be ignored on receive.
	D:		An IP-TFS payload is identified by the IP protocol number
	Don't Fragment bit, if set indicates the sender of the notify		IPTFS_PROTOCOL (TBD1). The first octet of this payload indicates the
	message does not support receiving packet fragments (i.e., inner		format of the remaining payload data.
	packets MUST be sent using a single "Data Block"). This value
	only applies to what the sender is capable of receiving; the
	sender MAY still send packet fragments unless similarly restricted
	by the receiver in it's IPTFS_REQUIREMENTS notification.
	6. Packet and Data Formats		0 1 2 3 4 5 6 7
			+-+-+-+-+-+-+-+-+-+-+-
			| Sub-type | ...
			+-+-+-+-+-+-+-+-+-+-+-
	6.1. ESP IP-TFS Payload		Sub-type:
			An 8 bit value indicating the payload format.
	An ESP IP-TFS payload is identified by the IP protocol number		This specification defines 2 payload sub-types. These payload
	IPTFS_PROTOCOL (TBD1). This payload begins with a fixed 4 or 16		formats are defined in the following sections.
	octet header followed by a variable amount of "DataBlocks" data. The
	exact payload format and fields are defined in the following
	sections.
	6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format		6.1.1. Non-Congestion Control IPTFS_PROTOCOL Payload Format
	The non-congestion control IPTFS_PROTOCOL payload is comprised of a 4		The non-congestion control IPTFS_PROTOCOL payload is comprised of a 4
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|V|C| Reserved | BlockOffset |		| Sub-Type (0) | Reserved | BlockOffset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DataBlocks ...		| DataBlocks ...
	+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-
	V:		Sub-type:
	A 1 bit version field that MUST be set to zero. If received as		An octet indicating the payload format. For this non-congestion
	one the packet MUST be dropped.		control format, the value is 0.
	C:
	A 1 bit value that MUST be set to 0 to indicate no congestion
	control information is present.
	Reserved:		Reserved:
	A 14 bit field set to 0 and ignored on receipt.		An octet set to 0 on generation, and ignored on receipt.
	BlockOffset:		BlockOffset:
	A 16 bit unsigned integer counting the number of octets of		A 16 bit unsigned integer counting the number of octets of
	"DataBlocks" data before the start of a new data block.		"DataBlocks" data before the start of a new data block.
	"BlockOffset" can count past the end of the "DataBlocks" data in		"BlockOffset" can count past the end of the "DataBlocks" data in
	which case all the "DataBlocks" data belongs to the previous data		which case all the "DataBlocks" data belongs to the previous data
	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).
	skipping to change at page 13, line 23 ¶		skipping to change at page 13, line 14 ¶
	6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format		6.1.2. Congestion Control IPTFS_PROTOCOL Payload Format
	The congestion control IPTFS_PROTOCOL payload is comprised of a 16		The congestion control IPTFS_PROTOCOL payload is comprised of a 16
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|V|C|E| Reserved | BlockOffset |		| Sub-type (1) | Reserved |E| BlockOffset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RTT | Delay |		| RTT | Delay |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LossEventRate |		| LossEventRate |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LastSeqNum |		| LastSeqNum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| DataBlocks ...		| DataBlocks ...
	+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-
	V:		Sub-type:
	A 1 bit version field that MUST be set to zero. If received as		An octet indicating the payload format. For this congestion
	one the packet MUST be dropped.		control format, the value is 1.
	C:		Reserved:
	A 1 bit value that MUST be set to 1 which indicates the presence		A 7 bit field set to 0 on generation, and ignored on receipt.
	of the congestion information header fields "RTT", "Delay",
	"LossEventRate" and "LastSeqNum".
	E:		E:
	A 1 bit value if set indicates that Congestion Experienced (CE)		A 1 bit value if set indicates that Congestion Experienced (CE)
	ECN bits were received and used in deriving the reported		ECN bits were received and used in deriving the reported
	"LossEventRate".		"LossEventRate".
	Reserved:
	A 13 bit field set to 0 and ignored on receipt.
	BlockOffset:		BlockOffset:
	The same value as the non-congestion controlled payload format		The same value as the non-congestion controlled payload format
	value.		value.
	RTT:		RTT:
	A 16 bit value specifying the sender's current round-trip time		A 16 bit value specifying the sender's current round-trip time
	estimate in milliseconds. The value MAY be zero prior to the		estimate in milliseconds. 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.		SHOULD be set to zero on non-IP-TFS enabled SAs.
	Delay:		Delay:
	skipping to change at page 15, line 24 ¶		skipping to change at page 15, line 6 ¶
	These values are the actual values within the encapsulated IPv4		These values are the actual values within the encapsulated IPv4
	header. In other words, the start of this data block is the start of		header. In other words, the start of this data block is the start of
	the encapsulated IP packet.		the encapsulated IP packet.
	Type:		Type:
	A 4 bit value of 0x4 indicating IPv4 (i.e., first nibble of the		A 4 bit value of 0x4 indicating IPv4 (i.e., first nibble of the
	IPv4 packet).		IPv4 packet).
	TotalLength:		TotalLength:
	The 16 bit unsigned integer length field of the IPv4 inner packet.		The 16 bit unsigned integer "Total Length" field of the IPv4 inner
			packet.
	6.1.3.2. IPv6 Data Block		6.1.3.2. IPv6 Data Block
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x6 | TrafficClass | FlowLabel |		| 0x6 | TrafficClass | FlowLabel |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TotalLength | Rest of the inner packet ...		| PayloadLength | Rest of the inner packet ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	These values are the actual values within the encapsulated IPv6		These values are the actual values within the encapsulated IPv6
	header. In other words, the start of this data block is the start of		header. In other words, the start of this data block is the start of
	the encapsulated IP packet.		the encapsulated IP packet.
	Type:		Type:
	A 4 bit value of 0x6 indicating IPv6 (i.e., first nibble of the		A 4 bit value of 0x6 indicating IPv6 (i.e., first nibble of the
	IPv6 packet).		IPv6 packet).
	TotalLength:		PayloadLength:
	The 16 bit unsigned integer length field of the inner IPv6 inner		The 16 bit unsigned integer "Payload Length" field of the inner
	packet.		IPv6 inner packet.
	6.1.3.3. Pad Data Block		6.1.3.3. Pad Data Block
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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
			As discussed in Section 5.1 a notification message USE_IPTFS is used
			to negotiate IP-TFS operation in IKEv2.
			The USE_IPTFS Notification Message State Type is (TBD2).
			The notification payload contains 1 octet of requirement flags.
			There are currently 2 requirement flags defined. This may be revised
			by later specifications.
			+-+-+-+-+-+-+-+-+
			|0|0|0|0|0|0|C|D|
			+-+-+-+-+-+-+-+-+
			0:
			6 bits - reserved, MUST be zero on send, unless defined by later
			specifications.
			C:
			Congestion Control bit. If set, then the sender is requiring that
			congestion control information MUST be returned to it periodically
			as defined in Section 3.
			D:
			Don't Fragment bit, if set indicates the sender of the notify
			message does not support receiving packet fragments (i.e., inner
			packets MUST be sent using a single "Data Block"). This value
			only applies to what the sender is capable of receiving; the
			sender MAY still send packet fragments unless similarly restricted
			by the receiver in it's USE_IPTFS notification.
	7. IANA Considerations		7. IANA Considerations
	7.1. IPTFS_PROTOCOL Type		7.1. IPTFS_PROTOCOL Type
	This document requests a protocol number IPTFS_PROTOCOL be allocated		This document requests a protocol number IPTFS_PROTOCOL be allocated
	by IANA from "Assigned Internet Protocol Numbers" registry for		by IANA from "Assigned Internet Protocol Numbers" registry for
	identifying the IP-TFS ESP payload format.		identifying the IP-TFS payload.
	Type:		Type:
	TBD1		TBD1
	Description:		Description:
	IP-TFS ESP payload format.		An IP-TFS payload.
	Reference:		Reference:
	This document		This document
	7.2. IKEv2 Transform Type TFS Type		7.2. IPTFS_PROTOCOL Sub-Type Registry
	This document requests an IKEv2 Transform Type "TFS Type" be		This document requests IANA create a registry called "IPTFS_PROTOCOL
	allocated by IANA from the "Transform Type Values" registry.		Sub-Type Registry" under "IPTFS_PROTOCOL Parameters" IANA registries.
			The registration policy for this registry is "Standards Action"
			([RFC8126] and [RFC7120]).
	Type:		Name:
	TBD2		IPTFS_PROTOCOL Sub-Type Registry
	Description:		Description:
	TFS Type		IPTFS_PROTOCOL Payload Formats.
	Used In:
	(optional in ESP)
	Reference:		Reference:
	This document		This document
	7.3. TFS Type Transform IDs Registry		This initial content for this registry is as follows:
	This document requests a "Transform Type TBD3 - TFS Type Transform
	IDs" registry be created. The registration procedure is Expert
	Review. The initial values are as follows:
	Number Name Reference		Sub-Type Name Reference
	----------------------------------------		--------------------------------------------------------
	0 NONE This document		0 Non-Congestion Control Format This document
	1 TFS_IPTFS_CC This document		1 Congestion Control Format This document
	2 TFS_IPTFS_NOCC This document		3-255 Reserved
	3-65535 Reserved This document
	7.4. IPTFS_REQUIREMENTS Notify Message Status Type		7.3. USE_IPTFS Notify Message Status Type
	This document requests a status type IPTFS_REQUIREMENTS be allocated		This document requests a status type USE_IPTFS be allocated from the
	from the "IKEv2 Notify Message Types - Status Types" registry.		"IKEv2 Notify Message Types - Status Types" registry.
	Value:		Value:
	TBD3		TBD2
	Name:		Name:
	IPTFS_REQUIREMENTS		USE_IPTFS
	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 18, line 34 ¶		skipping to change at page 18, line 38 ¶
	[AppCrypt]		[AppCrypt]
	Schneier, B., "Applied Cryptography: Protocols,		Schneier, B., "Applied Cryptography: Protocols,
	Algorithms, and Source Code in C", 11 2017.		Algorithms, and Source Code in C", 11 2017.
	[I-D.iab-wire-image]		[I-D.iab-wire-image]
	Trammell, B. and M. Kuehlewind, "The Wire Image of a		Trammell, B. and M. Kuehlewind, "The Wire Image of a
	Network Protocol", draft-iab-wire-image-01 (work in		Network Protocol", draft-iab-wire-image-01 (work in
	progress), November 2018.		progress), November 2018.
	[IKEV2IANA]
	IANA, "Internet Key Exchange Version 2 (IKEv2)
	Parameters",
	<http://www.iana.org/assignments/ikev2-parameters/>.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	DOI 10.17487/RFC0791, September 1981,		DOI 10.17487/RFC0791, September 1981,
	<https://www.rfc-editor.org/info/rfc791>.		<https://www.rfc-editor.org/info/rfc791>.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	DOI 10.17487/RFC1191, November 1990,		DOI 10.17487/RFC1191, November 1990,
	<https://www.rfc-editor.org/info/rfc1191>.		<https://www.rfc-editor.org/info/rfc1191>.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	skipping to change at page 19, line 29 ¶		skipping to change at page 19, line 29 ¶
	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>.
	[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
			Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
			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,
	"Encapsulating MPLS in UDP", RFC 7510,		"Encapsulating MPLS in UDP", RFC 7510,
	DOI 10.17487/RFC7510, April 2015,		DOI 10.17487/RFC7510, April 2015,
	<https://www.rfc-editor.org/info/rfc7510>.		<https://www.rfc-editor.org/info/rfc7510>.
	[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",		[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
	BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,		BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
	<https://www.rfc-editor.org/info/rfc8084>.		<https://www.rfc-editor.org/info/rfc8084>.
			[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	[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>.
End of changes. 56 change blocks.
	142 lines changed or deleted		154 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/