Processing of RST segments by Multipath TCP
draft-bonaventure-mptcp-rst-00

Abstract

This document discusses how a Multipath TCP implementation should generate and process RST segments.

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/.

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 4, 2015.

Copyright Notice

Copyright (c) 2014 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 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
• 1.1. Notational Conventions
• 2. Generation of RST segments
• 2.1. Lack of ressources
• 2.2. Administratively prohibited
• 2.3. Too many already acknowledged data
• 2.4. Unacceptable performance
• 2.5. Lifetime expired
• 2.6. Removed address
• 2.7. Middlebox interference has been detected
• 2.8. Multipath TCP specific errors
• 2.9. Fast Close
• 2.10. Unspecified TCP error
• 3. The MPTCP RST option
• 4. Security Considerations
• 5. Conclusion
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

The Transmission Control Protocol (TCP) [RFC0793] was designed to provide a reliable data transfer between hosts attached to a single IP address. Multipath TCP [RFC6824] is a recent extension that enables a single TCP connection to use multiple paths. For Multipath TCP, each path corresponds to a TCP connection established between the communicating hosts. Each of these connections is identified by the classical four-tuple (source and destination IP addresses and source and destination port numbers). Multipath TCP allows to group several of these TCP connections, called subflows in [RFC6824] inside a single Multipath TCP connection. It should be noted that the number of subflows that are used for a given Multipath TCP connection is not fixed and can change during the lifetime of a Multipath TCP connection.

In regular TCP, the RST flag is used to abruptly terminate a TCP connection. When a host receives a valid TCP segment with the RST flag, it immediately terminates the connection. This causes the loss of all in-flight data that has not yet been acknowledged. In the original TCP specification, a host could generate a segment with the RST flag in the following cases:

• A host receives a non-SYN segment that corresponds to a TCP connection that does not exist (anymore).
• A host receives a SYN segment and does not want to establish the requested connection for any reason.
• A host has tried to retransmit the same data too many times without having received an acknowledgment.
• The corresponding connection has been idle for a long time and no answer has been received to the keepalive segments that the host has sent over this TCP connection [RFC1122]
• A host does not have enough resources anymore (e.g. memory) to support the established connection.

Over the years, other reasons to use the RST flag have been added to TCP implementations. The most important one is the possibility for an application, typically a server, to abruptly terminate a TCP connection by forcing the stack to send a segment with the RST flag instead of waiting for the normal FIN exchange and being forced to maintain state.

Despite the fact that TCP is a transport protocol that is used only on endhosts, various types of middleboxes are known to spoof TCP segments that contain the RST flag to abruptly terminate TCP connections [IMC11]. Some of these middleboxes terminate TCP connections to block some applications such as P2P file transfers, others provide security services such as DPI and terminate TCP connections once they have identified suspicious data in the payload. This behavior of middleboxes has been considered as harmful in [RFC3360].

Multipath TCP cannot simply behave like regular TCP when transmitting and receiving TCP segments with the RST flag. Since a Multipath TCP connection is composed of several TCP subflows, the transmission or reception of a TCP RST on a subflow only terminates the corresponding subflow. This does not necessarily terminate the Multipath TCP connection.

This document is organized as follows. We discuss in section Section 2 the reasons why a Multipath TCP host could decide to transmit a RST segment. In section Section 3, we propose a new Multipath TCP option that can be used inside RST segments to convey additional information about the reason for this RST segment and explain how a Multipath TCP host should react to such segments.

1.1. Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

2. Generation of RST segments

This section documents the various reasons why a Multipath TCP host could generate a segment with the RST flag.

2.1. Lack of ressources

A Multipath TCP implementation cannot usually support an unlimited number of TCP subflows associated to a single Multipath TCP connection. A Multipath TCP implementation may face a lack of ressources when :

• It receives a SYN segment and accepting this subflow would exhaust the subflow table of the host.
• It experiences memory pressure and needs to recover additional ressources. Under these circumstances, it could decide to terminate some subflows for existing Multipath TCP connections.

2.2. Administratively prohibited

A Multipath TCP implementation can be configured with policies that determine which subflows can be associated to a given Multipath TCP connection. These policies could be specified on a per application basis, a per host basis or via other means that are outside the scope of this document. Based on this configuration, a Multipath TCP host could generate a RST segment to refuse the establishment of a subflow when :

• It receives a SYN segment from a source address that conflicts with its policies. For example, an enterprise server could be configured to only accept subflows that originate from the enterprise subnet and not from the global Internet.
• It receives a SYN segment with a destination address that conflicts with its policies. For example, a server may be configured to only expose some of its addresses to a subset of its clients.
• It receives a SYN segment destined to a destination port that conflicts with its policies. For example, a web server may be configured to only accept subflows targeted to port 80 even if the Multipath TCP specification allows to group together subflows on different destination ports.

Both ICMPv4 and ICMPv6 contain error codes that can be used to indicate similar error conditions. However, ICMP messages are more likely to be dropped by network equipment than TCP segments. Multipath TCP’s reaction to these ICMP messages and the TCP RST segments should be similar.

2.3. Too many already acknowledged data

