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

[Matthieu Baerts <[e-mail]>]

Hi Yoshi,

Thank you for your reply! Please see my comments below:

On 16/07/2025 18:51, Yoshifumi Nishida wrote:
> On Tue, Jul 15, 2025 at 2:14 PM Matthieu Baerts
> <[e-mail]> wrote:
>> 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.

Sorry, I was not clear about that: some MPTCP signalling options will be
retransmitted if needed. This is the case with ADD_ADDR for example, and
also the case here with NEW_KEY [1].

[1]
https://www.ietf.org/archive/id/draft-baerts-tcpm-mptcpext-00.html#section-4.2-7

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

MPTCP will retransmit pure ACKS, and indeed, this could be seen by
middleboxes -- or the sender/receiver if this event is not treated
differently -- as dup acks. But this should not happen often, and very
likely due to congestion, so probably not an issue for the CC, no?

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

Yes, that's correct. It is similar to the behaviour linked to the
ADD_ADDR in RFC8684 [2]: it leaves the choice to the implementors to
decide how to proceed with the retransmissions:

> According to local policy, the lack of this type of "echo" can indicate
> to the initial ADD_ADDR sender that the ADD_ADDR needs to be retransmitted.

On Linux for example, an ADD_ADDR will be retransmitted maximum 3 times.

[2] https://www.rfc-editor.org/rfc/rfc8684#section-3.4.1-9

>> [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.

It was not specified in RFC8684 for the ADD_ADDR [2], but this new draft
can of course advise stopping at some points:

  https://github.com/IPNetworkingLab/draft-mptcp-ext/issues/3

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

Great, thank you!

Cheers,
Matt