Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <alan.ford@gmail.com> Wed, 09 November 2016 08:04 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 B8356129660 for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 00:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 isZ1WSrbOGNA for <multipathtcp@ietfa.amsl.com>; Wed, 9 Nov 2016 00:04:12 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 2316512963A for <multipathtcp@ietf.org>; Wed, 9 Nov 2016 00:04:11 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id b14so157831586lfg.2 for <multipathtcp@ietf.org>; Wed, 09 Nov 2016 00:04:11 -0800 (PST)
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 :content-transfer-encoding:message-id:references:to; bh=w2p9mu5gtef3One7u4DQYabFEgvRlhM05r6AL8F1WrE=; b=sI4tbE7qwgNtyylVPcRuj17jAJh7+HuD2MG9CZbsVUt6uPmrnu+AVhlj5EJ6vSV3Jq gFpVwbF3WCo1Xipo433yD3wy3H63gAkYIR7LBg+3jLayOoyNZgDgyi681AbALAwinZcY LoT3SS3P+HwS5/DhDmKh+CWQqunQU4ntfsQuPkHQB5En2/uuV64Ws89PVsivDGwjdZtm gHiGCDfRe1WqlNwquyJZsouvXknlqE9rNi0lb21gkFboCO2Prc0v/PucohVwpEdOR9Ir vXEPQLB0y06DuWnz4BkH4PNclO+EaysFxqGGnVjCgGAX1n6WI0YxlVLHOSokdM/skDnm hD6Q==
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 :content-transfer-encoding:message-id:references:to; bh=w2p9mu5gtef3One7u4DQYabFEgvRlhM05r6AL8F1WrE=; b=SlXkgY29FXIv3fABHoZGH95v02nTDOhSoc9GvYp4XNwOWvKd45RVHNQ/cKBmIgU44D f8WfSU/r2zdsXoDaswRMwffajYT4s4o/uqpehIGyq4TQKLe5IU/I5gYWasHFWaXXZT8M d3gLybCdVp2CPAVQWm1BZKEoSak35vwrEVcCy4Ve4fH0eil6fblZIJyJDrS4VcKHDasx pAjRV8topWadxW9R7vuJNh2HWO6Dos7kpid/dG2rFVATez3qIVV4dKvgf+4AIfFvd4tw WNBv482ACbIaxJI7j/FdRUbno4o4Oqh27uwOyJhcbw9WlNgmCM8WRZUKS7wwH8Pfu4wp v8dA==
X-Gm-Message-State: ABUngvcjnTEgletrXOSV7tZdKUou3ow9X9kWxEkDvnWGwwBFF30Ts7yh5sJD0/6lPrPVTg==
X-Received: by 10.25.135.130 with SMTP id j124mr9981536lfd.88.1478678649208; Wed, 09 Nov 2016 00:04:09 -0800 (PST)
Received: from [10.20.4.162] (162.38.92.62.static.cust.telenor.com. [62.92.38.162]) by smtp.gmail.com with ESMTPSA id p3sm6887002lfe.1.2016.11.09.00.04.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Nov 2016 00:04:08 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DAE743@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Wed, 9 Nov 2016 08:04:09 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <06A031EE-5F50-4A0F-BBEC-9F2766C543FF@gmail.com>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <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> <87270f12-59ee-3caf-eeef-685195b35dcd@uclouvain.be> <A5256E6E-E2BA-4763-AEF9-3CC50EB432A2@gmail.com> <7f9dd7ab-2e24-0319-b62f-fc4fa68b9568@tik.ee.ethz.ch> <787AE7BB302AE849A7480A190F8B933009DAE3A6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <A95CD4E7-6A3B-4622-A818-03B10AD75D4D@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAE743@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/c_LtOUnS1X-MppM4AsFc9DO1q10>
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: Wed, 09 Nov 2016 08:04:14 -0000

Hi Med,

Thanks for providing some scenarios. Comments inline…

> On 9 Nov 2016, at 06:41, mohamed.boucadair@orange.com wrote:
> 
> Hi Alan, 
> 
> Below some examples to illustrate the problem I'm talking about. 
> 
> (1) Private IPv4 addresses or RFC6598 Shared Address space
> 
> Let's consider this configuration (reusing the same topology in this thread): 
> 
> laptop <-----------+
>                   | (Public IPv4@)
> smartphone <----> cpe <----FIXED------> mcp <------> server
>     +             + 
>  cellular1     cellular2
>                (Private IPv4)
> 
> In this example, the multipath CPEs gets a public IPv4 address from the fixed network and a private IPv4 address (or an address from RFC6598 range) from the mobile network (cellular2).
> 
> Consider the server is MPTCP-capable. 
> 
> The first subflow can be placed using the fixed line. Fine.
> The MCP will remove itself from the connection because the server is MPTCP-capable. Cool!
> The second subflow that will use cellaulr2 cannot be established because of a basic forwarding problem: packets sourced with private IPv4 addresses cannot be forwarded over the public Internet. 

Presumably cellular2 goes through a NAT in order to talk to anything in the public Internet. So it can be addressed to the server, and work like any other MPTCP subflow behind a NAT would work today.

What am I missing? Why is this any different to today with a MPTCP end host with private IP addresses?

The smartphone does not have knowledge of cellular2, presumably… So the CPE would have to do something funky with the traffic to split it over fixed and cellular2 - but it could still establish the subflow towards the server on cellular2, without any knowledge of the smartphone or the network.

> 
> (2) IPv6-only access network
> 
> Lets' consider this configuration: 
> 
> laptop <-----------+
>                   | (Public IPv4@              
> smartphone <----> cpe <----FIXED------> mcp <------> server
>     +              +                                IPv4-only
>  cellular1     cellular2
>                (IPv6-only prefix)
> 
> In this example, the multipath CPEs gets a public IPv4 address from the fixed network and an IPv6 prefix from the mobile network (cellular2). 
> 
> Consider the server is MPTCP-capable, but IPv4-only. 
> 
> The first subflow can be placed using the fixed line. Fine.
> The MCP will remove itself from the connection because the server is MPTCP-capable. Cool!
> The second subflow that will use cellaulr2 cannot be added because the remote server does not support IPv6.
> 

So in this case, if the MCP was on-path, it could be dual-stack and could add its IPv6 address to the subflows.

If the MCP knew the connection was being proxied, would this help? Since as you’ve already defined, the MCP <—> server path would then be TCP. If the MCP stayed on-path, you could do multi path towards the MCP but then lose MPTCP capabilities to the server.

Or alternatively, the MCP could always stay on-path but only add IPv6 addresses if it somehow had knowledge that was required based on the source or destination address. Does it need to know by a flag? Would there actually be any harm by maintaining itself on the path anyway? It’s not like it’s doing anything other than packet forwarding on the initial subflow, and just adds its IPv6 addresses to the initial exchanges in case it would be useful - and if it receives traffic to the relevant address/port, it can start forwarding it to the far end too (possibly over a second IPv4 subflow). Again, no need or any explicit signalling to make this work.

> I can share other examples where problems arise when the proxy is blindly removed from the connection based on the presence of MP_CAPABLE in SYN/ACK. 

If it would help to clarify, please do! Since I don’t see a problem in (1), and whilst I can see a potential problem in (2) above, I am not sure how you are resolving it. Any other examples very welcome!

Best regards,
Alan