• [RFC 6182] (MPTCP architecture), which explains the motivations behind Multipath TCP, contains a discussion of high-level design decisions on which this design is based, and provides an explanation of a functional separation through which an extensible MPTCP implementation can be developed.
• [RFC 6356] (congestion control), which presents a safe congestion control algorithm for coupling the behavior of the multiple paths in order to "do no harm" to other network users.
• [RFC 6897] (application considerations), which discusses what impact MPTCP will have on applications, what applications will want to do with MPTCP, and as a consequence of these factors, what API extensions an MPTCP implementation should present.

• It must be backward compatible with current, regular TCP, to increase its chances of deployment.
• It can be assumed that one or both hosts are multihomed and multiaddressed.

External Constraints:

The protocol must function through the vast majority of existing middleboxes such as NATs, firewalls, and proxies, and as such must resemble existing TCP as far as possible on the wire. Furthermore, the protocol must not assume that the segments it sends on the wire arrive unmodified at the destination:they may be split or coalesced; TCP options may be removed or duplicated.

Application Constraints:

The protocol must be usable with no change to existing applications that use the common TCP API (although it is reasonable that not all features would be available to such legacy applications). Furthermore, the protocol must provide the same service model as regular TCP to the application.

Fallback:

The protocol should be able to fall back to standard TCP with no interference from the user, to be able to communicate with legacy hosts.

Path:

A sequence of links between a sender and a receiver, defined in this context by a 4-tuple of source and destination addressport pairs.

Subflow:

A flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A subflow is started and terminated similarly to a regular TCP connection.

(MPTCP) Connection:

A set of one or more subflows, over which an application can communicate between two hosts. There is a one-to-one mapping between a connection and an application socket.

Data-level:

The payload data is nominally transferred over a connection, which in turn is transported over subflows. Thus, the term "data-level" is synonymous with "connection-level", in contrast to "subflow-level", which refers to properties of an individual subflow.

Token:

A locally unique identifier given to a multipath connection by a host. May also be referred to as a "Connection ID".

Host:

An end host operating an MPTCP implementation, and either initiating or accepting an MPTCP connection.

            Host A                               Host B
   ------------------------             ------------------------
   Address A1    Address A2             Address B1    Address B2
   ----------    ----------             ----------    ----------
       |             |                      |             |
       |     (initial connection setup)     |             |
       |----------------------------------->|             |
       |<-----------------------------------|             |
       |             |                      |             | 
       |            (additional subflow setup)            |
       |             |--------------------->|             |
       |             |<---------------------|             |
       |             |                      |             |
       |             |                      |             | 

• To a non-MPTCP-aware application, MPTCP will behave the same as normal TCP. Extended APIs could provide additional control to MPTCP-aware applications [RFC 6897]. An application begins by opening a TCP socket in the normal way. MPTCP signaling and operation are handled by the MPTCP implementation.
• An MPTCP connection begins similarly to a regular TCP connection. This is illustrated in Figure 2, where an MPTCP connection is established between addresses A1 and B1 on Hosts A and B, respectively.
• If extra paths are available, additional TCP sessions (termed MPTCP "subflows") are created on these paths and are combined with the existing session, which continues to appear as a single connection to the applications at both ends. The creation of the additional TCP session is illustrated between Address A2 on Host A and Address B1 on Host B.
• MPTCP identifies multiple paths by the presence of multiple addresses at hosts. Combinations of these multiple addresses equate to the additional paths. In the example, other potential paths that could be set up are A1<->B2 and A2<->B2. Although this additional session is shown as being initiated from A2, it could equally have been initiated from B1 or B2.
• The discovery and setup of additional subflows will be achieved through a path management method; this document describes a mechanism by which a host can initiate new subflows by using its own additional addresses or by signaling its available addresses to the other host.
• MPTCP adds connection-level sequence numbers to allow the reassembly of segments arriving on multiple subflows with differing network delays.
• Subflows are terminated as regular TCP connections, with a four-way FIN handshake. The MPTCP connection is terminated by a connection-level FIN.

