idnits 2.17.1 draft-boucadair-mptcp-plain-mode-10.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 (March 9, 2017) is 2567 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-06) exists of draft-barre-mptcp-tfo-01 == Outdated reference: A later version (-08) exists of draft-boucadair-mptcp-dhc-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft C. Jacquenet, Ed. 4 Intended status: Standards Track Orange 5 Expires: September 10, 2017 O. Bonaventure, Ed. 6 Tessares 7 D. Behaghel 8 OneAccess 9 S. Secci 10 UPMC 11 W. Henderickx, Ed. 12 Nokia/Alcatel-Lucent 13 R. Skog, Ed. 14 Ericsson 15 S. Vinapamula 16 Juniper 17 S. Seo 18 Korea Telecom 19 W. Cloetens 20 SoftAtHome 21 U. Meyer 22 Vodafone 23 LM. Contreras 24 Telefonica 25 B. Peirens 26 Proximus 27 March 9, 2017 29 Extensions for Network-Assisted MPTCP Deployment Models 30 draft-boucadair-mptcp-plain-mode-10 32 Abstract 34 Because of the lack of Multipath TCP (MPTCP) support at the server 35 side, some service providers now consider a network-assisted model 36 that relies upon the activation of a dedicated function called MPTCP 37 Conversion Point (MCP). Network-Assisted MPTCP deployment models are 38 designed to facilitate the adoption of MPTCP for the establishment of 39 multi-path communications without making any assumption about the 40 support of MPTCP by the communicating peers. MCPs located in the 41 network are responsible for establishing multi-path communications on 42 behalf of endpoints, thereby taking advantage of MPTCP capabilities 43 to achieve different goals that include (but are not limited to) 44 optimization of resource usage (e.g., bandwidth aggregation), of 45 resiliency (e.g., primary/backup communication paths), and traffic 46 offload management. 48 This document specifies extensions for Network-Assisted MPTCP 49 deployment models. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Status of This Memo 59 This Internet-Draft is submitted in full conformance with the 60 provisions of BCP 78 and BCP 79. 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF). Note that other groups may also distribute 64 working documents as Internet-Drafts. The list of current Internet- 65 Drafts is at http://datatracker.ietf.org/drafts/current/. 67 Internet-Drafts are draft documents valid for a maximum of six months 68 and may be updated, replaced, or obsoleted by other documents at any 69 time. It is inappropriate to use Internet-Drafts as reference 70 material or to cite them other than as "work in progress." 72 This Internet-Draft will expire on September 10, 2017. 74 Copyright Notice 76 Copyright (c) 2017 IETF Trust and the persons identified as the 77 document authors. All rights reserved. 79 This document is subject to BCP 78 and the IETF Trust's Legal 80 Provisions Relating to IETF Documents 81 (http://trustee.ietf.org/license-info) in effect on the date of 82 publication of this document. Please review these documents 83 carefully, as they describe your rights and restrictions with respect 84 to this document. Code Components extracted from this document must 85 include Simplified BSD License text as described in Section 4.e of 86 the Trust Legal Provisions and are provided without warranty as 87 described in the Simplified BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 92 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 93 3. Target Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 94 3.1. Multipath Client . . . . . . . . . . . . . . . . . . . . 6 95 3.2. Multipath CPE . . . . . . . . . . . . . . . . . . . . . . 7 96 4. The MP_PREFER_PROXY MPTCP Option . . . . . . . . . . . . . . 8 97 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 98 4.2. Option Processing . . . . . . . . . . . . . . . . . . . . 8 99 5. Supplying Data to MCPs . . . . . . . . . . . . . . . . . . . 9 100 5.1. The MP_CONVERT Information Element . . . . . . . . . . . 9 101 5.2. Processing an MP_CONVERT Information Element . . . . . . 11 102 6. MPTCP Connections from a Multipath TCP Client . . . . . . . . 13 103 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 13 104 6.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 14 105 7. MPTCP Connections Between Single Path Client and Server . . . 16 106 7.1. Description . . . . . . . . . . . . . . . . . . . . . . . 16 107 7.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 17 108 7.2.1. Downstream MCP . . . . . . . . . . . . . . . . . . . 17 109 7.2.2. Upstream MCP . . . . . . . . . . . . . . . . . . . . 17 110 8. Interaction with TFO . . . . . . . . . . . . . . . . . . . . 19 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 112 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 113 10.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 21 114 10.2. Denial-of-Service (DoS) . . . . . . . . . . . . . . . . 21 115 10.3. Illegitimate MCP . . . . . . . . . . . . . . . . . . . . 21 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 118 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 119 12.2. Informative References . . . . . . . . . . . . . . . . . 22 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 122 1. Introduction 124 The overall quality of connectivity services can be enhanced by 125 combining several access network links for various purposes - 126 resource optimization, better resiliency, etc. Some transport 127 protocols, such as Multipath TCP [RFC6824], can help achieve such 128 better quality, but failed to be massively deployed so far. 130 The support of multipath transport capabilities by communicating 131 hosts remains a privileged target design so that such hosts can 132 directly use the available resources provided by a variety of access 133 networks they can connect to. Nevertheless, network operators do not 134 control end hosts while the support of MPTCP by content servers 135 remains close to zero. 137 Network-Assisted MPTCP deployment models are designed to facilitate 138 the adoption of MPTCP for the establishment of multi-path 139 communications without making any assumption about the support of 140 MPTCP capabilities by communicating peers. Network-Assisted MPTCP 141 deployment models rely upon MPTCP Conversion Points (MCPs) that act 142 on behalf of hosts so that they can take advantage of establishing 143 communications over multiple paths. MCPs can be deployed in CPEs 144 (Customer Premises Equipment), as well as in the provider's network. 145 MCPs are responsible for establishing multi-path communications on 146 behalf of endpoints. Further details about the target use cases are 147 provided in Section 3. 149 Most of the current operational deployments that take advantage of 150 multi-interfaced devices rely upon the use of an encapsulation scheme 151 (such as [I-D.zhang-gre-tunnel-bonding], [TR-348]). The use of 152 encapsulation is motivated by the need to steer traffic towards the 153 concentrator and also to allow the distribution of any kind of 154 traffic besides TCP (e.g., UDP) among the available paths without 155 requiring any advanced traffic engineering tweaking technique in the 156 network to intercept traffic and redirect it towards the appropriate 157 MCP. 159 Current operational MPTCP deployments by network operators are 160 focused on the forwarding of TCP traffic. The design of such 161 deployments sometimes assumes the use of extra signalling provided by 162 SOCKS [RFC1928], at the cost of additional management complexity and 163 possible service degradation (e.g., up to 6 SOCKS messages may have 164 to be exchanged between two MCPs before actual payload data to be 165 transferred, thereby yielding several tens of milliseconds of extra 166 delay before the connection is established) . 168 To avoid the burden of encapsulation and additional signalling 169 between MCPs, this document explains how a plain transport mode is 170 enabled, so that packets are exchanged between a device and its 171 upstream MCP without requiring the activation of any encapsulation 172 scheme (e.g., IP-in-IP [RFC2473], GRE [RFC1701]). This plain 173 transport mode also avoids the need for out-of-band signalling, 174 unlike the aforementioned SOCKS context. 176 The solution described in this document also works properly when NATs 177 are present in the communication path between a device and its 178 upstream MCP. In particular, the solution in this document 179 accommodates deployments that involve CGN (Carrier Grade NAT) 180 upstream the MCP. 182 Network-Assisted MPTCP deployment and operational considerations are 183 discussed in [I-D.nam-mptcp-deployment-considerations]. 185 The plain transport mode is characterized as follows: 187 o 0-RTT proxy. 188 o No encapsulation required (no tunnels, whatsoever). 189 o No out-of-band signaling for each MPTCP subflow is required. 190 o Targets both on-path and off-path MCPs. 191 o Avoids interference with native MPTCP connections. 192 o Assists MPTCP connections even if endpoints are MPTCP-capable. 193 o Accommodates various deployment contexts, such as those that 194 require the preservation of the source IP address and others 195 characterized by an address sharing design. In particular: 197 * This solution is compatible with IPv4/IPv6. 198 * This solution does not impose any constraint on the addressing 199 scheme to be used by the client. 200 * This solution does not require nor exclude the use of distinct 201 IP prefix pools for network-assisted MPTCP deployments. 202 * This solution supports both transparent and non-transparent 203 operations. 205 2. Terminology 207 The reader should be familiar with the terminology defined in 208 [RFC6824]. 210 This document makes use of the following terms: 212 o Client: an endhost that initiates transport flows forwarded along 213 a single path. Such endhost is not assumed to support multipath 214 transport capabilities. 216 o Server: an endhost that communicates with a client. Such endhost 217 is not assumed to support multipath transport capabilities. 219 o Multipath Client: a Client that supports multipath transport 220 capabilities. 222 o Multipath Server: a Server that supports multipath transport 223 capabilities. Both the client and the server can be single-homed 224 or multi-homed. However, for the use cases discussed in this 225 document, the number of interfaces available at the endhosts is 226 not relevant. 228 o Transport flow: a sequence of packets that belong to a 229 unidirectional transport flow and which share at least one common 230 characteristic (e.g., the same destination address). TCP and SCTP 231 flows are composed of packets that have the same source and 232 destination addresses, the same protocol number and the same 233 source and destination ports. 235 o Multipath Conversion Point (MCP): a function that terminates a 236 transport flow and relays all data carried in the flow into 237 another transport flow. 239 MCP is a function that converts a multipath transport flow and 240 relays it over a single path transport flow and vice versa. 242 3. Target Use Cases 244 We consider two important use cases in this document. We briefly 245 introduce them in this section and leave the details to Section 6 and 246 Section 7. The first use case is a Multipath Client that interacts 247 with a remote Server through a MCP (Section 3.1). The second use 248 case is a multi-homed CPE that includes a MCP and interacts with a 249 remote Server through a downstream MCP (Section 3.2). 251 3.1. Multipath Client 253 In this use case, the Multipath Client would like to take advantage 254 of MPTCP even if the Server does not support MPTCP. A typical 255 example is a smartphone that could use both WLAN and LTE access 256 networks to reach a server in order to achieve higher bandwidth or 257 better resilience. 259 +--+ +-----+ +--+ 260 |C | | MCP | |S | 261 +--+ +-----+ +--+ 262 | | | 263 |<==================MPTCP Leg==============>|<---TCP -->| 264 | | | 266 Legend: 267 C: Client 268 MCP: Multipath Conversion Point 269 S: Server 271 Figure 1: Network-assisted MPTCP (Host-based Model) 273 In reference to Figure 1, the MCP terminates the MPTCP connection 274 established by the client and binds it to a TCP connection towards 275 the remote server. Two deployments of this use case are possible. 277 A first deployment is when the MCP is on the path between the 278 Multipath Client and the Server. In this case, the MCP can terminate 279 the MPTCP connection initiated by the Client and binds it to a TCP 280 connection that the MCP establishes with the Server. When the MCP is 281 not located on all default forwarding paths, the MPTCP connection 282 must be initiated by using the path where the MCP is located. 284 A second deployment is when the MCP is not on the path between the 285 Multipath Client and the Server. In this case, the Client must first 286 initiate a connection towards the MCP and request it to initiate a 287 TCP connection towards the Server. This is what the SOCKS protocol 288 performs by exchanging control messages to create appropriate 289 mappings to handle the connection. Unfortunately, this requires 290 additional round-trip-time that affects the performance of the end- 291 to-end data transfer, in particular for short-lived connections. 293 This document specifies the MP_CONVERT Information Element that is 294 carried in the SYN segment of the initial subflow. This SYN segment 295 is sent towards the MCP. The MP_CONVERT Information Element contains 296 the destination address (and optionally a port number) of the Server. 297 Thanks to this information, the MCP can immediately establish the TCP 298 connection with the Server without any additional round-trip-time, 299 unlike a SOCKS-based MPTCP design. 301 3.2. Multipath CPE 303 In this use case, neither the Client nor the Server support MPTCP. 304 Two MCPs are used as illustrated in Figure 2. The upstream MCP is 305 embedded in the CPE while the downstream MCP is located in the 306 provider's network. The CPE is attached to multiple access networks 307 (e.g., xDSL and LTE). The upstream MCP transparently terminates the 308 TCP connections initiated by the Client and converts them into MPTCP 309 connections. 311 Upstream Downstream 312 +--+ +-----+ +-----+ +--+ 313 |H1| | MCP | | MCP | |RM| 314 +--+ +-----+ +-----+ +--+ 315 | | | | 316 |<---TCP--->|<========MPTCP Leg===========>|<---TCP--->| 317 | | | | 319 Figure 2: Network-assisted MPTCP (CPE-based Model) 321 The same considerations detailed in Section 3.1 apply for the 322 insertion of the downstream MCP in an MPTCP connection. 324 4. The MP_PREFER_PROXY MPTCP Option 326 The implicit mode assumes that the MCP is located on a default 327 forwarding path (Section 5.2.2 of 328 [I-D.nam-mptcp-deployment-considerations]). In such mode, the first 329 subflow must always be placed over that primary path so that the MCP 330 can intercept MPTCP flows. Once intercepted, the MCP advertises its 331 reachability information by means of MPTCP signals (MP_JOIN or 332 ADD_ADDR). 334 In order to distinguish native MPTCP connections from proxied ones, a 335 new MPTCP option, called MP_PREFER_PROXY, is defined. This option is 336 meant to inform an on-path MCP that the connection should be proxied. 337 The absence of the MP_PREFER_PROXY option is an indication that the 338 corresponding MPTCP connection is native: an on-path MCP must not be 339 involved in such connection. If no explicit signal is included in 340 the initial SYN message, the MCP cannot distinguish "native" MPTCP 341 connections from "proxied" ones. 343 4.1. Option Format 345 The format of the MP_PREFER_PROXY is shown in Figure 3. 347 1 2 3 348 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 349 +---------------+---------------+-------+-----------------------+ 350 | Kind | Length |Subtype| Reserved | 351 +---------------+---------------+-------+-----------------------+ 353 Figure 3: MP_PREFER_PROXY MPTCP Option 355 o Kind and Length: are the same as those defined in Section 3 of 356 [RFC6824]. The size of this option is 4 bytes. 358 o Subtype: must be allocated by IANA (Section 9). 360 o "Reserved" bits: are reserved bits for future assignment as 361 additional flag bits. These additional flag bits MUST each be set 362 to zero and MUST be ignored upon receipt. 364 4.2. Option Processing 366 The MP_PREFER_PROXY option MUST only appear in the SYN message used 367 to create the initial subflow of a Multipath TCP connection. 369 If the MP_PREFER_PROXY appears in either a SYN segment that does not 370 include the MP_CAPABLE option or a segment whose SYN flag is unset, 371 it MUST be ignored. An implementation MAY log this event since it 372 likely indicates an operational issue. 374 The sender inserts the MP_PREFER_PROXY option for MPTCP connections 375 that it wants to be proxied by an on-path MCP. Such insertion is 376 possible only when there is enough space left in the dedicated TCP 377 option space. 379 Upon receipt of a SYN message with an MP_CAPABLE, the MCP MUST check 380 whether an MP_PREFER_PROXY option is present: 382 o If no such option is included, the MCP MUST NOT interfere with 383 that MPTCP connection (that is, it must not track this MPTCP 384 connection). Processing subsequent subflows of this connection 385 will be handled directly by the endpoints. 387 o If the MP_PREFER_PROXY option is present, the MCP MUST track the 388 establishment of the connection. That means that the MCP must be 389 prepared to insert itself for the establishment of subsequent 390 subflows, in particular. 392 Section 5.2.2.1 of [I-D.nam-mptcp-deployment-considerations] details 393 the use of the MP_PREFER_PROXY option. 395 5. Supplying Data to MCPs 397 This section focuses mainly on th explicit mode (Section 5.2.1 of 398 [I-D.nam-mptcp-deployment-considerations]) which assumes that the IP 399 reachability information of an MCP is explicitly configured on a 400 device, e.g., by means of a specific DHCP option 401 [I-D.boucadair-mptcp-dhc]. 403 5.1. The MP_CONVERT Information Element 405 In order to avoid extra delays when establishing a proxied MPTCP 406 connection, specific information are provided to an MCP during the 407 3WHS. Such information is meant to help the MCP instantiate the 408 required states to process the connection upstream. The supply of 409 such information is achieved by means of an object called the 410 MP_CONVERT (MC) Information Element (IE). This information element 411 typically carries the source/destination IP addresses and/or port 412 numbers of the used by the source and destination endpoints. Other 413 information may also be supplied to an MCP; future extensions may be 414 defined. 416 The format of the MP_CONVERT Information Element is shown in 417 Figure 4. 419 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 420 +---------------------------------------------------------------+ 421 | Magic Number | 422 +---------------+---------------+---------------------------+-+-+ 423 | Type | Length | Reserved |D|M| 424 +---------------+---------------+---------------------------+-+-+ 425 | Address (IPv4 - 4 octets / IPv6 - 16 octets) | 426 +-------------------------------+-------------------------------+ 427 | Port (2 octets, optional) | 428 +-------------------------------+ 430 Figure 4: MP_CONVERT Information Element 432 The description of the fields is as follows: 434 o Magic Number: This field MUST be set to "0xFAA8 0xFAA8" to 435 indicate this is an MP_CONVERT Information Element. This field is 436 meant to unambiguously distinguish any data supplied by an 437 application from the one injected by an MCP. Other magic numbers 438 are considered by the authors (e.g., 64 bits that include in 439 addition to "0xFAA8 0xFAA8" 32 bits to enclose the RFC number). 441 o Type: This field indicates the type of the MP_CONVERT Information 442 Element. It MUST be set to 0 to indicate this element includes an 443 IP address and, eventually, a port number. Other type values MAY 444 be defined in the future. 446 o Length: Indicates, in bytes, the length of MP_CONVERT Information 447 Element. The minimum size of this option is 4 bytes. 449 o "Reserved" bits: are reserved bits for future assignment as 450 additional flag bits. These additional flag bits MUST each be set 451 to zero and MUST be ignored upon receipt. 453 o D-bit (Direction bit): this flag indicates whether the enclosed IP 454 address (and port number) reflects the source or the destination 455 IP address (and port number). When the D-bit is set, the enclosed 456 IP address must be interpreted as the source IP address. When the 457 D-bit is unset, the enclosed IP address must be interpreted as the 458 destination IP address. 460 o M-bit (More bit): When the M-bit is unset, it indicates that 461 another MP_CONVERT IE is included. When the M-bit is set, it 462 indicates this is the last MP_CONVERT IE included in the payload; 463 if any data is placed right after this MP_CONVERT IE, it is 464 application data. 466 o Address: includes a source or destination IP address. The address 467 family is determined by the "Length" field. Concretely, a 468 MP_CONVERT Information Element that carries an IPv4 address has a 469 Length field of 8 bytes (or 10, if a port number is included). A 470 MP_CONVERT Information Element that carries an IPv6 address has a 471 Length of 20 bytes (or 22, if a port number is included). 473 o Port: If the D-bit is set (resp. unset), a source (resp. 474 destination) port number may be associated with the IP address. 475 This field is valid for protocols that use a 16 bit port number 476 (e.g., UDP, TCP, SCTP). This field is optional. 478 If the length of MP_CONVERT Information Element is not a multiple of 479 4 bytes, padding MUST be added to preserve 32 bits boundaries. 481 5.2. Processing an MP_CONVERT Information Element 483 The MP_CONVERT Information Element is a variable length object that 484 MUST NOT be used in TCP segments whose SYN flag is unset. This IE 485 can only appear in the TCP control messages with SYN flag set. The 486 information carried in the MP_CONVERT IE is used by an MCP to create 487 the initial subflow of a Multipath TCP connection (see the example in 488 Figure 5). 490 Up to two MP_CONVERT Information Elements with type set to zero can 491 appear inside a SYN segment. If two MP_CONVERT Information Elements 492 with type zero are included, these options MUST NOT have the same 493 D-bit value. 495 +----+ +-----+ +--+ 496 | C | | MCP | |S | 497 +----+ +-----+ +--+ 498 | | ________________________________| | 499 | / Initial subflow \ | 500 | |========SYN(MP_CAPABLE+MC(S))===>| | 501 | | |--SYN------->| 502 | | |<--SYN/ACK---| 503 | |<====SYN/ACK(MP_CAPABLE)=========| | 504 | | ... | | 505 | \ ________________________________/ | 506 .... .... 507 | | ________________________________| | 508 | / Additional subflow \ | 509 | \ ________________________________/ | 511 Legend: 512 <===>: MPTCP leg 513 <--->: TCP leg 514 MC(): MP_CONVERT Information Element 516 Figure 5: Carrying the MP_CONVERT Information Element 518 The MP_CONVERT Information Element MUST be included in the payload of 519 a TCP segment whose SYN flag is set. 521 If the MP_CONVERT Information Element appears in either a SYN segment 522 that does not include the MP_CAPABLE option or a segment whose SYN 523 flag is reset, it MUST be ignored. An implementation MAY log this 524 event since it likely indicates an operational issue. 526 If the original SYN message contains data in its payload (e.g., 527 [RFC7413]), that data MUST be placed right after the MP_CONVERT IEs 528 when generating the SYN in the MPTCP leg. 530 An implementation MUST ignore MP_CONVERT Information Elements that 531 include multicast, broadcast, and host loopback addresses [RFC6890]. 532 Concretely, an implementation that receives an MP_CONVERT Information 533 Element with such addresses MUST silently tear down the MPTCP 534 connection. 536 An implementation that supports the MP_CONVERT Information Element 537 with type zero MUST echo in the SYN/ACK the instances of the 538 MP_CONVERT Information Elements included in a SYN received from the 539 sender. A sender that does not receive in a SYN/ACK a copy of the 540 MP_CONVERT Information Elements it included in a SYN message MUST 541 terminate the MPTCP connection and falls back to TCP or native MPTCP 542 connection. Furthermore, the sender MUST add an entry to its local 543 cache to record the MCPs that do not support the MP_CONVERT 544 Information Element. This cache MUST be flushed out under the 545 following conditions: a new network attachment is detected by the 546 host, a new MCP is configured, the host gets a new IP address/prefix, 547 or a TTL has expired. Subsequent connections to an MCP in the cache 548 MUST NOT be placed using the explicit proxy mode. This procedure is 549 denoted as MCP capability discovery. 551 In the following sections, MP_CONVERT Information Element is used to 552 refer to the MP_CONVERT Information Element with the type field set 553 to zero. Future documents will specify the exact behavior of 554 processing MP_CONVERT Information Elements with a non zero type 555 field. 557 6. MPTCP Connections from a Multipath TCP Client 559 6.1. Description 561 The simplest usage of the MP_CONVERT Information Element is when a 562 Multipath TCP Client wants to use MPTCP to efficiently utilise 563 different network paths (e.g., WLAN and LTE from a smartphone) to 564 reach a server that does not support Multipath TCP. The basic 565 operation is illustrated in Figure 6. 567 To use its multipath capabilities to establish an MPTCP connection 568 over the available networks, the Client splits its end-to-end 569 connection towards the TCP Server into two: 571 (1) An MPTCP connection, that typically relies upon the 572 establishment of one subflow per network path, is established 573 between the client and the MCP. 575 (2) A TCP connection that is established by the MCP with the server. 577 Any data that is eligible to be transported over the MPTCP connection 578 is sent by the Client towards the MCP over the MPTCP connection. The 579 MCP then forwards these data over the regular TCP connection until 580 they reach the server. The same forwarding principle applies for the 581 data sent by the Server over the TCP connection with the MCP. 583 C <===========>MCP <------------> S 584 +<============>+ 586 Legend: 587 <===>: subflows of the upstream MPTCP connection 588 <--->: downstream TCP connection 590 Figure 6: A Multipath TCP Client interacts with a Server through a 591 Multipath Conversion Point 593 6.2. Theory of Operation 595 We assume in this section that the Multipath TCP Client has been 596 configured with the IP address of one or more MCPs which convert the 597 Multipath TCP connection into a regular TCP connection. The address 598 of such MCPs can be statically configured on the Client, dynamically 599 provisioned to the MPTCP Client by means of a DHCP option 600 [I-D.boucadair-mptcp-dhc], or by any other means that are outside the 601 scope of this document. 603 Conceptually, the MCP acts as a relay between an upstream MPTCP 604 connection and a downstream TCP connection. The MCP has at least a 605 single IP address that is reachable from the Multipath TCP Client. 606 It may be assigned other IP addresses. For the sake of simplicity, 607 we assume in this section that the MCP has a single IP address 608 denoted MCP@. Similarly, we assume that the client has two addresses 609 C@1 and C@2 while address S@ is assigned to the server. 611 The MCP maps an upstream MPTCP connection (and its associated 612 subflows) onto a downstream TCP connection. On the MCP, an 613 established Multipath TCP connection can be identified by the local 614 Token that was assigned upon reception of the SYN segment. 616 This Token is guaranteed to be unique on the MCP (provided that it 617 has a single IP address) during the entire lifetime of the MPTCP 618 connection. The 4-tuple (IP src, IP dst, Port src, Port dst) is used 619 to identify the downstream TCP connection. 621 To initiate a connection to a remote server S, the Multipath TCP 622 Client sends a SYN segment towards the MCP that includes the 623 MP_CONVERT Information Element described in Figure 4. The 624 destination address of the SYN segment is the IP address of the MCP. 625 The MP_CONVERT Information Element included in the SYN contains the 626 IP address and optionally the destination port of the Server (see 627 Figure 7). 629 +----+ +-----+ +--+ 630 | C | | MCP | |S | 631 +----+ +-----+ +--+ 632 C@1 C@2 MCP@ S@ 633 | | ________________________________| | 634 | / Initial subflow \ | 635 | |=======SYN(MP_CAPABLE+MC(S@))===>| | 636 | | |--SYN---->| 637 | | |<-SYN/ACK-| 638 | |<====SYN/ACK(MP_CAPABLE)=========| | 639 | | ... | | 640 | \ ________________________________/ | 641 .... .... 642 | |________________________________ | | 643 | / Additional subflow \| | 644 | \ ________________________________/ | 646 Legend: 647 <===>: MPTCP leg 648 <--->: TCP leg 650 Figure 7: Single-ended MCP Flow Example 652 The MCP processes this SYN segment as follows. First, it generates 653 the local key and a unique Token for the Multipath TCP connection. 654 This Token identifies the MPTCP connection. It is passed to the MCP 655 together with the contents of the MP_CONVERT Information Element 656 (i.e., the address of the destination server) and the destination 657 port. 659 The MCP then establishes a TCP connection with the destination 660 server. If the received MP_CONVERT Information Element contains a 661 port number, it is used as the destination port of the outgoing TCP 662 connection that is being established by the MCP. Otherwise, the 663 destination port of the upstream MPTCP connection is used as the 664 destination port of the downstream TCP connection. The MCP creates a 665 flow entry for the downstream TCP connection and maps the upstream 666 MPTCP connection onto the downstream TCP connection. 668 The downstream TCP connection is considered to be active upon 669 reception of the SYN/ACK segment sent by the destination server. The 670 reception of this segment triggers the MCP that confirms the 671 establishment of the upstream MPTCP connection by sending a SYN/ACK 672 segment towards the Multipath TCP Client (including MP_Convert). 674 At this point, there are two established connections. The endpoints 675 of the upstream Multipath TCP connection are the Multipath TCP Client 676 and the MCP. The endpoints of the downstream TCP connection are the 677 MCP and the Server. These two connections are bound by the MCP. 679 All the techniques defined in [RFC6824] can be used by the upstream 680 Multipath TCP connection. In particular, the subflows established 681 over the different network paths can be controlled by either the 682 Multipath TCP Client or the MCP. It is likely that the network 683 operators that deploy MCPs will define policies for the utilisation 684 of the MCP. These policies are discussed in Section 5.6 of 685 [I-D.nam-mptcp-deployment-considerations]. 687 Any data received by the MCP on the upstream Multipath TCP connection 688 will be forwarded by the MCP over the bound downstream TCP 689 connection. The same applies for data received over the downstream 690 TCP connection which will be forwarded by the MCP over the upstream 691 Multipath TCP connection. 693 One of the functions of the MCP is to maintain the binding between 694 the upstream Multipath TCP connection and the downstream TCP 695 connection. If the downstream TCP connection fails for some reason 696 (excessive retransmissions, reception of a RST segment, etc.), then 697 the MCP SHOULD force the teardown of the upstream Multipath TCP 698 connection by transmitting a FASTCLOSE. Similarly, if the upstream 699 Multipath TCP connection fails for some reason (e.g., reception of a 700 FASTCLOSE), the MCP SHOULD tear the downstream TCP connection down 701 and remove the flow entries. 703 The same reasoning applies when the upstream Multipath TCP connection 704 ends with the transmission of DATA_FINs. In this case, the MCP 705 SHOULD also terminate the bound downstream TCP connection by using 706 FIN segments. If the downstream TCP connection terminates with the 707 exchange of FIN segments, the MCP SHOULD initiate a graceful 708 termination of the bound upstream Multipath TCP connection. 710 An MCP SHOULD associate a lifetime with the Multipath TCP and TCP 711 flow entries. In this case, it SHOULD use the same lifetime for each 712 pair of bounded connections. 714 7. MPTCP Connections Between Single Path Client and Server 716 7.1. Description 718 There are situations where neither the client nor the server can use 719 multipath transport protocols albeit network providers would want to 720 optimize network resource usage by means of multi-path communication 721 techniques. Hybrid access service offerings are typical business 722 incentives for such situations, where network operators combine a 723 fixed network (e.g., xDSL) with a wireless network (e.g., LTE). In 724 this case, as illustrated in Figure 8, two MCPs are used for each 725 flow. The first MCP, located downstream of the client, converts the 726 single path TCP connection originated from the client into a 727 Multipath TCP connection established with a second MCP. The latter 728 will then establish a TCP connection with the destination server. 730 Upstream Downstream 731 C <---> MCP <===========> MCP <------------> S 732 +<=============>+ 734 Legend: 735 <===>: MPTCP leg 736 <--->: TCP leg 738 Figure 8: A Client interacts with a Server through an upstream and a 739 downstream Multipath Conversion Points 741 7.2. Theory of Operation 743 7.2.1. Downstream MCP 745 The downstream MCP can be deployed on-path or off-path. If the 746 downstream MCP is deployed off-path, its behavior is described in 747 Section 6.2. 749 If the downstream MCP is deployed on-path, it only terminates MPTCP 750 connections that carry an empty MP_PREFER_PROXY option inside their 751 SYN (i.e., no address is conveyed). If the MCP receives a SYN 752 segment that contains the MP_CAPABLE option but no MP_PREFER_PROXY, 753 it MUST forward the SYN to its final destination without any 754 modification. 756 7.2.2. Upstream MCP 758 The upstream and downstream MCPs cooperate. The upstream MCP may be 759 configured with the addresses of downstream MCPs. If the downstream 760 MCP is deployed on-path, the upstream MCP inserts an MP_PREFER_PROXY 761 option. 763 In this section, we assume that the upstream MCP has been configured 764 with one address of the downstream MCP. This address can be 765 configured statically, dynamically distributed by means of a DHCP 766 option [I-D.boucadair-mptcp-dhc], or by any other means that are 767 outside the scope of this document. 769 We assume that the upstream MCP has two addresses uMCP@1 and uMCP@2 770 while the downstream MCP is assigned a single IP address dMCP@. 772 The upstream MCP maps an upstream TCP connection onto a downstream 773 MPTCP connection (and its associated subflows) . On the upstream MCP, 774 an established MPTCP connection can be identified by the local Token 775 that was assigned upon reception of the SYN segment from the Client. 777 The Client sends a SYN segment addressed to the Server and it is 778 intercepted by the upstream MCP which in turns initiates an MPTCP 779 connection towards its downstream MCP that includes the MP_CONVERT 780 Information Element described in Figure 4. The destination address 781 of the SYN segment is the IP address of the downstream MCP. The 782 MP_CONVERT Information Element included in the SYN contains the IP 783 address and optionally the destination port of the Server; this 784 information is extracted from the SYN message received over the 785 upstream TCP connection. 787 Concretely, the upstream MCP processes the SYN segment received from 788 the Client as follows. 790 First, it generates the local key and a unique Token for the 791 Multipath TCP connection to identify the MPTCP connection. It 792 extracts the destination IP address and, optionally, the destination 793 port that will then be carried in a MP_CONVERT Information Element. 794 The upstream MCP establishes an MPTCP connection with the downstream 795 MCP. The upstream MCP creates a flow entry for the downstream MPTCP 796 connection and maps the upstream TCP connection onto the downstream 797 MPTCP connection. 799 The downstream MPTCP connection is considered to be active upon 800 reception of the SYN+ACK segment from the downstream MCP. The 801 reception of this segment triggers the upstream MCP that confirms the 802 establishment of the upstream TCP connection by sending a SYN+ACK 803 segment towards the TCP Client. 805 At this point, there are two established connections maintained by 806 the upstream MCP: 808 (1) The endpoints of the upstream TCP connection are the Client and 809 the upstream MCP. 811 (2) The endpoints of the downstream MPTCP connection are the 812 upstream MCP and the downstream MCP. 814 These two connections are bound by the upstream MCP. An example is 815 shown in Figure 9. 817 Upstream Downstream 818 +--+ +-----+ +-----+ +--+ 819 |C1| | MCP | | MCP | |S1| 820 +--+ +-----+ +-----+ +--+ 821 C@1 uMCP@1 uMCP@2 dMCP@ S@ 822 | | |______________________________| | 823 |--SYN--->|/ Initial subflow \ | 824 | |=======SYN(MP_CAPABLE+MC(S@))==>| | 825 | | |--SYN---->| 826 | | |<-SYN/ACK-| 827 | |<====SYN/ACK(MP_CAPABLE)========| | 828 |. 979 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 980 "TCP Extensions for Multipath Operation with Multiple 981 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 982 . 984 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 985 "Special-Purpose IP Address Registries", BCP 153, 986 RFC 6890, DOI 10.17487/RFC6890, April 2013, 987 . 989 12.2. Informative References 991 [I-D.barre-mptcp-tfo] 992 Barre, S., Detal, G., and O. Bonaventure, "TFO support for 993 Multipath TCP", draft-barre-mptcp-tfo-01 (work in 994 progress), January 2015. 996 [I-D.boucadair-mptcp-dhc] 997 Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options 998 for Network-Assisted Multipath TCP (MPTCP)", draft- 999 boucadair-mptcp-dhc-06 (work in progress), October 2016. 1001 [I-D.nam-mptcp-deployment-considerations] 1002 Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx, 1003 W., and R. Skog, "Network-Assisted MPTCP: Use Cases, 1004 Deployment Scenarios and Operational Considerations", 1005 draft-nam-mptcp-deployment-considerations-01 (work in 1006 progress), December 2016. 1008 [I-D.zhang-gre-tunnel-bonding] 1009 Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and 1010 M. Cullen, "Huawei's GRE Tunnel Bonding Protocol", draft- 1011 zhang-gre-tunnel-bonding-05 (work in progress), December 1012 2016. 1014 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 1015 Routing Encapsulation (GRE)", RFC 1701, 1016 DOI 10.17487/RFC1701, October 1994, 1017 . 1019 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 1020 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 1021 DOI 10.17487/RFC1928, March 1996, 1022 . 1024 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1025 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1026 December 1998, . 1028 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1029 Defeating Denial of Service Attacks which employ IP Source 1030 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1031 May 2000, . 1033 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1034 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 1035 . 1037 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 1038 Multipath Operation with Multiple Addresses", RFC 6181, 1039 DOI 10.17487/RFC6181, March 2011, 1040 . 1042 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1043 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 1044 . 1046 [TR-348] BBF, "Hybrid Access Broadband Network Architecture", July 1047 2016. 1049 Authors' Addresses 1050 Mohamed Boucadair (editor) 1051 Orange 1052 Rennes 35000 1053 France 1055 Email: mohamed.boucadair@orange.com 1057 Christian Jacquenet (editor) 1058 Orange 1059 Rennes 1060 France 1062 Email: christian.jacquenet@orange.com 1064 Olivier Bonaventure (editor) 1065 Tessares 1066 Belgium 1068 Email: olivier.bonaventure@tessares.net 1070 Denis Behaghel 1071 OneAccess 1073 Email: Denis.Behaghel@oneaccess-net.com 1075 Stefano Secci 1076 UPMC 1078 Email: stefano.secci@lip6.fr 1080 Wim Henderickx (editor) 1081 Nokia/Alcatel-Lucent 1082 Belgium 1084 Email: wim.henderickx@alcatel-lucent.com 1086 Robert Skog (editor) 1087 Ericsson 1089 Email: robert.skog@ericsson.com 1090 Suresh Vinapamula 1091 Juniper 1092 1137 Innovation Way 1093 Sunnyvale, CA 94089 1094 USA 1096 Email: Sureshk@juniper.net 1098 SungHoon Seo 1099 Korea Telecom 1100 Seoul 1101 Korea 1103 Email: sh.seo@kt.com 1105 Wouter Cloetens 1106 SoftAtHome 1107 Vaartdijk 3 701 1108 3018 Wijgmaal 1109 Belgium 1111 Email: wouter.cloetens@softathome.com 1113 Ullrich Meyer 1114 Vodafone 1115 Germany 1117 Email: ullrich.meyer@vodafone.com 1119 Luis M. Contreras 1120 Telefonica 1121 Spain 1123 Email: luismiguel.contrerasmurillo@telefonica.com 1125 Bart Peirens 1126 Proximus 1128 Email: bart.peirens@proximus.com