Re: [PATCH mptcp-net v2] mptcp: avoid combining some incoming suboptions

Hello,

On 22/07/2026 00:57, Matthieu Baerts (NGI0) wrote:
> Some MPTCP suboptions are mutually exclusive according to the RFC8684,
> but also because in different places, the code doesn't expect some
> combinations to be present. That's specially true for suboptions that
> would be present twice, but with different attributes.
> 
> The new restrictions are the same as the ones applied on the output
> side, with mptcp_write_options. The same rules can be reused:
> 
>   Which options can be used together?
> 
>   X: mutually exclusive
>   O: often used together
>   C: can be used together in some cases
>   P: could be used together but we prefer not to (optimisations)
> 
>   | Opt: | MPC  | MPJ  | DSS  | ADD  |  RM  | PRIO | FAIL |  FC  |
>   |------|------|------|------|------|------|------|------|------|
>   | MPC  |------|------|------|------|------|------|------|------|
>   | MPJ  |  X   |------|------|------|------|------|------|------|
>   | DSS  |  X   |  X   |------|------|------|------|------|------|
>   | ADD  |  X   |  X   |  P   |------|------|------|------|------|
>   | RM   |  C   |  C   |  C   |  P   |------|------|------|------|
>   | PRIO |  X   |  C   |  C   |  C   |  C   |------|------|------|
>   | FAIL |  X   |  X   |  C   |  X   |  X   |  X   |------|------|
>   | FC   |  X   |  X   |  X   |  X   |  X   |  X   |  X   |------|
>   | RST  |  X   |  X   |  X   |  X   |  X   |  X   |  O   |  O   |
>   |------|------|------|------|------|------|------|------|------|
> 
> The only difference is with the 'P': another stack could send and
> ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be
> allowed.
> 
> A point of attention is with the MP_CAPABLE: it could be used with a
> RM_ADDR, but there is no reason to add it with a SYN. Note that even
> with a 4th ACK, it doesn't seem to be useful, except when IDs are known
> in advance via another channel. Better not to break that.
> 
> Also, in mp_opt->suboptions, there is also a bit reserved to the
> checksum, which can be used in an MP_CAPABLE and a DSS. Each time a DSS
> option can be used in parallel with another option, the checksum can be
> set, so the verification is combined into a new OPTIONS_MPTCP_DSS macro.
I hope that's OK if I apply this patch: I would rather send it upstream
soon to avoid even more AI-generated reports when combining incompatible
options.

New patches for t/upstream-net and t/upstream:
- f34e22f63cde: mptcp: avoid combining some incoming suboptions
- Results: 2668d30f6377..aa8e7044082a (export-net)
- Results: a596e199424d..f630d7e8910a (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/bffeddcac4e2dc23c53eeb0b2cc0251289dd1948/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/5daa351aeda080c736302d73482d93f9b78e5aa8/checks

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.