Re: [multipathtcp] potential MPTCP proxy charter item

Olivier Bonaventure <> Sun, 06 November 2016 21:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C27D1298CC for <>; Sun, 6 Nov 2016 13:25:21 -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 TxXEfnN7xykY for <>; Sun, 6 Nov 2016 13:25:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24C651298BA for <>; Sun, 6 Nov 2016 13:25:20 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id C0AD367DA25; Sun, 6 Nov 2016 22:25:12 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 C0AD367DA25
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1478467513; bh=H0/dy5GvOtsKzhc+9LaalfEvxQCli39pgYY6jpC2hXU=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=V59v34XxCMpmiHTHZIi9/pMhHoxXSQZeqzljZ2CAWPDK15fob/5FR5k2/deC7R9uf +yX4VBFYNOWawPoaNBr+zXyZIi7gpYOzTGeb2H2acE51TgEWrZ7IVD5pR/6n685wkG pKkAso0rv9MAPCBLG0Sq9tEJJjOYk3Xie6wU/5VU=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-5
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> <> <> <> <> <>
To: Alan Ford <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Sun, 06 Nov 2016 22:25:12 +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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: C0AD367DA25.A3B75
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: Sun, 06 Nov 2016 21:25:21 -0000


>> 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/.

Indeed, the same could apply for TCP, SCTP and probably any transport 

> 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.

> 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.