1.1. The Problem

Transport protocols like TCP evolve regularly [RFC7414]. TCP has been improved in different ways. Some improvements such as changing the initial window size [RFC6928] or modifying the congestion control scheme can be applied independently on Clients and Servers. Other improvements such as Selective Acknowledgments [RFC2018] or large windows [RFC7323] require a new TCP option or changing the semantics of some fields in the TCP header. These modifications must be deployed on both Clients and Servers to be actually used on the Internet. Experience with the latter class of TCP extensions reveals that their deployment can require many years. Fukuda reports in [Fukuda2011] results of a decade of measurements showing the deployment of Selective Acknowledgments, Window Scale, and TCP Timestamps. [ANRW17] describes measurements showing that TCP Fast Open (TFO) [RFC7413] is still not widely deployed.¶

There are some situations where the transport stack used on Clients (or Servers) can be upgraded at a faster pace than the transport stack running on Servers (or Clients). In those situations, Clients (or Servers) would typically want to benefit from the features of an improved transport protocol even if the Servers (or Clients) have not yet been upgraded. Some assistance from the network to make use of these features is valuable. For example, Performance Enhancing Proxies [RFC3135] and other service functions have been deployed as solutions to improve TCP performance over links with specific characteristics.¶

Recent examples of TCP extensions include Multipath TCP (MPTCP) [RFC8684] or tcpcrypt [RFC8548]. Those extensions provide features that are interesting for Clients such as wireless devices. With Multipath TCP, those devices could seamlessly use Wireless Local Area Network (WLAN) and cellular networks for bonding purposes, faster hand-overs, or better resiliency. Unfortunately, deploying those extensions on both a wide range of Clients and Servers remains difficult.¶

More recently, 5G bonding experimentation has been conducted into global range of the incumbent 4G (LTE) connectivity using newly devised Clients and a Multipath TCP proxy. Even if the 5G and 4G bonding (that relies upon Multipath TCP) increases the bandwidth, it is also crucial to minimize latency entirely between end hosts regardless of whether intermediate nodes are inside or outside of the mobile core. In order to handle Ultra-Reliable Low Latency Communication (URLLC) for the next-generation mobile network, Multipath TCP and its proxy mechanism such as the one used to provide Access Traffic Steering, Switching, and Splitting (ATSSS) must be optimized to reduce latency [TS23501].¶

1.2. Network-Assisted Connections: The Rationale

This document specifies an application proxy called Transport Converter. A Transport Converter is a function that is installed by a network operator to aid the deployment of TCP extensions and to provide the benefits of such extensions to Clients in particular. A Transport Converter may provide conversion service for one or more TCP extensions. Which TCP extensions are eligible for the conversion service is deployment specific. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert), which is an application-layer protocol that uses a specific TCP port number on the Converter.¶

The Convert Protocol provides Zero Round-Trip Time (0-RTT) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Particularly, the Convert Protocol does not require extra signaling setup delays before making use of the conversion service. The Convert Protocol does not require any encapsulation (no tunnels, whatsoever).¶

The Transport Converter adheres to the main steps drawn in Section 3 of [RFC1919]. In particular, a Transport Converter achieves the following:¶

• Listening for Client sessions;¶
• Receiving the address of the Server from the Client;¶
• Setting up a session to the Server;¶
• Relaying control messages and data between the Client and the Server;¶
• Performing access controls according to local policies.¶

The main advantage of network-assisted conversion services is that they enable new TCP extensions to be used on a subset of the path between endpoints, which encourages the deployment of these extensions. Furthermore, the Transport Converter allows the Client and the Server to directly negotiate TCP extensions for the sake of native support along the full path.¶

The Convert Protocol is a generic mechanism to provide 0-RTT conversion service. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP. It is out of scope of this document to provide a comprehensive list of all potential conversion services. Applicability documents may be defined in the future.¶

This document does not assume that all the traffic is eligible for the network-assisted conversion service. Only a subset of the traffic will be forwarded to a Transport Converter according to a set of policies. These policies, and how they are communicated to endpoints, are out of scope. Furthermore, it is possible to bypass the Transport Converter to connect directly to the Servers that already support the required TCP extension(s).¶

This document assumes an explicit model in which a Client is configured with one or a list of Transport Converters (statically or through protocols such as [DHC-CONVERTER]). Configuration means are outside the scope of this document.¶

The use of a Transport Converter means that there is no end-to-end transport connection between the Client and Server. This could potentially create problems in some scenarios such as those discussed in Section 4 of [RFC3135]. Some of these problems may not be applicable. For example, a Transport Converter can inform a Client by means of Network Failure (65) or Destination Unreachable (97) error messages (Section 6.2.8) that it encounters a failure problem; the Client can react accordingly. An endpoint, or its network administrator, can assess the benefit provided by the Transport Converter service versus the risk. This is one reason why the Transport Converter functionality has to be explicitly requested by an endpoint.¶

This document is organized as follows:¶

• Section 3 provides a brief overview of the differences between the well-known SOCKS protocol and the 0-RTT TCP Convert Protocol.¶
• Section 4 provides a brief explanation of the operation of Transport Converters.¶
• Section 5 includes a set of sample examples to illustrate the overall behavior.¶
• Section 6 describes the Convert Protocol.¶
• Section 7 discusses how Transport Converters can be used to support different TCP extensions.¶
• Section 8 then discusses the interactions with middleboxes.¶
• Section 9 focuses on security considerations.¶
• Appendix A describes how a TCP stack would need to support the protocol described in this document.¶

4.1. Functional Elements

The Convert Protocol considers three functional elements:¶

• Clients¶
• Transport Converters¶
• Servers¶

A Transport Converter is a network function that proxies all data exchanged over one upstream connection to one downstream connection and vice versa (Figure 2). Thus, the Transport Converter maintains state that associates one upstream connection to a corresponding downstream connection.¶

A connection can be initiated from both sides of the Transport Converter (External realm, Internal realm).¶

                           |
                           :
                           |
                     +------------+
Client <- upstream ->| Transport  |<- downstream -> Server
         connection  | Converter  |   connection
                     +------------+
                           |
            Internal realm : External realm
                           |

"Client" refers to a software instance embedded on a host that can reach a Transport Converter in the internal realm. The "Client" can initiate connections via a Transport Converter (referred to as outgoing connections). Also, the "Client" can accept incoming connections via a Transport Converter (referred to as incoming connections).¶

A Transport Converter can be embedded in a standalone device or be activated as a service on a router. How such a function is enabled is deployment specific.¶

The architecture assumes that new software will be installed on the Client hosts to interact with one or more Transport Converters. Furthermore, the architecture allows for making use of new TCP extensions even if those are not supported by a given Server.¶

A Client is configured, through means that are outside the scope of this document, with the names and/or addresses of one or more Transport Converters and the TCP extensions that they support. The procedure for selecting a Transport Converter among a list of configured Transport Converters is outside the scope of this document.¶

One of the benefits of this design is that different transport protocol extensions can be used on the upstream and the downstream connections. This encourages the deployment of new TCP extensions until they are widely supported, in particular, by Servers.¶

The architecture does not mandate anything on the Server side.¶

Similar to SOCKS, the architecture does not interfere with end-to-end TLS connections [RFC8446] between the Client and the Server (Figure 3). In other words, end-to-end TLS is supported in the presence of a Converter.¶

    Client             Transport                Server
       |               Converter                  |
       |                   |                      |
       /==========================================\
      |            End-to-end TLS                  |
       \==========================================/

    * TLS messages exchanged between the Client
      and the Server are not shown.

It is out of scope of this document to elaborate on specific considerations related to the use of TLS in the Client-Converter connection leg to exchange Convert messages (in addition to the end-to-end TLS connection). In particular, (1) assessment of whether 0-RTT data mode discussed in Section 2.3 of [RFC8446] is safe under replay and (2) specification of a profile for its use (Appendix E.5 of [RFC8446]) are out of scope.¶

4.2. Theory of Operation

At a high level, the objective of the Transport Converter is to allow the use a specific extension, e.g., Multipath TCP, on a subset of the path even if the peer does not support this extension. This is illustrated in Figure 4 where the Client initiates a Multipath TCP connection with the Transport Converter (packets belonging to the Multipath TCP connection are shown with "===") while the Transport Converter uses a TCP connection with the Server.¶

    Client             Transport                Server
       |               Converter                  |
       |                   |                      |
       |==================>|--------------------->|
       |                   |                      |
       |<==================|<---------------------|
       |                   |                      |
      Multipath TCP packets     TCP packets

The packets belonging to a connection established through a Transport Converter may follow a different path than the packets directly exchanged between the Client and the Server. Deployments should minimize the possible additional delay by carefully selecting the location of the Transport Converter used to reach a given destination.¶

When establishing a connection, the Client can, depending on local policies, either contact the Server directly (e.g., by sending a TCP SYN towards the Server) or create the connection via a Transport Converter. In the latter case (that is, the conversion service is used), the Client initiates a connection towards the Transport Converter and indicates the IP address and port number of the Server within the connection establishment packet. Doing so enables the Transport Converter to immediately initiate a connection towards that Server without experiencing an extra delay. The Transport Converter waits until the receipt of the confirmation that the Server agrees to establish the connection before confirming it to the Client.¶

The Client places the destination address and port number of the Server in the payload of the SYN sent to the Transport Converter to minimize connection establishment delays. The Transport Converter maintains two connections that are combined together:¶

• The upstream connection is the one between the Client and the Transport Converter.¶
• The downstream connection is the one between the Transport Converter and the Server.¶

Any user data received by the Transport Converter over the upstream (or downstream) connection is proxied over the downstream (or upstream) connection.¶

Figure 5 illustrates the establishment of an outgoing TCP connection by a Client through a Transport Converter.¶

                        Transport
    Client              Converter              Server
       |                   |                      |
       |SYN [->Server:port]|         SYN          |
       |------------------>|--------------------->|
       |<------------------|<---------------------|
       |    SYN+ACK [ ]    |        SYN+ACK       |
       |        ...        |          ...         |

