Re: [multipathtcp] potential MPTCP proxy charter item

Alan Ford <> Mon, 07 November 2016 06:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D9F1129C5B for <>; Sun, 6 Nov 2016 22:22:40 -0800 (PST)
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 i97qLU_7u4rC for <>; Sun, 6 Nov 2016 22:22:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4F06129C57 for <>; Sun, 6 Nov 2016 22:22:38 -0800 (PST)
Received: by with SMTP id t79so156616938wmt.0 for <>; Sun, 06 Nov 2016 22:22:38 -0800 (PST)
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=metHnNMoaR7qkudxOeqLhBPdKiNnTa7ORkGuWcNgZvk=; b=XpqiMO0AuGz0GL7DeVLsw0gh1aq1WZUHLyUNbcLogcjqCQ4a+yWMVAJXsKQeT59vG+ EMZYMGBuKekBW6/WcCQzBPhnAQ8Va/uDSVVxgEGRa60/KY6S6c0ZJrN2RqtDDlE9l1Ca x2L2sSApLNjdEQAcYiRbejPZ0HMCDs1pwg8nZedBInoItH/9b6H9bmTt7wWAsQeo6nwU BmIKoYy3u4BFq3LdkmWpq50gQostLitIyn0rYVKcQiKHBN1sOVWgEfe9XKIZ7bHBN9gG YNksqQs0DsgqHTJAyTC4r1btYWY68NvsTZqofJjcAQO3vqLhLBfW6hPR6DyI4i/DWZLX 13Jw==
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=metHnNMoaR7qkudxOeqLhBPdKiNnTa7ORkGuWcNgZvk=; b=e0c8HJClNYsTBHlTPS3PDzaZaaUFOVST13LsrFAExpUvOW/S5rlxFc4v1AJT+W9Io5 wLjqwZ3yRNwxGFVD6xX5cyFZ2BiT1CBoZAZ6hczj8eelgLDr7gvvBPG5IxrCq9fK/Ndj W/8JECiuciHuVz4rRerPgs3uhsCHKnRDeBMwE2Td6E4MlGn50aRm0cHHL7+iqaoshB5S qSaR4mk0nBOOvhCeDTJKa9alZr64Xsbf1hNJxATuuXZ8Ny14x9Ak6ZSJp4lNEe9sODTZ nUsOtWqcWbbadZiQ6AZZHlIDtp5/pjVPVQDuYIbnrGFI1htD+szQ7JzxbaqKR8PJy0RT gJ8g==
X-Gm-Message-State: ABUngvdUErfprA/RXGmkjv24pwCeWPv2Jy54qVdvw082jK6KKTZgWEjgL5CF+/qdYGoyQg==
X-Received: by with SMTP id r204mr4758528wmg.69.1478499757224; Sun, 06 Nov 2016 22:22:37 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g142sm11510066wmd.2.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 06 Nov 2016 22:22:36 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_345BBAC3-8CFD-4C6D-B256-B52891334FCD"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Mon, 07 Nov 2016 06:22:34 +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: Mon, 07 Nov 2016 06:22:40 -0000

Hi Olivier,

> On 6 Nov 2016, at 21:25, Olivier Bonaventure <> wrote:
>> 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/.
> Indeed, the same could apply for TCP, SCTP and probably any transport protocol.

Good, I’m glad we agree here :-)

>> Why are you trying to make it a MPTCP option?
> The need comes from MPTCP. It could be defined as a TCP option instead of an MPTCP option. I think that explicitly specifying a proxy node is a useful feature that should be part of the transport protocol and not tied to a specific application. We are less and less in a pure end-to-end deployment model for the Internet and making those transport proxies explicit would make sense.

Why is it an option, however? When you are explicitly targeting a proxy node, surely the proxy is just as capable of pulling the data out of the payload here?

>> 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.
> RAO is not a solution because support for IP options on routers is far from optimal. The main reason why we proposed to use the option in implicit mode is because the working group asked to merge the plain-mode and transparent mode drafts in July.

I was under the impression you would be deploying this is controlled networks, or at least networks where operators had full choice of the equipment (CPEs and proxies) that would be deployed.