• To cope with NATs on the path, addresses are referred to by Address IDs, in case the IP packet's source address gets changed by a NAT. Setting up a new TCP flow is not possible if the receiver of the SYN is behind a NAT; to allow subflows to be created when either end is behind a NAT, MPTCP uses the ADD_ADDR message.
• MPTCP falls back to ordinary TCP if MPTCP operation is not possible -- for example, if one host is not MPTCP capable or if a middlebox alters the payload. This is discussed in Section 3.7.
• To address the threats identified in [RFC 6181], the following steps are taken: keys are sent in the clear in the MP_CAPABLE messages; MP_JOIN messages are secured with HMAC-SHA256 ([RFC 2104] using the algorithm in [RFC 6234]) using those keys; and standard TCP validity checks are made on the other messages (ensuring that sequence numbers are in-window [RFC 5961]). Residual threats to MPTCP v0 were identified in [RFC 7430], and those affecting the protocol (i.e., modifications to ADD_ADDR) have been incorporated in this document. Further discussion of security can be found in Section 5.

                       1                   2                   3
   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
  +---------------+---------------+-------+-------+---------------+
  |     Kind      |    Length     |Subtype|Version|A|B|C|D|E|F|G|H|
  +---------------+---------------+-------+-------+---------------+
  |                   Option Sender's Key (64 bits)               |
  |                      (if option Length > 4)                   |
  |                                                               |
  +---------------------------------------------------------------+
  |                  Option Receiver's Key (64 bits)              |
  |                      (if option Length > 12)                  |
  |                                                               |
  +-------------------------------+-------------------------------+
  |  Data-Level Length (16 bits)  |  Checksum (16 bits, optional) |
  +-------------------------------+-------------------------------+ 

• SYN (A->B): only the first 4 octets (Length = 4).
• SYN/ACK (B->A): B's key for this connection (Length = 12).
• ACK (no data) (A->B): A's key followed by B's key (Length = 20).
• 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).

A:

The leftmost bit, labeled "A", SHOULD be set to 1 to indicate "Checksum required", unless the system administrator has decided that checksums are not required (for example, if the environment is controlled and no middleboxes exist that might adjust the payload).

B:

The second bit, labeled "B", is an extensibility flag. It MUST be set to 0 for current implementations. This flag will be used for an extensibility mechanism in a future specification, and the impact of this flag will be defined at a later date. It is expected, but not mandated, that this flag would be used as part of an alternative security mechanism that does not require a full version upgrade of the protocol but does require redefining some elements of the handshake. If receiving a message with the "B" flag set to 1 and this is not understood, then the MP_CAPABLE in this SYN MUST be silently ignored, which triggers a fallback to regular TCP; the sender is expected to retry with a format compatible with this legacy specification. Note that the length of the MP_CAPABLE option, and the meanings of bits "D" through "H", may be altered by setting B=1.

C:

The third bit, labeled "C", is set to 1 to indicate that the sender of this option will not accept additional MPTCP subflows to the source address and port, and therefore the receiver MUST NOT try to open any additional subflows toward this address and port. This improves efficiency in situations where the sender knows a restriction is in place -- for example, if the sender is behind a strict NAT or operating behind a legacy Layer 4 load balancer.

D through H:

The remaining bits, labeled "D" through "H", are used for crypto algorithm negotiation. In this specification, only the rightmost bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC-SHA256 (as defined in Section 3.2). An implementation that only supports this method MUST set bit "H" to 1 and bits "D" through "G" to 0.

                       1                   2                   3
   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
  +---------------+---------------+-------+----------------------+
  |     Kind      |    Length     |Subtype| (reserved) |F|m|M|a|A|
  +---------------+---------------+-------+----------------------+
  |           Data ACK (4 or 8 octets, depending on flags)       |
  +--------------------------------------------------------------+
  |   Data Sequence Number (4 or 8 octets, depending on flags)   |
  +--------------------------------------------------------------+
  |              Subflow Sequence Number (4 octets)              |
  +-------------------------------+------------------------------+
  |  Data-Level Length (2 octets) |      Checksum (2 octets)     |
  +-------------------------------+------------------------------+ 

