Re: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing

[<[e-mail]>]

Did we reach consensus about this proposed change?
Thanks
phil

-----Original Message-----
From: multipathtcp [mailto:[e-mail]] On Behalf Of François Finfe
Sent: 13 September 2017 14:39
To: [e-mail]
Cc: Olivier Bonaventure <[e-mail]>
Subject: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing

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.


François

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

_______________________________________________
multipathtcp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/multipathtcp