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

<Markus.Amend@telekom.de> Fri, 19 July 2019 15:12 UTC

Return-Path: <Markus.Amend@telekom.de>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFCA1203D8 for <multipathtcp@ietfa.amsl.com>; Fri, 19 Jul 2019 08:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P01fb-UNx8JD for <multipathtcp@ietfa.amsl.com>; Fri, 19 Jul 2019 08:12:34 -0700 (PDT)
Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEEA6120301 for <multipathtcp@ietf.org>; Fri, 19 Jul 2019 08:12:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1563549150; x=1595085150; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JlsO9KTtV89u6wMf4JIhVRuF0vkMbF3J/CqFhD1nJwM=; b=IeZ/XQdOtWAtYf4mJVIezfjP/J8QvJB7LSHc/Dskhd0uVVyYoVfH10qX gVdrKzJadJq9gx6fMpMJmru+tn6/tLVqtZR6UZ9WttDLKQd2UGzS7Q5U3 eOM9UApPxwJ3gJyCuvfUuuUP8qMhVGuCzlhkJ0ERfIyl+Gi0xmnWw0kK1 TBh3oY7wmBY3+ZJ7xVeGGHAxJA/uZrOdOoKfZZEs+JJBHy9llUFUI5MxY ZMCXqNO+spkv9TSVVwWGcbPZ2l2jSk9MtAtNF0x5Ff0OzXeDCkAtpMwlM x1gbRWREg2RuyGgmlRPNPt5jrG3Nfb27gGAXofN6UDZJ5WrfOMncmpMpa A==;
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jul 2019 17:12:17 +0200
X-IronPort-AV: E=Sophos;i="5.64,282,1559512800"; d="scan'208,217";a="327194098"
X-MGA-submission: =?us-ascii?q?MDEgUq1+itsKPRvzK1TCTI4Y20FMCXH/tB+Mro?= =?us-ascii?q?0dXHWE+q3BxN86Dqc+S09eoabdah17Xb80OY18Pq1xQ2gshGq+k8XAkw?= =?us-ascii?q?5AVr0OZuDfiSvJDlbKnv3Vhl4uvRv5CeCQIQSkb8d3jXNmZX+ae/qYah?= =?us-ascii?q?MbeLeUMLAZA4XkFmxvhc1H/w=3D=3D?=
Received: from he105711.emea1.cds.t-internal.com ([10.169.118.42]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 19 Jul 2019 17:12:20 +0200
Received: from HE105709.EMEA1.cds.t-internal.com (10.169.118.41) by HE105711.emea1.cds.t-internal.com (10.169.118.42) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 19 Jul 2019 17:12:20 +0200
Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105709.EMEA1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 19 Jul 2019 17:12:20 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.17) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 19 Jul 2019 17:12:20 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AbiylEmIPmaDwW4NwQ0nyp9SZD/T0zsudAli+xn6Ym4qVHYgWvG+Bi+h0Tml6GDpyIi/SRRfu9k9/uhVqRIHn+hMNZX7DySnXCnEIihM9F69LP/T8VVj4jdLpkRrhhOZ75C773ROpUdtXh72PXOKgy8v+zjRWWhHKfWrD1JMDWW/3bEBkg0AwfowWq5XbW3GxkDyMsTf2MMJsQ8YFC9GzgTlivQRp7ku14N4RYgCBlA0SsnYmpexjv0aTbvHeVofht6dnRVZp0EHGvQe2Kk0u1cZtnlQjnJsI+xUJG3c/pTikci/ytJIn0jgTR0qrBBEEff6qVUV9DPkfEXgH7thxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JlsO9KTtV89u6wMf4JIhVRuF0vkMbF3J/CqFhD1nJwM=; b=T/RfKBZgPHQwP/VFWj71xtwrzAIyXEvJ3LA3KehFk6p0Bpn/GLPgfFZyqjwaBD/p1w/fyyNbDt2wj2ajgWzPtpaj/7e+0SsaKIQKs2pr4Fxw9Vc6gYQOFcayr7S69yEF5juI2DOq71Ei4zu3uGkVI8+VHQHOnSwL25bFKJvefTj0MOTCT3Ff+s4m0dcIfbMQYgdD7QwI9+nBR5iYE7XOPR6ALl9PJ9y8n8Bawu0xN6tvPk/eCF+yuEjljdTPhlTjE2OcrtYsBvc12i8dya0RuDGM06FxtgDN9oh+fFCck6CZcgtGqpyl1Dh/2k8sorbhDvJE++ZUoRhoi9u5Pv6quw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=telekom.de;dmarc=pass action=none header.from=telekom.de;dkim=pass header.d=telekom.de;arc=none
Received: from FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.21) by FRAPR01MB1203.DEUPRD01.PROD.OUTLOOK.DE (10.158.137.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Fri, 19 Jul 2019 15:12:19 +0000
Received: from FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6dc7:5b87:f2f3:d953]) by FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE ([fe80::6dc7:5b87:f2f3:d953%8]) with mapi id 15.20.2073.016; Fri, 19 Jul 2019 15:12:19 +0000
From: <Markus.Amend@telekom.de>
To: <nsd.ietf@gmail.com>, <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] comments on draft-amend-mptcp-robe-00
Thread-Index: AQHVOukSTro+Zk+7PkCv0Kc6ij5q0abNExHw
Date: Fri, 19 Jul 2019 15:12:19 +0000
Message-ID: <FRAPR01MB1170BA28B1E18F71FD61B0ADFACB0@FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE>
References: <CAAK044S6U05Vh2V5-TQt6Rr=n0t3_Fp9vBoJG0TGK1CjH9cBEg@mail.gmail.com>
In-Reply-To: <CAAK044S6U05Vh2V5-TQt6Rr=n0t3_Fp9vBoJG0TGK1CjH9cBEg@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Markus.Amend@telekom.de;
x-originating-ip: [212.201.104.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 10580d7f-14f5-4ee3-da91-08d70c5b7e54
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:FRAPR01MB1203;
x-ms-traffictypediagnostic: FRAPR01MB1203:
x-microsoft-antispam-prvs: <FRAPR01MB12038897FC1AB50145D91AB7FACB0@FRAPR01MB1203.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 01039C93E4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(39860400002)(366004)(346002)(199004)(189003)(6116002)(8936002)(66476007)(76116006)(66446008)(66556008)(14454004)(256004)(14444005)(64756008)(7736002)(81156014)(81166006)(66946007)(8676002)(26005)(446003)(71200400001)(186003)(3846002)(11346002)(229853002)(86362001)(71190400001)(5660300002)(102836004)(561944003)(33656002)(53546011)(476003)(790700001)(236005)(76176011)(316002)(66066001)(53936002)(6306002)(9686003)(54896002)(110136005)(55016002)(486006)(6246003)(478600001)(68736007)(52396003)(2906002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB1203; H:FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: KnlPEeRHNYebXJts92dgNjJTQZ6ciavEALr0agPyiUCcTPv32zMD7Yq9w/RxzopogvsAVMzGxEWDLPBX9fw1HgJsLZvsSKpZ8Ablw5NjjaTJBRVj+Y8DQzDITpjgoH/mXqCSHAJgAnBJXYCnPHZvHCuomtbpn7hL5JRaO2XYecudiwoXX08ZEh6JsjYleyy+ik2hl76nlsG7PewjAacjrqTbjG+8S1a5hS5sxdP8Wla9+CvhFULa2xwtYDVvH1OyAcEUeQISyV7x2vPNgeXgZ9cTezc5G1aC6d6Tz4CIbOF53n6QWcrADudvhvqH6VL7KOxqfh8Rzfoy1cG/6BBnl4+OL5i66XyPvDMUeLdi5UgyR3tJ8BVtZ77cMT1ibz0aEkXWyHg6HvfHLlw62vgF9l43ED3rOD6j3kUiYLAfllE=
Content-Type: multipart/alternative; boundary="_000_FRAPR01MB1170BA28B1E18F71FD61B0ADFACB0FRAPR01MB1170DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 10580d7f-14f5-4ee3-da91-08d70c5b7e54
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 15:12:19.6142 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Markus.Amend@telekom.de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB1203
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/KDwCVN7DzPYCh-shv_tBOva9aUU>
Subject: Re: [multipathtcp] comments on draft-amend-mptcp-robe-00
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2019 15:12:38 -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 <multipathtcp-bounces@ietf.org<mailto:multipathtcp-bounces@ietf.org>> On Behalf Of Yoshifumi Nishida
Sent: Montag, 15. Juli 2019 10:40
To: multipathtcp <multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>>
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