idnits 2.17.1 draft-barre-mptcp-tfo-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 29, 2018) is 2152 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-mptcp-rfc6824bis-11 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group S. Barre 3 Internet-Draft G. Detal 4 Intended status: Informational Tessares 5 Expires: November 30, 2018 O. Bonaventure 6 UCLouvain and Tessares 7 C. Paasch 8 Apple 9 May 29, 2018 11 TFO support for Multipath TCP 12 draft-barre-mptcp-tfo-03 14 Abstract 16 TCP Fast Open (TFO) is a TCP extension that allows sending data in 17 the SYN, instead of waiting until the TCP connection is established. 18 This document describes what parts of Multipath TCP must be adapted 19 to support it, and how TFO and MPTCP can operate together. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 30, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. TFO cookie request with MPTCP . . . . . . . . . . . . . . . . 3 57 3. Data sequence mapping under TFO . . . . . . . . . . . . . . . 4 58 4. Early context creation in server . . . . . . . . . . . . . . 4 59 5. Using TFO to avoid useless MPTCP negotiations . . . . . . . . 5 60 6. Using TFO with MP_JOIN . . . . . . . . . . . . . . . . . . . 6 61 7. Connection establishment examples . . . . . . . . . . . . . . 6 62 8. Middlebox interactions . . . . . . . . . . . . . . . . . . . 8 63 9. Security considerations . . . . . . . . . . . . . . . . . . . 9 64 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 66 12. Informative References . . . . . . . . . . . . . . . . . . . 10 67 Appendix A. Implementation status . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 TCP Fast Open, described in [RFC7413], has been introduced with the 73 objective of gaining one RTT before transmitting data. This is 74 considered a valuable gain as very short connections are very common, 75 especially for HTTP request/response schemes. MPTCP, on the other 76 hand, has been defined in [I-D.ietf-mptcp-rfc6824bis] to add 77 multipath support to TCP, where a TCP flow is divided in several TCP 78 subflows. Given that MPTCP can be applied transparently to any TCP 79 socket, without the application knowing, it should be able to support 80 TCP fast open when the application asks for it. 82 When doing that, one important thing to examine is the option length 83 consumed in segments that would carry both a TFO and an MPTCP option. 84 The handling of MPTCP data sequence mappings must also be updated to 85 take into account the data that is sent together with the SYN or the 86 SYN+ACK. A third issue to handle is the state creation in the 87 server: TFO allows the server to create TCP state as soon as a SYN is 88 received. With MPTCP, even more state is created, and it may be 89 useful to avoid this in a situation where MPTCP does not work but TFO 90 does. 92 The rest of this document is organized as follows: 94 Section 2 describes the TFO cookie request, in the case of a 95 Multipath TCP flow. Section 3 proposes a way to map SYN data to the 96 data sequence number space, while taking middleboxes into account. 98 In Section 4, it is explained that the MP_CAPABLE option is no longer 99 always necessary in the third ack of the three-way handshake. 100 Section 5 presents two ways to avoid useless MPTCP context creations 101 in the server, one for client implementations, the other for server 102 implementations, as a TFO extension. Section 6 takes the MP_JOIN 103 case into consideration. Finally, we describe middlebox interactions 104 in Section 8, and security considerations in Section 9. 106 2. TFO cookie request with MPTCP 108 When a TFO client first connects to a server, it cannot immediately 109 include data in the SYN for security reasons [RFC7413]. Instead, it 110 requests a cookie that will be used in subsequent connections. This 111 is done with the TCP cookie request/response options, of resp. 2 112 bytes and 6-18 bytes (depending on the chosen cookie length). 114 TFO and MPTCP can be combined provided that the total length of their 115 options does not exceed the maximum 40 bytes possible in TCP: 117 o In the SYN: MPTCP uses a 4-bytes long MP_CAPABLE option. The 118 MPTCP and TFO options sum up to 6 bytes. 119 [I-D.ietf-mptcp-rfc6824bis] mentions in Appendix A that SYN packet 120 options typically sum up to 19 bytes, or 24 bytes where 121 implementations pad each option up to a word boundary. Even in 122 the worst case, this fits the maximum option space. 124 o In the SYN+ACK: MPTCP uses a 12-bytes long MP_CAPABLE option, but 125 now TFO can be as long as 18 bytes. Since the maximum option 126 length may be exceeded, it is up to the server to solve this by 127 using a shorter cookie or pad the whole option block instead of 128 each option separately. Alternatively, the server may decide to 129 fallback to MPTCP-only (by not giving a cookie at all), or to TFO- 130 only. As an example, if we consider that 19 bytes are used for 131 classical TCP options, the maximum possible cookie length would be 132 of 7 bytes. The consequence of this, from a security viewpoint, 133 is explored in Section 9. Note that the same limitation applies 134 to subsequent connections, for the SYN packet (because the client 135 then echoes back the cookie to the server). Finally, if the 136 security impact of reducing the cookie size is not deemed 137 acceptable, the server can reduce the amount of other TCP-options 138 by omitting the TCP timestamps. Indeed, as outlined in 139 [I-D.ietf-mptcp-rfc6824bis] in Appendix A, an MPTCP connection 140 could also avoid the use of TCP timestamps thanks to MPTCP's use 141 of 64-bit sequence numbers which already provides protection 142 against wrapped sequence numbers. 144 o In the third ACK: Nothing special compared to MPTCP, since no TFO 145 option is used there. 147 Once the cookie has been successfully exchanged, the rest of the 148 connection is just regular MPTCP. The rest of this document assumes 149 that the cookie request has been exchanged, and that data can be 150 included in the SYN. 152 3. Data sequence mapping under TFO 154 MPTCP [I-D.ietf-mptcp-rfc6824bis] uses, in the TCP establishment 155 phase, a key exchange that is used to generate the Initial Data 156 Sequence Numbers (IDSNs). More precisely, 157 [I-D.ietf-mptcp-rfc6824bis] states in section 3.1 that "The SYN with 158 MP_CAPABLE occupies the first octet of data sequence space, although 159 this does not need to be acknowledged at the connection level until 160 the first data is sent". With TFO, one way to handle the data sent 161 together with the SYN would be to consider an implicit DSS mapping 162 that covers that SYN segment (since there is not enough space in the 163 SYN to include a DSS option). The problem with that approach is that 164 if a middlebox modifies the TFO data, this will not be noticed by 165 MPTCP because of the absence of a DSS-checksum. For example, a TCP 166 (but not MPTCP)-aware middlebox could insert bytes at the beginning 167 of the stream and adapt the TCP checksum and sequence numbers 168 accordingly. With an implicit mapping, this would give to client and 169 server a different view on the DSS-mapping, with no way to detect 170 this inconsistency as the DSS checksum is not present. One way to 171 solve this is to simply consider that the TFO data is not part of the 172 Data Sequence Number space: the SYN with MP_CAPABLE still occupies 173 the first octet of data sequence space, but then the first non-TFO 174 data byte occupies the second octet. This guarantees that, if the 175 use of DSS-checksum is negotiated, all data in the data sequence 176 number space is checksummed. We also note that this does not entail 177 a loss of functionality, because TFO-data is always sent when only 178 one path is active. 180 4. Early context creation in server 182 In order to enable the server to receive and send data before the end 183 of the three-way handshake, TFO allows creating state on the server 184 as soon as the SYN is received if a valid cookie is provided. The 185 MPTCP state should then also be created upon SYN reception (see 186 exceptions for that in Section 5). 188 DISCUSSION: Doing that allows relaxing the MPTCP MP_CAPABLE exchange, 189 in that the sender's and receiver's keys are no longer required in 190 the third ack of the three-way handshake, because their role was 191 precisely to compensate for the absence of server state until the end 192 of the establishment. The consequence is that the MP_CAPABLE option 193 can simply be removed from the third ack. However, an MPTCP option 194 must still be present when concluding the three-way handshake, to 195 confirm to the server that its own MP_CAPABLE option (in the SYN+ACK) 196 has been correctly received by the client. The DSS option can 197 replace the MP_CAPABLE option, while simultaneously allowing the 198 transmission of more data in the third ack. Moreover, providing a 199 DSS option to the server early allows faster establishment of new 200 subflows (see [I-D.ietf-mptcp-rfc6824bis], Section 3.1). 202 In order to decide whether it can send a third ack with DSS-only 203 instead of MP_CAPABLE, a client must verify if the TFO data has been 204 at least partially acknowledged. If the SYN+ACK only acknowledges 205 the SYN, TFO may be not supported in the server, or the cookie may 206 have been filtered by the network. There is no guarantee that the 207 MPTCP state has been created, and the third ack should contain the 208 MP_CAPABLE option, with the client and server keys. 210 5. Using TFO to avoid useless MPTCP negotiations 212 The TFO cookie, sent in a SYN, indicates that a previous connection 213 has been successfully established, and that TCP state can safely be 214 created. It does not however say anything about whether the MPTCP 215 options are filtered or not in the network. It is thus possible that 216 a server creates an MPTCP context upon SYN+TFO cookie reception, then 217 actually needs to discard it after having discovered that the MPTCP 218 options are filtered. 220 One way to solve this would be for the client to cache destinations 221 that do support MPTCP. TFO allows sending data together with the SYN 222 starting at the second connection. The first one is used to learn 223 the cookie from the server. It could also be used to learn whether 224 MPTCP can be used with the peer. 226 DISCUSSION: The other, compatible way to solve the problem is to 227 extend TFO and cache the Multipath Capability in the cookie generated 228 by the server. The server could modify its cookie computation, to 229 include multipath capability information in the cookie. Then, upon 230 SYN+TFO cookie reception, the server could easily determine if the 231 initial TFO flow was a successful MPTCP connection or not. The 232 problem with this approach is that the server does not know yet 233 whether the flow is multipath-capable when sending the TFO cookie. 234 It could then send a first pessimistic cookie, as 235 GetCookie(IP_Address, mp_capable=false) (adapted from [RFC7413], 236 Section 4.1.2). Then, when it is determined that the flow is 237 Multipath Capable (third ack received with an MPTCP option), a new 238 cookie=GetCookie(IP_Address, mp_capable=true) can be generated and 239 sent in the FIN to ensure reliable delivery. 241 6. Using TFO with MP_JOIN 243 TFO must not be used when establishing joined subflows. Doing that 244 would be in contradiction with [I-D.ietf-mptcp-rfc6824bis], that 245 states in section 3.2 that "It is not permitted to send data while in 246 the PRE_ESTABLISHED state". Using TFO with joined subflows would 247 mean that data is sent even before getting to the PRE_ESTABLISHED 248 state. 250 7. Connection establishment examples 252 In this section we show a few examples of possible TFO+MPTCP 253 establishment scenarios. For representing segments, we use the 254 Tcpdump syntax. 256 Before a client can send data together with the SYN, it must request 257 a cookie to the server, as shown in Figure 1. This is done by simply 258 combining the TFO and MPTCP options. 260 client server 261 | | 262 | S 0(0) , | 263 | -----------------------------------------------------------> | 264 | | 265 | S. 0(0) ack 1 , | 266 | <----------------------------------------------------------- | 267 | | 268 | . 0(0) ack 1 | 269 | -----------------------------------------------------------> | 270 | | 272 Figure 1: Cookie request 274 Once this is done, the received cookie can be used for TFO, as shown 275 in Figure 2. The MP_CAPABLE is no longer required for the third ack, 276 as explained in Section 4. Note that the last segment in the figure 277 has a TCP sequence number of 21, while the DSS subflow sequence 278 number is 1 (because the TFO data is not part of the data sequence 279 number space, as explained in Section 3. 281 client server 282 | | 283 | S 0(20) , | 284 | -----------------------------------------------------------> | 285 | | 286 | S. 0(0) ack 21 | 287 | <----------------------------------------------------------- | 288 | | 289 | . 1(100) ack 21 | 290 | <----------------------------------------------------------- | 291 | | 292 | . 21(20) ack 101 | 293 | -----------------------------------------------------------> | 294 | | 296 Figure 2: The server supports TFO 298 In Figure 3, the server does not support TFO. The client detects 299 that no state is created in the server (as no data is acked), and now 300 sends the MP_CAPABLE in the third ack, in order for the server to 301 build its MPTCP context at then end of the establishment. Now, the 302 tfo data, retransmitted, becomes part of the data sequence mapping 303 because it is effectively sent (in fact re-sent) after the 304 establishment. 306 client server 307 | | 308 | S 0(20) , | 309 | -----------------------------------------------------------> | 310 | | 311 | S. 0(0) ack 1 | 312 | <----------------------------------------------------------- | 313 | | 314 | . 21(0) ack 1 | 315 | -----------------------------------------------------------> | 316 | | 317 | . 1(20) ack 1 | 318 | -----------------------------------------------------------> | 319 | | 320 | . 0(0) ack 21 | 321 | <----------------------------------------------------------- | 323 Figure 3: The server does not support TFO 325 It is also possible that the server acknowledges only part of the TFO 326 data, as illustrated in Figure 4. 328 client server 329 | | 330 | S 0(1000) , | 331 | -----------------------------------------------------------> | 332 | | 333 | S. 0(0) ack 501 | 334 | <----------------------------------------------------------- | 335 | | 336 | . 501(500) ack 1 | 337 | -----------------------------------------------------------> | 338 | | 340 Figure 4: Partial data acknowledgement 342 8. Middlebox interactions 344 [I-D.ietf-mptcp-rfc6824bis], Section 6, describes middlebox 345 interactions for Multipath TCP. This document does not define any 346 new option compared to MPTCP or TFO. It defines a combination of 347 them. 349 TFO also defines how an implementation should react when the TFO SYN 350 is lost (fallback to regular TCP, [RFC7413] Section 4.2.1). 352 We propose to remove the MP_CAPABLE option from the third ack when 353 TFO is used, based on the assumption that the context has been 354 created already in the server upon SYN reception. Should the server 355 actually not create this state, it would not be able to create its 356 MPTCP state and would fallback to regular TCP. The state is not 357 created in the server if it has no TFO support or the cookie is 358 invalid, but in that case only the SYN is acknowledged, and the 359 client does send the MP_CAPABLE option. 361 The other case where the server does not create MPTCP state is when 362 the cookie includes a "mp_capable=false" information. In that case, 363 regular TCP is used to take into account middleboxes that prevent 364 correct MPTCP operation. 366 Even though this document presents mechanisms for collaboration 367 between MPTCP and TFO, the filtering of one will not stop the other 368 from working. For example, if a TFO option is dropped, MPTCP will 369 fallback to sending MP_CAPABLE in third_ack, because no TFO data is 370 acked. If the server stores MPTCP information in the cookie, this 371 will be completely opaque to the network, and even to the client. 372 Should that cookie be transformed or lost, it would not be accepted 373 anymore by the server, which would fallback to regular MPTCP 374 communication, or regular TCP if MPTCP options are also filtered or 375 modified. 377 The problem of middleboxes that alter the TFO data is solved by the 378 fact that TFO data is not part of the Data Sequence Number space, as 379 explained in Section 3. 381 9. Security considerations 383 Compared to using TFO or MPTCP alone, implementing the present 384 combination could lead to more state created in the server, since 385 MPTCP now creates state as soon as the first SYN is received. This 386 is however not considered as a problem, for the following reasons: 388 o The server will only create state when a valid TFO cookie is 389 received. This guarantees that a successful TCP connection has 390 been previously established with the same peer. 392 o It remains possible that a useless MPTCP context is created upon 393 SYN reception (due to TFO support but MPTCP options being filtered 394 by the network). This is more an optimization issue than a 395 security issue given the TFO cookie protection already present. 396 Section 5 still proposes a solution to avoid creating MPTCP state 397 in that case. 399 o When under memory pressure, a server always has the option to 400 refuse the client cookie. In that case, the session establishment 401 will happen without data, and the client will send the MP_CAPABLE 402 option in the third ack so that the server can create the MPTCP 403 context at that time. 405 As mentioned in Section 2, it may be required to reduce the length of 406 the cookie when MPTCP and TFO are used together. This can become a 407 security issue when attackers and networks become fast enough for a 408 brute force attack to be successful. An option to solve this would 409 be to use TCP payload to store additional options, as suggested in 410 [I-D.ietf-mptcp-rfc6824bis], Section 5. Another way would be to 411 allow longer TCP options by using an "Extended Data Offset Option" 412 [I-D.touch-tcpm-tcp-edo]. The problem with this is that the most 413 problematic segment in the present case is the SYN (with long TFO 414 cookie and MP_CAPABLE MPTCP option), for which it is more difficult 415 to apply the Extended Data Offset Option ([I-D.touch-tcpm-tcp-edo], 416 Section 7.7). 418 10. Conclusion 420 In this document, we have proposed minor extensions to MPTCP and TFO 421 to allow them to operate together. In particular, we proposed 422 excluding the TFO data from the data sequence number space. We 423 explained that TFO allows to relax the MPTCP establishment in that 424 the MP_CAPABLE option of the third ack can be removed in some cases. 425 We also emphasized that such a combination augments the size of the 426 TCP options, already quite large, although the combination is still 427 possible with common TCP options and limited cookie length. We also 428 proposed a way to cache multipath capability information in the 429 client or in the TFO cookie. Finally, we examined potential 430 middlebox interaction problems, or security problems that would arise 431 from that combined operation. 433 11. Acknowledgements 435 This work was supported by the FP7-Trilogy2 project and by the 436 Belgian Walloon Region under its FIRST Spin-Off Program (RICE 437 project). 439 12. Informative References 441 [I-D.ietf-mptcp-rfc6824bis] 442 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 443 Paasch, "TCP Extensions for Multipath Operation with 444 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-11 (work 445 in progress), May 2018. 447 [I-D.touch-tcpm-tcp-edo] 448 Touch, J. and W. Eddy, "TCP Extended Data Offset Option", 449 draft-touch-tcpm-tcp-edo-03 (work in progress), July 2014. 451 [MultipathTCP-Linux] 452 Paasch, C., Barre, S., and . et al, "Multipath TCP in the 453 Linux kernel", n.d., . 455 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 456 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 457 . 459 Appendix A. Implementation status 461 In this section, we present the report of the implementation of this 462 draft inside the Linux reference implementation of Multipath TCP 463 [MultipathTCP-Linux]. The support of TFO in the MPTCP stack has been 464 implemented on the 3.14 kernel (MPTCP v0.89). 466 The main design choices of this implementation are the following: 468 o Minimize the modification to the current MPTCP and TFO stacks, 469 i.e. let the TFO stack deal with sending data, receiving data 470 inside the SYN. 472 o Create the MPTCP state when receiving a SYN with a valid token on 473 the server side as defined in Section 4. 475 o Map the remaining data segments in the receive and send buffers to 476 MPTCP data sequence numbers. 478 This latter point needs further explanation. First, in the current 479 reference implementation of MPTCP, the MPTCP state is created upon 480 reception of the SYN+ACK on the client-side. The implementation 481 however did the MPTCP state allocation before processing the actual 482 acknowledgement at the subflow level. This means that data (even 483 acknowledged by the SYN+ACK) remains in the send buffer at the time 484 of the allocation (which contained only the SYN in the case of 485 regular MPTCP). We modified this behaviour to ensure that only 486 unacknowledged data remains in the send buffer when allocating the 487 state. Moreover, as the data was initially sent over the regular TCP 488 flow, they had no MPTCP sequence numbers (the MPTCP state did not 489 exist during the initial sendto() call). After the allocation of the 490 MPTCP state, we modify these sequence numbers such that they are 491 mapped starting at "IDSN + 1". This effectively gives the data 492 sequence number "IDSN + 1" to the first byte following the 493 establishement, since the acknowledged TFO data has been removed 494 fromt the queues at this point. This data will then follow the same 495 path as for data sent via a regular write() call. 497 As is the case for unacknowledged data on the client-side, the 498 server-side can also have data in the receive buffer (the data sent 499 in the SYN). We perform the same operation by mapping this data from 500 TCP to MPTCP sequence numbers. TFO data is then mapped ahead of the 501 IDSN, so as to ensure, again, that the first byte following the 502 establishment has the data sequence number "IDSN + 1". 504 As of this writing, the implementation still generates a regular 505 third acknowledgment with a MP_CAPABLE option (see Section 4) and it 506 does not take benefit from the TFO cache to avoid useless MPTCP 507 negotiation (see Section 5). 509 Authors' Addresses 510 Sebastien Barre 511 Tessares 513 Email: sebastien.barre@tessares.net 515 Gregory Detal 516 Tessares 518 Email: gregory.detal@tessares.net 520 Olivier Bonaventure 521 UCLouvain and Tessares 523 Email: Olivier.Bonaventure@tessares.net 525 Christoph Paasch 526 Apple 528 Email: cpaasch@apple.com