Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <alan.ford@gmail.com> Fri, 04 November 2016 16:43 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 8F8DB129469 for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 09:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 kOeO7e7JXTIL for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 09:43:20 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 C501A1295B0 for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 09:43:19 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id a197so62528305wmd.0 for <multipathtcp@ietf.org>; Fri, 04 Nov 2016 09:43:19 -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=VCOYMMI5G01zzmPzdEuDr9f6smrJsa+j5UVWZZCdwG0=; b=KlVyCbrUz4sLqyDSLK03KF26uD4T32lpr+lf730IDZ7nWy1RvbYEd+P7ect+Sv7UQ9 a2k1hSMl4nTsNkLyU7Kb4nSDY0szsvlEKMWI8blXImL1YmyZe0EszYl8mZJRZBbYXk07 IPqzNHeZa1ShRhqJKfvmmVVy2Fn2VgUa7+MYIWHOIV7enwEa/cmqF/H5vC32mxDO0Pov wA2DGCux2ZU8hFNF+JXUVAlbD3r2O5dvpik0FjCnO1VB2G2O/QWMpfYT+jwEkpDrheca SjsGgCjhZaTBkacdouMyDp8eQzR90/Tz1ehJRvtxpcpjKSjdomfrOVtSM1UKOGQlK2/I HTQQ==
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=VCOYMMI5G01zzmPzdEuDr9f6smrJsa+j5UVWZZCdwG0=; b=c+XuzHCzkjrnKswu/onvRLvzp0D1xDHmhXX6zj7ojesFUP8rZNjgei5SAipehvGpzd qWSWXdGfoeP+QMROQd1TVdrbkLVEXetb1prLpmNr+yR3PWgXQxIIcb2wdIKVqt+5t3i0 AJBt74ghRgiSmcuXrWUzlll6j46ULd9n9daBtJhMfB4sEA5aFLiC8ZAA9xequGnfFEFH rpuv8VQLW6ZtoK0LfzpHa6xEB1x/qdU45bYQvWmcuos+S9MaqkINcJBTXepmQXKRtMdv 324mbkwVH5I/ghUXeawJw4Gg4zfVlhMcWzHVccc9d0xH0MPeyfFcUz09nFtX6BXd2yN8 PvGg==
X-Gm-Message-State: ABUngveOQIa7ip90BeqiE6s+VvfzV125R72JVEguPZ5VlfPJpPbXrxYvSMOdnGdJPC4bEA==
X-Received: by 10.28.170.204 with SMTP id t195mr4097979wme.113.1478277798232; Fri, 04 Nov 2016 09:43:18 -0700 (PDT)
Received: from alans-mbp.lan ([37.152.254.14]) by smtp.gmail.com with ESMTPSA id vf8sm15103221wjc.27.2016.11.04.09.43.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Nov 2016 09:43:17 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_52266E44-3A41-4967-B516-CB560BE32DC5"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DACA51@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Fri, 04 Nov 2016 16:43:16 +0000
Message-Id: <B30C83B3-F83E-4111-8D56-AD40CFEF1C4D@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> <e81c001b-ba6b-2990-9a62-09622e1339e1@uclouvain.be> <ACE6C987-A8AD-477B-986C-CFB4A438323F@gmail.com> <8074e8da-71ba-633d-dd67-6fc37adf19e5@uclouvain.be> <E9ECBC32-A8F1-4C9A-9D26-A3FF64C815FA@gmail.com> <787AE7BB302AE849A7480A190F8B933009DACA51@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/AwBi_K500ELPQekXx2NorPfoOl4>
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 16:43:22 -0000

Err, exactly the way you’re proposing doing it today. In the TCP payload. Just don’t pretend it’s an MPTCP option when it’s not.

I was hoping that when these drafts were merged there would be a single desired deployment model, but it seems not. Explicit mode and Implicit mode are very different. Explicit mode is a proxy solution purely at the application layer and is not MPTCP-specific. You signal to a proxy - which is expecting it - information in the payload to define where the data is to be proxied on to.

