Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
Christoph Paasch <cpaasch@apple.com> Mon, 16 July 2018 15:31 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 4F53413111B for <multipathtcp@ietfa.amsl.com>; Mon, 16 Jul 2018 08:31:27 -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 E1YCnIuinJTA for <multipathtcp@ietfa.amsl.com>; Mon, 16 Jul 2018 08:31:25 -0700 (PDT)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 037031310E3 for <multipathtcp@ietf.org>; Mon, 16 Jul 2018 08:31:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531755083; x=2395668683; 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=t6NXtmTrjr4dWyxNSFvnHeIse4UMB93VFKeHoUWgujU=; b=qPoZpA/8jtl2bcwN9Xr81hnqU+A+iLBR89DZQB9w8vkLC8RoTCnr4xGAguWOvnC1 BKu0vKWaW5jPf5RS9QxcL2A8e99zEAzJ9CscUlt9IKiU7AL96CIFGwLH7jMldaDH jyyf46UC7WVj4OiajVttgBgF8oxRMQOj3ftHkkNr8I2790k2UE8mIeDcLaMXVyQG 67t+sT3svlV5i6I0K3ZfdbJkiSD56T/iE0RCG8n3+/AzWSgvAhdBxaUfhKA5kBGk yIJppYxqtHFTFCGaMIttJbLZRisWZC9TylajBNDhTOZmWN7w7zO3xbq9dN8C/MQm zxRvtKZU7hZkCYEpFUWiVg==;
X-AuditID: 11973e11-a14739e000005b22-62-5b4cba4aecb4
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 12.67.23330.A4ABC4B5; Mon, 16 Jul 2018 08:31:23 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"
Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBY007O3TSAXC10@ma1-mtap-s03.corp.apple.com>; Mon, 16 Jul 2018 08:31:22 -0700 (PDT)
Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBY00L00TS9FD00@nwk-mmpp-sz10.apple.com>; Mon, 16 Jul 2018 08:31:22 -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: 07279268-377b-401e-99df-9b30b75d0bbf
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: 4ceb6d44-7e15-4aaa-acc4-7af1f4154c6d
Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBY00K00TQ4R500@nwk-mmpp-sz10.apple.com>; Mon, 16 Jul 2018 08:31:20 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-16_04:,, signatures=0
X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1
Received: from localhost ([17.235.3.38]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBY00MYQTR9ZZ00@nwk-mmpp-sz10.apple.com>; Mon, 16 Jul 2018 08:30:47 -0700 (PDT)
Sender: cpaasch@apple.com
Date: Mon, 16 Jul 2018 11:30:45 -0400
From: Christoph Paasch <cpaasch@apple.com>
To: philip.eardley@bt.com
Cc: multipathtcp@ietf.org
Message-id: <20180716153045.GY1471@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>
In-reply-to: <89d03f9796844ab28090b057580e46c6@rew09926dag03b.domain1.systemhost.net>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUiqOHDruu9yyfaoOU2k8Xn1dfZLJatXcHo wOTR9mUyk8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIu/5zKVnBApmL9kk0sDYxXxboYOTkkBEwk mp+8YQexhQT2MUmcu8IBYvMKCEr8mHyPpYuRg4NZQF7i4HlZkDCzgLTEo78z2CFsLYnvj1qB SriAWjcySTxc2MoG4XQxSWyauY0NYgG7xJ9fO1ggbG2J04+nscHYf5dDTAKxD/y+CxXnkliw 9TQrhK0rce34aqgaNon1J5YwQdhaEkcXHmKEsa+9mcgKY9++/5EZwuaUOP9lIlSvjsStVWeZ II7rZJJYsuAVVHO2xKs5DVDNwRIPJ7QxQhT9Z5Q4teUpWJGwgKRE9507YFNZBFQlGiftBLuC DWjb29vtYM0iQDUrtq9ig4QLkP33EytEr4fE88tz2UHByCtgITHrsyjE/NnA4NrexjyBUWkW UmjPQoT2LKTQnoUU2gsYWVYxCuUmZuboZuYZ6SUWFOSk6iXn525iBKWK6XaCOxiPr7I6xCjA wajEw9sw2ydaiDWxrLgy9xCjNAeLkjhvp6FntJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG 7eTV3jKS5u9+G3uW81i+uvnmhSZz+6R5y1bV3NtxWsWs5YbVUamq0F3Jx7QeLXx0wO+v4dt6 U4lf+pdeqHRPu5ucFBv6Ku6DJ++DE47/GmxUJ3dnLPIqmrNzEsNe0wCRlQfOvSzfJRolKMnA KdNjutrh558nOZrGHswR59Wv1+S11DAriO9UYinOSDTUYi4qTgQAvWKrfPYCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/FBnxXWRyK39Kt4kuJ48_VTZF6TU>
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: Mon, 16 Jul 2018 15:31:35 -0000
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
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Yoshifumi Nishida
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- [multipathtcp] WG Last Call for draft-ietf-mptcp-… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Alan Ford
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- [multipathtcp] FW: WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Alan Ford
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- [multipathtcp] WG Last Call for draft-ietf-mptcp-… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Rahul Arvind Jadhav
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley