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

Christoph Paasch <> Thu, 04 August 2016 04:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2205A12D1C7 for <>; Wed, 3 Aug 2016 21:32:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.378
X-Spam-Status: No, score=-5.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gUbYy56Rukdg for <>; Wed, 3 Aug 2016 21:32:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4C3512D0D9 for <>; Wed, 3 Aug 2016 21:32:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1470285166; x=2334198766; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QwjiwnrLOKx3gcpM2KWPvuMM/jrsJ7R9bAKupZlEumY=; b=3MMbSYuSqy/iVchwquZkgh75RD5r6GZE9WVUcYCYNUeKbhdVnOnTiajVmaAOr/La Vs2IeIl1XC3bVtA2fLm0NBje75f0Fv9wRCPc/ir1810nxm+4Eytg98CNxi9buW8F roPp0NKm4XkFDw8fat6clUecC2Z0am6IzEhbOC0vopKRgveCQnSI0x0mumppogH4 m8rYQUYWR6fNWuDz871XDNoUJtlgqjuvj4NnFy+WLhejNLauoQDDrLQSp0x4QR9R zCfj99k4MVSM/sJJ20sOBAscnKAG04UgRU/BH35SojUqVkz/EhbJO3GtDUeyiFcM er+oYRyFx/7xbDotki5d5A==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 1E.83.10360.E65C2A75; Wed, 3 Aug 2016 21:32:46 -0700 (PDT)
X-AuditID: 11973e11-f79e76d000002878-0a-57a2c56e96e7
Received: from ( []) by (Apple SCV relay) with SMTP id CC.B9.31551.E65C2A75; Wed, 3 Aug 2016 21:32:46 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_oE/jTsJWtD5rsuNOeetdkw)"
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built May 17 2016)) with ESMTPSA id <>; Wed, 03 Aug 2016 21:32:46 -0700 (PDT)
From: Christoph Paasch <>
In-reply-to: <>
Date: Wed, 03 Aug 2016 21:32:46 -0700
Message-id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Wim Henderickx <>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUi2FAYpZt3dFG4wcVl6hafV19ns5j0exOL A5PHkiU/mTzu3rrEFMAUxWWTkpqTWZZapG+XwJVx4IBVwfGrjBUXn2U1MD7extjFyMkhIWAi MXfqB1YIW0ziwr31bF2MXBxCAnsZJWat2c4CU7T98WN2EFtIYCOjxMzmGBCbV0BQ4sfke2A1 zAJhEru3r2WFaP7FKDH/+muwqcICkhLdd+4wQ9g+Eh1XpoE1sAloSby93Q5WwylgK3Fx6wWw OIuAqsTtj7PZIYaGSrQ/3cAEscxGYsfTg1ALrrNKPH40lw0kISKgK7H24DGod2QlnpxcxAJS JCGwgE3i4rTlrBMYhWchuXYWkmtnMXIA2eoSU6bkQoS1JZ68u8AKYatJLPy9iAlZfAEj2ypG odzEzBzdzDwjvcSCgpxUveT83E2MoCiZbie4g/H4KqtDjAIcjEo8vBskF4ULsSaWFVfmHmKU 5mBREucNP7UgXEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjrvuskE+7d59aOJ81yUiJacpu 4d0vMw6x/81oO9yb5ZnNPHHm5SAV6cviU+bYaH2V7Ty57NX8xKnGB44r3r5/9lLGnrezb014 vGtGEJOesMVTcb9avzWPYiLf/zIINpj3MTBddpGqlOnKtSUzP1x2KQ+WbWsPLzDXjKwoDH2v EdMwx4Q3IzpQiaU4I9FQi7moOBEARBBLnHMCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FDMr5t3dFG4waUWZYvPq6+zWUz6vYnF gcljyZKfTB53b11iCmCK4rJJSc3JLEst0rdL4Mo4cMCq4PhVxoqLz7IaGB9vY+xi5OSQEDCR 2P74MTuELSZx4d56NhBbSGAjo8TM5hgQm1dAUOLH5HssIDazQJjE7u1rWbsYuYBqfjFKzL/+ mhUkISwgKdF95w4zhO0j0XFlGlgDm4CWxNvb7WA1nAK2Ehe3XgCLswioStz+OJsdYmioRPvT DUwQy2wkdjw9CLXgOqvE40dzwS4SEdCVWHvwGNTVshJPTi5imcAoMAvJgbOQHDiLkQPIVpeY MiUXIqwt8eTdBVYIW01i4e9FTMjiCxjZVjEKFKXmJFaa6SUWFOSk6iXn525iBAd1YdQOxobl VocYBTgYlXh4N0guChdiTSwrrsw9xCjBwawkwstwGCjEm5JYWZValB9fVJqTWnyIUZqDRUmc N+H4/HAhgfTEktTs1NSC1CKYLBMHp1QD42zBf25bNzJaXDMXvbUg5/PFzic5E2XaDjjNSrmk IpHlvdHm8P/5LFd0Vi67VhXMdfHcaR+tOu/NXZc+T7mTqrfExOrMcXn9ayt11Dpk9CdY7nqT Idw1+27Yxk+Oi2Ni6zYv8z+07GnThvc/4rba/b6bGiYZmm3h/6E7snLxvv3XHWo6DKNmLlJi Kc5INNRiLipOBADUcWyPZgIAAA==
Archived-At: <>
Cc: MultiPath TCP - IETF WG <>
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: Thu, 04 Aug 2016 04:32:49 -0000


