idnits 2.17.1 draft-ietf-tcpm-converters-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([This-RFC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 22, 2019) is 1732 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-RFC' is mentioned on line 1547, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-03) exists of draft-boucadair-tcpm-dhc-converter-02 == Outdated reference: A later version (-11) exists of draft-olteanu-intarea-socks-6-07 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM Working Group O. Bonaventure, Ed. 3 Internet-Draft Tessares 4 Intended status: Experimental M. Boucadair, Ed. 5 Expires: January 23, 2020 Orange 6 S. Gundavelli 7 Cisco 8 S. Seo 9 Korea Telecom 10 B. Hesmans 11 Tessares 12 July 22, 2019 14 0-RTT TCP Convert Protocol 15 draft-ietf-tcpm-converters-09 17 Abstract 19 This document specifies an application proxy, called Transport 20 Converter, to assist the deployment of TCP extensions such as 21 Multipath TCP. This proxy is designed to avoid inducing extra delay 22 when involved in a network-assisted connection (that is, 0-RTT). 24 This specification assumes an explicit model, where the proxy is 25 explicitly configured on hosts. 27 Editorial Note (To be removed by RFC Editor) 29 Please update these statements with the RFC number to be assigned to 30 this document: [This-RFC] 32 Please update TBA statements with the port number to be assigned to 33 the 0-RTT TCP Convert Protocol. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 23, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.2. Network-Assisted Connections: The Rationale . . . . . . . 4 71 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 72 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 6 74 3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 8 75 3.3. Sample Examples of Outgoing Converter-Assisted Multipath 76 TCP Connections . . . . . . . . . . . . . . . . . . . . . 12 77 3.4. Sample Example of Incoming Converter-Assisted Multipath 78 TCP Connection . . . . . . . . . . . . . . . . . . . . . 13 79 4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 14 80 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 15 81 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 16 82 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 16 83 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16 84 4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17 85 4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 17 86 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 18 87 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 20 88 4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 21 89 4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 21 90 5. Compatibility of Specific TCP Options with the Conversion 91 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 25 93 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 26 94 5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 26 95 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 26 96 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 27 97 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 27 98 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 28 99 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 28 101 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 28 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 103 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 29 104 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 30 105 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 31 106 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 31 107 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 31 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 109 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 32 110 8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 32 111 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 32 112 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 33 113 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 33 114 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 115 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 116 9.2. Informative References . . . . . . . . . . . . . . . . . 36 117 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 39 118 Appendix B. Example Socket API Changes to Support the 0-RTT 119 Convert Protocol . . . . . . . . . . . . . . . . . . 41 120 B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 41 121 B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 42 122 Appendix C. Differences with SOCKSv5 . . . . . . . . . . . . . . 43 123 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44 124 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 45 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 127 1. Introduction 129 1.1. The Problem 131 Transport protocols like TCP evolve regularly [RFC7414]. TCP has 132 been improved in different ways. Some improvements such as changing 133 the initial window size [RFC6928] or modifying the congestion control 134 scheme can be applied independently on clients and servers. Other 135 improvements such as Selective Acknowledgements [RFC2018] or large 136 windows [RFC7323] require a new TCP option or to change the semantics 137 of some fields in the TCP header. These modifications must be 138 deployed on both clients and servers to be actually used on the 139 Internet. Experience with the latter TCP extensions reveals that 140 their deployment can require many years. Fukuda reports in 141 [Fukuda2011] results of a decade of measurements showing the 142 deployment of Selective Acknowledgements, Window Scale and TCP 143 Timestamps. [ANRW17] describes measurements showing that TCP Fast 144 Open (TFO) [RFC7413] is still not widely deployed. 146 There are some situations where the transport stack used on clients 147 (or servers) can be upgraded at a faster pace than the transport 148 stack running on servers (or clients). In those situations, clients 149 would typically want to benefit from the features of an improved 150 transport protocol even if the servers have not yet been upgraded and 151 conversely. Some assistance from the network to make use of these 152 features is valuable. For example, Performance Enhancing Proxies 153 [RFC3135], and other service functions have been deployed as 154 solutions to improve TCP performance over links with specific 155 characteristics. 157 Recent examples of TCP extensions include Multipath TCP [RFC6824] or 158 TCPINC [RFC8548]. Those extensions provide features that are 159 interesting for clients such as wireless devices. With Multipath 160 TCP, those devices could seamlessly use WLAN (Wireless Local Area 161 Network) and cellular networks, for bonding purposes, faster hand- 162 overs, or better resiliency. Unfortunately, deploying those 163 extensions on both a wide range of clients and servers remains 164 difficult. 166 More recently, 5G bonding experimentation has been conducted into 167 global range of the incumbent 4G (LTE) connectivity using newly 168 devised clients and a Multipath TCP proxy. Even if the 5G and the 4G 169 bonding relying upon Multipath TCP increases the bandwidth, it is as 170 well crucial to minimize latency for all the way between endhosts 171 regardless of whether intermediate nodes are inside or outside of the 172 mobile core. In order to handle URLLC (Ultra Reliable Low Latency 173 Communication) for the next generation mobile network, Multipath TCP 174 and its proxy mechanism such as the one used to provide Access 175 Traffic Steering, Switching, and Splitting (ATSSS) must be optimized 176 to reduce latency [TS23501]. 178 1.2. Network-Assisted Connections: The Rationale 180 This document specifies an application proxy, called Transport 181 Converter. A Transport Converter is a function that is installed by 182 a network operator to aid the deployment of TCP extensions and to 183 provide the benefits of such extensions to clients. A Transport 184 Converter may provide conversion service for one or more TCP 185 extensions. Which TCP extensions are eligible to the conversion 186 service is deployment-specific. The conversion service is provided 187 by means of the 0-RTT TCP Convert Protocol (Convert), that is an 188 application-layer protocol which uses TCP port number TBA 189 (Section 8). 191 The Convert Protocol provides 0-RTT (Zero Round-Trip Time) conversion 192 service since no extra delay is induced by the protocol compared to 193 connections that are not proxied. Particularly, the Convert Protocol 194 does not require extra signaling setup delays before making use of 195 the conversion service. The Convert Protocol does not require any 196 encapsulation (no tunnels, whatsoever). 198 The Transport Converter adheres to the main principles drawn in 199 [RFC1919]. In particular, a Transport Converter achieves the 200 following: 202 o Listen for client sessions; 204 o Receive from a client the address of the final target server; 206 o Setup a session to the final server; 208 o Relay control messages and data between the client and the server; 210 o Perform access controls according to local policies. 212 The main advantage of network-assisted conversion services is that 213 they enable new TCP extensions to be used on a subset of the path 214 between endpoints, which encourages the deployment of these 215 extensions. Furthermore, the Transport Converter allows the client 216 and the server to directly negotiate TCP extensions for the sake of 217 native support along the full path. 219 The Convert Protocol is a generic mechanism to provide 0-RTT 220 conversion service. As a sample applicability use case, this 221 document specifies how the Convert Protocol applies for Multipath 222 TCP. It is out of scope of this document to provide a comprehensive 223 list of all potential conversion services. Applicability documents 224 may be defined in the future. 226 This document does not assume that all the traffic is eligible to the 227 network-assisted conversion service. Only a subset of the traffic 228 will be forwarded to a Transport Converter according to a set of 229 policies. These policies, and how they are communicated to 230 endpoints, are out of scope. Furthermore, it is possible to bypass 231 the Transport Converter to connect directly to the servers that 232 already support the required TCP extension(s). 234 This document assumes an explicit model in which a client is 235 configured with one or a list of Transport Converters (statically or 236 through protocols such as [I-D.boucadair-tcpm-dhc-converter]). 237 Configuration means are outside the scope of this document. 239 This document is organized as follows. First, Section 3 provides a 240 brief explanation of the operation of Transport Converters. Then, 241 Section 4 describes the Convert Protocol. Section 5 discusses how 242 Transport Converters can be used to support different TCP extensions. 243 Section 6 then discusses the interactions with middleboxes, while 244 Section 7 focuses on the security considerations. 246 Appendix B describes how a TCP stack would need to support the 247 protocol described in this document. Appendix C provides a 248 comparison with SOCKS proxies that are already used to deploy 249 Multipath TCP in some cellular networks (Section 2.2 of [RFC8041]). 251 2. Conventions and Definitions 253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 255 "OPTIONAL" in this document are to be interpreted as described in BCP 256 14 [RFC2119][RFC8174] when, and only when, they appear in all 257 capitals, as shown here. 259 The information shown between brackets in the figures refers to 260 Convert Protocol messages described in Section 4. 262 3. Architecture 264 3.1. Functional Elements 266 The Convert Protocol considers three functional elements: 268 o Clients; 270 o Transport Converters; 272 o Servers. 274 A Transport Converter is a network function that relays all data 275 exchanged over one upstream connection to one downstream connection 276 and vice versa (Figure 1). The Transport Converter, thus, maintains 277 state that associates one upstream connection to a corresponding 278 downstream connection. 280 A connection can be initiated from both sides of the Transport 281 Converter (Internet-facing interface, customer-facing interface). 283 "Client" refers to a software instance embedded on a host that can 284 reach a Transport Converter via its customer-facing interface. The 285 "Client" can initiate connections via a Transport Converter (referred 286 to as outgoing connections). Also, the "Client" can accept incoming 287 connections via a Transport Converter (referred to as incoming 288 connections). Nevertheless, and unless this is explicitly stated, 289 the description assumes outgoing connections as default. 291 | 292 : 293 | 294 +------------+ 295 client <- upstream ->| Transport |<- downstream ->server 296 | Converter | 297 +------------+ 298 | 299 customer-facing interface : Internet-facing interface 300 | 302 Figure 1: A Transport Converter Relays Data between Pairs of TCP 303 Connections 305 Transport Converters can be operated by network operators or third 306 parties. Nevertheless, this document focuses on the single 307 administrative deployment case where the entity offering the 308 connectivity service to a client is also the entity which owns and 309 operates the Transport Converter. 311 A Transport Converter can be embedded in a standalone device or be 312 activated as a service on a router. How such function is enabled is 313 deployment-specific. A sample deployment is depicted in Figure 2. 315 +-+ +-+ +-+ 316 Client - |R| -- |R| -- |R| - - - Server 317 +-+ +-+ +-+ 318 | 319 +-+ 320 |R| 321 +-+ 322 | 323 +---------+ 324 |Transport| 325 |Converter| 326 +---------+ 327 R: Router 329 Figure 2: A Transport Converter Can Be Installed Anywhere in the 330 Network 332 The architecture assumes that new software will be installed on the 333 Client hosts to interact with one or more Transport Converters. 334 Furthermore, the architecture allows for making use of new TCP 335 extensions even if those are not supported by a given server. 337 A Client is configured, through means that are outside the scope of 338 this document, with the names and/or the addresses of one or more 339 Transport Converters and the TCP extensions that they support. The 340 procedure for selecting a Transport Converter among a list of 341 configured Transport Converters is outside the scope of this 342 document. 344 One of the benefits of this design is that different transport 345 protocol extensions can be used on the upstream and the downstream 346 connections. This encourages the deployment of new TCP extensions 347 until they are widely supported by servers, in particular. 349 The architecture does not mandate anything on the Server side. 351 Similar to address sharing mechanisms, the architecture does not 352 interfere with end-to-end TLS connections [RFC8446] between the 353 Client and the Server (Figure 3). In other words, end-to-end TLS is 354 supported in the presence of a Converter. 356 Client Transport Server 357 | Converter | 358 | | | 359 /==========================================\ 360 | End-to-end TLS | 361 \==========================================/ 363 * TLS messages exchanged between the Client 364 and the Server are not shown. 366 Figure 3: End-to-end TLS via a Transport Converter 368 It is out of scope of this document to elaborate on specific 369 considerations related to the use of TLS in the Client-Converter 370 connection leg to exchange Convert messages (in addition to the end- 371 to-end TLS connection). 373 3.2. Theory of Operation 375 At a high level, the objective of the Transport Converter is to allow 376 the use a specific extension, e.g., Multipath TCP, on a subset of the 377 path even if the peer does not support this extension. This is 378 illustrated in Figure 4 where the Client initiates a Multipath TCP 379 connection with the Transport Converter (packets belonging to the 380 Multipath TCP connection are shown with "===") while the Transport 381 Converter uses a regular TCP connection with the Server. 383 Client Transport Server 384 | Converter | 385 | | | 386 |==================>|--------------------->| 387 | | | 388 |<==================|<---------------------| 389 | | | 390 Multipath TCP packets Regular TCP packets 392 Figure 4: An Example of 0-RTT Network-Assisted Outgoing MPTCP 393 Connection 395 The packets belonging to the pair of connections between the Client 396 and Server passing through a Transport Converter may follow a 397 different path than the packets directly exchanged between the Client 398 and the Server. Deployments should minimize the possible additional 399 delay by carefully selecting the location of the Transport Converter 400 used to reach a given destination. 402 When establishing a connection, the Client can, depending on local 403 policies, either contact the Server directly (e.g., by sending a TCP 404 SYN towards the Server) or create the connection via a Transport 405 Converter. In the latter case (that is, the conversion service is 406 used), the Client initiates a connection towards the Transport 407 Converter and indicates the IP address and port number of the Server 408 within the connection establishment packet. Doing so enables the 409 Transport Converter to immediately initiate a connection towards that 410 Server, without experiencing an extra delay. The Transport Converter 411 waits until the receipt of the confirmation that the Server agrees to 412 establish the connection before confirming it to the Client. 414 The Client places the destination address and port number of the 415 Server in the payload of the SYN sent to the Transport Converter to 416 minimize connection establishment delays. In accordance with 417 [RFC1919], the Transport Converter maintains two connections that are 418 combined together: 420 o the upstream connection is the one between the Client and the 421 Transport Converter. 423 o the downstream connection is between the Transport Converter and 424 the Server. 426 Any user data received by the Transport Converter over the upstream 427 (or downstream) connection is relayed over the downstream (or 428 upstream) connection. In particular, if the initial SYN message 429 contains data in its payload (e.g., [RFC7413]), that data MUST be 430 placed right after the Convert TLVs when generating the relayed SYN. 432 The Converter associates a lifetime with state entries used to bind 433 an upstream connection with its downstream connection. 435 Figure 5 illustrates the establishment of an outgoing TCP connection 436 by a Client through a Transport Converter. 438 Transport 439 Client Converter Server 440 | | | 441 |SYN [->Server:port]| SYN | 442 |------------------>|--------------------->| 443 |<------------------|<---------------------| 444 | SYN+ACK [ ] | SYN+ACK | 445 | | | 447 Figure 5: Establishment of an Outgoing TCP Connection Through a 448 Transport Converter (1) 450 The Client sends a SYN destined to the Transport Converter. The 451 payload of this SYN contains the address and port number of the 452 Server. The Transport Converter does not reply immediately to this 453 SYN. It first tries to create a TCP connection towards the target 454 Server. If this upstream connection succeeds, the Transport 455 Converter confirms the establishment of the connection to the Client 456 by returning a SYN+ACK and the first bytes of the bytestream contain 457 information about the TCP options that were negotiated with the 458 Server. This information is sent at the beginning of the bytestream, 459 either directly in the SYN+ACK or in a subsequent packet. For 460 graphical reasons, the figures in this section show that the 461 Transport Converter returns this information in the SYN+ACK packet. 462 An implementation could also place this information in a packet that 463 it sent shortly after the SYN+ACK. 465 The connection can also be established from the Internet towards a 466 Client via a Transport Converter (Figure 6). This is typically the 467 case when an application on the Client listens to a specific port 468 (the Client hosts an application server, typically). When the 469 Converter receives an incoming SYN from a remote host, it checks if 470 it can provide the conversion service for the destination IP address 471 and destination port number of that SYN. If the check is successful, 472 the Converter inserts the source IP address and source port number in 473 the SYN packet, rewrites the source IP address to one of its IP 474 addresses and, eventually, the destination IP address and port number 475 in accordance with any information stored locally. That SYN is then 476 forwarded to the next hop. SYN-ACK and ACK will be then exchanged 477 between the Client, the Converter, and remote host to confirm the 478 establishment of the connection. 480 Transport Remote 481 Client Converter Host (RH) 482 | | | 483 |SYN [<-RH IP@:port]| SYN | 484 |<------------------|<---------------------| 485 |------------------>|--------------------->| 486 | SYN+ACK [ ] | SYN+ACK | 487 | ... | ... | 489 Figure 6: Establishment of an Incoming TCP Connection Through a 490 Transport Converter 492 A Transport Converter MAY operate in address preservation or address 493 sharing modes as discussed in Section 5.4 of 494 [I-D.nam-mptcp-deployment-considerations]. Which behavior to use by 495 a Transport Converter is deployment-specific. If address sharing 496 mode is enabled, the Transport Converter MUST adhere to REQ-2 of 497 [RFC6888] which implies a default "IP address pooling" behavior of 498 "Paired" (as defined in Section 4.1 of [RFC4787]) must be supported. 499 This behavior is meant to avoid breaking applications that depend on 500 the source address remaining constant. 502 Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry 503 data inside its payload but forbids the receiver from delivering it 504 to the application until completion of the three-way-handshake. To 505 enable applications to exchange data in a TCP handshake, this 506 specification follows an approach similar to TCP Fast Open [RFC7413] 507 and thus removes the constraint by allowing data in SYN packets to be 508 delivered to the Transport Converter application. 510 As discussed in [RFC7413], such change to TCP semantic raises two 511 issues. First, duplicate SYNs can cause problems for some 512 applications that rely on TCP. Second, TCP suffers from SYN flooding 513 attacks [RFC4987]. TFO solves these two problems for applications 514 that can tolerate replays by using the TCP Fast Open option that 515 includes a cookie. However, the utilization of this option consumes 516 space in the limited TCP header. Furthermore, there are situations, 517 as noted in Section 7.3 of [RFC7413] where it is possible to accept 518 the payload of SYN packets without creating additional security risks 519 such as a network where addresses cannot be spoofed and the Transport 520 Converter only serves a set of hosts that are identified by these 521 addresses. 523 For these reasons, this specification does not mandate the use of the 524 TCP Fast Open option when the Client sends a connection establishment 525 packet towards a Transport Converter. The Convert protocol includes 526 an optional Cookie TLV that provides similar protection as the TCP 527 Fast Open option without consuming space in the extended TCP header. 529 If the downstream (or upstream) connection fails for some reason 530 (excessive retransmissions, reception of a RST segment, etc.), then 531 the Converter should force the teardown of the upstream (or 532 downstream) connection. 534 The same reasoning applies when the upstream connection ends. In 535 this case, the Converter should also terminate the downstream 536 connection by using FIN segments. If the downstream connection 537 terminates with the exchange of FIN segments, the Converter should 538 initiate a graceful termination of the upstream connection. 540 3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP 541 Connections 543 As an example, let us consider how the Convert protocol can help the 544 deployment of Multipath TCP. We assume that both the Client and the 545 Transport Converter support Multipath TCP, but consider two different 546 cases depending on whether the Server supports Multipath TCP or not. 548 As a reminder, a Multipath TCP connection is created by placing the 549 MP_CAPABLE (MPC) option in the SYN sent by the Client. 551 Figure 7 describes the operation of the Transport Converter if the 552 Server does not support Multipath TCP. 554 Transport 555 Client Converter Server 556 |SYN, | | 557 |MPC [->Server:port]| SYN, MPC | 558 |------------------>|--------------------->| 559 |<------------------|<---------------------| 560 | SYN+ACK,MPC [.] | SYN+ACK | 561 |------------------>|--------------------->| 562 | ACK, MPC | ACK | 563 | | | 565 Figure 7: Establishment of a Multipath TCP Connection Through a 566 Transport Converter towards a Server that Does Not Support Multipath 567 TCP 569 The Client tries to initiate a Multipath TCP connection by sending a 570 SYN with the MP_CAPABLE option (MPC in Figure 7). The SYN includes 571 the address and port number of the target Server, that are extracted 572 and used by the Transport Converter to initiate a Multipath TCP 573 connection towards this Server. Since the Server does not support 574 Multipath TCP, it replies with a SYN+ACK that does not contain the 575 MP_CAPABLE option. The Transport Converter notes that the connection 576 with the Server does not support Multipath TCP and returns the 577 extended TCP header received from the Server to the Client. 579 Note that, if the TCP connection fails for some reason, the Converter 580 tears down the Multipath TCP connection by transmitting a 581 MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with 582 the transmission of DATA_FINs, the Converter terminates the TCP 583 connection by using FIN segments. 585 Figure 8 considers a Server that supports Multipath TCP. In this 586 case, it replies to the SYN sent by the Transport Converter with the 587 MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport 588 Converter confirms the establishment of the connection to the Client 589 and indicates to the Client that the Server supports Multipath TCP. 590 With this information, the Client has discovered that the Server 591 supports Multipath TCP natively. This will enable the Client to 592 bypass the Transport Converter for the subsequent Multipath TCP 593 connections that it will initiate towards this Server. 595 Transport 596 Client Converter Server 597 |SYN, | | 598 |MPC [->Server:port]| SYN, MPC | 599 |------------------>|--------------------->| 600 |<------------------|<---------------------| 601 |SYN+ACK, | SYN+ACK, MPC | 602 |MPC [MPC supported]| | 603 |------------------>|--------------------->| 604 | ACK, MPC | ACK, MPC | 605 | | | 607 Figure 8: Establishment of a Multipath TCP Connection Through a 608 Converter Towards an MPTCP-capable Server 610 3.4. Sample Example of Incoming Converter-Assisted Multipath TCP 611 Connection 613 An example of an incoming Converter-assisted Multipath TCP connection 614 is depicted in Figure 9. In order to support incoming connections 615 from remote hosts, the Client may use PCP [RFC6887] to instruct the 616 Transport Converter to create dynamic mappings. Those mappings will 617 be used by the Transport Converter to intercept an incoming TCP 618 connection destined to the Client and convert it into a Multipath TCP 619 connection. 621 Typically, the Client sends a PCP request to the Converter asking to 622 create an explicit TCP mapping for (internal IP address, internal 623 port number). The Converter accepts the request by creating a TCP 624 mapping (internal IP address, internal port number, external IP 625 address, external port number). The external IP address and external 626 port number will be then advertised using an out-of-band mechanism so 627 that remote hosts can initiate TCP connections to the Client via the 628 Converter. Note that the external and internal information may be 629 the same. 631 Then, when the Converter receives an incoming SYN, it checks its 632 mapping table to verify if there is an active mapping matching the 633 destination IP address and destination port of that SYN. If an entry 634 is found, the Converter inserts an MP_CAPABLE option and Connect TLV 635 in the SYN packet, rewrites the source IP address to one of its IP 636 addresses and, eventually, the destination IP address and port number 637 in accordance with the information stored in the mapping. SYN-ACK 638 and ACK will be then exchanged between the Client and the Converter 639 to confirm the establishment of the initial subflow. The Client can 640 add new subflows following normal Multipath TCP procedures. 642 Transport Remote 643 Client Converter Host 644 | | | 645 |<--------------------|<-------------------| 646 |SYN, | SYN | 647 |MPC[Remote Host:port]| | 648 |-------------------->|------------------->| 649 | SYN+ACK, MPC | SYN+ACK | 650 |<--------------------|<-------------------| 651 | ACK, MPC | ACK | 652 | | | 654 Figure 9: Establishment of an Incoming Multipath TCP Connection 655 through a Transport Converter 657 It is out of scope of this document to define specific Convert TLVs 658 to manage incoming connections. These TLVs can be defined in a 659 separate document. 661 4. The Convert Protocol (Convert) 663 This section describes the messages that are exchanged between a 664 Client and a Transport Converter. 666 By default, the Transport Converter listens on TCP port number TBA 667 for Convert protocol (Convert, for short) messages from Clients. 669 Clients send packets that are eligible to the conversion service to 670 the provisioned Transport Converter using TBA as destination port 671 number. Additional information is supplied by Clients to the 672 Transport Converter by means of Convert messages as detailed in the 673 following sub-sections. 675 Convert messages may appear only in a SYN, SYN+ACK, or ACK. 677 Convert messages MUST be included as the first bytes of the 678 bytestream. A Convert message starts with a 32 bits long fixed 679 header (Section 4.1) followed by one or more Convert TLVs (Type, 680 Length, Value) (Section 4.2). 682 4.1. The Convert Fixed Header 684 The Convert Protocol uses a 32 bits long fixed header that is sent by 685 both the Client and the Transport Converter over each established 686 connection. This header indicates both the version of the protocol 687 used and the length of the Convert message. 689 The Client and the Transport Converter MUST send the fixed-sized 690 header, shown in Figure 10, as the first four bytes of the 691 bytestream. 693 1 2 3 694 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 695 +---------------+---------------+-------------------------------+ 696 | Version | Total Length | Unassigned | 697 +---------------+---------------+-------------------------------+ 699 Figure 10: The Fixed-Sized Header of the Convert Protocol 701 The Version is encoded as an 8 bits unsigned integer value. This 702 document specifies version 1. Version 0 is reserved by this document 703 and MUST NOT be used. 705 The Total Length is the number of 32 bits word, including the header, 706 of the bytestream that are consumed by the Convert messages. Since 707 Total Length is also an 8 bits unsigned integer, those messages 708 cannot consume more than 1020 bytes of data. This limits the number 709 of bytes that a Transport Converter needs to process. A Total Length 710 of zero is invalid and the connection MUST be reset upon reception of 711 a header with such total length. 713 The Unassigned field MUST be set to zero in this version of the 714 protocol. These bits are available for future use [RFC8126]. 716 Data added by the Convert protocol to the TCP bytestream is 717 unambiguously distinguished from payload data by the Total Length 718 field in the Convert messages. 720 4.2. Convert TLVs 722 4.2.1. Generic Convert TLV Format 724 The Convert protocol uses variable length messages that are encoded 725 using the generic TLV format depicted in Figure 11. 727 The length of all TLVs used by the Convert protocol is always a 728 multiple of four bytes. All TLVs are aligned on 32 bits boundaries. 729 All TLV fields are encoded using the network byte order. 731 1 2 3 732 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 733 +---------------+---------------+-------------------------------+ 734 | Type | Length | (optional) Value ... | 735 +---------------+---------------+-------------------------------+ 736 | ... Value | 737 +---------------------------------------------------------------+ 739 Figure 11: Convert Generic TLV Format 741 The Length field is expressed in units of 32 bits words. If 742 necessary, Value MUST be padded with zeroes so that the length of the 743 TLV is a multiple of 32 bits. 745 A given TLV MUST only appear once on a connection. If two or more 746 instances of the same TLV are exchanged over a Convert connection, 747 the associated TCP connections MUST be closed. 749 4.2.2. Summary of Supported Convert TLVs 751 This document specifies the following Convert TLVs: 753 +------+-----+----------+------------------------------------------+ 754 | Type | Hex | Length | Description | 755 +------+-----+----------+------------------------------------------+ 756 | 1 | 0x1 | 1 | Info TLV | 757 | 10 | 0xA | Variable | Connect TLV | 758 | 20 | 0x14| Variable | Extended TCP Header TLV | 759 | 21 | 0x15| Variable | Supported TCP Extensions TLV | 760 | 22 | 0x16| Variable | Cookie TLV | 761 | 30 | 0x1E| Variable | Error TLV | 762 +------+-----+----------+------------------------------------------+ 764 Figure 12: The TLVs used by the Convert Protocol 766 Type 0x0 is a reserved valued. Implementations MUST discard messages 767 with such TLV. 769 The Client typically sends in the first connection it established 770 with a Transport Converter the Info TLV (Section 4.2.3) to learn its 771 capabilities. Assuming the Client is authorized to invoke the 772 Transport Converter, the latter replies with the Supported TCP 773 Extensions TLV (Section 4.2.4). 775 The Client can request the establishment of connections to servers by 776 using the Connect TLV (Section 4.2.5). If the connection can be 777 established with the final server, the Transport Converter replies 778 with the Extended TCP Header TLV (Section 4.2.6). If not, the 779 Transport Converter returns an Error TLV (Section 4.2.8) and then 780 closes the connection. 782 When an error is encountered an Error TLV with the appropriate error 783 code MUST be returned by the Transport Converter. 785 4.2.3. The Info TLV 787 The Info TLV (Figure 13) is an optional TLV which can be sent by a 788 Client to request the TCP extensions that are supported by a 789 Transport Converter. It is typically sent on the first connection 790 that a Client establishes with a Transport Converter to learn its 791 capabilities. Assuming a Client is entitled to invoke the Transport 792 Converter, the latter replies with the Supported TCP Extensions TLV 793 described in Section 4.2.4. 795 1 2 3 796 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 797 +---------------+---------------+-------------------------------+ 798 | Type=0x1 | Length | Zero | 799 +---------------+---------------+-------------------------------+ 801 Figure 13: The Info TLV 803 4.2.4. Supported TCP Extensions TLV 805 The Supported TCP Extensions TLV (Figure 14) is used by a Transport 806 Converter to announce the TCP options for which it provides a 807 conversion service. A Transport Converter SHOULD include in this 808 list the TCP options that it accepts from Clients; these options are 809 included by the Transport Converter in the SYN packets that it sends 810 to initiate connections. 812 Each supported TCP option is encoded with its TCP option Kind listed 813 in the "TCP Parameters" registry maintained by IANA. 815 1 2 3 816 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 817 +---------------+---------------+-------------------------------+ 818 | Type=0x15 | Length | Unassigned | 819 +---------------+---------------+-------------------------------+ 820 | Kind #1 | Kind #2 | ... | 821 +---------------+---------------+-------------------------------+ 822 / ... / 823 / / 824 +---------------------------------------------------------------+ 826 Figure 14: The Supported TCP Extensions TLV 828 TCP option Kinds 0, 1, and 2 defined in [RFC0793] are supported by 829 all TCP implementations and thus MUST NOT appear in this list. 831 The list of Supported TCP Extensions is padded with 0 to end on a 32 832 bits boundary. 834 For example, if the Transport Converter supports Multipath TCP, 835 Kind=30 will be present in the Supported TCP Extensions TLV that it 836 returns in response to Info TLV. 838 4.2.5. Connect TLV 840 The Connect TLV (Figure 15) is used to request the establishment of a 841 connection via a Transport Converter. This connection can be from or 842 to a Client. 844 The 'Remote Peer Port' and 'Remote Peer IP Address' fields contain 845 the destination port number and IP address of the Server, for 846 outgoing connections. For incoming connections destined to a Client 847 serviced via a Transport Converter, these fields convey the source 848 port number and IP address. 850 The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 851 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format 852 defined in [RFC4291]. Further, Remote Peer IP address field MUST NOT 853 include multicast, broadcast, and host loopback addresses [RFC6890]. 854 Connect TLVs witch such messages MUST be discarded by the Transport 855 Converter. 857 We distinguish two types of Connect TLV based on their length: (1) 858 the base Connect TLV has a length of 20 bytes and contains a remote 859 address and a remote port, (2) the extended Connect TLV spans more 860 than 20 bytes and also includes the optional 'TCP Options' field. 861 This field is used to specify how specific TCP options should be 862 advertised by the Transport Converter to the server. 864 1 2 3 865 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 866 +---------------+---------------+-------------------------------+ 867 | Type=0xA | Length | Remote Peer Port | 868 +---------------+---------------+-------------------------------+ 869 | | 870 | Remote Peer IP Address (128 bits) | 871 | | 872 | | 873 +---------------------------------------------------------------+ 874 | TCP Options (Variable) | 875 | ... | 876 +---------------------------------------------------------------+ 878 Figure 15: The Connect TLV 880 The 'TCP Options' field is a variable length field that carries a 881 list of TCP option fields (Figure 16). Each TCP option field is 882 encoded as a block of 2+n bytes where the first byte is the TCP 883 option Kind and the second byte is the length of the TCP option as 884 specified in [RFC0793]. The minimum value for the TCP option Length 885 is 2. The TCP options that do not include a length subfield, i.e., 886 option types 0 (EOL) and 1 (NOP) defined in [RFC0793] MUST NOT be 887 placed inside the TCP options field of the Connect TLV. The optional 888 Value field contains the variable-length part of the TCP option. A 889 length of two indicates the absence of the Value field. The TCP 890 options field always ends on a 32 bits boundary after being padded 891 with zeros. 893 1 2 3 894 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 895 +---------------+---------------+---------------+---------------+ 896 | TCPOpt kind | TCPOpt Length | Value (opt) | .... | 897 +---------------+---------------+---------------+---------------+ 898 | .... | 899 +---------------------------------------------------------------+ 900 | ... | 901 +---------------------------------------------------------------+ 903 Figure 16: The TCP Options Field 905 Upon reception of a Connect TLV, and absent any policy (e.g., rate- 906 limit) or resource exhaustion conditions, a Transport Converter 907 attempts to establish a connection to the address and port that it 908 contains. The Transport Converter MUST use by default the TCP 909 options that correspond to its local policy to establish this 910 connection. These are the options that it advertises in the 911 Supported TCP Extensions TLV. 913 Upon reception of an extended Connect TLV, and absent any rate limit 914 policy or resource exhaustion conditions, a Transport Converter MUST 915 attempt to establish a connection to the address and port that it 916 contains. It MUST include the options of the 'TCP Options' subfield 917 in the SYN sent to the Server in addition to the TCP options that it 918 would have used according to its local policies. For the TCP options 919 that are listed without an optional value, the Transport Converter 920 MUST generate its own value. For the TCP options that are included 921 in the 'TCP Options' field with an optional value, it MUST copy the 922 entire option for use in the connection with the destination peer. 923 This feature is required to support TCP Fast Open. 925 The Transport Converter may discard a Connect TLV request for various 926 reasons (e.g., authorization failed, out of resources, invalid 927 address type). An error message indicating the encountered error is 928 returned to the requesting Client (Section 4.2.8). In order to 929 prevent denial-of-service attacks, error messages sent to a Client 930 SHOULD be rate-limited. 932 4.2.6. Extended TCP Header TLV 934 The Extended TCP Header TLV (Figure 17) is used by the Transport 935 Converter to send to the Client the extended TCP header that was 936 returned by the Server in the SYN+ACK packet. This TLV is only sent 937 if the Client sent a Connect TLV to request the establishment of a 938 connection. 940 1 2 3 941 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 942 +---------------+---------------+-------------------------------+ 943 | Type=0x14 | Length | Unassigned | 944 +---------------+---------------+-------------------------------+ 945 | Returned Extended TCP header | 946 | ... | 947 +---------------------------------------------------------------+ 949 Figure 17: The Extended TCP Header TLV 951 The Returned Extended TCP header field is a copy of the extended 952 header that was received in the SYN+ACK by the Transport Converter. 954 The Unassigned field MUST be set to zero by the transmitter and 955 ignored by the receiver. These bits are available for future use 956 [RFC8126]. 958 4.2.7. The Cookie TLV 960 The Cookie TLV (Figure 18 is an optional TLV which use is similar to 961 the TCP Fast Open Cookie [RFC7413]. A Transport Converter may want 962 to verify that a Client can receive the packets that it sends to 963 prevent attacks from spoofed addresses. This verification can be 964 done by using a Cookie that is bound to, for example, the IP 965 address(es) of the Client. This Cookie can be configured on the 966 Client by means that are outside of this document or provided by the 967 Transport Converter as follows. 969 A Transport Converter that has been configured to use the optional 970 Cookie TLV MUST verify the presence of this TLV in the payload of the 971 received SYN. If this TLV is present, the Transport Converter MUST 972 validate the Cookie by means similar to those in Section 4.1.2 of 973 [RFC7413] (i.e., IsCookieValid). If the Cookie is valid, the 974 connection establishment procedure can continue. Otherwise, the 975 Transport Converter MUST return an Error TLV set to "Not Authorized" 976 and close the connection. 978 If the received SYN did not contain a Cookie TLV, and cookie 979 validation is required, the Transport Converter should compute a 980 Cookie bound to this Client address and return a Convert message 981 containing the fixed header, an Error TLV set to "Missing Cookie" and 982 the computed Cookie and close the connection. The Client will react 983 to this error by storing the received Cookie in its cache and attempt 984 to reestablish a new connection to the Transport Converter that 985 includes the Cookie TLV. 987 The format of the Cookie TLV is shown in Figure 18. 989 1 2 3 990 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 991 +---------------+---------------+-------------------------------+ 992 | Type=0x16 | Length | Zero | 993 +---------------+---------------+-------------------------------+ 994 | Opaque Cookie | 995 | ... | 996 +---------------------------------------------------------------+ 998 Figure 18: The Cookie TLV 1000 4.2.8. Error TLV 1002 The Error TLV (Figure 19) is meant to provide information about some 1003 errors that occurred during the processing of a Convert message. 1004 This TLV has a variable length. It appears after the Convert fixed- 1005 header in the bytestream returned by the Transport Converter. Upon 1006 reception of an Error TLV, a Client MUST close the associated 1007 connection. 1009 1 2 3 1010 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 1011 +---------------+---------------+----------------+--------------+ 1012 | Type=0x1E | Length | Error Code | Value | 1013 +---------------+---------------+----------------+--------------+ 1015 Figure 19: The Error TLV 1017 Different types of errors can occur while processing Convert 1018 messages. Each error is identified by an Error Code represented as 1019 an unsigned integer. Four classes of error codes are defined: 1021 o Message validation and processing errors (0-31 range): returned 1022 upon reception of an invalid message (including valid messages but 1023 with invalid or unknown TLVs). 1025 o Client-side errors (32-63 range): the Client sent a request that 1026 could not be accepted by the Transport Converter (e.g., 1027 unsupported operation). 1029 o Converter-side errors (64-95 range): problems encountered on the 1030 Transport Converter (e.g., lack of resources) which prevent it 1031 from fulfilling the Client's request. 1033 o Errors caused by the destination server (96-127 range): the final 1034 destination could not be reached or it replied with a reset. 1036 The following error codes are defined in this document: 1038 o Unsupported Version (0): The version number indicated in the fixed 1039 header of a message received from a peer is not supported. 1041 This error code MUST be generated by a Transport Converter (or 1042 Client) when it receives a request having a version number that it 1043 does not support. 1045 The value field MUST be set to the version supported by the 1046 Transport Converter (or Client). When multiple versions are 1047 supported by the Transport Converter (or Client), it includes the 1048 list of supported version in the value field; each version is 1049 encoded in 8 bits. The list of supported versions should be 1050 padded with zeros to end on a 32 bits boundary. 1052 Upon receipt of this error code, the Client (or Transport 1053 Converter) checks whether it supports one of the versions returned 1054 by the Transport Converter (or Client). The highest common 1055 supported version MUST be used by the Client (or Transport 1056 Converter) in subsequent exchanges with the Transport Converter 1057 (or Client). 1059 o Malformed Message (1): This error code is sent to indicate that a 1060 message received from a peer is can not be successfully parsed and 1061 validated. 1063 Typically, this error code is sent by the Transport Converter if 1064 it receives a Connect TLV enclosing a multicast, broadcast, or 1065 loopback IP address. 1067 To ease troubleshooting, the value field MUST echo the received 1068 message shifted by one byte to keep to original alignment of the 1069 message. 1071 o Unsupported Message (2): This error code is sent to indicate that 1072 a message type received from a peer is not supported. 1074 To ease troubleshooting, the value field MUST echo the received 1075 message shifted by one byte to keep to original alignment of the 1076 message. 1078 o Missing Cookie (3): If a Transport Converter requires the 1079 utilization of Cookies to prevent spoofing attacks and a Cookie 1080 TLV was not included in the Convert message, the Transport 1081 Converter MUST return this error to the requesting client. The 1082 first byte of the value field MUST be set to zero and the 1083 remaining bytes of the Error TLV contain the Cookie computed by 1084 the Transport Converter for this Client. 1086 A Client which receives this error code MUST cache the received 1087 Cookie and include it in subsequent Convert messages sent to that 1088 Transport Converter. 1090 o Not Authorized (32): This error code indicates that the Transport 1091 Converter refused to create a connection because of a lack of 1092 authorization (e.g., administratively prohibited, authorization 1093 failure, invalid Cookie TLV, etc.). The Value field MUST be set 1094 to zero. 1096 This error code MUST be sent by the Transport Converter when a 1097 request cannot be successfully processed because the authorization 1098 failed. 1100 o Unsupported TCP Option (33): A TCP option that the Client 1101 requested to advertise to the final Server cannot be safely used. 1103 The Value field is set to the type of the unsupported TCP option. 1104 If several unsupported TCP options were specified in the Connect 1105 TLV, then the list of unsupported TCP options is returned. The 1106 list of unsupported TCP options MUST be padded with zeros to end 1107 on a 32 bits boundary. 1109 o Resource Exceeded (64): This error indicates that the Transport 1110 Converter does not have enough resources to perform the request. 1112 This error MUST be sent by the Transport Converter when it does 1113 not have sufficient resources to handle a new connection. The 1114 Transport Converter may indicate in the Value field the suggested 1115 delay (in seconds) that the Client SHOULD wait before soliciting 1116 the Transport Converter for a new proxied connection. A Value of 1117 zero corresponds to a default delay of at least 30 seconds. 1119 o Network Failure (65): This error indicates that the Transport 1120 Converter is experiencing a network failure to relay the request. 1122 The Transport Converter MUST send this error code when it 1123 experiences forwarding issues to relay a connection. The 1124 Transport Converter may indicate in the Value field the suggested 1125 delay (in seconds) that the Client SHOULD wait before soliciting 1126 the Transport Converter for a new proxied connection. A Value of 1127 zero corresponds to a default delay of at least 30 seconds. 1129 o Connection Reset (96): This error indicates that the final 1130 destination responded with an RST packet. The Value field MUST be 1131 set to zero. 1133 o Destination Unreachable (97): This error indicates that an ICMP 1134 destination unreachable, port unreachable, or network unreachable 1135 was received by the Transport Converter. The Value field MUST 1136 echo the Code field of the received ICMP message. 1138 Figure 20 summarizes the different error codes. 1140 +-------+------+-----------------------------------------------+ 1141 | Error | Hex | Description | 1142 +-------+------+-----------------------------------------------+ 1143 | 0 | 0x00 | Unsupported Version | 1144 | 1 | 0x01 | Malformed Message | 1145 | 2 | 0x02 | Unsupported Message | 1146 | 3 | 0x03 | Missing Cookie | 1147 | 32 | 0x20 | Not Authorized | 1148 | 33 | 0x21 | Unsupported TCP Option | 1149 | 64 | 0x40 | Resource Exceeded | 1150 | 65 | 0x41 | Network Failure | 1151 | 96 | 0x60 | Connection Reset | 1152 | 97 | 0x61 | Destination Unreachable | 1153 +-------+------+-----------------------------------------------+ 1155 Figure 20: Convert Error Values 1157 5. Compatibility of Specific TCP Options with the Conversion Service 1159 In this section, we discuss how several standard track TCP options 1160 can be supported through the Convert protocol. The non-standard 1161 track options and the experimental options will be discussed in other 1162 documents. 1164 5.1. Base TCP Options 1166 Three TCP options were initially defined in [RFC0793]: End-of-Option 1167 List (Kind=0), No-Operation (Kind=1) and Maximum Segment Size 1168 (Kind=2). The first two options are mainly used to pad the TCP 1169 header. There is no reason for a client to request a Transport 1170 Converter to specifically send these options towards the final 1171 destination. 1173 The Maximum Segment Size option (Kind=2) is used by a host to 1174 indicate the largest segment that it can receive over each 1175 connection. This value is function of the stack that terminates the 1176 TCP connection. There is no reason for a Client to request a 1177 Transport Converter to advertise a specific MSS value to a remote 1178 server. 1180 A Transport Converter MUST ignore options with Kind=0, 1 or 2 if they 1181 appear in a Connect TLV. It MUST NOT announce them in a Supported 1182 TCP Extensions TLV. 1184 5.2. Window Scale (WS) 1186 The Window Scale (WS) option (Kind=3) is defined in [RFC7323]. As 1187 for the MSS option, the window scale factor that is used for a 1188 connection strongly depends on the TCP stack that handles the 1189 connection. When a Transport Converter opens a TCP connection 1190 towards a remote server on behalf of a Client, it SHOULD use a WS 1191 option with a scaling factor that corresponds to the configuration of 1192 its stack. A local configuration MAY allow for WS option in the 1193 proxied message to be function of the scaling factor of the incoming 1194 connection. 1196 There is no benefit from a deployment viewpoint in enabling a Client 1197 of a Transport Converter to specifically request the utilization of 1198 the WS option (Kind=3) with a specific scaling factor towards a 1199 remote Server. For this reason, a Transport Converter MUST ignore 1200 option Kind=3 if it appears in a Connect TLV. It MUST NOT announce 1201 it in a Supported TCP Extensions TLV. 1203 5.3. Selective Acknowledgements 1205 Two distinct TCP options were defined to support selective 1206 acknowledgements in [RFC2018]. This first one, SACK Permitted 1207 (Kind=4), is used to negotiate the utilization of selective 1208 acknowledgements during the three-way handshake. The second one, 1209 SACK (Kind=5), carries the selective acknowledgements inside regular 1210 segments. 1212 The SACK Permitted option (Kind=4) MAY be advertised by a Transport 1213 Converter in the Supported TCP Extensions TLV. Clients connected to 1214 this Transport Converter MAY include the SACK Permitted option in the 1215 Connect TLV. 1217 The SACK option (Kind=5) cannot be used during the three-way 1218 handshake. For this reason, a Transport Converter MUST ignore option 1219 Kind=5 if it appears in a Connect TLV. It MUST NOT announce it in a 1220 TCP Supported Extensions TLV. 1222 5.4. Timestamp 1224 The Timestamp option was initially defined in [RFC1323] and later 1225 refined in [RFC7323]. It can be used during the three-way handshake 1226 to negotiate the utilization of timestamps during the TCP connection. 1227 It is notably used to improve round-trip-time estimations and to 1228 provide protection against wrapped sequence numbers (PAWS). As for 1229 the WS option, the timestamps are a property of a connection and 1230 there is limited benefit in enabling a client to request a Transport 1231 Converter to use the timestamp option when establishing a connection 1232 to a remote server. Furthermore, the timestamps that are used by TCP 1233 stacks are specific to each stack and there is no benefit in enabling 1234 a client to specify the timestamp value that a Transport Converter 1235 could use to establish a connection to a remote server. 1237 A Transport Converter MAY advertise the Timestamp option (Kind=8) in 1238 the TCP Supported Extensions TLV. The clients connected to this 1239 Transport Converter MAY include the Timestamp option in the Connect 1240 TLV but without any timestamp. 1242 5.5. Multipath TCP 1244 The Multipath TCP options are defined in [RFC6824]. [RFC6824] 1245 defines one variable length TCP option (Kind=30) that includes a 1246 subtype field to support several Multipath TCP options. There are 1247 several operational use cases where clients would like to use 1248 Multipath TCP through a Transport Converter [IETFJ16]. However, none 1249 of these use cases require the Client to specify the content of the 1250 Multipath TCP option that the Transport Converter should send to a 1251 remote server. 1253 A Transport Converter which supports Multipath TCP conversion service 1254 MUST advertise the Multipath TCP option (Kind=30) in the Supported 1255 TCP Extensions TLV. Clients serviced by this Transport Converter may 1256 include the Multipath TCP option in the Connect TLV but without any 1257 content. 1259 5.6. TCP Fast Open 1261 The TCP Fast Open cookie option (Kind=34) is defined in [RFC7413]. 1262 There are two different usages of this option that need to be 1263 supported by Transport Converters. The first utilization of the TCP 1264 Fast Open cookie option is to request a cookie from the server. In 1265 this case, the option is sent with an empty cookie by the client and 1266 the server returns the cookie. The second utilization of the TCP 1267 Fast Open cookie option is to send a cookie to the server. In this 1268 case, the option contains a cookie. 1270 A Transport Converter MAY advertise the TCP Fast Open cookie option 1271 (Kind=34) in the Supported TCP Extensions TLV. If a Transport 1272 Converter has advertised the support for TCP Fast Open in its 1273 Supported TCP Extensions TLV, it needs to be able to process two 1274 types of Connect TLV. If such a Transport Converter receives a 1275 Connect TLV with the TCP Fast Open cookie option that does not 1276 contain a cookie, it MUST add an empty TCP Fast Open cookie option in 1277 the SYN sent to the remote server. If such a Transport Converter 1278 receives a Connect TLV with the TCP Fast Open cookie option that 1279 contains a cookie, it MUST copy the TCP Fast Open cookie option in 1280 the SYN sent to the remote server. 1282 5.7. TCP User Timeout 1284 The TCP User Timeout option is defined in [RFC5482]. The associated 1285 TCP option (Kind=28) does not appear to be widely deployed. 1287 5.8. TCP-AO 1289 TCP-AO [RFC5925] provides a technique to authenticate all the packets 1290 exchanged over a TCP connection. Given the nature of this extension, 1291 it is unlikely that the applications that require their packets to be 1292 authenticated end-to-end would want their connections to pass through 1293 a converter. For this reason, we do not recommend the support of the 1294 TCP-AO option by Transport Converters. The only use cases where it 1295 could make sense to combine TCP-AO and the solution in this document 1296 are those where the TCP-AO-NAT extension [RFC6978] is in use. 1298 A Transport Converter MUST NOT advertise the TCP-AO option (Kind=29) 1299 in the Supported TCP Extensions TLV. If a Transport Converter 1300 receives a Connect TLV that contains the TCP-AO option, it MUST 1301 reject the establishment of the connection with error code set to 1302 "Unsupported TCP Option", except if the TCP-AO-NAT option is used. 1304 5.9. TCP Experimental Options 1306 The TCP Experimental options are defined in [RFC4727]. Given the 1307 variety of semantics for these options and their experimental nature, 1308 it is impossible to discuss them in details in this document. 1310 6. Interactions with Middleboxes 1312 The Convert Protocol is designed to be used in networks that do not 1313 contain middleboxes that interfere with TCP. Under such conditions, 1314 it is assumed that the network provider ensures that all involved on- 1315 path nodes are not breaking TCP signals (e.g., strip TCP options, 1316 discard some SYNs, etc.). 1318 Nevertheless, and in order to allow for a robust service, this 1319 section describes how a Client can detect middlebox interference and 1320 stop using the Transport Converter affected by this interference. 1322 Internet measurements [IMC11] have shown that middleboxes can affect 1323 the deployment of TCP extensions. In this section, we only discuss 1324 the middleboxes that modify SYN and SYN+ACK packets since the Convert 1325 Protocol places its messages in such packets. 1327 Consider a middlebox that removes the SYN payload. The Client can 1328 detect this problem by looking at the acknowledgement number field of 1329 the SYN+ACK returned by the Transport Converter. The Client MUST 1330 stop to use this Transport Converter given the middlebox 1331 interference. 1333 Consider now a middlebox that drops SYN/ACKs with a payload. The 1334 Client won't be able to establish a connection via the Transport 1335 Converter. 1337 The case of a middlebox that removes the payload of SYN+ACKs (but the 1338 payload of SYN) can be detected by a Client. This is hinted by the 1339 absence of an Error or Extended TCP Header TLV in a response. If an 1340 Error was returned by the Transport Converter, a message to close the 1341 connection would normally follow from the Converter. If no such 1342 message is received, the Client may continue to use this Converter. 1344 As explained in [RFC7413], some CGNs (Carrier Grade NATs) can affect 1345 the operation of TFO if they assign different IP addresses to the 1346 same end host. Such CGNs could affect the operation of the cookie 1347 validation used by the Convert Protocol. As a reminder CGNs, enabled 1348 on the path between a Client and a Transport Converter, must adhere 1349 to the address preservation defined in [RFC6888]. See also the 1350 discussion in Section 7.1 of [RFC7413]. 1352 7. Security Considerations 1354 7.1. Privacy & Ingress Filtering 1356 The Transport Converter may have access to privacy-related 1357 information (e.g., subscriber credentials). The Transport Converter 1358 is designed to not leak such sensitive information outside a local 1359 domain. 1361 Given its function and its location in the network, a Transport 1362 Converter has access to the payload of all the packets that it 1363 processes. As such, it MUST be protected as a core IP router (e.g., 1364 [RFC1812]). 1366 Furthermore, ingress filtering policies MUST be enforced at the 1367 network boundaries [RFC2827]. 1369 This document assumes that all network attachments are managed by the 1370 same administrative entity. Therefore, enforcing anti-spoofing 1371 filters at these network ensures that hosts are not sending traffic 1372 with spoofed source IP addresses. 1374 7.2. Authorization 1376 The Convert Protocol is intended to be used in managed networks where 1377 end hosts can be identified by their IP address. 1379 Stronger mutual authentication schemes MUST be defined to use the 1380 Convert Protocol in more open network environments. One possibility 1381 is to use TLS to perform mutual authentication between the client and 1382 the Converter. That is, use TLS when a Client retrieves a Cookie 1383 from the Converter and rely on certificate-based client 1384 authentication, pre-shared key based [RFC4279] or raw public key 1385 based client authentication [RFC7250] to secure this connection. 1387 If the authentication succeeds, the Converter returns a cookie to the 1388 Client. Subsequent Connect messages will be authorized as a function 1389 of the content of the Cookie TLV. 1391 In deployments where network-assisted connections are not allowed 1392 between hosts of a domain (i.e., hairpinning), the Converter may be 1393 instructed to discard such connections. Hairpinned connections are 1394 thus rejected by the Transport Converter by returning an Error TLV 1395 set to "Not Authorized". Absent explicit configuration otherwise, 1396 hairpinning is enabled by the Converter (see Figure 21. 1398 <===Network Provider===> 1400 +----+ from X1:x1 to X2':x2' +-----+ X1':x1' 1401 | C1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- 1402 +----+ | v | 1403 | v | 1404 | v | 1405 | v | 1406 +----+ from X1':x1' to X2:x2 | v | X2':x2' 1407 | C2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- 1408 +----+ +-----+ 1409 Converter 1411 Note: X2':x2' may be equal to 1412 X2:x2 1414 Figure 21: Hairpinning Example 1416 See below for authorization considerations that are specific for 1417 Multipath TCP. 1419 7.3. Denial of Service 1421 Another possible risk is the amplification attacks since a Transport 1422 Converter sends a SYN towards a remote Server upon reception of a SYN 1423 from a Client. This could lead to amplification attacks if the SYN 1424 sent by the Transport Converter were larger than the SYN received 1425 from the Client or if the Transport Converter retransmits the SYN. 1426 To mitigate such attacks, the Transport Converter SHOULD rate limit 1427 the number of pending requests for a given Client. It SHOULD also 1428 avoid sending to remote Servers SYNs that are significantly longer 1429 than the SYN received from the Client. Finally, the Transport 1430 Converter SHOULD only retransmit a SYN to a Server after having 1431 received a retransmitted SYN from the corresponding Client. Means to 1432 protect against SYN flooding attacks MUST also be enabled [RFC4987]. 1434 7.4. Traffic Theft 1436 Traffic theft is a risk if an illegitimate Converter is inserted in 1437 the path. Indeed, inserting an illegitimate Converter in the 1438 forwarding path allows traffic interception and can therefore provide 1439 access to sensitive data issued by or destined to a host. Converter 1440 discovery and configuration are out of scope of this document. 1442 7.5. Multipath TCP-specific Considerations 1444 Multipath TCP-related security threats are discussed in [RFC6181] and 1445 [RFC6824]. 1447 The operator that manages the various network attachments (including 1448 the Transport Converters) can enforce authentication and 1449 authorization policies using appropriate mechanisms. For example, a 1450 non-exhaustive list of methods to achieve authorization is provided 1451 hereafter: 1453 o The network provider may enforce a policy based on the 1454 International Mobile Subscriber Identity (IMSI) to verify that a 1455 user is allowed to benefit from the Multipath TCP converter 1456 service. If that authorization fails, the Packet Data Protocol 1457 (PDP) context/bearer will not be mounted. This method does not 1458 require any interaction with the Transport Converter for 1459 authorization matters. 1461 o The network provider may enforce a policy based upon Access 1462 Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) 1463 to control the hosts that are authorized to communicate with a 1464 Transport Converter. These ACLs may be installed as a result of 1465 RADIUS exchanges, e.g., [I-D.boucadair-radext-tcpm-converter]. 1467 This method does not require any interaction with the Transport 1468 Converter for authorization matters. 1470 o A device that embeds a Transport Converter may also host a RADIUS 1471 client that will solicit an AAA server to check whether 1472 connections received from a given source IP address are authorized 1473 or not [I-D.boucadair-radext-tcpm-converter]. 1475 A first safeguard against the misuse of Transport Converter resources 1476 by illegitimate users (e.g., users with access networks that are not 1477 managed by the same provider that operates the Transport Converter) 1478 is the Transport Converter to reject Multipath TCP connections 1479 received on its Internet-facing interfaces. Only Multipath TCP 1480 connections received on the customer-facing interfaces of a Transport 1481 Converter will be accepted. 1483 8. IANA Considerations 1485 8.1. Convert Service Port Number 1487 IANA is requested to assign a TCP port number (TBA) for the Convert 1488 Protocol from the "Service Name and Transport Protocol Port Number 1489 Registry" available at https://www.iana.org/assignments/service- 1490 names-port-numbers/service-names-port-numbers.xhtml. 1492 Service Name: convert 1493 Port Number: TBD 1494 Transport Protocol(s): TCP 1495 Description: 0-RTT TCP Convert Protocol 1496 Assignee: IESG 1497 Contact: IETF Chair 1498 Reference: RFC XXXX 1500 8.2. The Convert Protocol (Convert) Parameters 1502 IANA is requested to create a new "The Convert Protocol (Convert) 1503 Parameters" registry. 1505 The following subsections detail new registries within "The Convert 1506 Protocol (Convert) Parameters" registry. 1508 8.2.1. Convert Versions 1510 IANA is requested to create the "Convert versions" sub-registry. New 1511 values are assigned via IETF Review (Section 4.8 of [RFC8126]). 1513 The initial values to be assigned at the creation of the registry are 1514 as follows: 1516 +---------+--------------------------------------+-------------+ 1517 | Version | Description | Reference | 1518 +---------+--------------------------------------+-------------+ 1519 | 0 | Reserved by this document | [This-RFC] | 1520 | 1 | Assigned by this document | [This-RFC] | 1521 +---------+--------------------------------------+-------------+ 1523 8.2.2. Convert TLVs 1525 IANA is requested to create the "Convert TLVs" sub-registry. The 1526 procedure for assigning values from this registry is as follows: 1528 o The values in the range 1-127 can be assigned via IETF Review. 1530 o The values in the range 128-191 can be assigned via Specification 1531 Required. 1533 o The values in the range 192-255 can be assigned for Private Use. 1535 The initial values to be assigned at the creation of the registry are 1536 as follows: 1538 +---------+--------------------------------------+-------------+ 1539 | Code | Name | Reference | 1540 +---------+--------------------------------------+-------------+ 1541 | 0 | Reserved | [This-RFC] | 1542 | 1 | Info TLV | [This-RFC] | 1543 | 10 | Connect TLV | [This-RFC] | 1544 | 20 | Extended TCP Header TLV | [This-RFC] | 1545 | 21 | Supported TCP Extension TLV | [This-RFC] | 1546 | 22 | Cookie TLV | [This-RFC] | 1547 | 30 | Error TLV | [This-RFC] | 1548 +---------+--------------------------------------+-------------+ 1550 8.2.3. Convert Error Messages 1552 IANA is requested to create the "Convert Errors" sub-registry. Codes 1553 in this registry are assigned as a function of the error type. Four 1554 types are defined; the following ranges are reserved for each of 1555 these types: 1557 o Message validation and processing errors: 0-31 1559 o Client-side errors: 32-63 1561 o Transport Converter-side errors: 64-95 1563 o Errors caused by destination server: 96-127 1564 The procedure for assigning values from this sub-registry is as 1565 follows: 1567 o 0-127: Values in this range are assigned via IETF Review. 1569 o 128-191: Values in this range are assigned via Specification 1570 Required. 1572 o 192-255: Values in this range are assigned for Private Use. 1574 The initial values to be assigned at the creation of the registry are 1575 as follows: 1577 +-------+------+-----------------------------------+-----------+ 1578 | Error | Hex | Description | Reference | 1579 +-------+------+-----------------------------------+-----------+ 1580 | 0 | 0x00 | Unsupported Version | [This-RFC]| 1581 | 1 | 0x01 | Malformed Message | [This-RFC]| 1582 | 2 | 0x02 | Unsupported Message | [This-RFC]| 1583 | 3 | 0x03 | Missing Cookie | [This-RFC]| 1584 | 32 | 0x20 | Not Authorized | [This-RFC]| 1585 | 33 | 0x21 | Unsupported TCP Option | [This-RFC]| 1586 | 64 | 0x40 | Resource Exceeded | [This-RFC]| 1587 | 65 | 0x41 | Network Failure | [This-RFC]| 1588 | 96 | 0x60 | Connection Reset | [This-RFC]| 1589 | 97 | 0x61 | Destination Unreachable | [This-RFC]| 1590 +-------+------+-----------------------------------+-----------+ 1592 Figure 22: The Convert Error Codes 1594 9. References 1596 9.1. Normative References 1598 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1599 RFC 793, DOI 10.17487/RFC0793, September 1981, 1600 . 1602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1603 Requirement Levels", BCP 14, RFC 2119, 1604 DOI 10.17487/RFC2119, March 1997, 1605 . 1607 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 1608 Ciphersuites for Transport Layer Security (TLS)", 1609 RFC 4279, DOI 10.17487/RFC4279, December 2005, 1610 . 1612 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1613 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1614 2006, . 1616 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1617 ICMPv6, UDP, and TCP Headers", RFC 4727, 1618 DOI 10.17487/RFC4727, November 2006, 1619 . 1621 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1622 Translation (NAT) Behavioral Requirements for Unicast 1623 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1624 2007, . 1626 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1627 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1628 . 1630 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 1631 RFC 5482, DOI 10.17487/RFC5482, March 2009, 1632 . 1634 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1635 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1636 June 2010, . 1638 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1639 "TCP Extensions for Multipath Operation with Multiple 1640 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1641 . 1643 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 1644 A., and H. Ashida, "Common Requirements for Carrier-Grade 1645 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 1646 April 2013, . 1648 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 1649 "Special-Purpose IP Address Registries", BCP 153, 1650 RFC 6890, DOI 10.17487/RFC6890, April 2013, 1651 . 1653 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1654 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1655 Transport Layer Security (TLS) and Datagram Transport 1656 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1657 June 2014, . 1659 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1660 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1661 . 1663 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1664 Writing an IANA Considerations Section in RFCs", BCP 26, 1665 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1666 . 1668 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1669 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1670 May 2017, . 1672 9.2. Informative References 1674 [ANRW17] Trammell, B., Kuhlewind, M., De Vaere, P., Learmonth, I., 1675 and G. Fairhurst, "Tracking transport-layer evolution with 1676 PATHspider", Applied Networking Research Workshop 2017 1677 (ANRW17) , July 2017. 1679 [Fukuda2011] 1680 Fukuda, K., "An Analysis of Longitudinal TCP Passive 1681 Measurements (Short Paper)", Traffic Monitoring and 1682 Analysis. TMA 2011. Lecture Notes in Computer Science, vol 1683 6613. , 2011. 1685 [HotMiddlebox13b] 1686 Detal, G., Paasch, C., and O. Bonaventure, "Multipath in 1687 the Middle(Box)", HotMiddlebox'13 , December 2013, 1688 . 1691 [I-D.arkko-arch-low-latency] 1692 Arkko, J. and J. Tantsura, "Low Latency Applications and 1693 the Internet Architecture", draft-arkko-arch-low- 1694 latency-02 (work in progress), October 2017. 1696 [I-D.boucadair-mptcp-plain-mode] 1697 Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, 1698 D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 1699 Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., 1700 Contreras, L., and B. Peirens, "Extensions for Network- 1701 Assisted MPTCP Deployment Models", draft-boucadair-mptcp- 1702 plain-mode-10 (work in progress), March 2017. 1704 [I-D.boucadair-radext-tcpm-converter] 1705 Boucadair, M. and C. Jacquenet, "RADIUS Extensions for 1706 0-RTT TCP Converters", draft-boucadair-radext-tcpm- 1707 converter-02 (work in progress), April 2019. 1709 [I-D.boucadair-tcpm-dhc-converter] 1710 Boucadair, M., Jacquenet, C., and R. K, "DHCP Options for 1711 0-RTT TCP Converters", draft-boucadair-tcpm-dhc- 1712 converter-02 (work in progress), April 2019. 1714 [I-D.nam-mptcp-deployment-considerations] 1715 Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx, 1716 W., and R. Skog, "Network-Assisted MPTCP: Use Cases, 1717 Deployment Scenarios and Operational Considerations", 1718 draft-nam-mptcp-deployment-considerations-01 (work in 1719 progress), December 2016. 1721 [I-D.olteanu-intarea-socks-6] 1722 Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6", 1723 draft-olteanu-intarea-socks-6-07 (work in progress), July 1724 2019. 1726 [I-D.peirens-mptcp-transparent] 1727 Peirens, B., Detal, G., Barre, S., and O. Bonaventure, 1728 "Link bonding with transparent Multipath TCP", draft- 1729 peirens-mptcp-transparent-00 (work in progress), July 1730 2016. 1732 [IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment", 1733 IETF Journal, Fall 2016 , n.d.. 1735 [IMC11] Honda, K., Nishida, Y., Raiciu, C., Greenhalgh, A., 1736 Handley, M., and T. Hideyuki, "Is it still possible to 1737 extend TCP?", Proceedings of the 2011 ACM SIGCOMM 1738 conference on Internet measurement conference , 2011. 1740 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 1741 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1742 1992, . 1744 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1745 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1746 . 1748 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 1749 RFC 1919, DOI 10.17487/RFC1919, March 1996, 1750 . 1752 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1753 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1754 DOI 10.17487/RFC1928, March 1996, 1755 . 1757 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1758 Selective Acknowledgment Options", RFC 2018, 1759 DOI 10.17487/RFC2018, October 1996, 1760 . 1762 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1763 Defeating Denial of Service Attacks which employ IP Source 1764 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1765 May 2000, . 1767 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1768 Shelby, "Performance Enhancing Proxies Intended to 1769 Mitigate Link-Related Degradations", RFC 3135, 1770 DOI 10.17487/RFC3135, June 2001, 1771 . 1773 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 1774 Multipath Operation with Multiple Addresses", RFC 6181, 1775 DOI 10.17487/RFC6181, March 2011, 1776 . 1778 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1779 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1780 DOI 10.17487/RFC6887, April 2013, 1781 . 1783 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1784 "Increasing TCP's Initial Window", RFC 6928, 1785 DOI 10.17487/RFC6928, April 2013, 1786 . 1788 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1789 Traversal", RFC 6978, DOI 10.17487/RFC6978, July 2013, 1790 . 1792 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 1793 Scheffenegger, Ed., "TCP Extensions for High Performance", 1794 RFC 7323, DOI 10.17487/RFC7323, September 2014, 1795 . 1797 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1798 Zimmermann, "A Roadmap for Transmission Control Protocol 1799 (TCP) Specification Documents", RFC 7414, 1800 DOI 10.17487/RFC7414, February 2015, 1801 . 1803 [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 1804 Operational Experience with Multipath TCP", RFC 8041, 1805 DOI 10.17487/RFC8041, January 2017, 1806 . 1808 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1809 Better Connectivity Using Concurrency", RFC 8305, 1810 DOI 10.17487/RFC8305, December 2017, 1811 . 1813 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1814 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1815 . 1817 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1818 Q., and E. Smith, "Cryptographic Protection of TCP Streams 1819 (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, 1820 . 1822 [TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical 1823 Specification Group Services and System Aspects; System 1824 Architecture for the 5G System; Stage 2 (Release 16)", 1825 2019, . 1828 Appendix A. Change Log 1830 This section to be removed before publication. 1832 o 00 : initial version, designed to support Multipath TCP and TFO 1833 only 1835 o 00 to -01 : added section Section 5 describing the support of 1836 different standard tracks TCP options by Transport Converters, 1837 clarification of the IANA section, moved the SOCKS comparison to 1838 the appendix and various minor modifications 1840 o 01 to -02: Minor modifications 1842 o 02 to -03: Minor modifications 1844 o 03 to -04: Minor modifications 1845 o 04 to -05: Integrate a lot of feedback from implementors who have 1846 worked on client and server side implementations. The main 1847 modifications are the following : 1849 * TCP Fast Open is not strictly required anymore. Several 1850 implementors expressed concerns about this requirement. The 1851 TFO Cookie protects from some attack scenarios that affect open 1852 servers like web servers. The Convert protocol is different 1853 and as discussed in RFC7413, there are different ways to 1854 protect from such attacks. Instead of using a TFO cookie 1855 inside the TCP options, which consumes precious space in the 1856 extended TCP header, this version supports the utilization of a 1857 Cookie that is placed in the SYN payload. This provides the 1858 same level of protection as a TFO Cookie in environments were 1859 such protection is required. 1861 * the Bootstrap procedure has been simplified based on feedback 1862 from implementers 1864 * Error messages are not included in RST segments anymore but 1865 sent in the bytestream. Implementors have indicated that 1866 processing such segments on clients was difficult on some 1867 platforms. This change simplifies client implementations. 1869 * Many minor editorial changes to clarify the text based on 1870 implementors feedback. 1872 o 05 to -06: Many clarifications to integrate the comments from the 1873 chairs in preparation to the WGLC: 1875 * Updated IANA policy to require "IETF Review" instead of 1876 "Standard Action" 1878 * Call out explicitly that data in SYNs are relayed by the 1879 Converter 1881 * Reiterate the scope 1883 * Hairpinning behavior can be disabled (policy-based) 1885 * Fix nits 1887 o 07: 1889 * Update the text about supplying data in SYNs to make it clear 1890 that a constraint defined in RFC793 is relaxed following the 1891 same rationale as in RFC7413. 1893 * Nits 1895 * Added Appendix A on example Socket API changes 1897 o 08: 1899 * Added short discussion on the termination of connections 1901 o 09: 1903 * Various to comments received during last call 1905 Appendix B. Example Socket API Changes to Support the 0-RTT Convert 1906 Protocol 1908 B.1. Active Open (Client Side) 1910 On the client side, the support of the 0-RTT Converter protocol does 1911 not require any other changes than those identified in Appendix A of 1912 [RFC7413]. Those modifications are already supported by multiple TCP 1913 stacks. 1915 As an example, on Linux, a client can send the 0-RTT Convert message 1916 inside a SYN by using sendto with the MSG_FASTOPEN flag as shown in 1917 the example below: 1919 s = socket(AF_INET, SOCK_STREAM, 0); 1921 sendto(s, buffer, buffer_len, MSG_FASTOPEN, 1922 (struct sockaddr *) &server_addr, addr_len); 1924 The client side of the Linux TCP TFO can be used in two different 1925 modes depending on the host configuration (sysctl tcp_fastopen 1926 variable): 1928 o 0x1: (client) enables sending data in the opening SYN on the 1929 client. 1931 o 0x4: (client) send data in the opening SYN regardless of cookie 1932 availability and without a cookie option. 1934 By setting this configuration variable to 0x5, a Linux client using 1935 the above code would send data inside the SYN without using a TFO 1936 option. 1938 B.2. Passive Open (Converter Side) 1940 The Converter needs to enable the reception of data inside the SYN 1941 independently of the utilization of the TFO option. This implies 1942 that the Transport Converter application cannot rely on the TFO 1943 cookies to validate the reachability of the IP address that sent the 1944 SYN. It must rely on other techniques, such as the Cookie TLV 1945 described in this document, to verify this reachability. 1947 [RFC7413] suggested the utilization of a TCP_FASTOPEN socket option 1948 the enable the reception of SYNs containing data. Later, Appendix A 1949 of [RFC7413], mentioned: 1951 Traditionally, accept() returns only after a socket is connected. 1952 But, for a Fast Open connection, accept() returns upon receiving 1953 SYN with a valid Fast Open cookie and data, and the data is available 1954 to be read through, e.g., recvmsg(), read(). 1956 To support the 0-RTT Convert protocol, this behavior should be 1957 modified as follows: 1959 Traditionally, accept() returns only after a socket is connected. 1960 But, for a Fast Open connection, accept() returns upon receiving a 1961 SYN with data, and the data is available to be read through, e.g., 1962 recvmsg(), read(). The application that receives such SYNs with data 1963 must be able to validate the reachability of the source of the SYN 1964 and also deal with replayed SYNs. 1966 The Linux server side can be configured with the following sysctls: 1968 o 0x2: (server) enables the server support, i.e., allowing data in a 1969 SYN packet to be accepted and passed to the application before 1970 3-way handshake finishes. 1972 o 0x200: (server) accept data-in-SYN w/o any cookie option present. 1974 However, this configuration is system-wide. This is convenient for 1975 typical Transport Converter deployments where no other applications 1976 relying on TFO are collocated on the same device. 1978 Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added to 1979 provide the same behavior on a per socket basis. This enables a 1980 single host to support both servers that require the TFO cookie and 1981 servers that do not use it. 1983 Appendix C. Differences with SOCKSv5 1985 At a first glance, the solution proposed in this document could seem 1986 similar to the SOCKS v5 protocol [RFC1928] which is used to proxy TCP 1987 connections. The Client creates a connection to a SOCKS proxy, 1988 exchanges authentication information and indicates the destination 1989 address and port of the final server. At this point, the SOCKS proxy 1990 creates a connection towards the final server and relays all data 1991 between the two proxied connections. The operation of an 1992 implementation based on SOCKSv5 is illustrated in Figure 23. 1994 Client SOCKS Proxy Server 1995 --------------------> 1996 SYN 1997 <-------------------- 1998 SYN+ACK 1999 --------------------> 2000 ACK 2002 --------------------> 2003 Version=5, Auth Methods 2004 <-------------------- 2005 Method 2006 --------------------> 2007 Auth Request (unless "No auth" method negotiated) 2008 <-------------------- 2009 Auth Response 2010 --------------------> 2011 Connect Server:Port --------------------> 2012 SYN 2014 <-------------------- 2015 SYN+ACK 2016 <-------------------- 2017 Succeeded 2019 --------------------> 2020 Data1 2021 --------------------> 2022 Data1 2024 <-------------------- 2025 Data2 2026 <-------------------- 2027 Data2 2029 Figure 23: Establishment of a TCP connection through a SOCKS proxy 2030 without authentication 2032 The Convert protocol also relays data between an upstream and a 2033 downstream connection, but there are important differences with 2034 SOCKSv5. 2036 A first difference is that the Convert protocol exchanges all control 2037 information during the three-way handshake. This reduces the 2038 connection establishment delay compared to SOCKS that requires two or 2039 more round-trip-times before the establishment of the downstream 2040 connection towards the final destination. In today's Internet, 2041 latency is a important metric and various protocols have been tuned 2042 to reduce their latency [I-D.arkko-arch-low-latency]. A recently 2043 proposed extension to SOCKS leverages the TFO option 2044 [I-D.olteanu-intarea-socks-6]. 2046 A second difference is that the Convert protocol explicitly takes the 2047 TCP extensions into account. By using the Convert protocol, the 2048 Client can learn whether a given TCP extension is supported by the 2049 destination Server. This enables the Client to bypass the Transport 2050 Converter when the destination supports the required TCP extension. 2051 Neither SOCKS v5 [RFC1928] nor the proposed SOCKS v6 2052 [I-D.olteanu-intarea-socks-6] provide such a feature. 2054 A third difference is that a Transport Converter will only accept the 2055 connection initiated by the Client provided that the downstream 2056 connection is accepted by the Server. If the Server refuses the 2057 connection establishment attempt from the Transport Converter, then 2058 the upstream connection from the Client is rejected as well. This 2059 feature is important for applications that check the availability of 2060 a Server or use the time to connect as a hint on the selection of a 2061 Server [RFC8305]. 2063 A fourth difference is that the Convert protocol only allows the 2064 client to specify the address/port of the destination server and not 2065 a DNS name. We evaluated an alternate design for the Connect TLV 2066 that included the DNS name of the remote peer instead of its IP 2067 address as in SOCKS [RFC1928]. However, that design was not adopted 2068 because it induces both an extra load and increased delays on the 2069 Transport Converter to handle and manage DNS resolution requests. 2071 Acknowledgements 2073 Although they could disagree with the contents of the document, we 2074 would like to thank Joe Touch and Juliusz Chroboczek whose comments 2075 on the MPTCP mailing list have forced us to reconsider the design of 2076 the solution several times. 2078 We would like to thank Raphael Bauduin, Stefano Secci, Anandatirtha 2079 Nandugudi and Gregory Vander Schueren for their help in preparing 2080 this document. Nandini Ganesh provided valuable feedback about the 2081 handling of TFO and the error codes. Yuchung Cheng and Praveen 2082 Balasubramanian helped to clarify the discussion on supplying data in 2083 SYNs. Phil Eardley and Michael Scharf's helped to clarify different 2084 parts of the text. 2086 This document builds upon earlier documents that proposed various 2087 forms of Multipath TCP proxies [I-D.boucadair-mptcp-plain-mode], 2088 [I-D.peirens-mptcp-transparent] and [HotMiddlebox13b]. 2090 From [I-D.boucadair-mptcp-plain-mode]: 2092 Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi 2093 Nishida, and Christoph Paasch for their valuable comments. 2095 Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and 2096 Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos 2097 Aires). 2099 Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and 2100 Xavier Grall for their inputs. 2102 Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas 2103 Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves 2104 Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun 2105 Srinivasan, and Raghavendra Mallya for the discussion. 2107 Contributors 2109 Bart Peirens contributed to an early version of the document. 2111 As noted above, this document builds on two previous documents. 2113 The authors of [I-D.boucadair-mptcp-plain-mode] were: 2115 o Mohamed Boucadair 2117 o Christian Jacquenet 2119 o Olivier Bonaventure 2121 o Denis Behaghel 2123 o Stefano Secci 2125 o Wim Henderickx 2127 o Robert Skog 2128 o Suresh Vinapamula 2130 o SungHoon Seo 2132 o Wouter Cloetens 2134 o Ullrich Meyer 2136 o Luis M. Contreras 2138 o Bart Peirens 2140 The authors of [I-D.peirens-mptcp-transparent] were: 2142 o Bart Peirens 2144 o Gregory Detal 2146 o Sebastien Barre 2148 o Olivier Bonaventure 2150 Authors' Addresses 2152 Olivier Bonaventure (editor) 2153 Tessares 2155 Email: Olivier.Bonaventure@tessares.net 2157 Mohamed Boucadair (editor) 2158 Orange 2159 Rennes 35000 2160 France 2162 Email: mohamed.boucadair@orange.com 2164 Sri Gundavelli 2165 Cisco 2167 Email: sgundave@cisco.com 2169 SungHoon Seo 2170 Korea Telecom 2172 Email: sh.seo@kt.com 2173 Benjamin Hesmans 2174 Tessares 2176 Email: Benjamin.Hesmans@tessares.net