Re: [multipathtcp] towards a potential work item on two-ended proxy

"Henderickx, Wim (Nokia - BE)" <> Tue, 02 August 2016 19:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3AF312D8C6 for <>; Tue, 2 Aug 2016 12:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dz6nQgD6auVQ for <>; Tue, 2 Aug 2016 12:14:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C8A412D8F0 for <>; Tue, 2 Aug 2016 12:14:58 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id AA197EED3C392; Tue, 2 Aug 2016 19:14:52 +0000 (GMT)
Received: from ( []) by (GMO-o) with ESMTP id u72JEsw1023306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2016 19:14:55 GMT
Received: from ( []) by (GMO) with ESMTP id u72JE7WM000519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Aug 2016 21:14:38 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 2 Aug 2016 21:11:13 +0200
From: "Henderickx, Wim (Nokia - BE)" <>
To: Alan Ford <>
Thread-Topic: [multipathtcp] towards a potential work item on two-ended proxy
Thread-Index: AQHR6/78+H5KVobs2E61DPJLQEiUPaA0T3oAgAAn1gCAARlmAIAAeo6A
Date: Tue, 2 Aug 2016 19:11:12 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: nl-BE, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2016 19:15:01 -0000

On 02/08/16 15:52, "Alan Ford" <> wrote:

>Hi all,
>> On 1 Aug 2016, at 20:05, Henderickx, Wim (Nokia - BE) <> wrote:
>> On 01/08/16 20:42, "Rao Shoaib" <> wrote:
>>> On 08/01/2016 07:13 AM, Henderickx, Wim (Nokia - BE) wrote:
>>>>> Why is it necessary to know that the connection has been proxied ?
>>>> WH> Otherwise the concentrator will perform the proxy function although the destination is the application server.
>>>> So assume an E2E MPTCP flow. The UE initiates it and the element with the network assisted MPTCP proxy (Concentrator) receives it. The concentrator should not proxy this flow. It should only act upon MPTCP flow that should be proxied in network assisted mode. This is the reason we need an indication about this
>>> This seems like a deployment issue not a protocol issue. The decision to 
>>> proxy or not proxy should be based on the IP addresses or out of band 
>>> signaling. After all the entity adding the option some how knows to add 
>>> the option.
>>> I liked the initial proposal as it did not require any changes to the 
>>> protocol. These change (as I have said before) seem very deployment 
>>> specific and IMHO should not be part of the protocol.
>> WH> I would disagree since you don’t always control the addressing and it is better to have an explicit signaling in the protocol what to expect to happen.
>I’m trying to distinguish the various use cases; can we confirm this is correct?
>Transparent Mode
>- Source address = real source address
WH> not always since NAT can be in the path
>- Destination address = real destination address
>- Transparent proxies create MPTCP functionality in the stream, adding and removing the MPTCP headers, mapping seq numa, etc
>- Latest proposal is to add an indicator to say “this is proxied” so that a proxy can intercept it
WH> indeed or not intercept it based on the indication
>Plain Mode
>- Source address = real source
WH> could also be NATed in some use cases
>- Destination address = proxy destination address
>- Signalling protocol inside indicates real destination address
WH> or SRC address
>So - please correct me if this is wrong - but the main difference is that Plain Mode is targeted towards a proxy server whereas the transparent mode does not change src/dst addresses?
WH> the main difference is mainly DST IP is changed to get explicit routing to the proxy versus being implicit in the transparent case
>The issue I see with a generic proxy bit is that it does not contain any context about what kind of proxy is being intercepted. You could be sending in good faith expecting it to be picked up by Proxy from Operator A, but in fact is picked up by Operator B.
WH> the network assisted proxy is mainly targeting single operator/controlled operator use cases to avoid these issues.
>As I’ve said before, the plain mode option is not MPTCP-specific and is simple a signal that says “everything that follows is actually targeted for IP address a.b.c.d” - this is entirely transport-agnostic. If the HAG could know where to find a proxy (e.g. a well-known anycast address) then addresses could be rewritten and packets forwarded, with no need for any MPTCP protocol changes.
WH> you would still need to know the original destination IP@ that the application wanted to go to.
>However, I fear I may be misunderstanding some of the elements here, so I look forward to a consolidated draft where it should hopefully be much clearer what the proposal is.
WH> hope some answers clarify