--- 1/draft-ietf-mptcp-rfc6824bis-09.txt 2018-03-05 00:13:09.655596183 -0800 +++ 2/draft-ietf-mptcp-rfc6824bis-10.txt 2018-03-05 00:13:09.839600525 -0800 @@ -1,25 +1,25 @@ Internet Engineering Task Force A. Ford Internet-Draft Pexip Obsoletes: 6824 (if approved) C. Raiciu Intended status: Standards Track U. Politechnica of Bucharest -Expires: January 29, 2018 M. Handley +Expires: September 5, 2018 M. Handley U. College London O. Bonaventure U. catholique de Louvain C. Paasch Apple, Inc. - July 28, 2017 + March 4, 2018 TCP Extensions for Multipath Operation with Multiple Addresses - draft-ietf-mptcp-rfc6824bis-09 + draft-ietf-mptcp-rfc6824bis-10 Abstract TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. @@ -35,108 +35,112 @@ modifications primarily driven by deployment experience. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 29, 2018. + This Internet-Draft will expire on September 5, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Design Assumptions . . . . . . . . . . . . . . . . . . . 4 1.2. Multipath TCP in the Networking Stack . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 6 + 1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 8 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 8 - 2.1. Initiating an MPTCP Connection . . . . . . . . . . . . . 8 + 2.1. Initiating an MPTCP Connection . . . . . . . . . . . . . 9 2.2. Associating a New Subflow with an Existing MPTCP Connection . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.3. Informing the Other Host about Another Potential Address 9 - 2.4. Data Transfer Using MPTCP . . . . . . . . . . . . . . . . 10 + 2.3. Informing the Other Host about Another Potential Address 10 + 2.4. Data Transfer Using MPTCP . . . . . . . . . . . . . . . . 11 2.5. Requesting a Change in a Path's Priority . . . . . . . . 11 - 2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 11 + 2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 12 2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 12 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 13 + 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 14 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 20 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 25 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 27 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 30 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 31 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 32 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 33 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 34 3.3.7. Congestion Control Considerations . . . . . . . . . . 35 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 36 3.4. Address Knowledge Exchange (Path Management) . . . . . . 37 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 38 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 42 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 43 3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 44 3.7. MPTCP Experimental Option . . . . . . . . . . . . . . . . 46 3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 47 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 51 - 3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 51 + 3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 52 3.10.1. Port Usage . . . . . . . . . . . . . . . . . . . . . 52 3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . 52 3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . 53 - 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 54 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 55 - 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 58 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 61 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 - 8.1. MPTCP Option Subtypes . . . . . . . . . . . . . . . . . . 62 - 8.2. MPTCP Handshake Algorithms . . . . . . . . . . . . . . . 63 - 8.3. MP_TCPRST Reason Codes . . . . . . . . . . . . . . . . . 63 - 8.4. Experimental option registry . . . . . . . . . . . . . . 64 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 64 - 9.2. Informative References . . . . . . . . . . . . . . . . . 65 - Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . 68 - Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 69 - B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 70 - B.1.1. Authentication and Metadata . . . . . . . . . . . . . 70 - B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 70 - B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 70 - B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . 71 - B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . 71 - B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . 71 - Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 71 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 + 3.11. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 54 + 3.11.1. TFO cookie request with MPTCP . . . . . . . . . . . 54 + 3.11.2. Data sequence mapping under TFO . . . . . . . . . . 55 + 3.11.3. Connection establishment examples . . . . . . . . . 56 + 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 58 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 59 + 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 62 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 + 8.1. MPTCP Option Subtypes . . . . . . . . . . . . . . . . . . 66 + 8.2. MPTCP Handshake Algorithms . . . . . . . . . . . . . . . 67 + 8.3. MP_TCPRST Reason Codes . . . . . . . . . . . . . . . . . 67 + 8.4. Experimental option registry . . . . . . . . . . . . . . 68 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 68 + 9.2. Informative References . . . . . . . . . . . . . . . . . 69 + Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . 72 + Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 73 + B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 74 + B.1.1. Authentication and Metadata . . . . . . . . . . . . . 74 + B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 74 + B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 74 + B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . 75 + B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . 75 + B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . 75 + Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 75 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 1. Introduction Multipath TCP (MPTCP) is a set of extensions to regular TCP [RFC0793] to provide a Multipath TCP [RFC6182] service, which enables a transport connection to operate across multiple paths simultaneously. This document presents the protocol changes required to add multipath capability to TCP; specifically, those for signaling and setting up multiple paths ("subflows"), managing these subflows, reassembly of data, and termination of sessions. This is not the only information @@ -660,21 +665,21 @@ o ACK (with first data) (A->B): A's Key followed by B's Key followed by Data-Level Length, and optional Checksum (Length = 22 or 24). The contents of the option is determined by the SYN and ACK flags of the packet, along with the option's length field. For the diagram shown in Figure 4, "sender" and "receiver" refer to the sender or receiver of the TCP packet (which can be either host). The initial SYN, containing just the MP_CAPABLE header, is used to - define the version of MPTCP beign requested, as well as exchanging + define the version of MPTCP being requested, as well as exchanging flags to negotiate connection features, described later. This option is used to declare the 64-bit keys that the end hosts have generated for this MPTCP connection. This key is used to authenticate the addition of future subflows to this connection. This is the only time the key will be sent in clear on the wire (unless "fast close", Section 3.5, is used); all future subflows will identify the connection using a 32-bit "token". This token is a cryptographic hash of this key. The algorithm for this process is dependent on the authentication algorithm selected; the method of @@ -1971,24 +1976,24 @@ +---------------+---------------+-------+-------+---------------+ | Kind | Length = 3+n |Subtype|(resvd)| Address ID | ... +---------------+---------------+-------+-------+---------------+ (followed by n-1 Address IDs, if required) Figure 13: Remove Address (REMOVE_ADDR) Option 3.5. Fast Close Regular TCP has the means of sending a reset (RST) signal to abruptly - close a connection. With MPTCP, the RST only has the scope of the - subflow and will only close the concerned subflow but not affect the - remaining subflows. MPTCP's connection will stay alive at the data - level, in order to permit break-before-make handover between + close a connection. With MPTCP, a regular RST only has the scope of + the subflow and will only close the concerned subflow but not affect + the remaining subflows. MPTCP's connection will stay alive at the + data level, in order to permit break-before-make handover between subflows. It is therefore necessary to provide an MPTCP-level "reset" to allow the abrupt closure of the whole MPTCP connection, and this is the MP_FASTCLOSE option. MP_FASTCLOSE is used to indicate to the peer that the connection will be abruptly closed and no data will be accepted anymore. The reasons for triggering an MP_FASTCLOSE are implementation specific. Regular TCP does not allow sending a RST while the connection is in a synchronized state [RFC0793]. Nevertheless, implementations allow the sending of a RST in this state, if, for example, the operating @@ -2000,50 +2005,62 @@ +---------------+---------------+-------+-----------------------+ | Kind | Length |Subtype| (reserved) | +---------------+---------------+-------+-----------------------+ | Option Receiver's Key | | (64 bits) | | | +---------------------------------------------------------------+ Figure 14: Fast Close (MP_FASTCLOSE) Option - If Host A wants to force the closure of an MPTCP connection, the - MPTCP Fast Close procedure is as follows: + If Host A wants to force the closure of an MPTCP connection, it has + two different options: - o Host A sends an ACK containing the MP_FASTCLOSE option on one - subflow, containing the key of Host B as declared in the initial - connection handshake. On all the other subflows, Host A sends a - regular TCP RST to close these subflows, and tears them down. - Host A now enters FASTCLOSE_WAIT state. + o Option A (ACK) : Host A sends an ACK containing the MP_FASTCLOSE + option on one subflow, containing the key of Host B as declared in + the initial connection handshake. On all the other subflows, Host + A sends a regular TCP RST to close these subflows, and tears them + down. Host A now enters FASTCLOSE_WAIT state. - o Upon receipt of an MP_FASTCLOSE, containing the valid key, Host B - answers on the same subflow with a TCP RST and tears down all - subflows. Host B can now close the whole MPTCP connection (it - transitions directly to CLOSED state). + o Option R (RST) : Host A sends a RST containing the MP_FASTCLOSE + option on all subflows, containing the key of Host B as declared + in the initial connection handshake. Host A can tear the subflows + and the connection down immediately. + + If a host receives a packet with a valid MP_FASTCLOSE option, it + shall process it as follows : + + o Upon receipt of an ACK with MP_FASTCLOSE, containing the valid + key, Host B answers on the same subflow with a TCP RST and tears + down all subflows. Host B can now close the whole MPTCP + connection (it transitions directly to CLOSED state). o As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole connection (transition from FASTCLOSE_WAIT to CLOSED states). If Host A receives an MP_FASTCLOSE instead of a TCP RST, both hosts attempted fast closure simultaneously. Host A should reply with a TCP RST and tear down the connection. o If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow - where the MPTCP_RST has been sent), it SHOULD retransmit the + where the MP_FASTCLOSE has been sent), it SHOULD retransmit the MP_FASTCLOSE. The number of retransmissions SHOULD be limited to avoid this connection from being retained for a long time, but this limit is implementation specific. A RECOMMENDED number is 3. If no TCP RST is received in response, Host A SHOULD send a TCP - RST itself when it releases state in order to clear any remaining - state at middleboxes. + RST with the MP_FASTCLOSE option itself when it releases state in + order to clear any remaining state at middleboxes. + + o Upon receipt of a RST with MP_FASTCLOSE, containing the valid key, + Host B tears down all subflows. Host B can now close the whole + MPTCP connection (it transitions directly to CLOSED state). 3.6. Subflow Reset As discussed in Section 3.5 above, the MP_FASTCLOSE option provides a connection-level reset roughly analagous to a TCP RST. Regular TCP RST options remain used to at the subflow-level to indicate the receiving host has no knowledge of the MPTCP subflow or TCP connection to which the packet belongs. However, in MPTCP, there may be many reasons for rejecting the @@ -2497,20 +2514,190 @@ the ADD_ADDR option is informational only, and does not guarantee the other host will attempt a connection. In addition, an implementation may learn, over a number of connections, that certain interfaces or destination addresses consistently fail and may default to not trying to use MPTCP for these. Behavior could also be learned for particularly badly performing subflows or subflows that regularly fail during use, in order to temporarily choose not to use these paths. +3.11. TCP Fast Open + + TCP Fast Open, described in [RFC7413], has been introduced with the + objective of gaining one RTT before transmitting data. This is + considered a valuable gain as very short connections are very common, + especially for HTTP request/response schemes. It achieves this by + sending the SYN-segment together with data and allowing the server to + reply immediately with data after the SYN/ACK. [RFC7413] secures + this mechanism, by using a new TCP option that includes a cookie + which is negotiated in a preceding connection. + + When using TCP Fast Open in conjunction with MPTCP, there are two key + points to take into account, detailed hereafter. + +3.11.1. TFO cookie request with MPTCP + + When a TFO client first connects to a server, it cannot immediately + include data in the SYN for security reasons [RFC7413]. Instead, it + requests a cookie that will be used in subsequent connections. This + is done with the TCP cookie request/response options, of resp. 2 + bytes and 6-18 bytes (depending on the chosen cookie length). + + TFO and MPTCP can be combined provided that the total length of their + options does not exceed the maximum 40 bytes possible in TCP: + + o In the SYN: MPTCP uses a 4-bytes long MP_CAPABLE option. The + MPTCP and TFO options sum up to 6 bytes. With typical TCP-options + using up to 19 bytes in the SYN (24 bytes if options are padded at + a word boundary), there is enough space to combine the MP_CAPABLE + with the TFO Cookie Request. + + o In the SYN+ACK: MPTCP uses a 12-bytes long MP_CAPABLE option, but + now TFO can be as long as 18 bytes. Since the maximum option + length may be exceeded, it is up to the server to solve this by + using a shorter cookie. As an example, if we consider that 19 + bytes are used for classical TCP options, the maximum possible + cookie length would be of 7 bytes. Note that the same limitation + applies to subsequent connections, for the SYN packet (because the + client then echoes back the cookie to the server). Finally, if + the security impact of reducing the cookie size is not deemed + acceptable, the server can reduce the amount of other TCP-options + by omitting the TCP timestamps (as outlined in Appendix A). + +3.11.2. Data sequence mapping under TFO + + MPTCP uses, in the TCP establishment phase, a key exchange that is + used to generate the Initial Data Sequence Numbers (IDSNs). In + particular, the SYN with MP_CAPABLE occupies the first octet of the + data sequence space. With TFO, one way to handle the data sent + together with the SYN would be to consider an implicit DSS mapping + that covers that SYN segment (since there is not enough space in the + SYN to include a DSS option). The problem with that approach is that + if a middlebox modifies the TFO data, this will not be noticed by + MPTCP because of the absence of a DSS-checksum. For example, a TCP + (but not MPTCP)-aware middlebox could insert bytes at the beginning + of the stream and adapt the TCP checksum and sequence numbers + accordingly. With an implicit mapping, this would give to client and + server a different view on the DSS-mapping, with no way to detect + this inconsistency as the DSS checksum is not present. + + To solve this, the TFO data should not be considered part of the Data + Sequence Number space: the SYN with MP_CAPABLE still occupies the + first octet of data sequence space, but then the first non-TFO data + byte occupies the second octet. This guarantees that, if the use of + DSS-checksum is negotiated, all data in the data sequence number + space is checksummed. We also note that this does not entail a loss + of functionality, because TFO-data is always sent when only one path + is active. + +3.11.3. Connection establishment examples + + The following shows a few examples of possible TFO+MPTCP + establishment scenarios. + + Before a client can send data together with the SYN, it must request + a cookie to the server, as shown in Figure Figure 18. This is done + by simply combining the TFO and MPTCP options. + + client server + | | + | S 0(0) , | + | -----------------------------------------------------------> | + | | + | S. 0(0) ack 1 , | + | <----------------------------------------------------------- | + | | + | . 0(0) ack 1 | + | -----------------------------------------------------------> | + | | + + Figure 18: Cookie request + + Once this is done, the received cookie can be used for TFO, as shown + in Figure Figure 19. In this example, the client first sends 20 + bytes in the SYN. The server immediately replies with 100 bytes + following the SYN-ACK upon which the client replies with 20 more + bytes. Note that the last segment in the figure has a TCP sequence + number of 21, while the DSS subflow sequence number is 1 (because the + TFO data is not part of the data sequence number space, as explained + in Section Section 3.11.2. + + client server + | | + | S 0(20) , | + | -----------------------------------------------------------> | + | | + | S. 0(0) ack 21 | + | <----------------------------------------------------------- | + | | + | . 1(100) ack 21 | + | <----------------------------------------------------------- | + | | + | . 21(0) ack 1 | + | -----------------------------------------------------------> | + | | + | . 21(20) ack 101 | + | -----------------------------------------------------------> | + | | + + Figure 19: The server supports TFO + + In Figure Figure 20, the server does not support TFO. The client + detects that no state is created in the server (as no data is acked), + and now sends the MP_CAPABLE in the third ack, in order for the + server to build its MPTCP context at then end of the establishment. + Now, the tfo data, retransmitted, becomes part of the data sequence + mapping because it is effectively sent (in fact re-sent) after the + establishment. + + client server + | | + | S 0(20) , | + | -----------------------------------------------------------> | + | | + | S. 0(0) ack 1 | + | <----------------------------------------------------------- | + | | + | . 1(0) ack 1 | + | -----------------------------------------------------------> | + | | + | . 1(20) ack 1 | + | -----------------------------------------------------------> | + | | + | . 0(0) ack 21 | + | <----------------------------------------------------------- | + | | + + Figure 20: The server does not support TFO + + It is also possible that the server acknowledges only part of the TFO + data, as illustrated in Figure Figure 21. The client will simply + retransmit the missing data together with a DSS-mapping. + + client server + | | + | S 0(1000) , | + | -----------------------------------------------------------> | + | | + | S. 0(0) ack 501 | + | <----------------------------------------------------------- | + | | + | . 501(0) ack 1 | + | -----------------------------------------------------------> | + | | + | . 501(500) ack 1 | + | -----------------------------------------------------------> | + | | + + Figure 21: Partial data acknowledgement + 4. Semantic Issues In order to support multipath operation, the semantics of some TCP components have changed. To aid clarity, this section collects these semantic changes as a reference. Sequence number: The (in-header) TCP sequence number is specific to the subflow. To allow the receiver to reorder application data, an additional data-level sequence space is used. In this data- level sequence space, the initial SYN and the final DATA_FIN @@ -2702,21 +2888,21 @@ presence of the SYN flag. MPTCP SYN packets on the first subflow of a connection contain the MP_CAPABLE option (Section 3.1). If this is dropped, MPTCP SHOULD fall back to regular TCP. If packets with the MP_JOIN option (Section 3.2) are dropped, the paths will simply not be used. If a middlebox strips options but otherwise passes the packets unchanged, MPTCP will behave safely. If an MP_CAPABLE option is dropped on either the outgoing or the return path, the initiating - host can fall back to regular TCP, as illustrated in Figure 18 and + host can fall back to regular TCP, as illustrated in Figure 22 and discussed in Section 3.1. Subflow SYNs contain the MP_JOIN option. If this option is stripped on the outgoing path, the SYN will appear to be a regular SYN to Host B. Depending on whether there is a listening socket on the target port, Host B will reply either with SYN/ACK or RST (subflow connection fails). When Host A receives the SYN/ACK it sends a RST because the SYN/ACK does not contain the MP_JOIN option and its token. Either way, the subflow setup fails, but otherwise does not affect the MPTCP connection as a whole. @@ -2732,21 +2918,21 @@ Host A Host B | SYN(MP_CAPABLE) | |------------------------------------>| | Middlebox M | | | | | SYN/ACK |SYN/ACK(MP_CAPABLE)| |<----------------|-------------------| b) MP_CAPABLE option stripped on return path - Figure 18: Connection Setup with Middleboxes that Strip Options from + Figure 22: Connection Setup with Middleboxes that Strip Options from Packets We now examine data flow with MPTCP, assuming the flow is correctly set up, which implies the options in the SYN packets were allowed through by the relevant middleboxes. If options are allowed through and there is no resegmentation or coalescing to TCP segments, Multipath TCP flows can proceed without problems. The case when options get stripped on data packets has been discussed in the Fallback section. If a fraction of options are stripped, @@ -2987,31 +3173,31 @@ indicating the desired codepoint and providing a point of contact. A short description or acronym for the use is desired but should not be required. 9. References 9.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, - . + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, - . + . [SHS] National Institute of Science and Technology, "Secure Hash Standard", Federal Information Processing Standard (FIPS) 180-4, August 2015, . 9.2. Informative References [howhard] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., @@ -3025,119 +3211,123 @@ [norm] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics", Usenix Security 2001, 2001, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, - . + . [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, DOI 10.17487/RFC1323, May - 1992, . + 1992, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, - . + . [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, - . + . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, - . + . [RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, - . + . [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, - . + . [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, - . + . [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, - . + . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, - . + . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, - . + . [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, - . + . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, - . + . [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, - . + . [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, - . + . [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, DOI 10.17487/RFC6181, March 2011, - . + . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, - . + . [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, - . + . [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February - 2012, . + 2012, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, - . + . [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, - March 2013, . + March 2013, . [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, - . + . + + [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP + Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, + . [TCPLO] Ramaiah, A., "TCP option space extension", Work in Progress, March 2012. Appendix A. Notes on Use of TCP Options The TCP option space is limited due to the length of the Data Offset field in the TCP header (4 bits), which defines the TCP header length in 32-bit words. With the standard TCP header being 20 bytes, this leaves a maximum of 40 bytes for options, and many of these may @@ -3310,21 +3500,21 @@ is expected on the subflow. This state variable is modified upon reception of in-order segments. The value of RCV.NXT is copied to the SEG.ACK field of the next segments transmitted on the subflow. RCV.WND (32 bits with RFC 1323, 16 bits otherwise): This is the subflow-level receive window that is updated with the window field from the segments received on this subflow. Appendix C. Finite State Machine - The diagram in Figure 19 shows the Finite State Machine for + The diagram in Figure 23 shows the Finite State Machine for connection-level closure. This illustrates how the DATA_FIN connection-level signal (indicated as the DFIN flag on a DATA_ACK) interacts with subflow-level FINs, and permits "break-before-make" handover between subflows. +---------+ | M_ESTAB | +---------+ M_CLOSE | | rcv DATA_FIN ------- | | ------- @@ -3343,21 +3533,21 @@ | rcv DATA_FIN -------------- | -------------- | | ------- CLOSE all subflows | CLOSE all subflows | | snd DATA_ACK[DFIN] V delete MPTCP PCB V \ +-----------+ +---------+ ------------------------>|M_TIME WAIT|----------------->| M_CLOSED| +-----------+ +---------+ All subflows in CLOSED ------------ delete MPTCP PCB - Figure 19: Finite State Machine for Connection Closure + Figure 23: Finite State Machine for Connection Closure Authors' Addresses Alan Ford Pexip EMail: alan.ford@gmail.com Costin Raiciu University Politehnica of Bucharest