The Client sends a SYN destined to the Transport Converter. The payload of this SYN contains the address and port number of the Server. The Transport Converter does not reply immediately to this SYN. It first tries to create a TCP connection towards the target Server. If this upstream connection succeeds, the Transport Converter confirms the establishment of the connection to the Client by returning a SYN+ACK and the first bytes of the bytestream contain information about the TCP options that were negotiated with the Server. Also, a state entry is instantiated for this connection. This state entry is used by the Converter to handle subsequent messages belonging to the connection.¶

The connection can also be established from the Internet towards a Client via a Transport Converter (Figure 6). This is typically the case when the Client hosts an application Server that listens to a specific port number. When the Converter receives an incoming SYN from a remote host, it checks if it can provide the conversion service for the destination IP address and destination port number of that SYN. The Transport Converter receives this SYN because it is, for example, on the path between the remote host and the Client or it provides address-sharing service for the Client (Section 2 of [RFC6269]). If the check fails, the packet is silently ignored by the Converter. If the check is successful, the Converter tries to initiate a TCP connection towards the Client from its own address and using its configured TCP options. In the SYN that corresponds to this connection attempt, the Transport Convert inserts a TLV message that indicates the source address and port number of the remote host. A transport session entry is created by the Converter for this connection. SYN+ACK and ACK will then be exchanged between the Client, the Converter, and remote host to confirm the establishment of the connection. The Converter uses the transport session entry to proxy packets belonging to the connection.¶

  Transport              Remote
    Client              Converter             Host (RH)
       |                   |                      |
       |SYN [<-RH IP@:port]|         SYN          |
       |<------------------|<---------------------|
       |------------------>|--------------------->|
       |    SYN+ACK [ ]    |        SYN+ACK       |
       |        ...        |          ...         |

Standard TCP (Section 3.4 of [RFC0793]) allows a SYN packet to carry data inside its payload but forbids the receiver from delivering it to the application until completion of the three-way-handshake. To enable applications to exchange data in a TCP handshake, this specification follows an approach similar to TCP Fast Open [RFC7413] and thus, removes the constraint by allowing data in SYN packets to be delivered to the Transport Converter application.¶

As discussed in [RFC7413], such change to TCP semantics raises two issues. First, duplicate SYNs can cause problems for applications that rely on TCP; whether or not a given application is affected depends on the details of that application protocol. Second, TCP suffers from SYN flooding attacks [RFC4987]. TFO solves these two problems for applications that can tolerate replays by using the TCP Fast Open option that includes a cookie. However, the utilization of this option consumes space in the limited TCP header. Furthermore, there are situations, as noted in Section 7.3 of [RFC7413], where it is possible to accept the payload of SYN packets without creating additional security risks such as a network where addresses cannot be spoofed and the Transport Converter only serves a set of hosts that are identified by these addresses.¶

For these reasons, this specification does not mandate the use of the TCP Fast Open option when the Client sends a connection establishment packet towards a Transport Converter. The Convert Protocol includes an optional Cookie TLV that provides similar protection as the TCP Fast Open option without consuming space in the TCP header. Furthermore, this design allows for the use of longer cookies than [RFC7413].¶

If the downstream (or upstream) connection fails for some reason (excessive retransmissions, reception of an RST segment, etc.), then the Converter reacts by forcing the teardown of the upstream (or downstream) connection. In particular, if an ICMP error message that indicates a hard error is received on the downstream connection, the Converter echoes the Code field of that ICMP message in a Destination Unreachable Error TLV (see Section 6.2.8) that it transmits to the Client. Note that if an ICMP error message that indicates a soft error is received on the downstream connection, the Converter will retransmit the corresponding data until it is acknowledged or the connection times out. A classification of ICMP soft and hard errors is provided in Table 1 of [RFC5461].¶

The same reasoning applies when the upstream connection ends with an exchange of FIN segments. In this case, the Converter will also terminate the downstream connection by using FIN segments. If the downstream connection terminates with the exchange of FIN segments, the Converter should initiate a graceful termination of the upstream connection.¶

4.3. Data Processing at the Transport Converter

As mentioned in Section 4.2, the Transport Converter acts as a TCP 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 Server).¶

The control messages (i.e., the Convert messages discussed in Section 6) establish state (called transport session entry) in the Transport Converter that will enable it to proxy between the two TCP connections.¶

The Transport Converter uses the transport session entry to proxy packets belonging to the connection. An implementation example of a transport session entry for TCP connections is shown in Figure 7.¶

                   (C,c) <--> (T,t), (S,s), Lifetime

Where:¶

• C and c are the source IP address and source port number used by the Client for the upstream 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 a timer that tracks the remaining lifetime of the entry as assigned by the Converter. When the timer expires, the entry is deleted.¶

Clients send packets bound to connections eligible for the conversion service to the provisioned Transport Converter and destination port number. This applies for both control messages and data. Additional information is supplied by Clients to the Transport Converter by means of Convert messages as detailed in Section 6. User data can be included in SYN or non-SYN messages. User data is unambiguously distinguished from Convert TLVs by a Transport Converter owing to the Convert Fixed Header in the Convert messages (Section 6.1). These Convert TLVs are destined to the Transport Convert and are, thus, removed by the Transport Converter when proxying between the two connections.¶

