Additional subflows are not reset when MPTCP options are dropped/invalid after the 3WHS

[matttbe]

What did you do?

In short, this is similar to #518 where the MPTCP options are removed after the 3WHS, but this time on an MP_JOIN subflow.

1. Create an MPTCP connection where the first path has no middlebox intercepting the connection
2. For the additional subflows, use a path where a middlebox will intercept the connection, but only stripping the MPTCP options once the path has been established.

What happened?

The MPTCP connection got stalled at the closure time. Quite a bit of traffic got exchanged on the problematic path, with the MPTCP options visible on the sender side, but not on the reception side. At the application level, the connection didn't end after the "close" (only after a long timeout or a Ctrl+C)

What did you expect to have?

The subflow should be reset, and the connection should continue only on the other subflow.

System info

The client and the server were using the export branch.

Additional context

The server doesn't reset the subflow when receiving data without the DSS because f8d4bca added a bypass for the reception of infinite mapping, which also takes the present case into account (no DSS). I already have a fix for that (and a related one because the bypass should only work if we can fallback).

Also, the client should reset the connection when receiving an ACK without DSS options.

I'm working on that, and packetdrill tests.

Note: the bug has been initially reported to me by Chester A. Unal (arinc9)

[matttbe]

As discussed at the last meeting:

• When an additional subflow has been created, if we receive data without DSS (except if it is covered by a longer mapping sent before), we should reset this subflow. → OK
• If in the same case, a "pure" ACK is received without DACK, it seems to be OK according to the RFC: nothing seems to forbid it as @pabeni pointed out.

@cpaasch if you have the opportunity to look at this: is this correct? (TL;DR: OK to receive plain ACK without MPTCP DACK, but not data without MPTCP DSS)

Currently, when receiving such ACK, the MPTCP code doesn't do anything particular on the MPTCP side: no msk->snd_una update (and then no __mptcp_clean_una()) → so the transfer will continue until the sending buffer is full.