Re: [multipathtcp] potential MPTCP proxy charter item

<> Fri, 04 November 2016 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D65E12945E for <>; Fri, 4 Nov 2016 08:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.096
X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wg7dLsCc5AM7 for <>; Fri, 4 Nov 2016 08:55:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51E2512943C for <>; Fri, 4 Nov 2016 08:55:27 -0700 (PDT)
Received: from (unknown [xx.xx.xx.66]) by (ESMTP service) with ESMTP id 2A56620693; Fri, 4 Nov 2016 16:55:26 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by (ESMTP service) with ESMTP id F131A12006E; Fri, 4 Nov 2016 16:55:25 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0319.002; Fri, 4 Nov 2016 16:55:25 +0100
To: Alan Ford <>, "" <>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSNq6d51vUSjsiZkKqseB+xOXO0qDI+J0g
Date: Fri, 04 Nov 2016 15:55:24 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DACA51@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <> <787AE7BB302AE849A7480A190F8B933009D945B7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <> <> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.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_787AE7BB302AE849A7480A190F8B933009DACA51OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
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: Fri, 04 Nov 2016 15:55:29 -0000


If not an MPTCP option, which channel you would use to pass in-band some information between two MPTCP peers (client/proxy, proxy/proxy) while allowing for variable data to be exchanged, multiple instances to be included, no interference with TFO, etc. AND ensure interoperability between MPTCP peers?


De : Alan Ford []
Envoyé : vendredi 4 novembre 2016 16:18
À :
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Olivier,

On 4 Nov 2016, at 14:17, Olivier Bonaventure <<>> wrote:

Thanks for the comments, Olivier. If the working group thinks it would be a good idea, I would not be opposed to embedding some extended options support in MPTCP - as you say it seems a good chance to do so. I haven’t thought deeply yet about the various options below, all have their merits, but the flag sounds possibly easiest. Whatever extension was used, it could be particularly useful in the future for improved cryptographic handshakes.

This does not change my view, however, that MPTCP options should not be used for application-layer purposes, and that’s my main issue with MP_CONVERT as written - it’s a non-MPTCP-specific application-layer signal masquerading as a MPTCP option.

It's clear that a proxy can be developed entirely as an application. SOCKSv5 is one example. The main drawback with SOCKS is that this adds several round-trip-times to each connection establishment to setup the proxy. With an option in the SYN, a proxy to operate with zero-rtt overhead. Reducing latency is an objective that is shared by other working groups, see e.g. TLS 1.3, QUIC and others...

One of us is clearly missing some key piece of information, since I still don’t know how we can be arguing something that seems so fundamentally clear to me.

This is a clear-cut application on top of MPTCP. In explicit mode, the application protocol is:

- a few bytes of signal that defines the real target address
- followed by the proxied payload

I’m not saying “use SOCKS” - you have a proposal for a 0-RTT proxy signalling protocol here. That’s fine. But it’s not MPTCP-specific. Why are you trying to make it a MPTCP option?

As I said in the reply to Med, the implicit mode is slightly more difficult since you are expecting interception of MPTCP traffic based on some logic. That logic could be a “proxy alert” flag, or it could be inspection of all MPTCP SYNs’ payloads (data-on-SYN issues are probably not such big deal in your relatively controlled environments), or it could be using RFC 2113 RAO. It does not need to be an MPTCP option specific to this extension.