RFC 8803
0-RTT TCP Convert Protocol
0-RTT TCP Convert Protocol 🦋
okay bestie, this is RFC 8803 💖 It's an Experimental document from the IETF (Internet Engineering Task Force) Request for Comments series, published in July 2020 under ISSN 2070-1721 ✨ The editors are O. Bonaventure, Ed. (Tessares) and M. Boucadair, Ed. (Orange), with co-authors S. Gundavelli (Cisco), S. Seo (Korea Telecom), and B. Hesmans (Tessares) 🫶 Its title block doesn't list any Obsoletes or Updates entries, so it doesn't replace or change any earlier RFCs 🍓
Abstract 💅
okay so this doc specifies an application proxy called the Transport Converter 🌸 Its whole job is to help roll out TCP extensions, with Multipath TCP as the main example. One Transport Converter can offer conversion for one or more TCP extensions, and it does that using the 0-RTT TCP Convert Protocol (called Convert) 🔥
The 0-RTT part is the iconic bit 😭 Convert adds no extra delay compared to connections that aren't proxied, and it doesn't use any encapsulation at all. No tunnels whatsoever 💀✨
This spec assumes an explicit model, meaning the Transport Converter gets configured directly on hosts 🎀 As a sample use case, the doc shows how Convert applies to Multipath TCP 🦋
Status of This Memo 🌈
okay the status bit, lowkey important 🙈 This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧚
It defines an Experimental Protocol for the Internet community ✨ It's a product of the IETF and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💜 Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 💅
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8803 🫶
Copyright Notice 🌸
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read those carefully, because they explain your rights and restrictions for this document 👑 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⭐
Table of Contents 🎀
1. Introduction
1.1. The Problem
1.2. Network-Assisted Connections: The Rationale
1.3. Applicability Scope
2. Conventions and Definitions
3. Differences with SOCKSv5
4. Architecture and Behaviors
4.1. Functional Elements
4.2. Theory of Operation
4.3. Data Processing at the Transport Converter
4.4. Address Preservation vs. Address Sharing
4.4.1. Address Preservation
4.4.2. Address/Prefix Sharing
5. Sample Examples
5.1. Outgoing Converter-Assisted Multipath TCP Connections
5.2. Incoming Converter-Assisted Multipath TCP Connection
6. The Convert Protocol (Convert)
6.1. The Convert Fixed Header
6.2. Convert TLVs
6.2.1. Generic Convert TLV Format
6.2.2. Summary of Supported Convert TLVs
6.2.3. The Info TLV
6.2.4. Supported TCP Extensions TLV
6.2.5. Connect TLV
6.2.6. Extended TCP Header TLV
6.2.7. The Cookie TLV
6.2.8. Error TLV
7. Compatibility of Specific TCP Options with the Conversion
Service
7.1. Base TCP Options
7.2. Window Scale (WS)
7.3. Selective Acknowledgments
7.4. Timestamp
7.5. Multipath TCP
7.6. TCP Fast Open
7.7. TCP-AO
8. Interactions with Middleboxes
9. Security Considerations
9.1. Privacy & Ingress Filtering
9.2. Authentication and Authorization Considerations
9.3. Denial of Service
9.4. Traffic Theft
9.5. Logging
10. IANA Considerations
10.1. Convert Service Name
10.2. The Convert Protocol (Convert) Parameters
10.2.1. Convert Versions
10.2.2. Convert TLVs
10.2.3. Convert Error Messages
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Example Socket API Changes to Support the 0-RTT TCP
Convert Protocol
A.1. Active Open (Client Side)
A.2. Passive Open (Converter Side)
Acknowledgments
Contributors
Authors' Addresses1. Introduction ✨
1.1. The Problem 🦋
okay so transport protocols like TCP keep evolving all the time [RFC7414] 💖 TCP has improved in lots of different ways. Some changes, like the initial window size [RFC6928] or tweaks to the congestion control scheme, can be applied on Clients and Servers independently 🌸 Others, like Selective Acknowledgments [RFC2018] or large windows [RFC7323], need a new TCP option or a change to what some header fields mean. Those changes have to be deployed on both Clients and Servers before anyone actually uses them on the Internet 😭 Experience shows that the second group can take many years to roll out. Fukuda reports in [Fukuda2011] a decade of measurements showing how slowly Selective Acknowledgments, Window Scale, and TCP Timestamps got deployed 📉 And [ANRW17] shows that TCP Fast Open (TFO) [RFC7413] is still not widely deployed, which is honestly a lot 💀
Sometimes the transport stack on Clients (or Servers) gets upgraded faster than the one on Servers (or Clients) 🍓 In those cases, the Clients (or Servers) would really like to use the features of the improved protocol even though the other side hasn't been upgraded yet 🧚 Help from the network makes that possible, and it's super valuable ✨ For example, Performance Enhancing Proxies [RFC3135] and other service functions have been deployed to improve TCP performance over links with specific characteristics 💜
Newer TCP extensions include Multipath TCP (MPTCP) [RFC8684] and tcpcrypt [RFC8548] 🎀 They're really interesting for Clients like wireless devices. With Multipath TCP, those devices can seamlessly use Wireless Local Area Network (WLAN) and cellular networks together, for bonding, faster hand-overs, or better resiliency 🔥 The annoying part is that deploying these extensions across a wide range of Clients and Servers is still hard 🙈
More recently, 5G bonding experiments ran over the global range of the incumbent 4G (LTE) connectivity, using newly devised Clients and a Multipath TCP proxy 📡 Bonding 5G and 4G (which relies on Multipath TCP) boosts bandwidth, but it's also really important to minimize latency end to end between hosts, whether intermediate nodes sit inside or outside the mobile core 🌈 To handle Ultra-Reliable Low Latency Communication (URLLC) for the next-generation mobile network, Multipath TCP and its proxy mechanisms, like the ones used for Access Traffic Steering, Switching, and Splitting (ATSSS), have to be optimized to reduce latency [TS23501] 👑
1.2. Network-Assisted Connections: The Rationale 🌸
Okay so bestie, this document specifies an application proxy called Transport Converter ✨. A Transport Converter is a function that a network operator installs to help deploy TCP extensions and to hand their perks to Clients in particular 💅. One Transport Converter may offer conversion service for one or more TCP extensions. Which TCP extensions are eligible is deployment specific 🎀. The conversion service runs over the 0-RTT TCP Convert Protocol (Convert), an application-layer protocol that uses a specific TCP port number on the Converter 🦋.
The Convert Protocol gives Zero Round-Trip Time (0-RTT) conversion service, and it's giving speed ⭐. The protocol adds no extra delay compared to connections that aren't proxied. Especially iconic: it doesn't need extra signaling setup delays before you can start using the conversion service 💖. It also doesn't require any encapsulation, so no tunnels, whatsoever 🙈.
The Transport Converter follows the main steps drawn in Section 3 of [RFC1919]. Specifically, it does 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 win of network-assisted conversion services is that they let new TCP extensions be used on just a part of the path between the endpoints, which encourages people to actually deploy those extensions 🌈. Plus, the Transport Converter lets the Client and the Server directly negotiate TCP extensions, so you get native support along the full path too 👑.
The Convert Protocol is a generic mechanism for 0-RTT conversion service. As a sample use case, this document shows how the Convert Protocol applies to Multipath TCP 🧚. A full list of every possible conversion service is out of scope here, so don't come looking for it. Applicability documents may be defined in the future 🔮.
This document doesn't assume that all traffic is eligible for the network-assisted conversion service. Only a subset of traffic gets forwarded to a Transport Converter, according to a set of policies. Those policies, and how endpoints learn about them, are out of scope 🙃. It's also possible to bypass the Transport Converter and connect directly to Servers that already support the required TCP extension(s), which is a total green light 🍓.
This document assumes an explicit model where a Client is configured with one Transport Converter or a list of them, either statically or through protocols such as [DHC-CONVERTER]. How that configuration happens is outside the scope of this document 📋.
Real talk, using a Transport Converter means there's no end-to-end transport connection between the Client and the Server. That could cause problems in some scenarios, like the ones discussed in Section 4 of [RFC3135]. Some of those problems may not apply, though 🥺. For example, a Transport Converter can tell a Client about a failure using Network Failure (65) or Destination Unreachable (97) error messages (Section 6.2.8), and then the Client can react accordingly 💪. An endpoint, or its network administrator, can weigh the benefit the Transport Converter service provides against 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 gives a brief overview of the differences between the well-known SOCKS protocol and the 0-RTT TCP Convert Protocol.
- Section 4 gives a brief explanation of how Transport Converters operate.
- Section 5 includes a set of sample examples to show 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.
1.3. Applicability Scope ✨
Okay, this part is important, so listen up 👀. The 0-RTT TCP Convert Protocol specified in this document MUST be used in a single administrative domain deployment model. That means the entity offering connectivity service to a Client is also the entity that owns and operates the Transport Converter, with no transit over a third-party network 🏠.
Future deployment of Transport Converters by third parties MUST adhere to the mutual authentication requirements in Section 9.2, mainly to prevent illegitimate traffic interception (Section 9.4) 🔐. No cap, this one's serious.
2. Conventions and Definitions 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💜.
3. Differences with SOCKSv5 🧦
Several IETF protocols provide proxy services, and the one closest to the 0-RTT TCP Convert Protocol is the SOCKSv5 protocol [RFC1928]. This protocol is already used to deploy Multipath TCP in some cellular networks (Section 2.2 of [RFC8041]) 📱.
A SOCKS Client creates a connection to a SOCKS Proxy, exchanges authentication information, and indicates the IP address and port number of the target Server. At this point, the SOCKS Proxy creates a connection towards the target Server and relays all data between the two proxied connections 🔁. Here's how an implementation based on SOCKSv5 (without authentication) goes, as shown in Figure 1 🎬:
Client SOCKS Proxy Server
| | |
| --------------------> | |
| SYN | |
| <-------------------- | |
| SYN+ACK | |
| --------------------> | |
| ACK | |
| | |
| --------------------> | |
|Version=5, Auth Methods| |
| <-------------------- | |
| Method | |
| --------------------> | |
|Auth Request (unless "No auth" method negotiated)
| <-------------------- | |
| Auth Response | |
| --------------------> | |
| Connect Server:Port | --------------------> |
| | SYN |
| | <-------------------- |
| | SYN+ACK |
| <-------------------- | |
| Succeeded | |
| --------------------> | |
| Data1 | |
| | --------------------> |
| | Data1 |
| | <-------------------- |
| | Data2 |
| <-------------------- | |
| Data2 | |
...
Figure 1: Establishment of a TCP Connection through a SOCKS Proxy
without AuthenticationWhen SOCKS is used, an "end-to-end" connection between a Client and a Server turns into two TCP connections glued together on the SOCKS Proxy 🩹. The SOCKS Client and Server exchange control information at the start of the bytestream on the Client-Proxy connection. Then the SOCKS Proxy creates the connection with the target Server and glues the two connections together, so every byte the application (Client) sends to the SOCKS Proxy gets relayed to the Server, and vice versa 💌.
The Convert Protocol is also used on TCP proxies that relay data between an upstream and a downstream connection, but there are important differences from SOCKSv5 💅. The first difference: the 0-RTT TCP Convert Protocol exchanges all the control information during the initial RTT. That cuts the connection establishment delay compared to SOCKS, which needs two or more round-trip times before the downstream connection to the final destination is set up ⏱️. Latency matters a lot on today's Internet, and various protocols have been tuned to reduce it [LOW-LATENCY]. A recently proposed extension to SOCKS uses the TCP Fast Open (TFO) option to cut this delay too [INTAREA-SOCKS] 🚀.
The second difference: the Convert Protocol explicitly takes TCP extensions into account. Using it, the Client can learn whether a given TCP extension is supported by the destination Server. That lets the Client skip the Transport Converter when the Server supports the required TCP extension(s) 🧠. Neither SOCKSv5 [RFC1928] nor the proposed SOCKSv6 [INTAREA-SOCKS] offers that feature 🙅.
The third difference: a Transport Converter only confirms the connection the Client initiated once the downstream connection has already been accepted by the Server. If the Server refuses the connection attempt from the Transport Converter, the upstream connection from the Client gets rejected too. This matters for apps that check whether a Server is available, or that use time-to-connect as a hint for picking a Server [RFC8305] ⭐.
The fourth difference: the 0-RTT TCP Convert Protocol only lets the Client specify the IP address and port number of the destination Server, not a DNS name 🧭. An alternate design that included the DNS name of the remote peer instead of its IP address, like SOCKS does [RFC1928], was evaluated. It wasn't adopted, because it would add load and delays on the Transport Converter to handle and manage DNS resolution requests 😮💨. Also, name resolution at the Converter may fail (e.g., private names discussed in Section 2.1 of [RFC6731]), or may not match the one a Client's resolution library would return (e.g., Section 2.2 of [RFC6731]) 🫠.
4. Architecture and Behaviors ✨
4.1. Functional Elements 💅
Okay bestie, the Convert Protocol only has 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). So the Transport Converter keeps track of state that links each upstream connection to its matching downstream connection 🔗✨
|
:
|
+------------+
Client <- upstream ->| Transport |<- downstream -> Server
connection | Converter | connection
+------------+
|
Internal realm : External realm
|
Figure 2: A Transport Converter Proxies Data between Pairs of TCP
ConnectionsA connection can be started from both sides of the Transport Converter (External realm, Internal realm). It's giving two-way street 🚦💜
"Client" refers to a software instance embedded on a host that can reach a Transport Converter in the internal realm. The Client can start connections through a Transport Converter, which are called outgoing connections. The Client can also accept incoming connections through a Transport Converter, which are called incoming connections 📥🎀
A Transport Converter can be embedded in a standalone device, or it can be activated as a service on a router. How that gets switched on is deployment specific, so it depends on the setup 🧚
The architecture assumes that new software will be installed on the Client hosts so they can interact with one or more Transport Converters. Furthermore, the architecture lets you use new TCP extensions even if a given Server doesn't support them. Main character energy for the Client 👑✨
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, plus the TCP extensions that they support. The procedure for picking one Transport Converter out of a list of configured ones is also 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 people to deploy new TCP extensions until they are widely supported, especially by Servers. Lowkey genius 🧠💖
The architecture does not mandate anything on the Server side. The Servers are chill and don't have to change a thing 😌🍓
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. Your secrets stay secret, periodt 🔐💅
Client Transport Server
| Converter |
| | |
/==========================================\
| End-to-end TLS |
\==========================================/
* TLS messages exchanged between the Client
and the Server are not shown.
Figure 3: End-to-end TLS via a Transport ConverterIt is out of scope of this document to go into specific considerations for using TLS on the Client-Converter connection leg to exchange Convert messages (in addition to the end-to-end TLS connection). In particular, (1) assessing whether the 0-RTT data mode discussed in Section 2.3 of [RFC8446] is safe under replay and (2) specifying a profile for its use (Appendix E.5 of [RFC8446]) are both out of scope 🫣💀
4.2. Theory of Operation 🎀
okay so the big idea behind the Transport Converter is letting a specific extension, like Multipath TCP, work on just a subset of the path even when the peer doesn't support that extension 🦋 it's giving clever middleman energy, ngl. Figure 4 shows the vibe: the Client starts a Multipath TCP connection with the Transport Converter (the MPTCP packets are drawn with "===") while the Transport Converter uses a regular TCP connection with the Server 💖
Client Transport Server
| Converter |
| | |
|==================>|--------------------->|
| | |
|<==================|<---------------------|
| | |
Multipath TCP packets TCP packets
Figure 4: An Example of 0-RTT Network-Assisted Outgoing MPTCP
ConnectionThe packets for a connection that goes through a Transport Converter might take a different route than the packets that go directly between the Client and the Server 🛣️ so deployments should keep the extra delay down by carefully picking where the Transport Converter sits for a given destination ✨
So when a Client sets up a connection, it can either talk straight to the Server (like sending a TCP SYN toward the Server) or create the connection through a Transport Converter, depending on local policies 🧚 if it goes the converter route, the Client opens a connection to the Transport Converter and puts the Server's IP address and port number right inside the connection establishment packet. This lets the Transport Converter start a connection to that Server immediately, without adding any extra delay 🚀 the Transport Converter then waits for the Server to confirm it's happy to set up the connection before it confirms anything to the Client 🫶
The Client puts the destination address and port number of the Server in the payload of the SYN it sends to the Transport Converter, all to keep connection setup delays low 💅 and the Transport Converter ends up juggling two connections that get stitched 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 the Transport Converter gets over the upstream (or downstream) connection gets proxied over the downstream (or upstream) connection. It's literally a relay, bestie 🏃♀️💨
Figure 5 shows how an outgoing TCP connection gets set up by a Client through a Transport Converter.
| Note: The information shown between brackets in Figure 5 (and
| other figures in the document) refers to Convert Protocol
| messages described in Section 6.
Transport
Client Converter Server
| | |
|SYN [->Server:port]| SYN |
|------------------>|--------------------->|
|<------------------|<---------------------|
| SYN+ACK [ ] | SYN+ACK |
| ... | ... |
Figure 5: Establishment of an Outgoing TCP Connection through a
Transport ConverterHere's the flow 🎬 the Client sends a SYN to the Transport Converter, and that SYN's payload has the Server's address and port number. The Transport Converter does not answer that SYN right away. It first tries to create a TCP connection toward the target Server. If that upstream connection works out, the Transport Converter confirms the connection to the Client with a SYN+ACK, and the first bytes of the bytestream carry info about the TCP options that were negotiated with the Server 🌸 at this point, a state entry gets created for the connection. The Converter uses that state entry to handle the messages that come after, so it's basically the connection's memory 🧠
Now the connection can also come from the Internet toward a Client through a Transport Converter (Figure 6). This is usually the case when the Client runs an application Server that listens on a specific port number 🌈 when the Converter gets an incoming SYN from a remote host, it checks whether it can provide the conversion service for that SYN's destination IP address and destination port number. The Transport Converter gets that SYN because it's, for example, on the path between the remote host and the Client, or because it provides address-sharing service for the Client (Section 2 of [RFC6269]) 👑 if the check fails, the Converter silently ignores the packet 🙈 if the check passes, the Converter tries to start a TCP connection toward the Client from its own address, using its configured TCP options. In the SYN for that connection attempt, the Transport Convert inserts a TLV message that indicates the source address and port number of the remote host. The Converter then creates a transport session entry for this connection. SYN+ACK and ACK then get exchanged between the Client, the Converter, and the remote host to confirm the connection is established, and the Converter uses that transport session entry to proxy the packets for the connection 💜
Transport Remote
Client Converter Host (RH)
| | |
|SYN [<-RH IP@:port]| SYN |
|<------------------|<---------------------|
|------------------>|--------------------->|
| SYN+ACK [ ] | SYN+ACK |
| ... | ... |
Figure 6: Establishment of an Incoming TCP Connection through a
Transport ConverterOkay, the data-in-SYN drama is a whole thing 😭 standard TCP (Section 3.4 of [RFC0793]) lets a SYN carry data in its payload, but the receiver is forbidden from handing that data to the application until the three-way handshake is complete. So to let applications swap data during the TCP handshake, this spec takes a similar approach to TCP Fast Open [RFC7413] and removes that constraint by allowing data in SYN packets to be delivered to the Transport Converter application ✨
As [RFC7413] points out, this change to TCP semantics raises two issues 👀 first, duplicate SYNs can cause problems for applications that rely on TCP, and whether a given application gets affected depends on the details of its application protocol. Second, TCP suffers from SYN flooding attacks [RFC4987] 😱 TFO solves both of these for applications that can handle replays, by using the TCP Fast Open option that includes a cookie. The catch is that this option eats up space in the limited TCP header. Plus, there are situations, as noted in Section 7.3 of [RFC7413], where it's possible to accept the payload of SYN packets without creating extra security risks. One example is a network where addresses can't be spoofed and the Transport Converter only serves a set of hosts identified by those addresses 🔒
For all these reasons, this specification does not mandate the use of the TCP Fast Open option when the Client sends a connection establishment packet toward a Transport Converter 🙌 instead, the Convert Protocol includes an optional Cookie TLV that gives similar protection to the TCP Fast Open option without using up space in the TCP header 💅 and this design also allows for longer cookies than [RFC7413] does, which is so iconic 🍓
Now, if the downstream (or upstream) connection fails for some reason (excessive retransmissions, reception of an RST segment, etc.), the Converter reacts by forcing the upstream (or downstream) connection to tear down 💀 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 sends 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's acknowledged or the connection times out 🔁 a classification of ICMP soft and hard errors is provided in Table 1 of [RFC5461] 📋
The same logic applies when the upstream connection ends with an exchange of FIN segments. In that case, the Converter will also terminate the downstream connection by using FIN segments 👋 and if the downstream connection terminates with an exchange of FIN segments, the Converter should initiate a graceful termination of the upstream connection 🫧
4.3. Data Processing at the Transport Converter ✨
okay so, like we said in Section 4.2, the Transport Converter is basically a TCP proxy 🦋 It sits between the upstream connection (Client ↔ Transport Converter) and the downstream connection (Transport Converter ↔ Server). Main character energy, fr.
The control messages (aka the Convert messages from Section 6) set up some state called a transport session entry 🎀 That's what lets the Converter proxy between the two TCP connections.
The Converter uses that transport session entry to proxy packets for the connection. Here's an example of what one looks like for TCP connections 👇
(C,c) <--> (T,t), (S,s), Lifetime
Figure 7: An Example of Transport Session EntryHere's what the letters mean:
Candcare the source IP address and source port number the Client uses for the upstream connection.Sandsare the Server's IP address and port number.Tandtare the source IP address and source port number the Transport Converter uses to proxy the connection.Lifetimeis a timer that keeps track of how much time the entry has left, as assigned by the Converter. When it runs out, the entry gets deleted 💀
Clients send packets for connections that are eligible for the conversion service to the provisioned Transport Converter and destination port number. This goes for both control messages and data 💅 Extra info gets passed from Clients to the Transport Converter through Convert messages, which Section 6 covers in detail. User data can show up in SYN or non-SYN messages. The Transport Converter can tell user data apart from Convert TLVs because of the Convert Fixed Header in the Convert messages (Section 6.1). The Convert TLVs are meant for the Transport Converter itself, so it strips them out when it proxies between the two connections 🧚
When a packet shows up that belongs to an existing connection between a Client and the Transport Converter, the Converter forwards the user data to the Server using the info stored in the matching transport session entry. For example, using Figure 7, the Transport Converter proxies data received from (C,c) downstream, with (T,t) as the source transport address and (S,s) as the destination transport address 🌸
The same thing happens for data coming from the Server, just in reverse. The Converter acts as a TCP proxy and sends the data to the Client based on the info in a transport session entry. The Converter also gives a lifetime to the state entries that tie an upstream connection to its downstream connection ⏳
When Multipath TCP is used between the Client and the Transport Converter, the Converter keeps more state for each Multipath TCP connection (for example, info about the subflows) 🌈 The procedure above still applies, except the Converter also has to handle setting up and tearing down subflows and scheduling packets across the ones that are established. Those jobs belong to the Multipath TCP implementation. They're separate from the Convert Protocol, which only handles the Convert messages at the start of the bytestream 💜
A Transport Converter can run in address preservation mode, where it does not rewrite the source IP address (so C==T), or in address-sharing mode, where an address pool is shared across all Clients the Converter serves (so C!=T). Check Section 4.4 for more details. Which one to use is up to the deployment 🍓 If address-sharing mode is enabled, the Transport Converter MUST adhere to REQ-2 of [RFC6888], which implies that a default "IP address pooling" behavior of "Paired" (as defined in Section 4.1 of [RFC4787]) MUST be supported. This is there so apps that depend on the source address staying the same don't break 🫶
4.4. Address Preservation vs. Address Sharing ✨
The Transport Converter gets instructions on how to handle the source addresses of outgoing packets. The next two subsections walk through two deployment models, just for illustration. It's not this document's job to recommend one 🙈
4.4.1. Address Preservation 🌷
In this model, the visible source IP address of a packet that the Transport Converter proxies to a Server is the end host's (Client's) IP address. No dedicated IP address pool is provisioned to the Transport Converter, but the Converter sits on the path between the Client and the Server 🦋
For Multipath TCP, the Transport Converter keeps the source IP address the Client used when setting up the initial subflow. Data on secondary subflows gets proxied by the Transport Converter using the source IP address of the initial subflow. Here's an example of a proxied Multipath TCP connection with address preservation 👇
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.
Figure 8: Example of Address PreservationThe Transport Converter must be on the forwarding path of incoming traffic. Since the same (destination) IP address is used for both proxied and non-proxied connections, the Transport Converter should not drop incoming packets it intercepts when no matching entry is found for them. Unless it's explicitly configured otherwise, those packets get forwarded according to the instructions in a local forwarding table 🧭
4.4.2. Address/Prefix Sharing 🎀
A pool of global IPv4 addresses gets provisioned to the Transport Converter, along with possible instructions about the address-sharing ratio to apply (see Appendix B of [RFC6269]). That means one address ends up shared among multiple Clients 👯♀️
Similarly, rewriting the source IPv6 prefix [RFC6296] may be used to make it easier to redirect incoming IPv6 traffic to the right Transport Converter. A pool of IPv6 prefixes is then provisioned to the Transport Converter for this purpose ✨
Forwarding policies are enforced so that traffic headed to an address in such a pool gets intercepted by the right Transport Converter. Unlike Section 4.4.1, the Transport Converter drops incoming packets that don't match an active transport session entry 🚫
Here's an example 👇
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.
Figure 9: Address Sharing5. Sample Examples ✨
5.1. Outgoing Converter-Assisted Multipath TCP Connections
okay bestie, let's look at how the Convert Protocol can help Multipath TCP get deployed 🦋 we're assuming the Client and the Transport Converter both support Multipath TCP, but the vibe changes depending on whether the Server supports it too 👀
quick reminder: a Multipath TCP connection gets started by putting the MP_CAPABLE (MPC) option in the SYN that the Client sends 💖
Figure 10 shows what the Transport Converter does when 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 |
| ... | ... |Figure 10: Establishment of a Multipath TCP Connection through a Transport Converter towards a Server That Does Not support Multipath TCP
So the Client kicks things off with a SYN carrying the MP_CAPABLE option (that's the MPC in Figure 10) 🌸 The SYN includes the address and port number of the target Server. The Transport Converter pulls those out and uses them to start its own Multipath TCP connection to that Server 🧚 Since the Server doesn't support Multipath TCP, it replies with a SYN+ACK that doesn't have the MP_CAPABLE option. The Transport Converter notices the Server isn't MPTCP-capable and sends the extended TCP header it got from the Server back to the Client 😭
Now, if the TCP connection gets reset for some reason, the Converter tears the Multipath TCP connection down by sending an MP_FASTCLOSE 💀 And if the Multipath TCP connection ends with DATA_FINs, the Converter ends the TCP connection with FIN segments 🫶
ngl this next bit is so cute 🥹 with Multipath TCP, an RST only covers the subflow, so it only closes that one subflow and leaves the others alone. So the Converter does not terminate the downstream TCP connection when it gets an RST over a Multipath subflow ✨
Figure 11 is the glow-up scenario, where the Server does support Multipath TCP 🎀 It answers the SYN from the Transport Converter with the MP_CAPABLE option. When the Transport Converter gets that SYN+ACK, it confirms the connection to the Client and tells the Client that the Server supports Multipath TCP. So the Client now knows the Server is MPTCP-capable, and it can skip the Transport Converter for future Multipath TCP connections it starts toward that Server 🦋👑
Transport
Client Converter Server
|SYN, MPC | |
|[->Server:port] | SYN, MPC |
|------------------>|--------------------->|
|<------------------|<---------------------|
|SYN+ACK, MPC | SYN+ACK, MPC |
|[MPC supported] | |
|------------------>|--------------------->|
| ACK, MPC | ACK, MPC |
| ... | ... |Figure 11: Establishment of a Multipath TCP Connection through a Converter towards an MPTCP-Capable Server
5.2. Incoming Converter-Assisted Multipath TCP Connection
here's an example of an incoming Converter-assisted Multipath TCP connection 🌈 For remote hosts to reach the Client, the Client may use the Port Control Protocol (PCP) [RFC6887] to tell the Transport Converter to create dynamic mappings. The Transport Converter uses those mappings to catch an incoming TCP connection headed for the Client and turn it into a Multipath TCP connection 🫶
Transport Remote
Client Converter Host
| | |
|<--------------------|<-------------------|
|SYN, MPC | SYN |
|[Remote Host:port] | |
|-------------------->|------------------->|
| SYN+ACK, MPC | SYN+ACK |
|<--------------------|<-------------------|
| ACK, MPC | ACK |
| ... | ... |Figure 12: Establishment of an Incoming Multipath TCP Connection through a Transport Converter
Typically, the Client sends a PCP request to the Converter asking it to create an explicit TCP mapping for the internal IP address and internal port number 💅 The Converter says yes 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 get sent back to the Client in the PCP response. Then the Client (or the user) advertises the external IP address and external port number through an out-of-band mechanism, so remote hosts can start TCP connections to the Client via the Converter 🧚 Note that the external and internal information may be the same ✨
Next, when the Converter gets an incoming SYN, it checks its mapping table to see if there's an active mapping that matches the destination IP address and destination port of that SYN 👀 If there's no entry, the Converter silently ignores the message 🙈 If there is one, the Converter inserts an MP_CAPABLE option and a Connect TLV into the SYN packet, rewrites the source IP address to one of its own IP addresses, and maybe rewrites the destination IP address and port number too, based on what's stored in the mapping. Then the SYN+ACK and ACK get exchanged between the Client and the Converter to confirm the initial subflow is up 🎀 After that, the Client can add new subflows using normal Multipath TCP procedures 🦋
It's out of scope for this document to define specific Convert TLVs for managing incoming connections (basically TLVs that copy PCP messages). Those can be defined in a separate document 🌸
6. The Convert Protocol (Convert) 🎀
okay, this is where the Convert Protocol itself comes in 💜 This section defines the Convert Protocol (Convert, for short) messages that get exchanged between a Client and a Transport Converter.
The Transport Converter listens on a specific TCP port number for Convert messages from Clients. An administrator configures that port number 🔥 Absent any policy, the Transport Converter SHOULD silently ignore SYNs with no Convert TLVs 🙈
Convert messages may appear only in SYN, SYN+ACK, or ACK 💅
Convert messages MUST be included as the first bytes of the bytestream. Every Convert message starts with a fixed header that's 32 bits long (Section 6.1), followed by one or more Convert TLVs (Type, Length, Value) (Section 6.2) ✨
If the initial SYN message has user data in its payload (for example, see [RFC7413]), that data MUST be placed right after the Convert TLVs when the SYN is generated 🫶
The protocol can be extended by defining new TLVs or by bumping the version number if a totally different message format is needed 🌈 If a future version is defined with a different message format, the version negotiation procedure in Section 6.2.8 (see "Unsupported Version") is meant to help both peers agree on a version they both support 🧚
Implementation note 1: Several implementers expressed concerns about the use of TFO. As a reminder, the Fast Open Cookie protects from some attack scenarios that affect open servers like web servers. The Convert Protocol is different and, as discussed in [RFC7413], there are different ways to protect from such attacks. Instead of using a Fast Open Cookie inside the TCP options, which consumes precious space in the extended TCP header, the Convert Protocol supports the utilization of a Cookie that is placed in the SYN payload. This provides the same level of protection as a Fast Open Cookie in environments were such protection is required. Implementation note 2: Error messages are not included in RST but sent in the bytestream. Implementers have indicated that processing RST on Clients was difficult on some platforms. This design simplifies Client implementations.
6.1. The Convert Fixed Header
the Convert Protocol uses a fixed header that's 32 bits long, and both the Client and the Transport Converter send it over each established connection 💖 This header tells you both the version of the protocol being 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 |
+---------------+---------------+-------------------------------+Figure 13: The Convert Fixed Header
The version is an 8-bit unsigned integer. This document specifies version 1 ✨ Version 0 is reserved by this document and MUST NOT be used 🙅♀️
Note: Early versions of this specification didn't use a dedicated port number and only relied on the IP address of the Converter. Having a bit set in the Version field together with the Total Length field avoids misreading data in a SYN as Convert TLVs. Since the design was updated to use a specific service port, that constraint was relaxed. Version 0 would work, but given existing implementations already use Version 1, the use of Version 0 is kept reserved.
The Total Length is the number of 32-bit words, including the header, of the bytestream that the Convert messages consume. Since Total Length is also an 8-bit unsigned integer, those messages can't consume more than 1020 bytes of data 📏 That caps how many bytes a Transport Converter has to process 🫶 A Total Length of zero is invalid, and the connection MUST be reset when a header with that total length comes in 💀
The Magic Number field MUST be set to 0x2263 🔮 It's there to further strengthen the protocol so any data supplied by an application can be clearly told apart from Convert TLVs 🌸
The Total Length field clearly marks the number of 32-bit words that carry Convert TLVs at the beginning of the bytestream 🧚
6.2. Convert TLVs
6.2.1. Generic Convert TLV Format ✨
okay bestie, the Convert Protocol sends variable length messages, and they're all built from one generic TLV format 🎀 (see Figure 14).
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 //
+---------------------------------------------------------------+Figure 14: Convert Generic TLV Format
Every TLV length is always a multiple of four bytes 💅, and every TLV is aligned on a 32-bit boundary. All the TLV fields use network byte order 🌸.
The Length field covers the Type, Length, and Value fields 🧚. It's expressed in units of 32-bit words, not bytes 😭. Value MUST be padded with zeroes so the length of the TLV is a multiple of 32 bits 🫶.
A given TLV MUST only appear once on a connection ✨. If a Client receives two or more instances of the same TLV over a Convert connection, it MUST reset the associated TCP connection 💀. If a Converter receives two or more instances of the same TLV over a Convert connection, it MUST return a Malformed Message Error TLV and close the associated TCP connection 🙈.
6.2.2. Summary of Supported Convert TLVs 🦋
this document specifies the following Convert TLVs, and honestly the table is giving clean organisation 💜:
+======+======+==========+==============================+
| Type | Hex | Length | Description |
+======+======+==========+==============================+
| 1 | 0x1 | 1 | Info TLV |
+------+------+----------+------------------------------+
| 10 | 0xA | Variable | Connect TLV |
+------+------+----------+------------------------------+
| 20 | 0x14 | Variable | Extended TCP Header TLV |
+------+------+----------+------------------------------+
| 21 | 0x15 | Variable | Supported TCP Extensions TLV |
+------+------+----------+------------------------------+
| 22 | 0x16 | Variable | Cookie TLV |
+------+------+----------+------------------------------+
| 30 | 0x1E | Variable | Error TLV |
+------+------+----------+------------------------------+Table 1: The TLVs Used by the Convert Protocol
Type 0x0 is a reserved value 🙈. If a Client receives a TLV of type 0x0, it MUST reset the associated TCP connection. If a Converter receives a TLV of type 0x0, it MUST return an Unsupported Message Error TLV and close the associated TCP connection.
The Client typically sends, in the first connection it established with a Transport Converter, the Info TLV (Section 6.2.3) to learn its capabilities 🔍. Assuming the Client is authorized to invoke the Transport Converter, the latter replies with the Supported TCP Extensions TLV (Section 6.2.4) 👑.
The Client can request the establishment of connections to Servers by using the Connect TLV (Section 6.2.5) 🌈. If the connection can be established with the final Server, the Transport Converter replies with the Extended TCP Header TLV (Section 6.2.6). If not, the Transport Converter MUST return an Error TLV (Section 6.2.8) and then close the connection. The Transport Converter MUST NOT send an RST immediately after the detection of an error, so the Error TLV can reach the Client 🫶. As explained later, the Client will send an RST regardless upon reception of the Error TLV 💅.
6.2.3. The Info TLV 🔍
the Info TLV (Figure 15) is an optional TLV that a Client can send to request the TCP extensions supported by a Transport Converter 🧚. It's typically sent on the first connection that a Client establishes with a Transport Converter, to learn its capabilities ✨. Assuming a Client is entitled to invoke the Transport Converter, the latter replies with the Supported TCP Extensions TLV described in Section 6.2.4 🎀.
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 |
+---------------+---------------+-------------------------------+Figure 15: The Info TLV
6.2.4. Supported TCP Extensions TLV 🎀
the Supported TCP Extensions TLV (Figure 16) is how a Transport Converter announces the TCP options it provides a conversion service for 👑. A Transport Converter SHOULD include in this list the TCP options that it supports in outgoing SYNs 💖.
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 | ... |
+---------------+---------------+-------------------------------+
/ ... /
/ /
+---------------------------------------------------------------+Figure 16: The Supported TCP Extensions TLV
each supported TCP option is encoded with its TCP option Kind, as listed in the "Transmission Control Protocol (TCP) Parameters" registry maintained by IANA [IANA-CONVERT] 🦋. The Unassigned field MUST be set to zero by the Transport Converter and ignored by the Client 🫶.
TCP option Kinds 1 and 2, defined in [RFC0793], are supported by 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-bit boundary 🌸.
For example, if the Transport Converter supports Multipath TCP, Kind=30 will be present in the Supported TCP Extensions TLV that it returns in response to the Info TLV 🌈✨.
6.2.5. Connect TLV ✨
okay bestie, the Connect TLV (Figure 17) is the one you send when you want a Transport Converter to set up a connection for you 💅 and it works for connections going from a Client or coming back to one 🦋
the Remote Peer Port and Remote Peer IP Address fields hold the destination port and IP of the Server when it's an outgoing connection 🌸 and for incoming connections heading to a Client that's served through a Transport Converter, they carry the source port and IP from the SYN the Converter got from the Server 🧚
the Remote Peer IP Address MUST be encoded as an IPv6 address 💖 IPv4 addresses MUST use the IPv4-mapped IPv6 address format from [RFC4291] 🎀 and the Remote Peer IP Address field MUST NOT include multicast, broadcast, or host loopback addresses [RFC6890] 🙈 so if a Converter gets a Connect TLV with any of those invalid addresses, it MUST reply with a Malformed Message Error TLV and close the associated TCP connection 💀
there are two flavours of Connect TLV based on length 🍓 the Base Connect TLV has a length of 5 (so 20 bytes total) and carries a remote address and remote port (Figure 17) ✨ and the Extended Connect TLV is longer than 20 bytes and adds the optional TCP Options field (Figure 18) 👑 that one is for asking the Server to be sent specific TCP options 🫶
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) |
| |
| |
+---------------------------------------------------------------+
Figure 17: The Base Connect TLV 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) /
/ ... /
+---------------------------------------------------------------+
Figure 18: The Extended Connect TLVthe TCP Options field is variable length and holds a list of TCP option fields (Figure 19) 🌈 each one is a block of 2+n bytes, where the first byte is the TCP option Kind and the second is the option's length as defined in [RFC0793] 🦋 the minimum Length value is 2 ✨ options that don't have a length sub-field, meaning option types 0 (EOL) and 1 (NOP) from [RFC0793], MUST NOT be placed inside the TCP options field of the Connect TLV 🙅♀️ the optional Value field holds the variable-length part of the option, and a length of 2 means there's no Value field at all 🌸 the TCP options field always ends on a 32-bit boundary, padded with zeros 🧸
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) | .... |
+---------------+---------------+---------------+---------------+
| .... |
+---------------------------------------------------------------+
| ... |
+---------------------------------------------------------------+
Figure 19: The TCP Options Fieldwhen a Base Connect TLV shows up, and as long as there's no policy (like rate-limiting) or resource exhaustion getting in the way 🚦 a Transport Converter tries to connect to the address and port inside it 💖 it MUST use by default the TCP options that match its local policy to set that up 🎀
when an Extended Connect TLV arrives, the Transport Converter first checks whether it supports the TCP Options listed in the TCP Options field 🔍 if it doesn't, it sends back an error TLV set to "Unsupported TCP Option" (Section 6.2.8) 😭 if that check passes, and there's no rate-limit policy or resource exhaustion happening, the Transport Converter MUST attempt to connect to the address and port inside 🔥 it MUST include in the SYN it sends to the Server both the options listed in the TCP Options subfield AND the TCP options it would have used according to its local policies 🫶 for options listed without an optional value, the Transport Converter MUST generate its own value 💅 and for options listed with an optional value, it MUST copy the entire option into the SYN sent to the remote Server 🦋 this procedure is designed with TFO in mind 🧚 it especially lets a Fast Open Cookie get exchanged between the Client and the Server, so see Section 7 for the full tea on the different TCP option types ☕✨
a Transport Converter MAY refuse a Connect TLV request for a bunch of reasons (like failed authorization, being out of resources, an invalid address type, or an unsupported TCP option) 🙃 when that happens, an error message explaining what went wrong goes back to the requesting Client (Section 6.2.8) 💌 and to stop denial-of-service attacks, error messages sent to a Client SHOULD be rate-limited 🛡️🚨
6.2.6. Extended TCP Header TLV ✨
the Extended TCP Header TLV (Figure 20) is how the Transport Converter sends the Client back the TCP options that the Server returned in the SYN+ACK 🎀 a Transport Converter MUST return this TLV if the Client sent an Extended Connect TLV and the Server accepted the connection 💖
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 /
/ ... /
+---------------------------------------------------------------+
Figure 20: The Extended TCP Header TLVthe Returned Extended TCP header field is a copy of the TCP Options that were in the SYN+ACK the Transport Converter received 🦋
the Unassigned field MUST be set to zero by the sender and ignored by the receiver 🙈
6.2.7. The Cookie TLV ✨
the Cookie TLV (Figure 21) is optional and works kind of like the TCP Fast Open Cookie from [RFC7413] 🍓 a Transport Converter might want to check that a Client can actually receive the packets it sends, which helps stop attacks from spoofed addresses 🕵️♀️ it can do that by using a Cookie tied to, for example, the Client's IP address(es) 🌸 that Cookie can be set up on the Client through means outside this document, or the Transport Converter can hand it over 🧚
a Transport Converter that's configured to use the optional Cookie TLV MUST verify that this TLV is in the payload of the received SYN 👑 if it's there, the Transport Converter MUST validate the Cookie using methods similar to those in Section 4.1.2 of [RFC7413] (aka IsCookieValid) 💅 if the Cookie is valid, connection setup can keep going ✨ otherwise, the Transport Converter MUST return an Error TLV set to "Not Authorized" and close the connection 😤
if the received SYN didn't have a Cookie TLV and cookie validation is required, the Transport Converter MAY compute a Cookie bound to this Client address 🌈 in that case, the Transport Converter MUST return an Error TLV set to "Missing Cookie" along with the computed Cookie, and close the connection 🫶 the Client reacts to this error by first sending a reset to end the connection 💥 then it stores the received Cookie in its cache and tries to reestablish a new connection to the Transport Converter that includes the Cookie TLV 🔁🦋
the format of the Cookie TLV is shown in Figure 21 🎀
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 /
/ ... /
+---------------------------------------------------------------+
Figure 21: The Cookie TLV6.2.8. Error TLV ✨
Okay so the Error TLV (Figure 22) is the little note that tells you something went sideways while a Convert message was being processed 🙈. It has a variable length. When a Client receives one, it MUST reset the associated connection, no exceptions, bestie 💀.
An Error TLV can ride along in the SYN+ACK or in an ACK 🫶.
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 //
+---------------------------------------------------------------+
Figure 22: The Error TLVErrors can happen in lots of different ways while Convert messages are processed 🌸. Each error gets an Error Code, which is an unsigned integer. There are four classes of error codes, and they're sorted by number range:
- Message validation and processing errors (0-31 range): returned when a message is invalid. This also covers messages that are valid but have invalid or unknown TLVs.
- Client-side errors (32-63 range): the Client asked for something the Transport Converter couldn't accept, like an unsupported operation.
- Converter-side errors (64-95 range): something went wrong on the Transport Converter, like running out of resources, so it can't do what the Client asked.
- Errors caused by the destination Server (96-127 range): the final destination couldn't be reached, or it answered with a reset.
Here are the error codes defined in this document 💖.
Unsupported Version (0): the version number in the fixed header of a message from a peer isn't supported. This error code MUST be generated by a peer (for example, a Transport Converter) when it gets a request with a version number it doesn't support 🙅♀️.
The Value field MUST be set to the version supported by the peer. If the peer supports several versions, the Value field carries the list of supported versions, with each version encoded in 8 bits. That list MUST be padded with zeros so it ends on a 32-bit boundary 🧚.
When the remote peer (for example, a Client) gets this error code, it checks whether it supports any of the versions the other side sent back. The highest commonly supported version number MUST be used by the remote peer in later exchanges with that peer 👑.
Malformed Message (1): this one says a message from a peer couldn't be parsed and validated successfully 💀. Typically, the Transport Converter sends it if it gets a Connect TLV that encloses a multicast, broadcast, or loopback IP address.
To make troubleshooting easier, the Value field MUST echo the received message in the format shown in Figure 23. That format keeps the original alignment of the message that caused the error, so it's easier to see what went wrong 🔍.
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 | Zeros |
+---------------+---------------+----------------+--------------+
// Echo the message that triggered the error //
+---------------------------------------------------------------+
Figure 23: Error TLV to Ease Message CorrelationUnsupported Message (2): this one is sent when the message type a Client sent isn't supported 🙈. To make troubleshooting easier, the Value field MUST echo the received message in the format shown in Figure 23.
Missing Cookie (3): this is for when a Transport Converter needs Cookies to stop spoofing attacks, but the Convert message didn't include a Cookie TLV 🍓. The Transport Converter MUST return this error to the requesting Client only if it computes a cookie for that Client. The first byte of the Value field MUST be set to zero, and the rest of the Error TLV carries the Cookie the Transport Converter computed for this Client.
A Client that gets this error code SHOULD cache the Cookie it received and include it in later Convert messages it sends to that Transport Converter 💜.
Not Authorized (32): this means the Transport Converter refused to create a connection because of a lack of authorization. Think administratively prohibited, an authorization failure, or an invalid Cookie TLV 🚫. The Value field MUST be set to zero.
This error code MUST be sent by the Transport Converter when a request can't be processed successfully because authorization failed 🔒.
Unsupported TCP Option (33): the Client asked for a TCP option to be advertised to the final Server, but that option can't be used safely 🧐. The Value field is set to the type of the unsupported TCP option. If the Connect TLV asked for several unsupported TCP options, the Value field returns the whole list. That list MUST be padded with zeros so it ends on a 32-bit boundary 🎀.
Resource Exceeded (64): the Transport Converter doesn't have enough resources to handle the request 😭. This error MUST be sent by the Transport Converter when it doesn't have enough resources for a new connection. The Transport Converter may indicate, in the Value field, a suggested delay in seconds that the Client SHOULD wait before asking the Transport Converter for a new proxied connection. A Value of zero means a default delay of at least 30 seconds ⏳.
Network Failure (65): the Transport Converter is having a network failure and can't proxy the request 🌧️. The Transport Converter MUST send this error code when it runs into forwarding problems while proxying a connection. Same deal as before: the Transport Converter may indicate a suggested delay in seconds in the Value field, which the Client SHOULD wait before asking for a new proxied connection. A Value of zero means a default delay of at least 30 seconds 🕰️.
Connection Reset (96): the final destination answered with an RST segment 💔. The Value field MUST be set to zero.
Destination Unreachable (97): the Transport Converter got an ICMP message reporting a hard error, like destination unreachable, port unreachable, or network unreachable 🛑. The Value field MUST echo the Code field of the received ICMP message.
Quick reminder, because this one's easy to mix up: TCP implementations are supposed to act on an ICMP error message that's passed up from the IP layer. They find the connection that caused the error by using the demultiplexing info inside that ICMP message's payload. That demultiplexing trick doesn't apply to the "Destination Unreachable" Error TLV, because the error is sent in-band. So the ICMP payload is NOT echoed in that Error TLV 🙃.
Table 2 sums up all of these error codes at a glance 📋.
+=======+======+=========================+
| Error | Hex | Description |
+=======+======+=========================+
| 0 | 0x00 | Unsupported Version |
+-------+------+-------------------------+
| 1 | 0x01 | Malformed Message |
+-------+------+-------------------------+
| 2 | 0x02 | Unsupported Message |
+-------+------+-------------------------+
| 3 | 0x03 | Missing Cookie |
+-------+------+-------------------------+
| 32 | 0x20 | Not Authorized |
+-------+------+-------------------------+
| 33 | 0x21 | Unsupported TCP Option |
+-------+------+-------------------------+
| 64 | 0x40 | Resource Exceeded |
+-------+------+-------------------------+
| 65 | 0x41 | Network Failure |
+-------+------+-------------------------+
| 96 | 0x60 | Connection Reset |
+-------+------+-------------------------+
| 97 | 0x61 | Destination Unreachable |
+-------+------+-------------------------+
Table 2: Convert Error Values7. Compatibility of Specific TCP Options with the Conversion Service ✨
Here we get into how several deployed Standards Track TCP options can work through the Convert Protocol 🦋. Other TCP options will get their own documents later 📚.
7.1. Base TCP Options
Three TCP options were originally defined in [RFC0793]: End-of-Option List (Kind=0), No-Operation (Kind=1), and Maximum Segment Size (Kind=2) 🌷. The first two are mainly used to pad the TCP header, so there's no reason for a Client to ask a Transport Converter to send them to the final destination 🙅♀️.
The Maximum Segment Size option (Kind=2) is how a host tells the other side the largest segment it can receive on each connection 📏. That value depends on the stack terminating the TCP connection. So there's no reason for a Client to ask 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] 🪟. Just like with MSS, the window scale factor for a connection depends heavily on the TCP stack handling that connection. When a Transport Converter opens a TCP connection to a remote Server on behalf of a Client, it SHOULD use a WS option with a scaling factor that matches its own stack's configuration ⚙️. A local configuration MAY let the WS option in the proxied message depend on the scaling factor of the incoming connection 🧩.
From a deployment point of view, there's no benefit in letting a Client ask a Transport Converter to use the WS option (Kind=3) with a specific scaling factor toward a remote Server 🙈. For that 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 ✨
okay so there are two distinct TCP options for SACK, defined in [RFC2018] 🧚. The first one is SACK-Permitted (Kind=4), and it's the one that negotiates whether SACK is even happening during the three-way handshake 🤝. The second one is SACK (Kind=5), which actually carries the selective acknowledgments inside regular segments 💌.
A Transport Converter MAY advertise the SACK-Permitted option (Kind=4) in the Supported TCP Extensions TLV 🦋. Clients connected to that Transport Converter MAY also include the SACK-Permitted option in the Connect TLV 🎀.
bestie, the SACK option (Kind=5) cannot be used during the three-way handshake 🙅♀️. So a Transport Converter MUST ignore option Kind=5 if it shows up in a Connect TLV 💅. It also MUST NOT announce it in a TCP Supported Extensions TLV 🚫. no SACK in the handshake, periodt 💀.
7.4. Timestamp ⏰
The Timestamp option [RFC7323] can be used during the three-way handshake to negotiate timestamps for the TCP connection 🕰️. It's notably used to improve round-trip-time estimations and to provide Protection Against Wrapped Sequences (PAWS) 🌸. Like with WS, timestamps are a property of a connection, so there's limited benefit in letting a Client ask a Transport Converter to use the timestamp option when setting up a connection to a remote Server 🙄. Also, the timestamps TCP stacks use are specific to each stack, so there's no benefit in letting a Client specify the timestamp value a Transport Converter could use to reach a remote Server 🤷♀️.
A Transport Converter MAY advertise the Timestamp option (Kind=8) in the TCP Supported Extensions TLV ✨. Clients connected to it 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) with 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 sends to a remote Server 💁.
A Transport Converter that supports the Multipath TCP conversion service MUST advertise the Multipath TCP option (Kind=30) in the Supported TCP Extensions TLV 📣. Clients served by it 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] 🍓. Transport Converters need to support two usages of it. The first is requesting a cookie from the Server: the Client sends the option with an empty cookie, and the Server returns the cookie. The second is sending a cookie to the Server: in that 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 it has advertised TFO support in that 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. When the Converter gets that SYN-ACK, 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 does contain a cookie, it MUST copy the TCP Fast Open Cookie option into the SYN sent to the remote Server 🍬.
7.7. TCP-AO 🔐
The TCP Authentication Option (TCP-AO) [RFC5925] provides a way to authenticate all the packets exchanged over a TCP connection 🛡️. Because this extension is end to end by nature, apps that need their packets authenticated end to end probably won't want their connections going through a converter 🙅. So we do not recommend supporting TCP-AO in Transport Converters 😬. The only situations where combining TCP-AO with this solution could make sense are the ones where the TCP-AO-NAT extension [RFC6978] is in use 🧐.
A Transport Converter MUST NOT advertise TCP-AO (Kind=29) in the Supported TCP Extensions TLV 🚫. If a Transport Converter receives a Connect TLV that contains TCP-AO, it MUST reject the establishment of the connection with the error code set to Unsupported TCP Option, except if the TCP-AO-NAT option is used 💥. Still, TCP-AO-NAT is Experimental, so its usage isn't currently defined, and some other document has to specify it before anyone can use it 📚.
8. Interactions with Middleboxes 🕵️♀️
The Convert Protocol is designed for networks that don't contain middleboxes interfering with TCP 🧼. In those conditions, the network provider is assumed to make sure all involved on-path nodes aren't breaking TCP signals (like stripping TCP options or discarding some SYNs) ✨.
Still, to keep the service robust, this section explains how a Client can detect middlebox interference and stop using the affected Transport Converter 🛟.
Internet measurements [IMC11] have shown that middleboxes can affect the deployment of TCP extensions 📊. Here we focus on middleboxes that modify the payload, since the Convert Protocol places its messages at the beginning of the bytestream 💬.
Consider a middlebox that removes the SYN payload 🗑️. A Client can detect this by looking at the acknowledgment number field of the SYN+ACK, if the Transport Converter returns one. The Client MUST stop using this Transport Converter because of the middlebox interference 🛑.
Now consider a middlebox that drops SYN/ACKs with a payload 😵. The Client won't be able to establish a connection via the Transport Converter. A middlebox that removes the payload of SYN+ACKs, or from the packet that follows the SYN+ACK (but not the payload of SYN), can be detected by a Client. This shows up as the absence of a valid Convert message in the response 🔍.
As explained in [RFC7413], some Carrier Grade NATs (CGNs) can affect the operation of TFO if they assign different IP addresses to the same end host 🌐. Such CGNs could also affect the cookie validation used by the Convert Protocol 🍪. As a reminder, CGNs that are enabled on the path between a Client and a Transport Converter must adhere to the address preservation defined in [RFC6888] 📌. See also the discussion in Section 7.1 of [RFC7413] 💖.
9. Security Considerations 🔒
An implementation MUST check that the Convert TLVs are properly framed within the boundary indicated by the Total Length in the fixed header (Section 6.1) 📏.
Additional security considerations are discussed in the following subsections 👀.
9.1. Privacy & Ingress Filtering 🕶️
The Transport Converter may have access to privacy-related information (e.g., subscriber credentials) 😱. It 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 it processes, payloads and metadata included. It has the ability to profile and run 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
okay bestie, auth is where things get serious 🔐✨ The Convert Protocol is RECOMMENDED for managed networks where end hosts can be securely identified by their IP address. If that kind of control isn't happening and the network is more open, a strong mutual authentication scheme MUST be defined to use the Convert Protocol. no cap, that's non-negotiable 💅
One option for mutual authentication is TLS. The Client and the Converter authenticate each other with TLS, so when a Client grabs a Cookie from the Converter, that connection is protected by TLS. You can rely on certificate-based client authentication, pre-shared key-based client authentication [RFC4279], or raw public key-based client authentication [RFC7250] to lock it down 🎀 If the auth works, the Converter hands back a cookie to the Client. After that, later Connect messages get authorized based on what's inside the Cookie TLV.
Here's the lowkey scary part 👀 an attacker sitting inside the network between a Client and a Transport Converter could steal the Cookie and use it to get into the conversion service. That only works if the attacker spoofs the Client's IP address and the network doesn't filter packets with source-spoofed IP addresses. so ingress filtering really matters, periodt 🛡️
The operator who runs the network attachments (Transport Converters included) has a bunch of ways to enforce auth and authorization policies. This list is not exhaustive, but here are some methods to get authorization:
- The network provider can enforce a policy based on the International Mobile Subscriber Identity (IMSI) to check that a user is allowed to use the TCP converter service. If that check fails, the Packet Data Protocol (PDP) context/bearer doesn't get set up. This method doesn't need any interaction with the Transport Converter for authorization stuff 📱
- The network provider can enforce a policy based on Access Control Lists (ACLs), for example at a Broadband Network Gateway (BNG), to control which hosts are allowed to talk to a Transport Converter. These ACLs might be installed as a result of RADIUS exchanges, for example [TCPM-CONVERTER]. This method also doesn't need any interaction with the Transport Converter for authorization 🙌
- A device that has a Transport Converter built in can also host a RADIUS Client, which asks a AAA Server whether connections from a given source IP address are authorized [TCPM-CONVERTER] 🔑
A first safeguard against illegitimate users misusing Transport Converter resources (for example, users on access networks that aren't managed by the same provider that runs the Transport Converter) is that the Transport Converter rejects Convert connections received in the external realm. Only Convert connections received in the internal realm of a Transport Converter get accepted 🏰
In deployments where network-assisted connections aren't allowed between hosts of a domain (this is called hairpinning), the Converter can be told to discard those connections. Hairpinned connections get rejected by the Transport Converter, which returns an Error TLV set to "Not Authorized". Otherwise, if there's no 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:x2Figure 24: Hairpinning Example
9.3. Denial of Service
okay now the DoS part 😭 amplification attacks are a real risk here, because a Transport Converter sends a SYN toward a remote Server every time it gets a SYN from a Client. This could turn into an amplification attack if the SYN the Transport Converter sends is bigger than the SYN it received from the Client, or if the Transport Converter retransmits the SYN. To mitigate this, the Transport Converter SHOULD rate-limit the number of pending requests for a given Client. It SHOULD also avoid sending SYNs to remote Servers that are way longer than the SYN received from the Client. Finally, the Transport Converter SHOULD only retransmit a SYN to a Server after it has received a retransmitted SYN from the corresponding Client. Protections against SYN flooding attacks should also be turned on (for example, Section 3 of [RFC4987]) 🛡️💀
Another threat is attacks from within the network between a Client and a Transport Converter, including attacks that change the protocol version 🙈 Means to make sure illegitimate nodes can't connect to a network should be implemented.
9.4. Traffic Theft
traffic theft is a whole vibe if an illegitimate Converter gets inserted into the path 🕵️♀️ Putting a fake Converter in the forwarding path lets someone intercept traffic, which can expose sensitive data sent by or destined to a host. Converter discovery and configuration are out of scope for this document, so we're not covering that here 🌸
9.5. Logging
if the Converter is set up to behave in the address-sharing mode (Section 4.4.2), you need to think about the logging recommendations in Section 4 of [RFC6888] 📝 Security issues that show up in address-sharing environments are documented in Section 13 of [RFC6269].
10. IANA Considerations
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", which lives 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 8803Clients can use this service name with the procedure defined in [RFC2782] to find the IP address(es) and port number used by the Transport Converters of a domain 🧚
10.2. The Convert Protocol (Convert) Parameters
IANA has created a brand new "TCP Convert Protocol (Convert) Parameters" registry 🎉
The subsections below detail the new registries inside the "Convert Protocol (Convert) Parameters" registry.
The designated expert is expected to confirm that suitable documentation exists, 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 that the purpose and use of the requested code points are clear.
Also, designated experts should look at a few more criteria: whether the proposed registration duplicates existing functionality, whether it's likely to be of general applicability or only useful for private use, and whether the registration description is clear. All requests should be sent 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. If a registration decision could look like a conflict of interest for a particular expert, that expert should defer to the judgment of the other experts 🫶
10.2.1. Convert Versions
IANA has created the "Convert Versions" subregistry. New values are assigned via IETF Review (Section 4.8 of [RFC8126]) ✨
The initial values of the registry are as follows:
+=========+=============+===========+
| Version | Description | Reference |
+=========+=============+===========+
| 0 | Reserved | RFC 8803 |
+---------+-------------+-----------+
| 1 | Assigned | RFC 8803 |
+---------+-------------+-----------+Table 3: Current Convert Versions
10.2.2. Convert TLVs
IANA has created the "Convert TLVs" subregistry 🌈 Here's how values get assigned from it:
1-127: IETF Review128-191: Specification Required192-255: Private Use
The initial values of the registry are as follows:
+======+=============================+===========+
| Code | Name | Reference |
+======+=============================+===========+
| 0 | Reserved | RFC 8803 |
+------+-----------------------------+-----------+
| 1 | Info TLV | RFC 8803 |
+------+-----------------------------+-----------+
| 10 | Connect TLV | RFC 8803 |
+------+-----------------------------+-----------+
| 20 | Extended TCP Header TLV | RFC 8803 |
+------+-----------------------------+-----------+
| 21 | Supported TCP Extension TLV | RFC 8803 |
+------+-----------------------------+-----------+
| 22 | Cookie TLV | RFC 8803 |
+------+-----------------------------+-----------+
| 30 | Error TLV | RFC 8803 |
+------+-----------------------------+-----------+Table 4: Initial Convert TLVs
10.2.3. Convert Error Messages
okay bestie, IANA made a "Convert Errors" subregistry 🧚 and the codes in it are grouped by what kind of error happened, not just numbered randomly 💅 There are four error types, and each one gets its own reserved range:
0-31: Message validation and processing errors32-63: Client-side errors64-95: Transport Converter-side errors96-127: Errors caused by destination Server
Next up is how new codes get handed out 🎀 Codes 0-127 go through IETF Review, codes 128-191 need Specification Required, and codes 192-255 are Private Use 🌈
Here are the starting codes in the registry, the main character list 👑
+=======+=========================+===========+
| Error | Description | Reference |
+=======+=========================+===========+
| 0 | Unsupported Version | RFC 8803 |
+-------+-------------------------+-----------+
| 1 | Malformed Message | RFC 8803 |
+-------+-------------------------+-----------+
| 2 | Unsupported Message | RFC 8803 |
+-------+-------------------------+-----------+
| 3 | Missing Cookie | RFC 8803 |
+-------+-------------------------+-----------+
| 32 | Not Authorized | RFC 8803 |
+-------+-------------------------+-----------+
| 33 | Unsupported TCP Option | RFC 8803 |
+-------+-------------------------+-----------+
| 64 | Resource Exceeded | RFC 8803 |
+-------+-------------------------+-----------+
| 65 | Network Failure | RFC 8803 |
+-------+-------------------------+-----------+
| 96 | Connection Reset | RFC 8803 |
+-------+-------------------------+-----------+
| 97 | Destination Unreachable | RFC 8803 |
+-------+-------------------------+-----------+
Table 5: Initial Convert Error Codes11. References
11.1. Normative References
Here are the normative references, the ones you genuinely need to read 📚🦋
[RFC0793]Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981,<https://www.rfc-editor.org/info/rfc793>.[RFC2018]Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996,<https://www.rfc-editor.org/info/rfc2018>.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<https://www.rfc-editor.org/info/rfc2119>.[RFC2827]Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000,<https://www.rfc-editor.org/info/rfc2827>.[RFC4291]Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006,<https://www.rfc-editor.org/info/rfc4291>.[RFC4787]Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007,<https://www.rfc-editor.org/info/rfc4787>.[RFC4987]Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,<https://www.rfc-editor.org/info/rfc4987>.[RFC5925]Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010,<https://www.rfc-editor.org/info/rfc5925>.[RFC6888]Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013,<https://www.rfc-editor.org/info/rfc6888>.[RFC6890]Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013,<https://www.rfc-editor.org/info/rfc6890>.[RFC7323]Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014,<https://www.rfc-editor.org/info/rfc7323>.[RFC7413]Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,<https://www.rfc-editor.org/info/rfc7413>.[RFC8126]Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,<https://www.rfc-editor.org/info/rfc8126>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,<https://www.rfc-editor.org/info/rfc8174>.[RFC8684]Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020,<https://www.rfc-editor.org/info/rfc8684>.
11.2. Informative References ✨
These are the extra reads, the background lore that's nice to know but not required. Bestie, the citations go hard 📚💅
[ANRW17] Trammell, B., Kuehlewind, M., De Vaere, P., Learmonth, I., and G. Fairhurst, "Tracking transport-layer evolution with PATHspider", Applied Networking Research Workshop 2017 (ANRW17), July 2017.
[DHC-CONVERTER] Boucadair, M., Jacquenet, C., and T. Reddy.K, "DHCP Options for 0-RTT TCP Converters", Work in Progress, Internet-Draft, draft-boucadair-tcpm-dhc-converter-03, 7 October 2019, https://tools.ietf.org/html/draft-boucadair-tcpm-dhc-converter-03.
[Fukuda2011] Fukuda, K., "An Analysis of Longitudinal TCP Passive Measurements (Short Paper)", Traffic Monitoring and Analysis, TMA 2011, Lecture Notes in Computer Science, vol. 6613, 2011.
[HOT-MIDDLEBOX13] Detal, G., Paasch, C., and O. Bonaventure, "Multipath in the Middle(Box)", HotMiddlebox'13, DOI 10.1145/2535828.2535829, December 2013, https://inl.info.ucl.ac.be/publications/multipath-middlebox.
[IANA-CONVERT] IANA, "TCP Convert Protocol (Convert) Parameters", https://www.iana.org/assignments/tcp-convert-protocol-parameters.
[IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployments", IETF Journal, Vol. 12, Issue 2, November 2016.
[IMC11] Honda, K., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and T. Hideyuki, "Is it still possible to extend TCP?", Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference, DOI 10.1145/2068816.2068834, November 2011, https://doi.org/10.1145/2068816.2068834.
[INTAREA-SOCKS] Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6", Work in Progress, Internet-Draft, draft-olteanu-intarea-socks-6-10, 13 July 2020, https://tools.ietf.org/html/draft-olteanu-intarea-socks-6-10.
[LOW-LATENCY] Arkko, J. and J. Tantsura, "Low Latency Applications and the Internet Architecture", Work in Progress, Internet-Draft, draft-arkko-arch-low-latency-02, 30 October 2017, https://tools.ietf.org/html/draft-arkko-arch-low-latency-02.
[MPTCP-PLAIN] Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, D., Secci, S., Henderickx, W., Skog, R., Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., Contreras, L., and B. Peirens, "Extensions for Network-Assisted MPTCP Deployment Models", Work in Progress, Internet-Draft, draft-boucadair-mptcp-plain-mode-10, March 2017, https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-10.
[MPTCP-TRANSPARENT] Peirens, B., Detal, G., Barre, S., and O. Bonaventure, "Link bonding with transparent Multipath TCP", Work in Progress, Internet-Draft, draft-peirens-mptcp-transparent-00, 8 July 2016, https://tools.ietf.org/html/draft-peirens-mptcp-transparent-00.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, https://www.rfc-editor.org/info/rfc1812.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, DOI 10.17487/RFC1919, March 1996, https://www.rfc-editor.org/info/rfc1919.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928, March 1996, https://www.rfc-editor.org/info/rfc1928.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, https://www.rfc-editor.org/info/rfc2782.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, https://www.rfc-editor.org/info/rfc3135.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, https://www.rfc-editor.org/info/rfc4279.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, https://www.rfc-editor.org/info/rfc5461.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, https://www.rfc-editor.org/info/rfc6269.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, https://www.rfc-editor.org/info/rfc6296.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive DNS Server Selection for Multi-Interfaced Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, https://www.rfc-editor.org/info/rfc6731.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, https://www.rfc-editor.org/info/rfc6887.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, https://www.rfc-editor.org/info/rfc6928.
[RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT Traversal", RFC 6978, DOI 10.17487/RFC6978, July 2013, https://www.rfc-editor.org/info/rfc6978.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, https://www.rfc-editor.org/info/rfc7250.
[RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, https://www.rfc-editor.org/info/rfc7414.
[RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and Operational Experience with Multipath TCP", RFC 8041, DOI 10.17487/RFC8041, January 2017, https://www.rfc-editor.org/info/rfc8041.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, https://www.rfc-editor.org/info/rfc8305.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, https://www.rfc-editor.org/info/rfc8446.
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic Protection of TCP Streams (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, https://www.rfc-editor.org/info/rfc8548.
[TCPM-CONVERTER] Boucadair, M. and C. Jacquenet, "RADIUS Extensions for 0-RTT TCP Converters", Work in Progress, Internet-Draft, draft-boucadair-opsawg-tcpm-converter-01, 28 February 2020, https://tools.ietf.org/html/draft-boucadair-opsawg-tcpm-converter-01.
[TS23501] 3GPP (3rd Generation Partnership Project), "Technical Specification Group Services and System Aspects; System architecture for the 5G System; Stage 2 (Release 16)", 2019, https://www.3gpp.org/ftp/Specs/archive/23_series/23.501/.
Appendix A. Example Socket API Changes to Support the 0-RTT TCP Convert Protocol 🦋
A.1. Active Open (Client Side)
Okay, the Client side is giving easy mode 🌸 Supporting the 0-RTT Converter protocol doesn't need any changes beyond the ones listed in Appendix A of [RFC7413]. Multiple TCP stacks already have those changes, so you're not starting from scratch.
As an example, on Linux, a Client can send the 0-RTT Convert message inside a SYN using sendto with the MSG_FASTOPEN flag, like this:
s = socket(AF_INET, SOCK_STREAM, 0);
sendto(s, buffer, buffer_len, MSG_FASTOPEN,
(struct sockaddr *) &server_addr, addr_len);The Client side of Linux TFO can run in two different modes, depending on the host configuration (the tcp_fastopen sysctl 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. Iconic 🔥
A.2. Passive Open (Converter Side)
Now the Converter side is where it gets spicy 🌶️ The Converter needs to accept data inside the SYN whether or not the TFO option is used. That means the Transport Converter application can't rely on the Fast Open Cookies to check that the IP address that sent the SYN is reachable. It must rely on other techniques, such as the Cookie TLV described in this document, to verify this reachability.
[RFC7413] suggested using the TCP_FASTOPEN socket option to accept SYNs that contain 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.
This configuration is system wide, though. That's 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 was added to give the same behavior on a per-socket basis ✨ That means a single host can support both Servers that require the Fast Open Cookie and Servers that don't use it. Main character host energy 👑
Acknowledgments ✨
Okay so even tho they might totally disagree with what's in here, we still wanna shout out Joe Touch and Juliusz Chroboczek 💅 Their comments on the MPTCP mailing list made the authors rethink the design of the solution like, several times 😭 That's dedication, bestie.
We also want to thank Raphael Bauduin, Stefano Secci, Anandatirtha Nandugudi, and Gregory Vander Schueren 🫶 for helping get this doc ready. Nandini Ganesh gave super useful feedback on how TFO gets handled and on the error codes 🔥 Yuchung Cheng and Praveen Balasubramanian helped make the discussion about putting data in SYNs way clearer ✨ Phil Eardley and Michael Scharf untangled different parts of the text 🧚 Big thanks to Éric Vyncke, Roman Danyliw, Benjamin Kaduk, and Alexey Melnikov for the IESG review, and to Christian Huitema for the Security Directorate review 👑
Many thanks to Mirja Kühlewind for the detailed AD review 💜
This document builds on earlier work that proposed different forms of Multipath TCP proxies: [MPTCP-PLAIN], [MPTCP-TRANSPARENT], and [HOT-MIDDLEBOX13]. So honestly, these are the OGs 🦋
From [MPTCP-PLAIN]:
Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi Nishida, and Christoph Paasch for their super valuable comments 🌸
Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and Sri Gundavelli for the fruitful discussions at IETF 95 (Buenos Aires) 🌈
Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and Xavier Grall for their input 🍓
Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun Srinivasan, and Raghavendra Mallya for their input 💖
Contributors 🌈
Bart Peirens contributed to an early draft version of this document 🎀
As noted above, this document builds on two previous documents, so let's give those folks their flowers too 💐
The authors of [MPTCP-PLAIN] were:
- Mohamed Boucadair
- Christian Jacquenet
- Olivier Bonaventure
- Denis Behaghel
- Stefano Secci
- Wim Henderickx
- Robert Skog
- Suresh Vinapamula
- SungHoon Seo
- Wouter Cloetens
- Ullrich Meyer
- Luis M. Contreras
- Bart Peirens
The authors of [MPTCP-TRANSPARENT] were:
- Bart Peirens
- Gregory Detal
- Sebastien Barre
- Olivier Bonaventure
Authors' Addresses 🦋
Here's where you can find the editors and authors, so slide into their inboxes if you have questions 💌
Olivier Bonaventure (editor)
Tessares
Avenue Jean Monnet 1
B-1348 Louvain-la-Neuve
Belgium
Email: Olivier.Bonaventure@tessares.net
Mohamed Boucadair (editor)
Orange
Clos Courtel
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sgundave@cisco.com
SungHoon Seo
Korea Telecom
151 Taebong-ro
Seocho-gu, Seoul, 06763
Republic of Korea
Email: sh.seo@kt.com
Benjamin Hesmans
Tessares
Avenue Jean Monnet 1
B-1348 Louvain-la-Neuve
Belgium
Email: Benjamin.Hesmans@tessares.net📦 where this page comes from
- ietf: rfc8803 2020-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms