draft-ietf-tcpm-converters-05.txt   draft-ietf-tcpm-converters-06.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: August 11, 2019 Orange Expires: September 7, 2019 Orange
S. Gundavelli S. Gundavelli
Cisco Cisco
S. Seo S. Seo
Korea Telecom Korea Telecom
B. Hesmans B. Hesmans
Tessares Tessares
February 07, 2019 March 06, 2019
0-RTT TCP Convert Protocol 0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-05 draft-ietf-tcpm-converters-06
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 August 11, 2019. This Internet-Draft will expire on September 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 6 3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 6
3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 8 3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 8
3.3. Sample Examples of Outgoing Converter-Assisted Multipath 3.3. Sample Examples of Outgoing Converter-Assisted Multipath
TCP Connections . . . . . . . . . . . . . . . . . . . . . 11 TCP Connections . . . . . . . . . . . . . . . . . . . . . 11
3.4. Sample Example of Incoming Converter-Assisted Multipath 3.4. Sample Example of Incoming Converter-Assisted Multipath
TCP Connection . . . . . . . . . . . . . . . . . . . . . 12 TCP Connection . . . . . . . . . . . . . . . . . . . . . 13
4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 13 4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 14
4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 14 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 14
4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 14 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 15
4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 15 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16
4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 16 4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17
4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 16 4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 17
4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 17 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 18
4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 19 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 20
4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 19 4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 20
4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 20 4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 21
5. Compatibility of Specific TCP Options with the Conversion 5. Compatibility of Specific TCP Options with the Conversion
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 23 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 24
5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 24 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 25
5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 24 5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 25
5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 26
5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 25 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 26
5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 25 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 26
5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 26 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 27
5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 26 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 27
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 26 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 27 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 28
7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 28 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 29
7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 28 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 30
7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 28 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 30
7.5. Multipath TCP-specific Considerations . . . . . . . . . . 29 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8.1. Convert Service Port Number . . . . . . . . . . . . . . . 29 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 31
8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 30 8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 31
8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 30 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 31
8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 30 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 32
8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 31 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 34
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Differences with SOCKSv5 . . . . . . . . . . . . . . 39 Appendix A. Differences with SOCKSv5 . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
Transport protocols like TCP evolve regularly [RFC7414]. TCP has Transport protocols like TCP evolve regularly [RFC7414]. TCP has
been improved in different ways. Some improvements such as changing been improved in different ways. Some improvements such as changing
the initial window size [RFC6928] or modifying the congestion control the initial window size [RFC6928] or modifying the congestion control
scheme can be applied independently on clients and servers. Other scheme can be applied independently on clients and servers. Other
improvements such as Selective Acknowledgements [RFC2018] or large improvements such as Selective Acknowledgements [RFC2018] or large
windows [RFC7323] require a new TCP option or to change the semantics windows [RFC7323] require a new TCP option or to change the semantics
of some fields in the TCP header. These modifications must be of some fields in the TCP header. These modifications must be
skipping to change at page 5, line 16 skipping to change at page 5, line 16
they enable new TCP extensions to be used on a subset of the path they enable new TCP extensions to be used on a subset of the path
between endpoints, which encourages the deployment of these between endpoints, which encourages the deployment of these
extensions. Furthermore, the Transport Converter allows the client extensions. Furthermore, the Transport Converter allows the client
and the server to directly negotiate TCP options for the sake of and the server to directly negotiate TCP options for the sake of
native support along the full path. native support along the full path.
The Convert Protocol is a generic mechanism to provide 0-RTT The Convert Protocol is a generic mechanism to provide 0-RTT
conversion service. As a sample applicability use case, this conversion service. As a sample applicability use case, this
document specifies how the Convert Protocol applies for Multipath document specifies how the Convert Protocol applies for Multipath
TCP. It is out of scope of this document to provide a comprehensive TCP. It is out of scope of this document to provide a comprehensive
list of all potential conversion services. Applicability document list of all potential conversion services. Applicability documents
may defined in the future. may be defined in the future.
This document does not assume that all the traffic is eligible to the This document does not assume that all the traffic is eligible to the
network-assisted conversion service. Only a subset of the traffic network-assisted conversion service. Only a subset of the traffic
will be forwarded to a Transport Converter according to a set of will be forwarded to a Transport Converter according to a set of
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 that a client is configured with one or a list This document assumes an explicit model in which a client is
of Transport Converters (statically or through protocols such as configured with one or a list of Transport Converters (statically or
[I-D.boucadair-tcpm-dhc-converter]). Configuration means are outside through protocols such as [I-D.boucadair-tcpm-dhc-converter]).
the scope of this document. Configuration means are outside the scope of this document.
This document is organized as follows. We first provide a brief This document is organized as follows. We first provide a brief
explanation of the operation of Transport Converters in Section 3. explanation of the operation of Transport Converters in Section 3.
We describe the Convert Protocol in Section 4. We discuss in We describe the Convert Protocol in Section 4. We discuss in
Section 5 how Transport Converters can be used to support different Section 5 how Transport Converters can be used to support different
TCP extensions. We then discuss the interactions with middleboxes TCP extensions. We then discuss the interactions with middleboxes
(Section 6) and the security considerations (Section 7). (Section 6) and the security considerations (Section 7).
Appendix A provides a comparison with SOCKS proxies that are already Appendix A provides a comparison with SOCKS proxies that are already
used to deploy Multipath TCP in some cellular networks (Section 2.2 used to deploy Multipath TCP in some cellular networks (Section 2.2
skipping to change at page 7, line 23 skipping to change at page 7, line 23
+---------+ +---------+
|Transport| |Transport|
|Converter| |Converter|
+---------+ +---------+
Figure 2: A Transport Converter can be installed anywhere in the Figure 2: A Transport Converter can be installed anywhere in the
network network
The architecture assumes that new software will be installed on the The architecture assumes that new software will be installed on the
Client hosts to interact with one or more Transport Converters. Client hosts to interact with one or more Transport Converters.
Further, the architecture allows for making use of TCP new extensions Further, the architecture allows for making use of new TCP extensions
even if those are not supported by a given server. even if those are not supported by a given server.
The Client is configured, through means that are outside the scope of The Client is configured, through means that are outside the scope of
this document, with the names and/or the addresses of one or more this document, with the names and/or the addresses of one or more
Transport Converters and the TCP extensions that they support. The Transport Converters and the TCP extensions that they support. The
procedure for selecting a Transport Converter among a list of procedure for selecting a Transport Converter among a list of
configured Transport Converters is outside the scope of this configured Transport Converters is outside the scope of this
document. document.
One of the benefits of this design is that different transport One of the benefits of this design is that different transport
protocol extensions can be used on the upstream and the downstream protocol extensions can be used on the upstream and the downstream
connections. This encourages the deployment of new TCP extensions connections. This encourages the deployment of new TCP extensions
until they are widely supported by servers, in particular. until they are widely supported by servers, in particular.
The architecture does not mandate anything on the server side. The architecture does not mandate anything on the server side.
Similar to address sharing mechanisms, the architecture does not Similar to address sharing mechanisms, the architecture does not
interfere with end-to-end TLS connections [RFC8446] between the interfere with end-to-end TLS connections [RFC8446] between the
Client and the Server (Figure 3). Client and the Server (Figure 3). In other words, end-to-end TLS is
supported in the presence of a Converter.
Client Transport Server Client Transport Server
| Converter | | Converter |
| | | | | |
/==========================================\ /==========================================\
| End-to-end TLS | | End-to-end TLS |
\==========================================/ \==========================================/
* TLS messages exhanged between the Client * TLS messages exhanged between the Client
and the Server are not shown. and the Server are not shown.
Figure 3: End-to-end TLS via a Transport Converter Figure 3: End-to-end TLS via a Transport Converter
It is out of scope of this document to elaborate on specific
considerations related to the use of TLS in the Client-Converter
connection leg to exchange Convert TLVs (in addition to the end-to-
end TLS connection).
3.2. Theory of Operation 3.2. Theory of Operation
At a high level, the objective of the Transport Converter is to allow At a high level, the objective of the Transport Converter is to allow
the Client to use a specific extension, e.g., Multipath TCP, on a the use a specific extension, e.g., Multipath TCP, on a subset of the
subset of the path even if the Server does not support this path even if the peer does not support this extension. This is
extension. This is illustrated in Figure 4 where the Client illustrated in Figure 4 where the Client initiates a Multipath TCP
initiates a Multipath TCP connection with the Transport Converter connection with the Transport Converter (packets belonging to the
(packets belonging to the Multipath TCP connection are shown with Multipath TCP connection are shown with "===") while the Transport
"===") while the Transport Converter uses a regular TCP connection Converter uses a regular TCP connection with the Server.
with the Server.
Transport Transport
Client Converter Server Client Converter Server
======================> ======================>
--------------------> -------------------->
<-------------------- <--------------------
<====================== <======================
skipping to change at page 8, line 51 skipping to change at page 9, line 8
The packets belonging to the pair of connections between the Client The packets belonging to the pair of connections between the Client
and Server passing through a Transport Converter may follow a and Server passing through a Transport Converter may follow a
different path than the packets directly exchanged between the Client different path than the packets directly exchanged between the Client
and the Server. Deployments should minimize the possible additional and the Server. Deployments should minimize the possible additional
delay by carefully selecting the location of the Transport Converter delay by carefully selecting the location of the Transport Converter
used to reach a given destination. used to reach a given destination.
When establishing a connection, the Client can, depending on local When establishing a connection, the Client can, depending on local
policies, either contact the Server directly (e.g., by sending a TCP policies, either contact the Server directly (e.g., by sending a TCP
SYN towards the Server) or create the connection via a Transport SYN towards the Server) or create the connection via a Transport
Converter. In the latter case, the Client initiates a connection Converter. In the latter case (that is, the conversion service is
towards the Transport Converter and indicates the IP address and port used), the Client initiates a connection towards the Transport
number of the Server within the connection establishment packet. Converter and indicates the IP address and port number of the Server
Doing so enables the Transport Converter to immediately initiate a within the connection establishment packet. Doing so enables the
connection towards that Server, without experiencing an extra delay. Transport Converter to immediately initiate a connection towards that
The Transport Converter waits until the receipt of the confirmation Server, without experiencing an extra delay. The Transport Converter
that the Server agrees to establish the connection before confirming waits until the receipt of the confirmation that the Server agrees to
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. In accordance with
[RFC1919], the Transport Converter maintains two connections that are [RFC1919], the Transport Converter 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
(resp., downstream) connection is relayed over the downstream (resp., (resp., downstream) connection is relayed over the downstream (resp.,
upstream) connection. upstream) connection. In particular, if the initial SYN message
contains data in its payload (e.g., [RFC7413]), that data MUST be
placed right after the Convert TLVs when generating the relayed SYN.
Figure 5 illustrates the establishment of an outbound TCP connection Figure 5 illustrates the establishment of an outbound TCP connection
by a Client through a Transport Converter. The information shown by a Client through a Transport Converter. The information shown
between brackets denotes Convert Protocol messages described in between brackets denotes Convert Protocol messages described in
Section 4. Section 4.
Transport Transport
Client Converter Server Client Converter Server
--------------------> -------------------->
SYN [->Server:port] SYN [->Server:port]
skipping to change at page 13, line 40 skipping to change at page 14, line 30
SYN+ACK SYN+ACK
<--------------------- <---------------------
ACK ACK
<------------------- <-------------------
ACK, MPC ACK, MPC
Figure 8: Establishment of an Incoming TCP Connection through a Figure 8: Establishment of an Incoming TCP Connection through a
Transport Converter Transport Converter
It is out of scope of this document to define specific Convert TLVs
to manage incoming connections. These TLVs can be defined in a
separate document.
4. The Convert Protocol (Convert) 4. The Convert Protocol (Convert)
This section describes the messages that are exchanged between a This section describes the messages that are exchanged between a
Client and a Transport Converter. The Convert Protocol (Convert, for Client and a Transport Converter. The Convert Protocol (Convert, for
short) uses a 32 bits long fixed header that is sent by both the short) uses a 32 bits long fixed header that is sent by both the
Client and the Transport Converter over each established connection. Client and the Transport Converter over each established connection.
This header indicates both the version of the protocol used and the This header indicates both the version of the protocol used and the
length of the Convert message. length of the Convert message.
4.1. The Convert Fixed Header 4.1. The Convert Fixed Header
skipping to change at page 14, line 37 skipping to change at page 15, line 28
of the bytestream that are consumed by the Convert messages. Since of the bytestream that are consumed by the Convert messages. Since
Total Length is also an 8 bits unsigned integer, those messages Total Length is also an 8 bits unsigned integer, those messages
cannot consume more than 1020 bytes of data. This limits the number cannot consume more than 1020 bytes of data. This limits the number
of bytes that a Transport Converter needs to process. A Total Length of bytes that a Transport Converter needs to process. A Total Length
of zero is invalid and the connection MUST be reset upon reception of of zero is invalid and the connection MUST be reset upon reception of
a header with such total length. a header with such total length.
The Unassigned field MUST be set to zero in this version of the The Unassigned field MUST be set to zero in this version of the
protocol. These bits are available for future use [RFC8126]. protocol. These bits are available for future use [RFC8126].
Data added by the Convert protocol to the TCP bytestream in the
upstream connection is unambiguously distinguished from payload data
in the downstream connection by the Total Length field in the Convert
messages.
4.2. Convert TLVs 4.2. Convert TLVs
4.2.1. Generic Convert TLV Format 4.2.1. Generic Convert TLV Format
The Convert protocol uses variable length messages that are encoded The Convert protocol uses variable length messages that are encoded
using the generic TLV (Type, Length, Value) format depicted in using the generic TLV (Type, Length, Value) format depicted in
Figure 10. Figure 10.
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.
skipping to change at page 18, line 27 skipping to change at page 19, line 27
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| TCPOpt kind | TCPOpt Length | Value (opt) | .... | | TCPOpt kind | TCPOpt Length | Value (opt) | .... |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| .... | | .... |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| ... | | ... |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 15: The TCP Options field Figure 15: The TCP Options field
Upon reception of a Connect TLV, and absent any rate limit policy or Upon reception of a Connect TLV, and absent any policy (e.g., rate-
resource exhaustion conditions, a Transport Converter MUST attempt to limit) or resource exhaustion conditions, a Transport Converter
establish a connection to the address and port that it contains. The attempts to establish a connection to the address and port that it
Transport Converter MUST use by default the TCP options that contains. The Transport Converter MUST use by default the TCP
correspond to its local policy to establish this connection. These options that correspond to its local policy to establish this
are the options that it advertises in the Supported TCP Extensions connection. These are the options that it advertises in the
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' subfield
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
skipping to change at page 28, line 16 skipping to change at page 29, line 16
The Convert Protocol is intended to be used in managed networks where The Convert Protocol is intended to be used in managed networks where
end hosts can be identified by their IP address. end hosts can be identified by their IP address.
Stronger mutual authentication schemes MUST be defined to use the Stronger mutual authentication schemes MUST be defined to use the
Convert Protocol in more open network environments. One possibility Convert Protocol in more open network environments. One possibility
is to use TLS to perform mutual authentication between the client and is to use TLS to perform mutual authentication between the client and
the Converter. That is, use TLS when a Client retrieves a Cookie the Converter. That is, use TLS when a Client retrieves a Cookie
from the Converter and rely on certificate-based client from the Converter and rely on certificate-based client
authentication, pre-shared key based [RFC4279] or raw public key authentication, pre-shared key based [RFC4279] or raw public key
based client authentication [RFC7250] to secure this connection. If based client authentication [RFC7250] to secure this connection.
the authentication succeeds, the Converter returns a cookie whose
content may be, for example, set to a hash using as input the If the authentication succeeds, the Converter returns a cookie to the
representation of the Subject Public Key Info (SPKI) of the client Client. Subsequent Connect messages will be authorized as a function
X.509 certificate, the Client raw public key, or the "Pre-Shared Key of the content of the Cookie TLV.
(PSK) identity" used by the Client in the TLS ClientKeyExchange
message. Subsequent Connect messages will be authorized as a In deployments where network-assisted connections are not allowed
function of the content of the Cookie TLV. The client MUST also between hosts of a domain (i.e., hairpinning), the Converter may be
authenticate. instructed to discard such connections. Hairpinned connections are
thus rejected by the Transport Converter by returning an Error TLV
set to "Not Authorized". Absent explicit configuration otherwise,
hairpinning is enabled by the Converter (see Figure 20.
<===Network Provider===>
+----+ from X1:x1 to X2':x2' +-----+ X1':x1'
| C1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
+----+ | v |
| v |
| v |
| v |
+----+ from X1':x1' to X2:x2 | v | X2':x2'
| C2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
+----+ +-----+
Converter
Note: X2':x2' may be equal to
X2:x2
Figure 20: Hairpinning Example
See below for authorization considerations that are specific for See below for authorization considerations that are specific for
Multipath TCP. Multipath TCP.
7.3. Denial of Service 7.3. Denial of Service
Another possible risk is the amplification attacks since a Transport Another possible risk is the amplification attacks since a Transport
Converter sends a SYN towards a remote Server upon reception of a SYN Converter sends a SYN towards a remote Server upon reception of a SYN
from a Client. This could lead to amplification attacks if the SYN from a Client. This could lead to amplification attacks if the SYN
sent by the Transport Converter were larger than the SYN received sent by the Transport Converter were larger than the SYN received
skipping to change at page 30, line 16 skipping to change at page 31, line 38
IANA is requested to create a new "The Convert Protocol (Convert) IANA is requested to create a new "The Convert Protocol (Convert)
Parameters" registry. Parameters" registry.
The following subsections detail new registries within "The Convert The following subsections detail new registries within "The Convert
Protocol (Convert) Parameters" registry. Protocol (Convert) Parameters" registry.
8.2.1. Convert Versions 8.2.1. Convert Versions
IANA is requested to create the "Convert versions" sub-registry. New IANA is requested to create the "Convert versions" sub-registry. New
values are assigned via Standards Action. values are assigned via IETF Review (Section 4.8 of [RFC8126]).
The initial values to be assigned at the creation of the registry are The initial values to be assigned at the creation of the registry are
as follows: as follows:
+---------+--------------------------------------+-------------+ +---------+--------------------------------------+-------------+
| Version | Description | Reference | | Version | Description | Reference |
+---------+--------------------------------------+-------------+ +---------+--------------------------------------+-------------+
| 0 | Reserved by this document | [This-RFC] | | 0 | Reserved by this document | [This-RFC] |
| 1 | Assigned by this document | [This-RFC] | | 1 | Assigned by this document | [This-RFC] |
+---------+--------------------------------------+-------------+ +---------+--------------------------------------+-------------+
8.2.2. Convert TLVs 8.2.2. Convert TLVs
IANA is requested to create the "Convert TLVs" sub-registry. The IANA is requested to create the "Convert TLVs" sub-registry. The
procedure for assigning values from this registry is as follows: procedure for assigning values from this registry is as follows:
o The values in the range 1-127 can be assigned via Standards o The values in the range 1-127 can be assigned via IETF Review.
Action.
o The values in the range 128-191 can be assigned via Specification o The values in the range 128-191 can be assigned via Specification
Required. Required.
o The values in the range 192-255 can be assigned for Private Use. o The values in the range 192-255 can be assigned for Private Use.
The initial values to be assigned at the creation of the registry are The initial values to be assigned at the creation of the registry are
as follows: as follows:
+---------+--------------------------------------+-------------+ +---------+--------------------------------------+-------------+
skipping to change at page 31, line 35 skipping to change at page 32, line 50
o Client-side errors: 32-63 o Client-side errors: 32-63
o Transport Converter-side errors: 64-95 o Transport Converter-side errors: 64-95
o Errors caused by destination server: 96-127 o Errors caused by destination server: 96-127
The procedure for assigning values from this sub-registry is as The procedure for assigning values from this sub-registry is as
follows: follows:
o 0-191: Values in this range are assigned via Standards Action. o 0-191: Values in this range are assigned via IETF Review.
o 192-255: Values in this range are assigned via Specification o 192-255: Values in this range are assigned via Specification
Required. Required.
The initial values to be assigned at the creation of the registry are The initial values to be assigned at the creation of the registry are
as follows: as follows:
+-------+------+-----------------------------------+-----------+ +-------+------+-----------------------------------+-----------+
| Error | Hex | Description | Reference | | Error | Hex | Description | Reference |
+-------+------+-----------------------------------+-----------+ +-------+------+-----------------------------------+-----------+
skipping to change at page 32, line 20 skipping to change at page 33, line 26
| 2 | 0x02 | Unsupported Message | [This-RFC]| | 2 | 0x02 | Unsupported Message | [This-RFC]|
| 3 | 0x03 | Missing Cookie | [This-RFC]| | 3 | 0x03 | Missing Cookie | [This-RFC]|
| 32 | 0x20 | Not Authorized | [This-RFC]| | 32 | 0x20 | Not Authorized | [This-RFC]|
| 33 | 0x21 | Unsupported TCP Option | [This-RFC]| | 33 | 0x21 | Unsupported TCP Option | [This-RFC]|
| 64 | 0x40 | Resource Exceeded | [This-RFC]| | 64 | 0x40 | Resource Exceeded | [This-RFC]|
| 65 | 0x41 | Network Failure | [This-RFC]| | 65 | 0x41 | Network Failure | [This-RFC]|
| 96 | 0x60 | Connection Reset | [This-RFC]| | 96 | 0x60 | Connection Reset | [This-RFC]|
| 97 | 0x61 | Destination Unreachable | [This-RFC]| | 97 | 0x61 | Destination Unreachable | [This-RFC]|
+-------+------+-----------------------------------+-----------+ +-------+------+-----------------------------------+-----------+
Figure 20: The Convert Error Codes Figure 21: The Convert Error Codes
9. Acknowledgements 9. Acknowledgements
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
skipping to change at page 34, line 17 skipping to change at page 35, line 20
This section to be removed before publication. This section to be removed before publication.
o 00 : initial version, designed to support Multipath TCP and TFO o 00 : initial version, designed to support Multipath TCP and TFO
only only
o 00 to -01 : added section Section 5 describing the support of o 00 to -01 : added section Section 5 describing the support of
different standard tracks TCP options by Transport Converters, different standard tracks TCP options by Transport Converters,
clarification of the IANA section, moved the SOCKS comparison to clarification of the IANA section, moved the SOCKS comparison to
the appendix and various minor modifications the appendix and various minor modifications
o 01 to -02 : Minor modifications o 01 to -02: Minor modifications
o 02 to -03 : Minor modifications o 02 to -03: Minor modifications
o 03 to -04 : Minor modifications o 03 to -04: Minor modifications
o 04 to -05: Integrate a lot of feedback from implementors who have
worked on client and server side implementations. The main
modifications are the following :
* TCP Fast Open is not strictly required anymore. Several
implementors expressed concerns about this requirement. 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, this version supports the utilisation 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.
* the Boostrap procedure has been simplified based on feedback
from implementers
* Error messages are not included in RST segments anymore but
sent in the bytestream. Implementors have indicated that
processing such segments on clients was difficult on some
platforms. This change simplifies client implementations.
* Many minor editorial changes to clarify the text based on
implementors feedback.
o 05 to -06: Many clarifications to integrate the comments from the
chairs in preparation to the WGLC:
* Updated IANA policy to require "IETF Review" instead of
"Standard Action"
* Call out explicilty that data in SYNs are relayed by the
Converter
* Reiterate the scope
* Hairpinning behavior can be disabled (policy-based)
* Fix nits
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 34, line 50 skipping to change at page 36, line 47
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, ICMPv6, UDP, and TCP Headers", RFC 4727,
DOI 10.17487/RFC4727, November 2006, DOI 10.17487/RFC4727, November 2006,
<https://www.rfc-editor.org/info/rfc4727>. <https://www.rfc-editor.org/info/rfc4727>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>. <https://www.rfc-editor.org/info/rfc4987>.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
RFC 5482, DOI 10.17487/RFC5482, March 2009, RFC 5482, DOI 10.17487/RFC5482, March 2009,
<https://www.rfc-editor.org/info/rfc5482>. <https://www.rfc-editor.org/info/rfc5482>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>. <https://www.rfc-editor.org/info/rfc6824>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, "Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013, RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/info/rfc6890>. <https://www.rfc-editor.org/info/rfc6890>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
skipping to change at page 37, line 21 skipping to change at page 39, line 28
Peirens, B., Detal, G., Barre, S., and O. Bonaventure, Peirens, B., Detal, G., Barre, S., and O. Bonaventure,
"Link bonding with transparent Multipath TCP", draft- "Link bonding with transparent Multipath TCP", draft-
peirens-mptcp-transparent-00 (work in progress), July peirens-mptcp-transparent-00 (work in progress), July
2016. 2016.
[IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment", [IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment",
IETF Journal, Fall 2016 , n.d.. IETF Journal, Fall 2016 , n.d..
[IMC11] Honda, K., Nishida, Y., Raiciu, C., Greenhalgh, A., [IMC11] Honda, K., Nishida, Y., Raiciu, C., Greenhalgh, A.,
Handley, M., and T. Hideyuki, "Is it still possible to Handley, M., and T. Hideyuki, "Is it still possible to
extend TCP ?", Proceedings of the 2011 ACM SIGCOMM extend TCP?", Proceedings of the 2011 ACM SIGCOMM
conference on Internet measurement conference , 2011. conference on Internet measurement conference , 2011.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, DOI 10.17487/RFC1323, May for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
1992, <https://www.rfc-editor.org/info/rfc1323>. 1992, <https://www.rfc-editor.org/info/rfc1323>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
skipping to change at page 38, line 11 skipping to change at page 40, line 16
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001, DOI 10.17487/RFC3135, June 2001,
<https://www.rfc-editor.org/info/rfc3135>. <https://www.rfc-editor.org/info/rfc3135>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for
Multipath Operation with Multiple Addresses", RFC 6181, Multipath Operation with Multiple Addresses", RFC 6181,
DOI 10.17487/RFC6181, March 2011, DOI 10.17487/RFC6181, March 2011,
<https://www.rfc-editor.org/info/rfc6181>. <https://www.rfc-editor.org/info/rfc6181>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013, DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>. <https://www.rfc-editor.org/info/rfc6887>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <https://www.rfc-editor.org/info/rfc6888>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, "Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>. <https://www.rfc-editor.org/info/rfc6928>.
[RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT
Traversal", RFC 6978, DOI 10.17487/RFC6978, July 2013, Traversal", RFC 6978, DOI 10.17487/RFC6978, July 2013,
<https://www.rfc-editor.org/info/rfc6978>. <https://www.rfc-editor.org/info/rfc6978>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
skipping to change at page 39, line 28 skipping to change at page 41, line 23
Appendix A. Differences with SOCKSv5 Appendix A. 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 21. implementation based on SOCKSv5 is illustrated in Figure 22.
Client SOCKS Proxy Server Client SOCKS Proxy Server
--------------------> -------------------->
SYN SYN
<-------------------- <--------------------
SYN+ACK SYN+ACK
--------------------> -------------------->
ACK ACK
--------------------> -------------------->
skipping to change at page 40, line 40 skipping to change at page 42, line 40
--------------------> -------------------->
Data1 Data1
--------------------> -------------------->
Data1 Data1
<-------------------- <--------------------
Data2 Data2
<-------------------- <--------------------
Data2 Data2
Figure 21: Establishment of a TCP connection through a SOCKS proxy Figure 22: Establishment of a TCP connection through a SOCKS proxy
without authentication without authentication
The Convert protocol also relays data between an upstream and a The Convert protocol also relays data between an upstream and a
downstream connection, but there are important differences with downstream connection, but there are important differences with
SOCKSv5. SOCKSv5.
A first difference is that the Convert protocol leverages the TFO A first difference is that the Convert protocol exchanges all control
option [RFC7413] to exchange all control information during the information during the three-way handshake. This reduces the
three-way handshake. This reduces the connection establishment delay connection establishment delay compared to SOCKS that requires two or
compared to SOCKS that requires two or more round-trip-times before more round-trip-times before the establishment of the downstream
the establishment of the downstream connection towards the final connection towards the final destination. In today's Internet,
destination. In today's Internet, latency is a important metric and latency is a important metric and various protocols have been tuned
various protocols have been tuned to reduce their latency to reduce their latency [I-D.arkko-arch-low-latency]. A recently
[I-D.arkko-arch-low-latency]. A recently proposed extension to SOCKS proposed extension to SOCKS also leverages the TFO option
also leverages the TFO option [I-D.olteanu-intarea-socks-6]. [I-D.olteanu-intarea-socks-6].
A second difference is that the Convert protocol explicitly takes the A second difference is that the Convert protocol explicitly takes the
TCP extensions into account. By using the Convert protocol, the TCP extensions into account. By using the Convert protocol, the
Client can learn whether a given TCP extension is supported by the Client can learn whether a given TCP extension is supported by the
destination Server. This enables the Client to bypass the Transport destination Server. This enables the Client to bypass the Transport
Converter when the destination supports the required TCP extension. Converter when the destination supports the required TCP extension.
Neither SOCKS v5 [RFC1928] nor the proposed SOCKS v6 Neither SOCKS v5 [RFC1928] nor the proposed SOCKS v6
[I-D.olteanu-intarea-socks-6] provide such a feature. [I-D.olteanu-intarea-socks-6] provide such a feature.
A third difference is that a Transport Converter will only accept the A third difference is that a Transport Converter will only accept the
 End of changes. 34 change blocks. 
116 lines changed or deleted 194 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/