Re: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing

[Christoph Paasch <[e-mail]>]

Hello,

On 13/09/17 - 15:39:20, François Finfe wrote:
> Hi,
> 
> 
> RFC6824 and RFC6824bis use the FAST_CLOSE option to abruptly close a
> Multipath TCP connection. The motivation for the procedure defined in
> section 3.5 is to enable a host to quickly terminate a Multipath TCP
> connection without being forced to send DATA_FINs.
> 
> The current procedure defined in section 3.5 is that the host that
> wishes to abruptly terminate a connection must send a RST on all
> subflows except one where it sends an ACK with the FAST_CLOSE option and
> waits for a RST before closing the Multipath TCP connection. The
> FAST_CLOSE option includes the receiver’s key to authenticate the abrupt
> release of the subflow. This prevents attacks where a remote attacker
> could send spoofed packets that would terminate the Multipath TCP
> connection.
> 
> Unfortunately, the procedure defined in section 3.5 has a very important
> drawback. Although the host wants to abruptly close the Multipath TCP
> connection, it needs to maintain state for this connection until the
> other host has confirmed (with a RST) the termination of the connection.
> This goes against the idea of abruptly closing connections due to lack
> of ressources for example. We have faced some issues with applications
> using SO_LINGER set to zero that were expecting the socket to have
> disappeared after an abrupt release while it did not disappear.
> 
> It would make sense to reconsider the abrupt connection termination
> procedure defined in section 3.5 to enable a host to immediately
> terminate a Multipath TCP connection and release the associated data
> structures. One possibility would be to work as follows.
> 
> Consider a Multipath TCP connection established between a client and a
> server. There are two subflows, A and B. The server wants to abruptly
> close the connection. For this, we propose to continue to use the
> FAST_CLOSE option, but place it inside the RST packet sent over all
> subflows. By using a RST instead of an ACK as in section 3.5, the server
> does not need to maintain any state and can remove the data structures
> associated with the closed connection immediately. If one of the RST
> packets reaches the client, it will know that the entire connection has
> been closed by the server.
> 
> The only issue with this new approach is when none of the RST packets
> sent by the server reach the client. We would be in a situation where
> the client considers that the Multipath TCP is active while it does not
> exist anymore on the server. After some time, the client will send a
> packet to the server over one of the subflows. Since the Multipath TCP
> connection does not exist anymore on the server, it will reply with a
> RST packet that will close this subflow. The client will receive the
> same RST over all the established subflows. When all subflows have been
> closed, the client should try to establish a new subflow to the server
> by sending a SYN with MP_JOIN. Upon reception of this SYN, the server
> will try to match the connection token with the established Multipath
> TCP connection and will find that there is no matching connection.
> According to RFC6824, the server should reply with a RST packet to close
> the subflow. We could add to this RST packet a new MP_TCPRST option
> indicating that the server could not match the received token with an
> existing connection. Upon reception of a RST carrying this option, the
> client would know that the corresponding connection has been closed by
> the server and would close it itself.
> 
> We believe that this approach is simpler on the server side while still
> allowing clients to detect closed Multipath TCP connections. The abrupt
> closing (e.g. socket option SO_LINGER with zero timeout) is also
> properly implemented. In contrast with the current approach, it places
> the burden on the client instead of on the server, but we believe this
> is beneficial for servers that often need to abruptly close connections.

I strongly support this proposal.

Whenever the stack decides to force-fully close a connection due to
resource-limitations, it is important for the scalability of the system to
get rid of the state as quickly as possible. Otherwise, servers accumulate
huge numbers of these lingering connections.


Christoph