idnits 2.17.1 draft-duchene-mptcp-add-addr-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6824]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 192: '...e receiving host MUST return the exact...' RFC 2119 keyword, line 195: '...s an invalid echo of the option it MAY...' RFC 2119 keyword, line 198: '...on this address, it MUST consider this...' RFC 2119 keyword, line 199: '...been echoed, and MUST NOT retransmit t...' RFC 2119 keyword, line 301: '... This host MAY use this priority to ...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 08, 2016) is 2848 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-18) exists of draft-ietf-mptcp-rfc6824bis-06 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group F. Duchene 3 Internet-Draft O. Bonaventure 4 Intended status: Experimental UCLouvain 5 Expires: January 9, 2017 July 08, 2016 7 Multipath TCP Address Advertisement 8 draft-duchene-mptcp-add-addr-00 10 Abstract 12 Multipath TCP [RFC6824] defines the ADD_ADDR option that allows a 13 host to announce its addresses to the remote host. In this document 14 we propose some improvements to this mechanism. 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 January 9, 2017. 33 Copyright Notice 35 Copyright (c) 2016 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. Proposed ADD_ADDR option . . . . . . . . . . . . . . . . . . 4 52 2.1. Reliability . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. Backup . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.3. Priorities . . . . . . . . . . . . . . . . . . . . . . . 7 55 2.4. Path diversity . . . . . . . . . . . . . . . . . . . . . 9 56 2.5. Load balancing . . . . . . . . . . . . . . . . . . . . . 10 57 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 58 4. Security considerations . . . . . . . . . . . . . . . . . . . 11 59 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 62 6.2. Informative References . . . . . . . . . . . . . . . . . 12 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 65 1. Introduction 67 Multipath TCP is an extension to TCP [RFC0793] that was specified in 68 [RFC6824]. Multipath TCP allows hosts to use multiple paths to send 69 and receive the data belonging to one connection. For this, a 70 Multipath TCP is composed of several TCP connections that are called 71 subflows. [RFC6824] defines two options to manage the host 72 addresses: 74 o ADD_ADDR is used to announce one address bound to a host (possibly 75 combined with a port number) 77 o REMOVE_ADDR is used to indicate that an address previously 78 attached to a host is not anymore attached to this host 80 To cope with Network Address Translation (NAT), the ADD_ADDR and 81 REMOVE_ADDR options contain an address identifier encoded as an 8 82 bits integer. 84 When the initial subflow is created, it is assumed to be initiated 85 from the address of the client whose identifier is 0 towards the 86 address of the server whose identifier is also 0. Both the client 87 and the server can use ADD_ADDR to advertise the other addresses that 88 they use. When an additional subflow is created, the MP_JOIN option 89 placed in the SYN (resp. SYN+ACK) contains the identifier of the 90 address used to create (resp. accept) the subflow. 92 The latest Multipath TCP draft [I-D.ietf-mptcp-rfc6824bis] defines 93 the ADD_ADDR option as shown in Figure 1. 95 1 2 3 96 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 97 +---------------+---------------+-------+-------+---------------+ 98 | Kind | Length |Subtype|(resvd)| Address ID | 99 +---------------+---------------+-------+-------+---------------+ 100 | Address (IPv4 - 4 octets / IPv6 - 16 octets) | 101 +-------------------------------+-------------------------------+ 102 | Port (2 octets, optional) | | 103 +-------------------------------+ | 104 | Truncated HMAC (8 octets) | 105 | +-------------------------------+ 106 | | 107 +-------------------------------+ 109 Figure 1: The Multipath TCP ADD_ADDR option format 111 In this document, we propose to slightly modify the format of this 112 option based on issues that have been detected while working with the 113 Multipath TCP implementation in the Linux kernel. More precisely, we 114 address four different problems. The first, discussed in 115 Section 2.1, is that the ADD_ADDR option is sent unreliably. This 116 implies that the host sending an ADD_ADDR option cannot be sure that 117 the address that it has advertised has been learned by the distant 118 host. The second issue, discussed in Section 2.2 is the handling of 119 backup subflows. Multipath TCP supports the creation of backup 120 subflows through the B bit in the MP_JOIN option. These backup 121 subflows consume energy and radio ressources on mobile devices and it 122 would be useful for a host to be able to advertise a backup address 123 that would be used to create subflows after a failure. The third 124 issue is that multihomed hosts may have preferences on the 125 utilisation of some of their addresses/interfaces to create 126 additional subflows. Section 2.3 proposes a priority field that 127 allows them to advertise these preferences. The fourth issue is that 128 multihomed hosts, especially with IPv6, often have several addresses 129 assigned to each interface. In this case, it can be difficult to 130 establish disjoint paths between the communicating hosts. 131 Section 2.4 proposes a community field in the ADD_ADDR option to 132 indicate that some addresses share the same path. The last issue, 133 discussed in Section 2.5 is that some hosts, e.g. servers behind a 134 load balancer or clients behind a firewall, may want to indicate that 135 the address used for the initial subflow should not be used to create 136 additional ones. 138 2. Proposed ADD_ADDR option 140 To cope with the issues described later in this document we propose a 141 new format for this option. The format for this new option is shown 142 in Figure 2. 144 1 2 3 145 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 146 +---------------+---------------+-------+-------+---------------+ 147 | Kind | Length |Subtype|E|(rsv)| Address ID | 148 +---------------+---------------+-------+-------+---------------+ 149 | Address (IPv4 - 4 octets / IPv6 - 16 octets) | 150 +---------------+---------------+---------------+---------------+ 151 | Commu |prio |B| Port (2 octets, optional) | | 152 +---------------+---------------+---------------+ | 153 | | 154 | Truncated HMAC (8 octets) +---------------+ 155 | | 156 +-----------------------------------------------+ 158 Figure 2: The proposed Multipath TCP new ADD_ADDR option format 160 2.1. Reliability 162 A first issue with the ADD_ADDR option is that since it is 163 transmitted as a TCP option, it is not delivered reliably 164 [Cellnet12]. When a host announces an IPv4 address, it can insert 165 the ADD_ADDR option inside a segment that carries data that would 166 thus be delivered reliably like user data. However, if the ADD_ADDR 167 option contains an IPv6 address, it might be too large to fit inside 168 a segment that already contains a DSS option and possibly other 169 options such as the [RFC1323] timestamps. Given its length, the 170 ADD_ADDR option cannot be placed in the same segment as a DSS option. 171 In these two cases, the ADD_ADDR option will be often transmitted 172 inside a duplicate ACK that is not delivered reliably. [Cellnet12] 173 proposes a method to improve the reliability of the transmission of 174 the ADD_ADDR option, but to our knowledge this method has never been 175 implemented. To cope with packet losses, we propose to rely on the 176 "E" (Echo) flag in the ADD_ADDR option (Figure 3). 178 1 2 3 179 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 180 +---------------+---------------+-------+-------+---------------+ 181 | Kind | Length |Subtype|E|(rsv)| Address ID | 182 +---------------+---------------+-------+-------+---------------+ 184 Figure 3: The part of the proposed Multipath TCP new ADD_ADDR option 185 format with the Echo flag 187 The "E" flag is the "Echo" flag. When set to 0, it indicates that 188 the host sending this option is advertising a new address to the 189 receiving host. When set to 1, it indicates that the host sending 190 this option acknowledges the reception of an ADD_ADDR option by 191 echoing it. Upon reception of an ADD_ADDR option without the "E" 192 flag set, the receiving host MUST return the exact option that it 193 received with the "E" flag set to 1 to indicate the reception of the 194 ADD_ADDR option. If an host advertising a new address does nt 195 receive an echo, or receives an invalid echo of the option it MAY 196 retransmit the ADD_ADDR. To cope with the loss of the echo of the 197 option, if an host that advertised a new address without receiving 198 the echo receives an MP_JOIN on this address, it MUST consider this 199 address as having been echoed, and MUST NOT retransmit this ADD_ADDR 200 again. 202 2.2. Backup 204 The subflows that compose a Multipath TCP connection are not all 205 equal. [RFC6824] defines two types of subflows: 207 o the regular subflows 209 o the backup subflows 211 The regular subflows can be used to transport any data. The backup 212 subflows are intended to be used only when all the regular subflows 213 fail. [RFC6824] defines them by using the following sentence: "Hosts 214 can indicate at initial subflow setup whether they wish the subflow 215 to be used as a regular or backup path - a backup path only being 216 used if there are no regular paths available." 218 In [RFC6824] a host can specify the type of a subflow during the 219 three-way-handshake by using the "B" flag of the MP_JOIN option as 220 shown in Figure 4 and Figure 5 or when the subflow is already 221 established by sending an MP_PRIO option shown in Figure 6. 223 1 2 3 224 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 225 +---------------+---------------+-------+-----+-+---------------+ 226 | Kind | Length = 12 |Subtype| |B| Address ID | 227 +---------------+---------------+-------+-----+-+---------------+ 228 | Receiver's Token (32 bits) | 229 +---------------------------------------------------------------+ 230 | Sender's Random Number (32 bits) | 231 +---------------------------------------------------------------+ 233 Figure 4: Join Connection (MP_JOIN) Option (for Initial SYN) 235 1 2 3 236 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 237 +---------------+---------------+-------+-----+-+---------------+ 238 | Kind | Length = 16 |Subtype| |B| Address ID | 239 +---------------+---------------+-------+-----+-+---------------+ 240 | | 241 | Sender's Truncated HMAC (64 bits) | 242 | | 243 +---------------------------------------------------------------+ 244 | Sender's Random Number (32 bits) | 245 +---------------------------------------------------------------+ 247 Figure 5: Join Connection (MP_JOIN) Option (for Responding SYN/ACK) 249 1 2 3 250 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 251 +---------------+---------------+-------+-----+-+--------------+ 252 | Kind | Length |Subtype| |B| AddrID (opt) | 253 +---------------+---------------+-------+-----+-+--------------+ 255 Figure 6: Change Subflow Priority (MP_PRIO) Option 257 Both solutions rely on the principle that a subflow can be set in 258 backup mode only when being already established or during the subflow 259 setup. On mobile devices, backup subflows consume radio ressources 260 when they are established. This could unnecessarily consume both 261 energy on the mobile device [ATC14] and radio ressources in the 262 network for subflows that do not carry any data. Measurements on 263 smartphones [PAM2016] indicate that many subflows do not carry any 264 data but still consume resources for the SYN, RST and FIN packets. 266 To allow hosts using Multipath TCP to save ressources, we propose to 267 add the "B" "Backup" Flag in the ADD_ADDR option as shown in 268 Figure 7. This would allow an host to save ressources by being aware 269 of the remote backup addresses that could be used if all the non- 270 backup subflows fail without having to establish a subflow, achieving 271 a break-before-make scheme. 273 1 2 3 274 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 275 +---------------+---------------+---------------+---------------+ 276 | Commu |prio |B| Port (2 octets, optional) | | 277 +---------------+---------------+---------------+ | 279 Figure 7: The part of the proposed Multipath TCP new ADD_ADDR option 280 format with the Backup flag 282 2.3. Priorities 284 The backup mode defined in [RFC6824] only supports an "all-or- 285 nothing" mode in the usage of the subflows, where an host might just 286 prefer to use certain subflow over others. 288 To allow an host to inform the receving host about its preference in 289 terms of subflow usage, we propose to modify the ADD_ADDR option by 290 adding 3 "priority" bits as shown in Figure 8. 292 1 2 3 293 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 294 +---------------+---------------+---------------+---------------+ 295 | Commu |prio |B| Port (2 octets, optional) | | 296 +---------------+---------------+---------------+ | 298 Figure 8: The part of the proposed Multipath TCP new ADD_ADDR option 299 format with the priority bits 301 This host MAY use this priority to determine when to establish a 302 subflow towards this address. The priority field MUST be interpreted 303 as an unsigned integer value with the highest numerical value being 304 the most preferred one. 306 To allow the priority of an already established subflow to be 307 modified, we propose to modify the MP_PRIO option by adding the 3 308 priority bits next to the "B" flag has shown in Figure 9. 310 1 2 3 311 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 312 +---------------+---------------+-------+-----+-+--------------+ 313 | Kind | Length |Subtype|prio |B| AddrID (opt) | 314 +---------------+---------------+-------+-----+-+--------------+ 316 Figure 9: Change Subflow Priority (MP_PRIO) Option with 3 priority 317 bits added 319 To allow the hosts to advertise a per-subflow priority during the 320 three-way-handshake we modify the MP_JOIN option by adding the 3 321 priority bits as shown in Figure 10 and Figure 11, 323 1 2 3 324 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 325 +---------------+---------------+-------+-----+-+---------------+ 326 | Kind | Length = 12 |Subtype| prio|B| Address ID | 327 +---------------+---------------+-------+-----+-+---------------+ 328 | Receiver's Token (32 bits) | 329 +---------------------------------------------------------------+ 330 | Sender's Random Number (32 bits) | 331 +---------------------------------------------------------------+ 333 Figure 10: Join Connection (MP_JOIN) Option (for Initial SYN) with 334 the 3 priority bits 336 1 2 3 337 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 338 +---------------+---------------+-------+-----+-+---------------+ 339 | Kind | Length = 16 |Subtype| prio|B| Address ID | 340 +---------------+---------------+-------+-----+-+---------------+ 341 | | 342 | Sender's Truncated HMAC (64 bits) | 343 | | 344 +---------------------------------------------------------------+ 345 | Sender's Random Number (32 bits) | 346 +---------------------------------------------------------------+ 348 Figure 11: Join Connection (MP_JOIN) Option (for Responding SYN/ACK) 349 with the 3 priority bits 351 The priority bits included in the MP_JOIN specify indicate the 352 priority associated to this subflow. A host MAY use this information 353 when scheduling packets over this particular subflow. 355 2.4. Path diversity 357 +--- IPv4 1 ---+ 358 | | 359 +--- IPv6 1 ---+--- Interface 1 ---+ 360 | | | 361 client --- Internet ---+--- IPv6 2 ---+ | 362 | +--- Server 363 | | 364 | | 365 +--- IPv4 1 ---+--- Interface 2 ---+ 367 Figure 12: A dual stack server with multiple IP addresses attached to 368 the same interface. 370 As shown in Figure 12 a host might have several IP addresses assigned 371 to a single interface. Some clients would like to be able to create 372 subflows over disjoint paths to maximise the diversity of the 373 subflows. With the current ADD_ADDR option, the host receiving 374 several ADD_ADDR has no way of knowing the diversity between these 375 path. In the case of Figure 12 it could end up establishing 4 376 subflows where 2 could be sufficient to maximise diversity. 378 To allow a host to inform the receiving host about the diversity of 379 several addresses we propose to modify the ADD_ADDR to include 4 bits 380 describing a "Community" associated to this address. The community 381 values are an opaque field and it is expected that two addresses 382 having the same community share some resources. 384 1 2 3 385 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 386 +---------------+---------------+---------------+---------------+ 387 | Commu |B|prio | Port (2 octets, optional) | | 388 +---------------+---------------+---------------+ | 390 Figure 13: The part of the proposed Multipath TCP new ADD_ADDR option 391 format with the Community bits 393 With the community bits, a dual-stack host could elect to regroup all 394 the addresses attached to a single interface under the same 395 community, allowing the receiving host to decide on which advertised 396 addresses it wants to establish new subflows. 398 2.5. Load balancing 400 Many large web sites are served by servers that are behind a load 401 balancer. The load balancer receives the connection establishment 402 attempts and forwards them to the actual servers that serve the 403 requests. One issue for the end-to-end deployment of Multipath TCP 404 is it ability to be used on load-balancers. Different types of load 405 balancers are possible. We consider a simple but important load 406 balancer than does not maintain any per-flow state. This load 407 balancer is illustrated in illustrated in Figure 14. A stateless 408 load balancer can be implemented by hashing the five tuple (IP 409 addresses and port numbers) of each incoming packet and forward them 410 to one of the servers based on the hash value computed. With TCP, 411 this load balancer ensures that all the packets that belong to one 412 TCP connection are sent to the same server. 414 +--+---- S1 415 ---|LB|---- S2 416 +--+---- S3 418 Figure 14: Stateless load balancer 420 With Multipath TCP, this approach cannot be used anymore when 421 subflows are created by the clients. Such subflows can use any five 422 tuple and thus packets belonging to them will be forwarded over any 423 server, not necessarily the one that was selected by the hashing 424 function for the initial subflow. 426 To allow Multipath TCP to work for hosts being hosted behind 427 unmodified layer 4 load balancers, we propose to use the unused "B" 428 flag in the MP_CAPABLE option sent (shown in Figure 15 in the 429 SYN+ACK. This flag would allow a host behind a layer 4 load balancer 430 to inform the other host that this address MUST NOT be used to create 431 additional subflows. 433 A host receiving an MP_CAPABLE with the "B" set to 1 MUST NOT try to 434 establish a subflow to the address used in the MP_CAPABLE. This bit 435 can also be used in the MP_CAPABLE option sent in the SYN by a client 436 that resides behind a NAT or firewall or does not accept server- 437 initiated subflows. 439 1 2 3 440 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 441 +---------------+---------------+-------+-------+---------------+ 442 | Kind | Length |Subtype|Version|A|B|C|D|E|F|G|H| 443 +---------------+---------------+-------+-------+---------------+ 444 | Option Sender's Key (64 bits) | 445 | (if option Length > 4) | 446 | | 447 +---------------------------------------------------------------+ 448 | Option Receiver's Key (64 bits) | 449 | (if option Length > 12) | 450 | | 451 +-------------------------------+-------------------------------+ 452 | Data-Level Length (16 bits) | Checksum (16 bits, optional) | 453 +-------------------------------+-------------------------------+ 455 Figure 15: Multipath Capable (MP_CAPABLE) Option 457 This bit can be used by the servers behind a stateless load 458 balancers. Each of these servers has a different IP address than the 459 address of the load balancer. The servers set the "B" flag in the 460 MP_CAPABLE option that they return and advertise their own address by 461 using the ADD_ADDR option. Upon reception of this option, the 462 clients can create the additional subflows towards these addresses. 463 Compared with current stateless load balancers, an advantage of this 464 approach is that the packets belonging to the additional subflows do 465 not need to pass through the load balancer. 467 3. IANA considerations 469 This document proposes some modifications to the Multipath TCP 470 options defined in [RFC6824]. These modifications do not require any 471 specific action from IANA. 473 4. Security considerations 475 The security considerations defined for Multipath TCP in [RFC6182] 476 and [RFC7430] are applicable. 478 The "E" flag, community and priority values in the ADD_ADDR option do 479 not change the security considerations for the handling of this 480 option. Since the ADD_ADDR option is protected by an HMAC, an off- 481 path attacker cannot inject such an option in an existing Multipath 482 TCP connection. 484 The "priority" field of the MP_PRIO option is not protected by a 485 HMAC. It could be useful to consider the utilisation of an HMAC to 486 protect this option like the ADD_ADDR option. 488 The "B" flag of the MP_CAPABLE option does not change the security 489 considerations of this option. If an attacker that resides on a path 490 sets this bit, it could prevent the establishment of subflows. 491 However, Multipath TCP does not protect against an attacker that 492 resides on the path of the initial subflow and can modify the SYN/ 493 SYN+ACK packets. 495 5. Conclusion 497 In this document, we have discussed several issues with the 498 advertisement of addresses with the address advertisement in 499 Multipath TCP. We have proposed several modifications to the 500 protocol to address these issues. 502 6. References 504 6.1. Normative References 506 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 507 "TCP Extensions for Multipath Operation with Multiple 508 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 509 . 511 6.2. Informative References 513 [ATC14] Yeon-sup Lim, ., Yung-Chih Chen, ., Nahum, Erich., Don 514 Towsley, ., and . Richard Gibbens, "How green is multipath 515 TCP for mobile devices?", AllThingsCellular14 , 2014. 517 [Cellnet12] 518 Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O. 519 Bonaventure, "Exploring Mobile/WiFi Handover with 520 Multipath TCP", ACM SIGCOMM workshop on Cellular Networks 521 (Cellnet12) , 2012, 522 . 525 [I-D.ietf-mptcp-rfc6824bis] 526 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 527 Paasch, "TCP Extensions for Multipath Operation with 528 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-06 (work 529 in progress), July 2016. 531 [PAM2016] Quentin De Coninck, ., Matthieu Baerts, ., Benjamin 532 Hesmans, ., and O. Bonaventure, "A First Analysis of 533 Multipath TCP on Smartphones", 17th International Passive 534 and Active Measurements Conference , April 2016, 535 . 538 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 539 793, DOI 10.17487/RFC0793, September 1981, 540 . 542 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 543 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 544 1992, . 546 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 547 Iyengar, "Architectural Guidelines for Multipath TCP 548 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 549 . 551 [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 552 Raiciu, "Analysis of Residual Threats and Possible Fixes 553 for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/ 554 RFC7430, July 2015, 555 . 557 Authors' Addresses 559 Fabien Duchene 560 UCLouvain 562 Email: fabien.duchene@uclouvain.be 564 Olivier Bonaventure 565 UCLouvain 567 Email: Olivier.Bonaventure@uclouvain.be