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