Message-ID: <9144fcf7-9087-45b6-af4c-3d5f7040a06f@uclouvain.be>
Date: Tue, 15 Jul 2025 23:14:49 +0200
User-Agent: Mozilla Thunderbird Beta
Content-Language: en-GB, fr-BE
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
References: 
 <CAAK044Rmey=zL-zx=a2bZFR_r04WUUK-ij8Wuxm8P4YtE_eF7A@mail.gmail.com>
From: Matthieu Baerts <matthieu.baerts@uclouvain.be>
Organization: UCLouvain
In-Reply-To: 
 <CAAK044Rmey=zL-zx=a2bZFR_r04WUUK-ij8Wuxm8P4YtE_eF7A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?WUNwRDkzZzRBKzhiWjdKWllhRG9ObDB0SlpXcE0wcVgvaFBQR1Jadm91RWJ5?=
 =?utf-8?B?YWdyMjRhOTJCZ0lUYlNXZVd5aGFjdlpYNCthY3JhRi9lbmQ1L2ZnMVgzUjZq?=
 =?utf-8?B?eGhsdzBVc2FNOUFsZEY5ODFONG40SFZXSXBEKzBLRkMwYi9tMi9nMmtYdEFC?=
 =?utf-8?B?Rm53V094TGcxdFRxUnZTUEFETVRWdExOMUhzZ1FZTW1ueGwzaGlmcjJ1ZHMy?=
 =?utf-8?B?b0p0NDd6YWxKaEgvYW1Xc25vNy9pSks1OXZYS3F5RUZTVC9VK1ZlWlUyajVZ?=
 =?utf-8?B?YWZqS2VzUGkrUjl4RHRWNGxKMU80RitEUENCOGN3V21PRkgxM3VsVmZ0Mktp?=
 =?utf-8?B?elZFVW01bFZGWU1YTVoxS1FXZHFHT21hVzgxTjhJa2ViNjZJNnVJQ3g3cnN0?=
 =?utf-8?B?bGVId243WWJMSWhaMWpzcTFLRFFHTFhxV0grMzA2YlBtVGNUV3BmWENLUzJY?=
 =?utf-8?B?MlU1OTA5UFdiRGxWNkxLYjZIZTV4Um1BdzVTUGtvYVBiK1l4Qms5NWF5RVZw?=
 =?utf-8?B?Wngxay9xM0FxNldWMFh2enVCZWkwUmIySVpDczFOZHowRzB1M25RVUhGbjlW?=
 =?utf-8?B?cmtUbXlDNVpTSEhZYVY0MU1vRDVsRjhZUDg3YVJ0RVJ4RVR1SWJ0V1l5T3Jq?=
 =?utf-8?B?Nm5tNWp0SGhCbjk2aEZXV3lZZXoybmx4VFNrRUtUbXVub2NUV1YwOWYzcXJK?=
 =?utf-8?B?eXZGNk9ZbDRTQnJKU0FKcCtSS0ExWXVRUCtQMnlpVmpidFhVZG9HSHRrYmpE?=
 =?utf-8?B?aUFWd0tnc3NVdVYxcTJoVVZhVlFIRDc1bHVaNGZ5cFBIZ08ySW9GdHJGY2JV?=
 =?utf-8?B?TitPZFVaOHNtanRteVFNaHB3VWhndEUzdGVkYWNGcGhlaDNUeFhuQjcyM2dp?=
 =?utf-8?B?QkF0NlJjWGZ3RGsraGtTNzJMTmk1bXRyeEZWYzRKRmJUSFVHdHVMMS81Tjdk?=
 =?utf-8?B?UkFHUnVWdGhmVC9OaDdTTVM3dlVOWUVPRmtLWUpqNFl2cTYwNm5HWnM3U0Fy?=
 =?utf-8?B?amh5K2dtTVVsMUNieUhzNmkyUG90VVBuOXdMNVp1ZEVDYkJDQVE5YmZPNktl?=
 =?utf-8?B?dkF3WUR5bWZJTEVZSWo1bUhtTlM3VEc0YURyRTVsbzJPWW1QLy85M3lsSDVM?=
 =?utf-8?B?VVIyZ3VIOTFyOU1BQUJzdDBDaVF3VThsQzZhVE1LU3ZacE4rcC9HWFgzS2hV?=
 =?utf-8?B?WTRGcXdocWFuQjdhbXZwS2VYWlpISVhVbkt2OGF2VlRwelBNaFB2L3ZEcG1N?=
 =?utf-8?B?UCtSMHFUL3Q3enRubXNldkxJWXJMRkYzd1diSklFd3RPeHBMN29SUytiNy9T?=
 =?utf-8?B?QnY1OXN5OU9aZzFrOWtLeGRmS244c2lTNVRNTXR0YmtXN0tzWGNFMGZTRzB2?=
 =?utf-8?B?eGl4M3MvaU1oaDZIejJTYWtXeTZBdXRqZVhXYWlyNmhjMzNIRS9TeWpwNGtX?=
 =?utf-8?B?R2pZUERVeitoeE1Cc3luS0xWS29YbDNHeHdxN1RjSWNHTEt4TzZ6TU00UFRx?=
 =?utf-8?B?NlVPb0FsQWxXZURPTDFITmpKUVBzYjVTZzZUWXpOOHNGK2NUbEVvMlVDTkla?=
 =?utf-8?B?VXorYUNRMlFESGkwUjl2T3JuTHEwd3A0UDg2cFp2VnJtWFEyTkVhTXFmQnRy?=
 =?utf-8?B?c3o3b21IdXM3YTJuTE9NN3N3TFJTeFlySk1lQk1EVGdxakUrRzRKcUp3N0gw?=
 =?utf-8?B?Mjhza0FDb2NqNjlsMnh2N24wZmpGREpodDdXazdRTnp6ZkVuTHNtUnMwajVt?=
 =?utf-8?B?OTJqRHNlNTZoQmo5R3ZNUGlJN2pobkJheXMxVU5rZm8xTUltd3VuUmNsQXVP?=
 =?utf-8?B?WWFJMDZRcE5vQmg0SWNwNmYvUmorSGUvR2srK3hHVVZGclJTNDNSY281RzhG?=
 =?utf-8?B?RnM0RmhGUFhhYzlYcEJ4QzE3ZmdNOGJRY2twL0FqQTJoQ1VBY25GYTMvNTlM?=
 =?utf-8?B?c1d1c3pOQUYzYVRmTmlhdFVpVDhsOTJNc29DYXpUTFQ4TGFRYU5uUmh2NXE2?=
 =?utf-8?B?UVJmV2JxSVNseVZRY1B3QysrbHd3a1FnUm1kWStCbnUrcDhXMHVqaVFnM3ls?=
 =?utf-8?B?YW9HZng3VGF5eVc4SUZmSGtTNGprd0RuYll2QmtHbSsvdnVuck5lTjhvUTNl?=
 =?utf-8?B?bWZXbnpOUlM5Z1JQVU1NUzNjUHBkblc4dFRPRUsrbXZlZ0M1WmpPaU9ldEFG?=
 =?utf-8?B?VExqSDh2WjVrTXY3NVV6YjZaNEhheUtuRk96Q3ZhQ3JTdjN1Q0gvWkk4c0U5?=
 =?utf-8?B?SU9PLzNTam42U3dERHJIZjJDNDl3PT0=?=
