[multipathtcp] Re: comments on draft-baerts-tcpm-mptcpext-00

[Yoshifumi Nishida <[e-mail]>]

Hi Matt, thanks for your response. I put my comments in lines.

On Tue, Jul 15, 2025 at 2:14 PM Matthieu Baerts
<[e-mail]> wrote:
>
> Hi Yoshi,
>
> On 15/07/2025 05:57, Yoshifumi Nishida wrote:
> > Hi Matt, Olivier,
> >
> > Thanks for providing a draft. I have a couple of comments on the
> > following points.
>
> We appreciate your review!
>
> > It would be great if you could clarify them.
> >
> > 1: As far as I remember we had draft-paasch-mptcp-application-
> > authentication and draft-paasch-mptcp-ssl which address similar points.
> > I think it would be great if the draft can address what's the difference
> > between them and this draft and what's the advantages of this approach, etc.
>
> Good point! These drafts have been mentioned, but that's it. I created a
> task for that:
>
>   https://github.com/IPNetworkingLab/draft-mptcp-ext/issues/1

Thanks!

> > 2: How to send NEW_KEY options is not very clear to me. Should it be
> > sent with an ack or a data packet or doesn't it matter?
>
> Similar to other signalling options from RFC8684, it doesn't matter, as
> long as there is space in the TCP options. (That's why most signals are
> sent in a pure ACK)

I think it's fine if they're not retransmitted. But, it seems that
this option requires retransmissions.
In my understanding, MPTCP retransmits pure ACKs only if they are third ACKs.
However, this option will be used in other pure ACKs. One concern for
this is if we retransmit pure ACKs, it can be looked as dup acks,
which might trigger CC by mistake.

> > Also, what's the receiver's reaction when it receives the option?
>
> Each side should announce the new key, and switch to it when both sides
> receive it. We tried to explain this in the draft [1], but I suspect
> this is not clear enough, is that right?

Well, if a host receives a hash that doesn't match the stored one, it
just discards the option. I guess this means NEW_KEY option won't be
sent back.
Doesn't it cause retransmissions on the other side?

> [1]
> https://www.ietf.org/archive/id/draft-baerts-tcpm-mptcpext-00.html#section-4.2-7
>
> > In addition, I think
> > we'll need to define what we should do when the receipt of the option
> > cannot be confirmed. (e.g. no response from the receiver or rejected)
>
> For the moment, the receiver will discard the option [2]:
>
> > If a host receives a NEW_KEY option whose HMAC and key identifier do
> > not match the stored ones, it simply discards the option.
> [2]
> https://www.ietf.org/archive/id/draft-baerts-tcpm-mptcpext-00.html#section-4.2-10
>
> Do you think it would not be OK? Or should it be clearer?

I think a host that sends NEW_KEY option needs to give up resending it
at some point.
I think the draft needs to address this point.

> > 3: Why does it store just two keys? Or, does it mean it generates a new
> > key when the next key is chosen and throws away the current key?
>
> We don't think there is a need to deal with more than two keys: the
> current one, and the previous/next one. Only two keys can be used "at
> the same time" when we are in the process of switching to a new one.
>
> So yes, when there is a need to switch to a new one, the "non-active"
> key is thrown away, and the new one is suggested via NEW_KEY. The
> "active" key remains active until the reception of a NEW_KEY for the
> same new key.
>
> We should probably clarify in the draft why a maximum of two keys is enough:
>
>   https://github.com/IPNetworkingLab/draft-mptcp-ext/issues/2

Thanks. I think it would be good if this point is clarified.

> > 4: What will happen if responders don't support this feature? Is it
> > possible to fall back to normal MPTCP?
>
> Yes it is possible to fall back to "normal" MPTCP. Similar to the
> "mptcpdss" extension: compared to RFC8684, the only difference in the
> SYN + MP_CAPABLE is the 'E' flag. Something often confusing when reading
> RFC8684 is that the SYN + MP_CAPABLE doesn't carry any key. It looks
> like that:
>
>                           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|Version|A|B|C|D|E|F|G|H|
>      +---------------+---------------+-------+-------+---------------+
>      |  Data-Level Length (16 bits)  |  Checksum (16 bits, optional) |
>      +-------------------------------+-------------------------------+
>
>
> So if the 'E' flag is not supported, the receiver can send a SYN + ACK +
> MP_CAPABLE without the 'E' flag. At the reception of this SYN+ACK, the
> initiator can generate a token like before, and send it in the 3rd ACK.
> The draft tries to explain the fallback if this extension is not
> supported [3]:
>
> > A responder that receives a SYN with the MP_CAPABLE option having the
> > TBD bit set responds with an MP_CAPABLE option and the TBD bit set if
> > it supports the external keys. Otherwise, it replies with an
> > MP_CAPABLE option whose TBD bit is reset and follows the procedure
> > defined in [RFC8684].
>
> [3]
> https://www.ietf.org/archive/id/draft-baerts-tcpm-mptcpext-00.html#section-4.1-7
>
> Should it maybe be clearer?

Yes, thanks for the clarification.
--
Yoshi