Re: [multipathtcp] potential MPTCP proxy charter item

Christoph Paasch <> Fri, 04 November 2016 18:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B7841295FF for <>; Fri, 4 Nov 2016 11:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Status: No, score=-5.799 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_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H1YCednagrwp for <>; Fri, 4 Nov 2016 11:16:16 -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 49C6D129600 for <>; Fri, 4 Nov 2016 11:16:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1478283376; 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=usiLBOOcNOwuUSTA4a7pkb/CgogqfV+bepGNiZQNmhQ=; b=oyez+HxjdcXobAxwRV3/eYwJD1f7pgzKVEI47D820WIwTVnZL7MxX5Yh/AC6E/3/ hF+x3qlpGllCHBOgUMCuucX40etLR9ZVvQqazJ/26rck74/EKU+gfP2QDgcHBGdL NtSeaL6lHxdTbKPl/AZqP6iNRpT6+v5uzD46Tnv0mhFgZgc4FUmiRadO3Bejy9up 0kThf7A2UVD0bU3Xpa04h0HBJaV6cTT+Zj7+vXq5qRbFxI9POqpp6zOnRLAk1Ce2 zpbkAXOMrMX72JKvIRV1D6htK6M/a1t3h66aq5hrq8n4DdCYPE/xK4YrSjrlXUo4 8wpUITdytlXfG0WWMpLmfQ==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 76.D5.16908.F60DC185; Fri, 4 Nov 2016 11:16:15 -0700 (PDT)
X-AuditID: 11973e15-8ada39a00000420c-69-581cd06f8f6c
Received: from ( []) by (Apple SCV relay) with SMTP id 7B.75.23613.F60DC185; Fri, 4 Nov 2016 11:16:15 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-disposition: inline
Content-type: text/plain; charset="utf-8"
Received: from localhost ([]) by (Oracle Communications Messaging Server 64bit (built Jun 15 2016)) with ESMTPSA id <>; Fri, 04 Nov 2016 11:16:15 -0700 (PDT)
Date: Fri, 04 Nov 2016 11:16:15 -0700
From: Christoph Paasch <>
Message-id: <20161104181615.GP40488@Chimay.local>
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> <>
In-reply-to: <>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi2FAYpZt/QSbCYNsMG4uV51YwWxx++5Td 4vPq62wOzB47Z91l91iy5CeTR8uzk2wBzFFcNimpOZllqUX6dglcGQuntbIXnBSpeD1ZqYHx skAXIyeHhICJRNPv32xdjFwcQgJ7GSWuPTzMDJP4d/YyK0TiEKPEmn3TWEESvAKCEj8m32Pp YuTgYBaQlzhyKRskzCwgLfHo7wx2iLC6xJQpuRCtvxglul9uZASpERaQlOi+cwdsPouAqsS2 pb9ZQGw2AS2Jt7fbwcaLCChI7GvrZ4GYGSaxvmEDM0SvncS6x9/ZIU4wlLjx4CsLxIJtrBJr l3eDFXEK2ErsXbkXbJCogLLE38P3wIokBFawSRx+2s46gVFkFpIfZiH8MAvJD7MQfljAyLKK USg3MTNHNzPPTC+xoCAnVS85P3cTIyg2ptuJ7mA8s8rqEKMAB6MSD++OaTIRQqyJZcWVuYcY pTlYlMR5Lx4DCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDcHrfDafMav3JV5bU3Nl23ep13 +aqMZtXdh9sXup46tntn8iLxtl28sdMdrPiOX/smcXMft/WGxBudu38krtsj5xpzc8v3PrcS 9vsn5BRD8i59zf4vsWEOA0vjnbUbHYtZGic9OuBabfOr2sLbTNuC+0e3dp9UietRv463D2qO 5jxR+Oqca1+rxFKckWioxVxUnAgAekjCNW4CAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FD8QTf/gkyEwYSJZhYrz61gtjj89im7 xefV19kcmD12zrrL7rFkyU8mj5ZnJ9kCmKO4bFJSczLLUov07RK4MhZOa2UvOClS8XqyUgPj ZYEuRk4OCQETiX9nL7NC2GISF+6tZ+ti5OIQEjjEKLFm3zSwBK+AoMSPyfdYuhg5OJgF5CWO XMoGCTMLSEs8+juDHSKsLjFlSi5E6y9Gie6XGxlBaoQFJCW679xhBrFZBFQlti39zQJiswlo Sby93Q42XkRAQWJfWz8LxMwwifUNG5gheu0k1j3+zg5xgqHEjQdfWSAWbGOVWLu8G6yIU8BW Yu/KvWCDRAWUJf4evscygVFoFpKzZyGcPQvJ2bMQzl7AyLKKUaAoNSex0kwvsaAgJ1UvOT93 EyM4xAujdjA2LLc6xCjAwajEw7tjmkyEEGtiWXFlLjCIOJiVRHgXnQYK8aYkVlalFuXHF5Xm pBYfYpTmYFES533hA5QSSE8sSc1OTS1ILYLJMnFwSjUwaupujrBLnyFlIuT26twb36kO5ztu eDyVu/ltlfvp+un3NY8kd/NoVl9cfPTb0nyW9YotElUz/fM0raZvsY1fILi9+f69hRNP/WgI Whr8zFthTvNqXbO5KzevE3u83/bWBPX+8k75QKWDP3+L/zzOW9L5W9vrcFV10DWNexNKg6e8 busuU688qcRSnJFoqMVcVJwIADXcrDdtAgAA
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 18:16:17 -0000


On 04/11/16 - 11:02:02, Alan Ford wrote:
> > On 4 Nov 2016, at 10:12, <> <> wrote:
> >> -----Message d'origine-----
> >> De : Mirja Kühlewind []
> >> Envoyé : vendredi 4 novembre 2016 10:34
> >> À : BOUCADAIR Mohamed IMT/OLN; Alan Ford
> >> Cc :
> >> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> >> 
> >> Hi all,
> >> 
> >> first, I agree with Alan that such a signal does not need to/should not be
> >> part of the MPTCP protocol.
> > 
> > [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.