Multipath TCP allows data that was transmitted over one subflow to be retransmitted over another subflow. This situation can happen during a handover when a mobile host moves from one access network to another. In this case, the same data can be transmitted twice over different subflows. This is mandated by Multipath TCP to ensure that any middlebox on the path of the first subflow will see in-sequence segments. However, retransmitting already acknowledged data over a subflow is not the best utilisation of the network ressources as reported in [INFOCOM14]. It should be possible for a Multipath TCP host that has too many data that has already been acknowledged over one subflow but still needs to be retransmitted over another subflow to preserve the subflow ordering by terminating the subflow with too many outstanding but already acknowledged data. Measurements or simulations are required to evaluate the best threshold to be used by a Multipath TCP implementation to decide when to terminate such a subflow. In this document, we propose to terminate a subflow once there are more than one initial congestion window’s worth of data that are outstanding on this subflow but have already been acknowledged over another subflow or there is no other data on this subflow.

The situation described above is obviously transient. The termination of such a subflow does not indicate that the path should not be used anymore. Instead, the reception of a RST segment indicating such a cause should trigger the reestablishment of a subflow over this path. The host that sends such a RST segment could also send a SYN segment at the same time. However, it should be noted that there are situations such as a server sending the RST segment to a client connected behind a NAT where only the host that receives the RST segment is able to reestablish the subflow.

2.4. Unacceptable performance

A Multipath TCP host can send data over several subflows. Some of these subflows may perform well while the performance of others could be affected by various performance problems :

• Excessive delay compared to the other subflows. If the receive window used by Multipath TCP is too small, sending data over a long delay subflow would reduce the overall performance of the Multipath TCP connection.
• Excessive losses. The Multipath TCP congestion control scheme tries to move traffic away from congested paths. If one of the subflows is more heavily congested than the others, this can severely impact the performance of the Multipath TCP connection.
• Excessive reordering. Excessive reordering at the subflow level may lower performance by making TCP’s retransmission techniques less reactive. This error condition is typically transient.

A Multipath TCP host that detects that the performance of a Multipath TCP connection is severely affected by one of the underlying subflows, could decide to terminate the offending subflow. Depending on the number of remaining active subflows, it may be needed to reestablish another subflow to replace the terminated one.

2.5. Lifetime expired

A Multipath TCP connection is composed of several subflows. However, maintaining a large number of subflows can be costly from an implementation viewpoint. A Multipath TCP host should monitor the usage of the underlying subflows and could terminate one subflow when :

• No reply has been received to keepalive probes. The keepalive probes [RFC1122] can be used over each subflow to verify that their paths and the remote host are still active. If no answer is received to these probes, the corresponding subflow should be terminated. The Multipath TCP connection could be terminated once the last subflow is terminated. Note that sending a regular RST over each subflow will only terminate the subflow but not the Multipath TCP connection [RFC6824].

2.6. Removed address

When a host receives a REMOVE_ADDR option, it should send a TCP keepalive over each of the subflows using the removed address. If a response to the keepalive is received, the subflow should not be terminated. Otherwise, the lack of response to the keepalives will trigger a termination of the subflow as explained in section Section 2.5.

When a host sends a REMOVE_ADDR option, it SHOULD send a RST segment over each of the subflows that were using the removed address.

2.7. Middlebox interference has been detected

As explained in [RFC6824], Multipath TCP includes several mechanisms to detect and possibly cope with middlebox interference. There are unfortunately cases where Multipath TCP needs to terminate a subflow once it has detected middlebox interference. The following cases are listed in [RFC6824] :

o As explained on page 42 of [RFC6824], a host MUST close a subflow with a RST if the first ACK that it receives over this subflow does not contain the DSS option.

o As explained on page 43 of [RFC6824] a host MUST close a subflow by sending a RST segment with the MP_FAIL option if it receives a segment with an invalid DSS checksum. The MP_FAIL option includes the data sequence number of the first byte of the payload of the affected segment.

2.8. Multipath TCP specific errors

[RFC6824] lists several error conditions that are specific to Multipath TCP and may lead to the termination of a subflow by transmitting a RST segment. These error conditions are :

• A SYN segment with the MP_JOIN option was received with an invalid HMAC or an unknown token. In this case, the host may reply with a RST or silently ignore the error ([RFC6824] pages 22, 23 and 45).
• A TCP segment is received without a DSS checksum on a Multipath TCP connection where the usage of the checksum has been negotiated ([RFC6824] page 24).
• No DSS mapping has been received within a window of data ([RFC6824] page 27).

2.9. Fast Close

The MP_FASTCLOSE option is defined in [RFC6824] allows to quickly terminate a Multipath TCP connection. This operation is described in section 3.5 of [RFC6824].

2.10. Unspecified TCP error

A TCP implementation may send a RST segment for reasons that are unrelated to Multipath TCP.

3. The MPTCP RST option

The Multipath TCP specification [RFC6824] defines several Multipath TCP options. Each option is encoded by using the Type-Length-Value format shown in the figure below.

                        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|                       |
   +---------------+---------------+-------+                       |
   |                     Subtype-specific data                     |
   |                       (variable length)                       |
   +---------------------------------------------------------------+

                      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     |
 +---------------+---------------+-------+-----------------------+