Upon receipt of a packet that belongs to an existing connection between a Client and the Transport Converter, the Converter proxies the user data to the Server using the information stored in the corresponding transport session entry. For example, in reference to Figure 7, the Transport Converter proxies the data received from (C,⁠c) 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 Converter acts as a TCP proxy and sends the data to the Client relying upon the information stored in a transport session entry. The Converter associates a lifetime with state entries used to bind an upstream connection with its downstream connection.¶

When Multipath TCP is used between the Client and the Transport Converter, the Converter maintains more state (e.g., information about the subflows) for each Multipath TCP connection. The procedure described above continues to apply except that the Converter needs to manage the establishment/termination of subflows and schedule packets among the established ones. These operations are part of the Multipath TCP implementation. They are independent of the Convert Protocol that only processes the Convert messages in the beginning of the bytestream.¶

A Transport Converter may operate in address preservation mode (that 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 among all Clients serviced by the Converter (i.e., C!=T)); refer to Section 4.4 for more details. Which behavior to use by a Transport Converter is deployment specific. If address-sharing mode is enabled, the Transport Converter MUST adhere to REQ-2 of [RFC6888], which implies a default "IP address pooling" behavior of "Paired" (as defined in Section 4.1 of [RFC4787]) MUST be supported. This behavior is meant to avoid breaking applications that depend on the source address remaining constant.¶

4.4. Address Preservation vs. Address Sharing

The Transport Converter is provided with instructions about the behavior to adopt with regard to the processing of source addresses of outgoing packets. The following subsections discuss two deployment models for illustration purposes. It is out of the scope of this document to make a recommendation.¶

                                      Transport
       Client                        Converter          Server

        @:C1,C2                        @:Tc                @:S
           ||                            |                  |
           |src:C1     SYN         dst:Tc|src:C1       dst:S|
           |-------MPC [->S:port]------->|-------SYN------->|
           ||                            |                  |
           ||dst:C1                src:Tc|dst:C1       src:S|
           |<---------SYN/ACK------------|<-----SYN/ACK-----|
           ||                            |                  |
           |src:C1                 dst:Tc|src:C1       dst:S|
           |------------ACK------------->|-------ACK------->|
           |                             |                  |
           |src:C2          ...    dst:Tc|       ...        |
           ||<-----Secondary Subflow---->|src:C1       dst:S|
           ||                            |-------data------>|
           |               ..            |    ...           |

Legend:
  Tc: IP address used by the Transport Converter on the internal
      realm.

                                     Transport
      Client                         Converter          Server

         @:C                        @:Tc|Te                @:S
          |                             |                  |
          |src:C                  dst:Tc|src:Te       dst:S|
          |-------SYN [->S:port]------->|-------SYN------->|
          |                             |                  |
          |dst:C                  src:Tc|dst:Te       src:S|
          |<---------SYN/ACK------------|<-----SYN/ACK-----|
          |                             |                  |
          |src:C                  dst:Tc|src:Te       dst:S|
          |------------ACK------------->|-------ACK------->|
          |                             |                  |
          |              ...            |    ...           |

Legend:
  Tc: IP address used by the Transport Converter on the internal
      realm.
  Te: IP address used by the Transport Converter on the external
      realm.

5.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 Transport Converter support Multipath TCP but consider two different cases depending on whether or not the Server supports Multipath TCP.¶

As a reminder, a Multipath TCP connection is created by placing the MP_CAPABLE (MPC) option in the SYN sent by the Client.¶

Figure 10 describes the operation of the Transport Converter if the Server does not support Multipath TCP.¶

                        Transport
    Client              Converter              Server
       |SYN, MPC           |                      |
       |[->Server:port]    |         SYN, MPC     |
       |------------------>|--------------------->|
       |<------------------|<---------------------|
       |  SYN+ACK,MPC [.]  |      SYN+ACK         |
       |------------------>|--------------------->|
       |     ACK, MPC      |          ACK         |
       |        ...        |          ...         |

The Client tries to initiate a Multipath TCP connection by sending a SYN with the MP_CAPABLE option (MPC in Figure 10). The SYN includes the address and port number of the target Server, that are extracted and used by the Transport Converter to initiate a Multipath TCP connection towards this Server. Since the Server does not support Multipath TCP, it replies with a SYN+ACK that does not contain the MP_CAPABLE option. The Transport Converter notes that the connection with the Server does not support Multipath TCP and returns the extended TCP header received from the Server to the Client.¶

Note that, if the TCP connection is reset for some reason, the Converter tears down the Multipath TCP connection by transmitting an MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with the transmission of DATA_FINs, the Converter terminates the TCP connection by using FIN segments. As a side note, given that with Multipath TCP, RST only has the scope of the subflow and will only close the concerned subflow but not affect the remaining subflows, the Converter does not terminate the downstream TCP connection upon receipt of an RST over a Multipath subflow.¶

