Re: [multipathtcp] potential MPTCP proxy charter item

Joe Touch <touch@isi.edu> Tue, 08 November 2016 14:35 UTC

Return-Path: <touch@isi.edu>
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 0FADA129CAF for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.397
X-Spam-Level:
X-Spam-Status: No, score=-8.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] 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 5VC620jduYgP for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:35:21 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6747129674 for <multipathtcp@ietf.org>; Tue, 8 Nov 2016 06:35:21 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uA8EZ6jl001334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Nov 2016 06:35:09 -0800 (PST)
To: mohamed.boucadair@orange.com, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <57543A7A-1542-4C60-A5D3-E1658354BE5A@tik.ee.ethz.ch> <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@gmail.com> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <85D52AE4-FE5F-4977-8927-6BDB72614D07@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D2630820-7586-4361-A626-3278F22C319C@gmail.com> <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch> <4fceb7e5-a0b0-d4d2-8669-fad0df59095d@uclouvain.be> <C0212561-63DA-4578-9795-928B51F2A71B@tik.ee.ethz.ch> <c93d9d6b-f46b-2b11-da6b-a308159ef7c0@isi.edu> <00ba6ab8-8fbf-ab19-b996-b84b87ad5520@isi.edu> <F9AAAF6C-DF82-412E-9C88-9043CC1EC3AA@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAE088@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Joe Touch <touch@isi.edu>
Message-ID: <ca2610f2-4f1b-5123-1e6e-697dfbe7cdc7@isi.edu>
Date: Tue, 08 Nov 2016 06:35:07 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAE088@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/W1CdZojAYuMXP-2urm36nDmmsqU>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
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, 08 Nov 2016 14:35:23 -0000

Hi, Med,


On 11/8/2016 2:07 AM, mohamed.boucadair@orange.com wrote:
> Joe,
>
> I'm inserting the full text of that section here: 
>
> ====
>          4.2.2.5  TCP Options: RFC-793 Section 3.1
>
>             A TCP MUST be able to receive a TCP option in any segment.
>             A TCP MUST ignore without error any TCP option it does not
>             implement, assuming that the option has a length field (all
>             TCP options defined in the future will have length fields).
>             TCP MUST be prepared to handle an illegal option length
>             (e.g., zero) without crashing; a suggested procedure is to
>             reset the connection and log the reason.
> ====
>
>    The proposed design for the MP_CONVERT option does not violate that
>    text, IMO.  I'm listing here the design approaches that we considered
>    so far:
>
>       (1) no change to MP_CAPABLE: MPTCP proxies are prepared by design
>       to look at the payload of SYN to retrieve MP_CONVERT options.
>
>       *  MP_CONVERT options are inserted in the payload of a SYN that
>          includes MP_CAPABLE.
>       *  If the remote peer does not support MPTCP, the connection will
>          be reverted to TCP according to the base MPTCP specification.
...
Please explain. If there is option information in the SYN data, then a
legacy peer is allowed to keep that data (and ACK it) in the SYN ACK.

So now it has option info that it interprets as data. You can't undo
that unless you RST the connection, but that violates the cited text in
RFC1122 above, i.e., you have created an option you cannot ignore by
simply not ACKing it.


>      (2) change MP_CAPABLE to explicitly indicate that options are
>       present in the SYN payload:
>
>       *  A flag in the MP_CAPABLE will be set to indicate to a remote
>          peer that MP_CONVERT options are included in the payload.
>       *  If the remote peer does not support MPTCP, the connection will
>          be reverted to TCP as per base MPTCP specification.
...
This has exactly the same problem.

It's not about "MUST ignore" - it's about "without error". Your approach
creates an error in the TCP connection.

Joe