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

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 15 Jul 2019 01:40:28 -0700

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

---

From: <[email-masked]>
Date: Fri, 19 Jul 2019 15:12:19 +0000

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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Yoshifumi Nishida
Sent: Montag, 15. Juli 2019 10:40
To: multipathtcp <[email-masked]<mailto:[email-masked]>>
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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 20 Jul 2019 03:42:12 -0700

Hi Markus,

Thanks for the response.

On Fri, Jul 19, 2019 at 8:12 AM <[email-masked]> 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.
>
>
>
> 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
>
> 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 <[email-masked]> *On Behalf Of *Yoshifumi
> Nishida
> *Sent:* Montag, 15. Juli 2019 10:40
> *To:* multipathtcp <[email-masked]>
> *Subject:* [multipathtcp] comments on draft-amend-mptcp-robe-00
>
>
>
> Hi,
>

---

From: <[email-masked]>
Date: Mon, 22 Jul 2019 22:24:33 +0000

Hi Yoshi,

picking up your comments:

- Corner cases for Key-B_fast_hash I don’t see, as any match would be validated by a HMAC authentication. The Key-B_fast_hash is just for accelerating the matching process and reducing computational overhead.

- Including Key-A in the HMAC would give indication if the plain text Key-A in the MP_JOIN_CAP is valid. But maybe it is enough the have Key-B and Key-B', let me check this

- Pointing to the scenario when MP_JOIN_CAP does not arrive at Host B is very good. I have not considered this so far. Maybe a 4-WHS like MP-JOIN uses is an option, this could also facilitate the RobE_EXT negotiation

BR

Markus

From: Yoshifumi Nishida <[email-masked]>
Sent: Samstag, 20. Juli 2019 12:42
To: Amend, Markus <[email-masked]>
Cc: multipathtcp <[email-masked]>
Subject: Re: [multipathtcp] comments on draft-amend-mptcp-robe-00

Hi Markus,

Thanks for the response.

On Fri, Jul 19, 2019 at 8:12 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yoshi,

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.

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

Hi,

Thanks,
--
Yoshi