Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

<philip.eardley@bt.com> Tue, 17 July 2018 21:02 UTC

Return-Path: <philip.eardley@bt.com>
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 4F443130FD6 for <multipathtcp@ietfa.amsl.com>; Tue, 17 Jul 2018 14:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 rO08Pv8NqxeZ for <multipathtcp@ietfa.amsl.com>; Tue, 17 Jul 2018 14:02:38 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EF3130DE2 for <multipathtcp@ietf.org>; Tue, 17 Jul 2018 14:02:37 -0700 (PDT)
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 17 Jul 2018 22:02:34 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 17 Jul 2018 22:02:33 +0100
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Tue, 17 Jul 2018 22:02:33 +0100
From: philip.eardley@bt.com
To: cpaasch@apple.com
CC: multipathtcp@ietf.org
Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45ABicRDAAAKmB7oAAALeiAAD9k86A=
Date: Tue, 17 Jul 2018 21:02:32 +0000
Message-ID: <7182bd4c840141858db6075538f99dd8@rew09926dag03b.domain1.systemhost.net>
References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <8aaece0dfe6641ad96f4860720308424@rew09926dag03b.domain1.systemhost.net> <20180715191214.GT1471@MacBook-Pro-19.local> <89d03f9796844ab28090b057580e46c6@rew09926dag03b.domain1.systemhost.net> <20180716153045.GY1471@MacBook-Pro-19.local>
In-Reply-To: <20180716153045.GY1471@MacBook-Pro-19.local>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.216.161.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/DDn-Hn5sVIZTeSf2IrAGb_jwFN8>
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 17 Jul 2018 21:02:47 -0000

Christoph,
I think that basically works.

>>   The client may then retry a new connection with MPTCP v0. Additionally,
   the client can cache this information for future connections.

I think we could expand this a bit?
The client MAY re-try a new connection with MPTCP v0 or with TCP, based on considerations such as .... <importance of using multiple paths, danger of MPTCP downgrade attack...> Additionally the client MAY cache this information for future connections. 

Also, the document mostly uses the terms initiator and listener  (client & server as just in the TFO Appendix).

phil

-----Original Message-----
From: cpaasch@apple.com [mailto:cpaasch@apple.com] 
Sent: 16 July 2018 11:31
To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

In-line

On 16/07/18 - 14:49:45, philip.eardley@bt.com wrote:
> In-line
> 
> -----Original Message-----
> From: cpaasch@apple.com [mailto:cpaasch@apple.com]
> Sent: 15 July 2018 15:12
> To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>
> Cc: multipathtcp@ietf.org
> Subject: Re: [multipathtcp] WG Last Call for 
> draft-ietf-mptcp-rfc6824bis
> 
> Hello Phil,
> 
> some replies to your comments inline:
> 
> On 14/06/18 - 10:55:37, philip.eardley@bt.com wrote:
> > A few comments as I work through the document, basically minor so 
> > far
> > 
> > Section 3.1
> > << Given the SYN exchange is different between v1 and v0
> >    the exchange cannot be immediately downgraded, and therefore if the
> >    far end has requested a lower version then the initiator SHOULD
> >    respond with an ACK without any MP_CAPABLE option, to fall back to
> >    regular TCP.>>
> > I think it should say "to ensure the exchange cannot..."
> 
> I'm not sure where you would put the "to ensure the exchange cannot..."?
> 
> However, reading through this paragraph, I think the SHOULD should rather be a MUST, no? Because, if conflicting versions are being requested we anyways can't do MPTCP.
> 
> [phil] re-reading, I think I mis-interpreted the phrase "Given the SYN exchange is different between v1 and v0  the exchange cannot be immediately downgraded". -- I think you're saying "A downgrade attack is not immediately possible because the SYN exchange is different in v0 and v1". I don't understand - the downgrade attack is possible, in what sense isn't it immediately possible" ? 

The paragraph is not really about attackers trying to downgrade an MPTCP-version. What this part is describing is when the client supports v1 (and requests v1 in the SYN), while the server only supports v0.

In that case, the server would reply with a SYN/ACK and MP_CAPABLE of version 0. The client then needs to fallback to regular TCP as the two versions are not compatible. (because the SYN-exchange has changed).

Re-re-reading again as well, I realize that actually the above would not happen. If a server only supports v0, he will ignore the MP_CAPABLE option in the SYN, because its size is not what it expects.

I suggest the following text for this whole paragraph. Please let me know if that looks good:

   The MP_CAPABLE exchange in this specification (v1) is different to
   that specified in v0 [RFC6824].  If a host supports multiple versions
   of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the
   highest version number it supports.  The passive opener, on receipt
   of this, will signal the version number it wishes to use, which MUST
   be equal to or lower than the version number indicated in the initial
   MP_CAPABLE.
   There is a caveat though with respect to this version negotiation with
   old servers that only support v0. A server that supports v0 expects that
   the MP_CAPABLE option in the SYN-segment includes the client's key. If a
   client however already upgraded to v1, it won't include the key in the
   SYN-segment. Thus, the server will ignore the MP_CAPABLE of this
   SYN-segment and reply with a SYN/ACK that does not include an MP_CAPABLE.
   The client may then retry a new connection with MPTCP v0. Additionally,
   the client can cache this information for future connections.

> Re SHOULD vs MUST. Are there circumstances when you might want to use 
> mptvp v0 rather than use tcp?. Perhaps where an operator has control 
> of both end points (even in a proxy scenario)

Yes, I think so that one would rather use MPTCP v0 than use TCP.


Christoph