idnits 2.17.1 draft-bonaventure-mptcp-rst-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 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 1. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6528 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP O. Bonaventure 3 Internet-Draft C. Paasch 4 Intended status: Experimental G. Detal 5 Expires: January 4, 2015 UCLouvain 6 July 03, 2014 8 Processing of RST segments by Multipath TCP 9 draft-bonaventure-mptcp-rst-00 11 Abstract 13 This document discusses how a Multipath TCP implementation should 14 generate and process RST segments. 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 4, 2015. 33 Copyright Notice 35 Copyright (c) 2014 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 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 52 2. Generation of RST segments . . . . . . . . . . . . . . . . . 4 53 2.1. Lack of ressources . . . . . . . . . . . . . . . . . . . 4 54 2.2. Administratively prohibited . . . . . . . . . . . . . . . 4 55 2.3. Too many already acknowledged data . . . . . . . . . . . 5 56 2.4. Unacceptable performance . . . . . . . . . . . . . . . . 5 57 2.5. Lifetime expired . . . . . . . . . . . . . . . . . . . . 6 58 2.6. Removed address . . . . . . . . . . . . . . . . . . . . . 6 59 2.7. Middlebox interference has been detected . . . . . . . . 7 60 2.8. Multipath TCP specific errors . . . . . . . . . . . . . . 7 61 2.9. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.10. Unspecified TCP error . . . . . . . . . . . . . . . . . . 7 63 3. The MPTCP RST option . . . . . . . . . . . . . . . . . . . . 8 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 69 7.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 The Transmission Control Protocol (TCP) [RFC0793] was designed to 75 provide a reliable data transfer between hosts attached to a single 76 IP address. Multipath TCP [RFC6824] is a recent extension that 77 enables a single TCP connection to use multiple paths. For Multipath 78 TCP, each path corresponds to a TCP connection established between 79 the communicating hosts. Each of these connections is identified by 80 the classical four-tuple (source and destination IP addresses and 81 source and destination port numbers). Multipath TCP allows to group 82 several of these TCP connections, called subflows in [RFC6824] inside 83 a single Multipath TCP connection. It should be noted that the 84 number of subflows that are used for a given Multipath TCP connection 85 is not fixed and can change during the lifetime of a Multipath TCP 86 connection. 88 In regular TCP, the RST flag is used to abruptly terminate a TCP 89 connection. When a host receives a valid TCP segment with the RST 90 flag, it immediately terminates the connection. This causes the loss 91 of all in-flight data that has not yet been acknowledged. In the 92 original TCP specification, a host could generate a segment with the 93 RST flag in the following cases: 95 o A host receives a non-SYN segment that corresponds to a TCP 96 connection that does not exist (anymore). 98 o A host receives a SYN segment and does not want to establish the 99 requested connection for any reason. 101 o A host has tried to retransmit the same data too many times 102 without having received an acknowledgment. 104 o The corresponding connection has been idle for a long time and no 105 answer has been received to the keepalive segments that the host 106 has sent over this TCP connection [RFC1122] 108 o A host does not have enough resources anymore (e.g. memory) to 109 support the established connection. 111 Over the years, other reasons to use the RST flag have been added to 112 TCP implementations. The most important one is the possibility for 113 an application, typically a server, to abruptly terminate a TCP 114 connection by forcing the stack to send a segment with the RST flag 115 instead of waiting for the normal FIN exchange and being forced to 116 maintain state. 118 Despite the fact that TCP is a transport protocol that is used only 119 on endhosts, various types of middleboxes are known to spoof TCP 120 segments that contain the RST flag to abruptly terminate TCP 121 connections [IMC11]. Some of these middleboxes terminate TCP 122 connections to block some applications such as P2P file transfers, 123 others provide security services such as DPI and terminate TCP 124 connections once they have identified suspicious data in the payload. 125 This behavior of middleboxes has been considered as harmful in 126 [RFC3360]. 128 Multipath TCP cannot simply behave like regular TCP when transmitting 129 and receiving TCP segments with the RST flag. Since a Multipath TCP 130 connection is composed of several TCP subflows, the transmission or 131 reception of a TCP RST on a subflow only terminates the corresponding 132 subflow. This does not necessarily terminate the Multipath TCP 133 connection. 135 This document is organized as follows. We discuss in section 136 Section 2 the reasons why a Multipath TCP host could decide to 137 transmit a RST segment. In section Section 3, we propose a new 138 Multipath TCP option that can be used inside RST segments to convey 139 additional information about the reason for this RST segment and 140 explain how a Multipath TCP host should react to such segments. 142 1.1. Notational Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2. Generation of RST segments 150 This section documents the various reasons why a Multipath TCP host 151 could generate a segment with the RST flag. 153 2.1. Lack of ressources 155 A Multipath TCP implementation cannot usually support an unlimited 156 number of TCP subflows associated to a single Multipath TCP 157 connection. A Multipath TCP implementation may face a lack of 158 ressources when : 160 o It receives a SYN segment and accepting this subflow would exhaust 161 the subflow table of the host. 163 o It experiences memory pressure and needs to recover additional 164 ressources. Under these circumstances, it could decide to 165 terminate some subflows for existing Multipath TCP connections. 167 2.2. Administratively prohibited 169 A Multipath TCP implementation can be configured with policies that 170 determine which subflows can be associated to a given Multipath TCP 171 connection. These policies could be specified on a per application 172 basis, a per host basis or via other means that are outside the scope 173 of this document. Based on this configuration, a Multipath TCP host 174 could generate a RST segment to refuse the establishment of a subflow 175 when : 177 o It receives a SYN segment from a source address that conflicts 178 with its policies. For example, an enterprise server could be 179 configured to only accept subflows that originate from the 180 enterprise subnet and not from the global Internet. 182 o It receives a SYN segment with a destination address that 183 conflicts with its policies. For example, a server may be 184 configured to only expose some of its addresses to a subset of its 185 clients. 187 o It receives a SYN segment destined to a destination port that 188 conflicts with its policies. For example, a web server may be 189 configured to only accept subflows targeted to port 80 even if the 190 Multipath TCP specification allows to group together subflows on 191 different destination ports. 193 Both ICMPv4 and ICMPv6 contain error codes that can be used to 194 indicate similar error conditions. However, ICMP messages are more 195 likely to be dropped by network equipment than TCP segments. 196 Multipath TCP's reaction to these ICMP messages and the TCP RST 197 segments should be similar. 199 2.3. Too many already acknowledged data 201 Multipath TCP allows data that was transmitted over one subflow to be 202 retransmitted over another subflow. This situation can happen during 203 a handover when a mobile host moves from one access network to 204 another. In this case, the same data can be transmitted twice over 205 different subflows. This is mandated by Multipath TCP to ensure that 206 any middlebox on the path of the first subflow will see in-sequence 207 segments. However, retransmitting already acknowledged data over a 208 subflow is not the best utilisation of the network ressources as 209 reported in [INFOCOM14]. It should be possible for a Multipath TCP 210 host that has too many data that has already been acknowledged over 211 one subflow but still needs to be retransmitted over another subflow 212 to preserve the subflow ordering by terminating the subflow with too 213 many outstanding but already acknowledged data. Measurements or 214 simulations are required to evaluate the best threshold to be used by 215 a Multipath TCP implementation to decide when to terminate such a 216 subflow. In this document, we propose to terminate a subflow once 217 there are more than one initial congestion window's worth of data 218 that are outstanding on this subflow but have already been 219 acknowledged over another subflow or there is no other data on this 220 subflow. 222 The situation described above is obviously transient. The 223 termination of such a subflow does not indicate that the path should 224 not be used anymore. Instead, the reception of a RST segment 225 indicating such a cause should trigger the reestablishment of a 226 subflow over this path. The host that sends such a RST segment could 227 also send a SYN segment at the same time. However, it should be 228 noted that there are situations such as a server sending the RST 229 segment to a client connected behind a NAT where only the host that 230 receives the RST segment is able to reestablish the subflow. 232 2.4. Unacceptable performance 234 A Multipath TCP host can send data over several subflows. Some of 235 these subflows may perform well while the performance of others could 236 be affected by various performance problems : 238 o Excessive delay compared to the other subflows. If the receive 239 window used by Multipath TCP is too small, sending data over a 240 long delay subflow would reduce the overall performance of the 241 Multipath TCP connection. 243 o Excessive losses. The Multipath TCP congestion control scheme 244 tries to move traffic away from congested paths. If one of the 245 subflows is more heavily congested than the others, this can 246 severely impact the performance of the Multipath TCP connection. 248 o Excessive reordering. Excessive reordering at the subflow level 249 may lower performance by making TCP's retransmission techniques 250 less reactive. This error condition is typically transient. 252 A Multipath TCP host that detects that the performance of a Multipath 253 TCP connection is severely affected by one of the underlying 254 subflows, could decide to terminate the offending subflow. Depending 255 on the number of remaining active subflows, it may be needed to 256 reestablish another subflow to replace the terminated one. 258 2.5. Lifetime expired 260 A Multipath TCP connection is composed of several subflows. However, 261 maintaining a large number of subflows can be costly from an 262 implementation viewpoint. A Multipath TCP host should monitor the 263 usage of the underlying subflows and could terminate one subflow when 264 : 266 o No reply has been received to keepalive probes. The keepalive 267 probes [RFC1122] can be used over each subflow to verify that 268 their paths and the remote host are still active. If no answer is 269 received to these probes, the corresponding subflow should be 270 terminated. The Multipath TCP connection could be terminated once 271 the last subflow is terminated. Note that sending a regular RST 272 over each subflow will only terminate the subflow but not the 273 Multipath TCP connection [RFC6824]. 275 2.6. Removed address 277 When a host receives a REMOVE_ADDR option, it should send a TCP 278 keepalive over each of the subflows using the removed address. If a 279 response to the keepalive is received, the subflow should not be 280 terminated. Otherwise, the lack of response to the keepalives will 281 trigger a termination of the subflow as explained in section 282 Section 2.5. 284 When a host sends a REMOVE_ADDR option, it SHOULD send a RST segment 285 over each of the subflows that were using the removed address. 287 2.7. Middlebox interference has been detected 289 As explained in [RFC6824], Multipath TCP includes several mechanisms 290 to detect and possibly cope with middlebox interference. There are 291 unfortunately cases where Multipath TCP needs to terminate a subflow 292 once it has detected middlebox interference. The following cases are 293 listed in [RFC6824] : 295 o As explained on page 42 of [RFC6824], a host MUST close a subflow 296 with a RST if the first ACK that it receives over this subflow does 297 not contain the DSS option. 299 o As explained on page 43 of [RFC6824] a host MUST close a subflow by 300 sending a RST segment with the MP_FAIL option if it receives a 301 segment with an invalid DSS checksum. The MP_FAIL option includes 302 the data sequence number of the first byte of the payload of the 303 affected segment. 305 2.8. Multipath TCP specific errors 307 [RFC6824] lists several error conditions that are specific to 308 Multipath TCP and may lead to the termination of a subflow by 309 transmitting a RST segment. These error conditions are : 311 o A SYN segment with the MP_JOIN option was received with an invalid 312 HMAC or an unknown token. In this case, the host may reply with a 313 RST or silently ignore the error ([RFC6824] pages 22, 23 and 45). 315 o A TCP segment is received without a DSS checksum on a Multipath 316 TCP connection where the usage of the checksum has been negotiated 317 ([RFC6824] page 24). 319 o No DSS mapping has been received within a window of data 320 ([RFC6824] page 27). 322 2.9. Fast Close 324 The MP_FASTCLOSE option is defined in [RFC6824] allows to quickly 325 terminate a Multipath TCP connection. This operation is described in 326 section 3.5 of [RFC6824]. 328 2.10. Unspecified TCP error 330 A TCP implementation may send a RST segment for reasons that are 331 unrelated to Multipath TCP. 333 3. The MPTCP RST option 335 The Multipath TCP specification [RFC6824] defines several Multipath 336 TCP options. Each option is encoded by using the Type-Length-Value 337 format shown in the figure below. 339 1 2 3 340 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 341 +---------------+---------------+-------+-----------------------+ 342 | Kind | Length |Subtype| | 343 +---------------+---------------+-------+ | 344 | Subtype-specific data | 345 | (variable length) | 346 +---------------------------------------------------------------+ 348 Figure 1: The Multipath TCP option format 350 The proposed format for the Multipath TCP RST option is defined in 351 the figure below. 353 1 2 3 354 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 355 +---------------+---------------+-------+-----------------------+ 356 | Kind | Length |Subtype|U V W T| Reason | 357 +---------------+---------------+-------+-----------------------+ 359 Figure 2: The proposed Multipath TCP RST option format 361 The Multipath TCP RST option contains a reason code that allows the 362 sender of the option to provide more information about the reason for 363 the termination of the subflow. [RFC0793] allowed the utilisation of 364 the segment payload to provide additional information about the 365 reason for the termination of a TCP connection and some middleboxes 366 have used this facility [NDSS09]. However, without a precise format 367 for the reason code, the only thing that TCP implementations could do 368 with this payload was to log the received data. With a specific 369 reason field, it becomes possible for a Multipath TCP implementation 370 to intelligently and correctly react to the termination of a subflow. 372 The "T" flag is used by the sender to indicate whether the error 373 condition that is reported is Transient (T bit set to 1) or Permanent 374 (T bit set to 0). If the error condition is considered to be 375 Transient by the sender of the RST segment, the recipient of this 376 segment MAY try to reestablish a subflow over the failed path. If 377 the error condition is considered to be permanent, the receiver of 378 the RST segment SHOULD NOT try to reestablish a subflow over this 379 path. The "U", "V" and "W" flags are not defined by this 380 specification. 382 The "Reason" code is an 8 bits field that indicates the reason for 383 the termination of the subflow. The following codes are defined in 384 this document : 386 o Lack of ressources (code TBD1). This code indicates that the 387 sending host does not have enough ressources to support the 388 terminated subflow. 390 o Administratively prohibited (code TBD2). This code indicates that 391 the requested subflow is prohibited by the policies of the sending 392 host. 394 o Too many already acknowledged data (code TBD3). This code 395 indicates that there are too many data that need to be transmitted 396 over the terminated subflow while having already been acknowledged 397 over one or more other subflows. 399 o Unacceptable performance (code TBD4). This code indicates that 400 the performance of this subflow was too low compared to the other 401 subflows of this Multipath TCP connection. 403 o Lifetime expired (code TBD5). This code indicates that the 404 lifetime of the subflow has expired. 406 o Removed address (code TBD6). This code indicates that the address 407 associated to this subflow has been removed by the sender. 409 o Middlebox interference (code TBD7). Middlebox interference has 410 been detected over this subflow. 412 o Multipath TCP specific error (code TBD8). An error has been 413 detected in the processing of Multipath TCP options. 415 o Fast Close (code TBD9). This RST segment has been sent in 416 response to a segment with the MP_FASTCLOSE option. 418 o Unspecified TCP error (code TBD10). An unspecified TCP error has 419 been detected on the affected subflow. 421 1. IANA Considerations 423 This document request the allocation of a new MPTCP option sub-type 424 from IANA. Furthermore, it defines a set of error conditions that 425 can be encoded inside the MPTCP RST option. This list of error 426 conditions should be maintained by IANA. 428 +-------------+---------------------------------+ 429 | Codepoint # | Reason | 430 +-------------+---------------------------------+ 431 | TBD1 | Lack of ressources | 432 | | | 433 | TBD2 | Administratively prohibited | 434 | | | 435 | TBD3 | Too many unacknowledged data | 436 | | | 437 | TBD4 | Unacceptable performance | 438 | | | 439 | TBD5 | Lifetime expired | 440 | | | 441 | TBD6 | Removed address | 442 | | | 443 | TBD7 | Middlebox interference detected | 444 | | | 445 | TBD8 | Multipath TCP specific error | 446 | | | 447 | TBD9 | Response to Fast Close | 448 | | | 449 | TBD10 | Unspecified TCP error | 450 +-------------+---------------------------------+ 452 4. Security Considerations 454 Single TCP is vulnerable to various forms of attacks that use RST 455 segments. An off-path attacker could send spoofed RST segments to 456 terminate existing TCP connections. Several techniques have been 457 proposed to deal with such attacks [RFC6528] [RFC5961]. These 458 techniques can also be used with Multipath TCP. The utilization of 459 the proposed MPTCP RST option does not change anything to the 460 applicability of these attack mitigation techniques. Since Multipath 461 TCP supports break before make, it is important to note that a 462 successful RST attack does not result in a release of the Multipath 463 TCP connection. A host can decide to initiate a new subflow, over 464 the same or another path, upon reception of a RST segment. 466 An on-path middlebox may generate RST segments to terminate some 467 unwanted TCP connections [NDSS09] [RFC3360]. The attack mitigation 468 techniques proposed in [RFC6528] and [RFC5961] are not suitable to 469 defend against on-path attackers like middleboxes. As noted above, a 470 host that receive a valid RST segment could still react by 471 establishing another subflow, possibly over another path. The 472 presence of the proposed RST option in the RST segment does not 473 change these security considerations. 475 5. Conclusion 477 This document has analyzed the various reasons that may cause a 478 Multipath TCP implementation to generate a RST segment. Since a 479 Multipath TCP connection can combine several TCP subflows, the 480 termination of one subflow does not necessarily lead to the 481 termination of the entire Multipath TCP connection. We propose the 482 Multipath TCP RST option to convey additional information about the 483 reason that motivated the transmission of the RST segment. 485 6. Acknowledgements 487 This work was partially supported by the FP7 Trilogy2 project. 489 7. References 491 7.1. Normative References 493 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 494 793, September 1981. 496 [RFC1122] Braden, R., "Requirements for Internet Hosts - 497 Communication Layers", STD 3, RFC 1122, October 1989. 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 503 BCP 60, RFC 3360, August 2002. 505 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 506 Robustness to Blind In-Window Attacks", RFC 5961, August 507 2010. 509 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 510 Number Attacks", RFC 6528, February 2012. 512 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 513 "TCP Extensions for Multipath Operation with Multiple 514 Addresses", RFC 6824, January 2013. 516 7.2. Informative References 518 [IMC11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 519 Handley, M., and H. Tokuda, "Is it still possible to 520 extend TCP ?", Proceedings of the 2011 ACM SIGCOMM 521 conference on Internet measurement conference (IMC '11) , 522 2011, . 524 [INFOCOM14] 525 Lim, Y., Chen, Y., Nahum, E., Towsley, D., and K. Lee, 526 "Cross-Layer Path Management in Multi-path Transport 527 Protocol for Mobile Devices", IEEE INFOCOM'14 , 2014. 529 [NDSS09] Weaver, N., Sommer, R., and V. Paxson, "Detecting Forged 530 TCP Reset Packets", NDSS2009 , 2009. 532 Authors' Addresses 534 Olivier Bonaventure 535 UCLouvain 537 Email: Olivier.Bonaventure@uclouvain.be 539 Christoph Paasch 540 UCLouvain 542 Email: Christoph.Paasch@uclouvain.be 544 Gregory Detal 545 UCLouvain 547 Email: Gregory.Detal@uclouvain.be