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

Christoph Paasch <cpaasch@apple.com> Wed, 18 July 2018 14:14 UTC

Return-Path: <cpaasch@apple.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 78D39130E31 for <multipathtcp@ietfa.amsl.com>; Wed, 18 Jul 2018 07:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 tcdnd0BPjddX for <multipathtcp@ietfa.amsl.com>; Wed, 18 Jul 2018 07:13:59 -0700 (PDT)
Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 67797130E14 for <multipathtcp@ietf.org>; Wed, 18 Jul 2018 07:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531923238; x=2395836838; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FzH3Ilb+8EEL1FQMVgKD9aldykni0Z/khrbho8zOfTY=; b=ktaPbfb0iB7hZ5bhGfuq+OcNIrKzq8i3SJcsrwQhpoJIfI1nDemHRw8FRgJbvz20 /0coRIhgoNXIPPoy5JvItpS+rmksY+Fe/OroiUJCil+HO+c4RtLwn0Ss8tZR0eGE n9n5bT25x9LKjMBkxwMf7pgEO5tuvBqT+Cbi4V1gL7aEF6gVq1Aahl+jRm1YubZS T9kRNfDc9ZKhYPCN7ByhTvIv0YVvQeCfUv+Udka7+2Zk1VgcFg1AWxw6NW5faCne MPzQhLZU+lKA+1Fm5MOTWg41gy4HdC+czyKS0yX9kHzCaJuVSw0TwYu2f8g7AIaU y2KOo3vVv6GLumXUH/9vyQ==;
X-AuditID: 11ab0217-24b109e000003e90-62-5b4f4b26cbfd
Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id E9.47.16016.62B4F4B5; Wed, 18 Jul 2018 07:13:58 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PC200DMPFJ9QU80@mr2-mtap-s03.rno.apple.com>; Wed, 18 Jul 2018 07:13:57 -0700 (PDT)
Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200400F9TLW00@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:13:57 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 858e2f4dae29a6016c98c8320829244c
X-Va-E-CD: 3bbd785c51ace3f981efd92bc4e82048
X-Va-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7
X-Va-CD: 0
X-Va-ID: 82223510-c77b-44c7-8470-dcfe97d42b11
X-V-A:
X-V-T-CD: 858e2f4dae29a6016c98c8320829244c
X-V-E-CD: 3bbd785c51ace3f981efd92bc4e82048
X-V-R-CD: 2b9cdb0e57a359d759a3675f8c35d2a7
X-V-CD: 0
X-V-ID: 42a6051c-d85b-4a5c-a7ec-88bc83eaa818
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PC200400F9SLU00@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:13:57 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-16_06:,, signatures=0
X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1
Received: from localhost ([17.235.39.85]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PC200AVCFJ71R30@nwk-mmpp-sz11.apple.com>; Wed, 18 Jul 2018 07:13:56 -0700 (PDT)
Sender: cpaasch@apple.com
Date: Wed, 18 Jul 2018 10:13:55 -0400
From: Christoph Paasch <cpaasch@apple.com>
To: philip.eardley@bt.com
Cc: multipathtcp@ietf.org
Message-id: <20180718141355.GN1471@MacBook-Pro-19.local>
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> <7182bd4c840141858db6075538f99dd8@rew09926dag03b.domain1.systemhost.net>
In-reply-to: <7182bd4c840141858db6075538f99dd8@rew09926dag03b.domain1.systemhost.net>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUiuPlRu66at3+0wYX38hafV19ns1i2dgWj A5NH25fJTB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYPeUqU8FytYrvE36zNzDOk+ti5OSQEDCR eL6ykxnEFhI4yCSxYlsqiM0rICjxY/I9li5GDg5mAXmJg+dlQcLMAtISj/7OYIewtSS+P2oF KuECal3PJHFwdR+U08Ukcen+XUaIBewSf37tYIGwtSVOP57GBmP/XQ4xCcQ+8PsuVJxLYsHW 06wQtq7Es3OfoGrYJNafWMIEYWtJHF14iBHGvvZmIiuMffv+R2YIm1Pi/JeJUL06Ege3TWaC OK6TSeLU0nXsIJ9JCGRLdG6qgDCDJfa/VYYoaWCSOP59Hdg9wgKSEt137oDNZBFQlTg0vwNs FxvQrre328FsEaCaFdtXsUFCBcj++4kVotdD4vnlueyQALWQOLq0gRES0FOZJW6+qZzAqDQL KaxnIcJ6FlJYz0IK6wWMLKsYhXMTM3N0M/OMjPUSCwpyUvWS83M3MYISxWom8R2Mn18bHmIU 4GBU4uHN+OsbLcSaWFZcmXuIUZqDRUmc98MusWghgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jJIdb4ucG9pUt4d+FY+Z11IhsH1V0zm5+O+z246YF75PU4qxMvCJ8nwcJuMfn8rWVxjAIiOW 11nls+PL48ijKhFbKt6zZzcGWCr0ipyon9x/2+UV15cXkkdXPM1N+HJ1t3t/+joRoUPPnsxf fH3Fy098xdtuyG6y7Xy97+G2G/2RyvpBH/RslViKMxINtZiLihMBTEgi3/UCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/NNShTXCncGaLBCQwbIxdaNsSzjg>
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: Wed, 18 Jul 2018 14:14:02 -0000

Hello Phil,

On 17/07/18 - 21:02:32, philip.eardley@bt.com wrote:
> 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. 

thanks I expanded it in your suggested way.

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

Changed client/server to initiator/listener in the TFO appendix.


Christoph

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