idnits 2.17.1 draft-hesmans-mptcp-socket-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 448 has weird spacing: '...ned int opt...' -- The document date (March 05, 2018) is 2215 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 557 -- Looks like a reference, but probably isn't: '1' on line 558 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-08 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group B. Hesmans 3 Internet-Draft O. Bonaventure 4 Intended status: Informational F. Duchene 5 Expires: September 6, 2018 UCLouvain 6 March 05, 2018 8 A socket API to control Multipath TCP 9 draft-hesmans-mptcp-socket-03 11 Abstract 13 This document proposes an enhanced socket API to allow applications 14 to control the operation of a Multipath TCP stack. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 6, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Multipath TCP Socket API . . . . . . . . . . . . . . . . . . 5 53 3.1. Subflow list . . . . . . . . . . . . . . . . . . . . . . 5 54 3.2. Open subflow . . . . . . . . . . . . . . . . . . . . . . 7 55 3.3. Close subflow . . . . . . . . . . . . . . . . . . . . . . 8 56 3.4. Get subflow tuple . . . . . . . . . . . . . . . . . . . . 9 57 3.5. Subflow socket option . . . . . . . . . . . . . . . . . . 10 58 3.6. IPv6 Segment Routing extension . . . . . . . . . . . . . 11 59 4. Multipath-TCP events . . . . . . . . . . . . . . . . . . . . 13 60 4.1. Subflow creation . . . . . . . . . . . . . . . . . . . . 14 61 4.2. Subflow deletion . . . . . . . . . . . . . . . . . . . . 14 62 4.3. New local address available . . . . . . . . . . . . . . . 14 63 4.4. New remote address available . . . . . . . . . . . . . . 14 64 4.5. Prio changed . . . . . . . . . . . . . . . . . . . . . . 14 65 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 66 6. Security considerations . . . . . . . . . . . . . . . . . . . 14 67 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 71 9.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 Multipath TCP [RFC6824] was designed as an incrementally deployable 77 [RFC6182] extension to TCP [RFC0793]. One of its design objectives 78 was to remain backward compatible with the traditional socket API to 79 enable applications to benefit from Multipath TCP without requiring 80 any modification. This solution has been adopted by the Multipath 81 TCP implementation in the Linux kernel [MultipathTCP-Linux]. In this 82 implementation, once Multipath TCP has been enabled, all TCP 83 applications automatically use it. It is possible to turn Multipath 84 TCP off on a per socket basis, but this is rarely used. The 85 Multipath TCP stack contains a module, called the path manager, that 86 controls the utilisation of the different paths. Three path managers 87 have been implemented : 89 o the "full mesh" path manager, which is the default one, tries to 90 create subflows in full mesh among all the client addresses and 91 all addresses advertised by the server. All subflows are created 92 by the client because the server assumes that the client is often 93 behind a NAT or firewall 95 o the "ndiffports" path manager was designed for single-homed hosts. 96 It creates n parallel subflows between the client and the server. 97 It has been defined notably for datacenters [SIGCOMM11] 99 o the "user space" path manager [CONEXT15] uses Netlink to expose 100 events to specific applications and enables them to control the 101 operation of the underlying MPTCP stack. 103 However, discussions with users of the Multipath TCP implementation 104 in the Linux kernel indicate that they would often want a finer 105 control on the underlying stack and more precisely on the utilisation 106 of the different subflows. Smartphone applications are a typical 107 example. Measurements indicate that with the default path manager, 108 there are many subflows that are created without being used [PAM2016] 109 [COMMAG2016]. This increases energy consumption and could be avoided 110 on Multipath-TCP aware applications. 112 The Multipath TCP implementation used in Apple smartphones, tablets 113 and laptops [Apple-MPTCP] took a different approach. This MPTCP 114 stack is not exposed by default to the applications. To use MPTCP, 115 they need to use a specific address family and special system calls 116 [ANRW2016]. 118 Using a new address family and new system calls is a major 119 modification and application developers may not agree to maintain 120 different versions of their applications that run above regular TCP 121 and Multipath TCP. In this document, we propose a simple but 122 powerful API that relies only on socket options and the existing 123 system calls to interact with the MPTCP stack. Application 124 developers are already used to manipulate socket options and could 125 thus easily extend their applications to better utilize the 126 underlying MPTCP stack when available. This approach is similar to 127 the API outlined in [RFC6897], but to our knowledge, this API has 128 never been implemented. We also note that during the last decade the 129 socket API exposed by SCTP evolved to use more socket options 130 [RFC6458]. 132 This document is organised as follows. We first describe the basic 133 operation of our enhanced API in section Section 2. We then show in 134 section Section 3 how the "getsockopt" and "setsockopt" system calls 135 can be used to control the underlying Multipath TCP stack. We focus 136 on basic operations like retrieving the list of subflows that compose 137 a Multipath TCP connection, establishing a new subflow or terminating 138 an existing subflow in this first version of the document. We will 139 address in the next revision of this document more advanced topics 140 such as non-blocking I/O and the utilisation of the "recvmsg" and 141 "sendmsg" system calls. 143 2. Basic operation 145 In this section, we briefly describe the basic utilisation of the 146 enhanced socket API for Multipath TCP. As an illustration, we 147 consider a dual-homed smartphone having a WiFi and a cellular 148 interface that interacts with a single homed server. 150 We assume for simplicity in this example that the server is passive. 151 It creates a listening socket and accepts incoming connections 152 through the following system calls : 154 o "socket()" 156 o "bind()" 158 o "listen()" 160 Then data can be sent (resp. received) with the "send()" (resp. 161 "recv()") system calls and the connection can be terminated by using 162 the "close()" or "shutdown()" system calls. 164 On the client side, the following system calls are used to create a 165 Multipath TCP connection : 167 o "socket()" 169 o "connect()" 171 The "connect()" system call succeeds once the initial subflow of the 172 Multipath TCP connection has been established. We assume here that 173 Multipath TCP has been negotiated successfully. The client can then 174 send and receive data by using the "send()" and "recv()" system 175 calls. 177 The enhanced socket API enables the client (and also the server since 178 the protocol is symmetrical, but we ignore this in this section) to 179 control the utilisation of the different subflows. This control is 180 performed by setting and retrieving socket options through the 181 "setsockopt()" and "getsockopt()" system calls. Four main socket 182 options are defined to control the subflows used by the underlying 183 Multipath TCP connection : 185 o "MPTCP_GET_SUB_IDS" can only be used by "getsockopt()". It is 186 used to retrieve the current list of the subflows that compose the 187 underlying Multipath TCP connection. In this list, each one 188 identifier is associated with each subflow. 190 o "MPTCP_GET_SUB_TUPLE". This socket option is equivalent to the 191 "getpeername()" system call with regular TCP, but on a per subflow 192 basis. When used with "getsockopt()", it allows to retrieve the 193 IP addresses and ports of the two endpoints of a particular 194 subflow. 196 o "MPTCP_OPEN_SUB_TUPLE". This socket option is the equivalent to 197 the "connect()" system call, but it operates on subflows. It 198 allows to attempt to establish a new subflow by specifying its 199 (remote and optionally local) endpoints. 201 o "MPTCP_CLOSE_SUB_ID". This socket option allows to close a 202 specific subflow. 204 As an example, consider a smartphone application that creates a 205 Multipath TCP connection. This connection is established by using 206 the "connect()" system call. The MPTCP stack selects the outgoing 207 interface based on its routing table. Let us assume that the initial 208 subflow is established over the cellular interface. This is the only 209 subflow used for this connection at this time. To perform a 210 handover, the smartphone application would use "MPTCP_OPEN_SUB_TUPLE" 211 to create a new subflow over the WiFi interface. It can then use 212 "MPTCP_GET_SUB_TUPLE" to retrieve the local and remote addresses of 213 this subflow. Now that the WiFi subflow is active, the application 214 can use "MPTCP_CLOSE_SUB_ID" to close the cellular subflow. 216 3. Multipath TCP Socket API 218 From an application viewpoint, the interaction with the underlying 219 stack is awlays performed through a single socket. This unique 220 socket is used even if a Multipath TCP stack is used and many 221 subflows have been established. This single socket abstraction is 222 important because the applications exchange data through a bytestream 223 with both TCP and Multipath TCP. We preserve this abstraction in the 224 proposed enhanced socket API but expose some details of the 225 underlying MPTCP stack to the application. 227 For all the socket options presented bellow, we assume that the 228 underlying Multipath TCP connection is still a Multipath TCP 229 connection. Otherwise (e.g. after a fallback), they return an error 230 and set errno to "EOPNOTSUPP" is returned. 232 3.1. Subflow list 234 The first important information that a stack can expose are the 235 different subflows that are combined within a given Multipath TCP 236 connection. For this, we need a data structure that represents the 237 different subflows that compose a connection. The "mptcp_sub_ids" 238 structure shown in figure Figure 1 contains an array with the status 239 of the different subflows that compose a given connection. The 240 actual size of the array depends on the number of subflows and is 241 defined with the "sub_count" field. The "mptcp_sub_status" structure 242 reflects the status of each subflow. A subflow is identified by its 243 "id". In addition to the "id" of the subflow, the "mptcp_sub_status" 244 structure contains one flag : the "low\_prio" flag. It is set to 1 245 when the subflow is defined as a back-up subflow. Other flags could 246 be exposed through this structure in the future. 248 struct mptcp_sub_status { 249 __u8 id; 250 __u16 low_prio:1; 251 }; 253 struct mptcp_sub_ids { 254 __u8 sub_count; 255 struct mptcp_sub_status sub_status[]; 256 }; 258 Figure 1: The mptcp_sub_ids and mptcp_sub_status structures 260 This structure is used by the "MPTCP_GET_SUB_IDS" socket option. 261 More precisely, the "getsockopt", when used with the 262 "MPTCP_GET_SUB_IDS" socket option can retrieve the "mptcp_sub_ids" of 263 the underlying Multipath TCP connection. This call may return an 264 empty array if the connection does not contain any subflow. This can 265 happen with Multipath TCP when the last subflow composing the 266 connection has been terminated abruptly. 268 The "id" that is returned in the "mptcp_sub_ids" structure is 269 important because it identifies the subflow and is used as an 270 identifier by the other socket options. 272 The call may return the error "EINVAL" if the buffer passed by the 273 application is too small to copy the array of subflow status. 275 A simple example of its utilisation is presented in figure Figure 2. 277 int i; 278 unsigned int optlen; 279 struct mptcp_sub_ids *ids; 281 optlen = 42; 283 ids = malloc(optlen); 285 getsockopt(sockfd, IPPROTO_TCP, MPTCP_GET_SUB_IDS, ids, &optlen); 287 for(i = 0; i < ids->sub_count; i++){ 288 printf("Subflow id : %i\n", ids->sub_status[i].id); 289 } 291 Figure 2: Sample code for the utilisation of MPTCP_GET_SUB_IDS 293 3.2. Open subflow 295 Another important part of the API is to enable an application to open 296 new subflows. This is possible through the "MPTCP_OPEN_SUB_TUPLE" 297 socket option. This option uses the "mptcp_sub_tuple" structure 298 shown in figure Figure 3 to pass the priority, local and remote 299 endpoints of the new subflow. 301 struct mptcp_sub_tuple { 302 __u8 id; 303 __u8 prio; 304 __u8 addrs[0]; 305 int if_idx; 306 }; 308 Figure 3: The mptcp_sub_tuple structure 310 The "id" field is an output. This is the "id" of the created 311 subflow. The "prio" field indicates if the new subflow should be 312 considered as back-up or not. The "addrs" must be a pair array of 313 size two. The first address must be the address of the source and 314 the second address must be the address of the destination. The 315 actual structure passed must be either "sockaddr_in" or 316 "sockaddr_in6", but the two elements of the array must be of the same 317 type. The struct "sockaddr" can be used to determine which one is 318 actually passed. 320 The caller can also set the source address to be either "INADDR_ANY" 321 for IPv4 or "in6addr_any" for IPv6. In this case, the kernel chooses 322 the source address to be used for the new subflow. 324 If a single source address is used for multiple interfaces, the 325 caller may choose the interface to be used by setting the "if_idx" 326 field. If this field is set to zero the kernel will choose the 327 default interface. 329 Errors returned by either "bind()" or "connect()" are returned if an 330 error occurred during the process. 332 An example is provided in figure Figure 4. 334 unsigned int optlen; 335 struct mptcp_sub_tuple *sub_tuple; 336 struct sockaddr_in *addr; 337 int error; 339 optlen = sizeof(struct mptcp_sub_tuple) + 340 2 * sizeof(struct sockaddr_in); 341 sub_tuple = malloc(optlen); 343 sub_tuple->id = 0; 344 sub_tuple->prio = 0; 346 addr = (struct sockaddr_in*) &sub_tuple->addrs[0]; 348 addr->sin_family = AF_INET; 349 addr->sin_port = htons(12345); 350 inet_pton(AF_INET, "10.0.0.1", &addr->sin_addr); 352 addr++; 354 addr->sin_family = AF_INET; 355 addr->sin_port = htons(1234); 356 inet_pton(AF_INET, "10.1.0.1", &addr->sin_addr); 358 error = getsockopt(sockfd, IPPROTO_TCP, MPTCP_OPEN_SUB_TUPLE, 359 sub_tuple, &optlen); 361 Figure 4: Sample code to establish an additional subflow 363 3.3. Close subflow 365 To close a subflow, the socket option "MPTCP_CLOSE_SUBFLOW" is used. 366 This option used the "mptcp_close_sub_id" structure defined in figure 367 Figure 5. 369 struct mptcp_close_sub_id { 370 __u8 id; 371 int how; 372 }; 374 Figure 5: The mptcp_close_sub_id structure 376 In the above structure, "id" is the identifier of the subflow that 377 needs to be closed. If the "id" is invalid, "EINVAL" is returned. 379 The "how" field is used to define how to subflow should be 380 terminated. It recognises the same set of constant that are used by 381 "shutdown()". In addition to this set, "RST" can be used to 382 indicates that the subflow should be terminated by sending an "RST". 384 3.4. Get subflow tuple 386 An application may also be interested by the addresses and ports that 387 are used by a given subflow. To retrieve this information, the 388 socket option "MPTCP_GET_SUB_TUPLE" is used in combination with the 389 "mptcp_sub_tuple" structure shown in figure Figure 6. 391 struct mptcp_sub_tuple { 392 __u8 id; 393 __u8 addrs[0]; 394 }; 396 Figure 6: The mptcp_sub_tuple structure 398 This is the same structure as the one used to open a subflow but in 399 this context, "id" is the input and "addrs" is the output. 401 A sample code is provided in figure Figure 7. 403 unsigned int optlen; 404 struct mptcp_sub_tuple *sub_tuple; 406 optlen = 100; 408 sub_tuple = malloc(optlen); 410 sub_tuple->id = sub_id; 411 getsockopt(sockfd, IPPROTO_TCP, MPTCP_GET_SUB_TUPLE, sub_tuple, 412 &optlen); 414 sin = (struct sockaddr_in*) &sub_tuple->addrs[0]; 416 printf("\tip src : %s src port : %hu\n", inet_ntoa(sin->sin_addr), 417 ntohs(sin->sin_port)); 419 sin++; 421 printf("\tip dst : %s dst port : %hu\n", inet_ntoa(sin->sin_addr), 422 ntohs(sin->sin_port)); 424 Figure 7: Sample code using the MPTCP_GET_SUB_TUPLE option 426 3.5. Subflow socket option 428 TCP/IP implementations support different socket options. Some of 429 them can be applied to the TCP layer while others can be applied to 430 the IP layer. To be able to issue a socket option on a specific 431 subflow, we define the "MPTCP_SUB_GETSOCKOPT" and 432 "MPTCP_SUB_SETSOCKOPT" options. These two socket options use 433 respectively the structures presented in figure Figure 8. 435 struct mptcp_sub_getsockopt { 436 __u8 id; 437 int level; 438 int optname; 439 char __user *optval; 440 unsigned int __user *optlen; 441 }; 443 struct mptcp_sub_setsockopt { 444 __u8 id; 445 int level; 446 int optname; 447 char __user *optval; 448 unsigned int optlen; 449 }; 451 Figure 8: Structures used by the ``MPTCP_SUB_GETSOCKOPT`` and 452 ``MPTCP_SUB_SETSOCKOPT`` options 454 In the two structures "id" indicates to which subflow the socket 455 option should be redirected. The end of each structure contains the 456 information needed to perform the socket option call on the subflow. 458 Figure Figure 9 illustrates how the IP_TSO socket option can be 459 applied on a particular subflow. 461 unsigned int optlen, sub_optlen; 462 struct mptcp_sub_setsockopt sub_sso; 463 int val = 12; 465 optlen = sizeof(struct mptcp_sub_setsockopt); 466 sub_optlen = sizeof(int); 467 sub_sso.id = sub_id; 468 sub_sso.level = IPPROTO_IP; 469 sub_sso.optname = IP_TOS; 470 sub_sso.optlen = sub_optlen; 471 sub_sso.optval = (char *) &val; 473 setsockopt(sockfd, IPPROTO_TCP, MPTCP_SUB_SETSOCKOPT, &sub_sso, 474 optlen); 476 Figure 9: Example socket option 478 3.6. IPv6 Segment Routing extension 480 Segment Routing (SR) [I-D.ietf-spring-segment-routing] allows a node 481 to steer packets through specific paths inside a network. The IPv6 482 dataplane relies on the IPv6 Segment Routing Header which can be 483 added to IPv6 packets [I-D.ietf-6man-segment-routing-header]. 484 Multipath-TCP can leverage SRv6 to establish subflows that use a 485 specific path. Various use case are possible, including disjoint 486 paths or traffic engineered paths. To support IPv6 Segment routing, 487 the Segment Routing Header (SRH) needs to be associated to a subflow. 488 The modified structure is presented in figure Figure 10. 490 struct mptcp_sub_tuple { 491 __u8 id; 492 __u8 prio; 493 __u8 addrs[0]; 494 int if_idx; 495 struct ipv6_sr_hdr *ipv6_srh; 496 }; 498 Figure 10: The SRv6 enabled mptcp_sub_tuple structure 500 With this modified structure, the SRH can now be associated to a 501 subflow. An example is provided in figure Figure 11. In this 502 figure, a subflow is established between 2001:DB8:1111::1 and 503 2001:DB8:3333::1 passing through 2001:DB8:2222::1. 505 /* SRH structure */ 506 struct ipv6_sr_hdr { 507 uint8_t nexthdr; 508 uint8_t hdrlen; 509 uint8_t type; 510 uint8_t segments_left; 511 uint8_t first_segment; 512 uint8_t flags; 513 uint16_t reserved; 515 struct in6_addr segments[0]; 516 }; 518 unsigned int optlen; 519 struct mptcp_sub_tuple *sub_tuple; 520 struct sockaddr_in6 *addr; 521 int srh_len, error; 522 struct ipv6_sr_hdr *srh; 524 optlen = sizeof(struct mptcp_sub_tuple) + 525 2 * sizeof(struct sockaddr_in6); 526 sub_tuple = malloc(optlen); 528 sub_tuple->id = 0; 529 sub_tuple->prio = 0; 530 addr = (struct sockaddr_in6*) &sub_tuple->addrs[0]; 532 addr->sin_family = AF_INET6; 533 addr->sin_port = htons(12345); 534 inet_pton(AF_INET6, "2001:DB8:1111::1", &addr->sin_addr); 536 addr++; 538 addr->sin_family = AF_INET6; 539 addr->sin_port = htons(1234); 540 inet_pton(AF_INET6, "2001:DB8:3333:1:", &addr->sin_addr); 542 /* Now configuring the SRH to make the subflow go through 543 2001:DB8:2222::1 */ 544 srh_len = sizeof(*srh) + 2 * sizeof(struct in6_addr); 545 srh = malloc(srh_len); 546 if (!srh) 547 return -1; 549 srh->nexthdr = 0; 550 srh->hdrlen = 4; 551 srh->type = 4; 552 srh->segments_left = 1; 553 srh->first_segment = 1; 554 srh->flags = 0; 555 srh->reserved = 0; 557 memset(&srh->segments[0], 0, sizeof(struct in6_addr)); 558 inet_pton(AF_INET6, "2001:DB8:2222::1", &srh->segments[1]); 560 sub_tuple->ipv6_srh = srh; 562 error = getsockopt(sockfd, IPPROTO_TCP, MPTCP_OPEN_SUB_TUPLE, 563 sub_tuple, &optlen); 565 Figure 11: Sample code to establish an additional subflow with an SRH 567 The socket API for IPv6 Segment Routing is described in 568 [SRv6Sockets]. 570 4. Multipath-TCP events 572 In some cases, Multipath-TCP connections should be able to react upon 573 events. Applications that are aware of Multipath-TCP must receive 574 those events in order to take their decisions and react if needed. 576 The list of events that could be produced by Multipath-TCP stack, 577 upon subscription to those events, are presented bellow. 579 _** This section is still an early draft and will be updated to add 580 more details. **_ 582 4.1. Subflow creation 584 If the stack or the user requests a new subflow, the user will 585 receive this event if the subflow has been fully established and is 586 available to send new data. The event should contain the 587 identification of the subflow. 589 4.2. Subflow deletion 591 If one of the subflow is deleted, an event that contain the 592 identification of the subflow must be triggered. Moreover, the 593 reason of the deletion must be stated. 595 4.3. New local address available 597 When a new local address is available, the application should receive 598 all the informations needed to use the new address. 600 4.4. New remote address available 602 See previous section. 604 4.5. Prio changed 606 When one of the subflow receives a change in prio. The event must 607 contain the identification of the subflow and the new prio. 609 5. IANA considerations 611 There are no IANA considerations in this document. 613 6. Security considerations 615 TCP and UDP implementations usually reserve port numbers below 1024 616 for privileged users. On such implementations, Multipath TCP should 617 restrict the ability of the users to create subflows on privileged 618 ports through the "MPTCP_OPEN_SUB_TUPLE". 620 For similar reasons, the "MPTCP_SUB_SETSOCKOPT" socket option should 621 not enable an unprivileged user to retrieve or modify a socket option 622 on a subflow if he is not allowed to perform such actions on a 623 regular TCP connection. 625 Applications requiring strong security should implement cryptographic 626 protocols such as TLS [RFC5246] or ssh [RFC4251]. The proposed API 627 enables such application to better control their utilisation of the 628 underlying interfaces by managing the different subflows. 630 7. Conclusion 632 In this document, we have documented an enhanced socket API that 633 enables applications to control the creation and the release of 634 subflows by the underlying Multipath TCP stack. We expect that a 635 standardised API supported by different implementations will be an 636 important stop for the deployment of Multipath TCP aware applications 637 on both multihomed hosts such as smartphones as well as on servers. 638 This enhanced API has already been implemented on the Multipath TCP 639 implementation in the Linux kernel. Future versions of this document 640 will address more advanced utilisations of the socket API such as 641 non-blocking I/O and the "sendmsg()" and "recvmsg()" system calls. 643 8. Acknowledgements 645 We would like to thank Christoph Paasch, Quentin De Coninck Rao 646 Shoaib for their comments on an early version of this document. 648 9. References 650 9.1. Normative References 652 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 653 RFC 793, DOI 10.17487/RFC0793, September 1981, 654 . 656 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 657 "TCP Extensions for Multipath Operation with Multiple 658 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 659 . 661 9.2. Informative References 663 [ANRW2016] 664 Hesmans, B. and O. Bonaventure, "An enhanced socket API 665 for Multipath TCP", 2016, . 668 [Apple-MPTCP] 669 Apple, Inc, ., "iOS - Multipath TCP Support in iOS 7", 670 n.d., . 672 [COMMAG2016] 673 De Coninck, Q., Baerts, M., Hesmans, B., and O. 674 Bonaventure, "Observing Real Smartphone Applications over 675 Multipath TCP", IEEE Communications Magazine , March 2016, 676 . 679 [CONEXT15] 680 Hesmans, B., Detal, G., Barre, S., Bauduin, R., and O. 681 Bonaventure, "SMAPP - Towards Smart Multipath TCP-enabled 682 APPlications", Proc. Conext 2015, Heidelberg, Germany , 683 December 2015, . 686 [I-D.ietf-6man-segment-routing-header] 687 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 688 Field, B., daniel.voyer@bell.ca, d., 689 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 690 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 691 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 692 Header (SRH)", draft-ietf-6man-segment-routing-header-08 693 (work in progress), January 2018. 695 [I-D.ietf-spring-segment-routing] 696 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 697 Litkowski, S., and R. Shakir, "Segment Routing 698 Architecture", draft-ietf-spring-segment-routing-15 (work 699 in progress), January 2018. 701 [MultipathTCP-Linux] 702 Paasch, C., Barre, S., and . et al, "Multipath TCP 703 implementation in the Linux kernel", n.d., 704 . 706 [PAM2016] De Coninck, Q., Baerts, M., Hesmans, B., and O. 707 Bonaventure, "A First Analysis of Multipath TCP on 708 Smartphones", 17th International Passive and Active 709 Measurements Conference (PAM2016) , March 2016, 710 . 713 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 714 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 715 January 2006, . 717 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 718 (TLS) Protocol Version 1.2", RFC 5246, 719 DOI 10.17487/RFC5246, August 2008, . 722 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 723 Iyengar, "Architectural Guidelines for Multipath TCP 724 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 725 . 727 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 728 Yasevich, "Sockets API Extensions for the Stream Control 729 Transmission Protocol (SCTP)", RFC 6458, 730 DOI 10.17487/RFC6458, December 2011, . 733 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 734 Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, 735 March 2013, . 737 [SIGCOMM11] 738 Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A., 739 Wischik, D., and M. Handley, "Improving datacenter 740 performance and robustness with multipath TCP", 741 Proceedings of the ACM SIGCOMM 2011 conference , 2011, 742 . 744 [SRv6Sockets] 745 Duchene, F. and O. Bonaventure, "A socket API to control 746 IPv6 Segment Routing", n.d., . 749 Authors' Addresses 751 Benjamin Hesmans 752 UCLouvain 754 Email: Benjamin.Hesmans@uclouvain.be 756 Olivier Bonaventure 757 UCLouvain 759 Email: Olivier.Bonaventure@uclouvain.be 760 Fabien Duchene 761 UCLouvain 763 Email: Fabien.Duchene@uclouvain.be