• A = Data ACK present
• a = Data ACK is 8 octets (if not set, Data ACK is 4 octets)
• M = Data Sequence Number (DSN), Subflow Sequence Number (SSN), Data-Level Length, and Checksum (if negotiated) present
• m = Data Sequence Number is 8 octets (if not set, DSN is 4 octets)

• An MPTCP connection is initially set up between addressport A1 of Host A and addressport B1 of Host B. If Host A is multihomed and multiaddressed, it can start an additional subflow from its address A2 to B1, by sending a SYN with an MP_JOIN option from A2 to B1, using B's previously declared token for this connection. Alternatively, if B is multihomed, it can try to set up a new subflow from B2 to A1, using A's previously declared token. In either case, the SYN will be sent to the port already in use for the original subflow on the receiving host.
• Simultaneously (or after a timeout), an ADD_ADDR option (Section 3.4.1) is sent on an existing subflow, informing the receiver of the sender's alternative address(es). The recipient can use this information to open a new subflow to the sender's additional address(es). In our example, A will send the ADD_ADDR option informing B of addressport A2. The mix of using the SYN-based option and the ADD_ADDR option, including timeouts, is implementation specific and can be tailored to agree with local policy.
• If subflow A2-B1 is successfully set up, Host B can use the Address ID in the MP_JOIN option to correlate this source address with the ADD_ADDR option that will also arrive on an existing subflow; now B knows not to open A2-B1, ignoring the ADD_ADDR. Otherwise, if B has not received the A2-B1 MP_JOIN SYN but received the ADD_ADDR, it can try to initiate a new subflow from one or more of its addresses to address A2. This permits new sessions to be opened if one host is behind a NAT.

                       1                   2                   3
   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
  +---------------+---------------+-------+-----------------------+
  |     Kind      |    Length     |Subtype|      (reserved)       |
  +---------------+---------------+-------+-----------------------+
  |                      Option Receiver's Key                    |
  |                            (64 bits)                          |
  |                                                               |
  +---------------------------------------------------------------+ 

• 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.
• 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 down the subflows and the connection immediately.

• Upon receipt of an ACK with MP_FASTCLOSE by Host B, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows also through sending TCP RST signals. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state).
• 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 state to CLOSED state). 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.
• 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 MP_FASTCLOSE has been sent), it SHOULD retransmit the MP_FASTCLOSE. To keep this connection from being retained for a long time, the number of retransmissions SHOULD be limited; 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 with the MP_FASTCLOSE option itself when it releases state in order to clear any remaining state at middleboxes.

                       1                   2                   3
   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
  +---------------+---------------+-------+-----------------------+
  |     Kind      |    Length     |Subtype|U|V|W|T|    Reason     |
  +---------------+---------------+-------+-----------------------+ 

• Unspecified error (code 0x00). This is the default error; it implies that the subflow is no longer available. The presence of this option shows that the RST was generated by an MPTCP-aware device.
• MPTCP-specific error (code 0x01). An error has been detected in the processing of MPTCP options. This is the usual reason code to return in the cases where a RST is being sent to close a subflow because of an invalid response.
• Lack of resources (code 0x02). This code indicates that the sending host does not have enough resources to support the terminated subflow.
• Administratively prohibited (code 0x03). This code indicates that the requested subflow is prohibited by the policies of the sending host.
• Too much outstanding data (code 0x04). This code indicates that there is an excessive amount of data that needs to be transmitted over the terminated subflow while having already been acknowledged over one or more other subflows. This may occur if a path has been unavailable for a short period and it is more efficient to reset and start again than it is to retransmit the queued data.
• Unacceptable performance (code 0x05). This code indicates that the performance of this subflow was too low compared to the other subflows of this Multipath TCP connection.
• Middlebox interference (code 0x06). Middlebox interference has been detected over this subflow, making MPTCP signaling invalid. For example, this may be sent if the checksum does not validate.

