idnits 2.17.1 draft-ietf-tcpm-converters-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 16, 2018) is 2259 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Bootstrap' is mentioned on line 347, 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-09 == 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 6555 (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM Working Group O. Bonaventure 3 Internet-Draft Tessares 4 Intended status: Experimental M. Boucadair 5 Expires: August 20, 2018 Orange 6 B. Peirens 7 Proximus 8 S. Seo 9 Korea Telecom 10 A. Nandugudi 11 Tessares 12 February 16, 2018 14 0-RTT TCP Converter 15 draft-ietf-tcpm-converters-00 17 Abstract 19 This document specifies an application proxy, called Transport 20 Converter, to assist the deployment of Multipath TCP. This proxy is 21 designed to avoid inducing extra delay when involved in a network- 22 assisted connection (that is, 0-RTT). This specification assumes an 23 explicit model, where the proxy is explicitly configured on hosts. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 20, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Applicability Scope . . . . . . . . . . . . . . . . . . . . . 5 61 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Sample Examples of Converter-Assisted Multipath TCP 63 Connections . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.2. Sample Example of Incoming Converter-Assisted 65 Multipath TCP Connection . . . . . . . . . . . . . . . . . 11 66 3.3. Differences with SOCKSv5 . . . . . . . . . . . . . . . . . 12 67 4. The Converter Protocol . . . . . . . . . . . . . . . . . . . . 15 68 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 15 69 4.2. The Fixed Header . . . . . . . . . . . . . . . . . . . . . 15 70 4.3. Transport Converter TLVs . . . . . . . . . . . . . . . . . 16 71 4.3.1. Connect TLV . . . . . . . . . . . . . . . . . . . . . 16 72 4.3.2. Extended TCP Header TLV . . . . . . . . . . . . . . . 18 73 4.3.3. Error TLV . . . . . . . . . . . . . . . . . . . . . . 19 74 4.3.4. The Bootstrap TLV . . . . . . . . . . . . . . . . . . 21 75 4.3.5. Supported TCP Options TLV . . . . . . . . . . . . . . 22 76 5. Interactions with middleboxes . . . . . . . . . . . . . . . . 23 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 78 6.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 24 79 6.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 24 80 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 24 81 6.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 25 82 6.5. Multipath TCP-specific Considerations . . . . . . . . . . 25 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 85 8.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 28 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 91 1. Introduction 93 Transport protocols like TCP evolve regularly [RFC7414]. TCP has 94 been improved in different ways. Some improvements such as changing 95 the initial window size or modifying the congestion control scheme 96 can be applied independently on clients and servers. Other 97 improvements such as Selective Acknowledgements [RFC2018] or large 98 windows [RFC7323] require a new TCP option or to change the semantics 99 of some fields in the TCP header. These modifications must be 100 deployed on both clients and servers to be actually used on the 101 Internet. Experience with the latter TCP extensions reveals that 102 their deployment can require many years. Fukuda reports in 103 [Fukuda2011] results of a decade of measurements showing the 104 deployment of Selective Acknowledgements, Window Scale and TCP 105 Timestamps. Trammel et al. provide in [ANRW17] measurements showing 106 that TCP Fast Open [RFC7413] (TFO) is still not widely deployed. 108 There are some situations where the transport stack used on clients 109 (resp. servers) can be upgraded at a faster pace than the transport 110 stack running on servers (resp. clients). In those situations, 111 clients would typically want to benefit from the features of an 112 improved transport protocol even if the servers have not yet been 113 upgraded and conversely. In the past, Performance Enhancing Proxies 114 have been proposed and deployed [RFC3135] as solutions to improve TCP 115 performance over links with specific characteristics. 117 Recent examples of TCP extensions include Multipath TCP [RFC6824] or 118 TCPINC [I-D.ietf-tcpinc-tcpcrypt]. Those extensions provide features 119 that are interesting for clients such as wireless devices. With 120 Multipath TCP, those devices could seamlessly use WLAN and cellular 121 networks, for bonding purposes, faster handovers, or better 122 resiliency. Unfortunately, deploying those extensions on both a wide 123 range of clients and servers remains difficult. 125 This document specifies an application proxy, called Transport 126 Converter (TC). A Transport Converter is a function that is 127 installed by a network operator to aid the deployment of TCP 128 extensions and to provide the benefits of such extensions to clients. 129 A Transport Converter supports one or more TCP extensions. The 130 Converter Protocol (CP) is an application layer protocol that uses a 131 TCP port number (see IANA section). The Transport Converter adheres 132 to the main principles as drawn in [RFC1919]. In particular, the 133 Converter achieves the following: 135 o Listen for client sessions; 137 o Receive from a client the address of the final target server; 138 o Setup a session to the final server; 140 o Relay control messages and data between the client and the server; 142 o Perform access controls according to local policies. 144 The main advantage of network-assisted converters is that they enable 145 new TCP extensions to be used on a subset of the end-to-end path, 146 which encourages the deployment of these extensions. The Transport 147 Converter allows the client and the server to directly negotiate some 148 options between the endpoints. This document focuses on Multipath 149 TCP [RFC6824] and TCP Fast Open [RFC7413]. The support for other TCP 150 extensions will be discussed in other documents. 152 This document does not assume that all the traffic is eligible to the 153 network-assisted conversion service. Only a subset of the traffic 154 will be forwarded to a converter according to a set of policies. 155 Furthermore, it is possible to bypass the converter to connect to the 156 servers that already support the required TCP extension. 158 This document assumes that a client is configured with one or a list 159 of transport converters. Configuration means are outside the scope 160 of this document. 162 This document is organized as follows. We first provide a brief 163 explanation of the operation of Transport Converters in Section 3. 164 We compare them in Section 3.3 with SOCKS proxies that are already 165 used to deploy Multipath TCP in cellular networks [IETFJ16]. We then 166 describe the Converter Protocol in Section 4. We then discuss the 167 interactions with middleboxes (Section 5) and the security 168 considerations (Section 6). 170 2. Applicability Scope 172 This specification is designed with Multipath TCP 173 [RFC6824][I-D.ietf-mptcp-rfc6824bis] and TCP Fast Open [RFC7413] in 174 mind. That is, the specification draws how network-assisted 175 Multipath TCP connections can be established even if the remote 176 server is not Multipath TCP-capable without inducing extra connection 177 delays (0-RTT proxy). Further, the specification allows the client 178 for end-to-end Multipath TCP connections with or without proxy 179 involvement. Assessing the applicability of the solution to other 180 use cases and other TCP extensions such as [I-D.ietf-tcpinc-tcpcrypt] 181 is outside the scope of this document. Future documents are required 182 to specify the exact behavior when the converter is deployed in other 183 contexts than Multipath TCP. 185 3. Architecture 187 The architecture considers three types of endhosts: 189 o Client endhosts; 191 o Transport Converters; 193 o Server endhosts. 195 It does not mandate anything on the server side. The architecture 196 assumes that new software will be installed on the Client hosts and 197 on Transport Converters. Further, the architecture allows for making 198 use of TCP new extensions if those are supported by a given server. 200 A Transport Converter is a network function that relays all data 201 exchanged over one upstream connection to one downstream connection 202 and vice versa. A connection can be initiated from both interfaces 203 of the transport converter (Internet-facing interface, client-facing 204 interface). The converter, thus, maintains state that associates one 205 upstream connection to a corresponding downstream connection. One of 206 the benefits of this design is that different transport protocol 207 extensions can be used on the upstream and the downstream 208 connections. This encourages the deployment of new TCP extensions 209 until they are supported by many servers. 211 +------------+ 212 <--- upstream --->| Transport |<--- downstream ---> 213 | Converter | 214 +------------+ 216 Figure 1: A Transport Converter relays data between pairs of TCP 217 connections 219 Transport converters can be operated by network operators or third 220 parties. The Client is configured, through means that are outside 221 the scope of this document, with the names and/or the addresses of 222 one or more Transport Converters. The packets belonging to the pair 223 of connections between the Client and Server passing through a 224 Transport Converter may follow a different path than the packets 225 directly exchanged between the Client and the Server. Deployments 226 should minimize the possible additional delay by carefully selecting 227 the location of the Transport Converter used to reach a given 228 destination. 230 A transport converter can be embedded in a standalone device or be 231 activated as a service on a router. How such function is enabled is 232 deployement-specific. 234 +-+ +-+ +-+ 235 Client - |R| -- |R| -- |R| - - - Server 236 +-+ +-+ +-+ 237 | 238 Transport 239 Converter 241 Figure 2: A Transport Converter can be installed anywhere in the 242 network 244 When establishing a connection, the Client can, depending on local 245 policies, either contact the Server directly (e.g., by sending a TCP 246 SYN towards the Server) or create the connection via a Transport 247 Converter. In the latter case, which is the case we consider in this 248 document, the Client initiates a connection towards the Transport 249 Converter and indicates the address and port number of the ultimate 250 Server inside the connection establishment packet. Doing so enables 251 the Transport Converter to immediately initiate a connection towards 252 that Server, without experiencing an extra delay. The Transport 253 Converter waits until the confirmation that the Server agrees to 254 establish the connection before confirming it to the Client. 256 The client places the destination address and port number of the 257 target Server in the payload of the SYN sent to the Converter by 258 leveraging TCP Fast Open [RFC7413]. In accordance with [RFC1919], 259 the Transport Converter maintains two connections that are combined 260 together. The upstream connection is the one between the Client and 261 the Transport Converter. The downstream connection is between the 262 Transport Converter and the remote Server. Any user data received by 263 the Transport Converter over the upstream (resp., downstream) 264 connection is relayed over the downstream (resp., upstream) 265 connection. 267 At a high level, the objective of the Transport Converter is to allow 268 the Client to use a specific extension, e.g. Multipath TCP, on a 269 subset of the end-to-end path even if the Server does not support 270 this extension. This is illustrated in Figure 3 where the Client 271 initiates a Multipath TCP connection with the Converter (Multipath 272 packets are shown with =) while the Converter uses a regular TCP 273 connection with the Server. 275 Transport 276 Client Converter Server 277 ======================> 279 --------------------> 281 <-------------------- 283 <====================== 284 Multipath TCP packets Regular TCP packets 286 Figure 3: Different TCP variants can be used on the Client-Converter 287 path and on the Converter-Server path 289 Figure 4 illustrates the establishment of a TCP connection by the 290 Client through a Transport Converter. The information shown between 291 brackets is part of the Converter protocol described later in this 292 document. 294 The Client sends a SYN destined to the Transport Converter. This SYN 295 contains a TFO Cookie and inside its payload the addresses and ports 296 of the destination Server. The Transport Converter does not reply 297 immediately to this SYN. It first tries to create a TCP connection 298 towards the destination Server. If this second connection succeeds, 299 the Transport Converter confirms the establishment of the connection 300 to the Client by returning a SYN+ACK and the first bytes of the 301 bytestream contain information about the TCP Options that were 302 negotiated with the final Server. This information is sent at the 303 beginning of the bytestream, either directly in the SYN+ACK or in a 304 subsequent packet. For graphical reasons, the figures in this 305 section show that the Converter returns this information in the SYN+ 306 ACK packet. An implementation could also place this information in a 307 packet that it sent shortly after the SYN+ACK. 309 Transport 310 Client Converter Server 311 --------------------> 312 SYN TFO [->Server:port] 314 --------------------> 315 SYN 317 <-------------------- 318 SYN+ACK 319 <-------------------- 320 SYN+ACK [ ] 322 Figure 4: Establishment of a TCP connection through a Converter 324 The connection can also be established from the Internet towards a 325 client via a transport converter. This is typically the case when 326 the client embeds a server (video server, for example). 328 The procedure described in Figure 4 assumes that the Client has 329 obtained a TFO Cookie from the Transport Converter. This is part of 330 the Bootstrap procedure which is illustrated in Figure 5. The Client 331 sends a SYN with a TFO Request option to obtain a valid cookie from 332 the Converter. The Converter replies with a TFO cookie in the SYN+ 333 ACK. Once this connection has been established, the Client sends a 334 Bootstrap message to request the list of TCP options supported by the 335 Transport Converter. Thanks to this procedure, the Client knows 336 which TCP options are supported by a given Transport Converter. 338 Transport 339 Client Converter Server 340 --------------------> 341 SYN TFO(empty) 343 <-------------------- 344 SYN+ACK TFO(cookie) 346 --------------------> 347 [Bootstrap] 349 <-------------------- 350 [Supported TCP Options] 352 Figure 5: Bootstrapping a Client connection to a Transport Converter 354 Note that the Converter may rely on local policies to decide whether 355 it can service a given requesting client. That is, the Converter may 356 not return a cookie for that client. 358 Also, the Converter may behave in a Cookie-less mode when appropriate 359 means are enforced at the converter and the network in-between to 360 protect against attacks such as spoofing and SYN flood. Under such 361 deployments, the use of TFO is not required. 363 3.1. Sample Examples of Converter-Assisted Multipath TCP Connections 365 As an example, let us consider how such a protocol can help the 366 deployment of Multipath TCP [RFC6824]. We assume that both the 367 Client and the Transport Converter support Multipath TCP, but 368 consider two different cases depending 369 whether the Server supports Multipath TCP or not. A Multipath TCP 370 connection is created by placing the MP_CAPABLE (MPC) option in the 371 SYN sent by the Client. 373 Figure 6 describes the operation of the Transport Converter if the 374 Server does not support Multipath TCP. 376 Transport 377 Client Converter Server 378 --------------------> 379 SYN, MPC [->Server:port] 381 --------------------> 382 SYN, MPC 384 <-------------------- 385 SYN+ACK 386 <-------------------- 387 SYN+ACK,MPC [ ] 389 --------------------> 390 ACK,MPC 391 --------------------> 392 ACK 394 Figure 6: Establishment of a Multipath TCP connection through a 395 Converter 397 The Client tries to initiate a Multipath TCP connection by sending a 398 SYN with the MP_CAPABLE option (MPC in Figure 6). The SYN includes 399 the address and port number of the final Server and the Transport 400 Converter attempts to initiate a Multipath TCP connection towards 401 this Server. Since the Server does not support Multipath TCP, it 402 replies with a SYN+ACK that does not contain the MP_CAPABLE option. 403 The Transport Converter notes that the connection with the Server 404 does not support Multipath TCP and returns the TCP Options received 405 from the Server to the Client. 407 Figure 7 considers a Server that supports Multipath TCP. In this 408 case, it replies to the SYN sent by the Transport Converter with the 409 MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport 410 Converter confirms the establishment of the connection to the Client 411 and indicates to the Client that the Server supports Multipath TCP. 412 With this information, the Client has discovered that the Server 413 supports Multipath TCP natively. This will enable it to bypass the 414 Transport Converter for the next Multipath TCP connection that it 415 will initiate towards this Server. 417 Transport 418 Client Converter Server 419 --------------------> 420 SYN, MPC [->Server:port] 422 --------------------> 423 SYN, MPC 425 <-------------------- 426 SYN+ACK, MPC 427 <-------------------- 428 SYN+ACK, MPC [ MPC supported ] 430 --------------------> 431 ACK, MPC 432 --------------------> 433 ACK, MPC 435 Figure 7: Establishment of a Multipath TCP connection through a 436 converter 438 3.2. Sample Example of Incoming Converter-Assisted Multipath TCP 439 Connection 441 An example of an incoming converter-assisted Multipath TCP connection 442 is depicted in Figure 8. In order to support incoming connections 443 from remote hosts, the client may use PCP [RFC6887] to instruct the 444 converter to create dynamic mappings. Those mappings will be used by 445 the converter to intercept an incoming TCP connection destined to the 446 client and convert it into a Multipath TCP connection. 448 Transport 449 H1 Converter Remote Host 450 <------------------- 451 SYN 453 <------------------- 454 SYN, MPC[Remote Host:port] 456 ---------------------> 457 SYN+ACK, MPC 458 ---------------------> 459 SYN+ACK 461 <--------------------- 462 ACK 463 <------------------- 464 ACK, MPC 466 Figure 8: Establishment of an Incoming TCP Connection through a 467 Converter 469 3.3. Differences with SOCKSv5 471 The description above is a simplified description of the Converter 472 protocol. At a first glance, the proposed solution could seem 473 similar to the SOCKS v5 protocol [RFC1928]. This protocol is used to 474 proxy TCP connections. The Client creates a connection to a SOCKS 475 proxy, exchanges authentication information and indicates the 476 destination address and port of the final server. At this point, the 477 SOCKS proxy creates a connection towards the final server and relays 478 all data between the two proxied connections. The operation of an 479 implementation based on SOCKSv5 is illustrated in Figure 9. 481 Client SOCKS Proxy Server 482 --------------------> 483 SYN 484 <-------------------- 485 SYN+ACK 486 --------------------> 487 ACK 489 --------------------> 490 Version=5, Auth Methods 491 <-------------------- 492 Method 493 --------------------> 494 Auth Request (if "No auth" method negotiated) 495 <-------------------- 496 Auth Response 497 --------------------> 498 Connect Server:Port --------------------> 499 SYN 501 <-------------------- 502 SYN+ACK 503 <-------------------- 504 Succeeded 506 --------------------> 507 Data1 508 --------------------> 509 Data1 511 <-------------------- 512 Data2 513 <-------------------- 514 Data2 516 Figure 9: Establishment of a TCP connection through a SOCKS proxy 517 without authentication 519 The Converter protocol also relays data between an upstream and a 520 downstream connection, but there are important differences with 521 SOCKSv5. 523 A first difference is that the Converter protocol leverages the TFO 524 option [RFC7413] to exchange all control information during the 525 three-way handshake. This reduces the connection establishment delay 526 compared to SOCKS that requires two or more round-trip-times before 527 the establishment of the downstream connection towards the final 528 destination. In today's Internet, latency is a important metric and 529 various protocols have been tuned to reduce their latency 530 [I-D.arkko-arch-low-latency]. A recently proposed extension to SOCKS 531 also leverages the TFO option [I-D.olteanu-intarea-socks-6]. 533 A second difference is that the Converter protocol explicitly takes 534 the TCP extensions into account. By using the Converter protocol, 535 the Client can learn whether a given TCP extension is supported by 536 the destination Server. This enables the Client to bypass the 537 Transport Converter when the destination supports the required TCP 538 extension. Neither SOCKS v5 [RFC1928] nor the proposed SOCKS v6 539 [I-D.olteanu-intarea-socks-6] provide such a feature. 541 A third difference is that a Transport Converter will only accept the 542 connection initiated by the Client provided that the downstream 543 connection is accepted by the Server. If the Server refuses the 544 connection establishment attempt from the Transport Converter, then 545 the upstream connection from the Client is rejected as well. This 546 feature is important for applications that check the availability of 547 a Server or use the time to connect as a hint on the selection of a 548 Server [RFC6555]. 550 4. The Converter Protocol 552 We now describe in details the messages that are exchanged between a 553 Client and a Transport Converter. The Converter Protocol (CP) 554 leverages the TCP Fast Open extension defined in [RFC7413]. 556 The Converter Protocol uses a 32 bits long fixed header that is sent 557 by both the Client and the Transport Converter. This header 558 indicates both the version of the protocol used and the length of the 559 CP message. 561 4.1. Requirements 563 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 564 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 565 "OPTIONAL" in this document are to be interpreted as described in 566 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 567 as shown here. 569 4.2. The Fixed Header 571 The Fixed Header is used to exchange information about the version 572 and length of the messages between the Client and the Transport 573 Converter. The Client and the Transport Converter MUST send the 574 fixed-sized header shown in Figure 10 as the first four bytes of the 575 bytestream. 577 1 2 3 578 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 579 +---------------+---------------+-------------------------------+ 580 | Version | Total Length | Reserved | 581 +---------------+---------------+-------------------------------+ 583 Figure 10: The fixed-sized header of the Converter protocol 585 The Version is encoded as an 8 bits unsigned integer value. This 586 document specifies version 1. The Total Length is the number of 32 587 bits word, including the header, of the bytestream that are consumed 588 by the Converter protocol messages. Since Total Length is also an 8 589 bits unsigned integer, those messages cannot consume more than 1020 590 bytes of data. This limits the number of bytes that a Transport 591 Converter needs to process. A Total Length of zero is invalid and 592 the connection MUST be reset upon reception of such a header. The 593 Reserved field MUST be set to zero in this version of the protocol. 595 4.3. Transport Converter TLVs 597 The Converter protocol uses variable length messages that are encoded 598 using a TLV format to simplify the parsing of the messages and leave 599 room to extend the protocol in the future. A given TLV can only 600 appear once on a connection. If two or more copies of the same TLV 601 are exchanged over a Converter connection, the associated TCP 602 connections MUST be closed. All fields are encoded using the network 603 byte order. 605 Five TLVs are defined in this document. They are listed in Table 1. 607 +------+------+----------+---------------------------+ 608 | Type | Hex | Length | Description | 609 +------+------+----------+---------------------------+ 610 | 1 | 0x1 | 1 | Bootstrap TLV | 611 | | | | | 612 | 10 | 0xA | Variable | Connect TLV | 613 | | | | | 614 | 20 | 0x14 | Variable | Extended TCP Header TLV | 615 | | | | | 616 | 21 | 0x15 | Variable | Supported TCP Options TLV | 617 | | | | | 618 | 30 | 0x1E | Variable | Error TLV | 619 +------+------+----------+---------------------------+ 621 Table 1: The TLVs used by the Converter protocol 623 To use a given Transport Converter, a Client MUST first obtain a 624 valid TFO cookie from it. This is the bootstrap procedure during 625 which the Client opens a connection to the Transport Converter with 626 an empty TFO option. According to [RFC7413], the Transport Converter 627 returns its cookie in the SYN+ACK. Then the Client sends a Bootstrap 628 TLV and the Transport Converter replies with the Supported TCP 629 Options TLV that lists the TCP options that it supports (section 630 Section 4.3.5). 632 With the TFO Cookie of the Transport Converter, the Client can 633 request the establishment of connections to remote servers with the 634 Connect TLV (see Section 4.3.1). If the connection can be 635 established with the final server, the Transport Converter replies 636 with the Extended TCP Header TLV and returns an Error TLV inside a 637 RST packet (see section Section 4.3.3). 639 4.3.1. Connect TLV 641 This TLV (Figure 11) is used to request the establishment of a 642 connection via a Transport Converter. 644 The 'Remote Peer Port' and 'Remote Peer IP Address' fields contain 645 the destination port and IP address of the target server for an 646 outgoing connection towards a server located on the Internet. For 647 incoming connections destined to a client serviced via a Converter, 648 these fields convey the source port and IP address. 650 The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 651 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format 652 defined in [RFC4291]. 654 The optional 'TCP Options' field is used to specify how specific TCP 655 Options should be advertised by the Transport Converter to the final 656 destination of a connection. If this field is not supplied, the 657 Transport Converter MUST use the default TCP options that correspond 658 to its local policy. 660 1 2 3 661 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 662 +---------------+---------------+-------------------------------+ 663 | Type | Length | Remote Peer Port | 664 +---------------+---------------+-------------------------------+ 665 | | 666 | Remote Peer IP Address (128 bits) | 667 | | 668 | | 669 +---------------------------------------------------------------+ 670 | TCP Options (Variable) | 671 | ... | 672 +---------------------------------------------------------------+ 674 Figure 11: The Connect TLV 676 The 'TCP Options' field is a variable length field that carries a 677 list of TCP Option fields (Figure 12). Each TCP Option field is 678 encoded as a block of 2+n bytes where the first byte is the TCP 679 Option Type and the second byte is the length of the TCP Option as 680 specified in [RFC0793]. The minimum value for the TCP Option Length 681 is 2. The TCP Options that do not include a length subfield, i.e., 682 option types 0 (EOL) and 1 (NOP) defined in [RFC0793] cannot be 683 placed inside the TCP Options field of the Connect TLV. The optional 684 Value field contains the variable-length part of the TCP option. A 685 length of two indicates the absence of the Value field. The TCP 686 Options field always ends on a 32 bits boundary after being padded 687 with zeros. 689 1 2 3 690 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 691 +---------------+---------------+---------------+---------------+ 692 | TCPOpt type | TCPOpt Length | Value (opt) | .... | 693 +---------------+---------------+---------------+---------------+ 694 | .... | 695 +---------------------------------------------------------------+ 696 | ... | 697 +---------------------------------------------------------------+ 699 Figure 12: The TCP Options field 701 If a Transport Converter receives a Connect TLV with a non-empty TCP 702 Options field, it shall present those options to the destination peer 703 in addition to the TCP Options that it would have used according to 704 its local policies. For the TCP Options that are listed without an 705 optional value, the Converter MUST generate its own value. For the 706 TCP Options that are included in the 'TCP Options' field with an 707 optional value, it shall copy the entire option for use in the 708 connection with the destination peer. This feature is required to 709 support TCP Fast Open. 711 4.3.2. Extended TCP Header TLV 713 The Extended TCP Header TLV is used by the Transport Converter to 714 send to the Client the extended TCP header that was returned by the 715 Server in the SYN+ACK packet. This TLV is only sent if the Client 716 sent a Connect TLV to request the establishment of a connection. 718 1 2 3 719 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 720 +---------------+---------------+-------------------------------+ 721 | Type | Length | Reserved | 722 +---------------+---------------+-------------------------------+ 723 | Returned Extended TCP header | 724 | ... | 725 +---------------------------------------------------------------+ 727 Figure 13: The Extended TCP Header TLV 729 The Returned Extended TCP header field is a copy of the extended 730 header that was received in the SYN+ACK by the Transport Converter. 731 The Reserved field is set to zero by the transmitter and ignored by 732 the receiver. 734 4.3.3. Error TLV 736 This optional TLV can be used by the Transport Converter to provide 737 information about some errors that occurred during the processing of 738 a request to convert a connection. This TLV appears after the 739 Converter header in a RST segment returned by the Transport Converter 740 if the error is fatal and prevented the establishment of the 741 connection. If the error is not fatal and the connection could be 742 established with the final destination, then the error TLV will be 743 carried in the payload. 745 1 2 3 746 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 747 +---------------+---------------+----------------+--------------+ 748 | Type | Length | Error | Value | 749 +---------------+---------------+----------------+--------------+ 751 Figure 14: The Error TLV 753 Different types of errors can occur while processing Converter 754 protocol messages. Each error is identified by a code represented as 755 an unsigned integer. Four classes of errors are defined: 757 o Message validation and processing errors (0<= error code <= 31): 758 returned upon reception of an an invalid message (including valid 759 messages but with invalid or unknown TLVs). 761 o Client-side errors (32<= error code <= 63): the Client sent a 762 request that could not be accepted by the Converter (e.g., 763 unsupported operation). 765 o Converter-side errors (64<= error code <96) : problems encountered 766 on the Converter (e.g., lack of ressources) which prevent it from 767 fulfilling the Client's request. 769 o Errors caused by destination server (96<= error code <= 127) : the 770 final destination could not be reached or it replied with a reset 771 message. 773 The following errors are defined in this document: 775 o Unsupported Version (0): The version number indicated in the fixed 776 header of a message received from a peer is not supported. This 777 error code MUST be generated by a Converter when it receives a 778 request having a version number that it does not support. The 779 value field MUST be set to the version supported by the Converter. 780 When multiple versions are supported by the converter, it includes 781 the list of supported version in the value field; each version is 782 encoded in 8 bits. Upon receipt of this error code, the client 783 checks whether it supports one of the versions returned by the 784 Converter. The highest common supported version MUST be used by 785 the client in subsequent exchanges with the Converter. 787 o Malformed Message (1): This error code is sent to indicate that a 788 message can not be successfully parsed. To ease troubleshooting, 789 the value field MUST echo the received message. The Converter and 790 the Client MUST send a RST containing this error upon reception of 791 a malformed message. 793 o Unsupported Message (2): This error code is sent to indicate that 794 a message type is not supported by the converter. To ease 795 troubleshooting, the value field MUST echo the received message. 796 The Converter and the Client MUST send a RST containing this error 797 upon reception of an unsupported message. 799 o Not Authorized (32): This error code indicates that the Converter 800 refused to create a connection because of a lack of authorization 801 (e.g., administratively prohibited, authorization failure, etc.). 802 The Value field is set to zero. This error code MUST be sent by 803 the Converter when a request cannot be successfully processed 804 because the authorization failed. 806 o Unsupported TCP Option (33). A TCP Option that the Client 807 requested to advertise to the final Server is not supported by the 808 Transport Converter. The Value field is set to the type of the 809 unsupported TCP Option. If several unsupported TCP Options were 810 specified in the Connect TLV, only one of them is returned in the 811 Value. 813 o Resource Exceeded (64): This error indicates that the Transport 814 Converter does not have enough resources to perform the request. 815 This error MUST be sent by the Converter when it does not have 816 sufficient resources to handle a new connection. 818 o Network Failure (65): This error indicates that the converter is 819 experiencing a network failure to relay the request. The 820 converter MUST send this error code when it experiences forwarding 821 issues to relay a connection. 823 o Connection Reset (96): This error indicates that the final 824 destination responded with a RST packet. The Value field is set 825 to zero. 827 o Destination Unreachable (97): This error indicates that an ICMP 828 destination unreachable, port unreachable, or network unreachable 829 was received by the Converter. The Value field contains the Code 830 field of the received ICMP message. This error message MUST be 831 sent by the Converter when it receives an error message that is 832 bound to a message it relayed previously. 834 Table 2 summarizes the different error codes. 836 +-------+------+-------------------------+ 837 | Error | Hex | Description | 838 +-------+------+-------------------------+ 839 | 0 | 0x00 | Unsupported version | 840 | | | | 841 | 1 | 0x01 | Malformed Message | 842 | | | | 843 | 2 | 0x02 | Unsupported Message | 844 | | | | 845 | 32 | 0x20 | Not Authorized | 846 | | | | 847 | 33 | 0x21 | Unsupported TCP Option | 848 | | | | 849 | 64 | 0x40 | Resource Exceeded | 850 | | | | 851 | 65 | 0x41 | Network Failure | 852 | | | | 853 | 96 | 0x60 | Connection Reset | 854 | | | | 855 | 97 | 0x61 | Destination Unreachable | 856 +-------+------+-------------------------+ 858 Table 2: The different error codes 860 4.3.4. The Bootstrap TLV 862 The Bootstrap TLV is sent by a Client to request the TCP Extensions 863 that are supported by a Transport Converter. It is typically sent on 864 the first connection that a Client establishes with a Transport 865 Converter to learn its capabilities. The Transport Converter replies 866 with the Supported TCP Options TLV described in Section 4.3.5. 868 1 2 3 869 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 870 +---------------+---------------+-------------------------------+ 871 | Type | Length | Zero | 872 +---------------+---------------+-------------------------------+ 874 Figure 15: The Bootstrap TLV 876 4.3.5. Supported TCP Options TLV 878 The Supported TCP Options TLV is used by a Converter to announce the 879 TCP options that it supports. Each supported TCP Option is encoded 880 with its TCP option Kind listed in the TCP Parameters registry 881 maintained by IANA. TCP option Kinds 0, 1, and 2 defined in 882 [RFC0793] are supported by all TCP implementations and thus cannot 883 appear in this list. The list of supported TCP Options is padded 884 with 0 to end on a 32 bits boundary. 886 1 2 3 887 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 888 +---------------+---------------+-------------------------------+ 889 | Type | Length | Reserved | 890 +---------------+---------------+-------------------------------+ 891 | Kind #1 | Kind #2 | ... | 892 +---------------+---------------+-------------------------------+ 893 / ... / 894 / / 895 +---------------------------------------------------------------+ 897 Figure 16: The Supported TCP Options TLV 899 5. Interactions with middleboxes 901 The Converter protocol was designed to be used in networks that do 902 not contain middleboxes that interfere with TCP. We describe in this 903 section how a Client can detect middlebox interference and stop using 904 the Transport Converter affected by this interference. 906 Internet measurements [IMC11] have shown that middleboxes can affect 907 the deployment of TCP extensions. In this section, we only discuss 908 the middleboxes that modify SYN and SYN+ACK packets since the 909 Converter protocol places its messages in such packets. 911 Let us first consider a middlebox that removes the TFO Option from 912 the SYN packet. This interference will be detected by the Client 913 during the bootstrap procedure shown in Figure 5. A Client should 914 not use a Transport Converter that does not reply with the TFO option 915 during the Bootstrap. 917 Consider a middlebox that removes the SYN payload after the bootstrap 918 procedure. The Client can detect this problem by looking at the 919 acknowledgement number field of the SYN+ACK returned by the Transport 920 Converter. The Client should stop to use this Transport Converter 921 given the middlebox interference. 923 As explained in [RFC7413], some carrier-grade NATs can affect the 924 operation of TFO if they assign different IP addresses to the same 925 end host. Such carrier-grade NATs could affect the operation of the 926 TFO Option used by the Converter protocol. See also the discussion 927 in section 7.1 of [RFC7413]. 929 6. Security Considerations 931 6.1. Privacy & Ingress Filtering 933 The Converter may have access to privacy-related information (e.g., 934 subscriber credentials). The Converter MUST NOT leak such sensitive 935 information outside a local domain. 937 Given its function and its location in the network, a Transport 938 Converter has access to the payload of all the packets that it 939 processes. As such, it must be protected as a core IP router. 941 Furthermore, ingress filtering policies MUST be enforced at the 942 network boundaries [RFC2827]. 944 This document assumes that all network attachements are managed by 945 the same administrative entity. Therefore, enforcing anti-spoofing 946 filters at these network ensures that hosts are not sending traffic 947 with spoofed source IP addresses. 949 6.2. Authorization 951 The Converter protocol is intended to be used in managed networks 952 where end hosts can be identified by their IP address. Thanks to the 953 Bootstrap procedure (Figure 5), the Transport Converter can verify 954 that the Client correctly receives packets sent by the Converter. 955 Stronger authentication schemes should be defined to use the 956 Converter protocol in more open network environments. 958 See below for authorization considerations that are specific for 959 Multipath TCP. 961 6.3. Denial of Service 963 Another possible risk is the amplification attacks since a Transport 964 Converter sends a SYN towards a remote Server upon reception of a SYN 965 from a Client. This could lead to amplification attacks if the SYN 966 sent by the Transport Converter were larger than the SYN received 967 from the Client or if the Transport Converter retransmits the SYN. 968 To mitigate such attacks, the Transport Converter SHOULD rate limit 969 the number of pending requests for a given Client. It SHOULD also 970 avoid sending to remote Servers SYNs that are significantly longer 971 than the SYN received from the Client. In practice, Transport 972 Converters SHOULD NOT advertise to a Server TCP Options that were not 973 specified by the Client in the received SYN. Finally, the Transport 974 Converter SHOULD only retransmit a SYN to a Server after having 975 received a retransmitted SYN from the corresponding Client. 977 Upon reception of a SYN that contains a valid TFO Cookie and a 978 Connect TLV, the Transport Converter attempts to establish a TCP 979 connection to a remote Server. There is a risk of denial of service 980 attack if a Client requests too many connections in a short period of 981 time. Implementations SHOULD limit the number of pending connections 982 from a given Client. Means to protect against SYN flooding attacks 983 MUST also be enabled [RFC4987]. 985 6.4. Traffic Theft 987 Traffic theft is a risk if an illegitimate Converter is inserted in 988 the path. Indeed, inserting an illegitimate Converter in the 989 forwarding path allows traffic interception and can therefore provide 990 access to sensitive data issued by or destined to a host. Converter 991 discovery and configuration are out of scope of this document. 993 6.5. Multipath TCP-specific Considerations 995 Multipath TCP-related security threats are discussed in [RFC6181] and 996 [RFC6824]. 998 The operator that manages the various network attachments (including 999 the Converters) can enforce authentication and authorization policies 1000 using appropriate mechanisms. For example, a non-exhaustive list of 1001 methods to achieve authorization is provided hereafter: 1003 o The network provider may enforce a policy based on the 1004 International Mobile Subscriber Identity (IMSI) to verify that a 1005 user is allowed to benefit from the aggregation service. If that 1006 authorization fails, the Packet Data Protocol (PDP) context/bearer 1007 will not be mounted. This method does not require any interaction 1008 with the Converter. 1010 o The network provider may enforce a policy based upon Access 1011 Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) 1012 to control the hosts that are authorized to communicate with a 1013 Converter. These ACLs may be installed as a result of RADIUS 1014 exchanges, e.g. [I-D.boucadair-mptcp-radius]. This method does 1015 not require any interaction with the Converter. 1017 o A device that embeds the Converter may also host a RADIUS client 1018 that will solicit an AAA server to check whether connections 1019 received from a given source IP address are authorized or not 1020 [I-D.boucadair-mptcp-radius]. 1022 A first safeguard against the misuse of Converter resources by 1023 illegitimate users (e.g., users with access networks that are not 1024 managed by the same provider that operates the Converter) is the 1025 Converter to reject Multipath TCP connections received on its 1026 Internet-facing interfaces. Only Multipath PTCP connections received 1027 on the customer-facing interfaces of a Converter will be accepted. 1029 7. IANA Considerations 1031 This document requests the allocation of a reserved service name and 1032 port number for the converter protocol at https://www.iana.org/ 1033 assignments/service-names-port-numbers/ 1034 service-names-port-numbers.xhtml. 1036 This documents specifies version 1 of the Converter protocol. Five 1037 types of Converter messages are defined: 1039 o 1: Bootstrap TLV 1041 o 10: Connect TLV 1043 o 20: Extended TCP Header TLV 1045 o 21: Supported TCP Options TLV 1047 o 30: Error TLV 1049 Furthermore, it also defines the following error codes: 1051 +-------+------+-------------------------+ 1052 | Error | Hex | Description | 1053 +-------+------+-------------------------+ 1054 | 0 | 0x00 | Unsupported version | 1055 | | | | 1056 | 1 | 0x01 | Malformed Message | 1057 | | | | 1058 | 2 | 0x02 | Unsupported Message | 1059 | | | | 1060 | 32 | 0x20 | Not Authorized | 1061 | | | | 1062 | 33 | 0x21 | Unsupported TCP Option | 1063 | | | | 1064 | 64 | 0x40 | Resource Exceeded | 1065 | | | | 1066 | 65 | 0x41 | Network Failure | 1067 | | | | 1068 | 96 | 0x60 | Connection Reset | 1069 | | | | 1070 | 97 | 0x61 | Destination Unreachable | 1071 +-------+------+-------------------------+ 1073 Table 3: The different error codes 1075 8. Acknowledgements 1077 Although they could disagree with the contents of the document, we 1078 would like to thank Joe Touch and Juliusz Chroboczek whose comments 1079 on the MPTCP mailing list have forced us to reconsider the design of 1080 the solution several times. 1082 We would like to thank Raphael Bauduin and Stefano Secci for their 1083 help in preparing this draft. Sri Gundavelli and Nandini Ganesh 1084 provided valuable feedback about the handling of TFO and the error 1085 codes. Thanks to them. 1087 This document builds upon earlier documents that proposed various 1088 forms of Multipath TCP proxies [I-D.boucadair-mptcp-plain-mode], 1089 [I-D.peirens-mptcp-transparent] and [HotMiddlebox13b]. 1091 From [I-D.boucadair-mptcp-plain-mode]: 1093 Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi 1094 Nishida, and Christoph Paasch for their valuable comments. 1096 Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and 1097 Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos 1098 Aires). 1100 Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and 1101 Xavier Grall for their inputs. 1103 Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas 1104 Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves 1105 Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun 1106 Srinivasan, and Raghavendra Mallya for the discussion. 1108 8.1. Contributors 1110 As noted above, this document builds on two previous documents. 1112 The authors of [I-D.boucadair-mptcp-plain-mode] were: - Mohamed 1113 Boucadair - Christian Jacquenet - Olivier Bonaventure - Denis 1114 Behaghel - Stefano Secci - Wim Henderickx - Robert Skog - Suresh 1115 Vinapamula - SungHoon Seo - Wouter Cloetens - Ullrich Meyer - Luis M. 1116 Contreras - Bart Peirens 1118 The authors of [I-D.peirens-mptcp-transparent] were: - Bart Peirens - 1119 Gregory Detal - Sebastien Barre - Olivier Bonaventure 1121 9. References 1123 9.1. Normative References 1125 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1126 RFC 793, DOI 10.17487/RFC0793, September 1981, 1127 . 1129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1130 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1131 RFC2119, March 1997, 1132 . 1134 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1135 Architecture", RFC 4291, DOI 10.17487/RFC4291, 1136 February 2006, . 1138 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1139 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1140 . 1142 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1143 "TCP Extensions for Multipath Operation with Multiple 1144 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1145 . 1147 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1148 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1149 . 1151 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1152 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1153 May 2017, . 1155 9.2. Informative References 1157 [ANRW17] Trammell, B., Kuhlewind, M., De Vaere, P., Learmonth, I., 1158 and G. Fairhurst, "Tracking transport-layer evolution with 1159 PATHspider", Applied Networking Research Workshop 2017 1160 (ANRW17) , July 2017. 1162 [Fukuda2011] 1163 Fukuda, K., "An Analysis of Longitudinal TCP Passive 1164 Measurements (Short Paper)", Traffic Monitoring and 1165 Analysis. TMA 2011. Lecture Notes in Computer Science, vol 1166 6613. , 2011. 1168 [HotMiddlebox13b] 1169 Detal, G., Paasch, C., and O. Bonaventure, "Multipath in 1170 the Middle(Box)", HotMiddlebox'13 , December 2013, . 1173 [I-D.arkko-arch-low-latency] 1174 Arkko, J. and J. Tantsura, "Low Latency Applications and 1175 the Internet Architecture", 1176 draft-arkko-arch-low-latency-02 (work in progress), 1177 October 2017. 1179 [I-D.boucadair-mptcp-plain-mode] 1180 Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, 1181 D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 1182 Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., 1183 Contreras, L., and B. Peirens, "Extensions for Network- 1184 Assisted MPTCP Deployment Models", 1185 draft-boucadair-mptcp-plain-mode-10 (work in progress), 1186 March 2017. 1188 [I-D.boucadair-mptcp-radius] 1189 Boucadair, M. and C. Jacquenet, "RADIUS Extensions for 1190 Network-Assisted Multipath TCP (MPTCP)", 1191 draft-boucadair-mptcp-radius-05 (work in progress), 1192 October 2017. 1194 [I-D.ietf-mptcp-rfc6824bis] 1195 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1196 Paasch, "TCP Extensions for Multipath Operation with 1197 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-09 (work 1198 in progress), July 2017. 1200 [I-D.ietf-tcpinc-tcpcrypt] 1201 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1202 Q., and E. Smith, "Cryptographic protection of TCP Streams 1203 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-11 (work in 1204 progress), November 2017. 1206 [I-D.olteanu-intarea-socks-6] 1207 Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6", 1208 draft-olteanu-intarea-socks-6-01 (work in progress), 1209 October 2017. 1211 [I-D.peirens-mptcp-transparent] 1212 Peirens, B., Detal, G., Barre, S., and O. Bonaventure, 1213 "Link bonding with transparent Multipath TCP", 1214 draft-peirens-mptcp-transparent-00 (work in progress), 1215 July 2016. 1217 [IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment", 1218 IETF Journal, Fall 2016 , n.d.. 1220 [IMC11] Honda, K., Nishida, Y., Raiciu, C., Greenhalgh, A., 1221 Handley, M., and T. Hideyuki, "Is it still possible to 1222 extend TCP ?", Proceedings of the 2011 ACM SIGCOMM 1223 conference on Internet measurement conference , 2011. 1225 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 1226 RFC 1919, DOI 10.17487/RFC1919, March 1996, 1227 . 1229 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1230 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1231 DOI 10.17487/RFC1928, March 1996, 1232 . 1234 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1235 Selective Acknowledgment Options", RFC 2018, DOI 10.17487/ 1236 RFC2018, October 1996, 1237 . 1239 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1240 Defeating Denial of Service Attacks which employ IP Source 1241 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1242 May 2000, . 1244 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1245 Shelby, "Performance Enhancing Proxies Intended to 1246 Mitigate Link-Related Degradations", RFC 3135, 1247 DOI 10.17487/RFC3135, June 2001, 1248 . 1250 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 1251 Multipath Operation with Multiple Addresses", RFC 6181, 1252 DOI 10.17487/RFC6181, March 2011, 1253 . 1255 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1256 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, 1257 April 2012, . 1259 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1260 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1261 DOI 10.17487/RFC6887, April 2013, 1262 . 1264 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 1266 Scheffenegger, Ed., "TCP Extensions for High Performance", 1267 RFC 7323, DOI 10.17487/RFC7323, September 2014, 1268 . 1270 [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. 1271 Zimmermann, "A Roadmap for Transmission Control Protocol 1272 (TCP) Specification Documents", RFC 7414, DOI 10.17487/ 1273 RFC7414, February 2015, 1274 . 1276 Authors' Addresses 1278 Olivier Bonaventure 1279 Tessares 1281 Email: Olivier.Bonaventure@tessares.net 1283 Mohamed Boucadair 1284 Orange 1286 Email: mohamed.boucadair@orange.com 1288 Bart Peirens 1289 Proximus 1291 Email: bart.peirens@proximus.com 1293 SungHoon Seo 1294 Korea Telecom 1296 Email: sh.seo@kt.com 1298 Anandatirtha Nandugudi 1299 Tessares 1301 Email: anand.nandugudi@tessares.net