X-OriginatorOrg: uclouvain.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 dfa5c580-2c5b-4979-d192-08ddc3e4a31b
X-MS-Exchange-CrossTenant-AuthSource: GVXPR03MB8450.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2025 21:14:51.4493
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 
 YEPLo/jlyGOHXjWK0OBFzhoEnI+/AaeeAVXC61GeZ0tEdUHMyufZxTrPUGF0BZ1BKySv979Lc+WmWAbag2qyJ0n2eDQBQlVfwkwDw2+G7GM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB6963
Message-ID-Hash: L3GDFUK3BSC6MHYOBZO72M7NEWH6XR67
X-Message-ID-Hash: L3GDFUK3BSC6MHYOBZO72M7NEWH6XR67
X-MailFrom: matthieu.baerts@uclouvain.be
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation;
 header-match-multipathtcp.ietf.org-0; nonmember-moderation; administrivia;
 implicit-dest; max-recipients; max-size; news-moderation; no-subject;
 digests; suspicious-header
CC: multipathtcp <multipathtcp@ietf.org>,
 "tcpm@ietf.org Extensions" <tcpm@ietf.org>,
 Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5Bmultipathtcp=5D_Re=3A_comments_on_draft-baerts-tcpm-mptcpext-00?=
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/multipathtcp/oA3CuwyM9O59cWm_pYg8L_9h4ro>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Owner: <mailto:multipathtcp-owner@ietf.org>
List-Post: <mailto:multipathtcp@ietf.org>
List-Subscribe: <mailto:multipathtcp-join@ietf.org>
List-Unsubscribe: <mailto:multipathtcp-leave@ietf.org>

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


> 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)

> 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?

[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?


> 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


> 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?

Cheers,
Matt