• A sender MUST include a DSS option with Data Sequence Mapping in every segment until one of the sent segments has been acknowledged with a DSS option containing a Data ACK. Upon reception of the acknowledgment, the sender has the confirmation that the DSS option passes in both directions and may choose to send fewer DSS options than once per segment.
• If, however, an ACK is received for data (not just for the SYN) without a DSS option containing a Data ACK, the sender determines that the path is not MPTCP capable. In the case of this occurring on an additional subflow (i.e., one started with MP_JOIN), the host MUST close the subflow with a RST, which SHOULD contain an MP_TCPRST option (Section 3.6) with a "Middlebox interference" reason code.
• In the case of such an ACK being received on the first subflow (i.e., that started with MP_CAPABLE), before any additional subflows are added, the implementation MUST drop out of MPTCP mode and fall back to regular TCP. The sender will send one final Data Sequence Mapping, with the Data-Level Length value of 0 indicating an infinite mapping (to inform the other end in case the path drops options in one direction only), and then revert to sending data on the single subflow without any MPTCP options.
• If a subflow breaks during operation, e.g., if it is rerouted and MPTCP options are no longer permitted, then once this is detected (by the subflow-level receive buffer filling up, since there is no mapping available in order to DATA_ACK this data), the subflow SHOULD be treated as broken and closed with a RST, since no data can be delivered to the application layer and no fallback signal can be reliably sent. This RST SHOULD include the MP_TCPRST option (Section 3.6) with a "Middlebox interference" reason code.

                       1                   2                   3
   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
  +---------------+---------------+-------+----------------------+
  |     Kind      |   Length=12   |Subtype|      (reserved)      |
  +---------------+---------------+-------+----------------------+
  |                                                              |
  |                 Data Sequence Number (8 octets)              |
  |                                                              |
  +--------------------------------------------------------------+ 

