draft-ietf-tcpm-converters-09.txt		draft-ietf-tcpm-converters-10.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: January 23, 2020 Orange		Expires: February 2, 2020 Orange
	S. Gundavelli		S. Gundavelli
	Cisco		Cisco
	S. Seo		S. Seo
	Korea Telecom		Korea Telecom
	B. Hesmans		B. Hesmans
	Tessares		Tessares
	July 22, 2019		August 01, 2019
	0-RTT TCP Convert Protocol		0-RTT TCP Convert Protocol
	draft-ietf-tcpm-converters-09		draft-ietf-tcpm-converters-10
	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 January 23, 2020.		This Internet-Draft will expire on February 2, 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 34 ¶		skipping to change at page 2, line 34 ¶
	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 . . . . . . . . . . . . . . . . . . . 8
	3.3. Sample Examples of Outgoing Converter-Assisted Multipath		3.3. Sample Examples of Outgoing Converter-Assisted Multipath
	TCP Connections . . . . . . . . . . . . . . . . . . . . . 12		TCP Connections . . . . . . . . . . . . . . . . . . . . . 12
	3.4. Sample Example of Incoming Converter-Assisted Multipath		3.4. Sample Example of Incoming Converter-Assisted Multipath
	TCP Connection . . . . . . . . . . . . . . . . . . . . . 13		TCP Connection . . . . . . . . . . . . . . . . . . . . . 13
	4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 14		4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 15
	4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 15		4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 15
	4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 16		4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 16
	4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 16		4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 16
	4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16		4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16
	4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17		4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17
	4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 17		4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 18
	4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 18		4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 19
	4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 20		4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 21
	4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 21		4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 21
	4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 21		4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 22
	5. Compatibility of Specific TCP Options with the Conversion		5. Compatibility of Specific TCP Options with the Conversion
	Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 25		5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 25
	5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 26		5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 26
	5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 26		5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 26
	5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 26		5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 27
	5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 27		5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 27
	5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 27		5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 27
	5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 28		5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 28
	5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 28		5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 28
	5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 28		5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 28
	6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 28		6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 28
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 29		7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 29		7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 29
	7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 30		7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 30
	7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 31		7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 31
	7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 31		7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 31
	7.5. Multipath TCP-specific Considerations . . . . . . . . . . 31		7.5. Multipath TCP-specific Considerations . . . . . . . . . . 32
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	8.1. Convert Service Port Number . . . . . . . . . . . . . . . 32		8.1. Convert Service Port Number . . . . . . . . . . . . . . . 32
	8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 32		8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 33
	8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 32		8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 33
	8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 33		8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 33
	8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 33		8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 34
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	9.1. Normative References . . . . . . . . . . . . . . . . . . 34		9.1. Normative References . . . . . . . . . . . . . . . . . . 35
	9.2. Informative References . . . . . . . . . . . . . . . . . 36		9.2. Informative References . . . . . . . . . . . . . . . . . 37
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 39		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40
	Appendix B. Example Socket API Changes to Support the 0-RTT		Appendix B. Example Socket API Changes to Support the 0-RTT
	Convert Protocol . . . . . . . . . . . . . . . . . . 41		Convert Protocol . . . . . . . . . . . . . . . . . . 42
	B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 41		B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 42
	B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 42		B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 42
	Appendix C. Differences with SOCKSv5 . . . . . . . . . . . . . . 43		Appendix C. Some Design Considerations . . . . . . . . . . . . . 43
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44		Appendix D. Differences with SOCKSv5 . . . . . . . . . . . . . . 44
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 45		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
	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 Acknowledgements [RFC2018] or large
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 13 ¶
	Configuration means are outside the scope of this document.		Configuration means are outside the scope of this document.
	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 provides a		protocol described in this document. Appendix C records some
	comparison with SOCKS proxies that are already used to deploy		considerations that impacted the design of the protocol. Appendix D
	Multipath TCP in some cellular networks (Section 2.2 of [RFC8041]).		provides a comparison with SOCKS proxies that are already used to
			deploy Multipath TCP in some cellular networks (Section 2.2 of
			[RFC8041]).
	2. Conventions and Definitions		2. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The information shown between brackets in the figures refers to		The information shown between brackets in the figures refers to
	Convert Protocol messages described in Section 4.		Convert Protocol messages described in Section 4.
			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;
	skipping to change at page 6, line 45 ¶		skipping to change at page 7, line 5 ¶
	A Transport Converter is a network function that relays all data		A Transport Converter is a network function that relays 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" refers to a software instance embedded on a host that can		|
	reach a Transport Converter via its customer-facing interface. The		:
	"Client" can initiate connections via a Transport Converter (referred		|
	to as outgoing connections). Also, the "Client" can accept incoming		+------------+
	connections via a Transport Converter (referred to as incoming		Client <- upstream ->| Transport |<- downstream ->Server
	connections). Nevertheless, and unless this is explicitly stated,		| Converter |
	the description assumes outgoing connections as default.		+------------+
			|
	|		customer-facing interface : Internet-facing interface
	:		|
	|
	+------------+
	client <- upstream ->| Transport |<- downstream ->server
	| Converter |
	+------------+
	|
	customer-facing interface : Internet-facing interface
	|
	Figure 1: A Transport Converter Relays Data between Pairs of TCP		Figure 1: A Transport Converter Relays Data between Pairs of TCP
	Connections		Connections
			"Client" refers to a software instance embedded on a host that can
			reach a Transport Converter via its customer-facing interface. The
			"Client" can initiate connections via a Transport Converter (referred
			to as outgoing connections (Section 3.3)). Also, the "Client" can
			accept incoming connections via a Transport Converter (referred to as
			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
	parties. Nevertheless, this document focuses on the single		parties. Nevertheless, this document focuses on the single
	administrative deployment case where the entity offering the		administrative deployment case where the entity offering the
	connectivity service to a client is also the entity which owns and		connectivity service to a client is also the entity which owns and
	operates the Transport Converter.		operates the Transport Converter.
	A Transport Converter can be embedded in a standalone device or be		A Transport Converter can be embedded in a standalone device or be
	activated as a service on a router. How such function is enabled is		activated as a service on a router. How such function is enabled is
	deployment-specific. A sample deployment is depicted in Figure 2.		deployment-specific. A sample deployment is depicted in Figure 2.
	skipping to change at page 9, line 38 ¶		skipping to change at page 9, line 40 ¶
	used), the Client initiates a connection towards the Transport		used), the Client initiates a connection towards the Transport
	Converter and indicates the IP address and port number of the Server		Converter and indicates the IP address and port number of the Server
	within the connection establishment packet. Doing so enables the		within the connection establishment packet. Doing so enables the
	Transport Converter to immediately initiate a connection towards that		Transport Converter to immediately initiate a connection towards that
	Server, without experiencing an extra delay. The Transport Converter		Server, without experiencing an extra delay. The Transport Converter
	waits until the receipt of the confirmation that the Server agrees to		waits until the receipt of the confirmation that the Server agrees to
	establish the connection before confirming it to the Client.		establish the connection before confirming it to the Client.
	The Client places the destination address and port number of the		The Client places the destination address and port number of the
	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. In accordance with		minimize connection establishment delays. The Transport Converter
	[RFC1919], the Transport Converter maintains two connections that are		maintains two connections that are combined together:
	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.
	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		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
			sharing modes as discussed in Section 5.4 of
			[I-D.nam-mptcp-deployment-considerations]. Which behavior to use by
			a Transport Converter is deployment-specific. If address sharing
			mode is enabled, the Transport Converter MUST adhere to REQ-2 of
			[RFC6888] which implies a default "IP address pooling" behavior of
			"Paired" (as defined in Section 4.1 of [RFC4787]) must be supported.
			This behavior is meant to avoid breaking applications that depend on
			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.
	Transport		Transport
	Client Converter Server		Client Converter Server
	| | |		| | |
	|SYN [->Server:port]| SYN |		|SYN [->Server:port]| SYN |
	|------------------>|--------------------->|		|------------------>|--------------------->|
	|<------------------|<---------------------|		|<------------------|<---------------------|
	| SYN+ACK [ ] | SYN+ACK |		| SYN+ACK [ ] | SYN+ACK |
	| | |		| ... | ... |
	Figure 5: Establishment of an Outgoing TCP Connection Through a		Figure 5: Establishment of an Outgoing TCP Connection Through a
	Transport Converter (1)		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. This information is sent at the beginning of the bytestream,		Server.
	either directly in the SYN+ACK or in a subsequent packet. For
	graphical reasons, the figures in this section show that the
	Transport Converter returns this information in the SYN+ACK packet.
	An implementation could also place this information in a packet that
	it sent shortly after the SYN+ACK.
	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 is successful,
	the Converter inserts the source IP address and source port number in		the Converter inserts the source IP address and source port number in
	the SYN packet, rewrites the source IP address to one of its IP		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 (i.e., only when the Converter is
	in accordance with any information stored locally. That SYN is then		configured in an address sharing mode), the destination IP address
	forwarded to the next hop. SYN-ACK and ACK will be then exchanged		and port number in accordance with any information stored locally.
	between the Client, the Converter, and remote host to confirm the		That SYN is then forwarded to the next hop. SYN+ACK and ACK will be
	establishment of the connection.		then exchanged between the Client, the Converter, and remote host to
			confirm the establishment of 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 |
	| ... | ... |		| ... | ... |
	Figure 6: Establishment of an Incoming TCP Connection Through a		Figure 6: Establishment of an Incoming TCP Connection Through a
	Transport Converter		Transport Converter
	A Transport Converter MAY operate in address preservation or address
	sharing modes as discussed in Section 5.4 of
	[I-D.nam-mptcp-deployment-considerations]. Which behavior to use by
	a Transport Converter is deployment-specific. If address sharing
	mode is enabled, the Transport Converter MUST adhere to REQ-2 of
	[RFC6888] which implies a default "IP address pooling" behavior of
	"Paired" (as defined in Section 4.1 of [RFC4787]) must be supported.
	This behavior is meant to avoid breaking applications that depend on
	the source address remaining constant.
	Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry		Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry
	data inside its payload but forbids the receiver from delivering it		data inside its payload but forbids the receiver from delivering it
	to the application until completion of the three-way-handshake. To		to the application until completion of the three-way-handshake. To
	enable applications to exchange data in a TCP handshake, this		enable applications to exchange data in a TCP handshake, this
	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
	skipping to change at page 12, line 4 ¶		skipping to change at page 11, line 51 ¶
	the payload of SYN packets without creating additional security risks		the payload of SYN packets without creating additional security risks
	such as a network where addresses cannot be spoofed and the Transport		such as a network where addresses cannot be spoofed and the Transport
	Converter only serves a set of hosts that are identified by these		Converter only serves a set of hosts that are 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.
			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 a 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 teardown 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
	skipping to change at page 12, line 40 ¶		skipping to change at page 12, line 40 ¶
	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
	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		Note that, if the TCP connection fails for some reason, the Converter
	tears down the Multipath TCP connection by transmitting a		tears down the Multipath TCP connection by transmitting a
	MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with		MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with
	the transmission of DATA_FINs, the Converter terminates the TCP		the transmission of DATA_FINs, the Converter terminates the TCP
	connection by using FIN segments.		connection by using FIN segments. As a side note, given that with
			Multipath TCP, RST only has the scope of the subflow and will only
			close the concerned subflow but not affect the remaining subflows,
			the Converter does not terminate the TCP connection upon receipt of
			an RST over a Multipath subflow.
	Figure 8 considers a Server that supports Multipath TCP. In this		Figure 8 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 13, line 34 ¶		skipping to change at page 13, line 38 ¶
	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
	from remote hosts, the Client may use PCP [RFC6887] to instruct the		from remote hosts, the Client may use PCP [RFC6887] to instruct the
	skipping to change at page 14, line 18 ¶		skipping to change at page 14, line 23 ¶
	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 an entry
	is found, the Converter inserts an MP_CAPABLE option and Connect TLV		is 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		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 describes the messages that are exchanged between a		This section defines the Convert protocol (Convert, for short)
	Client and a Transport Converter.		messages that are exchanged between a Client and a Transport
			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 protocol (Convert, for short) messages from Clients.		for Convert messages from Clients.
	Clients send packets that are eligible to the conversion service to		Clients send packets bound to connections eligible to the conversion
	the provisioned Transport Converter using TBA as destination port		service to the provisioned Transport Converter using TBA as
	number. Additional information is supplied by Clients to the		destination port number. This applies for both control and data
			messages. Additional information is supplied by Clients to the
	Transport Converter by means of Convert messages as detailed in the		Transport Converter by means of Convert messages as detailed in the
	following sub-sections.		following 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. A Convert message starts with a 32 bits long fixed		bytestream. All Convert messages start 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).
	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.
	skipping to change at page 16, line 19 ¶		skipping to change at page 16, line 31 ¶
	The Convert protocol uses variable length messages that are encoded		The Convert protocol uses variable length messages that are encoded
	using the generic TLV format depicted in Figure 11.		using the generic TLV format depicted in Figure 11.
	The length of all TLVs used by the Convert protocol is always a		The length of all TLVs used by the Convert protocol is always a
	multiple of four bytes. All TLVs are aligned on 32 bits boundaries.		multiple of four bytes. All TLVs are aligned on 32 bits boundaries.
	All TLV fields are encoded using the network byte order.		All TLV fields are encoded using the network byte order.
	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
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| Type | Length | (optional) Value ... |		| Type | Length | Value ... |
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| ... Value |		// ... (optional) Value //
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 11: Convert Generic TLV Format		Figure 11: Convert Generic TLV Format
	The Length field is expressed in units of 32 bits words. If		The Length field covers Type, Length, and Value fields. It is
	necessary, Value MUST be padded with zeroes so that the length of the		expressed in units of 32 bits words. If necessary, Value MUST be
	TLV is a multiple of 32 bits.		padded with zeroes so that the length of the TLV is a multiple of 32
			bits.
	A given TLV MUST only appear once on a connection. If two or more		A given TLV MUST only appear once on a connection. If two or more
	instances of the same TLV are exchanged over a Convert connection,		instances of the same TLV are exchanged over a Convert connection,
	the associated TCP connections MUST be closed.		the associated TCP connections MUST be closed.
	4.2.2. Summary of Supported Convert TLVs		4.2.2. Summary of Supported Convert TLVs
	This document specifies the following Convert TLVs:		This document specifies the following Convert TLVs:
	+------+-----+----------+------------------------------------------+		+------+-----+----------+------------------------------------------+
	skipping to change at page 19, line 15 ¶		skipping to change at page 19, line 41 ¶
	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
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| Type=0xA | Length | Remote Peer Port |		| Type=0xA | Length | Remote Peer Port |
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| |		| |
	| Remote Peer IP Address (128 bits) |		| Remote Peer IP Address (128 bits) |
	| |		| |
	| |		| |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| TCP Options (Variable) |		/ TCP Options (Variable) /
	| ... |		/ ... /
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	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 subfield, i.e.,
	skipping to change at page 20, line 37 ¶		skipping to change at page 21, line 18 ¶
	Converter to send to the Client the extended TCP header that was		Converter to send to the Client the extended TCP header that was
	returned by the Server in the SYN+ACK packet. This TLV is only sent		returned by the Server in the SYN+ACK packet. This TLV is only sent
	if the Client sent a Connect TLV to request the establishment of a		if the Client sent a Connect TLV to request the establishment of a
	connection.		connection.
	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
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| Type=0x14 | Length | Unassigned |		| Type=0x14 | Length | Unassigned |
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| Returned Extended TCP header |		/ Returned Extended TCP header /
	| ... |		/ ... /
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 17: The Extended TCP Header TLV		Figure 17: The Extended TCP Header TLV
	The Returned Extended TCP header field is a copy of the extended		The Returned Extended TCP header field is a copy of the extended
	header that was received in the SYN+ACK by the Transport Converter.		header that was received in the SYN+ACK by the Transport Converter.
	The Unassigned field MUST be set to zero by the transmitter and		The Unassigned field MUST be set to zero by the sender and ignored by
	ignored by the receiver. These bits are available for future use		the receiver. These bits are available for future use [RFC8126].
	[RFC8126].
	4.2.7. The Cookie TLV		4.2.7. The Cookie TLV
	The Cookie TLV (Figure 18 is an optional TLV which use is similar to		The Cookie TLV (Figure 18 is an optional TLV which use is similar to
	the TCP Fast Open Cookie [RFC7413]. A Transport Converter may want		the TCP Fast Open Cookie [RFC7413]. A Transport Converter may want
	to verify that a Client can receive the packets that it sends to		to verify that a Client can receive the packets that it sends to
	prevent attacks from spoofed addresses. This verification can be		prevent attacks from spoofed addresses. This verification can be
	done by using a Cookie that is bound to, for example, the IP		done by using a Cookie that is bound to, for example, the IP
	address(es) of the Client. This Cookie can be configured on the		address(es) of the Client. This Cookie can be configured on the
	Client by means that are outside of this document or provided by the		Client by means that are outside of this document or provided by the
	skipping to change at page 21, line 41 ¶		skipping to change at page 22, line 17 ¶
	to reestablish a new connection to the Transport Converter that		to reestablish a new connection to the Transport Converter that
	includes the Cookie TLV.		includes the Cookie TLV.
	The format of the Cookie TLV is shown in Figure 18.		The format of the Cookie TLV is shown in Figure 18.
	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
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| Type=0x16 | Length | Zero |		| Type=0x16 | Length | Zero |
	+---------------+---------------+-------------------------------+		+---------------+---------------+-------------------------------+
	| Opaque Cookie |		/ Opaque Cookie /
	| ... |		/ ... /
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 18: The Cookie TLV		Figure 18: The Cookie TLV
	4.2.8. Error TLV		4.2.8. Error TLV
	The Error TLV (Figure 19) is meant to provide information about some		The Error TLV (Figure 19) is meant to provide information about some
	errors that occurred during the processing of a Convert message.		errors that occurred during the processing of a Convert message.
	This TLV has a variable length. It appears after the Convert fixed-		This TLV has a variable length. Upon reception of an Error TLV, a
	header in the bytestream returned by the Transport Converter. Upon		Client MUST close the associated connection.
	reception of an Error TLV, a Client MUST close the associated
	connection.
	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
	+---------------+---------------+----------------+--------------+		+---------------+---------------+----------------+--------------+
	| Type=0x1E | Length | Error Code | Value |		| Type=0x1E | Length | Error Code | Value |
	+---------------+---------------+----------------+--------------+		+---------------+---------------+----------------+--------------+
			// ... (optional) Value //
			+---------------------------------------------------------------+
	Figure 19: The Error TLV		Figure 19: The Error TLV
	Different types of errors can occur while processing Convert		Different types of errors can occur while processing Convert
	messages. Each error is identified by an Error Code represented as		messages. Each error is identified by an Error Code represented as
	an unsigned integer. Four classes of error codes are defined:		an unsigned integer. Four classes of error codes are defined:
	o Message validation and processing errors (0-31 range): returned		o Message validation and processing errors (0-31 range): returned
	upon reception of an invalid message (including valid messages but		upon reception of an invalid message (including valid messages but
	with invalid or unknown TLVs).		with invalid or unknown TLVs).
	skipping to change at page 29, line 15 ¶		skipping to change at page 29, line 24 ¶
	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 acknowledgement 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 the		The case of a middlebox that removes the payload of SYN+ACKs (but not
	payload of SYN) can be detected by a Client. This is hinted by the		the payload of SYN) can be detected by a Client. This is hinted by
	absence of an Error or Extended TCP Header TLV in a response. If an		the absence of an Error or Extended TCP Header TLV in a response. If
	Error was returned by the Transport Converter, a message to close the		an Error was returned by the Transport Converter, a message to close
	connection would normally follow from the Converter. If no such		the connection would normally follow from the Converter. If no such
	message is received, the Client may continue to use this Converter.		message is received, the Client may continue to use this Converter.
	As explained in [RFC7413], some CGNs (Carrier Grade NATs) can affect		As explained in [RFC7413], some CGNs (Carrier Grade NATs) can affect
	the operation of TFO if they assign different IP addresses to the		the operation of TFO if they assign different IP addresses to the
	same end host. Such CGNs could affect the operation of the cookie		same end host. Such CGNs could affect the operation of the cookie
	validation used by the Convert Protocol. As a reminder CGNs, enabled		validation used by the Convert Protocol. As a reminder CGNs, enabled
	on the path between a Client and a Transport Converter, must adhere		on the path between a Client and a Transport Converter, must adhere
	to the address preservation defined in [RFC6888]. See also the		to the address preservation defined in [RFC6888]. See also the
	discussion in Section 7.1 of [RFC7413].		discussion in Section 7.1 of [RFC7413].
	skipping to change at page 43, line 5 ¶		skipping to change at page 43, line 37 ¶
	However, this configuration is system-wide. This is convenient for		However, this configuration is system-wide. This is convenient for
	typical Transport Converter deployments where no other applications		typical Transport Converter deployments where no other applications
	relying on TFO are collocated on the same device.		relying on TFO are collocated on the same device.
	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. Differences with SOCKSv5		Appendix C. Some Design Considerations
			Several implementors expressed concerns about the use of TFO. As a
			reminder, the TFO Cookie protects from some attack scenarios that
			affect open servers like web servers. The Convert protocol is
			different and as discussed in RFC7413, there are different ways to
			protect from such attacks. Instead of using a TFO cookie inside the
			TCP options, which consumes precious space in the extended TCP
			header, the Convert protocol supports the utilization of a Cookie
			that is placed in the SYN payload. This provides the same level of
			protection as a TFO Cookie in environments were such protection is
			required.
			Error messages are not included in RST segments but sent in the
			bytestream. Implementors have indicated that processing such
			segments on clients was difficult on some platforms. This change
			simplifies client implementations.
			Appendix D. Differences with SOCKSv5
	At a first glance, the solution proposed in this document could seem		At a first glance, the solution proposed in this document could seem
	similar to the SOCKS v5 protocol [RFC1928] which is used to proxy TCP		similar to the SOCKS v5 protocol [RFC1928] which is used to proxy TCP
	connections. The Client creates a connection to a SOCKS proxy,		connections. The Client creates a connection to a SOCKS proxy,
	exchanges authentication information and indicates the destination		exchanges authentication information and indicates the destination
	address and port of the final server. At this point, the SOCKS proxy		address and port of the final server. At this point, the SOCKS proxy
	creates a connection towards the final server and relays all data		creates a connection towards the final server and relays all data
	between the two proxied connections. The operation of an		between the two proxied connections. The operation of an
	implementation based on SOCKSv5 is illustrated in Figure 23.		implementation based on SOCKSv5 is illustrated in Figure 23.
End of changes. 46 change blocks.
	105 lines changed or deleted		132 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/