Re: [multipathtcp] potential MPTCP proxy charter item

Olivier Bonaventure <> Mon, 07 November 2016 08:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58424129BDD for <>; Mon, 7 Nov 2016 00:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qeJ7bgQXIRki for <>; Mon, 7 Nov 2016 00:00:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8785129B6A for <>; Mon, 7 Nov 2016 00:00:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 1B4B267DC5A; Mon, 7 Nov 2016 09:00:17 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 1B4B267DC5A
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1478505617; bh=mH83eM95i+Gvi313tznpgjfA7+QB6ndnioy3tOkKxGA=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=dfgAbStzDcgEN72Ptc1Az+INmw8xegnWCWAnkr0oR/n6eoCmMlhAL48tklZZGF5Uz MGWgVJxVMHYcN9yRk0ILvK9YVRWWk/JC410rdz8n0hW8PEU4CdzG4lPpdiLReHRVtq 23kYvonA5AQJSr7so7c5rLzA9Z+8NFCJJzEPklIU=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-2
References: <> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <787AE7BB302AE849A7480A190F8B933009DAC5DE@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <20161104181615.GP40488@Chimay.local>
To: Christoph Paasch <>,
From: Olivier Bonaventure <>
Message-ID: <>
Date: Mon, 07 Nov 2016 09:00:17 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20161104181615.GP40488@Chimay.local>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 1B4B267DC5A.A2CA5
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
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: Mon, 07 Nov 2016 08:00:27 -0000


>>> [Med] Defining another channel to carry the signal "I want to be MPTCP-proxied" outside the MPTCP normal channel will import the same set of hindrances we had with MPTCP design for middlebloxes traversal. The use of MPTCP to convey the "I want to be MPTCP-proxied" leverages on base MPTCP to detect "unfriendly MPTCP" in-path nodes. That's a pragmatic engineering design.
>> The MP_CONVERT signal has multiple purposes. When signalled with a target IP address in explicit mode, it is a pure application-layer signal, and is separate from the MPTCP connection entering the MCP.
>> In implicit mode this is indeed at a slightly different layer, and yes, you are asking the network to do something. But it’s still not a necessary part of the MPTCP protocol to make this happen. This is similar to a transparent HTTP proxy, or to a NAT - neither requires any changes to HTTP or TCP/IP to work.
>> You could detect MPTCP SYNs and see if your signal is present. If you don’t want to be inspecting every MPTCP SYN in implicit mode, use an existing standard - I suggest RAO. Given this is a controlled environment, you shouldn’t have any deployment concerns here.
>> If RAO is not appropriate for some reason, I might be persuaded that a flag in the MP_CAPABLE that says “proxies should inspect this” could be added to the base protocol. However, the rest of the protocol - i.e. the MP_CONVERT signal - is application-layer and outside MPTCP.
>> Ultimately MPTCP Proxying is an application of MPTCP and should be defined as such.
> I'm also late on this thread. But just want to reiterate what I already
> mentioned before in July.
> I also think that proxying between different transport-layer protocols is not
> an MPTCP-specific operation and as such should not be tied to MPTCP.
> Making it independent of MPTCP would be much better as it allows to proxy
> across any kind of transport protocol. So, let's just put it (as already
> suggested) in the payload, without linking it to MPTCP.

 From an architectural viewpoint, providing addressing information for a 
proxy is clearly outside the bytestream exchanged by the application. It 
is cleaner to place this control plane information inside options 
instead of messing up the bytestream and changing the first few bytes of 
each connection. I think that we should have a clean separation between 
the control plane and the data plane in MPTCP. We already use options to 
carry addressing information related to the endhosts (ADD_ADDR, 
REMOVE_ADDR), the addresses required by the proxy are the same type of 
information and they should also be exchanged as TCP options. Encoding 
them in the payload would likely create more problems in the long term.