[multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing

[François Finfe <[e-mail]>]

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.