Figure 11 considers a Server that supports Multipath TCP. In this case, it replies to the SYN sent by the Transport Converter with the MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport Converter confirms the establishment of the connection to the Client and indicates to the Client that the Server supports Multipath TCP. With this information, the Client has discovered that the Server supports Multipath TCP. This will enable the Client to bypass the Transport Converter for the subsequent Multipath TCP connections that it will initiate towards this Server.¶

                        Transport
    Client              Converter              Server
       |SYN, MPC           |                      |
       |[->Server:port]    |         SYN, MPC     |
       |------------------>|--------------------->|
       |<------------------|<---------------------|
       |SYN+ACK, MPC       |      SYN+ACK, MPC    |
       |[MPC supported]    |                      |
       |------------------>|--------------------->|
       |     ACK, MPC      |        ACK, MPC      |
       |        ...        |          ...         |

5.2. Incoming Converter-Assisted Multipath TCP Connection

An example of an incoming Converter-assisted Multipath TCP connection is depicted in Figure 12. In order to support incoming connections from remote hosts, the Client may use the Port Control Protocol (PCP) [RFC6887] to instruct the Transport Converter to create dynamic mappings. Those mappings will be used by the Transport Converter to intercept an incoming TCP connection destined to the Client and convert it into a Multipath TCP connection.¶

Typically, the Client sends a PCP request to the Converter asking to create an explicit TCP mapping for the internal IP address and internal port number. The Converter accepts the request by creating a TCP mapping for the internal IP address, internal port number, external IP address, and external port number. The external IP address, external port number, and assigned lifetime are returned back to the Client in the PCP response. The external IP address and external port number will then be advertised by the Client (or the user) using an out-of-band mechanism so that remote hosts can initiate TCP connections to the Client via the Converter. Note that the external and internal information may be the same.¶

Then, when the Converter receives an incoming SYN, it checks its mapping table to verify if there is an active mapping matching the destination IP address and destination port of that SYN. If no entry is found, the Converter silently ignores the message. If an entry is found, the Converter inserts an MP_CAPABLE option and Connect TLV in the SYN packet, and rewrites the source IP address to one of its IP addresses and, eventually, the destination IP address and port number in accordance with the information stored in the mapping. SYN+ACK and ACK will then be exchanged between the Client and the Converter to confirm the establishment of the initial subflow. The Client can add new subflows following normal Multipath TCP procedures.¶

                        Transport             Remote
    Client              Converter              Host
      |                     |                    |
      |<--------------------|<-------------------|
      |SYN, MPC             |         SYN        |
      |[Remote Host:port]   |                    |
      |-------------------->|------------------->|
      |      SYN+ACK, MPC   |       SYN+ACK      |
      |<--------------------|<-------------------|
      |       ACK, MPC      |           ACK      |
      |        ...          |          ...       |

It is out of scope of this document to define specific Convert TLVs to manage incoming connections (that is, TLVs that mimic PCP messages). These TLVs can be defined in a separate document.¶

6.1. The Convert Fixed Header

The Convert Protocol uses a fixed header that is 32 bits long sent by both the Client and the Transport Converter over each established connection. This header indicates both the version of the protocol used and the length of the Convert message.¶

The Client and the Transport Converter MUST send the fixed-sized header, shown in Figure 13, as the first four bytes of the bytestream.¶

                     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
+---------------+---------------+-------------------------------+
|  Version      |  Total Length |          Magic Number         |
+---------------+---------------+-------------------------------+

The version is encoded as an 8-bit unsigned integer value. This document specifies version 1. Version 0 is reserved by this document and MUST NOT be used.¶

The Total Length is the number of 32-bit words, including the header, of the bytestream that are consumed by the Convert messages. Since Total Length is also an 8-bit unsigned integer, those messages 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 zero is invalid and the connection MUST be reset upon reception of a header with such a total length.¶

The Magic Number field MUST be set to 0x2263. This field is meant to further strengthen the protocol to unambiguously distinguish any data supplied by an application from Convert TLVs.¶

The Total Length field unambiguously marks the number of 32-bit words that carry Convert TLVs in the beginning of the bytestream.¶

6.2. Convert TLVs

                        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
   +---------------+---------------+-------------------------------+
   |     Type      |     Length    |             Value  ...        |
   +---------------+---------------+-------------------------------+
   //              ...   (optional) Value                         //
   +---------------------------------------------------------------+

                     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
