draft-ietf-tcpm-converters-07.txt		draft-ietf-tcpm-converters-08.txt
	TCPM Working Group O. Bonaventure, Ed.		TCPM Working Group O. Bonaventure, Ed.
	Internet-Draft Tessares		Internet-Draft Tessares
	Intended status: Experimental M. Boucadair, Ed.		Intended status: Experimental M. Boucadair, Ed.
	Expires: December 13, 2019 Orange		Expires: December 20, 2019 Orange
	S. Gundavelli		S. Gundavelli
	Cisco		Cisco
	S. Seo		S. Seo
	Korea Telecom		Korea Telecom
	B. Hesmans		B. Hesmans
	Tessares		Tessares
	June 11, 2019		June 18, 2019
	0-RTT TCP Convert Protocol		0-RTT TCP Convert Protocol
	draft-ietf-tcpm-converters-07		draft-ietf-tcpm-converters-08
	Abstract		Abstract
	This document specifies an application proxy, called Transport		This document specifies an application proxy, called Transport
	Converter, to assist the deployment of TCP extensions such as		Converter, to assist the deployment of TCP extensions such as
	Multipath TCP. This proxy is designed to avoid inducing extra delay		Multipath TCP. This proxy is designed to avoid inducing extra delay
	when involved in a network-assisted connection (that is, 0-RTT).		when involved in a network-assisted connection (that is, 0-RTT).
	This specification assumes an explicit model, where the proxy is		This specification assumes an explicit model, where the proxy is
	explicitly configured on hosts.		explicitly configured on hosts.
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 December 13, 2019.		This Internet-Draft will expire on December 20, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 31 ¶		skipping to change at page 2, line 31 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 6		3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 6
	3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 8		3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 8
	3.3. Sample Examples of Outgoing Converter-Assisted Multipath		3.3. Sample Examples of Outgoing Converter-Assisted Multipath
	TCP Connections . . . . . . . . . . . . . . . . . . . . . 11		TCP Connections . . . . . . . . . . . . . . . . . . . . . 11
	3.4. Sample Example of Incoming Converter-Assisted Multipath		3.4. Sample Example of Incoming Converter-Assisted Multipath
	TCP Connection . . . . . . . . . . . . . . . . . . . . . 12		TCP Connection . . . . . . . . . . . . . . . . . . . . . 13
	4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 13		4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 14
	4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 13		4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 14
	4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 14		4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 15
	4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 14		4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 15
	4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 15		4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16
	4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 16		4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17
	4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 16		4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 17
	4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 17		4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 18
	4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 19		4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 20
	4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 19		4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 20
	4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 20		4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 21
	5. Compatibility of Specific TCP Options with the Conversion		5. Compatibility of Specific TCP Options with the Conversion
	Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 23		Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 23		5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 24
	5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 24		5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 25
	5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 24		5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 25
	5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 25		5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 26
	5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 25		5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 26
	5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 25		5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 26
	5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 26		5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 27
	5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 26		5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 27
	5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 26		5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 27
	6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 26		6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 27
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 27		7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 27		7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 28
	7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 28		7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 29
	7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 29		7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 30
	7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 29		7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 30
	7.5. Multipath TCP-specific Considerations . . . . . . . . . . 29		7.5. Multipath TCP-specific Considerations . . . . . . . . . . 30
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	8.1. Convert Service Port Number . . . . . . . . . . . . . . . 30		8.1. Convert Service Port Number . . . . . . . . . . . . . . . 31
	8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 30		8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 31
	8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 30		8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 31
	8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 31		8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 32
	8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 31		8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 32
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
	9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 33		9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 34
	10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 34		10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 35
	11. Example Socket API Changes to Support the 0-RTT Convert		11. Example Socket API Changes to Support the 0-RTT Convert
	Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 35		Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	11.1. Active Open (Client Side) . . . . . . . . . . . . . . . 35		11.1. Active Open (Client Side) . . . . . . . . . . . . . . . 36
	11.2. Passive Open (Converter Side) . . . . . . . . . . . . . 36		11.2. Passive Open (Converter Side) . . . . . . . . . . . . . 37
	12. Differences with SOCKSv5 . . . . . . . . . . . . . . . . . . 37		12. Differences with SOCKSv5 . . . . . . . . . . . . . . . . . . 38
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	13.1. Normative References . . . . . . . . . . . . . . . . . . 39		13.1. Normative References . . . . . . . . . . . . . . . . . . 40
	13.2. Informative References . . . . . . . . . . . . . . . . . 41		13.2. Informative References . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
	1. Introduction		1. Introduction
	Transport protocols like TCP evolve regularly [RFC7414]. TCP has		Transport protocols like TCP evolve regularly [RFC7414]. TCP has
	been improved in different ways. Some improvements such as changing		been improved in different ways. Some improvements such as changing
	the initial window size [RFC6928] or modifying the congestion control		the initial window size [RFC6928] or modifying the congestion control
	scheme can be applied independently on clients and servers. Other		scheme can be applied independently on clients and servers. Other
	improvements such as Selective Acknowledgements [RFC2018] or large		improvements such as Selective Acknowledgements [RFC2018] or large
	windows [RFC7323] require a new TCP option or to change the semantics		windows [RFC7323] require a new TCP option or to change the semantics
	of some fields in the TCP header. These modifications must be		of some fields in the TCP header. These modifications must be
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 26 ¶
	extensions on both a wide range of clients and servers remains		extensions on both a wide range of clients and servers remains
	difficult.		difficult.
	More recently, experimentation of 5G bonding, which has very scarce		More recently, experimentation of 5G bonding, which has very scarce
	coverage, has been conducted into global range of the incumbent 4G		coverage, has been conducted into global range of the incumbent 4G
	(LTE) connectivity in newly devised clients using Multipath TCP		(LTE) connectivity in newly devised clients using Multipath TCP
	proxy. Even if the 5G and the 4G bonding by using Multipath TCP		proxy. Even if the 5G and the 4G bonding by using Multipath TCP
	increases the bandwidth, it is as well crucial to minimize latency		increases the bandwidth, it is as well crucial to minimize latency
	for all the way between endhosts regardless of whether intermediate		for all the way between endhosts regardless of whether intermediate
	nodes are inside or outside of the mobile core. In order to handle		nodes are inside or outside of the mobile core. In order to handle
	uRLLC (Ultra-Reliable Low-Latency Communication) for the next		URLLC (Ultra Reliable Low Latency Communication) for the next
	generation mobile network, Multipath TCP and its proxy mechanism such		generation mobile network, Multipath TCP and its proxy mechanism such
	as the one used to provide Access Taffic Steering, Switching, and		as the one used to provide Access Traffic Steering, Switching, and
	Splitting (ATSSS) must be optimised to reduce latency.		Splitting (ATSSS) must be optimised to reduce latency [TS23501].
	This document specifies an application proxy, called Transport		This document specifies an application proxy, called Transport
	Converter. A Transport Converter is a function that is installed by		Converter. A Transport Converter is a function that is installed by
	a network operator to aid the deployment of TCP extensions and to		a network operator to aid the deployment of TCP extensions and to
	provide the benefits of such extensions to clients. A Transport		provide the benefits of such extensions to clients. A Transport
	Converter may provide conversion service for one or more TCP		Converter may provide conversion service for one or more TCP
	extensions. Which TCP extensions are eligible to the conversion		extensions. Which TCP extensions are eligible to the conversion
	service is deployment-specific. The conversion service is provided		service is deployment-specific. The conversion service is provided
	by means of the 0-RTT TCP Convert Protocol (Convert), that is an		by means of the 0-RTT TCP Convert Protocol (Convert), that is an
	application-layer protocol which uses TCP port number TBA		application-layer protocol which uses TCP port number TBA
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 31 ¶
	o the downstream connection is between the Transport Converter and		o the downstream connection is between the Transport Converter and
	the Server.		the Server.
	Any user data received by the Transport Converter over the upstream		Any user data received by the Transport Converter over the upstream
	(or downstream) connection is relayed over the downstream (or		(or downstream) connection is relayed over the downstream (or
	upstream) connection. In particular, if the initial SYN message		upstream) connection. In particular, if the initial SYN message
	contains data in its payload (e.g., [RFC7413]), that data MUST be		contains data in its payload (e.g., [RFC7413]), that data MUST be
	placed right after the Convert TLVs when generating the relayed SYN.		placed right after the Convert TLVs when generating the relayed SYN.
			The Converter associates a lifetime with state entries used to bind
			an upstream connection with its downstream connection.
	Figure 5 illustrates the establishment of an outbound TCP connection		Figure 5 illustrates the establishment of an outbound TCP connection
	by a Client through a Transport Converter. The information shown		by a Client through a Transport Converter. The information shown
	between brackets denotes Convert Protocol messages described in		between brackets denotes Convert Protocol messages described in
	Section 4.		Section 4.
	Transport		Transport
	Client Converter Server		Client Converter Server
	| | |		| | |
	|SYN [->Server:port]| SYN |		|SYN [->Server:port]| SYN |
	|------------------>|--------------------->|		|------------------>|--------------------->|
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 49 ¶
	specification follows an approach similar to TCP Fast Open [RFC7413]		specification follows an approach similar to TCP Fast Open [RFC7413]
	and thus removes the constraint by allowing data in SYN packets to be		and thus removes the constraint by allowing data in SYN packets to be
	delivered to the Transport Converter application.		delivered to the Transport Converter application.
	As discussed in [RFC7413], such change to TCP semantic raises two		As discussed in [RFC7413], such change to TCP semantic raises two
	issues. First, duplicate SYNs can cause problems for some		issues. First, duplicate SYNs can cause problems for some
	applications that rely on TCP. Second, TCP suffers from SYN flooding		applications that rely on TCP. Second, TCP suffers from SYN flooding
	attacks [RFC4987]. TFO solves these two problems for applications		attacks [RFC4987]. TFO solves these two problems for applications
	that can tolerate replays by using the TCP Fast Open option that		that can tolerate replays by using the TCP Fast Open option that
	includes a cookie. However, the utilization of this option consumes		includes a cookie. However, the utilization of this option consumes
	space in the limited TCP extended header. Furthermore, there are		space in the limited TCP header. Furthermore, there are situations,
	situations, as noted in Section 7.3 of [RFC7413] where it is possible		as noted in Section 7.3 of [RFC7413] where it is possible to accept
	to accept the payload of SYN packets without creating additional		the payload of SYN packets without creating additional security risks
	security risks such as a network where addresses cannot be spoofed		such as a network where addresses cannot be spoofed and the Transport
	and the Transport Converter only serves a set of hosts that are		Converter only serves a set of hosts that are identified by these
	identified by these addresses.		addresses.
	For these reasons, this specification does not mandate the use of the		For these reasons, this specification does not mandate the use of the
	TCP Fast Open option when the Client sends a connection establishment		TCP Fast Open option when the Client sends a connection establishment
	packet towards a Transport Converter. The Convert protocol includes		packet towards a Transport Converter. The Convert protocol includes
	an optional Cookie TLV that provides similar protection as the TCP		an optional Cookie TLV that provides similar protection as the TCP
	Fast Open option without consuming space in the extended TCP header.		Fast Open option without consuming space in the extended TCP header.
			If the downstream (or upstream) connection fails for some reason
			(excessive retransmissions, reception of a RST segment, etc.), then
			the Converter should force the teardown of the upstream (or
			downstream) connection.
			The same reasoning applies when the upstream connection ends. In
			this case, the Converter should also terminate the downstream
			connection by using FIN segments. If the downstream connection
			terminates with the exchange of FIN segments, the Converter should
			initiate a graceful termination of the upstream connection.
	3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP		3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP
	Connections		Connections
	As an example, let us consider how the Convert protocol can help the		As an example, let us consider how the Convert protocol can help the
	deployment of Multipath TCP. We assume that both the Client and the		deployment of Multipath TCP. We assume that both the Client and the
	Transport Converter support Multipath TCP, but consider two different		Transport Converter support Multipath TCP, but consider two different
	cases depending on whether the Server supports Multipath TCP or not.		cases depending on whether the Server supports Multipath TCP or not.
	As a reminder, a Multipath TCP connection is created by placing the		As a reminder, a Multipath TCP connection is created by placing the
	MP_CAPABLE (MPC) option in the SYN sent by the Client.		MP_CAPABLE (MPC) option in the SYN sent by the Client.
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 33 ¶
	The Client tries to initiate a Multipath TCP connection by sending a		The Client tries to initiate a Multipath TCP connection by sending a
	SYN with the MP_CAPABLE option (MPC in Figure 6). The SYN includes		SYN with the MP_CAPABLE option (MPC in Figure 6). The SYN includes
	the address and port number of the target Server, that are extracted		the address and port number of the target Server, that are extracted
	and used by the Transport Converter to initiate a Multipath TCP		and used by the Transport Converter to initiate a Multipath TCP
	connection towards this Server. Since the Server does not support		connection towards this Server. Since the Server does not support
	Multipath TCP, it replies with a SYN+ACK that does not contain the		Multipath TCP, it replies with a SYN+ACK that does not contain the
	MP_CAPABLE option. The Transport Converter notes that the connection		MP_CAPABLE option. The Transport Converter notes that the connection
	with the Server does not support Multipath TCP and returns the		with the Server does not support Multipath TCP and returns the
	extended TCP header received from the Server to the Client.		extended TCP header received from the Server to the Client.
			Note that, if the TCP connection fails for some reason, the Converter
			tears down the Multipath TCP connection by transmitting a
			MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with
			the transmission of DATA_FINs, the Converter terminates the TCP
			connection by using FIN segments.
	Figure 7 considers a Server that supports Multipath TCP. In this		Figure 7 considers a Server that supports Multipath TCP. In this
	case, it replies to the SYN sent by the Transport Converter with the		case, it replies to the SYN sent by the Transport Converter with the
	MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport		MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport
	Converter confirms the establishment of the connection to the Client		Converter confirms the establishment of the connection to the Client
	and indicates to the Client that the Server supports Multipath TCP.		and indicates to the Client that the Server supports Multipath TCP.
	With this information, the Client has discovered that the Server		With this information, the Client has discovered that the Server
	supports Multipath TCP natively. This will enable the Client to		supports Multipath TCP natively. This will enable the Client to
	bypass the Transport Converter for the subsequent Multipath TCP		bypass the Transport Converter for the subsequent Multipath TCP
	connections that it will initiate towards this Server.		connections that it will initiate towards this Server.
	skipping to change at page 23, line 52 ¶		skipping to change at page 24, line 52 ¶
	In this section, we discuss how several standard track TCP options		In this section, we discuss how several standard track TCP options
	can be supported through the Convert protocol. The non-standard		can be supported through the Convert protocol. The non-standard
	track options and the experimental options will be discussed in other		track options and the experimental options will be discussed in other
	documents.		documents.
	5.1. Base TCP Options		5.1. Base TCP Options
	Three TCP options were initially defined in [RFC0793]: End-of-Option		Three TCP options were initially defined in [RFC0793]: End-of-Option
	List (Kind=0), No-Operation (Kind=1) and Maximum Segment Size		List (Kind=0), No-Operation (Kind=1) and Maximum Segment Size
	(Kind=2). The first two options are mainly used to pad the TCP		(Kind=2). The first two options are mainly used to pad the TCP
	extended header. There is no reason for a client to request a		header. There is no reason for a client to request a Transport
	Transport Converter to specifically send these options towards the		Converter to specifically send these options towards the final
	final destination.		destination.
	The Maximum Segment Size option (Kind=2) is used by a host to		The Maximum Segment Size option (Kind=2) is used by a host to
	indicate the largest segment that it can receive over each		indicate the largest segment that it can receive over each
	connection. This value is function of the stack that terminates the		connection. This value is function of the stack that terminates the
	TCP connection. There is no reason for a Client to request a		TCP connection. There is no reason for a Client to request a
	Transport Converter to advertise a specific MSS value to a remote		Transport Converter to advertise a specific MSS value to a remote
	server.		server.
	A Transport Converter MUST ignore options with Kind=0, 1 or 2 if they		A Transport Converter MUST ignore options with Kind=0, 1 or 2 if they
	appear in a Connect TLV. It MUST NOT announce them in a Supported		appear in a Connect TLV. It MUST NOT announce them in a Supported
	skipping to change at page 35, line 35 ¶		skipping to change at page 36, line 35 ¶
	o 07:		o 07:
	* Update the text about supplying data in SYNs to make it clear		* Update the text about supplying data in SYNs to make it clear
	that a constraint defined in RFC793 is relaxed folloiwng the		that a constraint defined in RFC793 is relaxed folloiwng the
	same rationale as in RFC7413.		same rationale as in RFC7413.
	* Nits		* Nits
	* Added Appendix A on example Socket API changes		* Added Appendix A on example Socket API changes
			o 08:
			* Added short discusion on the termination of connections
	11. Example Socket API Changes to Support the 0-RTT Convert Protocol		11. Example Socket API Changes to Support the 0-RTT Convert Protocol
	11.1. Active Open (Client Side)		11.1. Active Open (Client Side)
	On the client side, the support of the 0-RTT Converter protocol does		On the client side, the support of the 0-RTT Converter protocol does
	not require any other changes than those identified in Appendix A of		not require any other changes than those identified in Appendix A of
	[RFC7413]. Those modifications are already supported by multiple TCP		[RFC7413]. Those modifications are already supported by multiple TCP
	stacks.		stacks.
	As an example, on Linux, a client can send the 0-RTT Convert message		As an example, on Linux, a client can send the 0-RTT Convert message
	skipping to change at page 44, line 30 ¶		skipping to change at page 45, line 30 ¶
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,		[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
	Q., and E. Smith, "Cryptographic Protection of TCP Streams		Q., and E. Smith, "Cryptographic Protection of TCP Streams
	(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,		(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
	<https://www.rfc-editor.org/info/rfc8548>.		<https://www.rfc-editor.org/info/rfc8548>.
			[TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical
			Specification Group Services and System Aspects; System
			Architecture for the 5G System; Stage 2 (Release 16)",
			2019, <https://www.3gpp.org/ftp/Specs/
			archive/23_series/23.501/>.
	Authors' Addresses		Authors' Addresses
	Olivier Bonaventure (editor)		Olivier Bonaventure (editor)
	Tessares		Tessares
	Email: Olivier.Bonaventure@tessares.net		Email: Olivier.Bonaventure@tessares.net
	Mohamed Boucadair (editor)		Mohamed Boucadair (editor)
	Orange		Orange
End of changes. 16 change blocks.
	62 lines changed or deleted		92 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/