Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <alan.ford@gmail.com> Fri, 04 November 2016 11:02 UTC

Return-Path: <alan.ford@gmail.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 D1E481295AC for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 04:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iBw5Q8n0H_qR for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 04:02:06 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 10F4E12949F for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 04:02:05 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id p190so43033411wmp.1 for <multipathtcp@ietf.org>; Fri, 04 Nov 2016 04:02:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=hCenPFFokBLHvk3jQnUmANSRGC+uzx/sURc7OfAgbM0=; b=ECgrbek0Bq8QyXq5jq95vPBTtf+6rj+g0kc0aS2Goqf7PkF7snOiw5+4paMQS6Jw77 6g6Fa4qXcBkrDySZvtaSmM4g7usjZEY+iTPpNMMDbmYVW/f+ctfF0bevYvx4NeWPPU5Q qQbglrFkN0muHPOIFukXUElHl68ddNRx1yq4cz6U20gZWCVSE7LN4XXIL3WkEzwNFccw w0R0sXPE5RXrsNn9t/HAlm+JizsOxVdGSApWX5sin7I2UpyHuA2hs+Z5yRpxMmG84x5G eu3TAchqiVLXTFj4sTK5B92RUe9iZ3zKQRhrkwTxulKdZOMfTjRm2gtVA2EKsUcCQ6zz 9SJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hCenPFFokBLHvk3jQnUmANSRGC+uzx/sURc7OfAgbM0=; b=NVM7EDaurf2hG8LfsTVrThv1LxRzTTSpK2kPkGVDHA+CszDRXEu/SH20/BGerOhHQx 15CvBnO9WX/6nTGCpKwKxa2XqCzCEyHf4eIwyWw5hfln9tTPsXYx4+7rT9kUlHnUFHcL PGcqWTgrN8OoDeUnV0qQHE06+XLQYdUYyUUp1SaIRs5j78h5ODvCnV1I/oE6JiEvvxhu LcFx4vJS6bsvmgJau4JIJfLHL01r8Zap4L/oy7V/jIsESeC092tu3awyvUPZAobHepHs pVAjGAMzlHNyViXPgfBr5KypORryq94vtFuhOtbTttj8208XhYJehqbN8xYV1zcQi29Q of5g==
X-Gm-Message-State: ABUngvdnnkGLor3YWU2iqZ0UKr2wE6KCgP7grJJoT44f24gbB2HtkTed6abo+cbKgNeAOQ==
X-Received: by 10.28.54.161 with SMTP id y33mr2934863wmh.122.1478257324517; Fri, 04 Nov 2016 04:02:04 -0700 (PDT)
Received: from alans-mbp.lan ([37.152.254.14]) by smtp.gmail.com with ESMTPSA id ff4sm13604120wjd.39.2016.11.04.04.02.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Nov 2016 04:02:03 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_51AAA225-4EB7-4460-9BD2-D179E56D1D82"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAC5DE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Fri, 4 Nov 2016 11:02:02 +0000
Message-Id: <EBFA61A5-4A9E-4B41-BDC1-4F9056241D70@gmail.com>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <428609FE-DE79-45CD-B668-EF95F409B593@tik.ee.ethz.ch> <8bed05c5-9f6f-04aa-8aa8-690aa3ce30f4@uclouvain.be> <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <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> <787AE7BB302AE849A7480A190F8B933009DAC5DE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/IBLn-vDMJjxtOJdSDfVCEdkS9Ng>
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: Fri, 04 Nov 2016 11:02:13 -0000

Hi Med,

Inline…

> On 4 Nov 2016, at 10:12, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
> 
>> -----Message d'origine-----
>> De : Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
>> Envoyé : vendredi 4 novembre 2016 10:34
>> À : BOUCADAIR Mohamed IMT/OLN; Alan Ford
>> Cc : multipathtcp@ietf.org
>> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>> 
>> Hi all,
>> 
>> first, I agree with Alan that such a signal does not need to/should not be
>> part of the MPTCP protocol.
> 
> [Med] Defining another channel to carry the signal "I want to be MPTCP-proxied" outside the MPTCP normal channel will import the same set of hindrances we had with MPTCP design for middlebloxes traversal. The use of MPTCP to convey the "I want to be MPTCP-proxied" leverages on base MPTCP to detect "unfriendly MPTCP" in-path nodes. That's a pragmatic engineering design. 

The MP_CONVERT signal has multiple purposes. When signalled with a target IP address in explicit mode, it is a pure application-layer signal, and is separate from the MPTCP connection entering the MCP.

In implicit mode this is indeed at a slightly different layer, and yes, you are asking the network to do something. But it’s still not a necessary part of the MPTCP protocol to make this happen. This is similar to a transparent HTTP proxy, or to a NAT - neither requires any changes to HTTP or TCP/IP to work.

You could detect MPTCP SYNs and see if your signal is present. If you don’t want to be inspecting every MPTCP SYN in implicit mode, use an existing standard - I suggest RAO. Given this is a controlled environment, you shouldn’t have any deployment concerns here.

If RAO is not appropriate for some reason, I might be persuaded that a flag in the MP_CAPABLE that says “proxies should inspect this” could be added to the base protocol. However, the rest of the protocol - i.e. the MP_CONVERT signal - is application-layer and outside MPTCP.

Ultimately MPTCP Proxying is an application of MPTCP and should be defined as such.

Regards,
Alan