Re: [multipathtcp] Two proxy scenario (network proxy off path) - far end connection initiation?

<> Thu, 30 March 2017 20:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4613B124BFA for <>; Thu, 30 Mar 2017 13:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.395
X-Spam-Status: No, score=-5.395 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_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VdWWaRP1lGdJ for <>; Thu, 30 Mar 2017 13:04:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC193127B31 for <>; Thu, 30 Mar 2017 13:04:48 -0700 (PDT)
Received: from (unknown [xx.xx.xx.66]) by (ESMTP service) with ESMTP id 6BD5520557; Thu, 30 Mar 2017 22:04:47 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by (ESMTP service) with ESMTP id 0EFD0120055; Thu, 30 Mar 2017 22:04:47 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0319.002; Thu, 30 Mar 2017 22:04:46 +0200
From: <>
To: Yoshifumi Nishida <>, "" <>
CC: philip.eardley <>, multipathtcp <>
Thread-Topic: [multipathtcp] Two proxy scenario (network proxy off path) - far end connection initiation?
Thread-Index: AQHSqX9SBkIJGOc8m0WkzItjUXxyV6GtrEyg
Date: Thu, 30 Mar 2017 20:04:45 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E443FE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <787AE7BB302AE849A7480A190F8B933009E431BF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E443FEOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [multipathtcp] Two proxy scenario (network proxy off path) - far end connection initiation?
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: Thu, 30 Mar 2017 20:04:51 -0000

Hi Yoshi,

Please see inline.


De : Yoshifumi Nishida []
Envoyé : jeudi 30 mars 2017 12:59
À :
Cc : philip.eardley; BOUCADAIR Mohamed IMT/OLN; multipathtcp
Objet : Re: [multipathtcp] Two proxy scenario (network proxy off path) - far end connection initiation?

Hmm.  But, I am not very sure if we really need to think about this case at this moment.

It seems to me there are too many assumptions to make this work and
[Med] The tools to make this work are the same as for end-to-end MPTCP when firewalls, NAT64, DS-Lite AFTR, CGN, NPTv6, etc. are on the path.

it doesn't look very scalable (I'm not sure how to maintain such public IP address table)
[Med] PCP on the CGN is a deployment reality…

If we don't see strong demands to support this case, I think it might be better put aside it for the time being.
[Med] I’m neutral on this. Our proposal allows to cover both in/out connections with the same object (MP_CONVERT IE). If you don’t think that MPTCP should be symmetric, then the same conclusion will apply for proxyied connections.


On Thu, Mar 30, 2017 at 8:19 AM, Olivier Bonaventure <<>> wrote:
On 30/03/17 17:03,<> wrote:
If I get it right, the assumption here is that for a TCP connection initiated from the remote end point , the remote network proxy is on path.  (in the other direction we're assuming the remote proxy is off path, so seems a bit odd?)

This is related to the fact that if the downstream MCP operates in explicit mode, then it performs NAT. Typically, the MCP has a block of public IP addresses that it uses for the clients that it serves. All external packets destined to any of these addresses are routed to the MCP.
I think there's also the assumption that the local endpoint (in the home) has previously made a connection out which has instantiated state in the remote proxy. So in this scenario, when the TCP SYN from the remote end point hits the remote proxy, then the remote proxy knows which home gateway the other end is on. Or something like that - to be honest, I couldn't understand the slide /section of the draft.

There is an assumption that either there is a one-to-one mapping between the client addresses and the public addresses used by the MCP or the client has configured some port mapping rules, e.g. with PCP on the dMCP and the uMCP


multipathtcp mailing list<>