Checksum support

[matttbe]

As defined in RFC8684, it needs to be negotiated:

(...)

The second octet is reserved for flags, allocated as follows:
A: The leftmost bit, labeled "A", SHOULD be set to 1 to indicate "Checksum required", unless the system administrator has decided that checksums are not required (for example, if the environment is controlled and no middleboxes exist that might adjust the payload).

(...)

Both the crypto and checksum bits negotiate capabilities in similar ways. For the "Checksum required" bit (labeled "A"), if either host requires the use of checksums, checksums MUST be used. In other words, the only way for checksums not to be used is if both hosts in their SYNs set A=0. This decision is confirmed by the setting of the "A" bit in the third packet (the ACK) of the handshake. For example, if the initiator sets A=0 in the SYN but the responder sets A=1 in the SYN/ACK, checksums MUST be used in both directions, and the initiator will set A=1 in the ACK. The decision regarding whether to use checksums will be stored by an implementation in a per-connection binary state variable. If A=1 is received by a host that does not want to use checksums, it MUST fall back to regular TCP by ignoring the MP_CAPABLE option as if it was invalid.

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

But also when transferring data:

(...)

The flags, when set, define the contents of this option, as follows:

(...)

M = Data Sequence Number (DSN), Subflow Sequence Number (SSN), Data-Level Length, and Checksum (if negotiated) present

(...)

Note that the checksum is only present in this option if the use of MPTCP checksumming has been negotiated at the MP_CAPABLE handshake (see Section 3.1). The presence of the checksum can be inferred from the length of the option. If a checksum is present but its use had not been negotiated in the MP_CAPABLE handshake, the receiver MUST close the subflow with a RST, as it is not behaving as negotiated. If a checksum is not present when its use has been negotiated, the receiver MUST close the subflow with a RST, as it is considered broken. In both cases, this RST SHOULD be accompanied by an MP_TCPRST option (Section 3.6) with the reason code for an "MPTCP-specific error"

(...)

The Data Sequence Mapping also contains a checksum of the data that this mapping covers, if the use of checksums has been negotiated at the MP_CAPABLE exchange. Checksums are used to detect if the payload has been adjusted in any way by a non-MPTCP-aware middlebox. If this checksum fails, it will trigger a failure of the subflow, or a fallback to regular TCP, as documented in Section 3.7, since MPTCP can no longer reliably know the subflow sequence space at the receiver to build Data Sequence Mappings. Without checksumming enabled, corrupt data may be delivered to the application if a middlebox alters segment boundaries, alters content, or does not deliver all segments covered by a Data Sequence Mapping. It is therefore RECOMMENDED that checksumming be used, unless it is known that the network path contains no such devices.The checksum algorithm used is the standard TCP checksum [RFC0793], operating over the data covered by this mapping, along with a pseudo‑header as shown in Figure 10.

                       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
  +--------------------------------------------------------------+
  |                                                              |
  |                Data Sequence Number (8 octets)               |
  |                                                              |
  +--------------------------------------------------------------+
  |              Subflow Sequence Number (4 octets)              |
  +-------------------------------+------------------------------+
  |  Data-Level Length (2 octets) |        Zeros (2 octets)      |
  +-------------------------------+------------------------------+

Figure 10: Pseudo-Header for DSS Checksum

Note that the data sequence number used in the pseudo-header is always the 64-bit value, irrespective of what length is used in the DSS option itself. The standard TCP checksum algorithm has been chosen, since it will be calculated anyway for the TCP subflow, and if calculated first over the data before adding the pseudo-headers, it only needs to be calculated once. Furthermore, since the TCP checksum is additive, the checksum for a DSN_MAP can be constructed by simply adding together the checksums for the data of each constituent TCP segment and adding the checksum for the DSS pseudo‑header.

Note that checksumming relies on the TCP subflow containing contiguous data; therefore, a TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing mapping. Further note, however, that if Urgent data is received on a subflow, it SHOULD be mapped to the data sequence space and delivered to the application, analogous to Urgent data in regular TCP.

(...)

An "infinite" mapping can be used to fall back to regular TCP by mapping the subflow-level data to the connection-level data for the remainder of the connection (see Section 3.7). This is achieved by setting the Data-Level Length field of the DSS option to the reserved value of 0. The checksum, in such a case, will also be set to 0.

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

And every other MPTCP packets headers.

Please also see the link with MP_FAIL #52 in the Fallback section: https://www.rfc-editor.org/rfc/rfc8684.html#sec_fallback

[geliangtang]

Hi Matt, I'll work on this issue.

[matttbe]

Can be closed thanks to Geliang and Paolo's commits and reviews from Mat!

• 9e37234: mptcp: add csum_enabled in mptcp_sock
• 8e5a007: mptcp: generate the data checksum
• 65d5dab: mptcp: add csum_reqd in mptcp_out_options
• fa7ac4a: mptcp: send out checksum for MP_CAPABLE with data
• 020aa27: mptcp: send out checksum for DSS
• f343075: mptcp: add sk parameter for mptcp_parse_option
• 36175fd: mptcp: add csum_reqd in mptcp_options_received
• f9b610c: mptcp: receive checksum for MP_CAPABLE with data
• dcf392e: mptcp: receive checksum for DSS
• ff6ab77: mptcp: validate the data checksum
• c30f4b4: mptcp: cleanup error path in subflow_check_data_avail()
• 7929c26: mptcp: tune re-injections for csum enabled mode
• b5cfe0d: mptcp: add the mib for data checksum
• caf02cd: mptcp: add a new sysctl checksum_enabled
• c8a3478: selftests: mptcp: enable checksum in mptcp_connect.sh
• ed46f07: selftests: mptcp: enable checksum in mptcp_join.sh
• Results: 0987319..e2c6aca

---

• d1af2c9: Squash to "mptcp: add a new sysctl checksum_enabled"
• Results: e2c6aca..dd923e7

---

• c5be02c: "squashed" patch 1/5 in "mptcp: add csum_reqd in mptcp_out_options"
• 29f9232: "squashed" patch 2/5 in "mptcp: add the mib for data checksum"
• ad81f7f: "squashed" patch 3/5 in "mptcp: add a new sysctl checksum_enabled"
• e2cc6a7: mptcp: dump csum fields in mptcp_dump_mpext
• d92aa7c: "squashed" patch 5/5 in "selftests: mptcp: enable checksum in mptcp_join.sh"
• Results: dd923e7..9e9ac16

---

• 4a14b59: "squashed" in "mptcp: dump csum fields in mptcp_dump_mpext"
• Results: 9e9ac16..3ad3c4c