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

<Markus.Amend@telekom.de> Mon, 22 July 2019 22:25 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 DD4F412006B for <multipathtcp@ietfa.amsl.com>; Mon, 22 Jul 2019 15:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.297
X-Spam-Level:
X-Spam-Status: No, score=-4.297 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, URIBL_BLOCKED=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 nQxjbOfG6kO0 for <multipathtcp@ietfa.amsl.com>; Mon, 22 Jul 2019 15:25:01 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 1A208120293 for <multipathtcp@ietf.org>; Mon, 22 Jul 2019 15:25:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1563834299; x=1595370299; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OJvUpV+aVvXQMyUzLuzS/TP4i9GMVGEKbDMFfYyYaGE=; b=BMtcUcQSXEDBZA9s2HjuIoskYnV5pon75J4nWxOjU4X2AwBryWgB1BHr zMZOzhYAwXrWehClmKz5ioOoBdjq9PrYiTbGSkCHKwaHcqPwRDIL//bmY +hUl7LAv75c271R0BEZhJgZx+0UGe8amwOVMa1nsafRWSRd0ee3m7jTgi 0iKhDHyJ03eoWVN1oonebqFHa6GkRYXT1MMNFNf8/gMUh3NrONoC0vyGB fZot8lZtiinaNAwt5TUWnyvzCBs5DlmY5gNFarYtus18SitFmPR7YvnK9 bUFKBmsg/cdp0td2Q6eXxUjCDMDQS9ezBFycBcFzn1TIeD4HuVnHYcwD8 A==;
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2019 00:24:57 +0200
X-IronPort-AV: E=Sophos;i="5.64,296,1559512800"; d="scan'208,217";a="464933823"
X-MGA-submission: =?us-ascii?q?MDERL/nEhAxY8ShLGfKAKzJqi2DO3H4c93fdZw?= =?us-ascii?q?X3xbJLu4Y08qXxlHHX8xgrHN6KT9NpdU/YIBcrV+NIRDK70goL3CVkiq?= =?us-ascii?q?pI7wxpk9j+Zn+CExzr+X6fsjt1uasPOci97PBasEhp2IFTUSUOjQ8nZL?= =?us-ascii?q?N77Wb6/avarrZc+Aa4VH6eKQ=3D=3D?=
Received: from he105716.emea1.cds.t-internal.com ([10.169.118.52]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 23 Jul 2019 00:24:58 +0200
Received: from HE105715.EMEA1.cds.t-internal.com (10.169.118.51) by HE105716.emea1.cds.t-internal.com (10.169.118.52) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 00:24:55 +0200
Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105715.EMEA1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 23 Jul 2019 00:24:55 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.18) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 00:24:51 +0200
Received: from FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE (10.158.133.21) by FRAPR01MB0900.DEUPRD01.PROD.OUTLOOK.DE (10.158.135.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Mon, 22 Jul 2019 22:24:33 +0000
Received: from FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE ([fe80::84a2:8467:4d99:1ab8]) by FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE ([fe80::84a2:8467:4d99:1ab8%5]) with mapi id 15.20.2094.013; Mon, 22 Jul 2019 22:24:33 +0000
From: <Markus.Amend@telekom.de>
To: <nsd.ietf@gmail.com>
CC: <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] comments on draft-amend-mptcp-robe-00
Thread-Index: AQHVOukSTro+Zk+7PkCv0Kc6ij5q0abNExHwgAZGsACAA+ToIA==
Date: Mon, 22 Jul 2019 22:24:33 +0000
Message-ID: <FRAPR01MB1170B068CACDEE60D64F7D6BFAC40@FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE>
References: <CAAK044S6U05Vh2V5-TQt6Rr=n0t3_Fp9vBoJG0TGK1CjH9cBEg@mail.gmail.com> <FRAPR01MB1170BA28B1E18F71FD61B0ADFACB0@FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE> <CAAK044S+pN-+ajYon2WAjdiArAQWL_ZBkffiLnC+L7-UmDa79w@mail.gmail.com>
In-Reply-To: <CAAK044S+pN-+ajYon2WAjdiArAQWL_ZBkffiLnC+L7-UmDa79w@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: 7c2e37ef-2639-4259-7eda-08d70ef35f29
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:FRAPR01MB0900;
x-ms-traffictypediagnostic: FRAPR01MB0900:
x-microsoft-antispam-prvs: <FRAPR01MB09009EBF79D5C038CF248DB0FAC40@FRAPR01MB0900.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 01068D0A20
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(366004)(346002)(376002)(189003)(199004)(51914003)(5660300002)(7736002)(6246003)(6916009)(55016002)(6116002)(8676002)(68736007)(229853002)(236005)(4326008)(86362001)(3846002)(790700001)(66946007)(64756008)(66556008)(81166006)(81156014)(9686003)(76116006)(71200400001)(54896002)(6306002)(71190400001)(66476007)(8936002)(66446008)(26005)(256004)(52396003)(7696005)(53546011)(186003)(102836004)(486006)(446003)(476003)(66066001)(5070765005)(76176011)(11346002)(478600001)(14444005)(316002)(14454004)(561944003)(53936002)(2906002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0900; H:FRAPR01MB1170.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: VUoZwRx+3oKZoqFDHwgaWPJO2tn0eetDTNrZoYl6mnqTt+3jjWcjh+GlWGUTXn4HfavXVYiNci6l5NSPKXhnLDRkqhNLJHjZV/d9HQl6nmFmLCrkA5JL19F9xoaA11Y24yxVyM9kjmVrAzDQnJtVUBRDk3gMZtVcNDhl+oSj9I9tbcZ8hzwSSwim1nuST31Quy3PVgHnfAqaH9uZNRtzS4VHBVmGBjb1RBs0WcgAffELIKN1x2QThZdgbTxfYC1hA7ZnjwCDZlAI48CHeqxcBkM09nGMiuPlkhcm+KAU6bAcFTnD//Ld2moKiN5Iu+qOf1+gtBBS6nQnj8uscIWy3CCjZ5kv93phguihATYTpTADcMr4MaYkY370m1KUyY18hCRq7Jsep9KO1c//hJLKcJqI4yxzNdC5DG+OLTL707c=
Content-Type: multipart/alternative; boundary="_000_FRAPR01MB1170B068CACDEE60D64F7D6BFAC40FRAPR01MB1170DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c2e37ef-2639-4259-7eda-08d70ef35f29
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2019 22:24:33.1801 (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: FRAPR01MB0900
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/qpY3jW15yOvvF2QmdZZ7Ijv4r0M>
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: Mon, 22 Jul 2019 22:25:05 -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 <nsd.ietf@gmail.com>
Sent: Samstag, 20. Juli 2019 12:42
To: Amend, Markus <Markus.Amend@telekom.de>
Cc: multipathtcp <multipathtcp@ietf.org>
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 <Markus.Amend@telekom.de<mailto:Markus.Amend@telekom.de>> 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 ☺

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