• Unknown token in MP_JOIN (or HMAC failure in MP_JOIN ACK, or missing MP_JOIN in SYN/ACK response): send RST (analogous to TCP's behavior on an unknown port)
• DSN out of window (during normal operation): drop the data; do not send Data ACKs
• Remove request for unknown Address ID: silently ignore

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 occupy 1 octet of sequence space. This is done to ensure that these signals are acknowledged at the connection level. There is an explicit mapping of data sequence space to subflow sequence space, which is signaled through TCP options in data packets.

ACK:

The ACK field in the TCP header acknowledges only the subflow sequence number -- not the data-level sequence space. Implementations SHOULD NOT attempt to infer a data-level acknowledgment from the subflow ACKs. This separates subflow-level and connection-level processing at an end host.

Duplicate ACK:

A duplicate ACK that includes any MPTCP signaling (with the exception of the DSS option) MUST NOT be treated as a signal of congestion. To limit the chances of non-MPTCP-aware entities mistakenly interpreting duplicate ACKs as a signal of congestion, MPTCP SHOULD NOT send more than two duplicate ACKs containing (non-DSS) MPTCP signals in a row.

Receive Window:

The receive window in the TCP header indicates the amount of free buffer space for the whole data-level connection (as opposed to the amount of space for this subflow) that is available at the receiver. The semantics are the same as for regular TCP, but to maintain these semantics the receive window must be interpreted at the sender as relative to the sequence number given in the DATA_ACK rather than the subflow ACK in the TCP header. In this way, the original role of flow control is preserved. Note that some middleboxes may change the receive window, and so a host SHOULD use the maximum value of those recently seen on the constituent subflows for the connection-level receive window and also needs to maintain a subflow-level window for subflow-level processing.

FIN:

The FIN flag in the TCP header applies only to the subflow it is sent on -- not to the whole connection. For connection-level FIN semantics, the DATA_FIN option is used.

RST:

The RST flag in the TCP header applies only to the subflow it is sent on -- not to the whole connection. The MP_FASTCLOSE option provides the Fast Close functionality of a RST at the MPTCP connection level.

Address List:

Address list management (i.e., knowledge of the local and remote hosts' lists of available IP addresses) is handled on a per-connection basis (as opposed to per subflow, per host, or per pair of communicating hosts). This permits the application of per-connection local policy. Adding an address to one connection (either explicitly through an ADD_ADDR message or implicitly through an MP_JOIN) has no implications for other connections between the same pair of hosts.

5-tuple:

The 5-tuple (protocol, local address, local port, remote address, remote port) presented by kernel APIs to the application layer in a non-multipath-aware application is that of the first subflow, even if the subflow has since been closed and removed from the connection. This decision, and other related API issues, are discussed in more detail in [RFC 6897].

• Provide a mechanism to confirm that the parties in a subflow handshake are the same as the parties in the original connection setup.
• Provide verification that the peer can receive traffic at a new address before using it as part of a connection.
• Provide replay protection, i.e., ensure that a request to addremove a subflow is "fresh".

• defining a new MPTCP cryptographic algorithm, as negotiated in MP_CAPABLE. If an implementation was being deployed in a controlled environment where additional assumptions could be made, such as the ability for the servers to store state during the TCP handshake, then it may be possible to use a stronger cryptographic algorithm than would otherwise be possible.
• defining how to secure data transfer with MPTCP, while not changing the signaling part of the protocol.
• defining security that requires more option space, perhaps in conjunction with a "long options" proposal for extending the TCP option space (such as those surveyed in [TCPLO]), or perhaps building on the current approach with a second stage of security based on MPTCP options.
• revisiting the working group's decision to exclusively use TCP options for MPTCP signaling and instead looking at the possibility of using TCP payloads as well.

• available flags in MP_CAPABLE (Figure 4).
• available subtypes in the MPTCP option (Figure 3).
• the Version field in MP_CAPABLE (Figure 4).

             Host A                              Host B 
               |              Middlebox M            |
               |                   |                 |
               | SYN (MP_CAPABLE)  |        SYN      |
               |-------------------|---------------->|
               |                SYN/ACK              |
               |<------------------------------------|
           a) MP_CAPABLE option stripped on outgoing path
         
             Host A                                Host B 
               |           SYN (MP_CAPABLE)            |
               |-------------------------------------->|
               |             Middlebox M               |
               |                  |                    |
               |    SYN/ACK       |SYN/ACK (MP_CAPABLE)|
               |<-----------------|--------------------|
           b) MP_CAPABLE option stripped on return path 

