Re: [multipathtcp] comments on draft-amend-mptcp-robe-00

[<[e-mail]>]

Hi Yoshi,

thanks for your comment. To be honest I wrote the draft in a hurry to have something available for the upcoming meeting, that is the reason why not everything is explained in depth. A revision of the content is planned for IETF 106 then, for which I have already collected some potential co-authors and reviewers ☺

But coming to your questions. RobE in general guarantees session establishment if at least one path out of a bunch is functional, without knowing which one is functional beforehand.
A simple break-before-make can ensure this by the cost of establishing (a lot of) MPTCP-connections which needs to be dropped afterwards and may be re-established using a MP_JOIN. In the draft you can find this concept referred to as RobE_SIM. Further it is present in Fig. 2 at step SA6.1->SB6.1, when sender decides to go for the first established initial flow and drop (RST) the other one.

Another option in Fig. 2 is drawn using MP_JOIN_CAP instead of RST to gain immediate use of such a – from a RobE_SIM view useless -  path and join it to the initial path. This offers shortest latency to establish e2e connection and faster subflow establishment to accelerate transmission speed.

The big benefit of MP_JOIN_CAP are twofold.


1.       MP_JOIN_CAP can immediately join an initial flow to another initial flow

2.       MPTCP v1 (RFC6824bis) explicitly requires the final ACK with a Key-A of the initial flow 3WHS, which is not the case when using MP_JOIN_CAP

As I presented the idea of RobE at IETF 99 first in a more rudimentary state, the comment from the audience was, that RobE

- must not require (much) more calculation time inside a MPTCP implementation compared to the traditional MP_CAPABLE/MP_JOIN
- must be secure like traditional MPTCP
- must cover MPTCP v0 and v1

To fulfill this, the HMAC of a MP_JOIN_CAP contains information on the selected initial path’s Key A and Key B (which is not the path sending the MP_JOIN_CAP) and also a fast hash of Key_B to.
Section 2.3.2 in the draft explains the cases which kind of information carried by the MP_JOIN_CAP is needed in which scenario.

- When everything goes well, the path which returns first a SYN/ACK will be selected as initial path on initiator side (Host A, Fig 2). If the corresponding last ACK+MP_CAPABLE is received first before the MP_JOIN_CAP arrives on receiver side (Host B), than Key-A from the MP_JOIN_CAP can identify relationship and authenticate by the HMAC. This effort is comparable to MP_JOIN and is true for MPTCP v0 and v1

- When the MP_JOIN_CAP arrives before the final ACK of the selected initial path we have to differentiate between v1 and v0. For v0 the effort is like MP_JOIN, because Key-A is known on receiver side already. For v1 Key-A is not known since it is carried first with the final ACK. For that a very little amount of extra calculation has to be executed. It is assumed, that the receiver calculates a Key-B__fast_hash and stores this information with the not yet established connection. Iterating over this connections only (presumably small effort) and compare with Key-B__fast_hash of the MP_JOIN_CAP gives on the other hand the huge effect, that even the not yet established connection and the flow carrying the MP_JOIN_CAP become immediately usable! Fur sure after identifying a flow with the less secure fast_hash this is followed by an authentication with the HMAC.

I hope that clarifies a little bit your first question.

If I got your second question right, it raises the issue of MP_JOIN_CAP support negotiation?! That will be addressed in a later revision of the draft in section 2.4. However a simple solution could be just resetting a flow, if the receiver does not support MP_JOIN_CAP, analogous to the error handling in RFC6824 section 3.7.

BR

Markus

From: multipathtcp <[e-mail]<mailto:[e-mail]>> On Behalf Of Yoshifumi Nishida
Sent: Montag, 15. Juli 2019 10:40
To: multipathtcp <[e-mail]<mailto:[e-mail]>>
Subject: [multipathtcp] comments on draft-amend-mptcp-robe-00

Hi,
I've read this draft and I personally like the idea in the draft. Thanks for an interesting proposal.
Bellows are my comments on the draft.
1: I'm trying to understand the rationale behinds the format of MP_JOIN_CAP, such as the purpose of Key-B_fast_cash and the calculation of HMAC_keys. Could you elaborate?
2: Don't we have a certain ACK mechanism for MP_JOIN_CAP such as ADD_ADDR? Otherwise, we cannot confirm that the peer has agreed with sender's intention and it can cause errors in the mptcp session.

Thanks,
--
Yoshi