Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Wed, 09 November 2016 06:41 UTC

Return-Path: <mohamed.boucadair@orange.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 11DF41294C5 for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 22:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.097
X-Spam-Level:
X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 AOq-cUbONSLo for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 22:41:24 -0800 (PST)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327E8129430 for <multipathtcp@ietf.org>; Tue, 8 Nov 2016 22:41:24 -0800 (PST)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 9E112A010E; Wed, 9 Nov 2016 07:41:22 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 742321C0076; Wed, 9 Nov 2016 07:41:22 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Wed, 9 Nov 2016 07:41:22 +0100
From: mohamed.boucadair@orange.com
To: Alan Ford <alan.ford@gmail.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSOdkznemdljzUmEGiGID3gGUCC6DQL2Qg
Date: Wed, 09 Nov 2016 06:41:21 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAE743@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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>
In-Reply-To: <A95CD4E7-6A3B-4622-A818-03B10AD75D4D@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/JSZyKPHb5-FtBsIN3Xoz-kNgkqk>
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 06:41:26 -0000

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. 

(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.

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. 

Cheers,
Med

> -----Message d'origine-----
> De : Alan Ford [mailto:alan.ford@gmail.com]
> Envoyé : mardi 8 novembre 2016 17:00
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Mirja Kühlewind; Olivier.Bonaventure@uclouvain.be;
> multipathtcp@ietf.org
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Med,
> 
> > On 8 Nov 2016, at 15:32, mohamed.boucadair@orange.com wrote:
> >
> > The problem is that if the MCP blindly withdraws itself based on the
> server capabilities, MPTCP connections may not be established in some
> cases, e.g., private IPv4 addresses are assigned for some secondary access
> networks.
> 
> Could you walk me through this scenario? Despite Olivier’s and your
> diagrams I’m not following how this does not work. If the far end supports
> MPTCP, the secondary interface gets to the far end by its own route and
> joins the MPTCP connection. If the far end does not, then the MCP will
> have inserted its address in the MPTCP signalling, so the secondary
> interface could route to it directly too.
> 
> So in what scenario does this not work?
> 
> Regards,
> Alan