draft-ietf-tcpm-converters-12.txt   draft-ietf-tcpm-converters-13.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: April 6, 2020 Orange Expires: April 24, 2020 Orange
S. Gundavelli S. Gundavelli
Cisco Cisco
S. Seo S. Seo
Korea Telecom Korea Telecom
B. Hesmans B. Hesmans
Tessares Tessares
October 04, 2019 October 22, 2019
0-RTT TCP Convert Protocol 0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-12 draft-ietf-tcpm-converters-13
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 April 6, 2020. This Internet-Draft will expire on April 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Network-Assisted Connections: The Rationale . . . . . . . 4 1.2. Network-Assisted Connections: The Rationale . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Architecture & Behaviors . . . . . . . . . . . . . . . . . . 7
3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 7 3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 7
3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 9 3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 9
3.3. Data Processing at the Transport Converter . . . . . . . 12 3.3. Data Processing at the Transport Converter . . . . . . . 12
3.4. Sample Examples of Outgoing Converter-Assisted Multipath 3.3.1. Base Behavior . . . . . . . . . . . . . . . . . . . . 12
TCP Connections . . . . . . . . . . . . . . . . . . . . . 14 3.3.2. Multipath TCP Specifics . . . . . . . . . . . . . . . 14
3.5. Sample Example of Incoming Converter-Assisted Multipath 4. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 15
TCP Connection . . . . . . . . . . . . . . . . . . . . . 16 4.1. Outgoing Converter-Assisted Multipath TCP Connections . . 15
4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 17 4.2. Incoming Converter-Assisted Multipath TCP Connection . . 16
4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 17 5. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 17
4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 18 5.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 18
4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 18 5.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 19 5.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 18
4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 20 5.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 19
4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 20 5.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 20
4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 21 5.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 20
4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 23 5.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 21
4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 23 5.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 23
4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 24 5.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 24
5. Compatibility of Specific TCP Options with the Conversion 5.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 24
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Compatibility of Specific TCP Options with the Conversion
5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 27 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 28 6.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 28
5.3. Selective Acknowledgments . . . . . . . . . . . . . . . . 28 6.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 29
5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 29 6.3. Selective Acknowledgments . . . . . . . . . . . . . . . . 29
5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 29 6.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 29 6.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 30
5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 30 6.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 30
5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 31
5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 30 6.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 31 6.9. TCP Experimental Options . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 7. Interactions with Middleboxes . . . . . . . . . . . . . . . . 31
7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 32
7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 33 8.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 33
7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 33 8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 34
7.5. Multipath TCP-specific Considerations . . . . . . . . . . 34 8.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8.5. Multipath TCP-specific Considerations . . . . . . . . . . 34
8.1. Convert Service Port Number . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 35 9.1. Convert Service Port Number . . . . . . . . . . . . . . . 35
8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 35 9.2. The Convert Protocol (Convert) Parameters . . . . . . . . 35
8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 35 9.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 35
8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 36 9.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.2.3. Convert Error Messages . . . . . . . . . . . . . . . 36
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 39 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Example Socket API Changes to Support the 0-RTT Appendix B. Example Socket API Changes to Support the 0-RTT
Convert Protocol . . . . . . . . . . . . . . . . . . 44 Convert Protocol . . . . . . . . . . . . . . . . . . 44
B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 44 B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 44
B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 44 B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 45
Appendix C. Some Design Considerations . . . . . . . . . . . . . 45 Appendix C. Some Design Considerations . . . . . . . . . . . . . 46
Appendix D. Address Preservation vs. Address Sharing . . . . . . 46 Appendix D. Address Preservation vs. Address Sharing . . . . . . 46
D.1. Address Preservation . . . . . . . . . . . . . . . . . . 46 D.1. Address Preservation . . . . . . . . . . . . . . . . . . 46
D.2. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . 47 D.2. Address/Prefix Sharing . . . . . . . . . . . . . . . . . 47
Appendix E. Differences with SOCKSv5 . . . . . . . . . . . . . . 48 Appendix E. Differences with SOCKSv5 . . . . . . . . . . . . . . 48
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
1.1. The Problem 1.1. The Problem
Transport protocols like TCP evolve regularly [RFC7414]. TCP has Transport protocols like TCP evolve regularly [RFC7414]. TCP has
skipping to change at page 4, line 21 skipping to change at page 4, line 22
(or servers) can be upgraded at a faster pace than the transport (or servers) can be upgraded at a faster pace than the transport
stack running on servers (or clients). In those situations, clients stack running on servers (or clients). In those situations, clients
would typically want to benefit from the features of an improved would typically want to benefit from the features of an improved
transport protocol even if the servers have not yet been upgraded and transport protocol even if the servers have not yet been upgraded and
conversely. Some assistance from the network to make use of these conversely. Some assistance from the network to make use of these
features is valuable. For example, Performance Enhancing Proxies features is valuable. For example, Performance Enhancing Proxies
[RFC3135], and other service functions have been deployed as [RFC3135], and other service functions have been deployed as
solutions to improve TCP performance over links with specific solutions to improve TCP performance over links with specific
characteristics. characteristics.
Recent examples of TCP extensions include Multipath TCP [RFC6824] or Recent examples of TCP extensions include Multipath TCP (MPTCP)
TCPINC [RFC8548]. Those extensions provide features that are [RFC6824] or TCPINC [RFC8548]. Those extensions provide features
interesting for clients such as wireless devices. With Multipath that are interesting for clients such as wireless devices. With
TCP, those devices could seamlessly use WLAN (Wireless Local Area Multipath TCP, those devices could seamlessly use WLAN (Wireless
Network) and cellular networks, for bonding purposes, faster hand- Local Area Network) and cellular networks, for bonding purposes,
overs, or better resiliency. Unfortunately, deploying those faster hand-overs, or better resiliency. Unfortunately, deploying
extensions on both a wide range of clients and servers remains those extensions on both a wide range of clients and servers remains
difficult. difficult.
More recently, 5G bonding experimentation has been conducted into More recently, 5G bonding experimentation has been conducted into
global range of the incumbent 4G (LTE) connectivity using newly global range of the incumbent 4G (LTE) connectivity using newly
devised clients and a Multipath TCP proxy. Even if the 5G and the 4G devised clients and a Multipath TCP proxy. Even if the 5G and the 4G
bonding relying upon Multipath TCP increases the bandwidth, it is as bonding relying upon Multipath TCP increases the bandwidth, it is as
well crucial to minimize latency for all the way between endhosts well crucial to minimize latency for all the way between endhosts
regardless of whether intermediate nodes are inside or outside of the regardless of whether intermediate nodes are inside or outside of the
mobile core. In order to handle URLLC (Ultra Reliable Low Latency mobile core. In order to handle URLLC (Ultra Reliable Low Latency
Communication) for the next generation mobile network, Multipath TCP Communication) for the next generation mobile network, Multipath TCP
skipping to change at page 5, line 5 skipping to change at page 5, line 6
This document specifies an application proxy, called Transport This document specifies an application proxy, called Transport
Converter. A Transport Converter is a function that is installed by Converter. A Transport Converter is a function that is installed by
a network operator to aid the deployment of TCP extensions and to a network operator to aid the deployment of TCP extensions and to
provide the benefits of such extensions to clients. A Transport provide the benefits of such extensions to clients. A Transport
Converter may provide conversion service for one or more TCP Converter may provide conversion service for one or more TCP
extensions. Which TCP extensions are eligible to the conversion extensions. Which TCP extensions are eligible to the conversion
service is deployment-specific. The conversion service is provided service is deployment-specific. The conversion service is provided
by means of the 0-RTT TCP Convert Protocol (Convert), that is an by means of the 0-RTT TCP Convert Protocol (Convert), that is an
application-layer protocol which uses TCP port number TBA application-layer protocol which uses TCP port number TBA
(Section 8). (Section 9).
The Convert Protocol provides 0-RTT (Zero Round-Trip Time) conversion The Convert Protocol provides 0-RTT (Zero Round-Trip Time) conversion
service since no extra delay is induced by the protocol compared to service since no extra delay is induced by the protocol compared to
connections that are not proxied. Particularly, the Convert Protocol connections that are not proxied. Particularly, the Convert Protocol
does not require extra signaling setup delays before making use of does not require extra signaling setup delays before making use of
the conversion service. The Convert Protocol does not require any the conversion service. The Convert Protocol does not require any
encapsulation (no tunnels, whatsoever). encapsulation (no tunnels, whatsoever).
The Transport Converter adheres to the main principles drawn in The Transport Converter adheres to the main principles drawn in
[RFC1919]. In particular, a Transport Converter achieves the [RFC1919]. In particular, a Transport Converter achieves the
skipping to change at page 6, line 13 skipping to change at page 6, line 16
configured with one or a list of Transport Converters (statically or configured with one or a list of Transport Converters (statically or
through protocols such as [I-D.boucadair-tcpm-dhc-converter]). through protocols such as [I-D.boucadair-tcpm-dhc-converter]).
Configuration means are outside the scope of this document. Configuration means are outside the scope of this document.
The use of a Transport Converter means that there is no end-to-end The use of a Transport Converter means that there is no end-to-end
transport connection between the client and server. This could transport connection between the client and server. This could
potentially create problems in some scenarios such as those discussed potentially create problems in some scenarios such as those discussed
in Section 4 of [RFC3135]. Some of these problems may not be in Section 4 of [RFC3135]. Some of these problems may not be
applicable, for example, a Transport Converter can inform a client by applicable, for example, a Transport Converter can inform a client by
means of Network Failure (65) or Destination Unreachable (97) error means of Network Failure (65) or Destination Unreachable (97) error
messages (Section 4.2.8) that it encounters a failure problem; the messages (Section 5.2.8) that it encounters a failure problem; the
client can react accordingly. An endpoint, or its network client can react accordingly. An endpoint, or its network
administrator, can assess the benefit provided by the Transport administrator, can assess the benefit provided by the Transport
Converter service versus the risk. This is one reason why the Converter service versus the risk. This is one reason why the
Transport Converter functionality has to be explicitly requested by Transport Converter functionality has to be explicitly requested by
an endpoint. an endpoint.
This document is organized as follows. First, Section 3 provides a This document is organized as follows. First, Section 3 provides a
brief explanation of the operation of Transport Converters. Then, brief explanation of the operation of Transport Converters. Then,
Section 4 describes the Convert Protocol. Section 5 discusses how Section 5 describes the Convert Protocol. Section 6 discusses how
Transport Converters can be used to support different TCP extensions. Transport Converters can be used to support different TCP extensions.
Section 6 then discusses the interactions with middleboxes, while Section 7 then discusses the interactions with middleboxes, while
Section 7 focuses on the security considerations. Section 8 focuses on the security considerations.
Appendix B describes how a TCP stack would need to support the Appendix B describes how a TCP stack would need to support the
protocol described in this document. Appendix C records some protocol described in this document. Appendix C records some
considerations that impacted the design of the protocol. Appendix E considerations that impacted the design of the protocol. Appendix E
provides a comparison with SOCKS proxies that are already used to provides a comparison with SOCKS proxies that are already used to
deploy Multipath TCP in some cellular networks (Section 2.2 of deploy Multipath TCP in some cellular networks (Section 2.2 of
[RFC8041]). [RFC8041]).
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The information shown between brackets in the figures refers to The information shown between brackets in the figures refers to
Convert Protocol messages described in Section 4. Convert Protocol messages described in Section 5.
Only the exchange of control messages is depicted in the figures. Only the exchange of control messages is depicted in the figures.
3. Architecture 3. Architecture & Behaviors
3.1. Functional Elements 3.1. Functional Elements
The Convert Protocol considers three functional elements: The Convert Protocol considers three functional elements:
o Clients; o Clients;
o Transport Converters; o Transport Converters;
o Servers. o Servers.
skipping to change at page 7, line 40 skipping to change at page 7, line 43
| |
customer-facing interface : Internet-facing interface customer-facing interface : Internet-facing interface
| |
Figure 1: A Transport Converter Proxies Data between Pairs of TCP Figure 1: A Transport Converter Proxies Data between Pairs of TCP
Connections Connections
"Client" refers to a software instance embedded on a host that can "Client" refers to a software instance embedded on a host that can
reach a Transport Converter via its customer-facing interface. The reach a Transport Converter via its customer-facing interface. The
"Client" can initiate connections via a Transport Converter (referred "Client" can initiate connections via a Transport Converter (referred
to as outgoing connections (Section 3.4)). Also, the "Client" can to as outgoing connections (Section 4.1)). Also, the "Client" can
accept incoming connections via a Transport Converter (referred to as accept incoming connections via a Transport Converter (referred to as
incoming connections (Section 3.5)). incoming connections (Section 4.2)).
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 12, line 20 skipping to change at page 12, line 20
includes a cookie. However, the utilization of this option consumes includes a cookie. However, the utilization of this option consumes
space in the limited TCP header. Furthermore, there are situations, space in the limited TCP header. Furthermore, there are situations,
as noted in Section 7.3 of [RFC7413] where it is possible to accept as noted in Section 7.3 of [RFC7413] where it is possible to accept
the payload of SYN packets without creating additional security risks the payload of SYN packets without creating additional security risks
such as a network where addresses cannot be spoofed and the Transport such as a network where addresses cannot be spoofed and the Transport
Converter only serves a set of hosts that are identified by these Converter only serves a set of hosts that are identified by these
addresses. addresses.
For these reasons, this specification does not mandate the use of the For these reasons, this specification does not mandate the use of the
TCP Fast Open option when the Client sends a connection establishment TCP Fast Open option when the Client sends a connection establishment
packet towards a Transport Converter. The Convert protocol includes packet towards a Transport Converter. The Convert Protocol includes
an optional Cookie TLV that provides similar protection as the TCP an optional Cookie TLV that provides similar protection as the TCP
Fast Open option without consuming space in the extended TCP header. Fast Open option without consuming space in the extended TCP header.
In particular, this design allows for the use of longer cookies. In particular, this design allows for the use of longer cookies.
If the downstream (or upstream) connection fails for some reason If the downstream (or upstream) connection fails for some reason
(excessive retransmissions, reception of an RST segment, etc.), then (excessive retransmissions, reception of an RST segment, etc.), then
the Converter should force the tear-down of the upstream (or the Converter should force the tear-down of the upstream (or
downstream) connection. downstream) connection.
The same reasoning applies when the upstream connection ends. In The same reasoning applies when the upstream connection ends. In
this case, the Converter should also terminate the downstream this case, the Converter should also terminate the downstream
connection by using FIN segments. If the downstream connection connection by using FIN segments. If the downstream connection
terminates with the exchange of FIN segments, the Converter should terminates with the exchange of FIN segments, the Converter should
initiate a graceful termination of the upstream connection. initiate a graceful termination of the upstream connection.
3.3. Data Processing at the Transport Converter 3.3. Data Processing at the Transport Converter
3.3.1. Base Behavior
As mentioned in Section 3.2, the Transport Converter acts as a TCP As mentioned in Section 3.2, the Transport Converter acts as a TCP
proxy between the upstream connection (i.e., between the Client and proxy between the upstream connection (i.e., between the Client and
the Transport Converter) and the downstream connection (i.e., between the Transport Converter) and the downstream connection (i.e., between
the Transport Converter and the Server). the Transport Converter and the Server).
The control messages, discussed in Section 4, establish state The control messages, discussed in Section 5, establish state
(called, transport session entry) in the Transport Converter that (called, transport session entry) in the Transport Converter that
will enable it to proxy between the two TCP connections. will enable it to proxy between the two TCP connections.
The Transport Converter uses the transport session entry to proxy The Transport Converter uses the transport session entry to proxy
packets belonging to the connection. An implementation example of a packets belonging to the connection. An implementation example of a
transport session entry for TCP connections is shown in Figure 7. transport session entry for TCP connections is shown in Figure 7.
(C,c) <--> (T,t), (S,s), Lifetime (C,c) <--> (T,t), (S,s), Lifetime
Where: Where:
* C and c are the source IP address and source port number * C and c are the source IP address and source port number
used by the Client for the usptream connection. used by the Client for the upstream connection.
* S and s are the Server's IP address and port number. * S and s are the Server's IP address and port number.
* T and t are the source IP address and source port number * T and t are the source IP address and source port number
used by the Transport Converter to proxy the connection. used by the Transport Converter to proxy the connection.
* Lifetime is the validity lifetime of the entry as assigned * Lifetime is the validity lifetime of the entry as assigned
by the Converter. by the Converter.
Figure 7: An Example of Transport Session Entry (TCP) Figure 7: An Example of Transport Session Entry (TCP)
Note that for the Multipath TCP case, the Transport Converter
identifies an MPTCP connection by means, e.g., of the token assigned
to the MPTCP connection. Subflows can be added or deleted during the
lifetime of an MPTCP connection between a Client and a Transport
Converter. The identification of each subflow that belongs to an
MPTCP connection are also part of the transport session entry. An
implementation example of a transport session entry maintained by a
Transport Converter for Multipath TCP connections is shown in
Figure 7. As a reminder, the Convert TLVs are only exchanged during
the establishment of the initial subflow.
token, {(C1,c1), .., (Cn, cn)} <--> (T,t), (S,s), Lifetime
Where:
* Token is a locally unique identifier given to a (upstream)
multipath connection by the Transport Converter.
* Ci and ci are the source IP address and source port number
used by the Client for a subflow of a (upstream) Multipath TCP
connection.
* S and s are the Server's IP address and port number.
* T and t are the source IP address and source port number
used by the Transport Converter to proxy the connection.
* Lifetime is the validity lifetime of the entry as assigned
by the Converter.
Figure 8: An Example of Transport Session Entry (Multipath TCP)
Clients send packets bound to connections eligible to the conversion Clients send packets bound to connections eligible to the conversion
service to the provisioned Transport Converter using TBA as service to the provisioned Transport Converter using TBA as
destination port number. This applies for both control messages and destination port number. This applies for both control messages and
data. Additional information is supplied by Clients to the Transport data. Additional information is supplied by Clients to the Transport
Converter by means of Convert messages as detailed in Section 4. Converter by means of Convert messages as detailed in Section 5.
User data can be included in SYN or non-SYN messages. User data is User data can be included in SYN or non-SYN messages. User data is
unambiguously distinguished from Convert TLVs by a Transport unambiguously distinguished from Convert TLVs by a Transport
Converter owing to the Total Length field in the Convert messages Converter owing to the Convert Fixed Header in the Convert messages
(Section 4.1). These Convert TLVs are destined to the Transport (Section 5.1). These Convert TLVs are destined to the Transport
Convert and are, thus, removed by the Transport Converter when Convert and are, thus, removed by the Transport Converter when
proxying between the two connections. proxying between the two connections.
Upon receipt of a Non-SYN (or a secondary subflow for Multipath TCP) Upon receipt of a Non-SYN (or a secondary subflow for Multipath TCP)
on port number TBA by the Transport Converter from a Client, the on port number TBA by the Transport Converter from a Client, the
Converter checks if the packet matches an active transport session Converter checks if the packet matches an active transport session
entry. If no entry is found, the Transport Converter MUST silently entry. If no entry is found, the Transport Converter MUST silently
ignore the packet. If an entry is found, the user data is proxied to ignore the packet. If an entry is found, the user data is proxied to
the Server using the information stored in the corresponding the Server using the information stored in the corresponding
transport session entry. For example, transport session entry. For example, in reference to Figure 7, the
Transport Converter proxies the data received from (C, c) downstream
o In reference to Figure 7, the Transport Converter proxies the data using (T,t) as source transport address and (S,s) as destination
received from (C, c) downstream using (T,t) as source transport transport address.
address and (S,s) as destination transport address.
o In reference to Figure 8, the Transport Converter proxies the data
received from a new subflow of an existing Multipath TCP
connection (Cn, cn) downstream using (T,t) as source transport
address and (S,s) as destination transport address.
A similar process happens for data sent from the Server. The A similar process happens for data sent from the Server. The
Converter acts as a TCP proxy and sends the data to the Client Converter acts as a TCP proxy and sends the data to the Client
relying upon the information stored in a transport session entry. relying upon the information stored in a transport session entry.
Considerations that are specific to Multipath TCP are described in
Section 3.3.2.
A Transport Converter may operate in address preservation mode (that A Transport Converter may operate in address preservation mode (that
is, the Converter does not rewrite the source IP address (i.e., is, the Converter does not rewrite the source IP address (i.e.,
C==T)) or address sharing mode (that is, an address pool is shared C==T)) or address sharing mode (that is, an address pool is shared
among all Clients serviced by the Converter (i.e., C!=T)); refer to among all Clients serviced by the Converter (i.e., C!=T)); refer to
Appendix D for more details. Which behavior to use by a Transport Appendix D for more details. Which behavior to use by a Transport
Converter is deployment-specific. If address sharing mode is Converter is deployment-specific. If address sharing mode is
enabled, the Transport Converter MUST adhere to REQ-2 of [RFC6888] enabled, the Transport Converter MUST adhere to REQ-2 of [RFC6888]
which implies a default "IP address pooling" behavior of "Paired" (as which implies a default "IP address pooling" behavior of "Paired" (as
defined in Section 4.1 of [RFC4787]) must be supported. This defined in Section 4.1 of [RFC4787]) must be supported. This
behavior is meant to avoid breaking applications that depend on the behavior is meant to avoid breaking applications that depend on the
source address remaining constant. source address remaining constant.
3.4. Sample Examples of Outgoing Converter-Assisted Multipath TCP 3.3.2. Multipath TCP Specifics
Connections
As an example, let us consider how the Convert protocol can help the Note that for the Multipath TCP case, the Convert TLVs are only
exchanged during the establishment of the initial subflow.
The Transport Converter identifies an MPTCP connection by means,
e.g., of the token assigned to the MPTCP connection (Section 2.2 of
[RFC6824]). An implementation example of an MPTCP transport session
entry maintained by a Transport Converter is shown in Figure 8. The
entry needs to be updated whenever subflows are added to, or deleted
from, the MPTCP connection.
token, {(C1,c1), .., (Cn, cn)} <--> (T,t), (S,s), Lifetime
Where:
* Token is a locally unique identifier given to a (upstream)
multipath connection by the Transport Converter. The token
is a one-way hash of the MPTCP key.
* Ci and ci are the source IP address and source port number
used by the Client for a subflow of an (upstream) MPTCP
connection.
* S and s are the Server's IP address and port number.
* T and t are the source IP address and source port number
used by the Transport Converter to proxy the connection.
* Lifetime is the validity lifetime of the entry as assigned
by the Converter.
Figure 8: An Example of MPTCP Transport Session Entry
Upon receipt of a secondary subflow by the Transport Converter from a
Client, the Converter follows the same behavior specified in
Section 3.3.1 for processing Non-SYNs. For example, in reference to
Figure 8, the Transport Converter proxies the data received from a
new subflow of an existing Multipath TCP connection (Cn, cn)
downstream using (T,t) as source transport address and (S,s) as
destination transport address.
4. Sample Examples
4.1. Outgoing Converter-Assisted Multipath TCP Connections
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 9 describes the operation of the Transport Converter if the Figure 9 describes the operation of the Transport Converter if the
Server does not support Multipath TCP. Server does not support Multipath TCP.
skipping to change at page 16, line 20 skipping to change at page 16, line 32
|<------------------|<---------------------| |<------------------|<---------------------|
|SYN+ACK, | SYN+ACK, MPC | |SYN+ACK, | SYN+ACK, MPC |
|MPC [MPC supported]| | |MPC [MPC supported]| |
|------------------>|--------------------->| |------------------>|--------------------->|
| ACK, MPC | ACK, MPC | | ACK, MPC | ACK, MPC |
| ... | ... | | ... | ... |
Figure 10: Establishment of a Multipath TCP Connection Through a Figure 10: Establishment of a Multipath TCP Connection Through a
Converter Towards an MPTCP-capable Server Converter Towards an MPTCP-capable Server
3.5. Sample Example of Incoming Converter-Assisted Multipath TCP 4.2. 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 11. In order to support incoming connections is depicted in Figure 11. 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
connection. connection.
Typically, the Client sends a PCP request to the Converter asking to Typically, the Client sends a PCP request to the Converter asking to
skipping to change at page 17, line 24 skipping to change at page 17, line 36
| ACK, MPC | ACK | | ACK, MPC | ACK |
| ... | ... | | ... | ... |
Figure 11: Establishment of an Incoming Multipath TCP Connection Figure 11: Establishment of an Incoming Multipath TCP Connection
through a Transport Converter through a Transport Converter
It is out of scope of this document to define specific Convert TLVs It is out of scope of this document to define specific Convert TLVs
to manage incoming connections. These TLVs can be defined in a to manage incoming connections. These TLVs can be defined in a
separate document. separate document.
4. The Convert Protocol (Convert) 5. The Convert Protocol (Convert)
This section defines the Convert protocol (Convert, for short) This section defines the Convert Protocol (Convert, for short)
messages that are exchanged between a Client and a Transport messages that are exchanged between a Client and a Transport
Converter. Converter.
By default, the Transport Converter listens on TCP port number TBA By default, the Transport Converter listens on TCP port number TBA
for Convert messages from Clients. for Convert messages from Clients.
Convert messages may appear only in a SYN, SYN+ACK, or ACK. Convert messages may appear only in a SYN, SYN+ACK, or ACK.
Convert messages MUST be included as the first bytes of the Convert messages MUST be included as the first bytes of the
bytestream. All Convert messages starts with a 32 bits long fixed bytestream. All Convert messages starts with a 32 bits long fixed
header (Section 4.1) followed by one or more Convert TLVs (Type, header (Section 5.1) followed by one or more Convert TLVs (Type,
Length, Value) (Section 4.2). Length, Value) (Section 5.2).
4.1. The Convert Fixed Header 5.1. The Convert Fixed Header
The Convert Protocol uses a 32 bits long fixed header that is sent by The Convert Protocol uses a 32 bits long fixed header that is sent by
both the Client and the Transport Converter over each established both the Client and the Transport Converter over each established
connection. This header indicates both the version of the protocol connection. This header indicates both the version of the protocol
used and the length of the Convert message. used and the length of the Convert message.
The Client and the Transport Converter MUST send the fixed-sized The Client and the Transport Converter MUST send the fixed-sized
header, shown in Figure 12, as the first four bytes of the header, shown in Figure 12, as the first four bytes of the
bytestream. 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 12: The Fixed-Sized Header of the Convert Protocol Figure 12: The Convert Fixed Header
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
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 is Data added by the Convert Protocol to the TCP bytestream is
unambiguously distinguished from payload data by the Total Length unambiguously distinguished from payload data by the Total Length
field in the Convert messages. field in the Convert messages.
4.2. Convert TLVs 5.2. Convert TLVs
4.2.1. Generic Convert TLV Format 5.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 format depicted in Figure 13. using the generic TLV format depicted in Figure 13.
The length of all TLVs used by the Convert protocol is always a The length of all TLVs used by the Convert Protocol is always a
multiple of four bytes. All TLVs are aligned on 32 bits boundaries. multiple of four bytes. All TLVs are aligned on 32 bits boundaries.
All TLV fields are encoded using the network byte order. All TLV fields are encoded using the network byte order.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Type | Length | Value ... | | Type | Length | Value ... |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
// ... (optional) Value // // ... (optional) Value //
+---------------------------------------------------------------+ +---------------------------------------------------------------+
skipping to change at page 19, line 14 skipping to change at page 19, line 24
The Length field covers Type, Length, and Value fields. It is The Length field covers Type, Length, and Value fields. It is
expressed in units of 32 bits words. If necessary, Value MUST be expressed in units of 32 bits words. If necessary, Value MUST be
padded with zeroes so that the length of the TLV is a multiple of 32 padded with zeroes so that the length of the TLV is a multiple of 32
bits. bits.
A given TLV MUST only appear once on a connection. If two or more A given TLV MUST only appear once on a connection. If two or more
instances of the same TLV are exchanged over a Convert connection, instances of the same TLV are exchanged over a Convert connection,
the associated TCP connections MUST be closed. the associated TCP connections MUST be closed.
4.2.2. Summary of Supported Convert TLVs 5.2.2. Summary of Supported Convert TLVs
This document specifies the following Convert TLVs: This document specifies the following Convert TLVs:
+------+-----+----------+------------------------------------------+ +------+-----+----------+------------------------------------------+
| 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 14: The TLVs used by the Convert Protocol Figure 14: 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 typically sends in the first connection it established The Client typically sends in the first connection it established
with a Transport Converter the Info TLV (Section 4.2.3) to learn its with a Transport Converter the Info TLV (Section 5.2.3) to learn its
capabilities. Assuming the Client is authorized to invoke the capabilities. Assuming the Client is authorized to invoke the
Transport Converter, the latter replies with the Supported TCP Transport Converter, the latter replies with the Supported TCP
Extensions TLV (Section 4.2.4). Extensions TLV (Section 5.2.4).
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 5.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.6). If not, the with the Extended TCP Header TLV (Section 5.2.6). If not, the
Transport Converter returns an Error TLV (Section 4.2.8) and then Transport Converter returns an Error TLV (Section 5.2.8) and then
closes the connection. closes the connection.
When an error is encountered an Error TLV with the appropriate error When an error is encountered an Error TLV with the appropriate error
code MUST be returned by the Transport Converter. code MUST be returned by the Transport Converter.
4.2.3. The Info TLV 5.2.3. The Info TLV
The Info TLV (Figure 15) is an optional TLV which can be sent by a The Info TLV (Figure 15) is an optional TLV which can be sent by a
Client to request the TCP extensions that are supported by a Client to request the TCP extensions that are supported by a
Transport Converter. It is typically sent on the first connection Transport Converter. It is typically sent on the first connection
that a Client establishes with a Transport Converter to learn its that a Client establishes with a Transport Converter to learn its
capabilities. Assuming a Client is entitled to invoke the Transport capabilities. Assuming a Client is entitled to invoke the Transport
Converter, the latter replies with the Supported TCP Extensions TLV Converter, the latter replies with the Supported TCP Extensions TLV
described in Section 4.2.4. described in Section 5.2.4.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Type=0x1 | Length | Zero | | Type=0x1 | Length | Zero |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
Figure 15: The Info TLV Figure 15: The Info TLV
4.2.4. Supported TCP Extensions TLV 5.2.4. Supported TCP Extensions TLV
The Supported TCP Extensions TLV (Figure 16) is used by a Transport The Supported TCP Extensions TLV (Figure 16) is used by a Transport
Converter to announce the TCP options for which it provides a Converter to announce the TCP options for which it provides a
conversion service. A Transport Converter SHOULD include in this conversion service. A Transport Converter SHOULD include in this
list the TCP options that it accepts from Clients; these options are list the TCP options that it accepts from Clients; these options are
included by the Transport Converter in the SYN packets that it sends included by the Transport Converter in the SYN packets that it sends
to initiate connections. to initiate connections.
Each supported TCP option is encoded with its TCP option Kind listed Each supported TCP option is encoded with its TCP option Kind listed
in the "TCP Parameters" registry maintained by IANA. in the "TCP Parameters" registry maintained by IANA.
skipping to change at page 21, line 12 skipping to change at page 21, line 28
TCP option Kinds 0, 1, and 2 defined in [RFC0793] are supported by TCP option Kinds 0, 1, and 2 defined in [RFC0793] are supported by
all TCP implementations and thus MUST NOT appear in this list. all TCP implementations and thus MUST NOT appear in this list.
The list of Supported TCP Extensions is padded with 0 to end on a 32 The list of Supported TCP Extensions is padded with 0 to end on a 32
bits boundary. bits boundary.
For example, if the Transport Converter supports Multipath TCP, For example, if the Transport Converter supports Multipath TCP,
Kind=30 will be present in the Supported TCP Extensions TLV that it Kind=30 will be present in the Supported TCP Extensions TLV that it
returns in response to Info TLV. returns in response to Info TLV.
4.2.5. Connect TLV 5.2.5. Connect TLV
The Connect TLV (Figure 17) is used to request the establishment of a The Connect TLV (Figure 17) is used to request the establishment of a
connection via a Transport Converter. This connection can be from or connection via a Transport Converter. This connection can be from or
to a Client. to a Client.
The 'Remote Peer Port' and 'Remote Peer IP Address' fields contain The 'Remote Peer Port' and 'Remote Peer IP Address' fields contain
the destination port number and IP address of the Server, for the destination port number and IP address of the Server, for
outgoing connections. For incoming connections destined to a Client outgoing connections. For incoming connections destined to a Client
serviced via a Transport Converter, these fields convey the source serviced via a Transport Converter, these fields convey the source
port number and IP address. port number and IP address.
skipping to change at page 23, line 4 skipping to change at page 23, line 20
would have used according to its local policies. For the TCP options would have used according to its local policies. For the TCP options
that are listed without an optional value, the Transport Converter that are listed without an optional value, the Transport Converter
MUST generate its own value. For the TCP options that are included MUST generate its own value. For the TCP options that are included
in the 'TCP Options' field with an optional value, it MUST copy the in the 'TCP Options' field with an optional value, it MUST copy the
entire option for use in the connection with the destination peer. entire option for use in the connection with the destination peer.
This feature is required to support TCP Fast Open. This feature is required to support TCP Fast Open.
The Transport Converter may discard a Connect TLV request for various The Transport Converter may discard a Connect TLV request for various
reasons (e.g., authorization failed, out of resources, invalid reasons (e.g., authorization failed, out of resources, invalid
address type). An error message indicating the encountered error is address type). An error message indicating the encountered error is
returned to the requesting Client (Section 4.2.8). In order to returned to the requesting Client (Section 5.2.8). In order to
prevent denial-of-service attacks, error messages sent to a Client prevent denial-of-service attacks, error messages sent to a Client
SHOULD be rate-limited. SHOULD be rate-limited.
4.2.6. Extended TCP Header TLV 5.2.6. Extended TCP Header TLV
The Extended TCP Header TLV (Figure 19) is used by the Transport The Extended TCP Header TLV (Figure 19) is used by the Transport
Converter to send to the Client the extended TCP header that was Converter to send to the Client the extended TCP header that was
returned by the Server in the SYN+ACK packet. This TLV is only sent returned by the Server in the SYN+ACK packet. This TLV is only sent
if the Client sent a Connect TLV to request the establishment of a if the Client sent a Connect TLV to request the establishment of a
connection. connection.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
skipping to change at page 23, line 33 skipping to change at page 24, line 5
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 19: The Extended TCP Header TLV Figure 19: The Extended TCP Header TLV
The Returned Extended TCP header field is a copy of the extended The Returned Extended TCP header field is a copy of the extended
header that was received in the SYN+ACK by the Transport Converter. header that was received in the SYN+ACK by the Transport Converter.
The Unassigned field MUST be set to zero by the sender and ignored by The Unassigned field MUST be set to zero by the sender and ignored by
the receiver. These bits are available for future use [RFC8126]. the receiver. These bits are available for future use [RFC8126].
4.2.7. The Cookie TLV 5.2.7. The Cookie TLV
The Cookie TLV (Figure 20 is an optional TLV which use is similar to The Cookie TLV (Figure 20 is an optional TLV which use is similar to
the TCP Fast Open Cookie [RFC7413]. A Transport Converter may want the TCP Fast Open Cookie [RFC7413]. A Transport Converter may want
to verify that a Client can receive the packets that it sends to to verify that a Client can receive the packets that it sends to
prevent attacks from spoofed addresses. This verification can be prevent attacks from spoofed addresses. This verification can be
done by using a Cookie that is bound to, for example, the IP done by using a Cookie that is bound to, for example, the IP
address(es) of the Client. This Cookie can be configured on the address(es) of the Client. This Cookie can be configured on the
Client by means that are outside of this document or provided by the Client by means that are outside of this document or provided by the
Transport Converter as follows. Transport Converter as follows.
skipping to change at page 24, line 27 skipping to change at page 24, line 47
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Type=0x16 | Length | Zero | | Type=0x16 | Length | Zero |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
/ Opaque Cookie / / Opaque Cookie /
/ ... / / ... /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 20: The Cookie TLV Figure 20: The Cookie TLV
4.2.8. Error TLV 5.2.8. Error TLV
The Error TLV (Figure 21) is meant to provide information about some The Error TLV (Figure 21) is meant to provide information about some
errors that occurred during the processing of a Convert message. errors that occurred during the processing of a Convert message.
This TLV has a variable length. Upon reception of an Error TLV, a This TLV has a variable length. Upon reception of an Error TLV, a
Client MUST close the associated connection. Client MUST close the associated connection.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+----------------+--------------+ +---------------+---------------+----------------+--------------+
| Type=0x1E | Length | Error Code | Value | | Type=0x1E | Length | Error Code | Value |
skipping to change at page 27, line 40 skipping to change at page 28, line 22
| 32 | 0x20 | Not Authorized | | 32 | 0x20 | Not Authorized |
| 33 | 0x21 | Unsupported TCP Option | | 33 | 0x21 | Unsupported TCP Option |
| 64 | 0x40 | Resource Exceeded | | 64 | 0x40 | Resource Exceeded |
| 65 | 0x41 | Network Failure | | 65 | 0x41 | Network Failure |
| 96 | 0x60 | Connection Reset | | 96 | 0x60 | Connection Reset |
| 97 | 0x61 | Destination Unreachable | | 97 | 0x61 | Destination Unreachable |
+-------+------+-----------------------------------------------+ +-------+------+-----------------------------------------------+
Figure 22: Convert Error Values Figure 22: Convert Error Values
5. Compatibility of Specific TCP Options with the Conversion Service 6. Compatibility of Specific TCP Options with the Conversion Service
In this section, we discuss how several standard track TCP options In this section, we discuss how several standard track TCP options
can be supported through the Convert protocol. The non-standard can be supported through the Convert Protocol. The non-standard
track options and the experimental options will be discussed in other track options and the experimental options will be discussed in other
documents. documents.
5.1. Base TCP Options 6.1. Base TCP Options
Three TCP options were initially defined in [RFC0793]: End-of-Option Three TCP options were initially defined in [RFC0793]: End-of-Option
List (Kind=0), No-Operation (Kind=1) and Maximum Segment Size List (Kind=0), No-Operation (Kind=1) and Maximum Segment Size
(Kind=2). The first two options are mainly used to pad the TCP (Kind=2). The first two options are mainly used to pad the TCP
header. There is no reason for a client to request a Transport header. There is no reason for a client to request a Transport
Converter to specifically send these options towards the final Converter to specifically send these options towards the final
destination. destination.
The Maximum Segment Size option (Kind=2) is used by a host to The Maximum Segment Size option (Kind=2) is used by a host to
indicate the largest segment that it can receive over each indicate the largest segment that it can receive over each
connection. This value is function of the stack that terminates the connection. This value is function of the stack that terminates the
TCP connection. There is no reason for a Client to request a TCP connection. There is no reason for a Client to request a
Transport Converter to advertise a specific MSS value to a remote Transport Converter to advertise a specific MSS value to a remote
server. server.
A Transport Converter MUST ignore options with Kind=0, 1 or 2 if they A Transport Converter MUST ignore options with Kind=0, 1 or 2 if they
appear in a Connect TLV. It MUST NOT announce them in a Supported appear in a Connect TLV. It MUST NOT announce them in a Supported
TCP Extensions TLV. TCP Extensions TLV.
5.2. Window Scale (WS) 6.2. Window Scale (WS)
The Window Scale (WS) option (Kind=3) is defined in [RFC7323]. As The Window Scale (WS) option (Kind=3) is defined in [RFC7323]. As
for the MSS option, the window scale factor that is used for a for the MSS option, the window scale factor that is used for a
connection strongly depends on the TCP stack that handles the connection strongly depends on the TCP stack that handles the
connection. When a Transport Converter opens a TCP connection connection. When a Transport Converter opens a TCP connection
towards a remote server on behalf of a Client, it SHOULD use a WS towards a remote server on behalf of a Client, it SHOULD use a WS
option with a scaling factor that corresponds to the configuration of option with a scaling factor that corresponds to the configuration of
its stack. A local configuration MAY allow for WS option in the its stack. A local configuration MAY allow for WS option in the
proxied message to be function of the scaling factor of the incoming proxied message to be function of the scaling factor of the incoming
connection. connection.
There is no benefit from a deployment viewpoint in enabling a Client There is no benefit from a deployment viewpoint in enabling a Client
of a Transport Converter to specifically request the utilization of of a Transport Converter to specifically request the utilization of
the WS option (Kind=3) with a specific scaling factor towards a the WS option (Kind=3) with a specific scaling factor towards a
remote Server. For this reason, a Transport Converter MUST ignore remote Server. For this reason, a Transport Converter MUST ignore
option Kind=3 if it appears in a Connect TLV. It MUST NOT announce option Kind=3 if it appears in a Connect TLV. It MUST NOT announce
it in a Supported TCP Extensions TLV. it in a Supported TCP Extensions TLV.
5.3. Selective Acknowledgments 6.3. Selective Acknowledgments
Two distinct TCP options were defined to support selective Two distinct TCP options were defined to support selective
acknowledgments in [RFC2018]. This first one, SACK Permitted acknowledgments in [RFC2018]. This first one, SACK Permitted
(Kind=4), is used to negotiate the utilization of selective (Kind=4), is used to negotiate the utilization of selective
acknowledgments during the three-way handshake. The second one, SACK acknowledgments during the three-way handshake. The second one, SACK
(Kind=5), carries the selective acknowledgments inside regular (Kind=5), carries the selective acknowledgments inside regular
segments. segments.
The SACK Permitted option (Kind=4) MAY be advertised by a Transport The SACK Permitted option (Kind=4) MAY be advertised by a Transport
Converter in the Supported TCP Extensions TLV. Clients connected to Converter in the Supported TCP Extensions TLV. Clients connected to
this Transport Converter MAY include the SACK Permitted option in the this Transport Converter MAY include the SACK Permitted option in the
Connect TLV. Connect TLV.
The SACK option (Kind=5) cannot be used during the three-way The SACK option (Kind=5) cannot be used during the three-way
handshake. For this reason, a Transport Converter MUST ignore option handshake. For this reason, a Transport Converter MUST ignore option
Kind=5 if it appears in a Connect TLV. It MUST NOT announce it in a Kind=5 if it appears in a Connect TLV. It MUST NOT announce it in a
TCP Supported Extensions TLV. TCP Supported Extensions TLV.
5.4. Timestamp 6.4. Timestamp
The Timestamp option was initially defined in [RFC1323] and later The Timestamp option was initially defined in [RFC1323] and later
refined in [RFC7323]. It can be used during the three-way handshake refined in [RFC7323]. It can be used during the three-way handshake
to negotiate the utilization of timestamps during the TCP connection. to negotiate the utilization of timestamps during the TCP connection.
It is notably used to improve round-trip-time estimations and to It is notably used to improve round-trip-time estimations and to
provide protection against wrapped sequence numbers (PAWS). As for provide protection against wrapped sequence numbers (PAWS). As for
the WS option, the timestamps are a property of a connection and the WS option, the timestamps are a property of a connection and
there is limited benefit in enabling a client to request a Transport there is limited benefit in enabling a client to request a Transport
Converter to use the timestamp option when establishing a connection Converter to use the timestamp option when establishing a connection
to a remote server. Furthermore, the timestamps that are used by TCP to a remote server. Furthermore, the timestamps that are used by TCP
stacks are specific to each stack and there is no benefit in enabling stacks are specific to each stack and there is no benefit in enabling
a client to specify the timestamp value that a Transport Converter a client to specify the timestamp value that a Transport Converter
could use to establish a connection to a remote server. could use to establish a connection to a remote server.
A Transport Converter MAY advertise the Timestamp option (Kind=8) in A Transport Converter MAY advertise the Timestamp option (Kind=8) in
the TCP Supported Extensions TLV. The clients connected to this the TCP Supported Extensions TLV. The clients connected to this
Transport Converter MAY include the Timestamp option in the Connect Transport Converter MAY include the Timestamp option in the Connect
TLV but without any timestamp. TLV but without any timestamp.
5.5. Multipath TCP 6.5. Multipath TCP
The Multipath TCP options are defined in [RFC6824]. [RFC6824] The Multipath TCP options are defined in [RFC6824]. [RFC6824]
defines one variable length TCP option (Kind=30) that includes a sub- defines one variable length TCP option (Kind=30) that includes a sub-
type field to support several Multipath TCP options. There are type field to support several Multipath TCP options. There are
several operational use cases where clients would like to use several operational use cases where clients would like to use
Multipath TCP through a Transport Converter [IETFJ16]. However, none Multipath TCP through a Transport Converter [IETFJ16]. However, none
of these use cases require the Client to specify the content of the of these use cases require the Client to specify the content of the
Multipath TCP option that the Transport Converter should send to a Multipath TCP option that the Transport Converter should send to a
remote server. remote server.
A Transport Converter which supports Multipath TCP conversion service A Transport Converter which supports Multipath TCP conversion service
MUST advertise the Multipath TCP option (Kind=30) in the Supported MUST advertise the Multipath TCP option (Kind=30) in the Supported
TCP Extensions TLV. Clients serviced by this Transport Converter may TCP Extensions TLV. Clients serviced by this Transport Converter may
include the Multipath TCP option in the Connect TLV but without any include the Multipath TCP option in the Connect TLV but without any
content. content.
5.6. TCP Fast Open 6.6. TCP Fast Open
The TCP Fast Open cookie option (Kind=34) is defined in [RFC7413]. The TCP Fast Open cookie option (Kind=34) is defined in [RFC7413].
There are two different usages of this option that need to be There are two different usages of this option that need to be
supported by Transport Converters. The first utilization of the TCP supported by Transport Converters. The first utilization of the TCP
Fast Open cookie option is to request a cookie from the server. In Fast Open cookie option is to request a cookie from the server. In
this case, the option is sent with an empty cookie by the client and this case, the option is sent with an empty cookie by the client and
the server returns the cookie. The second utilization of the TCP the server returns the cookie. The second utilization of the TCP
Fast Open cookie option is to send a cookie to the server. In this Fast Open cookie option is to send a cookie to the server. In this
case, the option contains a cookie. case, the option contains a cookie.
skipping to change at page 30, line 21 skipping to change at page 31, line 7
Converter has advertised the support for TCP Fast Open in its Converter has advertised the support for TCP Fast Open in its
Supported TCP Extensions TLV, it needs to be able to process two Supported TCP Extensions TLV, it needs to be able to process two
types of Connect TLV. If such a Transport Converter receives a types of Connect TLV. If such a Transport Converter receives a
Connect TLV with the TCP Fast Open cookie option that does not Connect TLV with the TCP Fast Open cookie option that does not
contain a cookie, it MUST add an empty TCP Fast Open cookie option in contain a cookie, it MUST add an empty TCP Fast Open cookie option in
the SYN sent to the remote server. If such a Transport Converter the SYN sent to the remote server. If such a Transport Converter
receives a Connect TLV with the TCP Fast Open cookie option that receives a Connect TLV with the TCP Fast Open cookie option that
contains a cookie, it MUST copy the TCP Fast Open cookie option in contains a cookie, it MUST copy the TCP Fast Open cookie option in
the SYN sent to the remote server. the SYN sent to the remote server.
5.7. TCP User Timeout 6.7. TCP User Timeout
The TCP User Timeout option is defined in [RFC5482]. The associated The TCP User Timeout option is defined in [RFC5482]. The associated
TCP option (Kind=28) does not appear to be widely deployed. TCP option (Kind=28) does not appear to be widely deployed.
5.8. TCP-AO 6.8. TCP-AO
TCP-AO [RFC5925] provides a technique to authenticate all the packets TCP-AO [RFC5925] provides a technique to authenticate all the packets
exchanged over a TCP connection. Given the nature of this extension, exchanged over a TCP connection. Given the nature of this extension,
it is unlikely that the applications that require their packets to be it is unlikely that the applications that require their packets to be
authenticated end-to-end would want their connections to pass through authenticated end-to-end would want their connections to pass through
a converter. For this reason, we do not recommend the support of the a converter. For this reason, we do not recommend the support of the
TCP-AO option by Transport Converters. The only use cases where it TCP-AO option by Transport Converters. The only use cases where it
could make sense to combine TCP-AO and the solution in this document could make sense to combine TCP-AO and the solution in this document
are those where the TCP-AO-NAT extension [RFC6978] is in use. are those where the TCP-AO-NAT extension [RFC6978] is in use.
A Transport Converter MUST NOT advertise the TCP-AO option (Kind=29) A Transport Converter MUST NOT advertise the TCP-AO option (Kind=29)
in the Supported TCP Extensions TLV. If a Transport Converter in the Supported TCP Extensions TLV. If a Transport Converter
receives a Connect TLV that contains the TCP-AO option, it MUST receives a Connect TLV that contains the TCP-AO option, it MUST
reject the establishment of the connection with error code set to reject the establishment of the connection with error code set to
"Unsupported TCP Option", except if the TCP-AO-NAT option is used. "Unsupported TCP Option", except if the TCP-AO-NAT option is used.
5.9. TCP Experimental Options 6.9. TCP Experimental Options
The TCP Experimental options are defined in [RFC4727]. Given the The TCP Experimental options are defined in [RFC4727]. Given the
variety of semantics for these options and their experimental nature, variety of semantics for these options and their experimental nature,
it is impossible to discuss them in details in this document. it is impossible to discuss them in details in this document.
6. Interactions with Middleboxes 7. Interactions with Middleboxes
The Convert Protocol is designed to be used in networks that do not The Convert Protocol is designed to be used in networks that do not
contain middleboxes that interfere with TCP. Under such conditions, contain middleboxes that interfere with TCP. Under such conditions,
it is assumed that the network provider ensures that all involved on- it is assumed that the network provider ensures that all involved on-
path nodes are not breaking TCP signals (e.g., strip TCP options, path nodes are not breaking TCP signals (e.g., strip TCP options,
discard some SYNs, etc.). discard some SYNs, etc.).
Nevertheless, and in order to allow for a robust service, this Nevertheless, and in order to allow for a robust service, this
section describes how a Client can detect middlebox interference and section describes how a Client can detect middlebox interference and
stop using the Transport Converter affected by this interference. stop using the Transport Converter affected by this interference.
skipping to change at page 31, line 47 skipping to change at page 32, line 30
message is received, the Client may continue to use this Converter. message is received, the Client may continue to use this Converter.
As explained in [RFC7413], some CGNs (Carrier Grade NATs) can affect As explained in [RFC7413], some CGNs (Carrier Grade NATs) can affect
the operation of TFO if they assign different IP addresses to the the operation of TFO if they assign different IP addresses to the
same end host. Such CGNs could affect the operation of the cookie same end host. Such CGNs could affect the operation of the cookie
validation used by the Convert Protocol. As a reminder CGNs, enabled validation used by the Convert Protocol. As a reminder CGNs, enabled
on the path between a Client and a Transport Converter, must adhere on the path between a Client and a Transport Converter, must adhere
to the address preservation defined in [RFC6888]. See also the to the address preservation defined in [RFC6888]. See also the
discussion in Section 7.1 of [RFC7413]. discussion in Section 7.1 of [RFC7413].
7. Security Considerations 8. Security Considerations
7.1. Privacy & Ingress Filtering
8.1. Privacy & Ingress Filtering
The Transport Converter may have access to privacy-related The Transport Converter may have access to privacy-related
information (e.g., subscriber credentials). The Transport Converter information (e.g., subscriber credentials). The Transport Converter
is designed to not leak such sensitive information outside a local is designed to not leak such sensitive information outside a local
domain. domain.
Given its function and its location in the network, a Transport Given its function and its location in the network, a Transport
Converter has access to the payload of all the packets that it Converter has access to the payload of all the packets that it
processes. As such, it MUST be protected as a core IP router (e.g., processes. As such, it MUST be protected as a core IP router (e.g.,
[RFC1812]). [RFC1812]).
Furthermore, ingress filtering policies MUST be enforced at the Furthermore, ingress filtering policies MUST be enforced at the
network boundaries [RFC2827]. network boundaries [RFC2827].
This document assumes that all network attachments are managed by the This document assumes that all network attachments are managed by the
same administrative entity. Therefore, enforcing anti-spoofing same administrative entity. Therefore, enforcing anti-spoofing
filters at these network ensures that hosts are not sending traffic filters at these network ensures that hosts are not sending traffic
with spoofed source IP addresses. with spoofed source IP addresses.
7.2. Authorization 8.2. Authorization
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
skipping to change at page 33, line 26 skipping to change at page 34, line 5
Converter Converter
Note: X2':x2' may be equal to Note: X2':x2' may be equal to
X2:x2 X2:x2
Figure 23: Hairpinning Example Figure 23: 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 8.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
from the Client or if the Transport Converter retransmits the SYN. from the Client or if the Transport Converter retransmits the SYN.
To mitigate such attacks, the Transport Converter SHOULD rate limit To mitigate such attacks, the Transport Converter SHOULD rate limit
the number of pending requests for a given Client. It SHOULD also the number of pending requests for a given Client. It SHOULD also
avoid sending to remote Servers SYNs that are significantly longer avoid sending to remote Servers SYNs that are significantly longer
than the SYN received from the Client. Finally, the Transport than the SYN received from the Client. Finally, the Transport
Converter SHOULD only retransmit a SYN to a Server after having Converter SHOULD only retransmit a SYN to a Server after having
received a retransmitted SYN from the corresponding Client. Means to received a retransmitted SYN from the corresponding Client. Means to
protect against SYN flooding attacks MUST also be enabled [RFC4987]. protect against SYN flooding attacks MUST also be enabled [RFC4987].
7.4. Traffic Theft 8.4. Traffic Theft
Traffic theft is a risk if an illegitimate Converter is inserted in Traffic theft is a risk if an illegitimate Converter is inserted in
the path. Indeed, inserting an illegitimate Converter in the the path. Indeed, inserting an illegitimate Converter in the
forwarding path allows traffic interception and can therefore provide forwarding path allows traffic interception and can therefore provide
access to sensitive data issued by or destined to a host. Converter access to sensitive data issued by or destined to a host. Converter
discovery and configuration are out of scope of this document. discovery and configuration are out of scope of this document.
7.5. Multipath TCP-specific Considerations 8.5. Multipath TCP-specific Considerations
Multipath TCP-related security threats are discussed in [RFC6181] and Multipath TCP-related security threats are discussed in [RFC6181] and
[RFC6824]. [RFC6824].
The operator that manages the various network attachments (including The operator that manages the various network attachments (including
the Transport Converters) can enforce authentication and the Transport Converters) can enforce authentication and
authorization policies using appropriate mechanisms. For example, a authorization policies using appropriate mechanisms. For example, a
non-exhaustive list of methods to achieve authorization is provided non-exhaustive list of methods to achieve authorization is provided
hereafter: hereafter:
skipping to change at page 34, line 45 skipping to change at page 35, line 21
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
managed by the same provider that operates the Transport Converter) managed by the same provider that operates the Transport Converter)
is the Transport Converter to reject Multipath TCP connections is the Transport Converter to reject Multipath TCP connections
received on its Internet-facing interfaces. Only Multipath TCP received on its Internet-facing interfaces. Only Multipath TCP
connections received on the customer-facing interfaces of a Transport connections received on the customer-facing interfaces of a Transport
Converter will be accepted. Converter will be accepted.
8. IANA Considerations 9. IANA Considerations
8.1. Convert Service Port Number 9.1. Convert Service Port Number
IANA is requested to assign a TCP port number (TBA) for the Convert IANA is requested to assign a TCP port number (TBA) for the Convert
Protocol from the "Service Name and Transport Protocol Port Number Protocol from the "Service Name and Transport Protocol Port Number
Registry" available at https://www.iana.org/assignments/service- Registry" available at https://www.iana.org/assignments/service-
names-port-numbers/service-names-port-numbers.xhtml. names-port-numbers/service-names-port-numbers.xhtml.
Service Name: convert Service Name: convert
Port Number: TBD Port Number: TBD
Transport Protocol(s): TCP Transport Protocol(s): TCP
Description: 0-RTT TCP Convert Protocol Description: 0-RTT TCP Convert Protocol
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Reference: RFC XXXX Reference: RFC XXXX
8.2. The Convert Protocol (Convert) Parameters 9.2. The Convert Protocol (Convert) Parameters
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 9.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 IETF Review (Section 4.8 of [RFC8126]). 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 9.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 IETF Review. o The values in the range 1-127 can be assigned via IETF Review.
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.
skipping to change at page 36, line 17 skipping to change at page 36, line 39
+---------+--------------------------------------+-------------+ +---------+--------------------------------------+-------------+
| 0 | Reserved | [This-RFC] | | 0 | Reserved | [This-RFC] |
| 1 | Info TLV | [This-RFC] | | 1 | Info TLV | [This-RFC] |
| 10 | Connect TLV | [This-RFC] | | 10 | Connect TLV | [This-RFC] |
| 20 | Extended TCP Header TLV | [This-RFC] | | 20 | Extended TCP Header TLV | [This-RFC] |
| 21 | Supported TCP Extension TLV | [This-RFC] | | 21 | Supported TCP Extension TLV | [This-RFC] |
| 22 | Cookie TLV | [This-RFC] | | 22 | Cookie TLV | [This-RFC] |
| 30 | Error TLV | [This-RFC] | | 30 | Error TLV | [This-RFC] |
+---------+--------------------------------------+-------------+ +---------+--------------------------------------+-------------+
8.2.3. Convert Error Messages 9.2.3. Convert Error Messages
IANA is requested to create the "Convert Errors" sub-registry. Codes IANA is requested to create the "Convert Errors" sub-registry. Codes
in this registry are assigned as a function of the error type. Four in this registry are assigned as a function of the error type. Four
types are defined; the following ranges are reserved for each of types are defined; the following ranges are reserved for each of
these types: these types:
o Message validation and processing errors: 0-31 o Message validation and processing errors: 0-31
o Client-side errors: 32-63 o Client-side errors: 32-63
skipping to change at page 37, line 22 skipping to change at page 37, line 34
| 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 24: The Convert Error Codes Figure 24: The Convert Error Codes
9. References 10. References
9.1. Normative References 10.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 39, line 5 skipping to change at page 39, 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>.
9.2. Informative References 10.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 39, line 45 skipping to change at page 40, line 13
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-02 (work in progress), April 2019. 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-02 (work in progress), April 2019. converter-03 (work in progress), October 2019.
[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",
skipping to change at page 42, line 37 skipping to change at page 42, line 48
2019, <https://www.3gpp.org/ftp/Specs/ 2019, <https://www.3gpp.org/ftp/Specs/
archive/23_series/23.501/>. archive/23_series/23.501/>.
Appendix A. Change Log Appendix A. Change Log
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 6 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 o 04 to -05: Integrate a lot of feedback from implementors who have
worked on client and server side implementations. The main worked on client and server side implementations. The main
modifications are the following : modifications are the following :
* TCP Fast Open is not strictly required anymore. Several * TCP Fast Open is not strictly required anymore. Several
implementors expressed concerns about this requirement. The implementors expressed concerns about this requirement. The
TFO Cookie protects from some attack scenarios that affect open TFO Cookie protects from some attack scenarios that affect open
servers like web servers. The Convert protocol is different servers like web servers. The Convert Protocol is different
and as discussed in RFC7413, there are different ways to and as discussed in RFC7413, there are different ways to
protect from such attacks. Instead of using a TFO cookie protect from such attacks. Instead of using a TFO cookie
inside the TCP options, which consumes precious space in the inside the TCP options, which consumes precious space in the
extended TCP header, this version supports the utilization of a extended TCP header, this version supports the utilization of a
Cookie that is placed in the SYN payload. This provides the Cookie that is placed in the SYN payload. This provides the
same level of protection as a TFO Cookie in environments were same level of protection as a TFO Cookie in environments were
such protection is required. such protection is required.
* the Bootstrap procedure has been simplified based on feedback * the Bootstrap procedure has been simplified based on feedback
from implementors from implementors
skipping to change at page 44, line 13 skipping to change at page 44, line 23
* Added Appendix A on example Socket API changes * Added Appendix A on example Socket API changes
o 08: o 08:
* Added short discussion on the termination of connections * Added short discussion on the termination of connections
o 09: o 09:
* Address various comments received during last call * Address various comments received during last call
o 10-13:
* Changes to address the comments from Phil: Add a new section to
group data plane considerations in one place + add a new
appendix with more details on address modes + rearrange the
MPTCP text.
Appendix B. Example Socket API Changes to Support the 0-RTT Convert Appendix B. Example Socket API Changes to Support the 0-RTT Convert
Protocol Protocol
B.1. Active Open (Client Side) B.1. Active Open (Client Side)
On the client side, the support of the 0-RTT Converter protocol does On the client side, the support of the 0-RTT Converter protocol does
not require any other changes than those identified in Appendix A of not require any other changes than those identified in Appendix A of
[RFC7413]. Those modifications are already supported by multiple TCP [RFC7413]. Those modifications are already supported by multiple TCP
stacks. stacks.
skipping to change at page 45, line 16 skipping to change at page 45, line 33
[RFC7413] suggested the utilization of a TCP_FASTOPEN socket option [RFC7413] suggested the utilization of a TCP_FASTOPEN socket option
the enable the reception of SYNs containing data. Later, Appendix A the enable the reception of SYNs containing data. Later, Appendix A
of [RFC7413], mentioned: of [RFC7413], mentioned:
Traditionally, accept() returns only after a socket is connected. Traditionally, accept() returns only after a socket is connected.
But, for a Fast Open connection, accept() returns upon receiving But, for a Fast Open connection, accept() returns upon receiving
SYN with a valid Fast Open cookie and data, and the data is available SYN with a valid Fast Open cookie and data, and the data is available
to be read through, e.g., recvmsg(), read(). to be read through, e.g., recvmsg(), read().
To support the 0-RTT Convert protocol, this behavior should be To support the 0-RTT Convert Protocol, this behavior should be
modified as follows: modified as follows:
Traditionally, accept() returns only after a socket is connected. Traditionally, accept() returns only after a socket is connected.
But, for a Fast Open connection, accept() returns upon receiving a 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., SYN with data, and the data is available to be read through, e.g.,
recvmsg(), read(). The application that receives such SYNs with data recvmsg(), read(). The application that receives such SYNs with data
must be able to validate the reachability of the source of the SYN must be able to validate the reachability of the source of the SYN
and also deal with replayed SYNs. and also deal with replayed SYNs.
The Linux server side can be configured with the following sysctls: The Linux server side can be configured with the following sysctls:
skipping to change at page 45, line 47 skipping to change at page 46, line 18
Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added to Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added to
provide the same behavior on a per socket basis. This enables a provide the same behavior on a per socket basis. This enables a
single host to support both servers that require the TFO cookie and single host to support both servers that require the TFO cookie and
servers that do not use it. servers that do not use it.
Appendix C. Some Design Considerations Appendix C. Some Design Considerations
Several implementors expressed concerns about the use of TFO. As a Several implementors expressed concerns about the use of TFO. As a
reminder, the TFO Cookie protects from some attack scenarios that reminder, the TFO Cookie protects from some attack scenarios that
affect open servers like web servers. The Convert protocol is affect open servers like web servers. The Convert Protocol is
different and, as discussed in RFC7413, there are different ways to different and, as discussed in RFC7413, there are different ways to
protect from such attacks. Instead of using a TFO cookie inside the protect from such attacks. Instead of using a TFO cookie inside the
TCP options, which consumes precious space in the extended TCP TCP options, which consumes precious space in the extended TCP
header, the Convert protocol supports the utilization of a Cookie header, the Convert Protocol supports the utilization of a Cookie
that is placed in the SYN payload. This provides the same level of that is placed in the SYN payload. This provides the same level of
protection as a TFO Cookie in environments were such protection is protection as a TFO Cookie in environments were such protection is
required. required.
Error messages are not included in RST segments but sent in the Error messages are not included in RST segments but sent in the
bytestream. Implementors have indicated that processing such bytestream. Implementors have indicated that processing such
segments on clients was difficult on some platforms. This change segments on clients was difficult on some platforms. This change
simplifies client implementations. simplifies client implementations.
Appendix D. Address Preservation vs. Address Sharing Appendix D. Address Preservation vs. Address Sharing
skipping to change at page 47, line 38 skipping to change at page 47, line 38
Figure 25: Example of Address Preservation Figure 25: Example of Address Preservation
The Transport Converter must be on the forwarding path of incoming The Transport Converter must be on the forwarding path of incoming
traffic. Because the same (destination) IP address is used for both traffic. Because the same (destination) IP address is used for both
proxied and non-proxied connections, the Transport Converter should proxied and non-proxied connections, the Transport Converter should
not drop incoming packets it intercepts if no matching entry is found not drop incoming packets it intercepts if no matching entry is found
for the packets. Unless explicitly configured otherwise, such for the packets. Unless explicitly configured otherwise, such
packets are forwarded according to the instructions of a local packets are forwarded according to the instructions of a local
forwarding table. forwarding table.
D.2. IPv4 Address Sharing D.2. Address/Prefix Sharing
A pool of global IPv4 addresses is provisioned to the Transport A pool of global IPv4 addresses is provisioned to the Transport
Converter along with possible instructions about the address sharing Converter along with possible instructions about the address sharing
ratio to apply (see Appendix B of [RFC6269]). An address is thus ratio to apply (see Appendix B of [RFC6269]). An address is thus
shared among multiple clients. shared among multiple clients.
Likewise, rewriting the source IPv6 prefix [RFC6296] may be used to Likewise, rewriting the source IPv6 prefix [RFC6296] may be used to
ease redirection of incoming IPv6 traffic towards the appropriate ease redirection of incoming IPv6 traffic towards the appropriate
Transport Converter. A pool of IPv6 prefixes is then provisioned to Transport Converter. A pool of IPv6 prefixes is then provisioned to
the Transport Converter for this purpose. the Transport Converter for this purpose.
Adequate forwarding policies are enforced so that traffic destined to Adequate forwarding policies are enforced so that traffic destined to
an address of such pool is intercepted by the appropriate Transport an address of such pool is intercepted by the appropriate Transport
Converter. Unlike Appendix D.1, the Transport Converter drops Converter. Unlike Appendix D.1, the Transport Converter drops
incoming packets which do match an active transport session entry. incoming packets which do not match an active transport session
entry.
An example is shown in Figure 26. An example is shown in Figure 26.
Transport Transport
Client Converter Server Client Converter Server
@:C @:Tc|Te @:S @:C @:Tc|Te @:S
| | | | | |
|src:C dst:Tc|src:Te dst:S| |src:C dst:Tc|src:Te dst:S|
|-------SYN [->S:port]------->|-------SYN------->| |-------SYN [->S:port]------->|-------SYN------->|
skipping to change at page 49, line 43 skipping to change at page 49, line 43
Data1 Data1
<-------------------- <--------------------
Data2 Data2
<-------------------- <--------------------
Data2 Data2
Figure 27: Establishment of a TCP connection through a SOCKS proxy Figure 27: 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 exchanges all control A first difference is that the Convert Protocol exchanges all control
information during the three-way handshake. This reduces the information during the three-way handshake. This reduces the
connection establishment delay compared to SOCKS that requires two or connection establishment delay compared to SOCKS that requires two or
more round-trip-times before the establishment of the downstream more round-trip-times before the establishment of the downstream
connection towards the final destination. In today's Internet, connection towards the final destination. In today's Internet,
latency is a important metric and various protocols have been tuned latency is a important metric and various protocols have been tuned
to reduce their latency [I-D.arkko-arch-low-latency]. A recently to reduce their latency [I-D.arkko-arch-low-latency]. A recently
proposed extension to SOCKS leverages the TFO option proposed extension to SOCKS 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
connection initiated by the Client provided that the downstream connection initiated by the Client provided that the downstream
connection is accepted by the Server. If the Server refuses the connection is accepted by the Server. If the Server refuses the
connection establishment attempt from the Transport Converter, then connection establishment attempt from the Transport Converter, then
the upstream connection from the Client is rejected as well. This the upstream connection from the Client is rejected as well. This
feature is important for applications that check the availability of 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 a Server or use the time to connect as a hint on the selection of a
Server [RFC8305]. Server [RFC8305].
A fourth difference is that the Convert protocol only allows the A fourth difference is that the Convert Protocol only allows the
client to specify the address/port of the destination server and not client to specify the address/port of the destination server and not
a DNS name. We evaluated an alternate design for the Connect TLV a DNS name. We evaluated an alternate design for the Connect TLV
that included the DNS name of the remote peer instead of its IP that included the DNS name of the remote peer instead of its IP
address as in SOCKS [RFC1928]. However, that design was not adopted address as in SOCKS [RFC1928]. However, that design was not adopted
because it induces both an extra load and increased delays on the because it induces both an extra load and increased delays on the
Transport Converter to handle and manage DNS resolution requests. Transport Converter to handle and manage DNS resolution requests.
Acknowledgments Acknowledgments
Although they could disagree with the contents of the document, we Although they could disagree with the contents of the document, we
 End of changes. 91 change blocks. 
179 lines changed or deleted 199 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/