+---------------+---------------+-------------------------------+
|     Type=0x1  |     Length    |             Zero              |
+---------------+---------------+-------------------------------+

                      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
 +---------------+---------------+-------------------------------+
 |     Type=0x15 |     Length    |           Unassigned          |
 +---------------+---------------+-------------------------------+
 |     Kind #1   |     Kind #2   |           ...                 |
 +---------------+---------------+-------------------------------+
 /                              ...                              /
 /                                                               /
 +---------------------------------------------------------------+

                      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
 +---------------+---------------+-------------------------------+
 |     Type=0xA  |     Length    |      Remote Peer Port         |
 +---------------+---------------+-------------------------------+
 |                                                               |
 |         Remote Peer IP Address (128 bits)                     |
 |                                                               |
 |                                                               |
 +---------------------------------------------------------------+

                      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
 +---------------+---------------+-------------------------------+
 |     Type=0xA  |     Length    |      Remote Peer Port         |
 +---------------+---------------+-------------------------------+
 |                                                               |
 |         Remote Peer IP Address (128 bits)                     |
 |                                                               |
 |                                                               |
 +---------------------------------------------------------------+
 /                          TCP Options (Variable)               /
 /                              ...                              /
 +---------------------------------------------------------------+

                     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
 +---------------+---------------+---------------+---------------+
 |  TCPOpt kind  | TCPOpt Length | Value  (opt)  |  ....         |
 +---------------+---------------+---------------+---------------+
 |                             ....                              |
 +---------------------------------------------------------------+
 |                              ...                              |
 +---------------------------------------------------------------+

                      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
 +---------------+---------------+-------------------------------+
 |     Type=0x14 |     Length    |           Unassigned          |
 +---------------+---------------+-------------------------------+
 /               Returned Extended TCP header                    /
 /                              ...                              /
 +---------------------------------------------------------------+

                      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
 +---------------+---------------+-------------------------------+
 |     Type=0x16 |     Length    |             Zero              |
 +---------------+---------------+-------------------------------+
 /                        Opaque  Cookie                         /
 /                              ...                              /
 +---------------------------------------------------------------+

                      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
 +---------------+---------------+----------------+--------------+
 |     Type=0x1E |     Length    |    Error Code  |  Value       |
 +---------------+---------------+----------------+--------------+
 //              ...   (optional) Value                         //
 +---------------------------------------------------------------+

7.1. Base TCP Options