• NATs (Network Address (and port) Translators) [RFC 3022] change the source address (and often the source port) of packets. This means that a host will not know its public-facing address for signaling in MPTCP. Therefore, MPTCP permits implicit address addition via the MP_JOIN option, and the handshake mechanism ensures that connection attempts to private addresses [RFC 1918], since they are authenticated, will only set up subflows to the correct hosts. Explicit address removal is undertaken by an Address ID to allow no knowledge of the source address.
• Performance Enhancing Proxies (PEPs) [RFC 3135] might proactively ACK data to increase performance. MPTCP, however, relies on accurate congestion control signals from the end host, and non-MPTCP-aware PEPs will not be able to provide such signals. MPTCP will, therefore, fall back to single-path TCP or close the problematic subflow (see Section 3.7).
• Traffic normalizers [norm] may not allow holes in sequence numbers, and they may cache packets and retransmit the same data. MPTCP looks like standard TCP on the wire and will not retransmit different data on the same subflow sequence number. In the event of a retransmission, the same data will be retransmitted on the original TCP subflow even if it is additionally retransmitted at the connection level on a different subflow.
• Firewalls [RFC 2979] might perform Initial Sequence Number (ISN) randomization on TCP connections. MPTCP uses relative sequence numbers in Data Sequence Mappings to cope with this. Like NATs, firewalls will not permit many incoming connections, so MPTCP supports address signaling (ADD_ADDR) so that a multiaddressed host can invite its peer behind the firewall/NAT to connect out to its additional interface.
• Intrusion Detection Systems / Intrusion Prevention Systems (IDSsIPSs) observe packet streams for patterns and content that could threaten a network. MPTCP may require the instrumentation of additional paths, and an MPTCP-aware IDS or IPS would need to read MPTCP tokens to correlate data from multiple subflows to maintain comparable visibility into all of the traffic between devices. Without such changes, an IDS would get an incomplete view of the traffic, increasing the risk of missing traffic of interest (false negatives) and increasing the chances of erroneously identifying a subflow as a risk due to only seeing partial data (false positives).
• Application-level middleboxes such as content-aware firewalls may alter the payload within a subflow -- for example, rewriting URIs in HTTP traffic. MPTCP will detect such changes using the checksum and close the affected subflow(s), if there are other subflows that can be used. If all subflows are affected, MPTCP will fall back to TCP, allowing such middleboxes to change the payload. MPTCP-aware middleboxes should be able to adjust the payload and MPTCP metadata in order not to break the connection.

• TCP options may be removed, or packets with unknown options dropped, by many classes of middleboxes. It is intended that the initial SYN exchange, with a TCP option, will be sufficient to identify the path's capabilities. If such a packet does not get through, MPTCP will end up falling back to regular TCP.
• Segmentation/coalescing (e.g., TCP segmentation offloading) might copy options between packets and might strip some options. MPTCP's Data Sequence Mapping includes the relative subflow sequence number instead of using the sequence number in the segment. In this way, the mapping is independent of the packets that carry it.
• The receive window may be shrunk by some middleboxes at the subflow level. MPTCP will use the maximum window at the data level but will also obey subflow-specific windows.

[RFC0793]

J. Postel, "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.

[RFC2104]

H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC5961]

A. Ramaiah, R. Stewart, and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010,
<https://www.rfc-editor.org/info/rfc5961>.

[RFC6234]

D. Eastlake 3rd, and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[deployments]

Universite Catholique de Louvain, O. Bonaventure, and S. Seo, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", IETF Journal 2016, November 2016,
<https://www.ietfjournal.org/multipath-tcp-deployments/>.

[howhard]

University College London, C. Raiciu, C. Paasch, S. Barre, A. Ford, M. Honda, F. Duchene, O. Bonaventure, and M. Handley, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", Usenix Symposium on Networked Systems Design and Implementation 2012, April 2012,
<https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu>.

[norm]

Technische Universitat Munchen, M. Handley, V. Paxson, and C. Kreibich, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", Usenix Security Symposium 2001, August 2001,
<https://www.usenix.org/legacy/events/sec01/full_papers/handley/handley.pdf>.

[RFC1122]

R. Braden, "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.

[RFC1918]

Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.

[RFC2018]

M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996,
<https://www.rfc-editor.org/info/rfc2018>.

[RFC2979]

N. Freed, "Behavior of and Requirements for Internet Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000,
<https://www.rfc-editor.org/info/rfc2979>.

[RFC2992]

C. Hopps, "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,
<https://www.rfc-editor.org/info/rfc2992>.

[RFC3022]

P. Srisuresh, and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>.

[RFC3135]

J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001,
<https://www.rfc-editor.org/info/rfc3135>.

[RFC4086]

D. Eastlake 3rd, J. Schiller, and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.

[RFC4987]

W. Eddy, "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>.

[RFC5681]

