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

Tommy Pauly <> Thu, 04 August 2016 00:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D706126D74 for <>; Wed, 3 Aug 2016 17:10:13 -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 mhXjAkaP2hSR for <>; Wed, 3 Aug 2016 17:10:11 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DF9A12D8E0 for <>; Wed, 3 Aug 2016 17:10:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1470269409; x=2334183009; 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=wN6/ISbbugt9jjlp5BT8th5ASRNFNpPIGiNtXapk594=; b=DsYiJEBbyVFEy9PSf2Mka/BjkdBlgqwLgkq4jZJ2Yyo2f2fD5ePY4hLmKJyInPpB IeJOFzuqrJfWXdfCctefYy4d6OS2ivpPgcblqgrPuuABa3rlGoAdGEvdvA+X/uke MFMSpXdeWR0TrSAjP8Q7HF53uHZY2ErRN33fe6AqZoE8J7kvKt69b4942XN7DJbW 2pOSIgAvF8yUirA32zrSalkgyJyh7uvNKTnaU5v/C0CDTJqs87nixLXsN6KUjmXb W3SOQMnvB61A3SrN8rwlcYYoscUVGGoKd7im8YSRefXuGxXN4f7RN6JYs5VtjUvF 1tOebmfvcaJwytOZdyRJUA==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 63.0F.10360.1E782A75; Wed, 3 Aug 2016 17:10:09 -0700 (PDT)
X-AuditID: 11973e11-f79e76d000002878-ea-57a287e18fc4
Received: from ( []) by (Apple SCV relay) with SMTP id 50.94.01452.1E782A75; Wed, 3 Aug 2016 17:10:09 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_utUjyEuWq/Q8LulkBIHKwQ)"
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Jun 15 2016)) with ESMTPSA id <>; Wed, 03 Aug 2016 17:10:09 -0700 (PDT)
From: Tommy Pauly <>
Message-id: <>
Date: Wed, 03 Aug 2016 17:10:09 -0700
In-reply-to: <>
To: "Henderickx, Wim (Nokia - BE)" <>
References: <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3195)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUi2FDorPuwfVG4wZYefouV51YwW3xefZ3N YtLvTSwOzB47Z91l91iy5CeTx91bl5gCmKO4bFJSczLLUov07RK4MrrO/GAtWL6OsWLHyfOM DYwPpjJ2MXJySAiYSGy+84sZwhaTuHBvPVsXIxeHkMBeRom151tZYYq23uhmhEgcYpS4seYs WDevgKDEj8n3WEBsZoEwie+rJzJBFHUwSZzs3svexcjBISwgIbF5TyJIDZuAisTxbxuYQcK8 AjYS5y8WgYSFBXwkOq5MAxvDIqAqMf36YXYQm1PAVqJ3bQ8TzPgfvefB7hEBin+beArq0I8s Eqe7/0J9Iysx988bsEMlBG6zSax6u5N1AqPwLCS3zkJy6yygO5gF1CWmTMmFCGtLPHl3gRXC VpNY+HsRE7L4Aka2VYxCuYmZObqZeUZ6iQUFOal6yfm5mxhBsTPdTnAH4/FVVocYBTgYlXh4 N0guChdiTSwrrsw9xCjNwaIkzht+akG4kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYj9ssH AgtY39z4fE9cf9b6iQGnPzVkmy1JvaLfOpfPNfCevcq1Ox/3/Hg0PcNb5Ij4Y3nBrbt60ztD X/q0/JCw7E3kLr5rWve4/8admuizP+XYNj0K5XNafuZcRGVwvJHL79laad93H3Za/eIvz8I4 uXV7+9zftfWL9vzhtF/4RdA+lqnwXKgSS3FGoqEWc1FxIgApzeD9fgIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUi2FB8Rvdh+6Jwg0vnOSxWnlvBbPF59XU2 i0m/N7E4MHvsnHWX3WPJkp9MHndvXWIKYI7isklJzcksSy3St0vgyug684O1YPk6xoodJ88z NjA+mMrYxcjJISFgIrH1RjeULSZx4d56ti5GLg4hgUOMEjfWnAVL8AoISvyYfI8FxGYWCJP4 vnoiE0RRB5PEye697F2MHBzCAhISm/ckgtSwCahIHP+2gRkkzCtgI3H+YhFIWFjAR6LjyjSw MSwCqhLTrx9mB7E5BWwletf2MMGM/9F7nhXEFgGKf5t4CuqejywSp7v/Qh0qKzH3zxvGCYwC s5CcNwvJebOAVjMLqEtMmZILEdaWePLuAiuErSax8PciJmTxBYxsqxgFilJzEiuN9BILCnJS 9ZLzczcxgkO90HkH47FlVocYBTgYlXh4N0guChdiTSwrrswFhhEHs5II791WoBBvSmJlVWpR fnxRaU5q8SHGiYxAX05klhJNzgdGYl5JvKGJiYGJsbGZsbG5iTkthZXEeROPzw8XEkhPLEnN Tk0tSC2COYqJg1OqgbFwZuFO2UNhi6dbzNjILX45/WHYpZTpEo8+tTFeF8n6ucC2a3Eew5GQ SSdfLVEpe/LN33+70r4li1oarx4MqPH0+tp8/UMYb+ySg81RGx4asrJGN7yafuDrs6QVzaL2 Hqr9PP1HfynMjP3SEWDVGGd4nFtCtFrzgdFjpf1sj8r8pGwP7v7UMFOJpTgj0VCLuag4EQBG 6wT56AIAAA==
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: Thu, 04 Aug 2016 00:10:13 -0000

> 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.

Tommy Pauly

> Regards,
> Alan
> _______________________________________________
> multipathtcp mailing list