Subject: [multipathtcp] Adding options in MPTCP RST

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 03 Mar 2014 20:55:41 +0100

Hello,

With regular TCP, a host sends a RST when it does not have any state 
about a TCP connection. The reception of a RST forces the termination of 
the corresponding TCP connection.

Given that a RST segment is a fast way to terminate a TCP connection, 
some middleboxes are capable of sending spoofed RST segments to 
terminate TCP connections. We've seen some of these deployed to block 
some forms of P2P applications, but some DPIs are likely capable of 
doing this as well.

With Multipath TCP, a RST can have a slightly different meaning. It can 
indicate that a host has lost all its state for the corresponding MPTCP 
connection. In this case, the other host should discard all its state.

However, there are situations where a host could want to send a RST to 
quickly terminate a subflow without terminating the MPTCP connection 
(which can continue on other subflows that already exist or will be 
established). A typical example is a server having two subflows towards 
a client. The server has sent a window worth of data on the first 
subflow but this data has not yet been acknowledged. After some tiemout 
expiration, the server retransmits the data over the second subflow and 
it gets immediately acknowledged. When the first subflow recovers, the 
server still needs to retransmit the data over this subflow even if it 
has already been acknowledged at the MPTCP level. This is inefficient. 
It would be nice for the server to be able to send a RST over the first 
subflow with a kind of reason code that indicates that the client should 
recreate a subflow. Since the client is often behind a NAT, it is 
impossible for the server to create this subflow by itself.

Another example is when the server can support a limited number of 
subflows, say 2. If it receives a SYN for a third subflow from the 
client, it would reply with a RST. Adding a reason code indicating that 
the server supports up to 2 subflows would allow the client to learn 
that it should not try to establish more subflows.

By adding an option in the MPTCP RST, we might also enable the client to 
distinguish between a RST generated by a middlebox and a RST generated 
by the endhost. For this, the RST option could include the DATAACK and a 
HMAC of this DATA_ACK to authenticate it.

Any other thoughts on adding options inside the RST ?

Olivier

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Mar 2014 18:05:38 -0800

On 3/3/2014 11:55 AM, Olivier Bonaventure wrote:
...
> Any other thoughts on adding options inside the RST ?

Ian Heavens suggested doing something like this in Jan. 1998, in a long 
exchange he and I had about TIME-WAIT, where he noted:

"Another possibility would be to encode the RST type as a TCP option
(suggested to me by Richard Stevens)."

I'm not sure where you can/should add RST options unless they're in a 
TCP option, FWIW.

Joe