M. Allman, V. Paxson, and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.

[RFC6181]

M. Bagnulo, "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, DOI 10.17487/RFC6181, March 2011,
<https://www.rfc-editor.org/info/rfc6181>.

[RFC6182]

A. Ford, C. Raiciu, M. Handley, S. Barre, and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<https://www.rfc-editor.org/info/rfc6182>.

[RFC6356]

C. Raiciu, M. Handley, and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011,
<https://www.rfc-editor.org/info/rfc6356>.

[RFC6528]

F. Gont, and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012,
<https://www.rfc-editor.org/info/rfc6528>.

[RFC6824]

A. Ford, C. Raiciu, M. Handley, and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>.

[RFC6897]

M. Scharf, and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013,
<https://www.rfc-editor.org/info/rfc6897>.

[RFC7323]

D. Borman, B. Braden, V. Jacobson, and R. Scheffenegger, "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.

[RFC7413]

Y. Cheng, J. Chu, S. Radhakrishnan, and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.

[RFC7430]

M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, and C. Raiciu, "Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/RFC7430, July 2015,
<https://www.rfc-editor.org/info/rfc7430>.

[RFC8041]

O. Bonaventure, C. Paasch, and G. Detal, "Use Cases and Operational Experience with Multipath TCP", RFC 8041, DOI 10.17487/RFC8041, January 2017,
<https://www.rfc-editor.org/info/rfc8041>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[TCPLO]

A Ramaiah, "TCP option space extension", Internet-Draft draft-ananth-tcpm-tcpoptext-00, March 2012,
<https://tools.ietf.org/html/draft-ananth-tcpm-tcpoptext-00>.

• In the SYN: MPTCP uses a 4-byte MP_CAPABLE option. The sum of the MPTCP and TFO options is 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.
• In the SYN + ACK: MPTCP uses a 12-byte MP_CAPABLE option, but now the TFO option can be as long as 18 bytes. Since the maximum option length may be exceeded, it is up to the listener to avoid this problem 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 7 bytes. Note that, for the SYN packet, the same limitation applies to subsequent connections (because the initiator then echoes the cookie back to the listener). Finally, if the security impact of reducing the cookie size is not deemed acceptable, the listener can reduce the amount of space used by other TCP options by omitting the TCP timestamps (as outlined in Appendix A).

Local.Token (32 bits):

This is the token chosen by the local host onthis MPTCP connection. The token must be unique among all establishedMPTCP connections and is generated from the local key.

Local.Key (64 bits):

This is the key sent by the local host on thisMPTCP connection.

Remote.Token (32 bits):

This is the token chosen by the remote host onthis MPTCP connection, generated from the remote key.

Remote.Key (64 bits):

This is the key chosen by the remote host onthis MPTCP connection.

MPTCP.Checksum (flag):

This flag is set to true if at least one of the hosts has set the "A" bit in the MP_CAPABLE options exchanged duringconnection establishment; otherwise,it is set to false. If this flag is set, the checksum must be computed inall DSS options.

SND.UNA (64 bits):

This is the data sequence number of the next byte to beacknowledged, at the MPTCP connection level. This variable is updatedupon reception of a DSS option containing a DATA_ACK.

SND.NXT (64 bits):

This is the data sequence number of the next byte to besent. SND.NXT is used to determine the value of the DSN in the DSS option.

SND.WND (32 bits):

This is the send window. 32 bits if the features in RFC 7323 are used; 16 bits otherwise. MPTCP maintains the send window at the MPTCP connection level, and the samewindow is shared by all subflows. All subflows use the MPTCP connection-levelSND.WND to compute the SEQ.WND value that is sent in eachtransmitted segment.

RCV.NXT (64 bits):

This is the data sequence number of the next byte thatis expected on the MPTCP connection. This state variable is modifiedupon reception of in-order data. The value of RCV.NXT is used to specifythe DATA_ACK that is sent in the DSS option on all subflows.

