Re: [multipathtcp] Consensus call on potential MPTCP proxy work

<mohamed.boucadair@orange.com> Tue, 18 April 2017 14:30 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 02DF2128B44 for <multipathtcp@ietfa.amsl.com>; Tue, 18 Apr 2017 07:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 YWV59dHoSmg3 for <multipathtcp@ietfa.amsl.com>; Tue, 18 Apr 2017 07:30:17 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B168131809 for <multipathtcp@ietf.org>; Tue, 18 Apr 2017 07:30:17 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 32F6E1204E2; Tue, 18 Apr 2017 16:30:15 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 05144180077; Tue, 18 Apr 2017 16:30:15 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0319.002; Tue, 18 Apr 2017 16:30:14 +0200
From: <mohamed.boucadair@orange.com>
To: Joe Touch <touch@isi.edu>, "philip.eardley@bt.com" <philip.eardley@bt.com>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSuEf/fdYfWY1wG0WtXqHcvFS6GqHLI5rg
Date: Tue, 18 Apr 2017 14:30:14 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E4FBB2@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu>
In-Reply-To: <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E4FBB2OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/ZHYY7d2wiKNrRvphFz1R78h1Omc>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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, 18 Apr 2017 14:30:21 -0000

Hi Joe,

Some comments from my side :


·         The main target use case is a CPE that is connected to many networks (cellular and fixed, typically). Please refer to https://www.ietf.org/mail-archive/web/banana/current/pdfwmOoFT30Eh.pdf for more business drivers.

·         In order to enhance resilience and increase resource pooling, the CPE is MPTCP-capable.

·         Because of the lack of MPTCP support at the servers side, a proxy is introduced at the network side to assisted MPTCP connections of that CPE. Let's call this proxy: network-located proxy.

·         Because the network provider does not control hosts that are located behind a given CPE, a proxy is enabled on the CPE to transform some TCP connections into MPTCP ones.

·         The CPE is configured with its network-located proxy by means of DHCP, for example.

·         As mentioned in Phil's text, the proxies are both under the control of the operator. In particular, ** both ** the CPE and the network-proxy support the mechanism detailed hereafter (that is parse and strip any supplied data before forwarding upstream).

·         There is no tunnel/encapsulation at all. As such there is no ** TCP over TCP ** scheme. All is about plain transport mode.

o    The CPE forwards MPTCP connections it creates to its configured network-located proxy. This is exactly the same as with the data plane of SOCKS.

o    In order to inform its proxy about the ultimate destination IP address/port while ensuring 0-RTT, an information element is inserted in the payload of the SYN message of the initial subflow.

o    That information is stripped by the network-located proxy before forwarding the packet to its ultimate server.

o    In order to strengthen the solution, that information must be echoed by the proxy in the SYN/ACK as a guard against misconfigured proxies.

o    The information echoed in the SYN/ACK is used by the CPE to double check that the network-proxy complies with the solution. If not, no further MPTCP connection is established with that proxy till a TTL expires or a new proxy is configured.

o    More details can be found at https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

So:

·         "(TCP over TCP), which I already noted in previous discussion." WAS NEVER proposed.

·         The proposal does not "interfere with MPTCP's ability to silently fall-back to TCP when talking to legacy endpoints". Legacy endpoints that receive an MP_CAPABLE option (whether from an MPTCP-capable client or via a proxy) will ignore it and silently fall back to TCP. I don't see a problem here.

Cheers,
Med

De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de Joe Touch
Envoyé : mardi 18 avril 2017 15:30
À : philip.eardley@bt.com; multipathtcp@ietf.org
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work


Hi, all,

The description below isn't sufficient to determine whether this work is either needed or safe.

My initial conclusion is that this work is either (a) not needed at all, (b) out of scope, or (c) involves one if not two very bad ideas.

I have a few questions that determine which of (a), (b), or (c) apply (below), but I've already commented on my concerns that conclude (c) *based on previously assuming this was intended as an IP tunnel and used an option with control plane info in the SYN data) so I won't repeat them.

I am curious as to what's really intended here, though.

Joe

1) what is the reason for needing MPTCP work to support proxy-proxy use? True proxies are applications and can already setup MTCP themselves. Protocols for operators to configure proxies seem out of scope here. And if this "proxy" path is really an IP tunnel, that's a very bad idea (TCP over TCP), which I already noted in previous discussion.

2) what does "using the payload...to transfer a signalling message" mean? Are you using the MPTCP control plane? or the data plane of the MPTCP connection?

3) I'm not sure I fully understand the details of the optinns, but I understand that at least one of them puts data in the SYN that is interpreted as something other than TCP data (i.e., control plane). That is also a very bad idea - it interferes with MPTCPs ability to silently fall-back to TCP when talking to legacy endpoints, and the reasons for not using TCP data as control are discussed in draft-ietf-tcpm-tcp-edo, Section 8.7 (and are the reason for draft-touch-tcpm-tcp-syn-ext-opt), which I also already noted in previous discussion.
On 4/18/2017 1:17 AM, philip.eardley@bt.com<mailto:philip.eardley@bt.com> wrote:

Hi,
During the MPTCP meeting in Chicago we did several hums about potential MPTCP proxy work. Our interpretation of these hums is that we should do a consensus call for the following work:
--
MPTCP is now seeing widespread deployment in networks to bond together two accesses, such as fixed and mobile broadband, by using two MPTCP proxies, one in the home gateway or Customer Premises Equipment and one in the network. The WG develops a solution where the proxies are both under the control of the operator and where it is assumed that they are not on the default path. The solution is based on using the payload of an MPTCP packet to transfer a signalling message between the proxies. It is believed the solution will not require changes to RFC6824bis. The solution may require a means of configuring set-up information in the proxies, which would be done in coordination with other IETF WGs such as DHC. The WG does not develop a mechanism for the two proxies to discover each other.
--
Please say whether you support, or don't support, such work - so we can see if there's consensus for it.
Thanks
Phil & Yoshi

Hums during the meeting:

*         Should the MPTCP WG do any MPTCP proxy work, or do none - about 2:1 or 3:1 in favour of doing work

*         Should the MPTCP WG do proxy work based on option #1 in slide 12? Strongly more yes than no

*         Should the MPTCP WG do proxy work based on option #2 in slide 12? more no than yes

*         Should the MPTCP WG do proxy work based on option #3 in slide 12? Weak & roughly equal
Ref: https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-chairs-01.pdf
We believe the work does not require an update to the MPTCP WG charter.





_______________________________________________

multipathtcp mailing list

multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>

https://www.ietf.org/mailman/listinfo/multipathtcp