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

<> Fri, 21 April 2017 06:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2841612773A for <>; Thu, 20 Apr 2017 23:07:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hI730fYc6dn1 for <>; Thu, 20 Apr 2017 23:07:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00684127599 for <>; Thu, 20 Apr 2017 23:07:33 -0700 (PDT)
Received: from (unknown [xx.xx.xx.69]) by (ESMTP service) with ESMTP id 57800C0355; Fri, 21 Apr 2017 08:07:32 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by (ESMTP service) with ESMTP id DD2DA208E1; Fri, 21 Apr 2017 08:07:31 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0319.002; Fri, 21 Apr 2017 08:07:31 +0200
To: Juliusz Chroboczek <>
CC: "" <>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSuhERFYN3Pf6Ey0Kw29UUSw2QvaHPTV8w
Date: Fri, 21 Apr 2017 06:07:31 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E51D1E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <> <787AE7BB302AE849A7480A190F8B933009E5041F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E50F4A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009E515E7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Apr 2017 06:07:35 -0000

Hi Jaliusz,

Please see inline. 


> -----Message d'origine-----
> De : Juliusz Chroboczek []
> Envoyé : jeudi 20 avril 2017 22:03
> Cc :
> Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work
> >>> What I meant by "native MPTCP connections" is that the CPE won't proxy
> >>> a SYN that contains MP_CPABALE received from an MPTCP-capable
> >>> client. That is, the CPE won't modify the destination IP address to
> the
> >>> one of the network-located proxy. That SYN+MP_CPABALE will be received
> >>> and handled directly by the remote server.
> >> It will still act as a middlebox, though, with no way for the client to
> >> avoid it.
> > No. This is not true.
> > Connections that are not eligible to network-assisted MPTCP service
> > WON'T involve a proxy.
> I've probably missed something, then.  I don't see anything in -10 that
> says that non-eligible packets are forwarded statelessly without any
> modification, including forwarding unknown IP and TCP options.

[Med] Two comments here: 

* We don't touch/alter existing IP/TCP options/EHs for ** both ** eligible and non-eligible flows. This is something we will call out explicitly in the document to avoid misinterpretation. We are adding MPTCP options at the TCP option level and MP_CONVERT IE in the first SYN.  That's all. 

* The document is focusing more on "what we are doing" not "what we are not doing". It says for instance: 

   Any data that is eligible to be transported over the MPTCP connection
   is sent by the Client towards the MCP over the MPTCP connection.  The
   MCP then forwards these data over the regular TCP connection until
   they reach the server.  The same forwarding principle applies for the
   data sent by the Server over the TCP connection with the MCP. 


   Any data received by the upstream MCP over the upstream TCP
   connection will be forwarded by the MCP over the bound downstream
   MPTCP connection, assuming such data are eligible to MPTCP transport.
   The same applies for data received over the downstream MPTCP
   connection which will be forwarded by the upstream MCP over the
   upstream TCP connection.

So, other flows will be processed following any default forwarding behavior in place: that default may be NAT44, IPv4-in-IPv6 encap without NAT (DS-Lite), IPv4-in-IPv6 encap with port-restricted NAT (MAP-E, lw4o6), CLAT (464xlat), IPv4/IPv6 translation (MAP-E), ....

The text will be updated to call this out.       

  All I see
> on the subject is Section 4.3 paragraph 2, which I find hardly reassuring.
> My gut feeling is that either the proxy is implemented at the upper
> layers, in which case it terminates all connections and hence discards any
> unknown options, or it is implemented at a lower layer, allowing it to
> bypass selected packets, in which case it is no longer a mere upper layer
> proxy.  I just don't see how you can have it both ways.
> Could you please explain what I'm missing?

* This is an MPTCP proxy that does not need to understand IP/TCP options that are carried in the original SYN. 
* The proxy located at the network side does only process packets that are destined explicitly to it (i.e., DST@ of the packet==proxy@). 
* Packets that are not eligible to MPTCP-assisted service, will be forwarded without involving a proxy. 
* Even if that proxy is embedded in a device that is on a default forwarding path, the proxy won't intercept those packets because the destination address != proxy@. 

> -- Juliusz