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

[Yoshifumi Nishida <[e-mail]>]

Hi Markus,

Thanks for the response.

On Fri, Jul 19, 2019 at 8:12 AM <[e-mail]> wrote:

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

Thanks for the clarification. this is helpful. I am thinking we will need
to think about a corner case where there's conflict of Key-B_fast_hash. I
am also wondering if we need to include Key-A for HMAC calculation as
MP_JOIN_CAP already has Key-A.


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

Yes, reset will work in some situations.
But, what I was thinking is what will happen when MP_JOIN_CAP has not
reached to Host B for some reasons. (e.g. the ACK has been lost or a
middlebox removed the option)

Thanks,
--
Yoshi

>
>
> *From:* multipathtcp <[e-mail]> *On Behalf Of *Yoshifumi
> Nishida
> *Sent:* Montag, 15. Juli 2019 10:40
> *To:* multipathtcp <[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
>