idnits 2.17.1 draft-ietf-tcpm-converters-03.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 (October 18, 2018) is 2007 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-RFC' is mentioned on line 1289, but not defined == Missing Reference: 'Bootstrap' is mentioned on line 415, 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 (-02) exists of draft-boucadair-radext-tcpm-converter-00 == Outdated reference: A later version (-03) exists of draft-boucadair-tcpm-dhc-converter-00 == Outdated reference: A later version (-18) exists of draft-ietf-mptcp-rfc6824bis-12 == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-13 == Outdated reference: A later version (-11) exists of draft-olteanu-intarea-socks-6-04 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: April 21, 2019 Orange 6 S. Gundavelli 7 Cisco 8 S. Seo 9 Korea Telecom 10 October 18, 2018 12 0-RTT TCP Convert Protocol 13 draft-ietf-tcpm-converters-03 15 Abstract 17 This document specifies an application proxy, called Transport 18 Converter, to assist the deployment of TCP extensions such as 19 Multipath TCP. This proxy is designed to avoid inducing extra delay 20 when involved in a network-assisted connection (that is, 0-RTT). 21 This specification assumes an explicit model, where the proxy is 22 explicitly configured on hosts. 24 -- Editorial Note (To be removed by RFC Editor) 26 Please update these statements with the RFC number to be assigned to 27 this document: 28 [This-RFC] 30 Please update TBA statements with the port number to be assigned to 31 the Converter Protocol. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 21, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 5 71 3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 7 72 3.3. Sample Examples of Outgoing Converter-Assisted Multipath 73 TCP Connections . . . . . . . . . . . . . . . . . . . . . 10 74 3.4. Sample Example of Incoming Converter-Assisted Multipath 75 TCP Connection . . . . . . . . . . . . . . . . . . . . . 11 76 4. The Converter Protocol (Convert) . . . . . . . . . . . . . . 12 77 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 12 78 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 13 79 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 13 80 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 14 81 4.2.3. The Bootstrap TLV . . . . . . . . . . . . . . . . . . 15 82 4.2.4. Supported TCP Extension Services TLV . . . . . . . . 15 83 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 16 84 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 18 85 4.2.7. Error TLV . . . . . . . . . . . . . . . . . . . . . . 18 86 5. Compatibility of Specific TCP Options with the Conversion 87 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 21 89 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 22 90 5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 22 91 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 22 92 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 23 93 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 23 94 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 24 95 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 24 97 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 24 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 99 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 25 100 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 25 101 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 26 102 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 26 103 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 26 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 105 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 27 106 8.2. The Converter Protocol (Convert) Parameters . . . . . . . 27 107 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 27 108 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 28 109 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 28 110 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 111 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 30 112 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 31 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 114 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 115 11.2. Informative References . . . . . . . . . . . . . . . . . 32 116 Appendix A. Differences with SOCKSv5 . . . . . . . . . . . . . . 35 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 119 1. Introduction 121 Transport protocols like TCP evolve regularly [RFC7414]. TCP has 122 been improved in different ways. Some improvements such as changing 123 the initial window size [RFC6928] or modifying the congestion control 124 scheme can be applied independently on clients and servers. Other 125 improvements such as Selective Acknowledgements [RFC2018] or large 126 windows [RFC7323] require a new TCP option or to change the semantics 127 of some fields in the TCP header. These modifications must be 128 deployed on both clients and servers to be actually used on the 129 Internet. Experience with the latter TCP extensions reveals that 130 their deployment can require many years. [Fukuda2011] reports 131 results of a decade of measurements showing the deployment of 132 Selective Acknowledgements, Window Scale and TCP Timestamps. 133 [ANRW17] describes measurements showing that TCP Fast Open [RFC7413] 134 (TFO) is still not widely deployed. 136 There are some situations where the transport stack used on clients 137 (resp. servers) can be upgraded at a faster pace than the transport 138 stack running on servers (resp. clients). In those situations, 139 clients would typically want to benefit from the features of an 140 improved transport protocol even if the servers have not yet been 141 upgraded and conversely. In the past, Performance Enhancing Proxies 142 have been proposed and deployed [RFC3135] as solutions to improve TCP 143 performance over links with specific characteristics. 145 Recent examples of TCP extensions include Multipath TCP 146 [RFC6824][I-D.ietf-mptcp-rfc6824bis] or TCPINC 147 [I-D.ietf-tcpinc-tcpcrypt]. Those extensions provide features that 148 are interesting for clients such as wireless devices. With Multipath 149 TCP, those devices could seamlessly use WLAN and cellular networks, 150 for bonding purposes, faster handovers, or better resiliency. 151 Unfortunately, deploying those extensions on both a wide range of 152 clients and servers remains difficult. 154 More recently, experimentation of 5G bonding, which has very scarce 155 coverage, has been conducted into global range of the incumbent 4G 156 (LTE) connectivity in newly devised clients using Multipath TCP 157 proxy. Even if the 5G and the 4G bonding by using Multipath TCP 158 increases the bandwidth to data transfer, it is as well crucial to 159 minimize latency for all the way between endhosts regardless of 160 whether intermediate nodes are inside or outside of the mobile core. 161 In order to handle uRLLC (Ultra-Reliable Low-Latency Communication) 162 for the next generation mobile network, Multipath TCP and its proxy 163 mechanism must be optimised to reduce latency. 165 This document specifies an application proxy, called Transport 166 Converter. A Transport Converter is a function that is installed by 167 a network operator to aid the deployment of TCP extensions and to 168 provide the benefits of such extensions to clients. A Transport 169 Converter may support conversion service for one or more TCP 170 extensions. This service is provided by means of the Converter 171 Protocol (Convert), that is an application layer protocol which uses 172 TBA TCP port number (Section 8). 174 The Transport Converter adheres to the main principles as drawn in 175 [RFC1919]. In particular, the Converter achieves the following: 177 o Listen for client sessions; 179 o Receive from a client the address of the final target server; 181 o Setup a session to the final server; 183 o Relay control messages and data between the client and the server; 185 o Perform access controls according to local policies. 187 The main advantage of network-assisted Converters is that they enable 188 new TCP extensions to be used on a subset of the end-to-end path, 189 which encourages the deployment of these extensions. The Transport 190 Converter allows the client and the server to directly negotiate TCP 191 options. 193 The Convert Protocol is a generic mechanism to provide 0-RTT 194 conversion service. As a sample applicability use case, this 195 document specifies how the Convert Protocol applies for Multipath 196 TCP. It is out of scope of this document to provide a comprehensive 197 list of potential all conversion services; separate documents may be 198 edited in the future for other conversion services upon need. 200 This document does not assume that all the traffic is eligible to the 201 network-assisted conversion service. Only a subset of the traffic 202 will be forwarded to a Converter according to a set of policies. 203 Furthermore, it is possible to bypass the Converter to connect to the 204 servers that already support the required TCP extension. 206 This document assumes that a client is configured with one or a list 207 of Converters (e.g., [I-D.boucadair-tcpm-dhc-converter]). 208 Configuration means are outside the scope of this document. 210 This document is organized as follows. We first provide a brief 211 explanation of the operation of Transport Converters in Section 3. 212 We describe the Converter Protocol in Section 4. We discuss in 213 Section 5 how Transport Converters can be used to support different 214 TCP options. We then discuss the interactions with middleboxes 215 (Section 6) and the security considerations (Section 7). 217 Appendix A provides a comparison with SOCKS proxies that are already 218 used to deploy Multipath TCP in some cellular networks. 220 2. Requirements 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 224 "OPTIONAL" in this document are to be interpreted as described in 225 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 226 as shown here. 228 3. Architecture 230 3.1. Functional Elements 232 The architecture considers three types of endhosts: 234 o Client endhosts; 236 o Transport Converters; 238 o Server endhosts. 240 A Transport Converter is a network function that relays all data 241 exchanged over one upstream connection to one downstream connection 242 and vice versa (Figure 1). The Converter, thus, maintains state that 243 associates one upstream connection to a corresponding downstream 244 connection. 246 A connection can be initiated from both sides of the Transport 247 Converter (Internet-facing interface, client-facing interface). 249 +------------+ 250 <--- upstream --->| Transport |<--- downstream ---> 251 | Converter | 252 +------------+ 254 Figure 1: A Transport Converter relays data between pairs of TCP 255 connections 257 Transport Converters can be operated by network operators or third 258 parties. Nevertheless, this document focuses on the single 259 administrative deployment case where the entity offering the 260 connectivity service to a client is also the entity which owns and 261 operates the Transport Converter. 263 A Transport Converter can be embedded in a standalone device or be 264 activated as a service on a router. How such function is enabled is 265 deployment-specific (Figure 2). 267 +-+ +-+ +-+ 268 Client - |R| -- |R| -- |R| - - - Server 269 +-+ +-+ +-+ 270 | 271 Transport 272 Converter 274 Figure 2: A Transport Converter can be installed anywhere in the 275 network 277 The architecture assumes that new software will be installed on the 278 Client hosts and on Transport Converters. Further, the architecture 279 allows for making use of TCP new extensions if those are supported by 280 a given server. 282 The Client is configured, through means that are outside the scope of 283 this document, with the names and/or the addresses of one or more 284 Transport Converters. 286 The architecture does not mandate anything on the server side. 288 Similar to address sharing mechanisms, the architecture does not 289 interfere with end-to-end TLS connections between the client and the 290 server. 292 One of the benefits of this design is that different transport 293 protocol extensions can be used on the upstream and the downstream 294 connections. This encourages the deployment of new TCP extensions 295 until they are widely supported by servers. 297 3.2. Theory of Operation 299 At a high level, the objective of the Transport Converter is to allow 300 the Client to use a specific extension, e.g. Multipath TCP, on a 301 subset of the end-to-end path even if the Server does not support 302 this extension. This is illustrated in Figure 3 where the Client 303 initiates a Multipath TCP connection with the Converter (Multipath 304 packets are shown with "===") while the Converter uses a regular TCP 305 connection with the Server. 307 The packets belonging to the pair of connections between the Client 308 and Server passing through a Transport Converter may follow a 309 different path than the packets directly exchanged between the Client 310 and the Server. Deployments should minimize the possible additional 311 delay by carefully selecting the location of the Transport Converter 312 used to reach a given destination. 314 Transport 315 Client Converter Server 316 ======================> 318 --------------------> 320 <-------------------- 322 <====================== 323 Multipath TCP packets Regular TCP packets 325 Figure 3: Different TCP variants can be used on the Client-Converter 326 path and on the Converter-Server path 328 When establishing a connection, the Client can, depending on local 329 policies, either contact the Server directly (e.g., by sending a TCP 330 SYN towards the Server) or create the connection via a Transport 331 Converter. In the latter case, which is the case we consider in this 332 document, the Client initiates a connection towards the Transport 333 Converter and indicates the IP address and port number of the 334 ultimate Server inside the connection establishment packet. Doing so 335 enables the Transport Converter to immediately initiate a connection 336 towards that Server, without experiencing an extra delay. The 337 Transport Converter waits until the confirmation that the Server 338 agrees to establish the connection before confirming it to the 339 Client. 341 The client places the destination address and port number of the 342 target Server in the payload of the SYN sent to the Converter by 343 leveraging TCP Fast Open [RFC7413]. In accordance with [RFC1919], 344 the Transport Converter maintains two connections that are combined 345 together: 347 o the upstream connection is the one between the Client and the 348 Transport Converter. 350 o the downstream connection is between the Transport Converter and 351 the remote Server. 353 Any user data received by the Transport Converter over the upstream 354 (resp., downstream) connection is relayed over the downstream (resp., 355 upstream) connection. 357 Figure 4 illustrates the establishment of a TCP connection by the 358 Client through a Transport Converter. The information shown between 359 brackets is part of the Converter Protocol described later in this 360 document. 362 Transport 363 Client Converter Server 364 --------------------> 365 SYN TFO [->Server:port] 367 --------------------> 368 SYN 370 <-------------------- 371 SYN+ACK 372 <-------------------- 373 SYN+ACK [ ] 375 Figure 4: Establishment of a TCP connection through a Converter 377 The Client sends a SYN destined to the Transport Converter. This SYN 378 contains a TFO cookie and inside its payload the addresses and ports 379 of the destination Server. The Transport Converter does not reply 380 immediately to this SYN. It first tries to create a TCP connection 381 towards the destination Server. If this second connection succeeds, 382 the Transport Converter confirms the establishment of 384 the connection to the Client by returning a SYN+ACK and the first 385 bytes of the bytestream contain information about the TCP options 386 that were negotiated with the final Server. This information is sent 387 at the beginning of the bytestream, either directly in the SYN+ACK or 388 in a subsequent packet. For graphical reasons, the figures in this 389 section show that the Converter returns this information in the 390 SYN+ACK packet. An implementation could also place this information 391 in a packet that it sent shortly after the SYN+ACK. 393 The connection can also be established from the Internet towards a 394 Client via a Transport Converter. This is typically the case when 395 the Client embeds a server (video server, for example). 397 The procedure described in Figure 4 assumes that the Client has 398 obtained a TFO cookie from the Transport Converter. This is part of 399 the Bootstrap procedure which is illustrated in Figure 5. The Client 400 sends a SYN with a TFO request option to obtain a valid cookie from 401 the Converter. The Converter replies with a TFO cookie in the 402 SYN+ACK. Once this connection has been established, the Client sends 403 a Bootstrap message to request the list of TCP options for which the 404 Transport Converter provides a conversion service. 406 Transport 407 Client Converter Server 408 --------------------> 409 SYN TFO(empty) 411 <-------------------- 412 SYN+ACK TFO(cookie) 414 --------------------> 415 [Bootstrap] 417 <-------------------- 418 [Supported TCP Extension Services] 420 Figure 5: Bootstrapping a Client connection to a Transport Converter 422 Note that the Converter may rely on local policies to decide whether 423 it can service a given requesting Client. That is, the Converter 424 will not return a cookie for that Client. How such policies are 425 supplied to the Converter are out of scope. 427 Also, the Converter may behave in a cookie-less mode when appropriate 428 means are enforced at the Converter and the network in-between to 429 protect against attacks such as spoofing and SYN flood. Under such 430 deployments, the use of TFO is not required. 432 3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP 433 Connections 435 As an example (Figure 6), let us consider how the Convert protocol 436 can help the deployment of Multipath TCP [RFC6824]. We assume that 437 both the Client and the Transport Converter support Multipath TCP, 438 but consider two different cases depending whether the Server 439 supports Multipath TCP or not. A Multipath TCP connection is created 440 by placing the MP_CAPABLE (MPC) option in the SYN sent by the Client. 442 Figure 6 describes the operation of the Transport Converter if the 443 Server does not support Multipath TCP. 445 Transport 446 Client Converter Server 447 --------------------> 448 SYN, MPC [->Server:port] 450 --------------------> 451 SYN, MPC 453 <-------------------- 454 SYN+ACK 455 <-------------------- 456 SYN+ACK,MPC [ ] 458 --------------------> 459 ACK,MPC 460 --------------------> 461 ACK 463 Figure 6: Establishment of a Multipath TCP connection through a 464 Converter 466 The Client tries to initiate a Multipath TCP connection by sending a 467 SYN with the MP_CAPABLE option (MPC in Figure 6). The SYN includes 468 the address and port number of the final Server and the Transport 469 Converter attempts to initiate a Multipath TCP connection towards 470 this Server. Since the Server does not support Multipath TCP, it 471 replies with a SYN+ACK that does not contain the MP_CAPABLE option. 472 The Transport Converter notes that the connection with the Server 473 does not support Multipath TCP and returns the TCP options received 474 from the Server to the Client. 476 Figure 7 considers a Server that supports Multipath TCP. In this 477 case, it replies to the SYN sent by the Transport Converter with the 478 MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport 479 Converter confirms the establishment of the connection to the Client 480 and indicates to the Client that the Server supports Multipath TCP. 481 With this information, the Client has discovered that the Server 482 supports Multipath TCP natively. This will enable it to bypass the 483 Transport Converter for the next Multipath TCP connection that it 484 will initiate towards this Server. 486 Transport 487 Client Converter Server 488 --------------------> 489 SYN, MPC [->Server:port] 491 --------------------> 492 SYN, MPC 494 <-------------------- 495 SYN+ACK, MPC 496 <-------------------- 497 SYN+ACK, MPC [ MPC supported ] 499 --------------------> 500 ACK, MPC 501 --------------------> 502 ACK, MPC 504 Figure 7: Establishment of a Multipath TCP connection through a 505 converter 507 3.4. Sample Example of Incoming Converter-Assisted Multipath TCP 508 Connection 510 An example of an incoming Converter-assisted Multipath TCP connection 511 is depicted in Figure 8. In order to support incoming connections 512 from remote hosts, the Client may use PCP [RFC6887] to instruct the 513 Converter to create dynamic mappings. Those mappings will be used by 514 the Converter to intercept an incoming TCP connection destined to the 515 Client and convert it into a Multipath TCP connection. 517 Transport 518 Client Converter Remote Host 519 <------------------- 520 SYN 522 <------------------- 523 SYN, MPC[Remote Host:port] 525 ---------------------> 526 SYN+ACK, MPC 527 ---------------------> 528 SYN+ACK 530 <--------------------- 531 ACK 532 <------------------- 533 ACK, MPC 535 Figure 8: Establishment of an Incoming TCP Connection through a 536 Converter 538 4. The Converter Protocol (Convert) 540 This section describes in details the messages that are exchanged 541 between a Client and a Transport Converter. The Converter Protocol 542 (Convert, for short) leverages the TCP Fast Open extension [RFC7413]. 544 The Converter Protocol uses a 32 bits long fixed header that is sent 545 by both the Client and the Transport Converter. This header 546 indicates both the version of the protocol used and the length of the 547 Convert message. 549 4.1. The Convert Fixed Header 551 The Fixed Header is used to exchange information about the version 552 and length of the messages between the Client and the Transport 553 Converter. 555 The Client and the Transport Converter MUST send the fixed-sized 556 header shown in Figure 9 as the first four bytes of the bytestream. 558 1 2 3 559 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 560 +---------------+---------------+-------------------------------+ 561 | Version | Total Length | Unassigned | 562 +---------------+---------------+-------------------------------+ 564 Figure 9: The fixed-sized header of the Converter protocol 566 The Version is encoded as an 8 bits unsigned integer value. This 567 document specifies version 1. Version 0 is reserved by this document 568 and MUST NOT be used. 570 The Total Length is the number of 32 bits word, including the header, 571 of the bytestream that are consumed by the Converter protocol 572 messages. Since Total Length is also an 8 bits unsigned integer, 573 those messages cannot consume more than 1020 bytes of data. This 574 limits the number of bytes that a Transport Converter needs to 575 process. A Total Length of zero is invalid and the connection MUST 576 be reset upon reception of such a header. 578 The Unassigned field MUST be set to zero in this version of the 579 protocol. These bits are available for future use [RFC8126]. 581 4.2. Convert TLVs 583 4.2.1. Generic Convert TLV Format 585 The Convert protocol uses variable length messages that are encoded 586 using the generic TLV format depicted in Figure 10. All TLV fields 587 are encoded using the network byte order. 589 1 2 3 590 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 591 +---------------+---------------+-------------------------------+ 592 | Type | Length | (optional) Value ... | 593 +---------------+---------------+-------------------------------+ 594 | ... (optional) Value | 595 +---------------------------------------------------------------+ 597 Figure 10: Converter Generic TLV Format 599 A given TLV LUST only appear once on a connection. If two or more 600 copies of the same TLV are exchanged over a Converter connection, the 601 associated TCP connections MUST be closed. All fields are encoded 602 using the network byte order. The length field is the number of 32 603 bits words. 605 4.2.2. Summary of Supported Convert TLVs 607 This document specifies the following Convert TLVs: 609 +------+-----+----------+------------------------------------------+ 610 | Type | Hex | Length | Description | 611 +------+-----+----------+------------------------------------------+ 612 | 1 | 0x1 | 1 | Bootstrap TLV | 613 | 10 | 0xA | Variable| Connect TLV | 614 | 20 | 0x14| Variable| Extended TCP Header TLV | 615 | 21 | 0x15| Variable| Supported TCP Extension Services TLV | 616 | 30 | 0x1E| Variable| Error TLV | 617 +------+-----+----------+------------------------------------------+ 619 Figure 11: The TLVs used by the Converter protocol 621 To establish a connection via a Transport Converter, a Client MUST 622 first obtain a valid TFO cookie from that Converter. This is the 623 bootstrap procedure during which the Client opens a connection to the 624 Transport Converter with an empty TFO option. According to 625 [RFC7413], the Transport Converter returns its cookie in the SYN+ACK. 626 Then the Client sends a Bootstrap TLV (Section 4.2.3) to which the 627 Transport Converter replies with the Supported TCP Extension Services 628 TLV described in Section 4.2.4. 630 With the TFO cookie of the Transport Converter, the Client can 631 request the establishment of connections to remote servers with the 632 Connect TLV (see Section 4.2.5). If the connection can be 633 established with the final server, the Transport Converter replies 634 with the Extended TCP Header TLV and returns an Error TLV inside a 635 RST packet (see Section 4.2.7). 637 When the Transport Converter receives an incoming connection 638 establishment from a Client, it MUST process the TCP options found in 639 the SYN and the Connect TLV. In general, the Transport Converter 640 MUST add to the proxied SYN the TCP options that were included in the 641 Connect TLV. It SHOULD add to the proxied SYN the TCP options that 642 were included in the incoming SYN provided that it supports the 643 corresponding TCP extension. 645 There are some exceptions to these rules given the semantics of some 646 TCP options. First, TCP options with Kinds 0 (EOL), 1 (NOP), 2 647 (MSS), and 3 (WS) MUST be used according to the configuration of the 648 TCP stack of the Transport Converter. The Timestamps option 649 (Kind=10) SHOULD be used in the proxied SYN if it was present in the 650 incoming SYN, but the contents of the option in the proxied SYN 651 SHOULD be set by the Converter's stack. The MP_CAPABLE option SHOULD 652 be added to the proxied SYN if it was present in the incoming SYN, 653 but the content of the option in the proxied SYN SHOULD be set by the 654 Converter's stack. The TCP Fast Open cookie option SHOULD be handled 655 as described in Section 6. 657 As a general rule, when an error is encountered an Error TLV with the 658 appropriate error code MUST be returned. 660 4.2.3. The Bootstrap TLV 662 The Bootstrap TLV (Figure 12 is sent by a Client to request the TCP 663 extensions that are supported by a Transport Converter and for which 664 it provides a conversion service. It is typically sent on the first 665 connection that a Client establishes with a Transport Converter to 666 learn its capabilities. Assuming a Client is entitled to invoke the 667 Converter, this latter replies with the Supported TCP Extensions 668 Services TLV described in Section 4.2.4. 670 1 2 3 671 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 672 +---------------+---------------+-------------------------------+ 673 | Type | Length | Zero | 674 +---------------+---------------+-------------------------------+ 676 Figure 12: The Bootstrap TLV 678 4.2.4. Supported TCP Extension Services TLV 680 The Supported TCP Extension Services TLV (Figure 13) is used by a 681 Converter to announce the TCP options for which it provides a 682 conversion service. Each supported TCP option is encoded with its 683 TCP option Kind listed in the "TCP Parameters" registry maintained by 684 IANA. 686 1 2 3 687 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 688 +---------------+---------------+-------------------------------+ 689 | Type | Length | Unassigned | 690 +---------------+---------------+-------------------------------+ 691 | Kind #1 | Kind #2 | ... | 692 +---------------+---------------+-------------------------------+ 693 / ... / 694 / / 695 +---------------------------------------------------------------+ 697 Figure 13: The Supported TCP Extension Services TLV 699 TCP option Kinds 0, 1, and 2 defined in [RFC0793] are supported by 700 all TCP implementations and thus MUST NOT appear in this list. 702 The list of Supported TCP Extension Services is padded with 0 to end 703 on a 32 bits boundary. 705 Typically, if the Converter only supports Multipath TCP conversion 706 service, solely Kind=30 will be present in the Supported TCP 707 Extension Services TLV returned by the Converter to a requesting 708 Client. 710 4.2.5. Connect TLV 712 The Connect TLV (Figure 14) is used to request the establishment of a 713 connection via a Transport Converter. 715 The 'Remote Peer Port' and 'Remote Peer IP Address' fields contain 716 the destination port number and IP address of the target server for 717 an outgoing connection towards a server located on the Internet. For 718 incoming connections destined to a client serviced via a Converter, 719 these fields convey the source port and IP address. 721 The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 722 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format 723 defined in [RFC4291]. 725 The optional 'TCP Options' field is used to specify how specific TCP 726 Options should be advertised by the Transport Converter to the final 727 destination of a connection. If this field is not supplied, the 728 Transport Converter MUST use the default TCP options that correspond 729 to its local policy. 731 The Connect TLV could be designed to be generic to include the DNS 732 name of the remote peer instead of its IP address as in SOCKS 733 [RFC1928]. However, that design was not adopted because it induces 734 both an extra load and increased delays on the Converter to handle 735 and manage DNS resolution requests. 737 1 2 3 738 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 739 +---------------+---------------+-------------------------------+ 740 | Type | Length | Remote Peer Port | 741 +---------------+---------------+-------------------------------+ 742 | | 743 | Remote Peer IP Address (128 bits) | 744 | | 745 | | 746 +---------------------------------------------------------------+ 747 | TCP Options (Variable) | 748 | ... | 749 +---------------------------------------------------------------+ 751 Figure 14: The Connect TLV 753 The 'TCP Options' field is a variable length field that carries a 754 list of TCP option fields (Figure 15). Each TCP option field is 755 encoded as a block of 2+n bytes where the first byte is the TCP 756 option Type and the second byte is the length of the TCP option as 757 specified in [RFC0793]. The minimum value for the TCP option Length 758 is 2. The TCP options that do not include a length subfield, i.e., 759 option types 0 (EOL) and 1 (NOP) defined in [RFC0793] cannot be 760 placed inside the TCP options field of the Connect TLV. The optional 761 Value field contains the variable-length part of the TCP option. A 762 length of two indicates the absence of the Value field. The TCP 763 options field always ends on a 32 bits boundary after being padded 764 with zeros. 766 1 2 3 767 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 768 +---------------+---------------+---------------+---------------+ 769 | TCPOpt type | TCPOpt Length | Value (opt) | .... | 770 +---------------+---------------+---------------+---------------+ 771 | .... | 772 +---------------------------------------------------------------+ 773 | ... | 774 +---------------------------------------------------------------+ 776 Figure 15: The TCP Options field 778 If a Transport Converter receives a Connect TLV with a non-empty TCP 779 options field, and the Converter acceptss to process the request, it 780 SHALL present those options to the destination peer in addition to 781 the TCP options that it would have used according to its local 782 policies. For the TCP options that are listed without an optional 783 value, the Converter MUST generate its own value. For the TCP 784 options that are included in the 'TCP Options' field with an optional 785 value, it SHALL copy the entire option for use in the connection with 786 the destination peer. This feature is required to support TCP Fast 787 Open. 789 The Converter may discard a Connect TLV request for many reasons 790 (e.g., bad TFO cookie, authorization failed, out of resources). An 791 error message indicating the encountered error is returned to the 792 requesting Client Section 4.2.7. In order to prevent denial-of- 793 service attacks, error messages sent to a Client SHOULD be rate- 794 limited. 796 4.2.6. Extended TCP Header TLV 798 The Extended TCP Header TLV (Figure 16) is used by the Transport 799 Converter to send to the Client the extended TCP header that was 800 returned by the Server in the SYN+ACK packet. This TLV is only sent 801 if the Client sent a Connect TLV to request the establishment of a 802 connection. 804 1 2 3 805 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 806 +---------------+---------------+-------------------------------+ 807 | Type | Length | Unassigned | 808 +---------------+---------------+-------------------------------+ 809 | Returned Extended TCP header | 810 | ... | 811 +---------------------------------------------------------------+ 813 Figure 16: The Extended TCP Header TLV 815 The Returned Extended TCP header field is a copy of the extended 816 header that was received in the SYN+ACK by the Transport Converter. 818 The Unassigned field MUST be set to zero by the transmitter and 819 ignored by the receiver. These bits are available for future use 820 [RFC8126]. 822 4.2.7. Error TLV 824 The optional Error TLV (Figure 17) can be used by the Transport 825 Converter to provide information about some errors that occurred 826 during the processing of a request to convert a connection. This TLV 827 appears after the Convert header in a RST segment returned by the 828 Transport Converter if the error is fatal and prevented the 829 establishment of the connection. If the error is not fatal and the 830 connection could be established with the final destination, then the 831 error TLV will be carried in the payload. 833 1 2 3 834 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 835 +---------------+---------------+----------------+--------------+ 836 | Type | Length | Error | Value | 837 +---------------+---------------+----------------+--------------+ 839 Figure 17: The Error TLV 841 Different types of errors can occur while processing Convert 842 messages. Each error is identified by a code represented as an 843 unsigned integer. Four classes of errors are defined: 845 o Message validation and processing errors (0-31 range): returned 846 upon reception of an an invalid message (including valid messages 847 but with invalid or unknown TLVs). 849 o Client-side errors (32-63 range): the Client sent a request that 850 could not be accepted by the Converter (e.g., unsupported 851 operation). 853 o Converter-side errors (64-95 range) : problems encountered on the 854 Converter (e.g., lack of resources) which prevent it from 855 fulfilling the Client's request. 857 o Errors caused by destination server (96-127 range) : the final 858 destination could not be reached or it replied with a reset 859 message. 861 The following error codes are defined in this document: 863 o Unsupported Version (0): The version number indicated in the fixed 864 header of a message received from a peer is not supported. 866 This error code MUST be generated by a Converter when it receives 867 a request having a version number that it does not support. 869 The value field MUST be set to the version supported by the 870 Converter. When multiple versions are supported by the Converter, 871 it includes the list of supported version in the value field; each 872 version is encoded in 8 bits. 874 Upon receipt of this error code, the client checks whether it 875 supports one of the versions returned by the Converter. The 876 highest common supported version MUST be used by the client in 877 subsequent exchanges with the Converter. 879 o Malformed Message (1): This error code is sent to indicate that a 880 message can not be successfully parsed. 882 To ease troubleshooting, the value field MUST echo the received 883 message. The Converter and the Client MUST send a RST containing 884 this error upon reception of a malformed message. 886 o Unsupported Message (2): This error code is sent to indicate that 887 a message type is not supported by the Converter. 889 To ease troubleshooting, the value field MUST echo the received 890 message. The Converter and the Client MUST send a RST containing 891 this error upon reception of an unsupported message. 893 o Not Authorized (32): This error code indicates that the Converter 894 refused to create a connection because of a lack of authorization 895 (e.g., administratively prohibited, authorization failure, etc.). 896 The Value field MUST be set to zero. 898 This error code MUST be sent by the Converter when a request 899 cannot be successfully processed because the authorization failed. 901 o Unsupported TCP Option (33): A TCP option that the Client 902 requested to advertise to the final Server cannot be safely used 903 jointly with the conversion service. 905 The Value field is set to the type of the unsupported TCP option. 906 If several unsupported TCP options were specified in the Connect 907 TLV, only one of them is returned in the Value. 909 o Resource Exceeded (64): This error indicates that the Transport 910 Converter does not have enough resources to perform the request. 912 This error MUST be sent by the Converter when it does not have 913 sufficient resources to handle a new connection. 915 o Network Failure (65): This error indicates that the Converter is 916 experiencing a network failure to relay the request. 918 The Converter MUST send this error code when it experiences 919 forwarding issues to relay a connection. 921 o Connection Reset (96): This error indicates that the final 922 destination responded with a RST packet. The Value field MUST be 923 set to zero. 925 o Destination Unreachable (97): This error indicates that an ICMP 926 destination unreachable, port unreachable, or network unreachable 927 was received by the Converter. The Value field MUST echo the Code 928 field of the received ICMP message. 930 This error message MUST be sent by the Converter when it receives 931 an error message that is bound to a message it relayed previously. 933 Figure 18 summarizes the different error codes. 935 +-------+------+-----------------------------------------------+ 936 | Error | Hex | Description | 937 +-------+------+-----------------------------------------------+ 938 | 0 | 0x00 | Unsupported Version | 939 | 1 | 0x01 | Malformed Message | 940 | 2 | 0x02 | Unsupported Message | 941 | 32 | 0x20 | Not Authorized | 942 | 33 | 0x21 | Unsupported TCP Option | 943 | 64 | 0x40 | Resource Exceeded | 944 | 65 | 0x41 | Network Failure | 945 | 96 | 0x60 | Connection Reset | 946 | 97 | 0x61 | Destination Unreachable | 947 +-------+------+-----------------------------------------------+ 949 Figure 18: Convert Error Values 951 5. Compatibility of Specific TCP Options with the Conversion Service 953 In this section, we discuss how several standard track TCP options 954 can be supported through the Converter. The non-standard track 955 options and the experimental options will be discussed in other 956 documents. 958 5.1. Base TCP Options 960 Three TCP options were initially defined in [RFC0793] : End-of-Option 961 List (Kind=0), No-Operation (Kind=1) and Maximum Segment Size 962 (Kind=2). The first two options are mainly used to pad the TCP 963 extended header. There is no reason for a client to request a 964 Converter to specifically send these options towards the final 965 destination. 967 The Maximum Segment Size option (Kind=2) is used by a host to 968 indicate the largest segment that it can receive over each 969 connection. This value is function of the stack that terminates the 970 TCP connection. There is no reason for a Client to request a 971 Converter to advertise a specific MSS value to a remote server. 973 A Converter MUST ignore options with Kind=0, 1 or 2 if they appear in 974 a Connect TLV. It MUST NOT announce them in a Bootstrap TLV. 976 5.2. Window Scale (WS) 978 The Window Scale option (Kind=3) is defined in [RFC7323]. As for the 979 MSS option, the window scale factor that is used for a connection 980 strongly depends on the TCP stack that handles the connection. When 981 a Converter opens a TCP connection towards a remote server on behalf 982 of a Client, it SHOULD use a WS option with a scaling factor that 983 corresponds to the configuration of its stack. A local configuration 984 MAY allow for WS option in the proxied message to be function of the 985 scaling factor of the incoming connection. 987 There is no benefit from a deployment viewpoint in enabling a Client 988 of a Converter to specifically request the utilisation of the WS 989 option (Kind=3) with a specific scaling factor towards a remote 990 Server. For this reason, a Converter MUST ignore option Kind=3 if it 991 appears in a Connect TLV. It MUST NOT announce it in a Bootstrap 992 TLV. 994 5.3. Selective Acknowledgements 996 Two distinct TCP options were defined to support selective 997 acknowledgements in [RFC2018]. This first one, SACK Permitted 998 (Kind=4), is used to negotiate the utilisation of selective 999 acknowledgements during the three-way handshake. The second one, 1000 SACK (Kind=5), carries the selective acknowledgements inside regular 1001 segments. 1003 The SACK Permitted option (Kind=4) MAY be advertised by a Transport 1004 Converter in the Bootstrap TLV. In this case, Clients connected to 1005 this Transport Converter MAY include the SACK Permitted option in the 1006 Connect TLV. 1008 The SACK option (Kind=5) cannot be used during the three-way 1009 handshake. For this reason, a Transport Converter MUST ignore option 1010 Kind=5 with if it appears in a Connect TLV. It MUST NOT announce it 1011 in a Bootstrap TLV. 1013 5.4. Timestamp 1015 The Timestamp option was initially defined in [RFC1323] which has 1016 been replaced by [RFC7323]. It can be used during the three-way 1017 handshake to negotiate the utilisation of the timestamps during the 1018 TCP connection. It is notably used to improve round-trip-time 1019 estimations and to provide protection against wrapped sequence 1020 numbers (PAWS). As for the WS option, the timestamps are a property 1021 of a connection and there is limited benefit in enabling a client to 1022 request a Converter to use the timestamp option when establishing a 1023 connection to a remote server. Furthermore, the timestamps that are 1024 used by TCP stacks are specific to each stack and there is no benefit 1025 in enabling a client to specify the timestamp value that a Converter 1026 could use to establish a connection to a remote server. 1028 A Transport Converter MAY advertise the Timestamp option (Kind=8) in 1029 the Bootstrap TLV. The clients connected to this Converter MAY 1030 include the Timestamp option in the Connect TLV but without any 1031 timestamp. 1033 5.5. Multipath TCP 1035 The Multipath TCP options are defined in [RFC6824]. [RFC6824] 1036 defines one variable length TCP option (Kind=30) that includes a 1037 subtype field to support several Multipath TCP options. There are 1038 several operational use cases where clients would like to use 1039 Multipath TCP through a Converter [IETFJ16]. However, none of these 1040 use cases require the Client to specify the content of the Multipath 1041 TCP option that the Converter should send to a remote server. 1043 A Transport Converter which supports Multipath TCP conversion service 1044 MUST advertise the Multipath TCP option (Kind=30) in the Bootstrap 1045 TLV. Clients serviced by this Converter may include the Multipath 1046 TCP option in the Connect TLV but without any content. 1048 5.6. TCP Fast Open 1050 The TCP Fast Open cookie option (Kind=34) is defined in [RFC7413]. 1051 There are two different usages of this option that need to be 1052 supported by Transport Converters. The first utilisation of the Fast 1053 Open cookie is to request a cookie from the server. In this case, 1054 the option is sent with an empty cookie by the client and the server 1055 returns the cookie. The second utilisation of the Fast Open cookie 1056 is to send a cookie to the server. In this case, the option contains 1057 a cookie. 1059 A Transport Converter MAY advertise the TCP Fast Open cookie option 1060 (Kind=34) in the Bootstrap TLV. If a Transport Converter has 1061 advertised the support for TCP Fast Open in its Bootstrap TLV, it 1062 needs to be able to process two types of Connect TLV. If such a 1063 Transport Converter receives a Connect TLV with the TCP Fast Open 1064 cookie option that does not contain a cookie, it MUST add an empty 1065 TCP Fast Open cookie option in the SYN sent to the remote server. If 1066 such a Transport Converter receives a Connect TLV with the TCP Fast 1067 Open cookie option that contains a cookie, it MUST copy the TCP Fast 1068 Open cookie option in the SYN sent to the remote server. 1070 5.7. TCP User Timeout 1072 The TCP User Timeout option is defined in [RFC5482]. The associated 1073 TCP option (Kind=28) does not appear to be widely deployed. 1075 Editor's Note: Feedback requested for the utilisation of this option 1076 by deployed TCP stacks. 1078 5.8. TCP-AO 1080 TCP-AO [RFC5925] provides a technique to authenticate all the packets 1081 exchanged over a TCP connection. Given the nature of this extension, 1082 it is unlikely that the applications that require their packets to be 1083 authenticated end-to-end would want their connections to pass through 1084 a converter. For this reason, we do not recommend the support of the 1085 TCP-AO option by Transport Converters. The only use cases where is 1086 makes sense to combine TCP-AO and the solution in this document are 1087 those where the TCP-AO-NAT extension [RFC6978] is in use. 1089 A Converter MUST NOT advertise the TCP-AO option (Kind=29) in the 1090 Bootstrap TLV. If a Converter receives a Connect TLV that contains 1091 the TCP-AO option, it MUST reject the establishment of the connection 1092 with error code set to "Unsupported TCP Option", except if the TCP- 1093 AO-NAT option is used. 1095 5.9. TCP Experimental Options 1097 The TCP Experimental options are defined in [RFC4727]. Given the 1098 variety of semantics for these options and their experimental nature, 1099 it is impossible to discuss them in details in this document. 1101 6. Interactions with Middleboxes 1103 The Converter Protocol was designed to be used in networks that do 1104 not contain middleboxes that interfere with TCP. We describe in this 1105 section how a Client can detect middlebox interference and stop using 1106 the Transport Converter affected by this interference. 1108 Internet measurements [IMC11] have shown that middleboxes can affect 1109 the deployment of TCP extensions. In this section, we only discuss 1110 the middleboxes that modify SYN and SYN+ACK packets since the 1111 Converter Protocol places its messages in such packets. 1113 Let us first consider a middlebox that removes the TFO Option from 1114 the SYN packet. This interference will be detected by the Client 1115 during the bootstrap procedure discussed in Section 4.2.3. A Client 1116 should not use a Transport Converter that does not reply with the TFO 1117 option during the Bootstrap. 1119 Consider a middlebox that removes the SYN payload after the bootstrap 1120 procedure. The Client can detect this problem by looking at the 1121 acknowledgement number field of the SYN+ACK returned by the Transport 1122 Converter. The Client should stop to use this Transport Converter 1123 given the middlebox interference. 1125 As explained in [RFC7413], some carrier-grade NATs can affect the 1126 operation of TFO if they assign different IP addresses to the same 1127 end host. Such carrier-grade NATs could affect the operation of the 1128 TFO Option used by the Converter Protocol. See also the discussion 1129 in Section 7.1 of [RFC7413]. 1131 7. Security Considerations 1133 7.1. Privacy & Ingress Filtering 1135 The Converter may have access to privacy-related information (e.g., 1136 subscriber credentials). The Converter MUST NOT leak such sensitive 1137 information outside a local domain. 1139 Given its function and its location in the network, a Transport 1140 Converter has access to the payload of all the packets that it 1141 processes. As such, it MUST be protected as a core IP router (e.g., 1142 [RFC1812]). 1144 Furthermore, ingress filtering policies MUST be enforced at the 1145 network boundaries [RFC2827]. 1147 This document assumes that all network attachments are managed by the 1148 same administrative entity. Therefore, enforcing anti-spoofing 1149 filters at these network ensures that hosts are not sending traffic 1150 with spoofed source IP addresses. 1152 7.2. Authorization 1154 The Converter Protocol is intended to be used in managed networks 1155 where end hosts can be identified by their IP address. Thanks to the 1156 Bootstrap procedure, the Transport Converter can verify that the 1157 Client correctly receives packets sent by the Converter. Stronger 1158 authentication schemes MUST be defined to use the Converter Protocol 1159 in more open network environments; such schemes are out of scope of 1160 this document. 1162 See below for authorization considerations that are specific for 1163 Multipath TCP. 1165 7.3. Denial of Service 1167 Another possible risk is the amplification attacks since a Transport 1168 Converter sends a SYN towards a remote Server upon reception of a SYN 1169 from a Client. This could lead to amplification attacks if the SYN 1170 sent by the Transport Converter were larger than the SYN received 1171 from the Client or if the Transport Converter retransmits the SYN. 1172 To mitigate such attacks, the Transport Converter SHOULD rate limit 1173 the number of pending requests for a given Client. It SHOULD also 1174 avoid sending to remote Servers SYNs that are significantly longer 1175 than the SYN received from the Client. In practice, Transport 1176 Converters SHOULD NOT advertise to a Server TCP options that were not 1177 specified by the Client in the received SYN. Finally, the Transport 1178 Converter SHOULD only retransmit a SYN to a Server after having 1179 received a retransmitted SYN from the corresponding Client. 1181 Upon reception of a SYN that contains a valid TFO cookie and a 1182 Connect TLV, the Transport Converter attempts to establish a TCP 1183 connection to a remote Server. There is a risk of denial of service 1184 attack if a Client requests too many connections in a short period of 1185 time. Implementations SHOULD limit the number of pending connections 1186 from a given Client. Means to protect against SYN flooding attacks 1187 MUST also be enabled [RFC4987]. 1189 7.4. Traffic Theft 1191 Traffic theft is a risk if an illegitimate Converter is inserted in 1192 the path. Indeed, inserting an illegitimate Converter in the 1193 forwarding path allows traffic interception and can therefore provide 1194 access to sensitive data issued by or destined to a host. Converter 1195 discovery and configuration are out of scope of this document. 1197 7.5. Multipath TCP-specific Considerations 1199 Multipath TCP-related security threats are discussed in [RFC6181] and 1200 [RFC6824]. 1202 The operator that manages the various network attachments (including 1203 the Converters) can enforce authentication and authorization policies 1204 using appropriate mechanisms. For example, a non-exhaustive list of 1205 methods to achieve authorization is provided hereafter: 1207 o The network provider may enforce a policy based on the 1208 International Mobile Subscriber Identity (IMSI) to verify that a 1209 user is allowed to benefit from the aggregation service. If that 1210 authorization fails, the Packet Data Protocol (PDP) context/bearer 1211 will not be mounted. This method does not require any interaction 1212 with the Converter. 1214 o The network provider may enforce a policy based upon Access 1215 Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) 1216 to control the hosts that are authorized to communicate with a 1217 Converter. These ACLs may be installed as a result of RADIUS 1218 exchanges, e.g. [I-D.boucadair-radext-tcpm-converter]. This 1219 method does not require any interaction with the Converter. 1221 o A device that embeds the Converter may also host a RADIUS client 1222 that will solicit an AAA server to check whether connections 1223 received from a given source IP address are authorized or not 1224 [I-D.boucadair-radext-tcpm-converter]. 1226 A first safeguard against the misuse of Converter resources by 1227 illegitimate users (e.g., users with access networks that are not 1228 managed by the same provider that operates the Converter) is the 1229 Converter to reject Multipath TCP connections received on its 1230 Internet-facing interfaces. Only Multipath PTCP connections received 1231 on the customer-facing interfaces of a Converter will be accepted. 1233 8. IANA Considerations 1235 8.1. Convert Service Port Number 1237 IANA is requested to assign a TCP port number (TBA) for the Converter 1238 Protocol from the "Service Name and Transport Protocol Port Number 1239 Registry" available at https://www.iana.org/assignments/service- 1240 names-port-numbers/service-names-port-numbers.xhtml. 1242 8.2. The Converter Protocol (Convert) Parameters 1244 IANA is requested to create a new "The Converter Protocol (Convert) 1245 Parameters" registry. 1247 The following subsections detail new registries within "The Converter 1248 Protocol (Convert) Parameters" registry. 1250 8.2.1. Convert Versions 1252 IANA is requested to create the "Convert versions" sub-registry. New 1253 values are assigned via Standards Action. 1255 The initial values to be assigned at the creation of the registry are 1256 as follows: 1258 +---------+--------------------------------------+-------------+ 1259 | Version | Description | Reference | 1260 +---------+--------------------------------------+-------------+ 1261 | 0 | Reserved by this document | [This-RFC] | 1262 | 1 | Assigned by this document | [This-RFC] | 1263 +---------+--------------------------------------+-------------+ 1265 8.2.2. Convert TLVs 1267 IANA is requested to create the "Convert TLVs" sub-registry. The 1268 procedure for assigning values from this registry is as follows: 1270 o The values in the range 1-127 can be assigned via Standards 1271 Action. 1273 o The values in the range 128-191 can be assigned via Specification 1274 Required. 1276 o The values in the range 192-255 can be assigned for Private Use. 1278 The initial values to be assigned at the creation of the registry are 1279 as follows: 1281 +---------+--------------------------------------+-------------+ 1282 | Code | Name | Reference | 1283 +---------+--------------------------------------+-------------+ 1284 | 0 | Reserved | [This-RFC] | 1285 | 1 | Bootstrap TLV | [This-RFC] | 1286 | 10 | Connect TLV | [This-RFC] | 1287 | 20 | Extended TCP Header TLV | [This-RFC] | 1288 | 22 | Supported TCP Extension Services TLV | [This-RFC] | 1289 | 30 | Error TLV | [This-RFC] | 1290 +---------+--------------------------------------+-------------+ 1292 8.2.3. Convert Error Messages 1294 IANA is requested to create the "Convert Errors" sub-registry. Codes 1295 in this registry are assigned as a function of the error type. Four 1296 types are defined; the following ranges are reserved for each of 1297 these types: 1299 o Message validation and processing errors: 0-31 1301 o Client-side errors: 32-63 1303 o Converter-side errors: 64-95 1305 o Errors caused by destination server: 96-127 1306 The procedure for assigning values from this sub-registry is as 1307 follows: 1309 o 0-191: Values in this range are assigned via Standards Action. 1311 o 192-255: Values in this range are assigned via Specification 1312 Required. 1314 The initial values to be assigned at the creation of the registry are 1315 as follows: 1317 +-------+------+-----------------------------------+-----------+ 1318 | Error | Hex | Description | Reference | 1319 +-------+------+-----------------------------------+-----------+ 1320 | 0 | 0x00 | Unsupported Version | [This-RFC]| 1321 | 1 | 0x01 | Malformed Message | [This-RFC]| 1322 | 2 | 0x02 | Unsupported Message | [This-RFC]| 1323 | 32 | 0x20 | Not Authorized | [This-RFC]| 1324 | 33 | 0x21 | Unsupported TCP Option | [This-RFC]| 1325 | 64 | 0x40 | Resource Exceeded | [This-RFC]| 1326 | 65 | 0x41 | Network Failure | [This-RFC]| 1327 | 96 | 0x60 | Connection Reset | [This-RFC]| 1328 | 97 | 0x61 | Destination Unreachable | [This-RFC]| 1329 +-------+------+-----------------------------------+-----------+ 1331 Figure 19: The Convert Error Codes 1333 9. Acknowledgements 1335 Although they could disagree with the contents of the document, we 1336 would like to thank Joe Touch and Juliusz Chroboczek whose comments 1337 on the MPTCP mailing list have forced us to reconsider the design of 1338 the solution several times. 1340 We would like to thank Raphael Bauduin, Stefano Secci, Benjamin 1341 Hesmans and Anandatirtha Nandugudi for their help in preparing this 1342 document. Nandini Ganesh provided valuable feedback about the 1343 handling of TFO and the error codes. Thanks to them. 1345 This document builds upon earlier documents that proposed various 1346 forms of Multipath TCP proxies [I-D.boucadair-mptcp-plain-mode], 1347 [I-D.peirens-mptcp-transparent] and [HotMiddlebox13b]. 1349 From [I-D.boucadair-mptcp-plain-mode]: 1351 Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi 1352 Nishida, and Christoph Paasch for their valuable comments. 1354 Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and 1355 Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos 1356 Aires). 1358 Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and 1359 Xavier Grall for their inputs. 1361 Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas 1362 Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves 1363 Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun 1364 Srinivasan, and Raghavendra Mallya for the discussion. 1366 9.1. Contributors 1368 Bart Peirens contributed to an early version of the document. 1370 As noted above, this document builds on two previous documents. 1372 The authors of [I-D.boucadair-mptcp-plain-mode] were: 1374 o Mohamed Boucadair 1376 o Christian Jacquenet 1378 o Olivier Bonaventure 1380 o Denis Behaghel 1382 o Stefano Secci 1384 o Wim Henderickx 1386 o Robert Skog 1388 o Suresh Vinapamula 1390 o SungHoon Seo 1392 o Wouter Cloetens 1394 o Ullrich Meyer 1396 o Luis M. Contreras 1398 o Bart Peirens 1400 The authors of [I-D.peirens-mptcp-transparent] were: 1402 o Bart Peirens 1404 o Gregory Detal 1406 o Sebastien Barre 1408 o Olivier Bonaventure 1410 10. Change Log 1412 This section to be removed before publication. 1414 o 00 : initial version, designed to support Multipath TCP and TFO 1415 only 1417 o 00 to -01 : added section Section 5 describing the support of 1418 different standard tracks TCP options by Transport Converters, 1419 clarification of the IANA section, moved the SOCKS comparison to 1420 the appendix and various minor modifications 1422 o 01 to -02 : Minor modifications 1424 o 02 to -03 : Minor modifications 1426 11. References 1428 11.1. Normative References 1430 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1431 RFC 793, DOI 10.17487/RFC0793, September 1981, 1432 . 1434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1435 Requirement Levels", BCP 14, RFC 2119, 1436 DOI 10.17487/RFC2119, March 1997, . 1439 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1440 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1441 2006, . 1443 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1444 ICMPv6, UDP, and TCP Headers", RFC 4727, 1445 DOI 10.17487/RFC4727, November 2006, . 1448 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1449 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1450 . 1452 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 1453 RFC 5482, DOI 10.17487/RFC5482, March 2009, 1454 . 1456 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1457 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1458 June 2010, . 1460 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1461 "TCP Extensions for Multipath Operation with Multiple 1462 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1463 . 1465 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1466 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1467 . 1469 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1470 Writing an IANA Considerations Section in RFCs", BCP 26, 1471 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1472 . 1474 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1475 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1476 May 2017, . 1478 11.2. Informative References 1480 [ANRW17] Trammell, B., Kuhlewind, M., De Vaere, P., Learmonth, I., 1481 and G. Fairhurst, "Tracking transport-layer evolution with 1482 PATHspider", Applied Networking Research Workshop 2017 1483 (ANRW17) , July 2017. 1485 [Fukuda2011] 1486 Fukuda, K., "An Analysis of Longitudinal TCP Passive 1487 Measurements (Short Paper)", Traffic Monitoring and 1488 Analysis. TMA 2011. Lecture Notes in Computer Science, vol 1489 6613. , 2011. 1491 [HotMiddlebox13b] 1492 Detal, G., Paasch, C., and O. Bonaventure, "Multipath in 1493 the Middle(Box)", HotMiddlebox'13 , December 2013, 1494 . 1497 [I-D.arkko-arch-low-latency] 1498 Arkko, J. and J. Tantsura, "Low Latency Applications and 1499 the Internet Architecture", draft-arkko-arch-low- 1500 latency-02 (work in progress), October 2017. 1502 [I-D.boucadair-mptcp-plain-mode] 1503 Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, 1504 D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 1505 Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., 1506 Contreras, L., and B. Peirens, "Extensions for Network- 1507 Assisted MPTCP Deployment Models", draft-boucadair-mptcp- 1508 plain-mode-10 (work in progress), March 2017. 1510 [I-D.boucadair-radext-tcpm-converter] 1511 Boucadair, M. and C. Jacquenet, "RADIUS Extensions for 1512 0-RTT TCP Converters", draft-boucadair-radext-tcpm- 1513 converter-00 (work in progress), April 2018. 1515 [I-D.boucadair-tcpm-dhc-converter] 1516 Boucadair, M., Jacquenet, C., and R. K, "DHCP Options for 1517 0-RTT TCP Converters", draft-boucadair-tcpm-dhc- 1518 converter-00 (work in progress), April 2018. 1520 [I-D.ietf-mptcp-rfc6824bis] 1521 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1522 Paasch, "TCP Extensions for Multipath Operation with 1523 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-12 (work 1524 in progress), October 2018. 1526 [I-D.ietf-tcpinc-tcpcrypt] 1527 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1528 Q., and E. Smith, "Cryptographic protection of TCP Streams 1529 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-13 (work in 1530 progress), September 2018. 1532 [I-D.olteanu-intarea-socks-6] 1533 Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6", 1534 draft-olteanu-intarea-socks-6-04 (work in progress), 1535 August 2018. 1537 [I-D.peirens-mptcp-transparent] 1538 Peirens, B., Detal, G., Barre, S., and O. Bonaventure, 1539 "Link bonding with transparent Multipath TCP", draft- 1540 peirens-mptcp-transparent-00 (work in progress), July 1541 2016. 1543 [IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment", 1544 IETF Journal, Fall 2016 , n.d.. 1546 [IMC11] Honda, K., Nishida, Y., Raiciu, C., Greenhalgh, A., 1547 Handley, M., and T. Hideyuki, "Is it still possible to 1548 extend TCP ?", Proceedings of the 2011 ACM SIGCOMM 1549 conference on Internet measurement conference , 2011. 1551 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 1552 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1553 1992, . 1555 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1556 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1557 . 1559 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 1560 RFC 1919, DOI 10.17487/RFC1919, March 1996, 1561 . 1563 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1564 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1565 DOI 10.17487/RFC1928, March 1996, . 1568 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1569 Selective Acknowledgment Options", RFC 2018, 1570 DOI 10.17487/RFC2018, October 1996, . 1573 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1574 Defeating Denial of Service Attacks which employ IP Source 1575 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1576 May 2000, . 1578 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1579 Shelby, "Performance Enhancing Proxies Intended to 1580 Mitigate Link-Related Degradations", RFC 3135, 1581 DOI 10.17487/RFC3135, June 2001, . 1584 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 1585 Multipath Operation with Multiple Addresses", RFC 6181, 1586 DOI 10.17487/RFC6181, March 2011, . 1589 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1590 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 1591 2012, . 1593 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1594 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1595 DOI 10.17487/RFC6887, April 2013, . 1598 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1599 "Increasing TCP's Initial Window", RFC 6928, 1600 DOI 10.17487/RFC6928, April 2013, . 1603 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1604 Traversal", RFC 6978, DOI 10.17487/RFC6978, July 2013, 1605 . 1607 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 1608 Scheffenegger, Ed., "TCP Extensions for High Performance", 1609 RFC 7323, DOI 10.17487/RFC7323, September 2014, 1610 . 1612 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1613 Zimmermann, "A Roadmap for Transmission Control Protocol 1614 (TCP) Specification Documents", RFC 7414, 1615 DOI 10.17487/RFC7414, February 2015, . 1618 Appendix A. Differences with SOCKSv5 1620 The description above is a simplified description of the Converter 1621 protocol. At a first glance, the proposed solution could seem 1622 similar to the SOCKS v5 protocol [RFC1928]. This protocol is used to 1623 proxy TCP connections. The Client creates a connection to a SOCKS 1624 proxy, exchanges authentication information and indicates the 1625 destination address and port of the final server. At this point, the 1626 SOCKS proxy creates a connection towards the final server and relays 1627 all data between the two proxied connections. The operation of an 1628 implementation based on SOCKSv5 is illustrated in Figure 20. 1630 Client SOCKS Proxy Server 1631 --------------------> 1632 SYN 1633 <-------------------- 1634 SYN+ACK 1635 --------------------> 1636 ACK 1638 --------------------> 1639 Version=5, Auth Methods 1640 <-------------------- 1641 Method 1642 --------------------> 1643 Auth Request (unless "No auth" method negotiated) 1644 <-------------------- 1645 Auth Response 1646 --------------------> 1647 Connect Server:Port --------------------> 1648 SYN 1650 <-------------------- 1651 SYN+ACK 1652 <-------------------- 1653 Succeeded 1655 --------------------> 1656 Data1 1657 --------------------> 1658 Data1 1660 <-------------------- 1661 Data2 1662 <-------------------- 1663 Data2 1665 Figure 20: Establishment of a TCP connection through a SOCKS proxy 1666 without authentication 1668 The Converter protocol also relays data between an upstream and a 1669 downstream connection, but there are important differences with 1670 SOCKSv5. 1672 A first difference is that the Converter protocol leverages the TFO 1673 option [RFC7413] to exchange all control information during the 1674 three-way handshake. This reduces the connection establishment delay 1675 compared to SOCKS that requires two or more round-trip-times before 1676 the establishment of the downstream connection towards the final 1677 destination. In today's Internet, latency is a important metric and 1678 various protocols have been tuned to reduce their latency 1679 [I-D.arkko-arch-low-latency]. A recently proposed extension to SOCKS 1680 also leverages the TFO option [I-D.olteanu-intarea-socks-6]. 1682 A second difference is that the Converter protocol explicitly takes 1683 the TCP extensions into account. By using the Converter protocol, 1684 the Client can learn whether a given TCP extension is supported by 1685 the destination Server. This enables the Client to bypass the 1686 Transport Converter when the destination supports the required TCP 1687 extension. Neither SOCKS v5 [RFC1928] nor the proposed SOCKS v6 1688 [I-D.olteanu-intarea-socks-6] provide such a feature. 1690 A third difference is that a Transport Converter will only accept the 1691 connection initiated by the Client provided that the downstream 1692 connection is accepted by the Server. If the Server refuses the 1693 connection establishment attempt from the Transport Converter, then 1694 the upstream connection from the Client is rejected as well. This 1695 feature is important for applications that check the availability of 1696 a Server or use the time to connect as a hint on the selection of a 1697 Server [RFC6555]. 1699 Authors' Addresses 1701 Olivier Bonaventure (editor) 1702 Tessares 1704 Email: Olivier.Bonaventure@tessares.net 1706 Mohamed Boucadair (editor) 1707 Orange 1709 Email: mohamed.boucadair@orange.com 1711 Sri Gundavelli 1712 Cisco 1714 Email: sgundave@cisco.com 1716 SungHoon Seo 1717 Korea Telecom 1719 Email: sh.seo@kt.com