> On Aug 3, 2016, at 9:14 PM, Henderickx, Wim (Nokia - BE) <> wrote:
> From: < <>> on behalf of Tommy Pauly < <>>
> Date: Thursday 4 August 2016 at 02:10
> To: Wim Henderickx < <>>
> Cc: Alan Ford < <>>, " <>" < <>>
> Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
>> On Aug 3, 2016, at 11:58 AM, Henderickx, Wim (Nokia - BE) < <>> wrote:
>> Alan, in-line
>> From: Alan Ford < <>>
>> Date: Wednesday 3 August 2016 at 09:20
>> To: Wim Henderickx < <>>
>> Cc: Rao Shoaib < <>>, " <>" < <>>
>> Subject: Re: [multipathtcp] towards a potential work item on two-ended proxy
>> Hi Wim, all,
>> Comment inline...
>>> On 2 Aug 2016, at 20:11, Henderickx, Wim (Nokia - BE) < <>> wrote:
>>> On 02/08/16 15:52, "Alan Ford" < <>> wrote:
>>>> 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
>> OK, so my understanding appears correct here.
>> WH> yes
>>>> 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.
>> Which is the point of the signalling protocol - the proposed “plain mode option” which is actually carried in the payload. My issue with this is that this is _not MPTCP-specific_. This is simply a signal above the transport layer to inform a proxy what the real destination is.
>> WH> I hear, you and I understand but we have an explicit use case for this with MPTCP and so far not in any other protocol. Hence I think it is good to extend MPTCP with this capability and liase with other WG(s) about this.
> While you may have a use-case for having proxies work with your MPTCP solution, it does not directly follow that the MPTCP protocol or WG is the best place to specify how the proxy works. This really does seem like a proxy solution that can be made more generic, and at the very least belongs as a protocol that is run within the MPTCP stream. This is what the SOCKS protocol does, and there is no reason you can't run SOCKS over MPTCP, or create a new variant of SOCKS or a similar protocol that you will run on top of MPTCP for your solution. Indeed, it could be seen as a benefit to work on the proxying solution independently from MPTCP, since that way it can be used for other transports. The end result will be the same, and the architecture will be cleaner.
> WH> given the extension is specific in TCP?MPTCP since we carry the information in a SYN packet it becomes specific to the protocol and hence I still believe it fits.

The information is actually carried in the payload. So, it is not really part of TCP/MPTCP. Carrying it in the SYN is just because TCP does not prevent carrying data in the SYN-segment.

> Other transport mechanisms have other means and can adopt a similar information element but the way the protocol consumes it is specific and should be done in the protocol afais.

I disagree that the information is consumed by MPTCP. It is rather consumed by the application sitting right on top of MPTCP, because this is the one that is reading the data out of the MPTCP-stream and forwarding it over to final destination. And MPTCP itself is not really using the plain-mode option.

If you look at Socks v4, it is actually carrying the exact same information than the plain-mode option (besides the protocol-field). So, an implementation could easily put the Socks-client request in the SYN-payload. The proxy who receives that can then (after connecting to the final server) reply in the SYN/ACK with the Socks-server option in the SYN/ACK's payload. And from there on, the data will be forwarded from one side to the other.

This would be a low-overhead handshake for the proxy without the chatty overhead of Socks v5.