idnits 2.17.1 draft-ietf-tcpm-converters-01.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 (March 05, 2018) is 2215 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'This-RFC' is mentioned on line 1277, but not defined == Missing Reference: 'Bootstrap' is mentioned on line 411, 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 (-18) exists of draft-ietf-mptcp-rfc6824bis-10 == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-11 == Outdated reference: A later version (-11) exists of draft-olteanu-intarea-socks-6-01 -- 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 (~~), 6 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: September 6, 2018 Orange 6 B. Peirens 7 Proximus 8 S. Seo 9 Korea Telecom 10 A. Nandugudi 11 Memphis University 12 March 05, 2018 14 0-RTT TCP Convert Protocol 15 draft-ietf-tcpm-converters-01 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). 23 This specification assumes an explicit model, where the proxy is 24 explicitly configured on hosts. 26 -- Editorial Note (To be removed by RFC Editor) 28 Please update these statements with the RFC number to be assigned to 29 this document: 30 [This-RFC] 32 Please update TBA statements with the port number to be assigned to 33 the Converter 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 September 6, 2018. 51 Copyright Notice 53 Copyright (c) 2018 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 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 5 72 3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 7 73 3.3. Sample Examples of Outgoing Converter-Assisted Multipath 74 TCP Connections . . . . . . . . . . . . . . . . . . . . . 10 75 3.4. Sample Example of Incoming Converter-Assisted Multipath 76 TCP Connection . . . . . . . . . . . . . . . . . . . . . 11 77 4. The Converter Protocol (Convert) . . . . . . . . . . . . . . 12 78 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 12 79 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 13 80 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 13 81 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 14 82 4.2.3. The Bootstrap TLV . . . . . . . . . . . . . . . . . . 15 83 4.2.4. Supported TCP Extension Services TLV . . . . . . . . 15 84 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 16 85 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 17 86 4.2.7. Error TLV . . . . . . . . . . . . . . . . . . . . . . 18 87 5. Compatibility of Specific TCP Options with the Conversion 88 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 21 90 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 21 91 5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 22 92 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 22 93 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 23 94 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 23 95 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 23 96 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 24 98 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 24 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 100 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 25 101 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 25 102 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 25 103 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 26 104 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 26 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 106 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 27 107 8.2. The Converter Protocol (Convert) Parameters . . . . . . . 27 108 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 27 109 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 28 110 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 28 111 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 112 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 30 113 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 30 114 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 115 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 116 11.2. Informative References . . . . . . . . . . . . . . . . . 31 117 Appendix A. Differences with SOCKSv5 . . . . . . . . . . . . . . 34 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 120 1. Introduction 122 Transport protocols like TCP evolve regularly [RFC7414]. TCP has 123 been improved in different ways. Some improvements such as changing 124 the initial window size [RFC6928] or modifying the congestion control 125 scheme can be applied independently on clients and servers. Other 126 improvements such as Selective Acknowledgements [RFC2018] or large 127 windows [RFC7323] require a new TCP option or to change the semantics 128 of some fields in the TCP header. These modifications must be 129 deployed on both clients and servers to be actually used on the 130 Internet. Experience with the latter TCP extensions reveals that 131 their deployment can require many years. [Fukuda2011] reports 132 results of a decade of measurements showing the deployment of 133 Selective Acknowledgements, Window Scale and TCP Timestamps. 134 [ANRW17] describes measurements showing that TCP Fast Open [RFC7413] 135 (TFO) is still not widely deployed. 137 There are some situations where the transport stack used on clients 138 (resp. servers) can be upgraded at a faster pace than the transport 139 stack running on servers (resp. clients). In those situations, 140 clients would typically want to benefit from the features of an 141 improved transport protocol even if the servers have not yet been 142 upgraded and conversely. In the past, Performance Enhancing Proxies 143 have been proposed and deployed [RFC3135] as solutions to improve TCP 144 performance over links with specific characteristics. 146 Recent examples of TCP extensions include Multipath TCP 147 [RFC6824][I-D.ietf-mptcp-rfc6824bis] or TCPINC 148 [I-D.ietf-tcpinc-tcpcrypt]. Those extensions provide features that 149 are interesting for clients such as wireless devices. With Multipath 150 TCP, those devices could seamlessly use WLAN and cellular networks, 151 for bonding purposes, faster handovers, or better resiliency. 152 Unfortunately, deploying those extensions on both a wide range of 153 clients and servers remains difficult. 155 More recently, experimentation of 5G bonding, which has very scarce 156 coverage, has been conducted into global range of the incumbent 4G 157 (LTE) connectivity in newly devised clients using Multipath TCP 158 proxy. Even if the 5G and the 4G bonding by using Multipath TCP 159 increases the bandwidth to data transfer, it is as well crucial to 160 minimize latency for all the way between endhosts regardless of 161 whether intermediate nodes are inside or ouside of the mobile core. 162 In order to handle uRLLC (Ultra-Reliable Low-Latency Communication) 163 for the next generation mobile network, Multipath TCP and its proxy 164 mechanism must be optimized to reduce latency. 166 This document specifies an application proxy, called Transport 167 Converter. A Transport Converter is a function that is installed by 168 a network operator to aid the deployment of TCP extensions and to 169 provide the benefits of such extensions to clients. A Transport 170 Converter may support conversion service for one or more TCP 171 extensions. This service is provided by means of the Converter 172 Protocol (Convert), that is an application layer protocol which uses 173 TBA TCP port number (Section 8). 175 The Transport Converter adheres to the main principles as drawn in 176 [RFC1919]. In particular, the Converter achieves the following: 178 o Listen for client sessions; 180 o Receive from a client the address of the final target server; 182 o Setup a session to the final server; 184 o Relay control messages and data between the client and the server; 186 o Perform access controls according to local policies. 188 The main advantage of network-assisted Converters is that they enable 189 new TCP extensions to be used on a subset of the end-to-end path, 190 which encourages the deployment of these extensions. The Transport 191 Converter allows the client and the server to directly negotiate TCP 192 options. 194 The Convert Protocol is a generic mechanism to provide 0-RTT 195 conversion service. As a sample applicability use case, this 196 document specifies how the Convert Protocol applies for Multiptah 197 TCP. It is out of scope of this document to provide a comprehensive 198 list of potential all conversion services; separate documents may be 199 edited in the future for other conversion services upon need. 201 This document does not assume that all the traffic is eligible to the 202 network-assisted conversion service. Only a subset of the traffic 203 will be forwarded to a Converter according to a set of policies. 204 Furthermore, it is possible to bypass the Converter to connect to the 205 servers that already support the required TCP extension. 207 This document assumes that a client is configured with one or a list 208 of Converters. Configuration means are outside the scope of this 209 document. 211 This document is organized as follows. We first provide a brief 212 explanation of the operation of Transport Converters in Section 3. 213 We describe the Converter Protocol in Section 4. We discuss in 214 Section 5 how Transport Converters can be used to support different 215 TCP options. We then discuss the interactions with middleboxes 216 (Section 6) and the security considerations (Section 7). 218 Appendix A provides a comparison with SOCKS proxies that are already 219 used to deploy Multipath TCP in some cellular networks. 221 2. Requirements 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in 226 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 227 as shown here. 229 3. Architecture 231 3.1. Functional Elements 233 The architecture considers three types of endhosts: 235 o Client endhosts; 237 o Transport Converters; 239 o Server endhosts. 241 A Transport Converter is a network function that relays all data 242 exchanged over one upstream connection to one downstream connection 243 and vice versa (Figure 1). The Converter, thus, maintains state that 244 associates one upstream connection to a corresponding downstream 245 connection. 247 A connection can be initiated from both sides of the Transport 248 Converter (Internet-facing interface, client-facing interface). 250 +------------+ 251 <--- upstream --->| Transport |<--- downstream ---> 252 | Converter | 253 +------------+ 255 Figure 1: A Transport Converter relays data between pairs of TCP 256 connections 258 Transport Converters can be operated by network operators or third 259 parties. Nevertheless, this document focuses on the single 260 administrative deployment case where the entity offering the 261 connectivity service to a client is also the entity which owns and 262 operates the Transport Converter. 264 A Transport Converter can be embedded in a standalone device or be 265 activated as a service on a router. How such function is enabled is 266 deployment-specific (Figure 2). 268 +-+ +-+ +-+ 269 Client - |R| -- |R| -- |R| - - - Server 270 +-+ +-+ +-+ 271 | 272 Transport 273 Converter 275 Figure 2: A Transport Converter can be installed anywhere in the 276 network 278 The architecture assumes that new software will be installed on the 279 Client hosts and on Transport Converters. Further, the architecture 280 allows for making use of TCP new extensions if those are supported by 281 a given server. 283 The Client is configured, through means that are outside the scope of 284 this document, with the names and/or the addresses of one or more 285 Transport Converters. 287 The architecture does not mandate anything on the server side. 289 One of the benefits of this design is that different transport 290 protocol extensions can be used on the upstream and the downstream 291 connections. This encourages the deployment of new TCP extensions 292 until they are widely supported by servers. 294 3.2. Theory of Operation 296 At a high level, the objective of the Transport Converter is to allow 297 the Client to use a specific extension, e.g. Multipath TCP, on a 298 subset of the end-to-end path even if the Server does not support 299 this extension. This is illustrated in Figure 3 where the Client 300 initiates a Multipath TCP connection with the Converter (Multipath 301 packets are shown with "===") while the Converter uses a regular TCP 302 connection with the Server. 304 The packets belonging to the pair of connections between the Client 305 and Server passing through a Transport Converter may follow a 306 different path than the packets directly exchanged between the Client 307 and the Server. Deployments should minimize the possible additional 308 delay by carefully selecting the location of the Transport Converter 309 used to reach a given destination. 311 Transport 312 Client Converter Server 313 ======================> 315 --------------------> 317 <-------------------- 319 <====================== 320 Multipath TCP packets Regular TCP packets 322 Figure 3: Different TCP variants can be used on the Client-Converter 323 path and on the Converter-Server path 325 When establishing a connection, the Client can, depending on local 326 policies, either contact the Server directly (e.g., by sending a TCP 327 SYN towards the Server) or create the connection via a Transport 328 Converter. In the latter case, which is the case we consider in this 329 document, the Client initiates a connection towards the Transport 330 Converter and indicates the IP address and port number of the 331 ultimate Server inside the connection establishment packet. Doing so 332 enables the Transport Converter to immediately initiate a connection 333 towards that Server, without experiencing an extra delay. The 334 Transport Converter waits until the confirmation that the Server 335 agrees to establish the connection before confirming it to the 336 Client. 338 The client places the destination address and port number of the 339 target Server in the payload of the SYN sent to the Converter by 340 leveraging TCP Fast Open [RFC7413]. In accordance with [RFC1919], 341 the Transport Converter maintains two connections that are combined 342 together: 344 o the upstream connection is the one between the Client and the 345 Transport Converter. 347 o the downstream connection is between the Transport Converter and 348 the remote Server. 350 Any user data received by the Transport Converter over the upstream 351 (resp., downstream) connection is relayed over the downstream (resp., 352 upstream) connection. 354 Figure 4 illustrates the establishment of a TCP connection by the 355 Client through a Transport Converter. The information shown between 356 brackets is part of the Converter Protocol described later in this 357 document. 359 Transport 360 Client Converter Server 361 --------------------> 362 SYN TFO [->Server:port] 364 --------------------> 365 SYN 367 <-------------------- 368 SYN+ACK 369 <-------------------- 370 SYN+ACK [ ] 372 Figure 4: Establishment of a TCP connection through a Converter 374 The Client sends a SYN destined to the Transport Converter. This SYN 375 contains a TFO cookie and inside its payload the addresses and ports 376 of the destination Server. The Transport Converter does not reply 377 immediately to this SYN. It first tries to create a TCP connection 378 towards the destination Server. If this second connection succeeds, 379 the Transport Converter confirms the establishment of 380 the connection to the Client by returning a SYN+ACK and the first 381 bytes of the bytestream contain information about the TCP options 382 that were negotiated with the final Server. This information is sent 383 at the beginning of the bytestream, either directly in the SYN+ACK or 384 in a subsequent packet. For graphical reasons, the figures in this 385 section show that the Converter returns this information in the 386 SYN+ACK packet. An implementation could also place this information 387 in a packet that it sent shortly after the SYN+ACK. 389 The connection can also be established from the Internet towards a 390 Client via a Transport Converter. This is typically the case when 391 the Client embeds a server (video server, for example). 393 The procedure described in Figure 4 assumes that the Client has 394 obtained a TFO cookie from the Transport Converter. This is part of 395 the Bootstrap procedure which is illustrated in Figure 5. The Client 396 sends a SYN with a TFO request option to obtain a valid cookie from 397 the Converter. The Converter replies with a TFO cookie in the 398 SYN+ACK. Once this connection has been established, the Client sends 399 a Bootstrap message to request the list of TCP options for which the 400 Transport Converter provides a conversion service. 402 Transport 403 Client Converter Server 404 --------------------> 405 SYN TFO(empty) 407 <-------------------- 408 SYN+ACK TFO(cookie) 410 --------------------> 411 [Bootstrap] 413 <-------------------- 414 [Supported TCP Extension Services] 416 Figure 5: Bootstrapping a Client connection to a Transport Converter 418 Note that the Converter may rely on local policies to decide whether 419 it can service a given requesting Client. That is, the Converter 420 will not return a cookie for that Client. How such policies are 421 supplied to the Converter are out of scope. 423 Also, the Converter may behave in a cookie-less mode when appropriate 424 means are enforced at the Converter and the network in-between to 425 protect against attacks such as spoofing and SYN flood. Under such 426 deployments, the use of TFO is not required. 428 3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP 429 Connections 431 As an example (Figure 6), let us consider how the Convert protocol 432 can help the deployment of Multipath TCP [RFC6824]. We assume that 433 both the Client and the Transport Converter support Multipath TCP, 434 but consider two different cases depending whether the Server 435 supports Multipath TCP or not. A Multipath TCP connection is created 436 by placing the MP_CAPABLE (MPC) option in the SYN sent by the Client. 438 Figure 6 describes the operation of the Transport Converter if the 439 Server does not support Multipath TCP. 441 Transport 442 Client Converter Server 443 --------------------> 444 SYN, MPC [->Server:port] 446 --------------------> 447 SYN, MPC 449 <-------------------- 450 SYN+ACK 451 <-------------------- 452 SYN+ACK,MPC [ ] 454 --------------------> 455 ACK,MPC 456 --------------------> 457 ACK 459 Figure 6: Establishment of a Multipath TCP connection through a 460 Converter 462 The Client tries to initiate a Multipath TCP connection by sending a 463 SYN with the MP_CAPABLE option (MPC in Figure 6). The SYN includes 464 the address and port number of the final Server and the Transport 465 Converter attempts to initiate a Multipath TCP connection towards 466 this Server. Since the Server does not support Multipath TCP, it 467 replies with a SYN+ACK that does not contain the MP_CAPABLE option. 468 The Transport Converter notes that the connection with the Server 469 does not support Multipath TCP and returns the TCP options received 470 from the Server to the Client. 472 Figure 7 considers a Server that supports Multipath TCP. In this 473 case, it replies to the SYN sent by the Transport Converter with the 474 MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport 475 Converter confirms the establishment of the connection to the Client 476 and indicates to the Client that the Server supports Multipath TCP. 477 With this information, the Client has discovered that the Server 478 supports Multipath TCP natively. This will enable it to bypass the 479 Transport Converter for the next Multipath TCP connection that it 480 will initiate towards this Server. 482 Transport 483 Client Converter Server 484 --------------------> 485 SYN, MPC [->Server:port] 487 --------------------> 488 SYN, MPC 490 <-------------------- 491 SYN+ACK, MPC 492 <-------------------- 493 SYN+ACK, MPC [ MPC supported ] 495 --------------------> 496 ACK, MPC 497 --------------------> 498 ACK, MPC 500 Figure 7: Establishment of a Multipath TCP connection through a 501 converter 503 3.4. Sample Example of Incoming Converter-Assisted Multipath TCP 504 Connection 506 An example of an incoming Converter-assisted Multipath TCP connection 507 is depicted in Figure 8. In order to support incoming connections 508 from remote hosts, the Client may use PCP [RFC6887] to instruct the 509 Converter to create dynamic mappings. Those mappings will be used by 510 the Converter to intercept an incoming TCP connection destined to the 511 Client and convert it into a Multipath TCP connection. 513 Transport 514 Client Converter Remote Host 515 <------------------- 516 SYN 518 <------------------- 519 SYN, MPC[Remote Host:port] 521 ---------------------> 522 SYN+ACK, MPC 523 ---------------------> 524 SYN+ACK 526 <--------------------- 527 ACK 528 <------------------- 529 ACK, MPC 531 Figure 8: Establishment of an Incoming TCP Connection through a 532 Converter 534 4. The Converter Protocol (Convert) 536 This section describes in details the messages that are exchanged 537 between a Client and a Transport Converter. The Converter Protocol 538 (Convert, for short) leverages the TCP Fast Open extension [RFC7413]. 540 The Converter Protocol uses a 32 bits long fixed header that is sent 541 by both the Client and the Transport Converter. This header 542 indicates both the version of the protocol used and the length of the 543 Convert message. 545 4.1. The Convert Fixed Header 547 The Fixed Header is used to exchange information about the version 548 and length of the messages between the Client and the Transport 549 Converter. 551 The Client and the Transport Converter MUST send the fixed-sized 552 header shown in Figure 9 as the first four bytes of the bytestream. 554 1 2 3 555 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 556 +---------------+---------------+-------------------------------+ 557 | Version | Total Length | Unassigned | 558 +---------------+---------------+-------------------------------+ 560 Figure 9: The fixed-sized header of the Converter protocol 562 The Version is encoded as an 8 bits unsigned integer value. This 563 document specifies version 1. Version 0 is reserved by this document 564 and MUST NOT be used. 566 The Total Length is the number of 32 bits word, including the header, 567 of the bytestream that are consumed by the Converter protocol 568 messages. Since Total Length is also an 8 bits unsigned integer, 569 those messages cannot consume more than 1020 bytes of data. This 570 limits the number of bytes that a Transport Converter needs to 571 process. A Total Length of zero is invalid and the connection MUST 572 be reset upon reception of such a header. 574 The Unassigned field MUST be set to zero in this version of the 575 protocol. These bits are available for future use [RFC8126]. 577 4.2. Convert TLVs 579 4.2.1. Generic Convert TLV Format 581 The Convert protocol uses variable length messages that are encoded 582 using the generic TLV format depicted in Figure 10. All TLV fields 583 are encoded using the network byte order. 585 1 2 3 586 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 587 +---------------+---------------+-------------------------------+ 588 | Type | Length | (optional) Value ... | 589 +---------------+---------------+-------------------------------+ 590 | ... (optional) Value | 591 +---------------------------------------------------------------+ 593 Figure 10: Converter Generic TLV Format 595 A given TLV MUST only appear once on a connection. If two or more 596 instances of the same TLV are exchanged over a Converter connection, 597 the associated TCP connections MUST be closed. 599 4.2.2. Summary of Supported Convert TLVs 601 This document specifies the following Convert TLVs: 603 +------+-----+----------+------------------------------------------+ 604 | Type | Hex | Length | Description | 605 +------+-----+----------+------------------------------------------+ 606 | 1 | 0x1 | 1 | Bootstrap TLV | 607 | 10 | 0xA | Variable| Connect TLV | 608 | 20 | 0x14| Variable| Extended TCP Header TLV | 609 | 21 | 0x15| Variable| Supported TCP Extension Services TLV | 610 | 30 | 0x1E| Variable| Error TLV | 611 +------+-----+----------+------------------------------------------+ 613 Figure 11: The TLVs used by the Converter protocol 615 To establish a connection via a Transport Converter, a Client MUST 616 first obtain a valid TFO cookie from that Converter. This is the 617 bootstrap procedure during which the Client opens a connection to the 618 Transport Converter with an empty TFO option. According to 619 [RFC7413], the Transport Converter returns its cookie in the SYN+ACK. 620 Then the Client sends a Bootstrap TLV (Section 4.2.3) to which the 621 Transport Converter replies with the Supported TCP Extension Services 622 TLV described in Section 4.2.4. 624 With the TFO cookie of the Transport Converter, the Client can 625 request the establishment of connections to remote servers with the 626 Connect TLV (see Section 4.2.5). If the connection can be 627 established with the final server, the Transport Converter replies 628 with the Extended TCP Header TLV and returns an Error TLV inside a 629 RST packet (see Section 4.2.7). 631 When the Transport Converter receives an incoming connection 632 establishment from a Client, it MUST process the TCP options found in 633 the SYN and the Connect TLV. In general, the Transport Converter 634 MUST add to the proxied SYN the TCP options that were included in the 635 Connect TLV. It SHOULD add to the proxied SYN the TCP options that 636 were included in the incoming SYN provided that it supports the 637 corresponding TCP extension. 639 There are some exceptions to these rules given the semantics of some 640 TCP options. First, TCP options with Kinds 0 (EOL), 1 (NOP), 2 641 (MSS), and 3 (WS) MUST be used according to the configuration of the 642 TCP stack of the Transport Converter. The Timestamps option 643 (Kind=10) SHOULD be used in the proxied SYN if it was present in the 644 incoming SYN, but the contents of the option in the proxied SYN 645 SHOULD be set by the Converter's stack. The MP_CAPABLE option SHOULD 646 be added to the proxied SYN if it was present in the incoming SYN, 647 but the content of the option in the proxied SYN SHOULD be set by the 648 Converter's stack. The TCP Fast Open cookie option SHOULD be handled 649 as described in Section 6. 651 As a general rule, when an error is encountered an Error TLV with the 652 appropriate error code MUST be returned. 654 4.2.3. The Bootstrap TLV 656 The Bootstrap TLV (Figure 12 is sent by a Client to request the TCP 657 extensions that are supported by a Transport Converter and for which 658 it provides a conversion service. It is typically sent on the first 659 connection that a Client establishes with a Transport Converter to 660 learn its capabilities. Assuming a Client is entitled to invoke the 661 Converter, this latter replies with the Supported TCP Extensions 662 Services TLV described in Section 4.2.4. 664 1 2 3 665 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 666 +---------------+---------------+-------------------------------+ 667 | Type | Length | Zero | 668 +---------------+---------------+-------------------------------+ 670 Figure 12: The Bootstrap TLV 672 4.2.4. Supported TCP Extension Services TLV 674 The Supported TCP Extension Services TLV (Figure 13) is used by a 675 Converter to announce the TCP options for which it provides a 676 conversion service. Each supported TCP option is encoded with its 677 TCP option Kind listed in the "TCP Parameters" registry maintained by 678 IANA. 680 1 2 3 681 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 682 +---------------+---------------+-------------------------------+ 683 | Type | Length | Unassigned | 684 +---------------+---------------+-------------------------------+ 685 | Kind #1 | Kind #2 | ... | 686 +---------------+---------------+-------------------------------+ 687 / ... / 688 / / 689 +---------------------------------------------------------------+ 691 Figure 13: The Supported TCP Extension Services TLV 693 TCP option Kinds 0, 1, and 2 defined in [RFC0793] are supported by 694 all TCP implementations and thus MUST NOT appear in this list. 696 The list of Supported TCP Extension Services is padded with 0 to end 697 on a 32 bits boundary. 699 Typically, if the Converter only supports Multipath TCP conversion 700 service, solely Kind=30 will be present in the Supported TCP 701 Extension Services TLV returned by the Converter to a requesting 702 Client. 704 4.2.5. Connect TLV 706 The Connect TLV (Figure 14) is used to request the establishment of a 707 connection via a Transport Converter. 709 The 'Remote Peer Port' and 'Remote Peer IP Address' fields contain 710 the destination port and IP address of the target server for an 711 outgoing connection towards a server located on the Internet. For 712 incoming connections destined to a client serviced via a Converter, 713 these fields convey the source port and IP address. 715 The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 716 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format 717 defined in [RFC4291]. 719 The optional 'TCP Options' field is used to specify how specific TCP 720 Options should be advertised by the Transport Converter to the final 721 destination of a connection. If this field is not supplied, the 722 Transport Converter MUST use the default TCP options that correspond 723 to its local policy. 725 1 2 3 726 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 727 +---------------+---------------+-------------------------------+ 728 | Type | Length | Remote Peer Port | 729 +---------------+---------------+-------------------------------+ 730 | | 731 | Remote Peer IP Address (128 bits) | 732 | | 733 | | 734 +---------------------------------------------------------------+ 735 | TCP Options (Variable) | 736 | ... | 737 +---------------------------------------------------------------+ 739 Figure 14: The Connect TLV 741 The 'TCP Options' field is a variable length field that carries a 742 list of TCP option fields (Figure 15). Each TCP option field is 743 encoded as a block of 2+n bytes where the first byte is the TCP 744 option Type and the second byte is the length of the TCP option as 745 specified in [RFC0793]. The minimum value for the TCP option Length 746 is 2. The TCP options that do not include a length subfield, i.e., 747 option types 0 (EOL) and 1 (NOP) defined in [RFC0793] cannot be 748 placed inside the TCP options field of the Connect TLV. The optional 749 Value field contains the variable-length part of the TCP option. A 750 length of two indicates the absence of the Value field. The TCP 751 options field always ends on a 32 bits boundary after being padded 752 with zeros. 754 1 2 3 755 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 756 +---------------+---------------+---------------+---------------+ 757 | TCPOpt type | TCPOpt Length | Value (opt) | .... | 758 +---------------+---------------+---------------+---------------+ 759 | .... | 760 +---------------------------------------------------------------+ 761 | ... | 762 +---------------------------------------------------------------+ 764 Figure 15: The TCP Options field 766 If a Transport Converter receives a Connect TLV with a non-empty TCP 767 options field, and the Converter accets to process the request, it 768 SHALL present those options to the destination peer in addition to 769 the TCP options that it would have used according to its local 770 policies. For the TCP options that are listed without an optional 771 value, the Converter MUST generate its own value. For the TCP 772 options that are included in the 'TCP Options' field with an optional 773 value, it SHALL copy the entire option for use in the connection with 774 the destination peer. This feature is required to support TCP Fast 775 Open. 777 The Converter may discard a Connect TLV request for many reasons 778 (e.g., bad TFO cookie, authorization failed, out of resources). An 779 error message indicating the encountered error is returned to the 780 requesting Client Section 4.2.7. In order to prevent denial-of- 781 service attacks, error messages sent to a Client SHOULD be rate- 782 limited. 784 4.2.6. Extended TCP Header TLV 786 The Extended TCP Header TLV (Figure 16) is used by the Transport 787 Converter to send to the Client the extended TCP header that was 788 returned by the Server in the SYN+ACK packet. This TLV is only sent 789 if the Client sent a Connect TLV to request the establishment of a 790 connection. 792 1 2 3 793 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 794 +---------------+---------------+-------------------------------+ 795 | Type | Length | Unassigned | 796 +---------------+---------------+-------------------------------+ 797 | Returned Extended TCP header | 798 | ... | 799 +---------------------------------------------------------------+ 801 Figure 16: The Extended TCP Header TLV 803 The Returned Extended TCP header field is a copy of the extended 804 header that was received in the SYN+ACK by the Transport Converter. 806 The Unassigned field MUST be set to zero by the transmitter and 807 ignored by the receiver. These bits are available for future use 808 [RFC8126]. 810 4.2.7. Error TLV 812 The optional Error TLV (Figure 17) can be used by the Transport 813 Converter to provide information about some errors that occurred 814 during the processing of a request to convert a connection. This TLV 815 appears after the Convert header in a RST segment returned by the 816 Transport Converter if the error is fatal and prevented the 817 establishment of the connection. If the error is not fatal and the 818 connection could be established with the final destination, then the 819 error TLV will be carried in the payload. 821 1 2 3 822 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 823 +---------------+---------------+----------------+--------------+ 824 | Type | Length | Error | Value | 825 +---------------+---------------+----------------+--------------+ 827 Figure 17: The Error TLV 829 Different types of errors can occur while processing Convert 830 messages. Each error is identified by a code represented as an 831 unsigned integer. Four classes of errors are defined: 833 o Message validation and processing errors (0-31 range): returned 834 upon reception of an an invalid message (including valid messages 835 but with invalid or unknown TLVs). 837 o Client-side errors (32-63 range): the Client sent a request that 838 could not be accepted by the Converter (e.g., unsupported 839 operation). 841 o Converter-side errors (64-95 range) : problems encountered on the 842 Converter (e.g., lack of resources) which prevent it from 843 fulfilling the Client's request. 845 o Errors caused by destination server (96-127 range) : the final 846 destination could not be reached or it replied with a reset 847 message. 849 The following error codes are defined in this document: 851 o Unsupported Version (0): The version number indicated in the fixed 852 header of a message received from a peer is not supported. 854 This error code MUST be generated by a Converter when it receives 855 a request having a version number that it does not support. 857 The value field MUST be set to the version supported by the 858 Converter. When multiple versions are supported by the Converter, 859 it includes the list of supported version in the value field; each 860 version is encoded in 8 bits. 862 Upon receipt of this error code, the client checks whether it 863 supports one of the versions returned by the Converter. The 864 highest common supported version MUST be used by the client in 865 subsequent exchanges with the Converter. 867 o Malformed Message (1): This error code is sent to indicate that a 868 message can not be successfully parsed. 870 To ease troubleshooting, the value field MUST echo the received 871 message. The Converter and the Client MUST send a RST containing 872 this error upon reception of a malformed message. 874 o Unsupported Message (2): This error code is sent to indicate that 875 a message type is not supported by the Converter. 877 To ease troubleshooting, the value field MUST echo the received 878 message. The Converter and the Client MUST send a RST containing 879 this error upon reception of an unsupported message. 881 o Not Authorized (32): This error code indicates that the Converter 882 refused to create a connection because of a lack of authorization 883 (e.g., administratively prohibited, authorization failure, etc.). 884 The Value field MUST be set to zero. 886 This error code MUST be sent by the Converter when a request 887 cannot be successfully processed because the authorization failed. 889 o Unsupported TCP Option (33): A TCP option that the Client 890 requested to advertise to the final Server cannot be safely used 891 jointly with the conversion service. 893 The Value field is set to the type of the unsupported TCP option. 894 If several unsupported TCP options were specified in the Connect 895 TLV, only one of them is returned in the Value. 897 o Resource Exceeded (64): This error indicates that the Transport 898 Converter does not have enough resources to perform the request. 900 This error MUST be sent by the Converter when it does not have 901 sufficient resources to handle a new connection. 903 o Network Failure (65): This error indicates that the Converter is 904 experiencing a network failure to relay the request. 906 The Converter MUST send this error code when it experiences 907 forwarding issues to relay a connection. 909 o Connection Reset (96): This error indicates that the final 910 destination responded with a RST packet. The Value field MUST be 911 set to zero. 913 o Destination Unreachable (97): This error indicates that an ICMP 914 destination unreachable, port unreachable, or network unreachable 915 was received by the Converter. The Value field MUST echo the Code 916 field of the received ICMP message. 918 This error message MUST be sent by the Converter when it receives 919 an error message that is bound to a message it relayed previously. 921 Figure 18 summarizes the different error codes. 923 +-------+------+-----------------------------------------------+ 924 | Error | Hex | Description | 925 +-------+------+-----------------------------------------------+ 926 | 0 | 0x00 | Unsupported Version | 927 | 1 | 0x01 | Malformed Message | 928 | 2 | 0x02 | Unsupported Message | 929 | 32 | 0x20 | Not Authorized | 930 | 33 | 0x21 | Unsupported TCP Option | 931 | 64 | 0x40 | Resource Exceeded | 932 | 65 | 0x41 | Network Failure | 933 | 96 | 0x60 | Connection Reset | 934 | 97 | 0x61 | Destination Unreachable | 935 +-------+------+-----------------------------------------------+ 937 Figure 18: Convert Error Values 939 5. Compatibility of Specific TCP Options with the Conversion Service 941 In this section, we discuss how several standard track TCP options 942 can be supported through the Converter. The non-standard track 943 options and the experimental options will be discussed in other 944 documents. 946 5.1. Base TCP Options 948 Three TCP options were initially defined in [RFC0793] : End-of-Option 949 List (Kind=0), No-Operation (Kind=1) and Maximum Segment Size 950 (Kind=2). The first two options are mainly used to pad the TCP 951 extended header. There is no reason for a client to request a 952 Converter to specifically send these options towards the final 953 destination. 955 The Maximum Segment Size option (Kind=2) is used by a host to 956 indicate the largest segment that it can receive over each 957 connection. This value is function of the stack that terminates the 958 TCP connection. There is no reason for a Client to request a 959 Converter to advertise a specific MSS value to a remote server. 961 A Converter MUST ignore options with Kind=0, 1 or 2 if they appear in 962 a Connect TLV. It MUST NOT announce them in a Bootstrap TLV. 964 5.2. Window Scale (WS) 966 The Window Scale option (Kind=3) is defined in [RFC7323]. As for the 967 MSS option, the window scale factor that is used for a connection 968 strongly depends on the TCP stack that handles the connection. When 969 a Converter opens a TCP connection towards a remote server on behalf 970 of a Client, it SHOULD use a WS option with a scaling factor that 971 corresponds to the configuration of its stack. A local configuration 972 MAY allow for WS option in the proxied message to be function of the 973 scaling factor of the incoming connection. 975 There is no benefit from a deployment viewpoint in enabling a Client 976 of a Converter to specifically request the utilisation of the WS 977 option (Kind=3) with a specific scaling factor towards a remote 978 Server. For this reason, a Converter MUST ignore option Kind=3 if it 979 appears in a Connect TLV. It MUST NOT announce it in a Bootstrap 980 TLV. 982 5.3. Selective Acknowledgements 984 Two distinct TCP options were defined to support selective 985 acknowledgements in [RFC2018]. This first one, SACK Permitted 986 (Kind=4), is used to negotiate the utilisation of selective 987 acknowledgements during the three-way handshake. The second one, 988 SACK (Kind=5), carries the selective acknowledgements inside regular 989 segments. 991 The SACK Permitted option (Kind=4) MAY be advertised by a Transport 992 Converter in the Bootstrap TLV. In this case, Clients connected to 993 this Transport Converter MAY include the SACK Permitted option in the 994 Connect TLV. 996 The SACK option (Kind=5) cannot be used during the three-way 997 handshake. For this reason, a Transport Converter MUST ignore option 998 Kind=5 with if it appears in a Connect TLV. It MUST NOT announce it 999 in a Bootstrap TLV. 1001 5.4. Timestamp 1003 The Timestamp option was initially defined in [RFC1323] which has 1004 been replaced by [RFC7323]. It can be used during the three-way 1005 handshake to negotiate the utilisation of the timestamps during the 1006 TCP connection. It is notably used to improve round-trip-time 1007 estimations and to provide protection against wrapped sequence 1008 numbers (PAWS). As for the WS option, the timestamps are a property 1009 of a connection and there is limited benefit in enabling a client to 1010 request a Converter to use the timestamp option when establishing a 1011 connection to a remote server. Furthermore, the timestamps that are 1012 used by TCP stacks are specific to each stack and there is no benefit 1013 in enabling a client to specify the timestamp value that a Converter 1014 could use to establish a connection to a remote server. 1016 A Transport Converter MAY advertise the Timestamp option (Kind=8) in 1017 the Bootstrap TLV. The clients connected to this Converter MAY 1018 include the Timestamp option in the Connect TLV but without any 1019 timestamp. 1021 5.5. Multipath TCP 1023 The Multipath TCP options are defined in [RFC6824]. [RFC6824] 1024 defines one variable length TCP option (Kind=30) that includes a 1025 subtype field to support several Multipath TCP options. There are 1026 several operational use cases where clients would like to use 1027 Multipath TCP through a Converter [IETFJ16]. However, none of these 1028 use cases require the Client to specify the content of the Multipath 1029 TCP option that the Converter should send to a remote server. 1031 A Transport Converter which supports Multipath TCP conversion service 1032 MUST advertise the Multipath TCP option (Kind=30) in the Bootstrap 1033 TLV. Clients serviced by this Converter may include the Multipath 1034 TCP option in the Connect TLV but without any content. 1036 5.6. TCP Fast Open 1038 The TCP Fast Open cookie option (Kind=34) is defined in [RFC7413]. 1039 There are two different usages of this option that need to be 1040 supported by Transport Converters. The first utilisation of the Fast 1041 Open cookie is to request a cookie from the server. In this case, 1042 the option is sent with an empty cookie by the client and the server 1043 returns the cookie. The second utilisation of the Fast Open cookie 1044 is to send a cookie to the server. In this case, the option contains 1045 a cookie. 1047 A Transport Converter MAY advertise the TCP Fast Open cookie option 1048 (Kind=34) in the Bootstrap TLV. If a Transport Converter has 1049 advertised the support for TCP Fast Open in its Bootstrap TLV, it 1050 needs to be able to process two types of Connect TLV. If such a 1051 Transport Converter receives a Connect TLV with the TCP Fast Open 1052 cookie option that does not contain a cookie, it MUST add an empty 1053 TCP Fast Open cookie option in the SYN sent to the remote server. If 1054 such a Transport Converter receives a Connect TLV with the TCP Fast 1055 Open cookie option that contains a cookie, it MUST copy the TCP Fast 1056 Open cookie option in the SYN sent to the remote server. 1058 5.7. TCP User Timeout 1060 The TCP User Timeout option is defined in [RFC5482]. The associated 1061 TCP option (Kind=28) does not appear to be widely deployed. 1063 Editor's Note: Feedback requested for the utilisation of this option 1064 by deployed TCP stacks. 1066 5.8. TCP-AO 1068 TCP-AO [RFC5925] provides a technique to authenticate all the packets 1069 exchanged over a TCP connection. Given the nature of this extension, 1070 it is unlikely that the applications that require their packets to be 1071 authenticated end-to-end would want their connections to pass through 1072 a converter. For this reason, we do not recommend the support of the 1073 TCP-AO option by Transport Converters. The only use cases where is 1074 makes sense to combine TCP-AO and the solution in this document are 1075 those where the TCP-AO-NAT extension [RFC6978] is in use. 1077 A Converter MUST NOT advertise the TCP-AO option (Kind=29) in the 1078 Bootstrap TLV. If a Converter receives a Connect TLV that contains 1079 the TCP-AO option, it MUST reject the establishment of the connection 1080 with error code set to "Unsupported TCP Option", except if the TCP- 1081 AO-NAT option is used. 1083 5.9. TCP Experimental Options 1085 The TCP Experimental options are defined in [RFC4727]. Given the 1086 variety of semantics for these options and their experimental nature, 1087 it is impossible to discuss them in details in this document. 1089 6. Interactions with Middleboxes 1091 The Converter Protocol was designed to be used in networks that do 1092 not contain middleboxes that interfere with TCP. We describe in this 1093 section how a Client can detect middlebox interference and stop using 1094 the Transport Converter affected by this interference. 1096 Internet measurements [IMC11] have shown that middleboxes can affect 1097 the deployment of TCP extensions. In this section, we only discuss 1098 the middleboxes that modify SYN and SYN+ACK packets since the 1099 Converter Protocol places its messages in such packets. 1101 Let us first consider a middlebox that removes the TFO Option from 1102 the SYN packet. This interference will be detected by the Client 1103 during the bootstrap procedure discussed in Section 4.2.3. A Client 1104 should not use a Transport Converter that does not reply with the TFO 1105 option during the Bootstrap. 1107 Consider a middlebox that removes the SYN payload after the bootstrap 1108 procedure. The Client can detect this problem by looking at the 1109 acknowledgement number field of the SYN+ACK returned by the Transport 1110 Converter. The Client should stop to use this Transport Converter 1111 given the middlebox interference. 1113 As explained in [RFC7413], some carrier-grade NATs can affect the 1114 operation of TFO if they assign different IP addresses to the same 1115 end host. Such carrier-grade NATs could affect the operation of the 1116 TFO Option used by the Converter Protocol. See also the discussion 1117 in Section 7.1 of [RFC7413]. 1119 7. Security Considerations 1121 7.1. Privacy & Ingress Filtering 1123 The Converter may have access to privacy-related information (e.g., 1124 subscriber credentials). The Converter MUST NOT leak such sensitive 1125 information outside a local domain. 1127 Given its function and its location in the network, a Transport 1128 Converter has access to the payload of all the packets that it 1129 processes. As such, it MUST be protected as a core IP router (e.g., 1130 [RFC1812]). 1132 Furthermore, ingress filtering policies MUST be enforced at the 1133 network boundaries [RFC2827]. 1135 This document assumes that all network attachments are managed by the 1136 same administrative entity. Therefore, enforcing anti-spoofing 1137 filters at these network ensures that hosts are not sending traffic 1138 with spoofed source IP addresses. 1140 7.2. Authorization 1142 The Converter Protocol is intended to be used in managed networks 1143 where end hosts can be identified by their IP address. Thanks to the 1144 Bootstrap procedure, the Transport Converter can verify that the 1145 Client correctly receives packets sent by the Converter. Stronger 1146 authentication schemes MUST be defined to use the Converter Protocol 1147 in more open network environments; such schemes are out of scope of 1148 this document. 1150 See below for authorization considerations that are specific for 1151 Multipath TCP. 1153 7.3. Denial of Service 1155 Another possible risk is the amplification attacks since a Transport 1156 Converter sends a SYN towards a remote Server upon reception of a SYN 1157 from a Client. This could lead to amplification attacks if the SYN 1158 sent by the Transport Converter were larger than the SYN received 1159 from the Client or if the Transport Converter retransmits the SYN. 1160 To mitigate such attacks, the Transport Converter SHOULD rate limit 1161 the number of pending requests for a given Client. It SHOULD also 1162 avoid sending to remote Servers SYNs that are significantly longer 1163 than the SYN received from the Client. In practice, Transport 1164 Converters SHOULD NOT advertise to a Server TCP options that were not 1165 specified by the Client in the received SYN. Finally, the Transport 1166 Converter SHOULD only retransmit a SYN to a Server after having 1167 received a retransmitted SYN from the corresponding Client. 1169 Upon reception of a SYN that contains a valid TFO cookie and a 1170 Connect TLV, the Transport Converter attempts to establish a TCP 1171 connection to a remote Server. There is a risk of denial of service 1172 attack if a Client requests too many connections in a short period of 1173 time. Implementations SHOULD limit the number of pending connections 1174 from a given Client. Means to protect against SYN flooding attacks 1175 MUST also be enabled [RFC4987]. 1177 7.4. Traffic Theft 1179 Traffic theft is a risk if an illegitimate Converter is inserted in 1180 the path. Indeed, inserting an illegitimate Converter in the 1181 forwarding path allows traffic interception and can therefore provide 1182 access to sensitive data issued by or destined to a host. Converter 1183 discovery and configuration are out of scope of this document. 1185 7.5. Multipath TCP-specific Considerations 1187 Multipath TCP-related security threats are discussed in [RFC6181] and 1188 [RFC6824]. 1190 The operator that manages the various network attachments (including 1191 the Converters) can enforce authentication and authorization policies 1192 using appropriate mechanisms. For example, a non-exhaustive list of 1193 methods to achieve authorization is provided hereafter: 1195 o The network provider may enforce a policy based on the 1196 International Mobile Subscriber Identity (IMSI) to verify that a 1197 user is allowed to benefit from the aggregation service. If that 1198 authorization fails, the Packet Data Protocol (PDP) context/bearer 1199 will not be mounted. This method does not require any interaction 1200 with the Converter. 1202 o The network provider may enforce a policy based upon Access 1203 Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) 1204 to control the hosts that are authorized to communicate with a 1205 Converter. These ACLs may be installed as a result of RADIUS 1206 exchanges, e.g. [I-D.boucadair-mptcp-radius]. This method does 1207 not require any interaction with the Converter. 1209 o A device that embeds the Converter may also host a RADIUS client 1210 that will solicit an AAA server to check whether connections 1211 received from a given source IP address are authorized or not 1212 [I-D.boucadair-mptcp-radius]. 1214 A first safeguard against the misuse of Converter resources by 1215 illegitimate users (e.g., users with access networks that are not 1216 managed by the same provider that operates the Converter) is the 1217 Converter to reject Multipath TCP connections received on its 1218 Internet-facing interfaces. Only Multipath PTCP connections received 1219 on the customer-facing interfaces of a Converter will be accepted. 1221 8. IANA Considerations 1223 8.1. Convert Service Port Number 1225 IANA is requested to assign a TCP port number (TBA) for the Converter 1226 Protocol from the "Service Name and Transport Protocol Port Number 1227 Registry" available at https://www.iana.org/assignments/service- 1228 names-port-numbers/service-names-port-numbers.xhtml. 1230 8.2. The Converter Protocol (Convert) Parameters 1232 IANA is requested to create a new "The Converter Protocol (Convert) 1233 Parameters" registry. 1235 The following subsections detail new registries within "The Converter 1236 Protocol (Convert) Parameters" registry. 1238 8.2.1. Convert Versions 1240 IANA is requested to create the "Convert versions" sub-registry. New 1241 values are assigned via Standards Action. 1243 The initial values to be assigned at the creation of the registry are 1244 as follows: 1246 +---------+--------------------------------------+-------------+ 1247 | Version | Description | Reference | 1248 +---------+--------------------------------------+-------------+ 1249 | 0 | Reserved by this document | [This-RFC] | 1250 | 1 | Assigned by this document | [This-RFC] | 1251 +---------+--------------------------------------+-------------+ 1253 8.2.2. Convert TLVs 1255 IANA is requested to create the "Convert TLVs" sub-registry. The 1256 procedure for assigning values from this registry is as follows: 1258 o The values in the range 1-127 can be assigned via Standards 1259 Action. 1261 o The values in the range 128-191 can be assigned via Specification 1262 Required. 1264 o The values in the range 192-255 can be assigned for Private Use. 1266 The initial values to be assigned at the creation of the registry are 1267 as follows: 1269 +---------+--------------------------------------+-------------+ 1270 | Code | Name | Reference | 1271 +---------+--------------------------------------+-------------+ 1272 | 0 | Reserved | [This-RFC] | 1273 | 1 | Bootstrap TLV | [This-RFC] | 1274 | 10 | Connect TLV | [This-RFC] | 1275 | 20 | Extended TCP Header TLV | [This-RFC] | 1276 | 22 | Supported TCP Extension Services TLV | [This-RFC] | 1277 | 30 | Error TLV | [This-RFC] | 1278 +---------+--------------------------------------+-------------+ 1280 8.2.3. Convert Error Messages 1282 IANA is requested to create the "Convert Errors" sub-registry. Codes 1283 in this registry are assigned as a function of the error type. Four 1284 types are defined; the following ranges are reserved for each of 1285 these types: 1287 o Message validation and processing errors: 0-31 1289 o Client-side errors: 32-63 1291 o Converter-side errors: 64-95 1293 o Errors caused by destination server: 96-127 1295 The procedure for assigning values from this sub-registry is as 1296 follows: 1298 o 0-191: Values in this range are assigned via Standards Action. 1300 o 192-255: Values in this range are assigned via Specification 1301 Required. 1303 The initial values to be assigned at the creation of the registry are 1304 as follows: 1306 +-------+------+-----------------------------------+-----------+ 1307 | Error | Hex | Description | Reference | 1308 +-------+------+-----------------------------------+-----------+ 1309 | 0 | 0x00 | Unsupported Version | [This-RFC]| 1310 | 1 | 0x01 | Malformed Message | [This-RFC]| 1311 | 2 | 0x02 | Unsupported Message | [This-RFC]| 1312 | 32 | 0x20 | Not Authorized | [This-RFC]| 1313 | 33 | 0x21 | Unsupported TCP Option | [This-RFC]| 1314 | 64 | 0x40 | Resource Exceeded | [This-RFC]| 1315 | 65 | 0x41 | Network Failure | [This-RFC]| 1316 | 96 | 0x60 | Connection Reset | [This-RFC]| 1317 | 97 | 0x61 | Destination Unreachable | [This-RFC]| 1318 +-------+------+-----------------------------------+-----------+ 1320 Figure 19: The Convert Error Codes 1322 9. Acknowledgements 1324 Although they could disagree with the contents of the document, we 1325 would like to thank Joe Touch and Juliusz Chroboczek whose comments 1326 on the MPTCP mailing list have forced us to reconsider the design of 1327 the solution several times. 1329 We would like to thank Raphael Bauduin, Stefano Secci, and Benjamin 1330 Hesmans for their help in preparing this document. Sri Gundavelli 1331 and Nandini Ganesh provided valuable feedback about the handling of 1332 TFO and the error codes. Thanks to them. 1334 This document builds upon earlier documents that proposed various 1335 forms of Multipath TCP proxies [I-D.boucadair-mptcp-plain-mode], 1336 [I-D.peirens-mptcp-transparent] and [HotMiddlebox13b]. 1338 From [I-D.boucadair-mptcp-plain-mode]: 1340 Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi 1341 Nishida, and Christoph Paasch for their valuable comments. 1343 Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and 1344 Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos 1345 Aires). 1347 Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and 1348 Xavier Grall for their inputs. 1350 Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas 1351 Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves 1352 Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun 1353 Srinivasan, and Raghavendra Mallya for the discussion. 1355 9.1. Contributors 1357 As noted above, this document builds on two previous documents. 1359 The authors of [I-D.boucadair-mptcp-plain-mode] were: - Mohamed 1360 Boucadair - Christian Jacquenet - Olivier Bonaventure - Denis 1361 Behaghel - Stefano Secci - Wim Henderickx - Robert Skog - Suresh 1362 Vinapamula - SungHoon Seo - Wouter Cloetens - Ullrich Meyer - Luis M. 1363 Contreras - Bart Peirens 1365 The authors of [I-D.peirens-mptcp-transparent] were: - Bart Peirens - 1366 Gregory Detal - Sebastien Barre - Olivier Bonaventure 1368 10. Change Log 1370 This section to be removed before publication. 1372 o 00 : initial version, designed to support Multipath TCP and TFO 1373 only 1375 o 00 to -01 : added section Section 5 describing the support of 1376 different standard tracks TCP options by Transport Converters, 1377 clarification of the IANA section, moved the SOCKS comparison to 1378 the appendix and various minor modifications 1380 11. References 1382 11.1. Normative References 1384 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1385 RFC 793, DOI 10.17487/RFC0793, September 1981, 1386 . 1388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1389 Requirement Levels", BCP 14, RFC 2119, 1390 DOI 10.17487/RFC2119, March 1997, 1391 . 1393 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1394 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1395 2006, . 1397 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1398 ICMPv6, UDP, and TCP Headers", RFC 4727, 1399 DOI 10.17487/RFC4727, November 2006, 1400 . 1402 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1403 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1404 . 1406 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 1407 RFC 5482, DOI 10.17487/RFC5482, March 2009, 1408 . 1410 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1411 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1412 June 2010, . 1414 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1415 "TCP Extensions for Multipath Operation with Multiple 1416 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1417 . 1419 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1420 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1421 . 1423 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1424 Writing an IANA Considerations Section in RFCs", BCP 26, 1425 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1426 . 1428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1430 May 2017, . 1432 11.2. Informative References 1434 [ANRW17] Trammell, B., Kuhlewind, M., De Vaere, P., Learmonth, I., 1435 and G. Fairhurst, "Tracking transport-layer evolution with 1436 PATHspider", Applied Networking Research Workshop 2017 1437 (ANRW17) , July 2017. 1439 [Fukuda2011] 1440 Fukuda, K., "An Analysis of Longitudinal TCP Passive 1441 Measurements (Short Paper)", Traffic Monitoring and 1442 Analysis. TMA 2011. Lecture Notes in Computer Science, vol 1443 6613. , 2011. 1445 [HotMiddlebox13b] 1446 Detal, G., Paasch, C., and O. Bonaventure, "Multipath in 1447 the Middle(Box)", HotMiddlebox'13 , December 2013, 1448 . 1451 [I-D.arkko-arch-low-latency] 1452 Arkko, J. and J. Tantsura, "Low Latency Applications and 1453 the Internet Architecture", draft-arkko-arch-low- 1454 latency-02 (work in progress), October 2017. 1456 [I-D.boucadair-mptcp-plain-mode] 1457 Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, 1458 D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 1459 Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., 1460 Contreras, L., and B. Peirens, "Extensions for Network- 1461 Assisted MPTCP Deployment Models", draft-boucadair-mptcp- 1462 plain-mode-10 (work in progress), March 2017. 1464 [I-D.boucadair-mptcp-radius] 1465 Boucadair, M. and C. Jacquenet, "RADIUS Extensions for 1466 Network-Assisted Multipath TCP (MPTCP)", draft-boucadair- 1467 mptcp-radius-05 (work in progress), October 2017. 1469 [I-D.ietf-mptcp-rfc6824bis] 1470 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1471 Paasch, "TCP Extensions for Multipath Operation with 1472 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-10 (work 1473 in progress), March 2018. 1475 [I-D.ietf-tcpinc-tcpcrypt] 1476 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1477 Q., and E. Smith, "Cryptographic protection of TCP Streams 1478 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-11 (work in 1479 progress), November 2017. 1481 [I-D.olteanu-intarea-socks-6] 1482 Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6", 1483 draft-olteanu-intarea-socks-6-01 (work in progress), 1484 October 2017. 1486 [I-D.peirens-mptcp-transparent] 1487 Peirens, B., Detal, G., Barre, S., and O. Bonaventure, 1488 "Link bonding with transparent Multipath TCP", draft- 1489 peirens-mptcp-transparent-00 (work in progress), July 1490 2016. 1492 [IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment", 1493 IETF Journal, Fall 2016 , n.d.. 1495 [IMC11] Honda, K., Nishida, Y., Raiciu, C., Greenhalgh, A., 1496 Handley, M., and T. Hideyuki, "Is it still possible to 1497 extend TCP ?", Proceedings of the 2011 ACM SIGCOMM 1498 conference on Internet measurement conference , 2011. 1500 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 1501 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1502 1992, . 1504 [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", 1505 RFC 1812, DOI 10.17487/RFC1812, June 1995, 1506 . 1508 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 1509 RFC 1919, DOI 10.17487/RFC1919, March 1996, 1510 . 1512 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1513 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1514 DOI 10.17487/RFC1928, March 1996, 1515 . 1517 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1518 Selective Acknowledgment Options", RFC 2018, 1519 DOI 10.17487/RFC2018, October 1996, 1520 . 1522 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1523 Defeating Denial of Service Attacks which employ IP Source 1524 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1525 May 2000, . 1527 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1528 Shelby, "Performance Enhancing Proxies Intended to 1529 Mitigate Link-Related Degradations", RFC 3135, 1530 DOI 10.17487/RFC3135, June 2001, 1531 . 1533 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 1534 Multipath Operation with Multiple Addresses", RFC 6181, 1535 DOI 10.17487/RFC6181, March 2011, 1536 . 1538 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1539 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 1540 2012, . 1542 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1543 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1544 DOI 10.17487/RFC6887, April 2013, 1545 . 1547 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1548 "Increasing TCP's Initial Window", RFC 6928, 1549 DOI 10.17487/RFC6928, April 2013, 1550 . 1552 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1553 Traversal", RFC 6978, DOI 10.17487/RFC6978, July 2013, 1554 . 1556 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 1557 Scheffenegger, Ed., "TCP Extensions for High Performance", 1558 RFC 7323, DOI 10.17487/RFC7323, September 2014, 1559 . 1561 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1562 Zimmermann, "A Roadmap for Transmission Control Protocol 1563 (TCP) Specification Documents", RFC 7414, 1564 DOI 10.17487/RFC7414, February 2015, 1565 . 1567 Appendix A. Differences with SOCKSv5 1569 The description above is a simplified description of the Converter 1570 protocol. At a first glance, the proposed solution could seem 1571 similar to the SOCKS v5 protocol [RFC1928]. This protocol is used to 1572 proxy TCP connections. The Client creates a connection to a SOCKS 1573 proxy, exchanges authentication information and indicates the 1574 destination address and port of the final server. At this point, the 1575 SOCKS proxy creates a connection towards the final server and relays 1576 all data between the two proxied connections. The operation of an 1577 implementation based on SOCKSv5 is illustrated in Figure 20. 1579 Client SOCKS Proxy Server 1580 --------------------> 1581 SYN 1582 <-------------------- 1583 SYN+ACK 1584 --------------------> 1585 ACK 1587 --------------------> 1588 Version=5, Auth Methods 1589 <-------------------- 1590 Method 1591 --------------------> 1592 Auth Request (unless "No auth" method negotiated) 1593 <-------------------- 1594 Auth Response 1595 --------------------> 1596 Connect Server:Port --------------------> 1597 SYN 1599 <-------------------- 1600 SYN+ACK 1601 <-------------------- 1602 Succeeded 1604 --------------------> 1605 Data1 1606 --------------------> 1607 Data1 1609 <-------------------- 1610 Data2 1611 <-------------------- 1612 Data2 1614 Figure 20: Establishment of a TCP connection through a SOCKS proxy 1615 without authentication 1617 The Converter protocol also relays data between an upstream and a 1618 downstream connection, but there are important differences with 1619 SOCKSv5. 1621 A first difference is that the Converter protocol leverages the TFO 1622 option [RFC7413] to exchange all control information during the 1623 three-way handshake. This reduces the connection establishment delay 1624 compared to SOCKS that requires two or more round-trip-times before 1625 the establishment of the downstream connection towards the final 1626 destination. In today's Internet, latency is a important metric and 1627 various protocols have been tuned to reduce their latency 1628 [I-D.arkko-arch-low-latency]. A recently proposed extension to SOCKS 1629 also leverages the TFO option [I-D.olteanu-intarea-socks-6]. 1631 A second difference is that the Converter protocol explicitly takes 1632 the TCP extensions into account. By using the Converter protocol, 1633 the Client can learn whether a given TCP extension is supported by 1634 the destination Server. This enables the Client to bypass the 1635 Transport Converter when the destination supports the required TCP 1636 extension. Neither SOCKS v5 [RFC1928] nor the proposed SOCKS v6 1637 [I-D.olteanu-intarea-socks-6] provide such a feature. 1639 A third difference is that a Transport Converter will only accept the 1640 connection initiated by the Client provided that the downstream 1641 connection is accepted by the Server. If the Server refuses the 1642 connection establishment attempt from the Transport Converter, then 1643 the upstream connection from the Client is rejected as well. This 1644 feature is important for applications that check the availability of 1645 a Server or use the time to connect as a hint on the selection of a 1646 Server [RFC6555]. 1648 Authors' Addresses 1650 Olivier Bonaventure (editor) 1651 Tessares 1653 Email: Olivier.Bonaventure@tessares.net 1655 Mohamed Boucadair (editor) 1656 Orange 1658 Email: mohamed.boucadair@orange.com 1660 Bart Peirens 1661 Proximus 1663 Email: bart.peirens@proximus.com 1665 SungHoon Seo 1666 Korea Telecom 1668 Email: sh.seo@kt.com 1669 Anandatirtha Nandugudi 1670 Memphis University 1672 Email: nndugudi@memphis.edu