draft-ietf-tcpm-converters-06.txt   draft-ietf-tcpm-converters-07.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: September 7, 2019 Orange Expires: December 13, 2019 Orange
S. Gundavelli S. Gundavelli
Cisco Cisco
S. Seo S. Seo
Korea Telecom Korea Telecom
B. Hesmans B. Hesmans
Tessares Tessares
March 06, 2019 June 11, 2019
0-RTT TCP Convert Protocol 0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-06 draft-ietf-tcpm-converters-07
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 September 7, 2019. This Internet-Draft will expire on December 13, 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 . . . . . . . . . . . . . . . . . . . . . 13 TCP Connection . . . . . . . . . . . . . . . . . . . . . 12
4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 14 4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 13
4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 14 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 13
4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 15 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 14
4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 15
4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17 4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 16
4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 17 4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 16
4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 18 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 17
4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 20 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 19
4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 20 4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 19
4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 21 4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 20
5. Compatibility of Specific TCP Options with the Conversion 5. Compatibility of Specific TCP Options with the Conversion
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 24 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 23
5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 25 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 24
5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 25 5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 24
5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 25
5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 26 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 25
5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 26 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 25
5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 27 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 26
5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 27 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 26
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 27 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 28 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 27
7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 29 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 28
7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 30 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 29
7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 30 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 29
7.5. Multipath TCP-specific Considerations . . . . . . . . . . 30 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. Convert Service Port Number . . . . . . . . . . . . . . . 31 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 30
8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 31 8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 30
8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 31 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 30
8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 32 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 31
8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 32 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 33
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 34
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. Example Socket API Changes to Support the 0-RTT Convert
11.1. Normative References . . . . . . . . . . . . . . . . . . 36 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . 38 11.1. Active Open (Client Side) . . . . . . . . . . . . . . . 35
Appendix A. Differences with SOCKSv5 . . . . . . . . . . . . . . 41 11.2. Passive Open (Converter Side) . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 12. Differences with SOCKSv5 . . . . . . . . . . . . . . . . . . 37
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.1. Normative References . . . . . . . . . . . . . . . . . . 39
13.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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
deployed on both clients and servers to be actually used on the deployed on both clients and servers to be actually used on the
Internet. Experience with the latter TCP extensions reveals that Internet. Experience with the latter TCP extensions reveals that
their deployment can require many years. Fukuda reports in their deployment can require many years. Fukuda reports in
[Fukuda2011] results of a decade of measurements showing the [Fukuda2011] results of a decade of measurements showing the
deployment of Selective Acknowledgements, Window Scale and TCP deployment of Selective Acknowledgements, Window Scale and TCP
Timestamps. [ANRW17] describes measurements showing that TCP Fast Timestamps. [ANRW17] describes measurements showing that TCP Fast
Open (TFO) [RFC7413] is still not widely deployed. Open (TFO) [RFC7413] is still not widely deployed.
There are some situations where the transport stack used on clients There are some situations where the transport stack used on clients
(resp. servers) can be upgraded at a faster pace than the transport (or servers) can be upgraded at a faster pace than the transport
stack running on servers (resp. clients). In those situations, stack running on servers (or clients). In those situations, clients
clients would typically want to benefit from the features of an would typically want to benefit from the features of an improved
improved transport protocol even if the servers have not yet been transport protocol even if the servers have not yet been upgraded and
upgraded and conversely. Performance Enhancing Proxies [RFC3135], conversely. Performance Enhancing Proxies [RFC3135], and other
and other service functions have been deployed as solutions to service functions have been deployed as solutions to improve TCP
improve TCP performance over links with specific characteristics. performance over links with specific characteristics.
Recent examples of TCP extensions include Multipath TCP [RFC6824] or Recent examples of TCP extensions include Multipath TCP [RFC6824] or
TCPINC [I-D.ietf-tcpinc-tcpcrypt]. Those extensions provide features TCPINC [RFC8548]. Those extensions provide features that are
that are interesting for clients such as wireless devices. With interesting for clients such as wireless devices. With Multipath
Multipath TCP, those devices could seamlessly use WLAN (Wireless TCP, those devices could seamlessly use WLAN (Wireless Local Area
Local Area Network) and cellular networks, for bonding purposes, Network) and cellular networks, for bonding purposes, faster
faster handovers, or better resiliency. Unfortunately, deploying handovers, or better resiliency. Unfortunately, deploying those
those extensions on both a wide range of clients and servers remains extensions on both a wide range of clients and servers remains
difficult. difficult.
More recently, experimentation of 5G bonding, which has very scarce More recently, experimentation of 5G bonding, which has very scarce
coverage, has been conducted into global range of the incumbent 4G coverage, has been conducted into global range of the incumbent 4G
(LTE) connectivity in newly devised clients using Multipath TCP (LTE) connectivity in newly devised clients using Multipath TCP
proxy. Even if the 5G and the 4G bonding by using Multipath TCP proxy. Even if the 5G and the 4G bonding by using Multipath TCP
increases the bandwidth, it is as well crucial to minimize latency increases the bandwidth, it is as well crucial to minimize latency
for all the way between endhosts regardless of whether intermediate for all the way between endhosts regardless of whether intermediate
nodes are inside or outside of the mobile core. In order to handle nodes are inside or outside of the mobile core. In order to handle
uRLLC (Ultra-Reliable Low-Latency Communication) for the next uRLLC (Ultra-Reliable Low-Latency Communication) for the next
generation mobile network, Multipath TCP and its proxy mechanism such generation mobile network, Multipath TCP and its proxy mechanism such
as the one used to provide Access tTaffic Steering, Switching, and as the one used to provide Access Taffic Steering, Switching, and
Splitting (ATSSS) must be optimised to reduce latency. Splitting (ATSSS) must be optimised to reduce latency.
This document specifies an application proxy, called Transport This document specifies an application proxy, called Transport
Converter. A Transport Converter is a function that is installed by Converter. A Transport Converter is a function that is installed by
a network operator to aid the deployment of TCP extensions and to a network operator to aid the deployment of TCP extensions and to
provide the benefits of such extensions to clients. A Transport provide the benefits of such extensions to clients. A Transport
Converter may provide conversion service for one or more TCP Converter may provide conversion service for one or more TCP
extensions. Which TCP extensions are eligible to the conversion extensions. Which TCP extensions are eligible to the conversion
service is deployment-specific. The conversion service is provided service is deployment-specific. The conversion service is provided
by means of the 0-RTT TCP Convert Protocol (Convert), that is an by means of the 0-RTT TCP Convert Protocol (Convert), that is an
skipping to change at page 5, line 39 skipping to change at page 5, line 42
through protocols such as [I-D.boucadair-tcpm-dhc-converter]). through protocols such as [I-D.boucadair-tcpm-dhc-converter]).
Configuration means are outside the scope of this document. Configuration means are outside the scope of this document.
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 discusses how a TCP stack would need to support the
used to deploy Multipath TCP in some cellular networks (Section 2.2 protocol described in this document. Appendix B provides a
of [RFC8041]). comparison with SOCKS proxies that are already used to deploy
Multipath TCP in some cellular networks (Section 2.2 of [RFC8041]).
2. Requirements 2. Requirements
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 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] [RFC8174] when, and only when, they appear in all capitals, [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here. as shown here.
3. Architecture 3. Architecture
3.1. Functional Elements 3.1. Functional Elements
The Convert Protocol considers three types of endhosts: The Convert Protocol considers three functional elements:
o Clients; o Clients;
o Transport Converters; o Transport Converters;
o Servers. o Servers.
A Transport Converter is a network function that relays all data A Transport Converter is a network function that 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, client-facing interface). Converter (Internet-facing interface, client-facing interface).
|
:
|
+------------+ +------------+
client <- upstream ->| Transport |<- downstream ->server client <- upstream ->| Transport |<- downstream ->server
| Converter | | Converter |
+------------+ +------------+
|
client-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
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 7, line 18 skipping to change at page 7, line 18
| |
+-+ +-+
|R| |R|
+-+ +-+
| |
+---------+ +---------+
|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 new TCP 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
skipping to change at page 8, line 32 skipping to change at page 8, line 32
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 use a specific extension, e.g., Multipath TCP, on a subset of the the use a specific extension, e.g., Multipath TCP, on a subset of the
path even if the peer does not support this extension. This is path even if the peer does not support this extension. This is
illustrated in Figure 4 where the Client initiates a Multipath TCP illustrated in Figure 4 where the Client initiates a Multipath TCP
connection with the Transport Converter (packets belonging to the connection with the Transport Converter (packets belonging to the
Multipath TCP connection are shown with "===") while the Transport Multipath TCP connection are shown with "===") while the Transport
Converter uses a regular TCP connection with the Server. Converter uses a regular TCP connection with the Server.
Transport Client Transport Server
Client Converter Server | Converter |
======================> | | |
|==================>|--------------------->|
--------------------> | | |
|<==================|<---------------------|
<-------------------- | | |
Multipath TCP packets Regular TCP packets
<======================
Multipath TCP packets Regular TCP packets
Figure 4: An example of network-assisted MPTCP Connection Figure 4: An Example of 0-RTT Network-Assisted MPTCP Connection
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
skipping to change at page 9, line 30 skipping to change at page 9, line 26
[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., (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.
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]| SYN |
|------------------>|--------------------->|
--------------------> |<------------------|<---------------------|
SYN | SYN+ACK [ ] | SYN+ACK |
| | |
<--------------------
SYN+ACK
<--------------------
SYN+ACK [ ]
Figure 5: Establishment of a TCP connection through a Transport Figure 5: Establishment of a TCP Connection Through a Transport
Converter (1) Converter (1)
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
skipping to change at page 11, line 7 skipping to change at page 10, line 32
[I-D.nam-mptcp-deployment-considerations]. Which behavior to use by [I-D.nam-mptcp-deployment-considerations]. Which behavior to use by
a Transport Converter is deployment-specific. If address sharing a Transport Converter is deployment-specific. If address sharing
mode is enabled, the Transport Converter MUST adhere to REQ-2 of mode is enabled, the Transport Converter MUST adhere to REQ-2 of
[RFC6888] which implies a default "IP address pooling" behavior of [RFC6888] which implies a default "IP address pooling" behavior of
"Paired" (as defined in Section 4.1 of [RFC4787]) must be supported. "Paired" (as defined in Section 4.1 of [RFC4787]) must be supported.
This behavior is meant to avoid breaking applications that depend on This behavior is meant to avoid breaking applications that depend on
the external address remaining constant. the external 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. This to the application until completion of the three-way-handshake. To
restriction was motivated by two concerns. First, duplicate SYNs can enable applications to exchange data in a TCP handshake, this
cause problems for some applications that rely on TCP [RFC7413]. specification follows an approach similar to TCP Fast Open [RFC7413]
Second, TCP suffers from SYN flooding attacks [RFC4987]. TCP Fast and thus removes the constraint by allowing data in SYN packets to be
Open [RFC7413] solves these two problems for applications that can delivered to the Transport Converter application.
tolerate replays by using the TCP Fast Open option that includes a
cookie. However, the utilization of this option consumes space in As discussed in [RFC7413], such change to TCP semantic raises two
the limited TCP extended header. Furthermore, there are situations, issues. First, duplicate SYNs can cause problems for some
as noted in Section 7.3 of [RFC7413] where it is possible to accept applications that rely on TCP. Second, TCP suffers from SYN flooding
the payload of SYN packets without creating additional security risks attacks [RFC4987]. TFO solves these two problems for applications
such as a network where addresses cannot be spoofed and the Transport that can tolerate replays by using the TCP Fast Open option that
Converter only serves a set of hosts that are identified by these includes a cookie. However, the utilization of this option consumes
addresses. For these reasons, this specification does not mandate space in the limited TCP extended header. Furthermore, there are
the use of the TCP Fast Open option when the Client sends a situations, as noted in Section 7.3 of [RFC7413] where it is possible
connection establishment packet towards a Transport Converter. The to accept the payload of SYN packets without creating additional
Convert protocol includes an optional Cookie TLV that provides security risks such as a network where addresses cannot be spoofed
similar protection as the TCP Fast Open option without consuming and the Transport Converter only serves a set of hosts that are
space in the extended TCP header. identified by these addresses.
For these reasons, this specification does not mandate the use of the
TCP Fast Open option when the Client sends a connection establishment
packet towards a Transport Converter. The Convert protocol includes
an optional Cookie TLV that provides similar protection as the TCP
Fast Open option without consuming space in the extended TCP header.
3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP 3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP
Connections Connections
As an example, let us consider how the Convert protocol can help the As an example, let us consider how the Convert protocol can help the
deployment of Multipath TCP. We assume that both the Client and the deployment of Multipath TCP. We assume that both the Client and the
Transport Converter support Multipath TCP, but consider two different Transport Converter support Multipath TCP, but consider two different
cases depending on whether the Server supports Multipath TCP or not. cases depending on whether the Server supports Multipath TCP or not.
As a reminder, a Multipath TCP connection is created by placing the As a reminder, a Multipath TCP connection is created by placing the
MP_CAPABLE (MPC) option in the SYN sent by the Client. MP_CAPABLE (MPC) option in the SYN sent by the Client.
Figure 6 describes the operation of the Transport Converter if the Figure 6 describes the operation of the Transport Converter if the
Server does not support Multipath TCP. Server does not support Multipath TCP.
Transport Transport
Client Converter Server Client Converter Server
--------------------> |SYN, | |
SYN, MPC [->Server:port] |MPC [->Server:port]| |
|------------------>| SYN, MPC |
--------------------> | |--------------------->|
SYN, MPC | |<---------------------|
|<------------------| SYN+ACK |
<-------------------- | SYN+ACK,MPC [.] | |
SYN+ACK | | |
<-------------------- |------------------>| |
SYN+ACK,MPC [.] | ACK, MPC |--------------------->|
| | ACK |
-------------------->
ACK,MPC
-------------------->
ACK
Figure 6: Establishment of a Multipath TCP connection through a Figure 6: 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 6). The SYN includes SYN with the MP_CAPABLE option (MPC in Figure 6). The SYN includes
the address and port number of the target Server, that are extracted the address and port number of the target Server, that are extracted
and used by the Transport Converter to initiate a Multipath TCP and used by the Transport Converter to initiate a Multipath TCP
connection towards this Server. Since the Server does not support connection towards this Server. Since the Server does not support
Multipath TCP, it replies with a SYN+ACK that does not contain the Multipath TCP, it replies with a SYN+ACK that does not contain the
MP_CAPABLE option. The Transport Converter notes that the connection MP_CAPABLE option. The Transport Converter notes that the connection
with the Server does not support Multipath TCP and returns the with the Server does not support Multipath TCP and returns the
skipping to change at page 13, line 5 skipping to change at page 12, line 15
Figure 7 considers a Server that supports Multipath TCP. In this Figure 7 considers a Server that supports Multipath TCP. In this
case, it replies to the SYN sent by the Transport Converter with the case, it replies to the SYN sent by the Transport Converter with the
MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport
Converter confirms the establishment of the connection to the Client Converter confirms the establishment of the connection to the Client
and indicates to the Client that the Server supports Multipath TCP. and indicates to the Client that the Server supports Multipath TCP.
With this information, the Client has discovered that the Server With this information, the Client has discovered that the Server
supports Multipath TCP natively. This will enable the Client to supports Multipath TCP natively. This will enable the Client to
bypass the Transport Converter for the subsequent Multipath TCP bypass the Transport Converter for the subsequent Multipath TCP
connections that it will initiate towards this Server. connections that it will initiate towards this Server.
Transport Transport
Client Converter Server Client Converter Server
--------------------> |SYN, | |
SYN, MPC [->Server:port] |MPC [->Server:port]| |
|------------------>| SYN, MPC |
--------------------> | |--------------------->|
SYN, MPC | |<---------------------|
|<------------------| SYN+ACK, MPC |
<-------------------- |SYN+ACK, | |
SYN+ACK, MPC |MPC [MPC supported]| |
<-------------------- |------------------>| |
SYN+ACK, MPC [ MPC supported ] | ACK, MPC |--------------------->|
| | ACK, MPC |
-------------------->
ACK, MPC
-------------------->
ACK, MPC
Figure 7: Establishment of a Multipath TCP connection through a Figure 7: Establishment of a Multipath TCP Connection Through a
converter towards a server that supports Multipath TCP 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 8. In order to support incoming connections is depicted in Figure 8. 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
Transport Converter to create dynamic mappings. Those mappings will Transport Converter to create dynamic mappings. Those mappings will
be used by the Transport Converter to intercept an incoming TCP be used by the Transport Converter to intercept an incoming TCP
connection destined to the Client and convert it into a Multipath TCP connection destined to the Client and convert it into a Multipath TCP
skipping to change at page 14, line 9 skipping to change at page 13, line 16
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 Transport
Client Converter Remote Host Client Converter Server
<------------------- | | |
SYN | |<-------------------|
|<--------------------| SYN |
<------------------- |SYN, | |
SYN, MPC[Remote Host:port] |MPC[Remote Host:port]| |
|-------------------->| |
---------------------> | SYN+ACK, MPC |------------------->|
SYN+ACK, MPC | | SYN+ACK |
---------------------> | |<-------------------|
SYN+ACK |<--------------------| ACK |
| ACK, MPC | |
<--------------------- | | |
ACK
<-------------------
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 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)
skipping to change at page 15, line 11 skipping to change at page 14, line 14
The Client and the Transport Converter MUST send the fixed-sized The Client and the Transport Converter MUST send the fixed-sized
header, shown in Figure 9, as the first four bytes of the bytestream. header, shown in Figure 9, as the first four bytes of the bytestream.
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
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Version | Total Length | Unassigned | | Version | Total Length | Unassigned |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
Figure 9: The fixed-sized header of the Convert protocol Figure 9: The Fixed-Sized Header of the Convert Protocol
The Version is encoded as an 8 bits unsigned integer value. This The Version is encoded as an 8 bits unsigned integer value. This
document specifies version 1. Version 0 is reserved by this document document specifies version 1. Version 0 is reserved by this document
and MUST NOT be used. and MUST NOT be used.
The Total Length is the number of 32 bits word, including the header, The Total Length is the number of 32 bits word, including the header,
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
skipping to change at page 16, line 38 skipping to change at page 15, line 38
| Type | Hex | Length | Description | | Type | Hex | Length | Description |
+------+-----+----------+------------------------------------------+ +------+-----+----------+------------------------------------------+
| 1 | 0x1 | 1 | Info TLV | | 1 | 0x1 | 1 | Info TLV |
| 10 | 0xA | Variable | Connect TLV | | 10 | 0xA | Variable | Connect TLV |
| 20 | 0x14| Variable | Extended TCP Header TLV | | 20 | 0x14| Variable | Extended TCP Header TLV |
| 21 | 0x15| Variable | Supported TCP Extensions TLV | | 21 | 0x15| Variable | Supported TCP Extensions TLV |
| 22 | 0x16| Variable | Cookie TLV | | 22 | 0x16| Variable | Cookie TLV |
| 30 | 0x1E| Variable | Error TLV | | 30 | 0x1E| Variable | Error TLV |
+------+-----+----------+------------------------------------------+ +------+-----+----------+------------------------------------------+
Figure 11: The TLVs used by the Convert protocol Figure 11: The TLVs used by the Convert Protocol
Type 0x0 is a reserved valued. Implementations MUST discard messages Type 0x0 is a reserved valued. Implementations MUST discard messages
with such TLV. with such TLV.
The Client can request the establishment of connections to servers by The Client can request the establishment of connections to servers by
using the Connect TLV (Section 4.2.5). If the connection can be using the Connect TLV (Section 4.2.5). If the connection can be
established with the final server, the Transport Converter replies established with the final server, the Transport Converter replies
with the Extended TCP Header TLV (Section 4.2.4). If not, the with the Extended TCP Header TLV (Section 4.2.4). If not, the
Transport Converter returns an Error TLV (Section 4.2.8) and then Transport Converter returns an Error TLV (Section 4.2.8) and then
closes the connection. closes the connection.
skipping to change at page 19, line 25 skipping to change at page 18, line 25
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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| 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 policy (e.g., rate- Upon reception of a Connect TLV, and absent any policy (e.g., rate-
limit) or resource exhaustion conditions, a Transport Converter limit) or resource exhaustion conditions, a Transport Converter
attempts to establish a connection to the address and port that it attempts to establish a connection to the address and port that it
contains. The Transport Converter MUST use by default the TCP contains. The Transport Converter MUST use by default the TCP
options that correspond to its local policy to establish this options that correspond to its local policy to establish this
connection. These are the options that it advertises in the connection. These are the options that it advertises in the
Supported TCP Extensions TLV. Supported TCP Extensions TLV.
Upon reception of an extended Connect TLV, and absent any rate limit Upon reception of an extended Connect TLV, and absent any rate limit
skipping to change at page 30, line 50 skipping to change at page 29, line 50
International Mobile Subscriber Identity (IMSI) to verify that a International Mobile Subscriber Identity (IMSI) to verify that a
user is allowed to benefit from the aggregation service. If that user is allowed to benefit from the aggregation service. If that
authorization fails, the Packet Data Protocol (PDP) context/bearer authorization fails, the Packet Data Protocol (PDP) context/bearer
will not be mounted. This method does not require any interaction will not be mounted. This method does not require any interaction
with the Transport Converter. with the Transport Converter.
o The network provider may enforce a policy based upon Access o The network provider may enforce a policy based upon Access
Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG)
to control the hosts that are authorized to communicate with a to control the hosts that are authorized to communicate with a
Transport Converter. These ACLs may be installed as a result of Transport Converter. These ACLs may be installed as a result of
RADIUS exchanges, e.g. [I-D.boucadair-radext-tcpm-converter]. RADIUS exchanges, e.g., [I-D.boucadair-radext-tcpm-converter].
This method does not require any interaction with the Transport This method does not require any interaction with the Transport
Converter. Converter.
o A device that embeds a Transport Converter may also host a RADIUS o A device that embeds a Transport Converter may also host a RADIUS
client that will solicit an AAA server to check whether client that will solicit an AAA server to check whether
connections received from a given source IP address are authorized connections received from a given source IP address are authorized
or not [I-D.boucadair-radext-tcpm-converter]. or not [I-D.boucadair-radext-tcpm-converter].
A first safeguard against the misuse of Transport Converter resources A first safeguard against the misuse of Transport Converter resources
by illegitimate users (e.g., users with access networks that are not by illegitimate users (e.g., users with access networks that are not
skipping to change at page 33, line 40 skipping to change at page 32, line 40
Although they could disagree with the contents of the document, we Although they could disagree with the contents of the document, we
would like to thank Joe Touch and Juliusz Chroboczek whose comments would like to thank Joe Touch and Juliusz Chroboczek whose comments
on the MPTCP mailing list have forced us to reconsider the design of on the MPTCP mailing list have forced us to reconsider the design of
the solution several times. the solution several times.
We would like to thank Raphael Bauduin, Stefano Secci, Anandatirtha We would like to thank Raphael Bauduin, Stefano Secci, Anandatirtha
Nandugudi and Gregory Vander Schueren for their help in preparing Nandugudi and Gregory Vander Schueren for their help in preparing
this document. Nandini Ganesh provided valuable feedback about the this document. Nandini Ganesh provided valuable feedback about the
handling of TFO and the error codes. Thanks to them. handling of TFO and the error codes. Thanks to them.
Thanks to Yuchung Cheng and Praveen Balasubramanian for the
discussion on supplying data in SYNs.
This document builds upon earlier documents that proposed various This document builds upon earlier documents that proposed various
forms of Multipath TCP proxies [I-D.boucadair-mptcp-plain-mode], forms of Multipath TCP proxies [I-D.boucadair-mptcp-plain-mode],
[I-D.peirens-mptcp-transparent] and [HotMiddlebox13b]. [I-D.peirens-mptcp-transparent] and [HotMiddlebox13b].
From [I-D.boucadair-mptcp-plain-mode]: From [I-D.boucadair-mptcp-plain-mode]:
Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi
Nishida, and Christoph Paasch for their valuable comments. Nishida, and Christoph Paasch for their valuable comments.
Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and
skipping to change at page 36, line 20 skipping to change at page 35, line 25
* Call out explicilty that data in SYNs are relayed by the * Call out explicilty that data in SYNs are relayed by the
Converter Converter
* Reiterate the scope * Reiterate the scope
* Hairpinning behavior can be disabled (policy-based) * Hairpinning behavior can be disabled (policy-based)
* Fix nits * Fix nits
11. References o 07:
11.1. Normative References * Update the text about supplying data in SYNs to make it clear
that a constraint defined in RFC793 is relaxed folloiwng the
same rationale as in RFC7413.
* Nits
* Added Appendix A on example Socket API changes
11. Example Socket API Changes to Support the 0-RTT Convert Protocol
11.1. Active Open (Client Side)
On the client side, the support of the 0-RTT Converter protocol does
not require any other changes than those identified in Appendix A of
[RFC7413]. Those modifications are already supported by multiple TCP
stacks.
As an example, on Linux, a client can send the 0-RTT Convert message
inside a SYN by using sendto with the MSG_FASTOPEN flag as shown in
the example below:
s = socket(AF_INET, SOCK_STREAM, 0);
sendto(s, buffer, buffer_len, MSG_FASTOPEN,
(struct sockaddr *) &server_addr, addr_len);
The client side of the Linux TCP TFO can be used in two different
modes depending on the host configuration (sysctl tcp_fastopen
variable):
o 0x1: (client) enables sending data in the opening SYN on the
client.
o 0x4: (client) send data in the opening SYN regardless of cookie
availability and without a cookie option.
By setting this configuration variable to 0x5, a Linux client using
the above code would send data inside the SYN without using a TFO
option.
11.2. Passive Open (Converter Side)
The Converter needs to enable the reception of data inside the SYN
independently of the utilisation of the TFO option. This implies
that the Transport Converter application cannot rely on the TFO
cookies to validate the reachability of the IP address that sent the
SYN. It must rely on other techniques, such as the Cookie TLV
described in this document, to verify this reachability.
[RFC7413] suggested the utilisation of a TCP_FASTOPEN socket option
the enable the reception of SYNs containing data. Later, Appendix A
of [RFC7413], mentionned:
Traditionally, accept() returns only after a socket is connected.
But, for a Fast Open connection, accept() returns upon receiving
SYN with a valid Fast Open cookie and data, and the data is available
to be read through, e.g., recvmsg(), read().
To support the 0-RTT Convert protocol, this behaviour should be
modified as follows:
Traditionally, accept() returns only after a socket is connected.
But, for a Fast Open connection, accept() returns upon receiving a
SYN with data, and the data is available to be read through, e.g.,
recvmsg(), read(). The application that receives such SYNs with data
must be able to validate the reachability of the source of the SYN
and also deal with replayed SYNs.
The Linux server side can be configured with the following sysctls:
o 0x2: (server) enables the server support, i.e., allowing data in a
SYN packet to be accepted and passed to the application before
3-way handshake finishes.
o 0x200: (server) accept data-in-SYN w/o any cookie option present.
However, this configuration is system-wide. This is convenient for
typical Transport Converter deployments where no other applications
relying on TFO are collocated on the same device.
Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added to
provide the same behaviour on a per socket basis. This enables a
single host to support both servers that require the TFO cookie and
servers that do not use it.
12. Differences with SOCKSv5
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
connections. The Client creates a connection to a SOCKS proxy,
exchanges authentication information and indicates the destination
address and port of the final server. At this point, the SOCKS proxy
creates a connection towards the final server and relays all data
between the two proxied connections. The operation of an
implementation based on SOCKSv5 is illustrated in Figure 22.
Client SOCKS Proxy Server
-------------------->
SYN
<--------------------
SYN+ACK
-------------------->
ACK
-------------------->
Version=5, Auth Methods
<--------------------
Method
-------------------->
Auth Request (unless "No auth" method negotiated)
<--------------------
Auth Response
-------------------->
Connect Server:Port -------------------->
SYN
<--------------------
SYN+ACK
<--------------------
Succeeded
-------------------->
Data1
-------------------->
Data1
<--------------------
Data2
<--------------------
Data2
Figure 22: Establishment of a TCP connection through a SOCKS proxy
without authentication
The Convert protocol also relays data between an upstream and a
downstream connection, but there are important differences with
SOCKSv5.
A first difference is that the Convert protocol exchanges all control
information during the three-way handshake. This reduces the
connection establishment delay compared to SOCKS that requires two or
more round-trip-times before the establishment of the downstream
connection towards the final destination. In today's Internet,
latency is a important metric and various protocols have been tuned
to reduce their latency [I-D.arkko-arch-low-latency]. A recently
proposed extension to SOCKS also leverages the TFO option
[I-D.olteanu-intarea-socks-6].
A second difference is that the Convert protocol explicitly takes the
TCP extensions into account. By using the Convert protocol, the
Client can learn whether a given TCP extension is supported by the
destination Server. This enables the Client to bypass the Transport
Converter when the destination supports the required TCP extension.
Neither SOCKS v5 [RFC1928] nor the proposed SOCKS v6
[I-D.olteanu-intarea-socks-6] provide such a feature.
A third difference is that a Transport Converter will only accept the
connection initiated by the Client provided that the downstream
connection is accepted by the Server. If the Server refuses the
connection establishment attempt from the Transport Converter, then
the upstream connection from the Client is rejected as well. This
feature is important for applications that check the availability of
a Server or use the time to connect as a hint on the selection of a
Server [RFC8305].
A fourth difference is that the Convert protocol only allows the
client to specify the address/port of the destination server and not
a DNS name. We evaluated an alternate design for the Connect TLV
that included the DNS name of the remote peer instead of its IP
address as in SOCKS [RFC1928]. However, that design was not adopted
because it induces both an extra load and increased delays on the
Transport Converter to handle and manage DNS resolution requests.
13. References
13.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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 38, line 5 skipping to change at page 41, line 18
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 13.2. Informative References
[ANRW17] Trammell, B., Kuhlewind, M., De Vaere, P., Learmonth, I., [ANRW17] Trammell, B., Kuhlewind, M., De Vaere, P., Learmonth, I.,
and G. Fairhurst, "Tracking transport-layer evolution with and G. Fairhurst, "Tracking transport-layer evolution with
PATHspider", Applied Networking Research Workshop 2017 PATHspider", Applied Networking Research Workshop 2017
(ANRW17) , July 2017. (ANRW17) , July 2017.
[Fukuda2011] [Fukuda2011]
Fukuda, K., "An Analysis of Longitudinal TCP Passive Fukuda, K., "An Analysis of Longitudinal TCP Passive
Measurements (Short Paper)", Traffic Monitoring and Measurements (Short Paper)", Traffic Monitoring and
Analysis. TMA 2011. Lecture Notes in Computer Science, vol Analysis. TMA 2011. Lecture Notes in Computer Science, vol
skipping to change at page 38, line 40 skipping to change at page 42, line 8
Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel,
D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R.,
Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., Vinapamula, S., Seo, S., Cloetens, W., Meyer, U.,
Contreras, L., and B. Peirens, "Extensions for Network- Contreras, L., and B. Peirens, "Extensions for Network-
Assisted MPTCP Deployment Models", draft-boucadair-mptcp- Assisted MPTCP Deployment Models", draft-boucadair-mptcp-
plain-mode-10 (work in progress), March 2017. plain-mode-10 (work in progress), March 2017.
[I-D.boucadair-radext-tcpm-converter] [I-D.boucadair-radext-tcpm-converter]
Boucadair, M. and C. Jacquenet, "RADIUS Extensions for Boucadair, M. and C. Jacquenet, "RADIUS Extensions for
0-RTT TCP Converters", draft-boucadair-radext-tcpm- 0-RTT TCP Converters", draft-boucadair-radext-tcpm-
converter-01 (work in progress), October 2018. converter-02 (work in progress), April 2019.
[I-D.boucadair-tcpm-dhc-converter] [I-D.boucadair-tcpm-dhc-converter]
Boucadair, M., Jacquenet, C., and R. K, "DHCP Options for Boucadair, M., Jacquenet, C., and R. K, "DHCP Options for
0-RTT TCP Converters", draft-boucadair-tcpm-dhc- 0-RTT TCP Converters", draft-boucadair-tcpm-dhc-
converter-01 (work in progress), October 2018. converter-02 (work in progress), April 2019.
[I-D.ietf-tcpinc-tcpcrypt]
Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic protection of TCP Streams
(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in
progress), December 2018.
[I-D.nam-mptcp-deployment-considerations] [I-D.nam-mptcp-deployment-considerations]
Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx, Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx,
W., and R. Skog, "Network-Assisted MPTCP: Use Cases, W., and R. Skog, "Network-Assisted MPTCP: Use Cases,
Deployment Scenarios and Operational Considerations", Deployment Scenarios and Operational Considerations",
draft-nam-mptcp-deployment-considerations-01 (work in draft-nam-mptcp-deployment-considerations-01 (work in
progress), December 2016. progress), December 2016.
[I-D.olteanu-intarea-socks-6] [I-D.olteanu-intarea-socks-6]
Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6", Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6",
draft-olteanu-intarea-socks-6-05 (work in progress), draft-olteanu-intarea-socks-6-06 (work in progress), March
October 2018. 2019.
[I-D.peirens-mptcp-transparent] [I-D.peirens-mptcp-transparent]
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..
skipping to change at page 41, line 14 skipping to change at page 44, line 25
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
Appendix A. Differences with SOCKSv5 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic Protection of TCP Streams
At a first glance, the solution proposed in this document could seem (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
similar to the SOCKS v5 protocol [RFC1928] which is used to proxy TCP <https://www.rfc-editor.org/info/rfc8548>.
connections. The Client creates a connection to a SOCKS proxy,
exchanges authentication information and indicates the destination
address and port of the final server. At this point, the SOCKS proxy
creates a connection towards the final server and relays all data
between the two proxied connections. The operation of an
implementation based on SOCKSv5 is illustrated in Figure 22.
Client SOCKS Proxy Server
-------------------->
SYN
<--------------------
SYN+ACK
-------------------->
ACK
-------------------->
Version=5, Auth Methods
<--------------------
Method
-------------------->
Auth Request (unless "No auth" method negotiated)
<--------------------
Auth Response
-------------------->
Connect Server:Port -------------------->
SYN
<--------------------
SYN+ACK
<--------------------
Succeeded
-------------------->
Data1
-------------------->
Data1
<--------------------
Data2
<--------------------
Data2
Figure 22: Establishment of a TCP connection through a SOCKS proxy
without authentication
The Convert protocol also relays data between an upstream and a
downstream connection, but there are important differences with
SOCKSv5.
A first difference is that the Convert protocol exchanges all control
information during the three-way handshake. This reduces the
connection establishment delay compared to SOCKS that requires two or
more round-trip-times before the establishment of the downstream
connection towards the final destination. In today's Internet,
latency is a important metric and various protocols have been tuned
to reduce their latency [I-D.arkko-arch-low-latency]. A recently
proposed extension to SOCKS also leverages the TFO option
[I-D.olteanu-intarea-socks-6].
A second difference is that the Convert protocol explicitly takes the
TCP extensions into account. By using the Convert protocol, the
Client can learn whether a given TCP extension is supported by the
destination Server. This enables the Client to bypass the Transport
Converter when the destination supports the required TCP extension.
Neither SOCKS v5 [RFC1928] nor the proposed SOCKS v6
[I-D.olteanu-intarea-socks-6] provide such a feature.
A third difference is that a Transport Converter will only accept the
connection initiated by the Client provided that the downstream
connection is accepted by the Server. If the Server refuses the
connection establishment attempt from the Transport Converter, then
the upstream connection from the Client is rejected as well. This
feature is important for applications that check the availability of
a Server or use the time to connect as a hint on the selection of a
Server [RFC8305].
A fourth difference is that the Convert protocol only allows the
client to specify the address/port of the destination server and not
a DNS name. We evaluated an alternate design for the Connect TLV
that included the DNS name of the remote peer instead of its IP
address as in SOCKS [RFC1928]. However, that design was not adopted
because it induces both an extra load and increased delays on the
Transport Converter to handle and manage DNS resolution requests.
Authors' Addresses Authors' Addresses
Olivier Bonaventure (editor) Olivier Bonaventure (editor)
Tessares Tessares
Email: Olivier.Bonaventure@tessares.net Email: Olivier.Bonaventure@tessares.net
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
 End of changes. 39 change blocks. 
271 lines changed or deleted 361 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/