draft-ietf-tcpm-converters-10.txt		draft-ietf-tcpm-converters-11.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: February 2, 2020 Orange		Expires: March 30, 2020 Orange
	S. Gundavelli		S. Gundavelli
	Cisco		Cisco
	S. Seo		S. Seo
	Korea Telecom		Korea Telecom
	B. Hesmans		B. Hesmans
	Tessares		Tessares
	August 01, 2019		September 27, 2019
	0-RTT TCP Convert Protocol		0-RTT TCP Convert Protocol
	draft-ietf-tcpm-converters-10		draft-ietf-tcpm-converters-11
	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.
	Editorial Note (To be removed by RFC Editor)		-- Editorial Note (To be removed by RFC Editor)
	Please update these statements with the RFC number to be assigned to		Please update these statements with the RFC number to be assigned to
	this document: [This-RFC]		this document: [This-RFC]
	Please update TBA statements with the port number to be assigned to		Please update TBA statements with the port number to be assigned to
	the 0-RTT TCP Convert Protocol.		the 0-RTT TCP Convert Protocol.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	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 February 2, 2020.		This Internet-Draft will expire on March 30, 2020.
	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 29 ¶		skipping to change at page 2, line 29 ¶
	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. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Network-Assisted Connections: The Rationale . . . . . . . 4		1.2. Network-Assisted Connections: The Rationale . . . . . . . 4
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . 9
	3.3. Sample Examples of Outgoing Converter-Assisted Multipath		3.3. Sample Examples of Outgoing Converter-Assisted Multipath
	TCP Connections . . . . . . . . . . . . . . . . . . . . . 12		TCP Connections . . . . . . . . . . . . . . . . . . . . . 13
	3.4. Sample Example of Incoming Converter-Assisted Multipath		3.4. Sample Example of Incoming Converter-Assisted Multipath
	TCP Connection . . . . . . . . . . . . . . . . . . . . . 13		TCP Connection . . . . . . . . . . . . . . . . . . . . . 14
	4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 15		4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 15
	4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 15		4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 16
	4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 16		4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 17
	4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 16		4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 17
	4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16		4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 17
	4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17		4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 18
	4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 18		4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 19
	4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 19		4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 20
	4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 21		4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 22
	4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 21		4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 22
	4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 22		4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 23
	5. Compatibility of Specific TCP Options with the Conversion		5. Compatibility of Specific TCP Options with the Conversion
	Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 25		5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 26
	5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 26		5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 27
	5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 26		5.3. Selective Acknowledgments . . . . . . . . . . . . . . . . 27
	5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 27		5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 28
	5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 27		5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 28
	5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 27		5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 28
	5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 28		5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 29
	5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 28		5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 29
	5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 28		5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 29
	6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 28		6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 29
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 29		7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 29		7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 30
	7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 30		7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 31
	7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 31		7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32
	7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 31		7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 32
	7.5. Multipath TCP-specific Considerations . . . . . . . . . . 32		7.5. Multipath TCP-specific Considerations . . . . . . . . . . 33
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	8.1. Convert Service Port Number . . . . . . . . . . . . . . . 32		8.1. Convert Service Port Number . . . . . . . . . . . . . . . 33
	8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 33		8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 34
	8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 33		8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 34
	8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 33		8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 34
	8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 34		8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 35
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	9.1. Normative References . . . . . . . . . . . . . . . . . . 35		9.1. Normative References . . . . . . . . . . . . . . . . . . 36
	9.2. Informative References . . . . . . . . . . . . . . . . . 37		9.2. Informative References . . . . . . . . . . . . . . . . . 38
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41
	Appendix B. Example Socket API Changes to Support the 0-RTT		Appendix B. Example Socket API Changes to Support the 0-RTT
	Convert Protocol . . . . . . . . . . . . . . . . . . 42		Convert Protocol . . . . . . . . . . . . . . . . . . 43
	B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 42		B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 43
	B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 42		B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 43
	Appendix C. Some Design Considerations . . . . . . . . . . . . . 43		Appendix C. Some Design Considerations . . . . . . . . . . . . . 44
	Appendix D. Differences with SOCKSv5 . . . . . . . . . . . . . . 44		Appendix D. Differences with SOCKSv5 . . . . . . . . . . . . . . 45
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
	1. Introduction		1. Introduction
	1.1. The Problem		1.1. The Problem
	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 Acknowledgments [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
	deployed on both clients and servers to be actually used on the		deployed on both clients and servers to be actually used on the
	Internet. Experience with the latter TCP extensions reveals that		Internet. Experience with the latter TCP extensions reveals that
	their deployment can require many years. Fukuda reports in		their deployment can require many years. Fukuda reports in
	[Fukuda2011] results of a decade of measurements showing the		[Fukuda2011] results of a decade of measurements showing the
	deployment of Selective Acknowledgements, Window Scale and TCP		deployment of Selective Acknowledgments, Window Scale and TCP
	Timestamps. [ANRW17] describes measurements showing that TCP Fast		Timestamps. [ANRW17] describes measurements showing that TCP Fast
	Open (TFO) [RFC7413] is still not widely deployed.		Open (TFO) [RFC7413] is still not widely deployed.
	There are some situations where the transport stack used on clients		There are some situations where the transport stack used on clients
	(or servers) can be upgraded at a faster pace than the transport		(or servers) can be upgraded at a faster pace than the transport
	stack running on servers (or clients). In those situations, clients		stack running on servers (or clients). In those situations, clients
	would typically want to benefit from the features of an improved		would typically want to benefit from the features of an improved
	transport protocol even if the servers have not yet been upgraded and		transport protocol even if the servers have not yet been upgraded and
	conversely. Some assistance from the network to make use of these		conversely. Some assistance from the network to make use of these
	features is valuable. For example, Performance Enhancing Proxies		features is valuable. For example, Performance Enhancing Proxies
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	policies. These policies, and how they are communicated to		policies. These policies, and how they are communicated to
	endpoints, are out of scope. Furthermore, it is possible to bypass		endpoints, are out of scope. Furthermore, it is possible to bypass
	the Transport Converter to connect directly to the servers that		the Transport Converter to connect directly to the servers that
	already support the required TCP extension(s).		already support the required TCP extension(s).
	This document assumes an explicit model in which a client is		This document assumes an explicit model in which a client is
	configured with one or a list of Transport Converters (statically or		configured with one or a list of Transport Converters (statically or
	through protocols such as [I-D.boucadair-tcpm-dhc-converter]).		through protocols such as [I-D.boucadair-tcpm-dhc-converter]).
	Configuration means are outside the scope of this document.		Configuration means are outside the scope of this document.
			The use of a Transport Converter means that there is no end-to-end
			transport connection between the client and server. This could
			potentially create problems in some scenarios such as those discussed
			in Section 4 of [RFC3135]. Some of these problems may not be
			applicable, for example, a Transport Converter can inform a client by
			means of Network Failure (65) or Destination Unreachable (97) error
			messages (Section 4.2.8) that it encounters a failure problem; the
			client can react accordingly. An endpoint, or its network
			administrator, can assess the benefit provided by the Transport
			Converter service versus the risk. This is one reason why the
			Transport Converter functionality has to be explicitly requested by
			an endpoint.
	This document is organized as follows. First, Section 3 provides a		This document is organized as follows. First, Section 3 provides a
	brief explanation of the operation of Transport Converters. Then,		brief explanation of the operation of Transport Converters. Then,
	Section 4 describes the Convert Protocol. Section 5 discusses how		Section 4 describes the Convert Protocol. Section 5 discusses how
	Transport Converters can be used to support different TCP extensions.		Transport Converters can be used to support different TCP extensions.
	Section 6 then discusses the interactions with middleboxes, while		Section 6 then discusses the interactions with middleboxes, while
	Section 7 focuses on the security considerations.		Section 7 focuses on the security considerations.
	Appendix B describes how a TCP stack would need to support the		Appendix B describes how a TCP stack would need to support the
	protocol described in this document. Appendix C records some		protocol described in this document. Appendix C records some
	considerations that impacted the design of the protocol. Appendix D		considerations that impacted the design of the protocol. Appendix D
	skipping to change at page 6, line 39 ¶		skipping to change at page 7, line 4 ¶
	Only the exchange of control messages is depicted in the figures.		Only the exchange of control messages is depicted in the figures.
	3. Architecture		3. Architecture
	3.1. Functional Elements		3.1. Functional Elements
	The Convert Protocol considers three functional elements:		The Convert Protocol considers three functional elements:
	o Clients;		o Clients;
	o Transport Converters;		o Transport Converters;
	o Servers.		o Servers.
	A Transport Converter is a network function that relays all data		A Transport Converter is a network function that proxies all data
	exchanged over one upstream connection to one downstream connection		exchanged over one upstream connection to one downstream connection
	and vice versa (Figure 1). The Transport Converter, thus, maintains		and vice versa (Figure 1). The Transport Converter, thus, maintains
	state that associates one upstream connection to a corresponding		state that associates one upstream connection to a corresponding
	downstream connection.		downstream connection.
	A connection can be initiated from both sides of the Transport		A connection can be initiated from both sides of the Transport
	Converter (Internet-facing interface, customer-facing interface).		Converter (Internet-facing interface, customer-facing interface).
	|		|
	:		:
	|		|
	+------------+		+------------+
	Client <- upstream ->| Transport |<- downstream ->Server		Client <- upstream ->| Transport |<- downstream -> Server
	| Converter |		connection | Converter | connection
	+------------+		+------------+
	|		|
	customer-facing interface : Internet-facing interface		customer-facing interface : Internet-facing interface
	|		|
	Figure 1: A Transport Converter Relays Data between Pairs of TCP		Figure 1: A Transport Converter Proxies Data between Pairs of TCP
	Connections		Connections
	"Client" refers to a software instance embedded on a host that can		"Client" refers to a software instance embedded on a host that can
	reach a Transport Converter via its customer-facing interface. The		reach a Transport Converter via its customer-facing interface. The
	"Client" can initiate connections via a Transport Converter (referred		"Client" can initiate connections via a Transport Converter (referred
	to as outgoing connections (Section 3.3)). Also, the "Client" can		to as outgoing connections (Section 3.3)). Also, the "Client" can
	accept incoming connections via a Transport Converter (referred to as		accept incoming connections via a Transport Converter (referred to as
	incoming connections (Section 3.4)).		incoming connections (Section 3.4)).
	Transport Converters can be operated by network operators or third		Transport Converters can be operated by network operators or third
	skipping to change at page 9, line 49 ¶		skipping to change at page 10, line 25 ¶
	Server in the payload of the SYN sent to the Transport Converter to		Server in the payload of the SYN sent to the Transport Converter to
	minimize connection establishment delays. The Transport Converter		minimize connection establishment delays. The Transport Converter
	maintains two connections that are combined together:		maintains two connections that are combined together:
	o the upstream connection is the one between the Client and the		o the upstream connection is the one between the Client and the
	Transport Converter.		Transport Converter.
	o the downstream connection is between the Transport Converter and		o the downstream connection is between the Transport Converter and
	the Server.		the Server.
			The control messages, discussed in Section 4, establish state in the
			Transport Converter that will enable it to proxy between the two TCP
			connections. These control messages are destined to the Transport
			Convert and are, thus, removed by the Converter when proxying between
			the two connections.
	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 proxied 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 SYN.
	The Converter associates a lifetime with state entries used to bind		The Converter associates a lifetime with state entries used to bind
	an upstream connection with its downstream connection.		an upstream connection with its downstream connection.
	A Transport Converter MAY operate in address preservation or address		A Transport Converter may operate in address preservation or address
	sharing modes as discussed in Section 5.4 of		sharing modes (e.g., Section 5.4 of
	[I-D.nam-mptcp-deployment-considerations]. Which behavior to use by		[I-D.nam-mptcp-deployment-considerations]). Which behavior to use by
	a Transport Converter is deployment-specific. If address sharing		a Transport Converter is deployment-specific. If address sharing
	mode is enabled, the Transport Converter MUST adhere to REQ-2 of		mode is enabled, the Transport Converter MUST adhere to REQ-2 of
	[RFC6888] which implies a default "IP address pooling" behavior of		[RFC6888] which implies a default "IP address pooling" behavior of
	"Paired" (as defined in Section 4.1 of [RFC4787]) must be supported.		"Paired" (as defined in Section 4.1 of [RFC4787]) must be supported.
	This behavior is meant to avoid breaking applications that depend on		This behavior is meant to avoid breaking applications that depend on
	the source address remaining constant.		the source address remaining constant.
	Figure 5 illustrates the establishment of an outgoing TCP connection		Figure 5 illustrates the establishment of an outgoing TCP connection
	by a Client through a Transport Converter.		by a Client through a Transport Converter.
	skipping to change at page 10, line 43 ¶		skipping to change at page 11, line 25 ¶
	Transport Converter		Transport Converter
	The Client sends a SYN destined to the Transport Converter. The		The Client sends a SYN destined to the Transport Converter. The
	payload of this SYN contains the address and port number of the		payload of this SYN contains the address and port number of the
	Server. The Transport Converter does not reply immediately to this		Server. The Transport Converter does not reply immediately to this
	SYN. It first tries to create a TCP connection towards the target		SYN. It first tries to create a TCP connection towards the target
	Server. If this upstream connection succeeds, the Transport		Server. If this upstream connection succeeds, the Transport
	Converter confirms the establishment of the connection to the Client		Converter confirms the establishment of the connection to the Client
	by returning a SYN+ACK and the first bytes of the bytestream contain		by returning a SYN+ACK and the first bytes of the bytestream contain
	information about the TCP options that were negotiated with the		information about the TCP options that were negotiated with the
	Server.		Server. Also, a state entry is instantiated for this connection.
			This state entry is used by the Converter to handle subsequent
			messages belonging to the connection. Note that the Converter
			silently ignores Non-SYN messages that do not match an active state
			entry.
	The connection can also be established from the Internet towards a		The connection can also be established from the Internet towards a
	Client via a Transport Converter (Figure 6). This is typically the		Client via a Transport Converter (Figure 6). This is typically the
	case when an application on the Client listens to a specific port		case when an application on the Client listens to a specific port
	(the Client hosts an application server, typically). When the		(the Client hosts an application server, typically). When the
	Converter receives an incoming SYN from a remote host, it checks if		Converter receives an incoming SYN from a remote host, it checks if
	it can provide the conversion service for the destination IP address		it can provide the conversion service for the destination IP address
	and destination port number of that SYN. If the check is successful,		and destination port number of that SYN. If the check fails, the
	the Converter inserts the source IP address and source port number in		packet is silently ignored by the Converter. If the check is
	the SYN packet, rewrites the source IP address to one of its IP		successful, the Converter inserts the source IP address and source
	addresses and, eventually (i.e., only when the Converter is		port number in the SYN packet, rewrites the source IP address to one
			of its IP addresses and, eventually (i.e., only when the Converter is
	configured in an address sharing mode), the destination IP address		configured in an address sharing mode), the destination IP address
	and port number in accordance with any information stored locally.		and port number in accordance with any information stored locally.
	That SYN is then forwarded to the next hop. SYN+ACK and ACK will be		That SYN is then forwarded to the next hop. A transport session
	then exchanged between the Client, the Converter, and remote host to		entry is created by the Converter for this connection. SYN+ACK and
	confirm the establishment of the connection.		ACK will be then exchanged between the Client, the Converter, and
			remote host to confirm the establishment of the connection. The
			Converter uses the transport session entry to proxy packets belonging
			to the connection.
	Transport Remote		Transport Remote
	Client Converter Host (RH)		Client Converter Host (RH)
	| | |		| | |
	|SYN [<-RH IP@:port]| SYN |		|SYN [<-RH IP@:port]| SYN |
	|<------------------|<---------------------|		|<------------------|<---------------------|
	|------------------>|--------------------->|		|------------------>|--------------------->|
	| SYN+ACK [ ] | SYN+ACK |		| SYN+ACK [ ] | SYN+ACK |
	| ... | ... |		| ... | ... |
	skipping to change at page 12, line 7 ¶		skipping to change at page 12, line 47 ¶
	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.
	In particular, this design allows for the use of longer cookies.		In particular, this design allows for the use of longer cookies.
	If the downstream (or upstream) connection fails for some reason		If the downstream (or upstream) connection fails for some reason
	(excessive retransmissions, reception of an RST segment, etc.), then		(excessive retransmissions, reception of an RST segment, etc.), then
	the Converter should force the teardown of the upstream (or		the Converter should force the tear-down of the upstream (or
	downstream) connection.		downstream) connection.
	The same reasoning applies when the upstream connection ends. In		The same reasoning applies when the upstream connection ends. In
	this case, the Converter should also terminate the downstream		this case, the Converter should also terminate the downstream
	connection by using FIN segments. If the downstream connection		connection by using FIN segments. If the downstream connection
	terminates with the exchange of FIN segments, the Converter should		terminates with the exchange of FIN segments, the Converter should
	initiate a graceful termination of the upstream connection.		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
	skipping to change at page 12, line 39 ¶		skipping to change at page 13, line 30 ¶
	Transport		Transport
	Client Converter Server		Client Converter Server
	|SYN, | |		|SYN, | |
	|MPC [->Server:port]| SYN, MPC |		|MPC [->Server:port]| SYN, MPC |
	|------------------>|--------------------->|		|------------------>|--------------------->|
	|<------------------|<---------------------|		|<------------------|<---------------------|
	| SYN+ACK,MPC [.] | SYN+ACK |		| SYN+ACK,MPC [.] | SYN+ACK |
	|------------------>|--------------------->|		|------------------>|--------------------->|
	| ACK, MPC | ACK |		| ACK, MPC | ACK |
	| | |
	| ... | ... |		| ... | ... |
	Figure 7: Establishment of a Multipath TCP Connection Through a		Figure 7: Establishment of a Multipath TCP Connection Through a
	Transport Converter towards a Server that Does Not Support Multipath		Transport Converter towards a Server that Does Not Support Multipath
	TCP		TCP
	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 7). The SYN includes		SYN with the MP_CAPABLE option (MPC in Figure 7). 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
	skipping to change at page 13, line 37 ¶		skipping to change at page 14, line 28 ¶
	Transport		Transport
	Client Converter Server		Client Converter Server
	|SYN, | |		|SYN, | |
	|MPC [->Server:port]| SYN, MPC |		|MPC [->Server:port]| SYN, MPC |
	|------------------>|--------------------->|		|------------------>|--------------------->|
	|<------------------|<---------------------|		|<------------------|<---------------------|
	|SYN+ACK, | SYN+ACK, MPC |		|SYN+ACK, | SYN+ACK, MPC |
	|MPC [MPC supported]| |		|MPC [MPC supported]| |
	|------------------>|--------------------->|		|------------------>|--------------------->|
	| ACK, MPC | ACK, MPC |		| ACK, MPC | ACK, MPC |
	| | |
	| ... | ... |		| ... | ... |
	Figure 8: Establishment of a Multipath TCP Connection Through a		Figure 8: Establishment of a Multipath TCP Connection Through a
	Converter Towards an MPTCP-capable Server		Converter Towards an MPTCP-capable Server
	3.4. Sample Example of Incoming Converter-Assisted Multipath TCP		3.4. Sample Example of Incoming Converter-Assisted Multipath TCP
	Connection		Connection
	An example of an incoming Converter-assisted Multipath TCP connection		An example of an incoming Converter-assisted Multipath TCP connection
	is depicted in Figure 9. In order to support incoming connections		is depicted in Figure 9. In order to support incoming connections
	skipping to change at page 14, line 19 ¶		skipping to change at page 15, line 9 ¶
	port number). The Converter accepts the request by creating a TCP		port number). The Converter accepts the request by creating a TCP
	mapping (internal IP address, internal port number, external IP		mapping (internal IP address, internal port number, external IP
	address, external port number). The external IP address and external		address, external port number). The external IP address and external
	port number will be then advertised using an out-of-band mechanism so		port number will be then advertised using an out-of-band mechanism so
	that remote hosts can initiate TCP connections to the Client via the		that remote hosts can initiate TCP connections to the Client via the
	Converter. Note that the external and internal information may be		Converter. Note that the external and internal information may be
	the same.		the same.
	Then, when the Converter receives an incoming SYN, it checks its		Then, when the Converter receives an incoming SYN, it checks its
	mapping table to verify if there is an active mapping matching the		mapping table to verify if there is an active mapping matching the
	destination IP address and destination port of that SYN. If an entry		destination IP address and destination port of that SYN. If no entry
	is found, the Converter inserts an MP_CAPABLE option and Connect TLV		is found, the Converter silently ignores the message. If an entry is
	in the SYN packet, rewrites the source IP address to one of its IP		found, the Converter inserts an MP_CAPABLE option and Connect TLV in
			the SYN packet, rewrites the source IP address to one of its IP
	addresses and, eventually, the destination IP address and port number		addresses and, eventually, the destination IP address and port number
	in accordance with the information stored in the mapping. SYN+ACK		in accordance with the information stored in the mapping. SYN+ACK
	and ACK will be then exchanged between the Client and the Converter		and ACK will be then exchanged between the Client and the Converter
	to confirm the establishment of the initial subflow. The Client can		to confirm the establishment of the initial subflow. The Client can
	add new subflows following normal Multipath TCP procedures.		add new subflows following normal Multipath TCP procedures.
	Transport Remote		Transport Remote
	Client Converter Host		Client Converter Host
	| | |		| | |
	|<--------------------|<-------------------|		|<--------------------|<-------------------|
	|SYN, | SYN |		|SYN, | SYN |
	|MPC[Remote Host:port]| |		|MPC[Remote Host:port]| |
	|-------------------->|------------------->|		|-------------------->|------------------->|
	| SYN+ACK, MPC | SYN+ACK |		| SYN+ACK, MPC | SYN+ACK |
	|<--------------------|<-------------------|		|<--------------------|<-------------------|
	| ACK, MPC | ACK |		| ACK, MPC | ACK |
	| | |		| ... | ... |
	| ... | ... |
	Figure 9: Establishment of an Incoming Multipath TCP Connection		Figure 9: Establishment of an Incoming Multipath TCP Connection
	through a Transport Converter		through a Transport Converter
	It is out of scope of this document to define specific Convert TLVs		It is out of scope of this document to define specific Convert TLVs
	to manage incoming connections. These TLVs can be defined in a		to manage incoming connections. These TLVs can be defined in a
	separate document.		separate document.
	4. The Convert Protocol (Convert)		4. The Convert Protocol (Convert)
	This section defines the Convert protocol (Convert, for short)		This section defines the Convert protocol (Convert, for short)
	messages that are exchanged between a Client and a Transport		messages that are exchanged between a Client and a Transport
	Converter.		Converter.
	By default, the Transport Converter listens on TCP port number TBA		By default, the Transport Converter listens on TCP port number TBA
	for Convert messages from Clients.		for Convert messages from Clients.
	Clients send packets bound to connections eligible to the conversion		Clients send packets bound to connections eligible to the conversion
	service to the provisioned Transport Converter using TBA as		service to the provisioned Transport Converter using TBA as
	destination port number. This applies for both control and data		destination port number. This applies for both control messages and
	messages. Additional information is supplied by Clients to the		data. Additional information is supplied by Clients to the Transport
	Transport Converter by means of Convert messages as detailed in the		Converter by means of Convert messages as detailed in the following
	following sub-sections.		sub-sections.
	Convert messages may appear only in a SYN, SYN+ACK, or ACK.		Convert messages may appear only in a SYN, SYN+ACK, or ACK.
	Convert messages MUST be included as the first bytes of the		Convert messages MUST be included as the first bytes of the
	bytestream. All Convert messages start with a 32 bits long fixed		bytestream. All Convert messages starts with a 32 bits long fixed
	header (Section 4.1) followed by one or more Convert TLVs (Type,		header (Section 4.1) followed by one or more Convert TLVs (Type,
	Length, Value) (Section 4.2).		Length, Value) (Section 4.2).
			User data can be included in SYN or non-SYN messages. User data is
			unambiguously distinguished from Convert TLVs owing to the Total
			Length field in the Convert messages.
	4.1. The Convert Fixed Header		4.1. The Convert Fixed Header
	The Convert Protocol uses a 32 bits long fixed header that is sent by		The Convert Protocol uses a 32 bits long fixed header that is sent by
	both the Client and the Transport Converter over each established		both the Client and the Transport Converter over each established
	connection. This header indicates both the version of the protocol		connection. This header indicates both the version of the protocol
	used and the length of the Convert message.		used and the length of the Convert message.
	The Client and the Transport Converter MUST send the fixed-sized		The Client and the Transport Converter MUST send the fixed-sized
	header, shown in Figure 10, as the first four bytes of the		header, shown in Figure 10, as the first four bytes of the
	bytestream.		bytestream.
	skipping to change at page 19, line 52 ¶		skipping to change at page 20, line 52 ¶
	/ ... /		/ ... /
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 15: The Connect TLV		Figure 15: The Connect TLV
	The 'TCP Options' field is a variable length field that carries a		The 'TCP Options' field is a variable length field that carries a
	list of TCP option fields (Figure 16). Each TCP option field is		list of TCP option fields (Figure 16). Each TCP option field is
	encoded as a block of 2+n bytes where the first byte is the TCP		encoded as a block of 2+n bytes where the first byte is the TCP
	option Kind and the second byte is the length of the TCP option as		option Kind and the second byte is the length of the TCP option as
	specified in [RFC0793]. The minimum value for the TCP option Length		specified in [RFC0793]. The minimum value for the TCP option Length
	is 2. The TCP options that do not include a length subfield, i.e.,		is 2. The TCP options that do not include a length sub-field, i.e.,
	option types 0 (EOL) and 1 (NOP) defined in [RFC0793] MUST NOT be		option types 0 (EOL) and 1 (NOP) defined in [RFC0793] MUST NOT be
	placed inside the TCP options field of the Connect TLV. The optional		placed inside the TCP options field of the Connect TLV. The optional
	Value field contains the variable-length part of the TCP option. A		Value field contains the variable-length part of the TCP option. A
	length of two indicates the absence of the Value field. The TCP		length of two indicates the absence of the Value field. The TCP
	options field always ends on a 32 bits boundary after being padded		options field always ends on a 32 bits boundary after being padded
	with zeros.		with zeros.
	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
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	skipping to change at page 20, line 34 ¶		skipping to change at page 21, line 34 ¶
	limit) or resource exhaustion conditions, a Transport Converter		limit) or resource exhaustion conditions, a Transport Converter
	attempts to establish a connection to the address and port that it		attempts to establish a connection to the address and port that it
	contains. The Transport Converter MUST use by default the TCP		contains. The Transport Converter MUST use by default the TCP
	options that correspond to its local policy to establish this		options that correspond to its local policy to establish this
	connection. These are the options that it advertises in the		connection. These are the options that it advertises in the
	Supported TCP Extensions TLV.		Supported TCP Extensions TLV.
	Upon reception of an extended Connect TLV, and absent any rate limit		Upon reception of an extended Connect TLV, and absent any rate limit
	policy or resource exhaustion conditions, a Transport Converter MUST		policy or resource exhaustion conditions, a Transport Converter MUST
	attempt to establish a connection to the address and port that it		attempt to establish a connection to the address and port that it
	contains. It MUST include the options of the 'TCP Options' subfield		contains. It MUST include the options of the 'TCP Options' sub-field
	in the SYN sent to the Server in addition to the TCP options that it		in the SYN sent to the Server in addition to the TCP options that it
	would have used according to its local policies. For the TCP options		would have used according to its local policies. For the TCP options
	that are listed without an optional value, the Transport Converter		that are listed without an optional value, the Transport Converter
	MUST generate its own value. For the TCP options that are included		MUST generate its own value. For the TCP options that are included
	in the 'TCP Options' field with an optional value, it MUST copy the		in the 'TCP Options' field with an optional value, it MUST copy the
	entire option for use in the connection with the destination peer.		entire option for use in the connection with the destination peer.
	This feature is required to support TCP Fast Open.		This feature is required to support TCP Fast Open.
	The Transport Converter may discard a Connect TLV request for various		The Transport Converter may discard a Connect TLV request for various
	reasons (e.g., authorization failed, out of resources, invalid		reasons (e.g., authorization failed, out of resources, invalid
	skipping to change at page 24, line 47 ¶		skipping to change at page 25, line 47 ¶
	Converter does not have enough resources to perform the request.		Converter does not have enough resources to perform the request.
	This error MUST be sent by the Transport Converter when it does		This error MUST be sent by the Transport Converter when it does
	not have sufficient resources to handle a new connection. The		not have sufficient resources to handle a new connection. The
	Transport Converter may indicate in the Value field the suggested		Transport Converter may indicate in the Value field the suggested
	delay (in seconds) that the Client SHOULD wait before soliciting		delay (in seconds) that the Client SHOULD wait before soliciting
	the Transport Converter for a new proxied connection. A Value of		the Transport Converter for a new proxied connection. A Value of
	zero corresponds to a default delay of at least 30 seconds.		zero corresponds to a default delay of at least 30 seconds.
	o Network Failure (65): This error indicates that the Transport		o Network Failure (65): This error indicates that the Transport
	Converter is experiencing a network failure to relay the request.		Converter is experiencing a network failure to proxy the request.
	The Transport Converter MUST send this error code when it		The Transport Converter MUST send this error code when it
	experiences forwarding issues to relay a connection. The		experiences forwarding issues to proxy a connection. The
	Transport Converter may indicate in the Value field the suggested		Transport Converter may indicate in the Value field the suggested
	delay (in seconds) that the Client SHOULD wait before soliciting		delay (in seconds) that the Client SHOULD wait before soliciting
	the Transport Converter for a new proxied connection. A Value of		the Transport Converter for a new proxied connection. A Value of
	zero corresponds to a default delay of at least 30 seconds.		zero corresponds to a default delay of at least 30 seconds.
	o Connection Reset (96): This error indicates that the final		o Connection Reset (96): This error indicates that the final
	destination responded with an RST packet. The Value field MUST be		destination responded with an RST packet. The Value field MUST be
	set to zero.		set to zero.
	o Destination Unreachable (97): This error indicates that an ICMP		o Destination Unreachable (97): This error indicates that an ICMP
	skipping to change at page 26, line 35 ¶		skipping to change at page 27, line 35 ¶
	proxied message to be function of the scaling factor of the incoming		proxied message to be function of the scaling factor of the incoming
	connection.		connection.
	There is no benefit from a deployment viewpoint in enabling a Client		There is no benefit from a deployment viewpoint in enabling a Client
	of a Transport Converter to specifically request the utilization of		of a Transport Converter to specifically request the utilization of
	the WS option (Kind=3) with a specific scaling factor towards a		the WS option (Kind=3) with a specific scaling factor towards a
	remote Server. For this reason, a Transport Converter MUST ignore		remote Server. For this reason, a Transport Converter MUST ignore
	option Kind=3 if it appears in a Connect TLV. It MUST NOT announce		option Kind=3 if it appears in a Connect TLV. It MUST NOT announce
	it in a Supported TCP Extensions TLV.		it in a Supported TCP Extensions TLV.
	5.3. Selective Acknowledgements		5.3. Selective Acknowledgments
	Two distinct TCP options were defined to support selective		Two distinct TCP options were defined to support selective
	acknowledgements in [RFC2018]. This first one, SACK Permitted		acknowledgments in [RFC2018]. This first one, SACK Permitted
	(Kind=4), is used to negotiate the utilization of selective		(Kind=4), is used to negotiate the utilization of selective
	acknowledgements during the three-way handshake. The second one,		acknowledgments during the three-way handshake. The second one, SACK
	SACK (Kind=5), carries the selective acknowledgements inside regular		(Kind=5), carries the selective acknowledgments inside regular
	segments.		segments.
	The SACK Permitted option (Kind=4) MAY be advertised by a Transport		The SACK Permitted option (Kind=4) MAY be advertised by a Transport
	Converter in the Supported TCP Extensions TLV. Clients connected to		Converter in the Supported TCP Extensions TLV. Clients connected to
	this Transport Converter MAY include the SACK Permitted option in the		this Transport Converter MAY include the SACK Permitted option in the
	Connect TLV.		Connect TLV.
	The SACK option (Kind=5) cannot be used during the three-way		The SACK option (Kind=5) cannot be used during the three-way
	handshake. For this reason, a Transport Converter MUST ignore option		handshake. For this reason, a Transport Converter MUST ignore option
	Kind=5 if it appears in a Connect TLV. It MUST NOT announce it in a		Kind=5 if it appears in a Connect TLV. It MUST NOT announce it in a
	skipping to change at page 27, line 28 ¶		skipping to change at page 28, line 28 ¶
	could use to establish a connection to a remote server.		could use to establish a connection to a remote server.
	A Transport Converter MAY advertise the Timestamp option (Kind=8) in		A Transport Converter MAY advertise the Timestamp option (Kind=8) in
	the TCP Supported Extensions TLV. The clients connected to this		the TCP Supported Extensions TLV. The clients connected to this
	Transport Converter MAY include the Timestamp option in the Connect		Transport Converter MAY include the Timestamp option in the Connect
	TLV but without any timestamp.		TLV but without any timestamp.
	5.5. Multipath TCP		5.5. Multipath TCP
	The Multipath TCP options are defined in [RFC6824]. [RFC6824]		The Multipath TCP options are defined in [RFC6824]. [RFC6824]
	defines one variable length TCP option (Kind=30) that includes a		defines one variable length TCP option (Kind=30) that includes a sub-
	subtype field to support several Multipath TCP options. There are		type field to support several Multipath TCP options. There are
	several operational use cases where clients would like to use		several operational use cases where clients would like to use
	Multipath TCP through a Transport Converter [IETFJ16]. However, none		Multipath TCP through a Transport Converter [IETFJ16]. However, none
	of these use cases require the Client to specify the content of the		of these use cases require the Client to specify the content of the
	Multipath TCP option that the Transport Converter should send to a		Multipath TCP option that the Transport Converter should send to a
	remote server.		remote server.
	A Transport Converter which supports Multipath TCP conversion service		A Transport Converter which supports Multipath TCP conversion service
	MUST advertise the Multipath TCP option (Kind=30) in the Supported		MUST advertise the Multipath TCP option (Kind=30) in the Supported
	TCP Extensions TLV. Clients serviced by this Transport Converter may		TCP Extensions TLV. Clients serviced by this Transport Converter may
	include the Multipath TCP option in the Connect TLV but without any		include the Multipath TCP option in the Connect TLV but without any
	skipping to change at page 29, line 15 ¶		skipping to change at page 30, line 15 ¶
	Nevertheless, and in order to allow for a robust service, this		Nevertheless, and in order to allow for a robust service, this
	section describes how a Client can detect middlebox interference and		section describes how a Client can detect middlebox interference and
	stop using the Transport Converter affected by this interference.		stop using the Transport Converter affected by this interference.
	Internet measurements [IMC11] have shown that middleboxes can affect		Internet measurements [IMC11] have shown that middleboxes can affect
	the deployment of TCP extensions. In this section, we only discuss		the deployment of TCP extensions. In this section, we only discuss
	the middleboxes that modify SYN and SYN+ACK packets since the Convert		the middleboxes that modify SYN and SYN+ACK packets since the Convert
	Protocol places its messages in such packets.		Protocol places its messages in such packets.
	Consider a middlebox that removes the SYN payload. The Client can		Consider a middlebox that removes the SYN payload. The Client can
	detect this problem by looking at the acknowledgement number field of		detect this problem by looking at the acknowledgment number field of
	the SYN+ACK returned by the Transport Converter. The Client MUST		the SYN+ACK returned by the Transport Converter. The Client MUST
	stop to use this Transport Converter given the middlebox		stop to use this Transport Converter given the middlebox
	interference.		interference.
	Consider now a middlebox that drops SYN/ACKs with a payload. The		Consider now a middlebox that drops SYN/ACKs with a payload. The
	Client won't be able to establish a connection via the Transport		Client won't be able to establish a connection via the Transport
	Converter.		Converter.
	The case of a middlebox that removes the payload of SYN+ACKs (but not		The case of a middlebox that removes the payload of SYN+ACKs (but not
	the payload of SYN) can be detected by a Client. This is hinted by		the payload of SYN) can be detected by a Client. This is hinted by
	skipping to change at page 37, line 21 ¶		skipping to change at page 38, line 21 ¶
	[Fukuda2011]		[Fukuda2011]
	Fukuda, K., "An Analysis of Longitudinal TCP Passive		Fukuda, K., "An Analysis of Longitudinal TCP Passive
	Measurements (Short Paper)", Traffic Monitoring and		Measurements (Short Paper)", Traffic Monitoring and
	Analysis. TMA 2011. Lecture Notes in Computer Science, vol		Analysis. TMA 2011. Lecture Notes in Computer Science, vol
	6613. , 2011.		6613. , 2011.
	[HotMiddlebox13b]		[HotMiddlebox13b]
	Detal, G., Paasch, C., and O. Bonaventure, "Multipath in		Detal, G., Paasch, C., and O. Bonaventure, "Multipath in
	the Middle(Box)", HotMiddlebox'13 , December 2013,		the Middle(Box)", HotMiddlebox'13 , December 2013,
	<http://inl.info.ucl.ac.be/publications/		<http://inl.info.ucl.ac.be/publications/multipath-
	multipath-middlebox>.		middlebox>.
	[I-D.arkko-arch-low-latency]		[I-D.arkko-arch-low-latency]
	Arkko, J. and J. Tantsura, "Low Latency Applications and		Arkko, J. and J. Tantsura, "Low Latency Applications and
	the Internet Architecture", draft-arkko-arch-low-		the Internet Architecture", draft-arkko-arch-low-
	latency-02 (work in progress), October 2017.		latency-02 (work in progress), October 2017.
	[I-D.boucadair-mptcp-plain-mode]		[I-D.boucadair-mptcp-plain-mode]
	Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel,		Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel,
	D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R.,		D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R.,
	Vinapamula, S., Seo, S., Cloetens, W., Meyer, U.,		Vinapamula, S., Seo, S., Cloetens, W., Meyer, U.,
	skipping to change at page 41, line 6 ¶		skipping to change at page 42, line 6 ¶
	servers like web servers. The Convert protocol is different		servers like web servers. The Convert protocol is different
	and as discussed in RFC7413, there are different ways to		and as discussed in RFC7413, there are different ways to
	protect from such attacks. Instead of using a TFO cookie		protect from such attacks. Instead of using a TFO cookie
	inside the TCP options, which consumes precious space in the		inside the TCP options, which consumes precious space in the
	extended TCP header, this version supports the utilization of a		extended TCP header, this version supports the utilization of a
	Cookie that is placed in the SYN payload. This provides the		Cookie that is placed in the SYN payload. This provides the
	same level of protection as a TFO Cookie in environments were		same level of protection as a TFO Cookie in environments were
	such protection is required.		such protection is required.
	* the Bootstrap procedure has been simplified based on feedback		* the Bootstrap procedure has been simplified based on feedback
	from implementers		from implementors
	* Error messages are not included in RST segments anymore but		* Error messages are not included in RST segments anymore but
	sent in the bytestream. Implementors have indicated that		sent in the bytestream. Implementors have indicated that
	processing such segments on clients was difficult on some		processing such segments on clients was difficult on some
	platforms. This change simplifies client implementations.		platforms. This change simplifies client implementations.
	* Many minor editorial changes to clarify the text based on		* Many minor editorial changes to clarify the text based on
	implementors feedback.		implementors feedback.
	o 05 to -06: Many clarifications to integrate the comments from the		o 05 to -06: Many clarifications to integrate the comments from the
	skipping to change at page 41, line 47 ¶		skipping to change at page 42, line 47 ¶
	* Nits		* Nits
	* Added Appendix A on example Socket API changes		* Added Appendix A on example Socket API changes
	o 08:		o 08:
	* Added short discussion on the termination of connections		* Added short discussion on the termination of connections
	o 09:		o 09:
	* Various to comments received during last call		* Address various comments received during last call
	Appendix B. Example Socket API Changes to Support the 0-RTT Convert		Appendix B. Example Socket API Changes to Support the 0-RTT Convert
	Protocol		Protocol
	B.1. Active Open (Client Side)		B.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.
	skipping to change at page 43, line 42 ¶		skipping to change at page 44, line 42 ¶
	Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added to		Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added to
	provide the same behavior on a per socket basis. This enables a		provide the same behavior on a per socket basis. This enables a
	single host to support both servers that require the TFO cookie and		single host to support both servers that require the TFO cookie and
	servers that do not use it.		servers that do not use it.
	Appendix C. Some Design Considerations		Appendix C. Some Design Considerations
	Several implementors expressed concerns about the use of TFO. As a		Several implementors expressed concerns about the use of TFO. As a
	reminder, the TFO Cookie protects from some attack scenarios that		reminder, the TFO Cookie protects from some attack scenarios that
	affect open servers like web servers. The Convert protocol is		affect open servers like web servers. The Convert protocol is
	different and as discussed in RFC7413, there are different ways to		different and, as discussed in RFC7413, there are different ways to
	protect from such attacks. Instead of using a TFO cookie inside the		protect from such attacks. Instead of using a TFO cookie inside the
	TCP options, which consumes precious space in the extended TCP		TCP options, which consumes precious space in the extended TCP
	header, the Convert protocol supports the utilization of a Cookie		header, the Convert protocol supports the utilization of a Cookie
	that is placed in the SYN payload. This provides the same level of		that is placed in the SYN payload. This provides the same level of
	protection as a TFO Cookie in environments were such protection is		protection as a TFO Cookie in environments were such protection is
	required.		required.
	Error messages are not included in RST segments but sent in the		Error messages are not included in RST segments but sent in the
	bytestream. Implementors have indicated that processing such		bytestream. Implementors have indicated that processing such
	segments on clients was difficult on some platforms. This change		segments on clients was difficult on some platforms. This change
	skipping to change at page 46, line 33 ¶		skipping to change at page 47, line 33 ¶
	Server [RFC8305].		Server [RFC8305].
	A fourth difference is that the Convert protocol only allows the		A fourth difference is that the Convert protocol only allows the
	client to specify the address/port of the destination server and not		client to specify the address/port of the destination server and not
	a DNS name. We evaluated an alternate design for the Connect TLV		a DNS name. We evaluated an alternate design for the Connect TLV
	that included the DNS name of the remote peer instead of its IP		that included the DNS name of the remote peer instead of its IP
	address as in SOCKS [RFC1928]. However, that design was not adopted		address as in SOCKS [RFC1928]. However, that design was not adopted
	because it induces both an extra load and increased delays on the		because it induces both an extra load and increased delays on the
	Transport Converter to handle and manage DNS resolution requests.		Transport Converter to handle and manage DNS resolution requests.
	Acknowledgements		Acknowledgments
	Although they could disagree with the contents of the document, we		Although they could disagree with the contents of the document, we
	would like to thank Joe Touch and Juliusz Chroboczek whose comments		would like to thank Joe Touch and Juliusz Chroboczek whose comments
	on the MPTCP mailing list have forced us to reconsider the design of		on the MPTCP mailing list have forced us to reconsider the design of
	the solution several times.		the solution several times.
	We would like to thank Raphael Bauduin, Stefano Secci, Anandatirtha		We would like to thank Raphael Bauduin, Stefano Secci, Anandatirtha
	Nandugudi and Gregory Vander Schueren for their help in preparing		Nandugudi and Gregory Vander Schueren for their help in preparing
	this document. Nandini Ganesh provided valuable feedback about the		this document. Nandini Ganesh provided valuable feedback about the
	handling of TFO and the error codes. Yuchung Cheng and Praveen		handling of TFO and the error codes. Yuchung Cheng and Praveen
	skipping to change at page 48, line 25 ¶		skipping to change at page 49, line 25 ¶
	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
			Clos Courtel
	Rennes 35000		Rennes 35000
	France		France
	Email: mohamed.boucadair@orange.com		Email: mohamed.boucadair@orange.com
	Sri Gundavelli		Sri Gundavelli
	Cisco		Cisco
	Email: sgundave@cisco.com		Email: sgundave@cisco.com
End of changes. 48 change blocks.
	111 lines changed or deleted		140 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/