Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <> Fri, 04 November 2016 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 372591294DA for <>; Fri, 4 Nov 2016 08:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Qpn5mK83WDpB for <>; Fri, 4 Nov 2016 08:17:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 783FE129470 for <>; Fri, 4 Nov 2016 08:17:54 -0700 (PDT)
Received: by with SMTP id n67so56320623wme.1 for <>; Fri, 04 Nov 2016 08:17:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ecsDX6hF5pY3zD80Poi/zw90b2UPY1IMu7uJJ30m6H0=; b=KZ2UvrskbI1SaxvV7PbY4OWtK+boexHQqb8atXrVI+VcCKIO1ujOxxThg3SH1yfTmP gbL2q77QPH27CmPvUpq1KFRyOrMp4uY4gvH6HOzMh/ee9nM2ktTMI6PIYY2SI5Mb7/Da 8cPvFl6nEaCBIgCPaucmyqutYj2RYKVPNCX7IUsy9n1Thq0ZWGCrN3oBIJroWpV6ATov TyxiaN2LyWZ3ISbq4sKIfzpdfwh837hKUAMANfEWS5y6ex6o2RBcaNJYBD1hbOR2TByQ d/WKc8a+/oqPh/Tmdbd3Qae/CGYHVcaf0hq3cQAaakPkCygXWpxKnAByK5DGT6WgvUeN aNXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ecsDX6hF5pY3zD80Poi/zw90b2UPY1IMu7uJJ30m6H0=; b=bxlF85lgaD1uEJSSyELHPL5ZjmAUSoln3vbWAmS4XYj8Vyxs7hCPh7Cc4gVfSkQfVo 4cjFK5S1II5Gpf4eWGPiXWmG9L063Tff0YCRHtwi7/nO0fUijQVPyXs1Vj0HDkwyP2aB LPjMwB0RE/78W+FZLKmolo5WEuhUZ0NAK+coExcJIZf47hBIkRnwnHJeMhEe+kEMnYOn 0G1+M5KMjUMOvQqwYoSk5purg6V8YuzMrCcfa6lAdcJC4ExFJxZSVukuqa7mVSaqKFOw I98sFg2DM+svE46z4ffdj55RZnxwHnBg6S1+1RJ1pDRoGApV7ThsNAstGCfCdAs+nQoF SKyg==
X-Gm-Message-State: ABUngvc0/j6rdYcu/lBn/nVY5pO6FKCCjd4faWnQ+fsGxxkNd0DobgedaZh/Gk0AiPya5g==
X-Received: by with SMTP id cj2mr12007469wjc.25.1478272672985; Fri, 04 Nov 2016 08:17:52 -0700 (PDT)
Received: from alans-mbp.lan ([]) by with ESMTPSA id k74sm5072325wmd.18.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Nov 2016 08:17:52 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_11D88FFE-2DA8-442E-8704-D289E7CB3DC1"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Fri, 04 Nov 2016 15:17:51 +0000
Message-Id: <>
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> <> <> <> <>
X-Mailer: Apple Mail (2.3124)
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:17:57 -0000

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.