Three TCP options were initially defined in [RFC0793]: End-of-Option List (Kind=0), No-Operation (Kind=1), and Maximum Segment Size (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 Converter to specifically send these options towards the final destination.¶

The Maximum Segment Size option (Kind=2) is used by a host to indicate the largest segment that it can receive over each connection. This value is a function of the stack that terminates the TCP connection. There is no reason for a Client to request a Transport Converter to advertise a specific Maximum Segment Size (MSS) value to a remote Server.¶

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 TCP Extensions TLV.¶

7.2. Window Scale (WS)

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 connection strongly depends on the TCP stack that handles the connection. When a Transport Converter opens a TCP connection 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 its stack. A local configuration MAY allow for a WS option in the proxied message to be a function of the scaling factor of the incoming connection.¶

From a deployment viewpoint, there is no benefit in enabling a Client of a Transport Converter to specifically request the utilization of the WS option (Kind=3) with a specific scaling factor towards a remote Server. For this reason, a Transport Converter MUST ignore option Kind=3 if it appears in a Connect TLV. The Transport Converter MUST NOT announce a WS option (Kind=3) in a Supported TCP Extensions TLV.¶

7.3. Selective Acknowledgments

Two distinct TCP options were defined to support Selective Acknowledgment (SACK) in [RFC2018]. This first one, SACK-Permitted (Kind=4), is used to negotiate the utilization of Selective Acknowledgments during the three-way handshake. The second one, SACK (Kind=5), carries the Selective Acknowledgments inside regular segments.¶

The SACK-Permitted option (Kind=4) MAY be advertised by a Transport Converter in the Supported TCP Extensions TLV. Clients connected to this Transport Converter MAY include the SACK-Permitted option in the Connect TLV.¶

The SACK option (Kind=5) cannot be used during the three-way 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 TCP Supported Extensions TLV.¶

7.4. Timestamp

The Timestamp option [RFC7323] can be used during the three-way handshake to negotiate the utilization of timestamps during the TCP connection. It is notably used to improve round-trip-time estimations and to provide Protection Against Wrapped Sequences (PAWS). As for the WS option, the timestamps are a property of a connection and there is limited benefit in enabling a Client to request a Transport Converter to use the timestamp option when establishing a connection 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 a Client to specify the timestamp value that a Transport Converter could use to establish a connection to a remote Server.¶

A Transport Converter MAY advertise the Timestamp option (Kind=8) in the TCP Supported Extensions TLV. The Clients connected to this Transport Converter MAY include the Timestamp option in the Connect TLV but without any timestamp.¶

7.5. Multipath TCP

The Multipath TCP options are defined in [RFC8684], which defines one variable length TCP option (Kind=30) that includes a sub-type field to support several Multipath TCP options. There are several operational use cases where Clients would like to use Multipath TCP through a Transport Converter [IETFJ16]. However, none of these use cases require the Client to specify the content of the Multipath TCP option that the Transport Converter should send to a remote Server.¶

A Transport Converter that supports Multipath TCP conversion service MUST advertise the Multipath TCP option (Kind=30) in the Supported TCP Extensions TLV. Clients serviced by this Transport Converter may include the Multipath TCP option in the Connect TLV but without any content.¶

7.6. TCP Fast Open

The TCP Fast Open Cookie option (Kind=34) is defined in [RFC7413]. There are two different usages of this option that need to be supported by Transport Converters. The first utilization of the TCP 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 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 case, the option contains a cookie.¶

A Transport Converter MAY advertise the TCP Fast Open Cookie option (Kind=34) in the Supported TCP Extensions TLV. If a Transport Converter has advertised the support for TCP Fast Open in its Supported TCP Extensions TLV, it needs to be able to process two types of Connect TLV.¶

If such a Transport Converter receives a 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 the SYN sent to the remote Server. If the remote Server supports TFO, it responds with a SYN-ACK according to the procedure in Section 4.1.2 of [RFC7413]. This SYN-ACK may contain a Fast Open option with a cookie. Upon receipt of the SYN-ACK by the Converter, it relays the Fast Open option with the cookie to the Client.¶

If such a Transport Converter 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 the SYN sent to the remote Server.¶

7.7. TCP-AO

The TCP Authentication Option (TCP-AO) [RFC5925] provides a technique to authenticate all the packets exchanged over a TCP connection. Given the nature of this extension, it is unlikely that the applications that require their packets to be authenticated end to end would want their connections to pass through a converter. For this reason, we do not recommend the support of the TCP-AO by Transport Converters. The only use cases where it 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.¶

A Transport Converter MUST NOT advertise the TCP-AO (Kind=29) in the Supported TCP Extensions TLV. If a Transport Converter receives a Connect TLV that contains the TCP-AO, it MUST reject the establishment of the connection with error code set to "Unsupported TCP Option", except if the TCP-AO-NAT option is used. Nevertheless, given that TCP-AO-NAT is Experimental, its usage is not currently defined and must be specified by some other document before it can be used.¶

9.1. Privacy & Ingress Filtering

The Transport Converter may have access to privacy-related information (e.g., subscriber credentials). The Transport Converter is designed to not leak such sensitive information outside a local domain.¶

Given its function and location in the network, a Transport Converter is in a position to observe all packets that it processes, to include payloads and metadata, and has the ability to profile and conduct some traffic analysis of user behavior. The Transport Converter MUST be as protected as a core IP router (e.g., Section 10 of [RFC1812]).¶

Furthermore, ingress filtering policies MUST be enforced at the network boundaries [RFC2827].¶

This document assumes that all network attachments are managed by the same administrative entity. Therefore, enforcing anti-spoofing filters at these networks is a guard that hosts are not sending traffic with spoofed source IP addresses.¶

9.2. Authentication and Authorization Considerations

The Convert Protocol is RECOMMENDED for use in a managed network where end hosts can be securely identified by their IP address. If such control is not exerted and there is a more open network environment, a strong mutual authentication scheme MUST be defined to use the Convert Protocol.¶

One possibility for mutual authentication is to use TLS to perform mutual authentication between the Client and the Converter. That is, use TLS when a Client retrieves a Cookie from the Converter and rely on certificate-based, pre-shared key-based [RFC4279], or raw public key-based Client authentication [RFC7250] to secure this connection. If the authentication succeeds, the Converter returns a cookie to the Client. Subsequent Connect messages will be authorized as a function of the content of the Cookie TLV. An attacker from within the network between a Client and a Transport Converter may intercept the Cookie and use it to be granted access to the conversion service. Such an attack is only possible if the attacker spoofs the IP address of the Client and the network does not filter packets with source-spoofed IP addresses.¶

The operator that manages the various network attachments (including the Transport Converters) has various options for enforcing authentication and authorization policies. For example, a non-exhaustive list of methods to achieve authorization is provided hereafter:¶

• The network provider may enforce a policy based on the International Mobile Subscriber Identity (IMSI) to verify that a user is allowed to benefit from the TCP converter service. If that authorization fails, the Packet Data Protocol (PDP) context/bearer will not be mounted. This method does not require any interaction with the Transport Converter for authorization matters.¶
• The network provider may enforce a policy based upon Access Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) to control the hosts that are authorized to communicate with a Transport Converter. These ACLs may be installed as a result of RADIUS exchanges, e.g., [TCPM-CONVERTER]. This method does not require any interaction with the Transport Converter for authorization matters.¶
• A device that embeds a Transport Converter may also host a RADIUS Client that will solicit a AAA Server to check whether or not connections received from a given source IP address are authorized [TCPM-CONVERTER].¶

A first safeguard against the misuse of Transport Converter resources by illegitimate users (e.g., users with access networks that are not managed by the same provider that operates the Transport Converter) is the Transport Converter to reject Convert connections received in the external realm. Only Convert connections received in the internal realm of a Transport Converter will be accepted.¶

In deployments where network-assisted connections are not allowed between hosts of a domain (i.e., hairpinning), the Converter may be instructed to discard such connections. Hairpinned connections are thus rejected by the Transport Converter by returning an Error TLV set to "Not Authorized". Otherwise, absent explicit configuration, hairpinning is enabled by the Converter (see Figure 24).¶

          <===Network Provider===>

   +----+ from X1:x1 to X2':x2'   +-----+ X1':x1'
   | C1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
   +----+                         |  v  |
                                  |  v  |
                                  |  v  |
                                  |  v  |
   +----+ from X1':x1' to X2:x2   |  v  | X2':x2'
   | C2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
   +----+                         +-----+
                                 Converter

   Note: X2':x2' may be equal to
         X2:x2

9.3. Denial of Service