RCV.WND (32 bits):

This is the connection-level receive window, which is the maximum of the RCV.WND on all the subflows. 32 bits if the features in RFC 7323 are used; 16 bits otherwise.

SND.UNA (32 bits):

This is the sequence number of the next byte to beacknowledged on the subflow. This variable is updated upon reception ofeach TCP acknowledgment on the subflow.

SND.NXT (32 bits):

This is the sequence number of the next byte to besent on the subflow. SND.NXT is used to set the value of SEG.SEQ upontransmission of the next segment.

RCV.NXT (32 bits):

This is the sequence number of the next byte thatis expected on the subflow. This state variable is modified uponreception of in-order segments. The value of RCV.NXT is copied to theSEG.ACK field of the next segments transmitted on the subflow.

RCV.WND (32 bits):

This is the subflow-level receive window that is updated with the window field from the segments received on this subflow. 32 bits if the features in RFC 7323 are used; 16 bits otherwise.

• This document incorporates lessons learned from the various implementations, deployments, and experiments gathered in the documents "Use Cases and Operational Experience with Multipath TCP" [RFC 8041] and the IETF Journal article "Multipath TCP Deployments" [deployments].
• Connection initiation, through the exchange of the MP_CAPABLE MPTCP option, is different from [RFC 6824]. The SYN no longer includes the initiator's key, to allow the MP_CAPABLE option on the SYN to be shorter in length and to avoid duplicating the sending of keying material.
• This also ensures reliable delivery of the key on the MP_CAPABLE option by allowing its transmission to be combined with data and thus using TCP's built-in reliability mechanism. If the initiator does not immediately have data to send, the MP_CAPABLE option with the keys will be repeated on the first data packet. If the other end is the first to send, then the presence of the DSS option implicitly confirms the receipt of the MP_CAPABLE.
• In the Flags field of MP_CAPABLE, "C" is now assigned to mean that the sender of this option will not accept additional MPTCP subflows to the source address and port. This improves efficiency -- for example, in cases where the sender is behind a strict NAT.
• In the Flags field of MP_CAPABLE, "H" now indicates the use of HMAC-SHA256 (rather than HMAC-SHA1).
• Connection initiation also defines the procedure for version negotiation, for implementations that support both v0 [RFC 6824] and v1 (this document).
• The HMAC-SHA256 (rather than HMAC-SHA1) algorithm is used, as it provides better security. It is used to generate the token in the MP_JOIN and ADD_ADDR messages and to set the IDSN.
• A new subflow-level option exists to signal reasons for sending a RST on a subflow (MP_TCPRST (Section 3.6)); this can help an implementation decide whether to attempt later reconnection.
• The MP_PRIO option (Section 3.3.8), which is used to signal a change of priority for a subflow, no longer includes the AddrID field. Its purpose was to allow the changed priority to be applied on a subflow other than the one it was sent on. However, it was determined that this could be used by a man-in-the-middle to divert all traffic onto its own path, and MP_PRIO does not include a token or other type of security mechanism.
• The ADD_ADDR option (Section 3.4.1), which is used to inform the other host about another potential address, is different in several ways. It now includes an HMAC of the added address, for enhanced security. In addition, reliability for the ADD_ADDR option has been added: the IPVer field is replaced with a flag field, and one flag is assigned ("E") that is used as an "echo" so a host can indicate that it has received the option.
• This document describes an additional way of performing a Fast Close -- by sending an MP_FASTCLOSE option on a RST on all subflows. This allows the host to tear down the subflows and the connection immediately.
• IANA has reserved the MPTCP option subtype of value 0xf for Private Use (Section 7.2). This document doesn't define how to use that value.
• This document adds a new appendix (Appendix B), which discusses the usage of both MPTCP options and TFO options on the same packet.

Alan Ford

Costin Raiciu

Mark Handley

Olivier Bonaventure

Christoph Paasch