The problem seems to be for implicit mode only. And more than that, it’s for implicit mode between two MCPs. I.e. scenario 3 in your document.

Looking again at the implicit mode scenario, in draft-nam-mptcp-deployment-considerations-00.txt, you have a case of a host (H1) which sends data to the far end; this is intercepted by the MCP, sent on as TCP-only, and the MCP inserts its own addresses. This does not need any additional signals to operate.

You later raised a scenario in an email which is not specifically stated in the document - one where you have TCP -> MCP1 -> MPTCP -> MCP2 -> TCP and you need to know if it’s come from another MCP or from the endpoint. Only data coming from MCP1 should be proxied. And MCP1 does not know about MCP2 so cannot address it directly.

But normal implicit mode operation would still work here, wouldn’t it? MCP2 could blindly add itself to the path in all cases. Does it actually matter if the MPTCP is coming from MCP1 or the end host?

Your email described a desire not to revert to TCP after MCP2 if the end host, rather than MCP1, had sent the MPTCP signalling. But surely that problem would go away if you decided to proxy based on the far end’s MPTCP capability - i.e. on the SYN/ACK, not the SYN?

I came into this email thinking I’d finally understood the scenario where a signal is required, but I’m now confused again. Please help me understand here!

Regards,
Alan

> On 4 Nov 2016, at 15:55, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
> 
> Re-,
>  
> If not an MPTCP option, which channel you would use to pass in-band some information between two MPTCP peers (client/proxy, proxy/proxy) while allowing for variable data to be exchanged, multiple instances to be included, no interference with TFO, etc. AND ensure interoperability between MPTCP peers?
>  
> Cheers,
> Med
>  
> De : Alan Ford [mailto:alan.ford@gmail.com] 
> Envoyé : vendredi 4 novembre 2016 16:18
> À : Olivier.Bonaventure@uclouvain.be
> Cc : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
>  
> Hi Olivier,
>  
> On 4 Nov 2016, at 14:17, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be <mailto:Olivier.Bonaventure@uclouvain.be>> wrote:
> 
> 
> Thanks for the comments, Olivier. If the working group thinks it would be a good idea, I would not be opposed to embedding some extended options support in MPTCP - as you say it seems a good chance to do so. I haven’t thought deeply yet about the various options below, all have their merits, but the flag sounds possibly easiest. Whatever extension was used, it could be particularly useful in the future for improved cryptographic handshakes.
> 
> This does not change my view, however, that MPTCP options should not be used for application-layer purposes, and that’s my main issue with MP_CONVERT as written - it’s a non-MPTCP-specific application-layer signal masquerading as a MPTCP option.
> 
> It's clear that a proxy can be developed entirely as an application. SOCKSv5 is one example. The main drawback with SOCKS is that this adds several round-trip-times to each connection establishment to setup the proxy. With an option in the SYN, a proxy to operate with zero-rtt overhead. Reducing latency is an objective that is shared by other working groups, see e.g. TLS 1.3, QUIC and others...
>  
> One of us is clearly missing some key piece of information, since I still don’t know how we can be arguing something that seems so fundamentally clear to me.
>  
> This is a clear-cut application on top of MPTCP. In explicit mode, the application protocol is:
>  
> - a few bytes of signal that defines the real target address
> - followed by the proxied payload
>  
> I’m not saying “use SOCKS” - you have a proposal for a 0-RTT proxy signalling protocol here. That’s fine. But it’s not MPTCP-specific. Why are you trying to make it a MPTCP option?
>  
> As I said in the reply to Med, the implicit mode is slightly more difficult since you are expecting interception of MPTCP traffic based on some logic. That logic could be a “proxy alert” flag, or it could be inspection of all MPTCP SYNs’ payloads (data-on-SYN issues are probably not such big deal in your relatively controlled environments), or it could be using RFC 2113 RAO. It does not need to be an MPTCP option specific to this extension.
>  
> Regards,
> Alan