MP_TCPRST support

[matttbe]

As defined in RFC8684:

An implementation of MPTCP may also need to send a regular TCP RST to force the closure of a subflow. A host sends a TCP RST in order to close a subflow or reject an attempt to open a subflow (MP_JOIN). In order to let the receiving host know why a subflow is being closed or rejected, the TCP RST packet MAY include the MP_TCPRST option (Figure 15). The host MAY use this information to decide, for example, whether it tries to re-establish the subflow immediately, later, or never.

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

Figure 15: TCP RST Reason (MP_TCPRST) Option

The MP_TCPRST option contains a reason code that allows the sender of the option to provide more information about the reason for the termination of the subflow. Using 12 bits of option space, the first 4 bits are reserved for flags (only one of which is currently defined), and the remaining octet is used to express a reason code for this subflow termination, from which a receiver MAY infer information about the usability of this path.
The "T" flag is used by the sender to indicate whether the error condition that is reported is Transient ("T" bit set to 1) or Permanent ("T" bit set to 0). If the error condition is considered to be Transient by the sender of the RST segment, the recipient of this segment MAY try to re-establish a subflow for this connection over the failed path. The time at which a receiver may try to re‑establish this subflow is implementation specific but SHOULD take into account the properties of the failure as defined by the provided reason code. If the error condition is considered to be Permanent, the receiver of the RST segment SHOULD NOT try to re‑establish a subflow for this connection over this path. The "U", "V", and "W" flags are not defined by this specification and are reserved for future use. An implementation of this specification MUST set these flags to 0, and a receiver MUST ignore them.
"Reason" is an 8-bit field that indicates the reason code for the termination of the subflow. The following codes are defined in this document:

• Unspecified error (code 0x00). This is the default error; it implies that the subflow is no longer available. The presence of this option shows that the RST was generated by an MPTCP-aware device.
• MPTCP-specific error (code 0x01). An error has been detected in the processing of MPTCP options. This is the usual reason code to return in the cases where a RST is being sent to close a subflow because of an invalid response.
• Lack of resources (code 0x02). This code indicates that the sending host does not have enough resources to support the terminated subflow.
• Administratively prohibited (code 0x03). This code indicates that the requested subflow is prohibited by the policies of the sending host.
• Too much outstanding data (code 0x04). This code indicates that there is an excessive amount of data that needs to be transmitted over the terminated subflow while having already been acknowledged over one or more other subflows. This may occur if a path has been unavailable for a short period and it is more efficient to reset and start again than it is to retransmit the queued data.
• Unacceptable performance (code 0x05). This code indicates that the performance of this subflow was too low compared to the other subflows of this Multipath TCP connection.
• Middlebox interference (code 0x06). Middlebox interference has been detected over this subflow, making MPTCP signaling invalid. For example, this may be sent if the checksum does not validate.

https://www.rfc-editor.org/rfc/rfc8684.html#sec_reset

If needed, new tickets can be created to track: receiver/sender side only and packetdrill support.

(Feature from the initial roadmap)

• Kernel code
• Packetdrill code
• IPRoute code: netlink events for the RST maybe? → Netlink events for MP_TCPRST #188
• Wireshark / TCPDump doesn't understand option subtype 8 → Wireshark / TCPDump doesn't understand option subtype 8 (MP_TCPRST) #189

[matttbe]

Florian is looking at this

[matttbe]

For the kernel code: it is now in our tree:

• 787b042: mptcp: add mptcp reset option support
• Results: 8a82f6b..99476ba

We can wait for multipath-tcp/packetdrill#45 to close this one

[matttbe]

• Packetdrill code → done with Mptcp reset option packetdrill#45

There are two remaining points: netlink events and wireshark/tcpdump. We can also create other tickets and close this one if it is not planned to work on them ;-)

[matttbe]

Thank you for your work!

With #188 and #189 , we can close this one!