Another possible risk is amplification attacks, since a Transport 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 sent by the Transport Converter were larger than the SYN received from the Client, or if the Transport Converter retransmits the SYN. To mitigate such attacks, the Transport Converter SHOULD rate-limit the number of pending requests for a given Client. It SHOULD also avoid sending SYNs that are significantly longer than the SYN received from the Client, to remote Servers. Finally, the Transport Converter SHOULD only retransmit a SYN to a Server after having received a retransmitted SYN from the corresponding Client. Means to protect against SYN flooding attacks should also be enabled (e.g., Section 3 of [RFC4987]).¶

Attacks from within the network between a Client and a Transport Converter (including attacks that change the protocol version) are yet another threat. Means to ensure that illegitimate nodes cannot connect to a network should be implemented.¶

9.4. Traffic Theft

Traffic theft is a risk if an illegitimate Converter is inserted in the path. Indeed, inserting an illegitimate Converter in the forwarding path allows traffic interception and can therefore provide access to sensitive data issued by or destined to a host. Converter discovery and configuration are out of scope of this document.¶

10.1. Convert Service Name

IANA has assigned a service name for the Convert Protocol from the "Service Name and Transport Protocol Port Number Registry" available at <https://www.iana.org/assignments/service-names-port-numbers>.¶

Service Name:

convert¶

Port Number:

N/A¶

Transport Protocol(s):

TCP¶

Description:

0-RTT TCP Convert Protocol¶

Assignee:

IESG <iesg@ietf.org>¶

Contact:

IETF Chair <chair@ietf.org>¶

Reference:

RFC 8803¶

Clients may use this service name to feed the procedure defined in [RFC2782] to discover the IP address(es) and the port number used by the Transport Converters of a domain.¶

10.2. The Convert Protocol (Convert) Parameters

IANA has created a new "TCP Convert Protocol (Convert) Parameters" registry.¶

The following subsections detail new registries within the "Convert Protocol (Convert) Parameters" registry.¶

The designated expert is expected to ascertain the existence of suitable documentation as described in Section 4.6 of [RFC8126] and to verify that the document is permanently and publicly available. The designated expert is also expected to check the clarity of purpose and use of the requested code points.¶

Also, criteria that should be applied by the designated experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for private use, and whether the registration description is clear. All requests should be directed to the review mailing list. For both the "Convert TLVs" and "Convert Errors" subregistries, IANA must only accept registry updates in the 128-191 range from the designated experts. It is suggested that multiple designated experts be appointed. In cases where a registration decision could be perceived as creating a conflict of interest for a particular expert, that expert should defer to the judgment of the other experts.¶

A.1. Active Open (Client Side)

On the Client side, the support of the 0-RTT Converter protocol does not require any other changes than those identified in Appendix A of [RFC7413]. Those modifications are already supported by multiple TCP stacks.¶

As an example, on Linux, a Client can send the 0-RTT Convert message inside a SYN by using sendto with the MSG_FASTOPEN flag as shown in the example below:¶

  s = socket(AF_INET, SOCK_STREAM, 0);

  sendto(s, buffer, buffer_len, MSG_FASTOPEN,
                 (struct sockaddr *) &server_addr, addr_len);

The Client side of the Linux TFO can be used in two different modes depending on the host configuration (sysctl tcp_fastopen variable):¶

0x1:

(client) enables sending data in the opening SYN on the Client.¶

0x4:

(client) enables sending data in the opening SYN regardless of cookie availability and without a cookie option.¶

By setting this configuration variable to 0x5, a Linux Client using the above code would send data inside the SYN without using a TFO option.¶

A.2. Passive Open (Converter Side)

The Converter needs to enable the reception of data inside the SYN independently of the utilization of the TFO option. This implies that the Transport Converter application cannot rely on the Fast Open Cookies to validate the reachability of the IP address that sent the SYN. It must rely on other techniques, such as the Cookie TLV described in this document, to verify this reachability.¶

[RFC7413] suggested the utilization of a TCP_FASTOPEN socket option to enable the reception of SYNs containing data. Later, Appendix A of [RFC7413] mentioned:¶

Traditionally, accept() returns only after a socket is connected. But, for a Fast Open connection, accept() returns upon receiving a SYN with a valid Fast Open cookie and data, and the data is available to be read through, e.g., recvmsg(), read().¶

To support the 0-RTT TCP Convert Protocol, this behavior should be modified as follows:¶

Traditionally, accept() returns only after a socket is connected. But, for a Fast Open connection, accept() returns upon receiving a SYN with data, and the data is available to be read through, e.g., recvmsg(), read(). The application that receives such SYNs with data must be able to validate the reachability of the source of the SYN and also deal with replayed SYNs.¶

The Linux Server side can be configured with the following sysctls:¶

0x2:

(server) enables the Server support, i.e., allowing data in a SYN packet to be accepted and passed to the application before a 3-way handshake finishes.¶

0x200:

(server) accepts data-in-SYN w/o any cookie option present.¶

However, this configuration is system wide. This is convenient for typical Transport Converter deployments where no other applications relying on TFO are collocated on the same device.¶

Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added to provide the same behavior on a per-socket basis. This enables a single host to support both Servers that require the Fast Open Cookie and Servers that do not use it.¶